From nobody Sun Nov 2 03:03:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFBD1A8759 for ; Sun, 2 Nov 2014 03:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCdE4ZmC7Hyb for ; Sun, 2 Nov 2014 03:03:33 -0800 (PST) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485A21A873E for ; Sun, 2 Nov 2014 03:03:32 -0800 (PST) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1XkswS-0003UL-DI; Sun, 02 Nov 2014 12:03:28 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1XkswS-0007ov-4Z; Sun, 02 Nov 2014 12:03:28 +0100 From: Florian Weimer To: Stephan Wenger References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> Date: Sun, 02 Nov 2014 12:03:28 +0100 In-Reply-To: (Stephan Wenger's message of "Wed, 22 Oct 2014 19:45:40 +0000") Message-ID: <87fve1zwxr.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SGNnEwSpzEAmrEcOXIuBS8C9Wcw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 11:03:35 -0000 * Stephan Wenger: > Nokia has made MPEG and ISO/IEC officially aware that they are not > willing to license essential patents under RAND terms. Does this even matter, in relative terms? RAND licenses for H.264 aren't available, either. The only patent licenses readily available to implementors explicitly exclude commercial use of implementations, which can hardly qualify as =E2=80=9Creasonable=E2=80=9D. This is not restricted to Cisco's OpenH264 effort, most video conferencing equipment is not licensed for commercial use. From nobody Sun Nov 2 04:48:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEBD1A8788 for ; Sun, 2 Nov 2014 04:48:31 -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 VYYdSqUGufTG for ; Sun, 2 Nov 2014 04:48:29 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923F01A8717 for ; Sun, 2 Nov 2014 04:48:29 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so3944475wgh.13 for ; Sun, 02 Nov 2014 04:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:in-reply-to:message-id:date:to :content-transfer-encoding:mime-version; bh=zHnG1ATbAQUr138Ni2JGUG7rDQ1RC6EtMtJb6IDZQsg=; b=MEwC6+27Odqo/oHFn8fuI0tTtzKof/1fb7/ezz00h93Fk9s00qZjwKRMAHjhoDKnXR 6e9nX6UqPJmDaKmw5CnRNbw0iKTng2U8AtPr4JpBFjaspREi5XaaIl/uTOL2dtJvJiIz ZLwDmckT7gBH2L4P2yl4QaV9XxgWfje+FZt3QVgBeZxAPLj7ITcsWDaeQSCnNzhgQ+kT OGOrBE0hHWx6V8aUi4yf0AXeZM5i5cjmlBcRB4ncmnDNXylGiLCLU5FgeAwDDG6UekUv F1j6KYY7Osm52plXaP4iv52RFGxZyMMgVEc0Mo8bO4k+RbUK8Eg8/OkHTiQXeyxn+j2u 3ZRw== X-Received: by 10.195.11.6 with SMTP id ee6mr3125724wjd.95.1414932508237; Sun, 02 Nov 2014 04:48:28 -0800 (PST) Received: from [100.68.115.189] (130.82-130-187.dynamic.clientes.euskaltel.es. [82.130.187.130]) by mx.google.com with ESMTPSA id f7sm5102290wiz.13.2014.11.02.04.48.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Nov 2014 04:48:27 -0800 (PST) References: From: Victor Pascual Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D201) In-Reply-To: Message-Id: Date: Sun, 2 Nov 2014 13:48:22 +0100 To: "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/49ciFtSLnzwK1uY3dafyppA5jY4 Subject: Re: [rtcweb] draft agenda for rtcweb at ietf91? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 12:48:31 -0000 I see draft agenda has now been published: http://tools.ietf.org/wg/rtcweb/a= genda -Victor > On Oct 29, 2014, at 10:11 AM, Victor Pascual Avila wrote: >=20 > Dear chairs, >=20 > where could I find the draft agenda for the upcoming meeting? >=20 > Thanks in advance, > -Victor From nobody Mon Nov 3 07:25:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99001A0137 for ; Mon, 3 Nov 2014 07:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] 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 HoqQRfr4jROt for ; Mon, 3 Nov 2014 07:25:14 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64ECA1A006C for ; Mon, 3 Nov 2014 07:25:14 -0800 (PST) Received: from [130.209.247.112] (port=54462 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XlJVF-0004W0-Ul; Mon, 03 Nov 2014 15:25:11 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_DE992C30-0568-49E7-9A68-83B5948EE41D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Mon, 3 Nov 2014 15:25:05 +0000 Message-Id: <790697E2-9C87-4B17-A49F-786292CF22AC@csperkins.org> References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> To: Bernard Aboba X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UIS7SLzqy2f95vn-mdth0pW-LKE Cc: "" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Nov 2014 15:25:17 -0000 --Apple-Mail=_DE992C30-0568-49E7-9A68-83B5948EE41D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would have thought the compatibility arguments offered to support = non-BUNDLE media applied here too, but okay. If I change the last = paragraph of rtp-usage, section 6.1 to: Receivers are REQUIRED to implement support for RTP retransmission packets [RFC4588] sent using SSRC multiplexing, and MAY also support RTP retransmission packets sent using session multiplexing. Senders MAY send RTP retransmission packets in response to NACKs if support for the RTP retransmission payload format has been negotiated, and if the sender believes it is useful to send a retransmission of the packet(s) referenced in the NACK. Senders do not need to retransmit every NACKed packet. is this acceptable? Colin On 28 Oct 2014, at 03:41, Bernard Aboba wrote: > Justin said:=20 >=20 > "I don't think the WG ever explicitly signed up for = session-multiplexing of RTX data" >=20 > [BA] I agree, and in addition would say the same thing with respect to = FEC - one of the fundamental objections to RFC 5109 is that it only = support session-multiplexing, not SSRC multiplexing. =20 >=20 > On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti = wrote: >=20 >=20 > On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins = wrote: > On 27 Oct 2014, at 17:17, Sergio Garcia Murillo = wrote: >> On 27/10/2014 18:10, Colin Perkins wrote: >>> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo = wrote: >>>> On 27/10/2014 17:45, Colin Perkins wrote: >>>>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo = wrote: >>>>>> On 27/10/2014 17:36, Colin Perkins wrote: >>>>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: >>>>>>>> Not sure if it is done on pourpose, but according to the RTP = usage draft, it may seem that full RFC 4588 is mandated at the = recevier side: >>>>>>>>=20 >>>>>>>> Receivers are REQUIRED to implement support for RTP = retransmission >>>>>>>> packets [RFC4588]. >>>>>>>>=20 >>>>>>>> That would include both modes, session and ssrc multiplexing. = Given the extensive usage of bundle and current implementations, session = multiplexing support doesn't make much sense. >>>>>>>>=20 >>>>>>>> Should we drop it, and state that only ssrc-multiplexing shall = be supported at the receiving end? >>>>>>>=20 >>>>>>> I don=92t see any advantage to doing so, given that support for = non-BUNDLE sessions is REQUIRED. You need to implement the signalling = needed for session-multiplexing of retransmission packet anyway, so = disallowing it buys you nothing. >>>>>>=20 >>>>>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, = what I don't see is how to do session multiplexing with BUNDLE sessions.=20= >>>>>=20 >>>>> You can=92t do session multiplexing for BUNDLE sessions; by = definition they use SSRC multiplexing. You could do non-BUNDLE sessions, = with retransmission sent on a separate RTP session though. >>>>>=20 >>>> So, you are saying exactly the same than me. SSRC multiplexing = supports both BUNDLE and NON-BUNDLE. So, why require support for session = multiplexing at all? As a developer, I don't see why I would have to = implement something that would be rarely used and provide no extra = benefit. >>>=20 >>> Non-BUNDLE is session multiplexing. It uses a separate RTP session = for the retransmissions.=20 >> Maybe I am the missing something, if you don't use bundle to send the = audio/video on same rtpsession, you can still send rtx+video on same = session. That's it non-bundle with ssrc-multiplexing. Are we referring = to different things? >=20 > Sure, but that doesn=92t alter the fact that the group decided that = non-BUNDLE media needs to be supported. Sending retransmission on a = separate RTP session is as needed for interoperability with legacy = systems as sending audio and video on separate RTP sessions (and = shouldn=92t be hard to support, since it uses the same mechanisms). >=20 > Non-BUNDLE media needs to be supported, but I don't think the WG ever = explicitly signed up for session-multiplexing of RTX data. Unified plan = is quite clear in its assertion that the primary, RTX, and FEC flows for = a given media stream should all be represented by a single m=3D line, = e.g. SSRC-multiplexed.=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_DE992C30-0568-49E7-9A68-83B5948EE41D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = would have thought the compatibility arguments offered to support = non-BUNDLE media applied here too, but okay. If I change the last = paragraph of rtp-usage, section 6.1 to:

   Receivers are REQUIRED to implement = support for RTP retransmission
   packets [RFC4588] sent using SSRC multiplexing, and = MAY also support
   RTP = retransmission packets sent using session multiplexing.  = Senders
   MAY send RTP = retransmission packets in response to NACKs if support
   for the RTP retransmission payload = format has been negotiated, and if
   the sender believes it is useful to send a = retransmission of the
   = packet(s) referenced in the NACK.  Senders do not need to = retransmit
   every NACKed = packet.

is this = acceptable?

Colin




On 28 Oct 2014, at 03:41, Bernard Aboba = <bernard.aboba@gmail.com> = wrote:
Justin = said: 

"I don't think the = WG ever explicitly signed up for session-multiplexing of RTX = data"

[BA] I agree, and in addition = would say the same thing with respect to FEC - one of the fundamental = objections to RFC 5109 is that it only support session-multiplexing, not = SSRC multiplexing.  

On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti = <juberti@google.com> = wrote:


On Mon, Oct 27, 2014 at = 12:16 PM, Colin Perkins <csp@csperkins.org> wrote:
On 27 = Oct 2014, at 17:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> = wrote:
=20 =20 =20
On 27/10/2014 18:10, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
=20
On 27/10/2014 17:45, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
=20
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP =
retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=92t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=92t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different = things?

Sure, but that = doesn=92t alter the fact that the group decided that non-BUNDLE media = needs to be supported. Sending retransmission on a separate RTP session = is as needed for interoperability with legacy systems as sending audio = and video on separate RTP sessions (and shouldn=92t be hard to support, = since it uses the same mechanisms).

<= div>Non-BUNDLE media needs to be supported, but I don't think the WG = ever explicitly signed up for session-multiplexing of RTX data. Unified = plan is quite clear in its assertion that the primary, RTX, and FEC = flows for a given media stream should all be represented by a single m=3D = line, e.g. SSRC-multiplexed. 

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





-- 
Colin Perkins

<= /div>


= --Apple-Mail=_DE992C30-0568-49E7-9A68-83B5948EE41D-- From nobody Mon Nov 3 07:34:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACACE1A0069 for ; Mon, 3 Nov 2014 07:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzkHoBXRG2Xg for ; Mon, 3 Nov 2014 07:34:49 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75C11A0211 for ; Mon, 3 Nov 2014 07:34:48 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so11382464wgh.34 for ; Mon, 03 Nov 2014 07:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=6aVA2ADvokr9xvpmjDXnE9mpTlvvHTA6aspQqS593KM=; b=qhqECLD0FwPG5MliP5csC7AB3jTA5jGL5+Hl0l8pWR0ZVINDpKle5Tq8ZQBCmSjEax 9U5dZXXcLH23s5k+5iewNEcxiLMpieoznGNJhVscb5ZXenFkfU2YdRkMO8IRr8B9jg9G L0Zg4HIYfUVSFEnqMpu6F5x4W742W/rNAttBNKLj/Rb8xg7GtOB7M7Ss8DVMErE9NY7c gfxIchMFXUCrrfYfqVU9dwgKse4/b1B7txnf15bQD2mxusk7823Qb9K+VIdvU5YvmMgz b2MmDSL5KYNKtg+t5ih4+WVtClnX43+1Sj9wJ5FP1vP/GPssIhPk49yosSaxNx88eLc5 yYsA== X-Received: by 10.194.184.140 with SMTP id eu12mr31016951wjc.47.1415028887078; Mon, 03 Nov 2014 07:34:47 -0800 (PST) Received: from [192.168.1.37] (144.Red-83-43-188.dynamicIP.rima-tde.net. [83.43.188.144]) by mx.google.com with ESMTPSA id bl9sm9070189wib.24.2014.11.03.07.34.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 07:34:46 -0800 (PST) Message-ID: <5457A0A7.7060004@gmail.com> Date: Mon, 03 Nov 2014 16:35:03 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> <790697E2-9C87-4B17-A49F-786292CF22AC@csperkins.org> In-Reply-To: <790697E2-9C87-4B17-A49F-786292CF22AC@csperkins.org> Content-Type: multipart/alternative; boundary="------------030802030201070900030909" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4nMFKI0yQ-9J78Ieugy-yUW8kEA Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Nov 2014 15:34:52 -0000 This is a multi-part message in MIME format. --------------030802030201070900030909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fine for me, thanxs Colin BR Sergio On 03/11/2014 16:25, Colin Perkins wrote: > I would have thought the compatibility arguments offered to support > non-BUNDLE media applied here too, but okay. If I change the last > paragraph of rtp-usage, section 6.1 to: > > Receivers are REQUIRED to implement support for RTP retransmission > packets [RFC4588] sent using SSRC multiplexing, and MAY also support > RTP retransmission packets sent using session multiplexing. Senders > MAY send RTP retransmission packets in response to NACKs if support > for the RTP retransmission payload format has been negotiated, and if > the sender believes it is useful to send a retransmission of the > packet(s) referenced in the NACK. Senders do not need to retransmit > every NACKed packet. > > is this acceptable? > > Colin > > > > > On 28 Oct 2014, at 03:41, Bernard Aboba > wrote: >> Justin said: >> >> "I don't think the WG ever explicitly signed up for >> session-multiplexing of RTX data" >> >> [BA] I agree, and in addition would say the same thing with respect >> to FEC - one of the fundamental objections to RFC 5109 is that it >> only support session-multiplexing, not SSRC multiplexing. >> >> On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti > > wrote: >> >> >> >> On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins >> > wrote: >> >> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo >> > > wrote: >>> On 27/10/2014 18:10, Colin Perkins wrote: >>>> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo >>>> >>> > wrote: >>>>> On 27/10/2014 17:45, Colin Perkins wrote: >>>>>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo >>>>>> >>>>> > wrote: >>>>>>> On 27/10/2014 17:36, Colin Perkins wrote: >>>>>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo >>>>>>>> >>>>>>> > wrote: >>>>>>>>> Not sure if it is done on pourpose, but according to >>>>>>>>> the RTP usage draft, it may seem that full RFC 4588 is >>>>>>>>> mandated at the recevier side: >>>>>>>>> >>>>>>>>> Receivers are REQUIRED to implement support for RTP retransmission >>>>>>>>> packets [RFC4588 ]. >>>>>>>>> >>>>>>>>> That would include both modes, session and ssrc >>>>>>>>> multiplexing. Given the extensive usage of bundle and >>>>>>>>> current implementations, session multiplexing support >>>>>>>>> doesn't make much sense. >>>>>>>>> >>>>>>>>> Should we drop it, and state that only >>>>>>>>> ssrc-multiplexing shall be supported at the receiving end? >>>>>>>> >>>>>>>> I don't see any advantage to doing so, given that >>>>>>>> support for non-BUNDLE sessions is REQUIRED. You need >>>>>>>> to implement the signalling needed for >>>>>>>> session-multiplexing of retransmission packet anyway, >>>>>>>> so disallowing it buys you nothing. >>>>>>> >>>>>>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE >>>>>>> sessions, what I don't see is how to do session >>>>>>> multiplexing with BUNDLE sessions. >>>>>> >>>>>> You can't do session multiplexing for BUNDLE sessions; by >>>>>> definition they use SSRC multiplexing. You could do >>>>>> non-BUNDLE sessions, with retransmission sent on a >>>>>> separate RTP session though. >>>>>> >>>>> So, you are saying exactly the same than me. SSRC >>>>> multiplexing supports both BUNDLE and NON-BUNDLE. So, why >>>>> require support for session multiplexing at all? As a >>>>> developer, I don't see why I would have to implement >>>>> something that would be rarely used and provide no extra >>>>> benefit. >>>> >>>> Non-BUNDLE is session multiplexing. It uses a separate RTP >>>> session for the retransmissions. >>> Maybe I am the missing something, if you don't use bundle to >>> send the audio/video on same rtpsession, you can still send >>> rtx+video on same session. That's it non-bundle with >>> ssrc-multiplexing. Are we referring to different things? >> >> Sure, but that doesn't alter the fact that the group decided >> that non-BUNDLE media needs to be supported. Sending >> retransmission on a separate RTP session is as needed for >> interoperability with legacy systems as sending audio and >> video on separate RTP sessions (and shouldn't be hard to >> support, since it uses the same mechanisms). >> >> Non-BUNDLE media needs to be supported, but I don't think the WG >> ever explicitly signed up for session-multiplexing of RTX data. >> Unified plan is quite clear in its assertion that the primary, >> RTX, and FEC flows for a given media stream should all be >> represented by a single m= line, e.g. SSRC-multiplexed. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030802030201070900030909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Fine for me, thanxs Colin

BR
Sergio
On 03/11/2014 16:25, Colin Perkins wrote:
I would have thought the compatibility arguments offered to support non-BUNDLE media applied here too, but okay. If I change the last paragraph of rtp-usage, section 6.1 to:

   Receivers are REQUIRED to implement support for RTP retransmission
   packets [RFC4588] sent using SSRC multiplexing, and MAY also support
   RTP retransmission packets sent using session multiplexing.  Senders
   MAY send RTP retransmission packets in response to NACKs if support
   for the RTP retransmission payload format has been negotiated, and if
   the sender believes it is useful to send a retransmission of the
   packet(s) referenced in the NACK.  Senders do not need to retransmit
   every NACKed packet.

is this acceptable?

Colin




On 28 Oct 2014, at 03:41, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Justin said: 

"I don't think the WG ever explicitly signed up for session-multiplexing of RTX data"

[BA] I agree, and in addition would say the same thing with respect to FEC - one of the fundamental objections to RFC 5109 is that it only support session-multiplexing, not SSRC multiplexing.  

On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti <juberti@google.com> wrote:


On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins <csp@csperkins.org> wrote:
On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 18:10, Colin Perkins wrote:
On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:45, Colin Perkins wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don’t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can’t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things?
Sure, but that doesn’t alter the fact that the group decided that non-BUNDLE media needs to be supported. Sending retransmission on a separate RTP session is as needed for interoperability with legacy systems as sending audio and video on separate RTP sessions (and shouldn’t be hard to support, since it uses the same mechanisms).

Non-BUNDLE media needs to be supported, but I don't think the WG ever explicitly signed up for session-multiplexing of RTX data. Unified plan is quite clear in its assertion that the primary, RTX, and FEC flows for a given media stream should all be represented by a single m= line, e.g. SSRC-multiplexed. 

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





-- 
Colin Perkins






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

--------------030802030201070900030909-- From nobody Mon Nov 3 10:09:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1C51A6FB1 for ; Mon, 3 Nov 2014 10:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_QP_LONG_LINE=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 H0-Pel8UFNBH for ; Mon, 3 Nov 2014 10:08:53 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD821A6FAD for ; Mon, 3 Nov 2014 10:08:53 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id ft15so11906204pdb.35 for ; Mon, 03 Nov 2014 10:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=/HW67XLnV34irQktSgixdsWwpAODf7q0R7ewRITwXaM=; b=Zhr85tQRcFtyIDuZXm/bLnwW6DNeHEGwLbc9TXFZdt9OrbBQJUU/kM5Du4ouck7VdK e/CFvGXqqN/fYTi3YuRW7fYa/f5KjnB1vN7zunrZjYotnbv0mYys7FQi6JmV9zgtb9hV 92KK4O5/N884kXgWYXHqcKKTO4q+X+JMjYparv1VC86eThWeExxlwowWxylaxn/wh099 HfAbkUKwVlGt2oUN5TE9J2QjNUYuBD8ALQQbrhDzwxD0pBLFwsHqn59c4abnzAW9AFVK CoWe7leWWLGYcEkNSgLL6Gsm407ncN4QSsirC46VAjszZ6Hpwe7B9AdFI9VXyimzQEBO /CJQ== X-Received: by 10.70.43.46 with SMTP id t14mr44620874pdl.57.1415038132643; Mon, 03 Nov 2014 10:08:52 -0800 (PST) Received: from [10.248.157.153] (mobile-166-171-121-202.mycingular.net. [166.171.121.202]) by mx.google.com with ESMTPSA id s7sm7836192pdi.72.2014.11.03.10.08.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 10:08:51 -0800 (PST) References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> <790697E2-9C87-4B17-A49F-786292CF22AC@csperkins.org> <5457A0A7.7060004@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5457A0A7.7060004@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-93C1B196-DD54-4434-8660-C82B5FA3A69E Content-Transfer-Encoding: 7bit Message-Id: <693F1285-01C9-4214-8304-0607E6C07141@gmail.com> X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Mon, 3 Nov 2014 10:08:44 -0800 To: Sergio Garcia Murillo Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HILo98yYJY_XLbXMv7kvLfLX7Wg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Nov 2014 18:08:56 -0000 --Apple-Mail-93C1B196-DD54-4434-8660-C82B5FA3A69E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fine with me too. > On Nov 3, 2014, at 7:35 AM, Sergio Garcia Murillo wrote: >=20 > Fine for me, thanxs Colin >=20 > BR > Sergio >> On 03/11/2014 16:25, Colin Perkins wrote: >> I would have thought the compatibility arguments offered to support= non-BUNDLE media applied here too, but okay. If I change the last paragraph= of rtp-usage, section 6.1 to: >>=20 >> Receivers are REQUIRED to implement support for RTP retransmission >> packets [RFC4588] sent using SSRC multiplexing, and MAY also support >> RTP retransmission packets sent using session multiplexing. = Senders >> MAY send RTP retransmission packets in response to NACKs if support >> for the RTP retransmission payload format has been negotiated, and if >> the sender believes it is useful to send a retransmission of= the >> packet(s) referenced in the NACK. Senders do not need to retransmit >> every NACKed packet. >>=20 >> is this acceptable? >>=20 >> Colin >>=20 >>=20 >>=20 >>=20 >>> On 28 Oct 2014, at 03:41, Bernard Aboba wrote:= >>> Justin said:=20 >>>=20 >>> "I don't think the WG ever explicitly signed up for session-multiplexing= of RTX data" >>>=20 >>> [BA] I agree, and in addition would say the same thing with respect to FE= C - one of the fundamental objections to RFC 5109 is that it only support se= ssion-multiplexing, not SSRC multiplexing. =20 >>>=20 >>>> On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti wro= te: >>>>=20 >>>>=20 >>>>> On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins wr= ote: >>>>>> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo wrote: >>>>>>> On 27/10/2014 18:10, Colin Perkins wrote: >>>>>>>> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo wrote: >>>>>>>>> On 27/10/2014 17:45, Colin Perkins wrote: >>>>>>>>>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo wrote: >>>>>>>>>>> On 27/10/2014 17:36, Colin Perkins wrote: >>>>>>>>>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo wrote: >>>>>>>>>>>> Not sure if it is done on pourpose, but according to the RTP us= age draft, it may seem that full RFC 4588 is mandated at the recevier side: >>>>>>>>>>>>=20 >>>>>>>>>>>> Receivers are REQUIRED to implement support for RTP retrans= mission >>>>>>>>>>>> packets [RFC4588]. >>>>>>>>>>>>=20 >>>>>>>>>>>> That would include both modes, session and ssrc multiplexing. G= iven the extensive usage of = bundle and current = implementations, session multiplexing support doesn't make much s= ense. >>>>>>>>>>>>=20 >>>>>>>>>>>> Should we drop it, and state that only = ssrc-multiplexing shall be supported at th= e receiving end? >>>>>>>>>>>=20 >>>>>>>>>>> I don=E2=80=99t see any advantage to doing so, given that suppor= t for non-BUNDLE sessions is = REQUIRED. You need to implement the signalling needed for session= -multiplexing of retransmission packet anyway, so disallowing it buys you no= thing. >>>>>>>>>>=20 >>>>>>>>>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions,= what I don't see is how to do session multiplexing with BUNDLE sessions. >>>>>>>>>=20 >>>>>>>>> You can=E2=80=99t do session multiplexing for BUNDLE sessions; by d= efinition they use SSRC multiplexing. You could do non-BUNDLE sessions, with= retransmission se= nt on a separate RTP session = though. >>>>>>>> So, you are saying exactly the same than me. SSRC multiplexing supp= orts both BUNDLE and NON-BUNDLE. So, why require support for session multipl= exing at all? As a developer, I don't see why I would have to implement some= thing that would be rarely used and provide no extra benefit. >>>>>>>=20 >>>>>>> Non-BUNDLE is session multiplexing. It uses a separate RTP session f= or the retransmissions. >>>>>> Maybe I am the missing something, if you don't use bundle to send the= audio/video on same rtpsession, you can still send rtx+video on same sessio= n. That's it non-bundle with ssrc-multiplexing. Are we referring to differen= t things? >>>>>=20 >>>>> Sure, but that doesn=E2=80=99t alter the fact that the group decided t= hat non-BUNDLE media needs to be supported. Sending retransmission on a sepa= rate RTP session is as needed for interoperability with legacy systems as se= nding audio and video on separate RTP sessions (and shouldn=E2=80=99t be har= d to support, since it uses the same mechanisms). >>>>=20 >>>> Non-BUNDLE media needs to be supported, but I don't think the WG ever e= xplicitly signed up for session-multiplexing of RTX data. Unified plan is qu= ite clear in its assertion that the primary, RTX, and FEC flows for a given m= edia stream should all be represented by a single m=3D line, e.g. SSRC-multi= plexed.=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-93C1B196-DD54-4434-8660-C82B5FA3A69E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Fine with me too.



On Nov 3, 2014, at 7:35 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> w= rote:

=20 =20 =20
Fine for me, thanxs Colin

BR
Sergio
On 03/11/2014 16:25, Colin Perkins wrote:
I would have thought the compatibility arguments offered to support non-BUNDLE media applied here too, but okay. If I change the last paragraph of rtp-usage, section 6.1 to:

   Receivers are REQUIRED to i= mplement support for RTP retransmission
   packets [RFC4588] sent usin= g SSRC multiplexing, and MAY also support
   RTP retransmission packets s= ent using session multiplexing.  Senders
   MAY send RTP retransmission= packets in response to NACKs if support
   for the RTP retransmission p= ayload format has been negotiated, and if
   the sender believes it is u= seful to send a retransmission of the
   packet(s) referenced in the= NACK.  Senders do not need to retransmit
   every NACKed packet.

is this acceptable?

Colin




On 28 Oct 2014, at 03:41, Bernard Aboba <bernard.aboba@gmail= .com> wrote:
Justin said: 

"I don't think the WG ever explicitly signed up for session-multiplexing of RTX data"

[BA] I agree, and in addition would say the same thing with respect to FEC - one of the fundamental objections to RFC 5109 is that it only support session-multiplexing, not SSRC multiplexing.  

On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti <jube= rti@google.com> wrote:


On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins = <csp@csperkins.org> wrote:
On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 18:10, Colin Perkins wrote:
On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
=
On 27/10/2014 17:45, Colin Perkins wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:36, Colin Perkins wrote:
=
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers ar=
e REQUIRED to implement support for RTP retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=E2=80=99= t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexi= ng of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=E2=80=99= t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things?
Sure, but that doesn=E2=80=99t alter the fact that the group decided that non-BUNDLE media needs to be supported. Sending retransmission on a separate RTP session is as needed for interoperability with legacy systems as sending audio and video on separate RTP sessions (and shouldn=E2=80=99t be hard to support, since it uses the same mechanisms).

Non-BUNDLE media needs to be supported, but I don't think the WG ever explicitly signed up for session-multiplexing of RTX data. Unified plan is quite clear in its assertion that the primary, RTX, and FEC flows for a given media stream should all be represented by a single m=3D line, e.g. SSRC-multiplexed. 

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





-- 
Colin Perkins






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

=20
____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-93C1B196-DD54-4434-8660-C82B5FA3A69E-- From nobody Mon Nov 3 11:01:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC461A009C for ; Mon, 3 Nov 2014 11:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] 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 aYjrC-hNyjvU for ; Mon, 3 Nov 2014 11:01:22 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6712E1A7023 for ; Mon, 3 Nov 2014 11:01:22 -0800 (PST) Received: from [81.187.2.149] (port=47390 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XlMsR-0005Hx-6d; Mon, 03 Nov 2014 19:01:20 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_77BFF1A3-8D77-40E7-9DEA-0734FD17A3D1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <693F1285-01C9-4214-8304-0607E6C07141@gmail.com> Date: Mon, 3 Nov 2014 19:01:14 +0000 Message-Id: <4CBB0F5A-F716-4D6B-9E8B-9704B5A10EF7@csperkins.org> References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> <790697E2-9C87-4B17-A49F-786292CF22AC@csperkins.org> <5457A0A7.7060004@gmail.com> <693F1285-01C9-4214-8304-0607E6C07141@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2UOChyCBg1X-YCPlKsEUtaI24sE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Nov 2014 19:01:25 -0000 --Apple-Mail=_77BFF1A3-8D77-40E7-9DEA-0734FD17A3D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Okay, I=92ll submit an update with this change once submissions reopen. Colin On 3 Nov 2014, at 18:08, Bernard Aboba wrote: > Fine with me too. >=20 >=20 >=20 > On Nov 3, 2014, at 7:35 AM, Sergio Garcia Murillo = wrote: >=20 >> Fine for me, thanxs Colin >>=20 >> BR >> Sergio >> On 03/11/2014 16:25, Colin Perkins wrote: >>> I would have thought the compatibility arguments offered to support = non-BUNDLE media applied here too, but okay. If I change the last = paragraph of rtp-usage, section 6.1 to: >>>=20 >>> Receivers are REQUIRED to implement support for RTP = retransmission >>> packets [RFC4588] sent using SSRC multiplexing, and MAY also = support >>> RTP retransmission packets sent using session multiplexing. = Senders >>> MAY send RTP retransmission packets in response to NACKs if = support >>> for the RTP retransmission payload format has been negotiated, = and if >>> the sender believes it is useful to send a retransmission of the >>> packet(s) referenced in the NACK. Senders do not need to = retransmit >>> every NACKed packet. >>>=20 >>> is this acceptable? >>>=20 >>> Colin >>>=20 >>>=20 >>>=20 >>>=20 >>> On 28 Oct 2014, at 03:41, Bernard Aboba = wrote: >>>> Justin said:=20 >>>>=20 >>>> "I don't think the WG ever explicitly signed up for = session-multiplexing of RTX data" >>>>=20 >>>> [BA] I agree, and in addition would say the same thing with respect = to FEC - one of the fundamental objections to RFC 5109 is that it only = support session-multiplexing, not SSRC multiplexing. =20 >>>>=20 >>>> On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti = wrote: >>>>=20 >>>>=20 >>>> On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins = wrote: >>>> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo = wrote: >>>>> On 27/10/2014 18:10, Colin Perkins wrote: >>>>>> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo = wrote: >>>>>>> On 27/10/2014 17:45, Colin Perkins wrote: >>>>>>>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo = wrote: >>>>>>>>> On 27/10/2014 17:36, Colin Perkins wrote: >>>>>>>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: >>>>>>>>>>> Not sure if it is done on pourpose, but according to the RTP = usage draft, it may seem that full RFC 4588 is mandated at the recevier = side: >>>>>>>>>>>=20 >>>>>>>>>>> Receivers are REQUIRED to implement support for RTP = retransmission >>>>>>>>>>> packets [RFC4588]. >>>>>>>>>>>=20 >>>>>>>>>>> That would include both modes, session and ssrc = multiplexing. Given the extensive usage of bundle and current = implementations, session multiplexing support doesn't make much sense. >>>>>>>>>>>=20 >>>>>>>>>>> Should we drop it, and state that only ssrc-multiplexing = shall be supported at the receiving end? >>>>>>>>>>=20 >>>>>>>>>> I don=92t see any advantage to doing so, given that support = for non-BUNDLE sessions is REQUIRED. You need to implement the = signalling needed for session-multiplexing of retransmission packet = anyway, so disallowing it buys you nothing. >>>>>>>>>=20 >>>>>>>>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE = sessions, what I don't see is how to do session multiplexing with BUNDLE = sessions.=20 >>>>>>>>=20 >>>>>>>> You can=92t do session multiplexing for BUNDLE sessions; by = definition they use SSRC multiplexing. You could do non-BUNDLE = sessions, with = retransmission sent on a separate RTP session though. >>>>>>>>=20 >>>>>>> So, you are saying exactly the same than me. SSRC multiplexing = supports both BUNDLE and NON-BUNDLE. So, why require support for = session multiplexing at = all? As a developer, I don't see why I would have to implement something = that would be rarely used and provide no extra benefit. >>>>>>=20 >>>>>> Non-BUNDLE is session multiplexing. It uses a separate RTP = session for the retransmissions.=20 >>>>> Maybe I am the missing something, if you don't use bundle to send = the audio/video on same rtpsession, you can still send rtx+video on same = session. That's it non-bundle with ssrc-multiplexing. Are we referring = to different things? >>>>=20 >>>> Sure, but that doesn=92t alter the fact that the group decided that = non-BUNDLE media needs to be supported. Sending retransmission on a = separate RTP session is as needed for interoperability with legacy = systems as sending audio and video on separate RTP sessions (and = shouldn=92t be hard to support, since it uses the same mechanisms). >>>>=20 >>>> Non-BUNDLE media needs to be supported, but I don't think the WG = ever explicitly signed up for session-multiplexing of RTX data. Unified = plan is quite clear in its assertion that the primary, RTX, and FEC = flows for a given media stream should all be represented by a single m=3D = line, e.g. SSRC-multiplexed.=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Colin Perkins >>> https://csperkins.org/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_77BFF1A3-8D77-40E7-9DEA-0734FD17A3D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Okay, = I=92ll submit an update with this change once submissions = reopen.
Colin


On 3 = Nov 2014, at 18:08, Bernard Aboba <bernard.aboba@gmail.com> = wrote:

Fine with me = too.



On Nov 3, 2014, at 7:35 AM, Sergio Garcia = Murillo <sergio.garcia.murillo@gmai= l.com> wrote:

=20 =20 =20
Fine for me, thanxs Colin

BR
Sergio
On 03/11/2014 16:25, Colin Perkins wrote:
I would have thought the compatibility arguments offered to support non-BUNDLE media applied here too, but okay. If I change the last paragraph of rtp-usage, section 6.1 to:

   Receivers are REQUIRED = to implement support for RTP retransmission
   packets [RFC4588] sent = using SSRC multiplexing, and MAY also support
   RTP retransmission = packets sent using session multiplexing.  Senders
   MAY send RTP = retransmission packets in response to NACKs if support
   for the RTP = retransmission payload format has been negotiated, and if
   the sender believes it = is useful to send a retransmission of the
   packet(s) referenced in = the NACK.  Senders do not need to retransmit
   every NACKed = packet.

is this acceptable?

Colin




On 28 Oct 2014, at 03:41, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Justin said: 

"I don't think the WG ever explicitly signed up for session-multiplexing of RTX data"

[BA] I agree, and in addition would say the same thing with respect to FEC - one of the fundamental objections to RFC 5109 is that it only support session-multiplexing, not SSRC multiplexing.  

On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti <juberti@google.com> wrote:


On Mon, Oct 27, 2014 = at 12:16 PM, Colin Perkins <csp@csperkins.org> wrote:
On 27 Oct 2014, at 17:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 18:10, Colin Perkins wrote:
On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:45, Colin Perkins = wrote:
On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 27/10/2014 17:36, Colin Perkins = wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP =
retransmission
    packets [RFC4588].
=
That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current = implementations, session multiplexing support doesn't make much = sense.

Should we drop it, and state that only = ssrc-multiplexing shall be supported at the receiving end?

I don=92t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for = session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=92t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra = benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions. =
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different things?
Sure, but that doesn=92t alter the fact that the group decided that non-BUNDLE media needs to be supported. Sending retransmission on a separate RTP session is as needed for interoperability with legacy systems as sending audio and video on separate RTP sessions (and shouldn=92t be hard to support, since it uses the same mechanisms).

=
Non-BUNDLE media needs to be supported, but I don't think the WG ever explicitly signed up for session-multiplexing of RTX data. Unified plan is quite clear in its assertion that the primary, RTX, and FEC flows for a given media stream should all be represented by a single m=3D = line, e.g. SSRC-multiplexed. 

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





-- 
Colin Perkins






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

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



-- 
Colin Perkins

<= /div>


= --Apple-Mail=_77BFF1A3-8D77-40E7-9DEA-0734FD17A3D1-- From nobody Mon Nov 3 15:32:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E85C1A888B for ; Mon, 3 Nov 2014 15:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e50Niwcfkfew for ; Mon, 3 Nov 2014 15:32:39 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.35.26]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3134F1A8887 for ; Mon, 3 Nov 2014 15:32:39 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 5CC7DC8D4A3CA; Mon, 3 Nov 2014 17:32:38 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 458C6C8D4A37C for ; Mon, 3 Nov 2014 17:32:38 -0600 (CST) Received: from [173.73.121.234] (port=60022 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XlR6z-0002C2-Nk for rtcweb@ietf.org; Mon, 03 Nov 2014 17:32:37 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Date: Mon, 3 Nov 2014 18:32:37 -0500 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XlR6z-0002C2-Nk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:60022 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nkoBvNHZQsgJTO39RSr4R47CWTw Subject: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 03 Nov 2014 23:32:40 -0000 All, One of the remaining major technical decisions for the RTCweb WG is = which codec(s) should be MTI. The issue has been on hold for over 6 = months and the original plan to was the re-attempt determining consensus = at the IETF 91. To make the best use of the WG=92s face-to-face time at = IETF 91, we want to give the WG ample time to digest/discuss the = questions the chairs intend to ask the WG concerning the MTI codec (or = codecs). We want to know before the meeting whether to ask the = questions and then what questions to ask - in other words we want to = inform the WG of the questions before the WG session so as to not waste = time debating what questions should be asked. Without further ado, these are the proposed questions: Question #0 (hum) Do you want to discuss this issue at this meeting? Question #1 (stand up) Please stand (or signal in the jabber chat) if you will be part of that = consensus process for this question. If you're here to read email or = watch the show, we want to know that your sitting throughout this isn't = expressing opinions for the consensus process. To many this might seem like a silly question, but the chairs believe the problem is well enough understood by those actively involved WG participants so we would like to confirm this understanding. The chairs will also use to the determine the informed pool of WG participants. =20 Question #2 (hum) Do you believe we need an MTI codec to avoid negotiation failures? Previous attempts at determining the MTI did not yield a result but did confirm that there is a desire for an MTI to avoid negotiation failures. Recently, some on the mailing list have expressed an interest in postponing this discussion until after IETF 91. The purpose of this question is to reconfirm the original consensus. Question #3 (open mic) Are there any codecs that were not included in the previous consensus = calls that warrant consideration? If yes, which one and why. The assumption is that the viable codecs are a) VP8, b) H.264, or c) VP8 and H.264. This is based on the extensive poll results from the last consensus calls. But time has passed so we need to entertain the ever so slight possibility that another codec has miraculously appeared. Remember, we want to ensure we=92re going to get maximum interoperability. Question #4 (open mic) Are there any new or unaddressed technical issues that will not allow us = to narrow the field to VP8 and H.264? We do not want to revisit previous discussions; we only want new or unaddressed technical issues and will throttle the discussion accordingly. We=92ll rely on WG participants and our former RAI AD (Mr. Sparks) for help in this area. We believe the technical discussion will fall into two buckets: - New or unresolved technical points. - Licensing. WRT licensing, the IETF tries not discuss whether IPR is valid, but an IPR issue that can be used as input to the decision making process is if enough people say they can=92t/won=92t implement because of the IPR. Question #5 (hum) With respect to the MTI codec: - Who can live with a requirement that WebRTC User Agents MUST support both VP8 and H.264 and WebRTC devices MUST support either VP8 or H.264? - Who can live with a requirement that all endpoints MUST support = VP8? - Who can live with a requirement that all endpoints MUST support = H.264? Thanks for your time, t/c/s= From nobody Mon Nov 3 16:08:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D70C1A1AAB for ; Mon, 3 Nov 2014 16:08:37 -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 vDFtanNwJ5ch for ; Mon, 3 Nov 2014 16:08:34 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999FE1A1A9A for ; Mon, 3 Nov 2014 16:08:33 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id y13so12532334pdi.34 for ; Mon, 03 Nov 2014 16:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=ghH2ytQ0oWKyMEK/KSrZy6Exuh/NBeSYynXcNBj0g84=; b=S7ByjdQ6SwBGyYf6JlZ99lWliCc/nf8G8y2iHzPDUNkmmaHl0P7NpFdh1U1YoSbPu4 5PjYZgyqIM2lNCK6SjsgkqwQVPxDXdOA9rxoSHY811vZTvmOZ+5i8GD9mLK1J+ZlXTNz V654q+a8kdCM8QiOa3IsUxvZkSSjwqZB9E30IgMZrs4lYSKnzD4NInmQT6cLL6GCv3dz giSQ0i73162+5bCKaWVyJ58KH3GsmAX1xOt7gq84SX5ZWfJWahfWDBoUez/KLL3Mr7iC n2969hYkKvKB4U5f+65GkrGQVDoZPi3hSUI6wtBYqKAbi7oBPG8ymThRwwFFojQHG2t0 4VNQ== X-Received: by 10.70.4.164 with SMTP id l4mr5020404pdl.137.1415059713146; Mon, 03 Nov 2014 16:08:33 -0800 (PST) Received: from [10.248.157.153] (mobile-166-171-121-202.mycingular.net. [166.171.121.202]) by mx.google.com with ESMTPSA id gy5sm18128325pbc.68.2014.11.03.16.08.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 16:08:31 -0800 (PST) References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Mime-Version: 1.0 (1.0) In-Reply-To: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <494EFF62-0914-44B3-9073-F49858293347@gmail.com> X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Mon, 3 Nov 2014 16:08:26 -0800 To: Sean Turner Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WeOIPqpNserAHRs46FGZQeI1JJY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 00:08:37 -0000 The questions below do not make it clear whether we are revisiting the MTI v= ideo codec issue or whether in addition the audio codec issue (on which we r= eached consensus) is also being reconsidered. Please clarify. > On Nov 3, 2014, at 3:32 PM, Sean Turner wrote: >=20 > All, >=20 > One of the remaining major technical decisions for the RTCweb WG is which c= odec(s) should be MTI. The issue has been on hold for over 6 months and th= e original plan to was the re-attempt determining consensus at the IETF 91. = To make the best use of the WG=E2=80=99s face-to-face time at IETF 91, we w= ant to give the WG ample time to digest/discuss the questions the chairs int= end to ask the WG concerning the MTI codec (or codecs). We want to know bef= ore the meeting whether to ask the questions and then what questions to ask -= in other words we want to inform the WG of the questions before the WG sess= ion so as to not waste time debating what questions should be asked. >=20 > Without further ado, these are the proposed questions: >=20 > Question #0 (hum) >=20 > Do you want to discuss this issue at this meeting? >=20 > Question #1 (stand up) >=20 > Please stand (or signal in the jabber chat) if you will be part of that co= nsensus process for this question. If you're here to read email or watch the= show, we want to know that your sitting throughout this isn't expressing op= inions for the consensus process. >=20 > To many this might seem like a silly question, > but the chairs believe the problem is well enough > understood by those actively involved WG > participants so we would like to confirm this > understanding. The chairs will also use to the > determine the informed pool of WG participants. =20 >=20 > Question #2 (hum) >=20 > Do you believe we need an MTI codec to avoid negotiation failures? >=20 > Previous attempts at determining the MTI did not > yield a result but did confirm that there is a desire > for an MTI to avoid negotiation failures. Recently, > some on the mailing list have expressed an interest > in postponing this discussion until after IETF 91. The > purpose of this question is to reconfirm the original > consensus. >=20 > Question #3 (open mic) >=20 > Are there any codecs that were not included in the previous consensus call= s that warrant consideration? If yes, which one and why. >=20 > The assumption is that the viable codecs are a) VP8, > b) H.264, or c) VP8 and H.264. This is based on the > extensive poll results from the last consensus calls. > But time has passed so we need to entertain the ever > so slight possibility that another codec has miraculously > appeared. Remember, we want to ensure we=E2=80=99re going > to get maximum interoperability. >=20 > Question #4 (open mic) >=20 > Are there any new or unaddressed technical issues that will not allow us t= o narrow the field to VP8 and H.264? >=20 > We do not want to revisit previous discussions; we only > want new or unaddressed technical issues and will throttle > the discussion accordingly. We=E2=80=99ll rely on WG participants > and our former RAI AD (Mr. Sparks) for help in this area. >=20 > We believe the technical discussion will fall into two > buckets: > - New or unresolved technical points. > - Licensing. WRT licensing, the IETF tries not discuss > whether IPR is valid, but an IPR issue that can be used > as input to the decision making process is if enough > people say they can=E2=80=99t/won=E2=80=99t implement because of th= e IPR. >=20 > Question #5 (hum) >=20 > With respect to the MTI codec: > - Who can live with a requirement that WebRTC User Agents > MUST support both VP8 and H.264 and WebRTC devices > MUST support either VP8 or H.264? > - Who can live with a requirement that all endpoints MUST support VP8? > - Who can live with a requirement that all endpoints MUST support H.264= ? >=20 > Thanks for your time, > t/c/s > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 3 16:27:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF221A1B19 for ; Mon, 3 Nov 2014 16:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gphvEuKY4I2 for ; Mon, 3 Nov 2014 16:27:09 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4E51A1B0E for ; Mon, 3 Nov 2014 16:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=727; q=dns/txt; s=iport; t=1415060829; x=1416270429; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4/AbUOvEF+R5Au1Fm0ocCKMoRqZQCaA7vv6E6DchR+o=; b=S6sVTfCfmOAi6AsSYnHroaGMW3p56+HxBHmW+Z6Q16RCPVKUGfaWoA2H emett/WhdRtnvCk8IIh/DyKunD+u3A6HMd4ERHjZXjtXadCJr4644P70z iZsACtwbcbtG+RYealWLN6U7f7oV5V+Fsr/ptxVxM6G4o+CIO/ULzQyqI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAKocWFStJV2c/2dsb2JhbABcgmsjgSwE1W0CgSEWAQEBAQF9hAMBAQMBOj8FCwIBCDYQIRElAgQOBYgsAwkJAcR2DYY5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF45WgVgRAR0zB4MtgR4BBJIaiVaCEYExg02KY4Zvg3hsgQ85gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,310,1413244800"; d="scan'208";a="368993438" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2014 00:27:09 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sA40R8cO027693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 00:27:09 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 18:27:08 -0600 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) Thread-Index: AQHP98YReKuvFqoakkS2INdsT2IHVg== Date: Tue, 4 Nov 2014 00:27:08 +0000 Message-ID: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <494EFF62-0914-44B3-9073-F49858293347@gmail.com> In-Reply-To: <494EFF62-0914-44B3-9073-F49858293347@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ffcgfc0FtQ3viJlNzvHIhn7R7HI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 00:27:11 -0000 On Nov 3, 2014, at 5:08 PM, Bernard Aboba wrote: > The questions below do not make it clear whether we are revisiting the MT= I video codec issue or whether in addition the audio codec issue (on which = we reached consensus) is also being reconsidered. Please clarify. >=20 Bernard, I think I can safely say the chairs were only thinking about the v= ideo codec when this was written and that should have been clear on that.=20 That said, there was consensus on 711 and opus being MTI but I think we wou= ld need to check carefully the status of if there was consensus that no oth= er audio codecs would be be MTI. But this email was really meant to be abou= t the video codecs.=20 From nobody Mon Nov 3 16:31:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6BE1A1B18 for ; Mon, 3 Nov 2014 16:31:17 -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 naqnUBKGHhDX for ; Mon, 3 Nov 2014 16:31:15 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 548181A1B06 for ; Mon, 3 Nov 2014 16:31:15 -0800 (PST) Received: from [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418] (unknown [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id F0DD34A267D for ; Mon, 3 Nov 2014 16:31:14 -0800 (PST) Message-ID: <54581E56.10407@matthew.at> Date: Mon, 03 Nov 2014 16:31:18 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> In-Reply-To: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KStwUo9sg514AR3IJ4hklZmy-oA Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 00:31:17 -0000 The below has been discussed to death on the list *and* nearly identical questions were presented at a previous meeting. I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then? As far as I can tell, nothing. Matthew Kaufman ps. Doing this with hums at a meeting just encourages filling the room with people who aren't participating in the process but whose employers have asked them to stuff the room to increase the hum volume. Those people will all stand up for question #1, then leave immediately after the hums are completed. Just like last time. On 11/3/2014 3:32 PM, Sean Turner wrote: > All, > > One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be MTI. The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91. To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs). We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked. > > Without further ado, these are the proposed questions: > > Question #0 (hum) > > Do you want to discuss this issue at this meeting? > > Question #1 (stand up) > > Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process. > > To many this might seem like a silly question, > but the chairs believe the problem is well enough > understood by those actively involved WG > participants so we would like to confirm this > understanding. The chairs will also use to the > determine the informed pool of WG participants. > > Question #2 (hum) > > Do you believe we need an MTI codec to avoid negotiation failures? > > Previous attempts at determining the MTI did not > yield a result but did confirm that there is a desire > for an MTI to avoid negotiation failures. Recently, > some on the mailing list have expressed an interest > in postponing this discussion until after IETF 91. The > purpose of this question is to reconfirm the original > consensus. > > Question #3 (open mic) > > Are there any codecs that were not included in the previous consensus calls that warrant consideration? If yes, which one and why. > > The assumption is that the viable codecs are a) VP8, > b) H.264, or c) VP8 and H.264. This is based on the > extensive poll results from the last consensus calls. > But time has passed so we need to entertain the ever > so slight possibility that another codec has miraculously > appeared. Remember, we want to ensure we’re going > to get maximum interoperability. > > Question #4 (open mic) > > Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264? > > We do not want to revisit previous discussions; we only > want new or unaddressed technical issues and will throttle > the discussion accordingly. We’ll rely on WG participants > and our former RAI AD (Mr. Sparks) for help in this area. > > We believe the technical discussion will fall into two > buckets: > - New or unresolved technical points. > - Licensing. WRT licensing, the IETF tries not discuss > whether IPR is valid, but an IPR issue that can be used > as input to the decision making process is if enough > people say they can’t/won’t implement because of the IPR. > > Question #5 (hum) > > With respect to the MTI codec: > - Who can live with a requirement that WebRTC User Agents > MUST support both VP8 and H.264 and WebRTC devices > MUST support either VP8 or H.264? > - Who can live with a requirement that all endpoints MUST support VP8? > - Who can live with a requirement that all endpoints MUST support H.264? > > Thanks for your time, > t/c/s > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 3 17:02:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743611A1B35 for ; Mon, 3 Nov 2014 17:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8HGlwfhS-xL for ; Mon, 3 Nov 2014 17:02:24 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 972B51A1B34 for ; Mon, 3 Nov 2014 17:02:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C19397C509F for ; Tue, 4 Nov 2014 02:02:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkK5OGFmhUPX for ; Tue, 4 Nov 2014 02:02:20 +0100 (CET) Received: from [IPv6:2620:0:1000:167d:6812:cbc2:7be6:f60] (unknown [IPv6:2620:0:1000:167d:6812:cbc2:7be6:f60]) by mork.alvestrand.no (Postfix) with ESMTPSA id D6F407C5099 for ; Tue, 4 Nov 2014 02:02:19 +0100 (CET) Message-ID: <54582599.6070806@alvestrand.no> Date: Mon, 03 Nov 2014 17:02:17 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> In-Reply-To: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Content-Type: multipart/alternative; boundary="------------090005020108050000000507" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RaB7meqk9xfHTRXIdoyCA_tNyp8 Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 01:02:29 -0000 This is a multi-part message in MIME format. --------------090005020108050000000507 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hm. I don’t think there’s much value in revisiting the “one codec” alternatives. We tried that, and know that we found no consensus. Nobody’s changed their minds. It would be very sad if we give up on interoperability for WebRTC devices. Accepting “either” means that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the “device” category is to allow fully compliant devices that don’t need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We’ve had that discussion before. Of course, WebRTC-compatible devices (as currently defined) can do whatever they want. But still, it seems that there’s a chance that discussing this again is worth it. We might find an agreement this time. Harald On 11/03/2014 03:32 PM, Sean Turner wrote: > All, > > One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be MTI. The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91. To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs). We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked. > > Without further ado, these are the proposed questions: > > Question #0 (hum) > > Do you want to discuss this issue at this meeting? > > Question #1 (stand up) > > Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process. > > To many this might seem like a silly question, > but the chairs believe the problem is well enough > understood by those actively involved WG > participants so we would like to confirm this > understanding. The chairs will also use to the > determine the informed pool of WG participants. > > Question #2 (hum) > > Do you believe we need an MTI codec to avoid negotiation failures? > > Previous attempts at determining the MTI did not > yield a result but did confirm that there is a desire > for an MTI to avoid negotiation failures. Recently, > some on the mailing list have expressed an interest > in postponing this discussion until after IETF 91. The > purpose of this question is to reconfirm the original > consensus. > > Question #3 (open mic) > > Are there any codecs that were not included in the previous consensus calls that warrant consideration? If yes, which one and why. > > The assumption is that the viable codecs are a) VP8, > b) H.264, or c) VP8 and H.264. This is based on the > extensive poll results from the last consensus calls. > But time has passed so we need to entertain the ever > so slight possibility that another codec has miraculously > appeared. Remember, we want to ensure we’re going > to get maximum interoperability. > > Question #4 (open mic) > > Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264? > > We do not want to revisit previous discussions; we only > want new or unaddressed technical issues and will throttle > the discussion accordingly. We’ll rely on WG participants > and our former RAI AD (Mr. Sparks) for help in this area. > > We believe the technical discussion will fall into two > buckets: > - New or unresolved technical points. > - Licensing. WRT licensing, the IETF tries not discuss > whether IPR is valid, but an IPR issue that can be used > as input to the decision making process is if enough > people say they can’t/won’t implement because of the IPR. > > Question #5 (hum) > > With respect to the MTI codec: > - Who can live with a requirement that WebRTC User Agents > MUST support both VP8 and H.264 and WebRTC devices > MUST support either VP8 or H.264? > - Who can live with a requirement that all endpoints MUST support VP8? > - Who can live with a requirement that all endpoints MUST support H.264? > > Thanks for your time, > t/c/s > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------090005020108050000000507 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hm.

I don’t think there’s much value in revisiting the “one codec” alternatives. We tried that, and know that we found no consensus. Nobody’s changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. Accepting “either” means that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the “device” category is to allow fully compliant devices that don’t need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We’ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there’s a chance that discussing this again is worth it. We might find an agreement this time.

Harald



On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be  MTI.  The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91.  To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs).  We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants.  

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we’re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We’ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can’t/won’t implement because of the IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.
--------------090005020108050000000507-- From nobody Mon Nov 3 17:13:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757C21A1AF4 for ; Mon, 3 Nov 2014 17:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZAMOPTwaWlW for ; Mon, 3 Nov 2014 17:13:26 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244321A1B3B for ; Mon, 3 Nov 2014 17:13:24 -0800 (PST) Received: from mail-pa0-f44.google.com ([209.85.220.44]:58259) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XlSgU-000704-42 for rtcweb@ietf.org; Mon, 03 Nov 2014 20:13:23 -0500 Received: by mail-pa0-f44.google.com with SMTP id bj1so13393517pad.3 for ; Mon, 03 Nov 2014 17:13:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.70.95.73 with SMTP id di9mr46146122pdb.50.1415063601549; Mon, 03 Nov 2014 17:13:21 -0800 (PST) Received: by 10.70.23.36 with HTTP; Mon, 3 Nov 2014 17:13:21 -0800 (PST) In-Reply-To: <54582599.6070806@alvestrand.no> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> Date: Mon, 3 Nov 2014 20:13:21 -0500 Message-ID: From: Jonathan Rosenberg To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c2ad724e1aab0506fe2bc0 X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/m34alkt2JknUuTiXRcRCZk7b_qM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 01:13:29 -0000 --001a11c2ad724e1aab0506fe2bc0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Matthew, You wrote: "I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then? As far as I can tell, nothing.: Actually several things have substantively changed since then. The list includes but is not limited to: * Cisco shipped its H264 open source and binary module * Firefox is using the Cisco binary module and as such Firefox now supports both H264 and VP8 * IOS8 has shipped with API support for H264 (you may recall that lack of a solution for H264 on IOS was an objection many had regarding the Cisco h264 binary module solution; this is now addressed) * there has been progress in the ongoing legal proceedings around VP8 * there are new IPR statements regarding VP8 in ongoing standards processes I think this is far beyond "nothing". And given the importance of this topic to progress on adoption of webRTC, it warrants discussion at the mic. -Jonathan R. On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand wrote: > Hm. > > I don=E2=80=99t think there=E2=80=99s much value in revisiting the =E2=80= =9Cone codec=E2=80=9D > alternatives. We tried that, and know that we found no consensus. Nobody= =E2=80=99s > changed their minds. > > It would be very sad if we give up on interoperability for WebRTC devices= . > Accepting =E2=80=9Ceither=E2=80=9D means that there will be 2 groups of t= hem, and they need > a gateway to talk to each other, even when they can all talk to all > compatible browsers. Having an MTI would be better - but one purpose of t= he > =E2=80=9Cdevice=E2=80=9D category is to allow fully compliant devices tha= t don=E2=80=99t need the > kind of corporate backing a browser needs - which means that licensed > codecs are an issue. We=E2=80=99ve had that discussion before. > > Of course, WebRTC-compatible devices (as currently defined) can do > whatever they want. > > But still, it seems that there=E2=80=99s a chance that discussing this ag= ain is > worth it. We might find an agreement this time. > > Harald > > > > > On 11/03/2014 03:32 PM, Sean Turner wrote: > > All, > > One of the remaining major technical decisions for the RTCweb WG is which= codec(s) should be MTI. The issue has been on hold for over 6 months and= the original plan to was the re-attempt determining consensus at the IETF = 91. To make the best use of the WG=E2=80=99s face-to-face time at IETF 91,= we want to give the WG ample time to digest/discuss the questions the chai= rs intend to ask the WG concerning the MTI codec (or codecs). We want to k= now before the meeting whether to ask the questions and then what questions= to ask - in other words we want to inform the WG of the questions before t= he WG session so as to not waste time debating what questions should be ask= ed. > > Without further ado, these are the proposed questions: > > Question #0 (hum) > > Do you want to discuss this issue at this meeting? > > Question #1 (stand up) > > Please stand (or signal in the jabber chat) if you will be part of that c= onsensus process for this question. If you're here to read email or watch t= he show, we want to know that your sitting throughout this isn't expressing= opinions for the consensus process. > > To many this might seem like a silly question, > but the chairs believe the problem is well enough > understood by those actively involved WG > participants so we would like to confirm this > understanding. The chairs will also use to the > determine the informed pool of WG participants. > > Question #2 (hum) > > Do you believe we need an MTI codec to avoid negotiation failures? > > Previous attempts at determining the MTI did not > yield a result but did confirm that there is a desire > for an MTI to avoid negotiation failures. Recently, > some on the mailing list have expressed an interest > in postponing this discussion until after IETF 91. The > purpose of this question is to reconfirm the original > consensus. > > Question #3 (open mic) > > Are there any codecs that were not included in the previous consensus cal= ls that warrant consideration? If yes, which one and why. > > The assumption is that the viable codecs are a) VP8, > b) H.264, or c) VP8 and H.264. This is based on the > extensive poll results from the last consensus calls. > But time has passed so we need to entertain the ever > so slight possibility that another codec has miraculously > appeared. Remember, we want to ensure we=E2=80=99re going > to get maximum interoperability. > > Question #4 (open mic) > > Are there any new or unaddressed technical issues that will not allow us = to narrow the field to VP8 and H.264? > > We do not want to revisit previous discussions; we only > want new or unaddressed technical issues and will throttle > the discussion accordingly. We=E2=80=99ll rely on WG participants > and our former RAI AD (Mr. Sparks) for help in this area. > > We believe the technical discussion will fall into two > buckets: > - New or unresolved technical points. > - Licensing. WRT licensing, the IETF tries not discuss > whether IPR is valid, but an IPR issue that can be used > as input to the decision making process is if enough > people say they can=E2=80=99t/won=E2=80=99t implement because of = the IPR. > > Question #5 (hum) > > With respect to the MTI codec: > - Who can live with a requirement that WebRTC User Agents > MUST support both VP8 and H.264 and WebRTC devices > MUST support either VP8 or H.264? > - Who can live with a requirement that all endpoints MUST support VP8= ? > - Who can live with a requirement that all endpoints MUST support H.2= 64? > > Thanks for your time, > t/c/s > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --001a11c2ad724e1aab0506fe2bc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Matthew,

You wrote:
"I'm going to a= sk what I asked when I first saw this on the agenda: What has substantively= changed since then?

As far as I can tell, = nothing.:

Actually several things have substantively changed s= ince then. The list includes but is not limited to:

* Cisco shippe= d its H264 open source and binary module
* Firefox is using the Cisco bin= ary module and as such Firefox now supports both H264 and VP8
<= div>* IOS8 has = shipped with API support for H264 (you may recall that lack of a solution f= or H264 on IOS was an objection many had regarding the Cisco h264 binary mo= dule solution; this is now addressed)
* there has been progress in the on= going legal proceedings around VP8
* there are new IPR statements regardi= ng VP8 in ongoing standards processes


I think this is far beyond "nothing"= . And given the importance of this topic to progress on adoption of webRTC,= it warrants discussion at the mic.

-Jonathan= R.


On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <harald@a= lvestrand.no> wrote:
=20 =20 =20
=20 =20 Hm.

I don=E2=80=99t think there=E2=80=99s much value in revisiting the = =E2=80=9Cone codec=E2=80=9D alternatives. We tried that, and know that we found no consensus. Nobody=E2=80=99s changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. Accepting =E2=80=9Ceither=E2=80=9D means that there will be = 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the =E2=80=9Cdevice=E2=80=9D category = is to allow fully compliant devices that don=E2=80=99t need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We=E2=80=99ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there=E2=80=99s a chance that discussing thi= s again is worth it. We might find an agreement this time.

Harald




On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which c=
odec(s) should be  MTI.  The issue has been on hold for over 6 months and t=
he original plan to was the re-attempt determining consensus at the IETF 91=
.  To make the best use of the WG=E2=80=99s face-to-face time at IETF 91, w=
e want to give the WG ample time to digest/discuss the questions the chairs=
 intend to ask the WG concerning the MTI codec (or codecs).  We want to kno=
w before the meeting whether to ask the questions and then what questions t=
o ask - in other words we want to inform the WG of the questions before the=
 WG session so as to not waste time debating what questions should be asked=
.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that con=
sensus process for this question. If you're here to read email or watch=
 the show, we want to know that your sitting throughout this isn't expr=
essing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants. =20

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls=
 that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we=E2=80=99re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to=
 narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We=E2=80=99ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can=E2=80=99t/won=E2=80=99t implement because of th=
e IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264=
?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Surveillance is pervasive. Go Dark.

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




--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net<= br>http://www.jdrosen.= net
--001a11c2ad724e1aab0506fe2bc0-- From nobody Mon Nov 3 19:15:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E611A8887 for ; Mon, 3 Nov 2014 19:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZupwjLcl4enQ for ; Mon, 3 Nov 2014 19:15:23 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 123881A887F for ; Mon, 3 Nov 2014 19:15:23 -0800 (PST) Received: from dhcp-231.braemoor.net (unknown [IPv6:2001:470:826a:d0:28:26fd:dbc7:a330]) (Authenticated sender: matthew@matthew.at) by mail.eeph.com (Postfix) with ESMTPSA id C9ACA4A26BD for ; Mon, 3 Nov 2014 19:15:22 -0800 (PST) Message-ID: <545844CC.5010000@matthew.at> Date: Mon, 03 Nov 2014 19:15:24 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090501070800060000020800" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pLnq9_6Vk4388e-xvqWqy6j9hpE Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 03:15:29 -0000 This is a multi-part message in MIME format. --------------090501070800060000020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A "substantive change" would be *any* of the parties who participate in these discussions having a different position than before. Yes, Cisco, who already supported H.264 and had announced an intention to ship an open source and binary module, shipped H.264. And Firefox, reluctant supporter of H.264 when available but preferring VP8 and some future even more free codec that isn't yet shipped, is reluctantly supporting H.264 when available. And iOS 8 has H.264, but of course Apple already had access to that H.264 if they were to put WEBRTC into their browser... Etc. Where's the "Google has decided to pull their support for VP8 and fully back H.264 for real-time communications on the web" announcement? Or the "Microsoft open-sources Internet Explorer, adds native VP8 to Windows" announcement? Or the "MPEG-LA drops all fees for H.264 encoding and decoding" announcement? Or really *anything* that substantially changes things from where we were six months ago? I don't get the desire to spend time on this topic... and I especially don't understand the call to pack as many people into a room as possible to conduct a hum, when the outcome will need to be discussed and confirmed on the list anyway. Matthew Kaufman On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote: > Matthew, > > You wrote: > "I'm going to ask what I asked when I first saw this on the agenda: > What has substantively changed since then? > > As far as I can tell, nothing.: > > Actually several things have substantively changed since then. The > list includes but is not limited to: > > * Cisco shipped its H264 open source and binary module > * Firefox is using the Cisco binary module and as such Firefox now > supports both H264 and VP8 > * IOS8 has shipped with API support for H264 (you may recall that lack > of a solution for H264 on IOS was an objection many had regarding the > Cisco h264 binary module solution; this is now addressed) > * there has been progress in the ongoing legal proceedings around VP8 > * there are new IPR statements regarding VP8 in ongoing standards > processes > > > I think this is far beyond "nothing". And given the importance of this > topic to progress on adoption of webRTC, it warrants discussion at the > mic. > > -Jonathan R. > > > On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand > > wrote: > > Hm. > > I don't think there's much value in revisiting the "one codec" > alternatives. We tried that, and know that we found no consensus. > Nobody's changed their minds. > > It would be very sad if we give up on interoperability for WebRTC > devices. Accepting "either" means that there will be 2 groups of > them, and they need a gateway to talk to each other, even when > they can all talk to all compatible browsers. Having an MTI would > be better - but one purpose of the "device" category is to allow > fully compliant devices that don't need the kind of corporate > backing a browser needs - which means that licensed codecs are an > issue. We've had that discussion before. > > Of course, WebRTC-compatible devices (as currently defined) can do > whatever they want. > > But still, it seems that there's a chance that discussing this > again is worth it. We might find an agreement this time. > > Harald > > > > > On 11/03/2014 03:32 PM, Sean Turner wrote: >> All, >> >> One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be MTI. The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91. To make the best use of the WG's face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs). We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked. >> >> Without further ado, these are the proposed questions: >> >> Question #0 (hum) >> >> Do you want to discuss this issue at this meeting? >> >> Question #1 (stand up) >> >> Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process. >> >> To many this might seem like a silly question, >> but the chairs believe the problem is well enough >> understood by those actively involved WG >> participants so we would like to confirm this >> understanding. The chairs will also use to the >> determine the informed pool of WG participants. >> >> Question #2 (hum) >> >> Do you believe we need an MTI codec to avoid negotiation failures? >> >> Previous attempts at determining the MTI did not >> yield a result but did confirm that there is a desire >> for an MTI to avoid negotiation failures. Recently, >> some on the mailing list have expressed an interest >> in postponing this discussion until after IETF 91. The >> purpose of this question is to reconfirm the original >> consensus. >> >> Question #3 (open mic) >> >> Are there any codecs that were not included in the previous consensus calls that warrant consideration? If yes, which one and why. >> >> The assumption is that the viable codecs are a) VP8, >> b) H.264, or c) VP8 and H.264. This is based on the >> extensive poll results from the last consensus calls. >> But time has passed so we need to entertain the ever >> so slight possibility that another codec has miraculously >> appeared. Remember, we want to ensure we're going >> to get maximum interoperability. >> >> Question #4 (open mic) >> >> Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264? >> >> We do not want to revisit previous discussions; we only >> want new or unaddressed technical issues and will throttle >> the discussion accordingly. We'll rely on WG participants >> and our former RAI AD (Mr. Sparks) for help in this area. >> >> We believe the technical discussion will fall into two >> buckets: >> - New or unresolved technical points. >> - Licensing. WRT licensing, the IETF tries not discuss >> whether IPR is valid, but an IPR issue that can be used >> as input to the decision making process is if enough >> people say they can't/won't implement because of the IPR. >> >> Question #5 (hum) >> >> With respect to the MTI codec: >> - Who can live with a requirement that WebRTC User Agents >> MUST support both VP8 and H.264 and WebRTC devices >> MUST support either VP8 or H.264? >> - Who can live with a requirement that all endpoints MUST support VP8? >> - Who can live with a requirement that all endpoints MUST support H.264? >> >> Thanks for your time, >> t/c/s >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090501070800060000020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A "substantive change" would be *any* of the parties who participate in these discussions having a different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention to ship an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring VP8 and some future even more free codec that isn't yet shipped, is reluctantly supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that H.264 if they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their support for VP8 and fully back H.264 for real-time communications on the web" announcement? Or the "Microsoft open-sources Internet Explorer, adds native VP8 to Windows" announcement? Or the "MPEG-LA drops all fees for H.264 encoding and decoding" announcement? Or really *anything* that substantially changes things from where we were six months ago?

I don't get the desire to spend time on this topic... and I especially don't understand the call to pack as many people into a room as possible to conduct a hum, when the outcome will need to be discussed and confirmed on the list anyway.

Matthew Kaufman

On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
Matthew,

You wrote:
"I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then?

As far as I can tell, nothing.:

Actually several things have substantively changed since then. The list includes but is not limited to:

* Cisco shipped its H264 open source and binary module
* Firefox is using the Cisco binary module and as such Firefox now supports both H264 and VP8
* IOS8 has shipped with API support for H264 (you may recall that lack of a solution for H264 on IOS was an objection many had regarding the Cisco h264 binary module solution; this is now addressed)
* there has been progress in the ongoing legal proceedings around VP8
* there are new IPR statements regarding VP8 in ongoing standards processes


I think this is far beyond "nothing". And given the importance of this topic to progress on adoption of webRTC, it warrants discussion at the mic.

-Jonathan R.


On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
Hm.

I don’t think there’s much value in revisiting the “one codec” alternatives. We tried that, and know that we found no consensus. Nobody’s changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. Accepting “either” means that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the “device” category is to allow fully compliant devices that don’t need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We’ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there’s a chance that discussing this again is worth it. We might find an agreement this time.

Harald




On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be  MTI.  The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91.  To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs).  We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants.  

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we’re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We’ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can’t/won’t implement because of the IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.

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




-- 


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

--------------090501070800060000020800-- From nobody Mon Nov 3 21:44:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84A01A88B9 for ; Mon, 3 Nov 2014 21:44:16 -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 Z1dY4B6CWq9d for ; Mon, 3 Nov 2014 21:44:13 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FABD1A88B8 for ; Mon, 3 Nov 2014 21:44:13 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id x69so9829825oia.35 for ; Mon, 03 Nov 2014 21:44:12 -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=SNKBh0ZgfrT/x/QiQd2bh2DJEYXGoHq7YOhLU7AbYG4=; b=HBUajdocllESpUxfdKTAupOTsPnpVzLfw6hh3B+P50Nqz22MTZGYotpGlc7eOqVXDf xYVNHJmhiggDtPpBU/gaNO3Bz1+rU4sX3IfYUQGtq3uiM6pkFnN7E6ffLQz8zxFyJvPx Kfdn6SWEhnxreSrvq9BVrQV01iAuxm+gPzP3O0KDptR1gpBdwMz3IT/TYcP+K+dLvjFk tJjXH8Bh+fN9qStx1IIWzc9OmHDyMtTiupVp9eCiBkybPMDSFAvT5ygf9x8f1nK4svsg vlcEquPsJgUOvmKFR00qNTj6oEk3QMDfoDmQqTNcTBvQYb1CKBCDLN6LQysjI2ECmvw5 U5jQ== MIME-Version: 1.0 X-Received: by 10.60.161.115 with SMTP id xr19mr34237473oeb.8.1415079852618; Mon, 03 Nov 2014 21:44:12 -0800 (PST) Received: by 10.202.209.8 with HTTP; Mon, 3 Nov 2014 21:44:12 -0800 (PST) In-Reply-To: <545844CC.5010000@matthew.at> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> <545844CC.5010000@matthew.at> Date: Tue, 4 Nov 2014 13:44:12 +0800 Message-ID: From: Alexandre GOUAILLARD To: Matthew Kaufman Content-Type: multipart/alternative; boundary=089e012287c6f1bba0050701f3c7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rPsU5BygV4AzrbvGMxxzm5c0akI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 05:44:16 -0000 --089e012287c6f1bba0050701f3c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Apple had 264, but there was no API to make 264 HW acceleration available to developers. It was mentioned as one of the reason why cisco open264 felt short of addressing some concerns voiced in the MTI pool. the iOS 8's 264 API changed this. In any case, I support the chair decision to try to revisit the question. On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman wrote= : > A "substantive change" would be *any* of the parties who participate in > these discussions having a different position than before. > > Yes, Cisco, who already supported H.264 and had announced an intention to > ship an open source and binary module, shipped H.264. > > And Firefox, reluctant supporter of H.264 when available but preferring > VP8 and some future even more free codec that isn't yet shipped, is > reluctantly supporting H.264 when available. > > And iOS 8 has H.264, but of course Apple already had access to that H.264 > if they were to put WEBRTC into their browser... > > Etc. > > Where's the "Google has decided to pull their support for VP8 and fully > back H.264 for real-time communications on the web" announcement? Or the > "Microsoft open-sources Internet Explorer, adds native VP8 to Windows" > announcement? Or the "MPEG-LA drops all fees for H.264 encoding and > decoding" announcement? Or really *anything* that substantially changes > things from where we were six months ago? > > I don't get the desire to spend time on this topic... and I especially > don't understand the call to pack as many people into a room as possible = to > conduct a hum, when the outcome will need to be discussed and confirmed o= n > the list anyway. > > Matthew Kaufman > > > On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote: > > Matthew, > > You wrote: > "I'm going to ask what I asked when I first saw this on the agenda: What > has substantively changed since then? > > As far as I can tell, nothing.: > > Actually several things have substantively changed since then. The list > includes but is not limited to: > > * Cisco shipped its H264 open source and binary module > * Firefox is using the Cisco binary module and as such Firefox now > supports both H264 and VP8 > * IOS8 has shipped with API support for H264 (you may recall that lack of > a solution for H264 on IOS was an objection many had regarding the Cisco > h264 binary module solution; this is now addressed) > * there has been progress in the ongoing legal proceedings around VP8 > * there are new IPR statements regarding VP8 in ongoing standards process= es > > > I think this is far beyond "nothing". And given the importance of this > topic to progress on adoption of webRTC, it warrants discussion at the mi= c. > > -Jonathan R. > > > On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand > wrote: > >> Hm. >> >> I don=E2=80=99t think there=E2=80=99s much value in revisiting the =E2= =80=9Cone codec=E2=80=9D >> alternatives. We tried that, and know that we found no consensus. Nobody= =E2=80=99s >> changed their minds. >> >> It would be very sad if we give up on interoperability for WebRTC >> devices. Accepting =E2=80=9Ceither=E2=80=9D means that there will be 2 g= roups of them, and >> they need a gateway to talk to each other, even when they can all talk t= o >> all compatible browsers. Having an MTI would be better - but one purpose= of >> the =E2=80=9Cdevice=E2=80=9D category is to allow fully compliant device= s that don=E2=80=99t need >> the kind of corporate backing a browser needs - which means that license= d >> codecs are an issue. We=E2=80=99ve had that discussion before. >> >> Of course, WebRTC-compatible devices (as currently defined) can do >> whatever they want. >> >> But still, it seems that there=E2=80=99s a chance that discussing this a= gain is >> worth it. We might find an agreement this time. >> >> Harald >> >> >> >> >> On 11/03/2014 03:32 PM, Sean Turner wrote: >> >> All, >> >> One of the remaining major technical decisions for the RTCweb WG is whic= h codec(s) should be MTI. The issue has been on hold for over 6 months an= d the original plan to was the re-attempt determining consensus at the IETF= 91. To make the best use of the WG=E2=80=99s face-to-face time at IETF 91= , we want to give the WG ample time to digest/discuss the questions the cha= irs intend to ask the WG concerning the MTI codec (or codecs). We want to = know before the meeting whether to ask the questions and then what question= s to ask - in other words we want to inform the WG of the questions before = the WG session so as to not waste time debating what questions should be as= ked. >> >> Without further ado, these are the proposed questions: >> >> Question #0 (hum) >> >> Do you want to discuss this issue at this meeting? >> >> Question #1 (stand up) >> >> Please stand (or signal in the jabber chat) if you will be part of that = consensus process for this question. If you're here to read email or watch = the show, we want to know that your sitting throughout this isn't expressin= g opinions for the consensus process. >> >> To many this might seem like a silly question, >> but the chairs believe the problem is well enough >> understood by those actively involved WG >> participants so we would like to confirm this >> understanding. The chairs will also use to the >> determine the informed pool of WG participants. >> >> Question #2 (hum) >> >> Do you believe we need an MTI codec to avoid negotiation failures? >> >> Previous attempts at determining the MTI did not >> yield a result but did confirm that there is a desire >> for an MTI to avoid negotiation failures. Recently, >> some on the mailing list have expressed an interest >> in postponing this discussion until after IETF 91. The >> purpose of this question is to reconfirm the original >> consensus. >> >> Question #3 (open mic) >> >> Are there any codecs that were not included in the previous consensus ca= lls that warrant consideration? If yes, which one and why. >> >> The assumption is that the viable codecs are a) VP8, >> b) H.264, or c) VP8 and H.264. This is based on the >> extensive poll results from the last consensus calls. >> But time has passed so we need to entertain the ever >> so slight possibility that another codec has miraculously >> appeared. Remember, we want to ensure we=E2=80=99re going >> to get maximum interoperability. >> >> Question #4 (open mic) >> >> Are there any new or unaddressed technical issues that will not allow us= to narrow the field to VP8 and H.264? >> >> We do not want to revisit previous discussions; we only >> want new or unaddressed technical issues and will throttle >> the discussion accordingly. We=E2=80=99ll rely on WG participants >> and our former RAI AD (Mr. Sparks) for help in this area. >> >> We believe the technical discussion will fall into two >> buckets: >> - New or unresolved technical points. >> - Licensing. WRT licensing, the IETF tries not discuss >> whether IPR is valid, but an IPR issue that can be used >> as input to the decision making process is if enough >> people say they can=E2=80=99t/won=E2=80=99t implement because of= the IPR. >> >> Question #5 (hum) >> >> With respect to the MTI codec: >> - Who can live with a requirement that WebRTC User Agents >> MUST support both VP8 and H.264 and WebRTC devices >> MUST support either VP8 or H.264? >> - Who can live with a requirement that all endpoints MUST support VP= 8? >> - Who can live with a requirement that all endpoints MUST support H.= 264? >> >> Thanks for your time, >> t/c/s >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/= rtcweb >> >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --089e012287c6f1bba0050701f3c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apple had 264, but there was no API to make 264 HW acceler= ation available to developers. It was mentioned as one of the reason why ci= sco open264 felt short of addressing some concerns voiced in the MTI pool. = the iOS 8's 264 API changed this.

In any case, I sup= port the chair decision to try to revisit the question.

On Tue, Nov 4, 2014 at 11= :15 AM, Matthew Kaufman <matthew@matthew.at> wrote:
=20 =20 =20
A "substantive change" would be *any* of the parties who part= icipate in these discussions having a different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention to ship an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring VP8 and some future even more free codec that isn't yet shipped, is reluctantly supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that H.264 if they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their support for VP8 = and fully back H.264 for real-time communications on the web" announcement? Or the "Microsoft open-sources Internet Explorer, ad= ds native VP8 to Windows" announcement? Or the "MPEG-LA drops al= l fees for H.264 encoding and decoding" announcement? Or really *anything= * that substantially changes things from where we were six months ago?
I don't get the desire to spend time on this topic... and I especially don't understand the call to pack as many people into a room as possible to conduct a hum, when the outcome will need to be discussed and confirmed on the list anyway.

Matthew Kaufman


On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
Matthew,

You wrote:
&q= uot;I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then?

As far as I can tell, nothing.:
Ac= tually several things have substantively changed since then. The list includes but is not limited to:
* Cisco shipped its H264 open source and binary module
* Firefox is using the Cisco binary module and as such Firefox now supports both H264 and VP8
* IOS8 has shipped with API support for H264 (you may recall that lack of a solution for H264 on IOS was an objection many had regarding the Cisco h264 binary module solution; this is now addressed)
* there has been progress in the ongoing legal proceedings around VP8
* there are new IPR statements regarding VP8 in ongoing standards processes
I think this is far beyond "nothing". And given the importance of this topic to progress on adoption of webRTC, it warrants discussion at the mic.

-Jonathan R.

On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
Hm.

I don=E2=80=99t think there=E2=80=99s much value in revisit= ing the =E2=80=9Cone codec=E2=80=9D alternatives. We tried that, and know that w= e found no consensus. Nobody=E2=80=99s changed their minds.
It would be very sad if we give up on interoperability for WebRTC devices. Accepting =E2=80=9Ceither=E2=80=9D mean= s that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the =E2=80=9Cdevice=E2=80=9D category is to = allow fully compliant devices that don=E2=80=99t need the kind of corpo= rate backing a browser needs - which means that licensed codecs are an issue. We=E2=80=99ve had that discussion befo= re.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there=E2=80=99s a chance that discussing this again is worth it. We might find an agreement this time.

Harald




On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which c=
odec(s) should be  MTI.  The issue has been on hold for over 6 months and t=
he original plan to was the re-attempt determining consensus at the IETF 91=
.  To make the best use of the WG=E2=80=99s face-to-face time at IETF 91, w=
e want to give the WG ample time to digest/discuss the questions the chairs=
 intend to ask the WG concerning the MTI codec (or codecs).  We want to kno=
w before the meeting whether to ask the questions and then what questions t=
o ask - in other words we want to inform the WG of the questions before the=
 WG session so as to not waste time debating what questions should be asked=
.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that con=
sensus process for this question. If you're here to read email or watch=
 the show, we want to know that your sitting throughout this isn't expr=
essing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants. =20

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls=
 that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we=E2=80=99re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to=
 narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We=E2=80=99ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can=E2=80=99t/won=E2=80=99t implement because of th=
e IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264=
?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Surveillance is pervasive. Go Dark.

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




-- 


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


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




--
Alex. Gouaillard, PhD, PhD, MBA--------------------------------------------------------------------------= ----------
CTO - Temasys Communications, S'pore / Mountain Vi= ew
President - CoSMo Software, Cambridge, MA
----------= --------------------------------------------------------------------------<= /div>

--089e012287c6f1bba0050701f3c7-- From nobody Mon Nov 3 22:36:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D782E1A88D4 for ; Mon, 3 Nov 2014 22:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 T8U6iLePqf3o for ; Mon, 3 Nov 2014 22:36:43 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF5B1A88D0 for ; Mon, 3 Nov 2014 22:36:43 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id e131so9943902oig.30 for ; Mon, 03 Nov 2014 22:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eDDHpxbpftKBUw+sKLXhmqSpT7U6H435/i5Xmi2/SUQ=; b=YOSUXa/IrBl0WIncemeujTJMjhAaOS0tEd4h28UDnLY2u0GZdXRHldeTlaVc5v+h6H 2uif6LgXV94XQkuekJp1THCz8x/xXdVVhRuIZuKThdRxy5Zrnl9F/WTGQOYG0gfYHYE1 dKt5s1sK7k/HKANPlUGkBH24dSnjgPAQhPLVGb5xeXkabqDAAdJZ8r6OXZlrHmz1IaoB YkV34anxerbU9zbA6OtNo8+e3Ih3abqsY09lETQE5sy1OVRbvLNc+GffTwu54eBhhspd rsDllHPeIszMmOGE0RVNnF0oC7rs4qAF1X50waBGoVwl2c3NKWr0kSZyCy5JaQRJtFJE I2yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eDDHpxbpftKBUw+sKLXhmqSpT7U6H435/i5Xmi2/SUQ=; b=M9PXdgygMyQ0wnQbCIxqDpzRBPUU33uTipLGvDMwvv76KKnbXkGM7oJaV5KTiSquXk /aDhW1H/DiInmHzPZJJgN0nlHIqbf66MCPvGHrwrPQjp/pj47NgM8wAdqv0H6I3dpAFi mWFeEMaGFJAZIZeJK0L6SgySrNHSaH81LWX3VmZEOyjw+9BTKjjHQyGHeuE5/uCOUPGJ xAn79SQBxirjNvYLTcIg0h6d0MJZwPUHKpTPhGqCYi1mznA07b3NDp55NrMRApykaHOG GVidouTOMgJwmbM9d+0EWkoqN3GC5l60JsVwbbRMjPdnWt0gbYyl6uZ5PjQcRmgF8okw A5Tg== X-Gm-Message-State: ALoCoQmQauUSHO7tAUIwzp6uwVHMqTPEBPVxy0QFu7Hdqt2f5G4Lz/fYNumaPJeyOjJTqnzACsun X-Received: by 10.182.24.166 with SMTP id v6mr40899186obf.30.1415083002375; Mon, 03 Nov 2014 22:36:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Mon, 3 Nov 2014 22:36:22 -0800 (PST) In-Reply-To: <54581E56.10407@matthew.at> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54581E56.10407@matthew.at> From: Justin Uberti Date: Mon, 3 Nov 2014 22:36:22 -0800 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=001a11c2eca4af7dc7050702af07 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qP5x4ThT73ZUnbF6co4EFnHbS7g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 06:36:45 -0000 --001a11c2eca4af7dc7050702af07 Content-Type: text/plain; charset=UTF-8 > > > > ps. Doing this with hums at a meeting just encourages filling the room > with people who aren't participating in the process but whose employers > have asked them to stuff the room to increase the hum volume. Those people > will all stand up for question #1, then leave immediately after the hums > are completed. Just like last time. I am shocked -- shocked -- at these allegations of room stuffing in our beloved IETF. Surely the blue sheets from IETF 88 (the last time we discussed codecs, on day 2) will put to rest these claims. Wait... CompanyDay2 RTCWEB AttendeesDay1 RTCWEB AttendeesDeltacisco251510mozilla1212 0ericsson1055huawei1082google990alu642oracle550 (stats shown for all company affiliations reported by 5 or more people) --001a11c2eca4af7dc7050702af07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


ps. Doing this with hums at a meeting just encourages filling the room with= people who aren't participating in the process but whose employers hav= e asked them to stuff the room to increase the hum volume. Those people wil= l all stand up for question #1, then leave immediately after the hums are c= ompleted. Just like last time.
=C2=A0
I am shock= ed -- shocked -- at these allegations of room stuffing in our beloved IETF.= =C2=A0 Surely the blue sheets from IETF 88 (t= he last time we discussed codecs, on day 2) will put to rest these claims.= =C2=A0

Wait...

<= col width=3D"37">=
CompanyDay2 RTCWEB AttendeesDay1 RTCWEB AttendeesDelta
cisco251510<= /td>
mozilla12120
ericsso= n1055
huawei1082
google990=
alu642
oracle550

(stats shown for all company affiliations reported by 5 or more pe= ople)

--001a11c2eca4af7dc7050702af07-- From nobody Tue Nov 4 02:24:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995AF1A0861 for ; Tue, 4 Nov 2014 02:24:35 -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 aNE_ak3_j2Vu for ; Tue, 4 Nov 2014 02:24:33 -0800 (PST) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A733C1A0043 for ; Tue, 4 Nov 2014 02:24:33 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id fp1so13464786pdb.13 for ; Tue, 04 Nov 2014 02:24:33 -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:from:date :message-id:subject:to:cc:content-type; bh=qeq04xfA95Atajc2LoBtQztRcnHO3St6de73I4WgsUw=; b=XQM45b4LfF/oOXeoeXa4ozs4y2rNrdLiupZmals8+DXKu+Cb28sFtRl2Z65nIk59/W NtV0FPZgx+F1P4h6AWgXpjJYrZBHoCmOe86fkVcE8L+P+33PAorTQmaeC8haFuwDzByZ y0oPQM08FmQEKdmHYUSkV72OcpuOD0jjIhOAD6qYmS+67bYYoAtiUyNMw6vh7Yo8X4bB y0KGWmCn2mFJAy31uXEs78eLX2b2xGfzY+V3qVhrPbdpBJHexs9ir23wZ7aH1WzgNrgW 2LrZ6tLsdVa0k1lI66Broeap7kpKM6T1h++oboXw9YnfpEdvzLGWZpSmKLgg6ZCtvTRb 68Iw== X-Gm-Message-State: ALoCoQm2AtqtGyv4N2Qxh98MJfKW8/an9ulqvxBJ3VCx29598JrFgcdzpcrlYSvcowE0eNbvNBBB X-Received: by 10.68.68.226 with SMTP id z2mr14963672pbt.107.1415096673112; Tue, 04 Nov 2014 02:24:33 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com. [209.85.220.48]) by mx.google.com with ESMTPSA id nz2sm9603pbb.29.2014.11.04.02.24.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 02:24:32 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id ey11so14158435pad.35 for ; Tue, 04 Nov 2014 02:24:32 -0800 (PST) X-Received: by 10.66.194.39 with SMTP id ht7mr4397482pac.91.1415096672056; Tue, 04 Nov 2014 02:24:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.100.227 with HTTP; Tue, 4 Nov 2014 02:24:11 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54581E56.10407@matthew.at> From: Emil Ivov Date: Tue, 4 Nov 2014 11:24:11 +0100 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bf0c5d87618a5050705de7f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Y5rjxj0nZebg4_G_nxVLtQl6vnU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 10:24:35 -0000 --047d7bf0c5d87618a5050705de7f Content-Type: text/plain; charset=UTF-8 Looking at the list of IETF attendees for that session [0] we see that total meeting participation for the delta companies was: Cisco: 118 Ericsson: 36 So, clearly someone was very sloppy when organizing the rtcweb MTI voting flood. A participation of 21% and 28% respectively is indeed quite embarassing. Reopening the question in Hawaii would allow raising the awareness among the non-voters and having the proper numbers attend this time. *That* could constitute one important change since last time and, if so, it would totally justify having the debate again. [0] https://www.ietf.org/registration/ietf88/attendance.py --sent from my mobile On 04 Nov 2014 7:36 AM, "Justin Uberti" wrote: > >> >> ps. Doing this with hums at a meeting just encourages filling the room >> with people who aren't participating in the process but whose employers >> have asked them to stuff the room to increase the hum volume. Those people >> will all stand up for question #1, then leave immediately after the hums >> are completed. Just like last time. > > > I am shocked -- shocked -- at these allegations of room stuffing in our > beloved IETF. Surely the blue > > sheets > > from IETF 88 (the last time we discussed codecs, on day 2) will put to rest > these claims. > > Wait... > > CompanyDay2 RTCWEB AttendeesDay1 RTCWEB AttendeesDeltacisco251510mozilla12 > 120ericsson1055huawei1082google990alu642oracle550 > (stats shown for all company affiliations reported by 5 or more people) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bf0c5d87618a5050705de7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Looking at the list of IETF attendees for t= hat session [0] we see that total meeting participation for the delta compa= nies was:

Cisco: 118
Ericsson: 36

So, clearly someone was very sloppy when organizing the rtcw= eb MTI voting flood. A participation of 21% and 28% respectively is indeed = quite embarassing.=C2=A0

Reopening the question in Hawaii would allow raising the awa= reness among the non-voters and having the proper numbers attend this time.= =C2=A0

*That* could constitute one important change since= last time and, if so, it would totally justify having the debate again.

[0]=C2=A0https://www.ietf.org/registration/ietf88/attendance.py<= /p>

--sent from my mobile

On 04 Nov 2014 7:36 AM, "Justin Uberti"= ; <juberti@googl= e.com> wrote:
=

ps. Doing this with hums at a meeting just encourages filling the room with= people who aren't participating in the process but whose employers hav= e asked them to stuff the room to increase the hum volume. Those people wil= l all stand up for question #1, then leave immediately after the hums are c= ompleted. Just like last time.
=C2=A0
I am shock= ed -- shocked -- at these allegations of room stuffing in our beloved IETF.= =C2=A0 Surely the blue sheets from IETF 88 (the last time we discussed codecs, on = day 2) will put to rest these claims.=C2=A0

Wait..= .

<= col width=3D"38"><= td style=3D"padding:2px 3px;vertical-align:bottom">mozilla=
CompanyDay2 RTCWEB At= tendeesDay1 RTCWEB AttendeesDelta
cisco251510
12120
ericsson= 1055
huawei1082
google9= 90
alu642
oracle550=

(stats shown for all compan= y affiliations reported by 5 or more people)

=

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

--047d7bf0c5d87618a5050705de7f-- From nobody Tue Nov 4 04:40:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F881A1B07 for ; Tue, 4 Nov 2014 04:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.243 X-Spam-Level: * X-Spam-Status: No, score=1.243 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUpj2SJ8fNhB for ; Tue, 4 Nov 2014 04:40:21 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 83E801A0071 for ; Tue, 4 Nov 2014 04:40:16 -0800 (PST) Received: (qmail 28388 invoked by uid 0); 4 Nov 2014 12:40:16 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 4 Nov 2014 12:40:16 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw4 with id BWg91p00L2Yhrsa01WgCEr; Tue, 04 Nov 2014 11:40:15 -0700 X-Authority-Analysis: v=2.1 cv=b7chvL2x c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=2mhjNb98rjwA:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=KWLd9SN1AAAA:8 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=N1z6yVdWAAAA:8 a=tSGl3AYFeBaBT0sejKcA:9 a=QEXdDO2ut3YA:10 a=UyMlXms6rVQA:10 a=DtGIcscNzR8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=5Y7otE8NktUY6HE6F9A56j8KVgysX4tzGavak//WHRw=; b=mynvcM09vhXJYGEl/51AXykXTtOnc+fj4ECST5k3SWTA60wrm+d8hRXc2+Sji5DgmOAC4DpcmmyNhMhAMO7pK7bARUWTqHHwKd0eipjUmOfbhtjUBR4J59bls1NY7Uti; Received: from localhost ([127.0.0.1]:51397 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XldP7-0000KS-SP for rtcweb@ietf.org; Tue, 04 Nov 2014 05:40:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 04 Nov 2014 05:40:07 -0700 From: Jackie Blanco To: rtcweb@ietf.org Message-ID: <5a3cc5a6735a646b377b4562f1d19bc4@sdiwc.info> X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/0.9.5 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TF9kHjZfkp87hExmqOEQs7i7kq0 Subject: [rtcweb] CFP: Fourth ICEEE2015 - International Conference on E-Learning and E-Technologies in Education X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 12:40:24 -0000 The Fourth International Conference on E-Learning and E-Technologies in Education (ICEEE2015) Surya University, Indonesia (21 KM from Jakarta Airport) September 10-12, 2015 http://sdiwc.net/conferences/iceee2015/ The proposed conference on the above theme will be held at Surya University, Indonesia (21 KM from Jakarta Airport) on September 10-12, 2015 which aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: - Accessibility to Disabled Users - Assessment and Accreditation of Courses and Institutions - Assessment Methods in Blended Learning Environments - Assessment Software Tools - Authoring Tools and Content Development - AV-Communication and Multimedia - Blended Learning - Collaborative Learning - Community Building - Computer-Aided Assessment - Context Dependent Learning - Cooperation with Industry in Teaching - Course Design and E-Learning Curriculae - Critical Success Factors in Distance Learning - Digital Libraries for E-Learning - Distance and E-Learning in a Global Context - Distance Education - Educating the Educators - E-Learning Hardware and Software - E-learning in Electrical, Mechanical, Civil and information engineering - E-Learning Platforms, Portals - E-Learning Success Cases - Errors in E-Learning - E-Testing and new Test Theories - Groupware Tools - Higher Education vs. Vocational Training - Immersive Learning - Impact and Achievements of International Initiatives - Intelligent Tutoring Systems - Interdisciplinary Programs for Distance Education - International Partnerships in Teaching - Joint Degrees - Learning Organization - Lifelong Learning: Continuing Professional Training and Development - Medical Applications - Metrics and Performance Measurement - Mobile Learning (M-learning) - Ontologies and Meta-Data Standards - Pedagogy Enhancement with E-Learning - Security Aspects - Simulated Communities and Online Mentoring - Standards and Interoperability - Supervising and Managing Student Projects - Synchronous and Asynchronous Learning - Teacher Evaluation - Technology Enhanced Learning - Technology Support for Pervasive Learning - Theoretical Bases of E-Learning Environments - Virtual Labs and Virtual Classrooms - Web-based Learning, Wikis and Blogs Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Paper submission can be done at http://sdiwc.net/conferences/iceee2015/openconf/openconf.php Important Dates ============== Submission Dates : Open from now until July 20, 2015 Notification of Acceptance : 2-4 weeks from the submission date Camera Ready Submission : September 1, 2015 Registration : September 1, 2015 Conference Dates : September 10-12, 2015 From nobody Tue Nov 4 05:09:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8421A1B0D for ; Tue, 4 Nov 2014 05:09:02 -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 VVaKC6npsrJV for ; Tue, 4 Nov 2014 05:08:55 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60CC1A1B06 for ; Tue, 4 Nov 2014 05:08:54 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so4347927lbv.24 for ; Tue, 04 Nov 2014 05:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=V5qwOi6AWYuezKuo7dIoAO+INqUFQbrzISN2hV/LRlA=; b=HDDBN8LjeBCbGRujts4Zol+M0gPpkCTFSXA8JkhRXeHyqDEWctCUmVZPjVNLXh++xn ZDXt9qyhO5rvDXZ86JIUkxDUQ0Da+4uiOpA+yxgKm1GAvmEt+ALnL6husmrSEmr6Ucmd GBvfwf/gJZchrNYqAZuA3gMbjaOF2KpPIBNX8/5TTIGM4heDEPq/mDGPRIgwk/Es2BB+ bxZYRlLUsZGrihIHdMMtjEH4bVNtMx/eM8Im/zgiKBvIywKuoiO9VzNz0Mk+Dua9plRu 4XzURt0X+EdxOIwkdk8wmE87W3zfjPoZZvyTnfyHraNwzg3JiJ9h3k+n0y1ckgQJ16Rb N/HQ== X-Received: by 10.112.77.129 with SMTP id s1mr60493924lbw.36.1415106532800; Tue, 04 Nov 2014 05:08:52 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id w8sm137580lbp.46.2014.11.04.05.08.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 05:08:47 -0800 (PST) Message-ID: <5458CFDC.4020401@gmail.com> Date: Tue, 04 Nov 2014 14:08:44 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Alexandre GOUAILLARD , Matthew Kaufman References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> <545844CC.5010000@matthew.at> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030701090604080908020100" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xIvILEHxS7R0p1ObPkWepNc55v0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 13:09:02 -0000 This is a multi-part message in MIME format. --------------030701090604080908020100 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit If there are groups of people willing to discuss the evolution of the surrounding environment around video codecs, that's their time, can be done anywhere at their wish. Related to the substance of webrtc MTI, there is nothing new out there relevant to the video codecs constraints. No change from MPEG-LA on H.264 costs and restrictions for use freely by everyone (including the open source space), as expected when having to implement an open standard from IETF. No final decisions on patent claims to VP8. Let's hope soon there will be news about: - MPEG-LA makes H.264 completely free - VP8 pattent claims get to a final decision in court, so either they are dismissed there or they can be dealt differently - a new completely free video codec shows up I expect IETF is going to stand against monopolistic trends and particular business interests, being the standardization body for open protocols in an open internet. It is no excuse to release/propose IETF standards that force someone either to pay to or be tracked by specific group of interests. Let's not forget that not so many years ago there were completely different communication means -- under monopoly, with high costs and very rigid -- without open standards with no barriers for anyone, the level of innovation we benefited in the past years wouldn't have happened. Daniel On 04/11/14 06:44, Alexandre GOUAILLARD wrote: > Apple had 264, but there was no API to make 264 HW acceleration > available to developers. It was mentioned as one of the reason why > cisco open264 felt short of addressing some concerns voiced in the MTI > pool. the iOS 8's 264 API changed this. > > In any case, I support the chair decision to try to revisit the question. > > On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman > wrote: > > A "substantive change" would be *any* of the parties who > participate in these discussions having a different position than > before. > > Yes, Cisco, who already supported H.264 and had announced an > intention to ship an open source and binary module, shipped H.264. > > And Firefox, reluctant supporter of H.264 when available but > preferring VP8 and some future even more free codec that isn't yet > shipped, is reluctantly supporting H.264 when available. > > And iOS 8 has H.264, but of course Apple already had access to > that H.264 if they were to put WEBRTC into their browser... > > Etc. > > Where's the "Google has decided to pull their support for VP8 and > fully back H.264 for real-time communications on the web" > announcement? Or the "Microsoft open-sources Internet Explorer, > adds native VP8 to Windows" announcement? Or the "MPEG-LA drops > all fees for H.264 encoding and decoding" announcement? Or really > *anything* that substantially changes things from where we were > six months ago? > > I don't get the desire to spend time on this topic... and I > especially don't understand the call to pack as many people into a > room as possible to conduct a hum, when the outcome will need to > be discussed and confirmed on the list anyway. > > Matthew Kaufman > > > On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote: >> Matthew, >> >> You wrote: >> "I'm going to ask what I asked when I first saw this on the >> agenda: What has substantively changed since then? >> >> As far as I can tell, nothing.: >> >> Actually several things have substantively changed since then. >> The list includes but is not limited to: >> >> * Cisco shipped its H264 open source and binary module >> * Firefox is using the Cisco binary module and as such Firefox >> now supports both H264 and VP8 >> * IOS8 has shipped with API support for H264 (you may recall that >> lack of a solution for H264 on IOS was an objection many had >> regarding the Cisco h264 binary module solution; this is now >> addressed) >> * there has been progress in the ongoing legal proceedings around VP8 >> * there are new IPR statements regarding VP8 in ongoing standards >> processes >> >> >> I think this is far beyond "nothing". And given the importance of >> this topic to progress on adoption of webRTC, it warrants >> discussion at the mic. >> >> -Jonathan R. >> >> >> On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand >> > wrote: >> >> Hm. >> >> I don’t think there’s much value in revisiting the “one >> codec” alternatives. We tried that, and know that we found no >> consensus. Nobody’s changed their minds. >> >> It would be very sad if we give up on interoperability for >> WebRTC devices. Accepting “either” means that there will be 2 >> groups of them, and they need a gateway to talk to each >> other, even when they can all talk to all compatible >> browsers. Having an MTI would be better - but one purpose of >> the “device” category is to allow fully compliant devices >> that don’t need the kind of corporate backing a browser needs >> - which means that licensed codecs are an issue. We’ve had >> that discussion before. >> >> Of course, WebRTC-compatible devices (as currently defined) >> can do whatever they want. >> >> But still, it seems that there’s a chance that discussing >> this again is worth it. We might find an agreement this time. >> >> Harald >> >> >> >> >> On 11/03/2014 03:32 PM, Sean Turner wrote: >>> All, >>> >>> One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be MTI. The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91. To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs). We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked. >>> >>> Without further ado, these are the proposed questions: >>> >>> Question #0 (hum) >>> >>> Do you want to discuss this issue at this meeting? >>> >>> Question #1 (stand up) >>> >>> Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process. >>> >>> To many this might seem like a silly question, >>> but the chairs believe the problem is well enough >>> understood by those actively involved WG >>> participants so we would like to confirm this >>> understanding. The chairs will also use to the >>> determine the informed pool of WG participants. >>> >>> Question #2 (hum) >>> >>> Do you believe we need an MTI codec to avoid negotiation failures? >>> >>> Previous attempts at determining the MTI did not >>> yield a result but did confirm that there is a desire >>> for an MTI to avoid negotiation failures. Recently, >>> some on the mailing list have expressed an interest >>> in postponing this discussion until after IETF 91. The >>> purpose of this question is to reconfirm the original >>> consensus. >>> >>> Question #3 (open mic) >>> >>> Are there any codecs that were not included in the previous consensus calls that warrant consideration? If yes, which one and why. >>> >>> The assumption is that the viable codecs are a) VP8, >>> b) H.264, or c) VP8 and H.264. This is based on the >>> extensive poll results from the last consensus calls. >>> But time has passed so we need to entertain the ever >>> so slight possibility that another codec has miraculously >>> appeared. Remember, we want to ensure we’re going >>> to get maximum interoperability. >>> >>> Question #4 (open mic) >>> >>> Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264? >>> >>> We do not want to revisit previous discussions; we only >>> want new or unaddressed technical issues and will throttle >>> the discussion accordingly. We’ll rely on WG participants >>> and our former RAI AD (Mr. Sparks) for help in this area. >>> >>> We believe the technical discussion will fall into two >>> buckets: >>> - New or unresolved technical points. >>> - Licensing. WRT licensing, the IETF tries not discuss >>> whether IPR is valid, but an IPR issue that can be used >>> as input to the decision making process is if enough >>> people say they can’t/won’t implement because of the IPR. >>> >>> Question #5 (hum) >>> >>> With respect to the MTI codec: >>> - Who can live with a requirement that WebRTC User Agents >>> MUST support both VP8 and H.264 and WebRTC devices >>> MUST support either VP8 or H.264? >>> - Who can live with a requirement that all endpoints MUST support VP8? >>> - Who can live with a requirement that all endpoints MUST support H.264? >>> >>> Thanks for your time, >>> t/c/s >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> -- >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> >> >> _______________________________________________ >> 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 > > > > > -- > Alex. Gouaillard, PhD, PhD, MBA > ------------------------------------------------------------------------------------ > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > * > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda --------------030701090604080908020100 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit If there are groups of people willing to discuss the evolution of the surrounding environment around video codecs, that's their time, can be done anywhere at their wish.

Related to the substance of webrtc MTI, there is nothing new out there relevant to the video codecs constraints. No change from MPEG-LA on H.264 costs and restrictions for use freely by everyone (including the open source space), as expected when having to implement an open standard from IETF. No final decisions on patent claims to VP8.

Let's hope soon there will be news about:
- MPEG-LA makes H.264 completely free
- VP8 pattent claims get to a final decision in court, so either they are dismissed there or they can be dealt differently
- a new completely free video codec shows up

I expect IETF is going to stand against monopolistic trends and particular business interests, being the standardization body for open protocols in an open internet. It is no excuse to release/propose IETF standards that force someone either to pay to or be tracked by specific group of interests.

Let's not forget that not so many years ago there were completely different communication means -- under monopoly, with high costs and very rigid -- without open standards with no barriers for anyone, the level of innovation we benefited in the past years wouldn't have happened.

Daniel


On 04/11/14 06:44, Alexandre GOUAILLARD wrote:
Apple had 264, but there was no API to make 264 HW acceleration available to developers. It was mentioned as one of the reason why cisco open264 felt short of addressing some concerns voiced in the MTI pool. the iOS 8's 264 API changed this.

In any case, I support the chair decision to try to revisit the question.

On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman <matthew@matthew.at> wrote:
A "substantive change" would be *any* of the parties who participate in these discussions having a different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention to ship an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring VP8 and some future even more free codec that isn't yet shipped, is reluctantly supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that H.264 if they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their support for VP8 and fully back H.264 for real-time communications on the web" announcement? Or the "Microsoft open-sources Internet Explorer, adds native VP8 to Windows" announcement? Or the "MPEG-LA drops all fees for H.264 encoding and decoding" announcement? Or really *anything* that substantially changes things from where we were six months ago?

I don't get the desire to spend time on this topic... and I especially don't understand the call to pack as many people into a room as possible to conduct a hum, when the outcome will need to be discussed and confirmed on the list anyway.

Matthew Kaufman


On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
Matthew,

You wrote:
"I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then?

As far as I can tell, nothing.:

Actually several things have substantively changed since then. The list includes but is not limited to:

* Cisco shipped its H264 open source and binary module
* Firefox is using the Cisco binary module and as such Firefox now supports both H264 and VP8
* IOS8 has shipped with API support for H264 (you may recall that lack of a solution for H264 on IOS was an objection many had regarding the Cisco h264 binary module solution; this is now addressed)
* there has been progress in the ongoing legal proceedings around VP8
* there are new IPR statements regarding VP8 in ongoing standards processes


I think this is far beyond "nothing". And given the importance of this topic to progress on adoption of webRTC, it warrants discussion at the mic.

-Jonathan R.


On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
Hm.

I don’t think there’s much value in revisiting the “one codec” alternatives. We tried that, and know that we found no consensus. Nobody’s changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. Accepting “either” means that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the “device” category is to allow fully compliant devices that don’t need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We’ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there’s a chance that discussing this again is worth it. We might find an agreement this time.

Harald




On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be  MTI.  The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91.  To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs).  We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants.  

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we’re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We’ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can’t/won’t implement because of the IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.

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




-- 


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


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




--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------



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


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
--------------030701090604080908020100-- From nobody Tue Nov 4 06:04:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098DE1A212A for ; Tue, 4 Nov 2014 06:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 339T6YIMyY20 for ; Tue, 4 Nov 2014 06:04:15 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A651A6F0E for ; Tue, 4 Nov 2014 06:04:13 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 73752D8BAE648; Tue, 4 Nov 2014 14:04:06 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sA4E3plE029481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 15:04:06 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 15:03:34 +0100 From: "DRAGE, Keith (Keith)" To: "miconda@gmail.com" , Alexandre GOUAILLARD , Matthew Kaufman Thread-Topic: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) Thread-Index: AQHP+DB2WeDtikPU4EeunXdmooHmHZxQfpMw Date: Tue, 4 Nov 2014 14:03:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B2703CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> <545844CC.5010000@matthew.at> <5458CFDC.4020401@gmail.com> In-Reply-To: <5458CFDC.4020401@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B2703CBFR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M6ww6O8lQYZUn6zljCpMp4iGOqc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 14:04:23 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B2703CBFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your statements about what the IETF should expect are somewhat different fr= om the statements in RFC 3979. I quote: In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. You are perfectly entitled to have your own personal view of what you desir= e, but please do not equate your desires with IETF policy in this area. I'd also note you are making your own assumptions about the IPR encumbrance= of various solutions, and those assumptions may not match those of other p= articipants. IETF itself does not evaluate IPR encumbrance. regards Keith Drage ________________________________ From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Daniel-Constanti= n Mierla Sent: 04 November 2014 13:09 To: Alexandre GOUAILLARD; Matthew Kaufman Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask t= hem) If there are groups of people willing to discuss the evolution of the surro= unding environment around video codecs, that's their time, can be done anyw= here at their wish. Related to the substance of webrtc MTI, there is nothing new out there rele= vant to the video codecs constraints. No change from MPEG-LA on H.264 costs= and restrictions for use freely by everyone (including the open source spa= ce), as expected when having to implement an open standard from IETF. No fi= nal decisions on patent claims to VP8. Let's hope soon there will be news about: - MPEG-LA makes H.264 completely free - VP8 pattent claims get to a final decision in court, so either they are d= ismissed there or they can be dealt differently - a new completely free video codec shows up I expect IETF is going to stand against monopolistic trends and particular = business interests, being the standardization body for open protocols in an= open internet. It is no excuse to release/propose IETF standards that forc= e someone either to pay to or be tracked by specific group of interests. Let's not forget that not so many years ago there were completely different= communication means -- under monopoly, with high costs and very rigid -- w= ithout open standards with no barriers for anyone, the level of innovation = we benefited in the past years wouldn't have happened. Daniel On 04/11/14 06:44, Alexandre GOUAILLARD wrote: Apple had 264, but there was no API to make 264 HW acceleration available t= o developers. It was mentioned as one of the reason why cisco open264 felt = short of addressing some concerns voiced in the MTI pool. the iOS 8's 264 A= PI changed this. In any case, I support the chair decision to try to revisit the question. On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman > wrote: A "substantive change" would be *any* of the parties who participate in the= se discussions having a different position than before. Yes, Cisco, who already supported H.264 and had announced an intention to s= hip an open source and binary module, shipped H.264. And Firefox, reluctant supporter of H.264 when available but preferring VP8= and some future even more free codec that isn't yet shipped, is reluctantl= y supporting H.264 when available. And iOS 8 has H.264, but of course Apple already had access to that H.264 i= f they were to put WEBRTC into their browser... Etc. Where's the "Google has decided to pull their support for VP8 and fully bac= k H.264 for real-time communications on the web" announcement? Or the "Micr= osoft open-sources Internet Explorer, adds native VP8 to Windows" announcem= ent? Or the "MPEG-LA drops all fees for H.264 encoding and decoding" announ= cement? Or really *anything* that substantially changes things from where w= e were six months ago? I don't get the desire to spend time on this topic... and I especially don'= t understand the call to pack as many people into a room as possible to con= duct a hum, when the outcome will need to be discussed and confirmed on the= list anyway. Matthew Kaufman On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote: Matthew, You wrote: "I'm going to ask what I asked when I first saw this on the agenda: What ha= s substantively changed since then? As far as I can tell, nothing.: Actually several things have substantively changed since then. The list inc= ludes but is not limited to: * Cisco shipped its H264 open source and binary module * Firefox is using the Cisco binary module and as such Firefox now supports= both H264 and VP8 * IOS8 has shipped with API support for H264 (you may recall that lack of a= solution for H264 on IOS was an objection many had regarding the Cisco h26= 4 binary module solution; this is now addressed) * there has been progress in the ongoing legal proceedings around VP8 * there are new IPR statements regarding VP8 in ongoing standards processes I think this is far beyond "nothing". And given the importance of this topi= c to progress on adoption of webRTC, it warrants discussion at the mic. -Jonathan R. On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand > wrote: Hm. I don't think there's much value in revisiting the "one codec" alternatives= . We tried that, and know that we found no consensus. Nobody's changed thei= r minds. It would be very sad if we give up on interoperability for WebRTC devices. = Accepting "either" means that there will be 2 groups of them, and they need= a gateway to talk to each other, even when they can all talk to all compat= ible browsers. Having an MTI would be better - but one purpose of the "devi= ce" category is to allow fully compliant devices that don't need the kind o= f corporate backing a browser needs - which means that licensed codecs are = an issue. We've had that discussion before. Of course, WebRTC-compatible devices (as currently defined) can do whatever= they want. But still, it seems that there's a chance that discussing this again is wor= th it. We might find an agreement this time. Harald On 11/03/2014 03:32 PM, Sean Turner wrote: All, One of the remaining major technical decisions for the RTCweb WG is which c= odec(s) should be MTI. The issue has been on hold for over 6 months and t= he original plan to was the re-attempt determining consensus at the IETF 91= . To make the best use of the WG's face-to-face time at IETF 91, we want t= o give the WG ample time to digest/discuss the questions the chairs intend = to ask the WG concerning the MTI codec (or codecs). We want to know before= the meeting whether to ask the questions and then what questions to ask - = in other words we want to inform the WG of the questions before the WG sess= ion so as to not waste time debating what questions should be asked. Without further ado, these are the proposed questions: Question #0 (hum) Do you want to discuss this issue at this meeting? Question #1 (stand up) Please stand (or signal in the jabber chat) if you will be part of that con= sensus process for this question. If you're here to read email or watch the= show, we want to know that your sitting throughout this isn't expressing o= pinions for the consensus process. To many this might seem like a silly question, but the chairs believe the problem is well enough understood by those actively involved WG participants so we would like to confirm this understanding. The chairs will also use to the determine the informed pool of WG participants. Question #2 (hum) Do you believe we need an MTI codec to avoid negotiation failures? Previous attempts at determining the MTI did not yield a result but did confirm that there is a desire for an MTI to avoid negotiation failures. Recently, some on the mailing list have expressed an interest in postponing this discussion until after IETF 91. The purpose of this question is to reconfirm the original consensus. Question #3 (open mic) Are there any codecs that were not included in the previous consensus calls= that warrant consideration? If yes, which one and why. The assumption is that the viable codecs are a) VP8, b) H.264, or c) VP8 and H.264. This is based on the extensive poll results from the last consensus calls. But time has passed so we need to entertain the ever so slight possibility that another codec has miraculously appeared. Remember, we want to ensure we're going to get maximum interoperability. Question #4 (open mic) Are there any new or unaddressed technical issues that will not allow us to= narrow the field to VP8 and H.264? We do not want to revisit previous discussions; we only want new or unaddressed technical issues and will throttle the discussion accordingly. We'll rely on WG participants and our former RAI AD (Mr. Sparks) for help in this area. We believe the technical discussion will fall into two buckets: - New or unresolved technical points. - Licensing. WRT licensing, the IETF tries not discuss whether IPR is valid, but an IPR issue that can be used as input to the decision making process is if enough people say they can't/won't implement because of the IPR. Question #5 (hum) With respect to the MTI codec: - Who can live with a requirement that WebRTC User Agents MUST support both VP8 and H.264 and WebRTC devices MUST support either VP8 or H.264? - Who can live with a requirement that all endpoints MUST support VP8? - Who can live with a requirement that all endpoints MUST support H.264= ? Thanks for your time, t/c/s _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net _______________________________________________ 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 -- Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard * _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda --_000_949EF20990823C4C85C18D59AA11AD8B2703CBFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Your statements about what the IE= TF should expect are somewhat different from the statements in RFC 3979. I = quote:
 
   In general, IETF working groups prefer technologies with no known I=
PR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

 
 
You are perfectly en=
titled to have your own personal view of what you desire, but please do not=
 equate your desires with IETF policy in this area.  

I'd also note you ar=
e making your own assumptions about the IPR encumbrance of various solution=
s, and those assumptions may not match those of other participants. IETF it=
self does not evaluate IPR encumbrance.


regards


 


Keith Drage

From: rtcweb [mailto:rtcweb-bounces= @ietf.org] On Behalf Of Daniel-Constantin Mierla
Sent: 04 November 2014 13:09
To: Alexandre GOUAILLARD; Matthew Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how t= o ask them)

If there are groups of people willing to discuss the evolution of the surro= unding environment around video codecs, that's their time, can be done anyw= here at their wish.

Related to the substance of webrtc MTI, there is nothing new out there rele= vant to the video codecs constraints. No change from MPEG-LA on H.264 costs= and restrictions for use freely by everyone (including the open source spa= ce), as expected when having to implement an open standard from IETF. No final decisions on patent claims = to VP8.

Let's hope soon there will be news about:
- MPEG-LA makes H.264 completely free
- VP8 pattent claims get to a final decision in court, so either they are d= ismissed there or they can be dealt differently
- a new completely free video codec shows up

I expect IETF is going to stand against monopolistic trends and particular = business interests, being the standardization body for open protocols in an= open internet. It is no excuse to release/propose IETF standards that forc= e someone either to pay to or be tracked by specific group of interests.

Let's not forget that not so many years ago there were completely different= communication means -- under monopoly, with high costs and very rigid -- w= ithout open standards with no barriers for anyone, the level of innovation = we benefited in the past years wouldn't have happened.

Daniel


On 04/11/14 06:44, Alexandre GOUAILLARD wrot= e:
Apple had 264, but there was no API to make 264 HW acceler= ation available to developers. It was mentioned as one of the reason why ci= sco open264 felt short of addressing some concerns voiced in the MTI pool. = the iOS 8's 264 API changed this.

In any case, I support the chair decision to try to revisit the questi= on.

On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman= <matthew@matthew.at> wrote:
A "substantive change" = would be *any* of the parties who participate in these discussions having a= different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention to s= hip an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring VP8= and some future even more free codec that isn't yet shipped, is reluctantl= y supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that H.264 i= f they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their support for VP8 and full= y back H.264 for real-time communications on the web" announcement? Or= the "Microsoft open-sources Internet Explorer, adds native VP8 to Win= dows" announcement? Or the "MPEG-LA drops all fees for H.264 encoding and decoding" announcement? Or really *anything* t= hat substantially changes things from where we were six months ago?

I don't get the desire to spend time on this topic... and I especially don'= t understand the call to pack as many people into a room as possible to con= duct a hum, when the outcome will need to be discussed and confirmed on the= list anyway.

Matthew Kaufman


On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
Matthew,

You wrote:
"I= 'm going to ask what I asked when I first saw this on the agenda: What has = substantively changed since then?

As far as I = can tell, nothing.:

Actuall= y several things have substantively changed since then. The list includes b= ut is not limited to:

* Cisco= shipped its H264 open source and binary module
* Firef= ox is using the Cisco binary module and as such Firefox now supports both H= 264 and VP8
* IOS8 = has shipped with API support for H264 (you may recall that lack of a soluti= on for H264 on IOS was an objection many had regarding the Cisco h264 binar= y module solution; this is now addressed)
* there= has been progress in the ongoing legal proceedings around VP8
* there= are new IPR statements regarding VP8 in ongoing standards processes=


I think this is far beyond "noth= ing". And given the importance of this topic to progress on adoption o= f webRTC, it warrants discussion at the mic.

-Jonathan R.


On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestran= d <harald@alvestrand.no> wrote:
Hm.

I don’t think there’s much value in revisiting the “one c= odec” alternatives. We tried that, and know that we found no consensu= s. Nobody’s changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. = Accepting “either” means that there will be 2 groups of them, a= nd they need a gateway to talk to each other, even when they can all talk t= o all compatible browsers. Having an MTI would be better - but one purpose of the “device” category is to all= ow fully compliant devices that don’t need the kind of corporate back= ing a browser needs - which means that licensed codecs are an issue. WeR= 17;ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever= they want.

But still, it seems that there’s a chance that discussing this again = is worth it. We might find an agreement this time.

Harald




On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which c=
odec(s) should be  MTI.  The issue has been on hold for over 6 months and t=
he original plan to was the re-attempt determining consensus at the IETF 91=
.  To make the best use of the WG’s face-to-face time at IETF 91, we =
want to give the WG ample time to digest/discuss the questions the chairs i=
ntend to ask the WG concerning the MTI codec (or codecs).  We want to know =
before the meeting whether to ask the questions and then what questions to =
ask - in other words we want to inform the WG of the questions before the W=
G session so as to not waste time debating what questions should be asked.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that con=
sensus process for this question. If you're here to read email or watch the=
 show, we want to know that your sitting throughout this isn't expressing o=
pinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants. =20

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls=
 that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we’re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to=
 narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We’ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can’t/won’t implement because of the IP=
R.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264=
?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Surveillance is pervasive. Go Dark.

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



-- 


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


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



--
Alex. Gouaillard, PhD, PhD, MBA
----------------------------------------------------------------------= --------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
----------------------------------------------------------------------= --------------



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


--=20
Daniel-Constantin Mierla
h=
ttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda<=
/a>
--_000_949EF20990823C4C85C18D59AA11AD8B2703CBFR712WXCHMBA11zeu_-- From nobody Tue Nov 4 06:45:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301231A8937 for ; Tue, 4 Nov 2014 06:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTH7dN24EzOY for ; Tue, 4 Nov 2014 06:45:25 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.205.23]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D281A8949 for ; Tue, 4 Nov 2014 06:45:25 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id BCD15FAB5D42F; Tue, 4 Nov 2014 08:45:24 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id A52CDFAB5D3B7 for ; Tue, 4 Nov 2014 08:45:24 -0600 (CST) Received: from [173.73.121.234] (port=52068 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XlfMJ-0007H0-TV; Tue, 04 Nov 2014 08:45:24 -0600 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Tue, 4 Nov 2014 09:45:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <872C77E0-99B3-4BBB-9F07-FD371CF6AD5C@ieca.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <494EFF62-0914-44B3-9073-F49858293347@gmail.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.234 X-Exim-ID: 1XlfMJ-0007H0-TV X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [173.73.121.234]:52068 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Wc1He8HhJ-L104w1dW9_2Cv62wc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 14:45:26 -0000 On Nov 03, 2014, at 19:27, Cullen Jennings (fluffy) = wrote: >=20 > On Nov 3, 2014, at 5:08 PM, Bernard Aboba = wrote: >=20 >> The questions below do not make it clear whether we are revisiting = the MTI video codec issue or whether in addition the audio codec issue = (on which we reached consensus) is also being reconsidered. Please = clarify. >>=20 >=20 > Bernard, I think I can safely say the chairs were only thinking about = the video codec when this was written and that should have been clear on = that.=20 >=20 > That said, there was consensus on 711 and opus being MTI but I think = we would need to check carefully the status of if there was consensus = that no other audio codecs would be be MTI. But this email was really = meant to be about the video codecs.=20 Definitely just about the video codecs. spt= From nobody Tue Nov 4 06:55:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D281A895C for ; Tue, 4 Nov 2014 06:55:30 -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 uPeSXNYNKeZ4 for ; Tue, 4 Nov 2014 06:55:25 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B181A020B for ; Tue, 4 Nov 2014 06:55:24 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id n15so1092328lbi.18 for ; Tue, 04 Nov 2014 06:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=jc4YgEwrvdvAbR6R94/E8uTnhiiuHIvs+soRJ9JVf64=; b=kazAZjzhBRbl+qWHudSTSjrVph1bmyM+aWRfKgeNWJ4Kc9Wj73BlQX7DEmKm6y67x2 Q7INTkaLyKVD3iwr7Pq1JhMyivcT/dGInkFIbaU/MR53Mq7HI9ELsQfr5PCMts4CTJyU PEv6DbIhyX9JE1sSQrW4BPmX+uqOApwZQEIQ0JFXgh9WjON0SQ05q3uyXU5hnTLnwxEZ 27KXDtAmHAckAozLo2R6K1cfWoUtbp7C4hIZfDTX6ux8800Za9O69jx9Nmoqdwcz+qle NsDhfw61B+35KiNZa8TJeh4UV5ITDZvPI9I/NpDnMh2qa/0trqtNQSq1TFjDBWPRtAFJ OCfg== X-Received: by 10.153.7.107 with SMTP id db11mr60318535lad.35.1415112922187; Tue, 04 Nov 2014 06:55:22 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id dw2sm240889lbc.38.2014.11.04.06.55.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 06:55:21 -0800 (PST) Message-ID: <5458E8D6.6090809@gmail.com> Date: Tue, 04 Nov 2014 15:55:18 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Alexandre GOUAILLARD , Matthew Kaufman References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> <545844CC.5010000@matthew.at> <5458CFDC.4020401@gmail.com> <949EF20990823C4C85C18D59AA11AD8B2703CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B2703CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------040007020005090503060501" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GGAhjO_IoDUE4tlZF56NvXNPUCc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:55:30 -0000 This is a multi-part message in MIME format. --------------040007020005090503060501 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I don't find anything contrary to the RFC paragraph you refer to. No technology (video codec in this case) is superior enough to the other for taking that in consideration (there were results from tests over tests and re-tests done by various entities), nothing changed, so this is not an excuse/reason to be considered. I did use 'I' not 'IETF' for my opinions, there is no 'equate' but 'expect'. Also, no IPR assumptions, just stated that nothing relevant changed related to them, given the conclusions from the past discussions. I did read most of the RFCs out there and worked for the past almost 15 years with the specs from IETF, therefore to be clear, my 'expect' comes from how IETF worked so far and I hope the future activity still tries to follow the 'preferred' guidelines rather than the 'exceptions'. Those being said, unless you can point case by case the specific parts in my initial opinions, I don't really get what you targeted with your answer. Daniel On 04/11/14 15:03, DRAGE, Keith (Keith) wrote: > Your statements about what the IETF should expect are somewhat > different from the statements in RFC 3979. I quote: > > In general, IETF working groups prefer technologies with no known IPR > claims or, for technologies with claims against them, an offer of > royalty-free licensing. But IETF working groups have the discretion > to adopt technology with a commitment of fair and non-discriminatory > terms, or even with no licensing commitment, if they feel that this > technology is superior enough to alternatives with fewer IPR claims > or free licensing to outweigh the potential cost of the licenses. > > You are perfectly entitled to have your own personal view of what you desire, but please do not equate your desires with IETF policy in this area. > I'd also note you are making your own assumptions about the IPR encumbrance of various solutions, and those assumptions may not match those of other participants. IETF itself does not evaluate IPR encumbrance. > regards > > Keith Drage > > ------------------------------------------------------------------------ > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of > *Daniel-Constantin Mierla > *Sent:* 04 November 2014 13:09 > *To:* Alexandre GOUAILLARD; Matthew Kaufman > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] The MTI Codec Questions (what to ask and > how to ask them) > > If there are groups of people willing to discuss the evolution of > the surrounding environment around video codecs, that's their > time, can be done anywhere at their wish. > > Related to the substance of webrtc MTI, there is nothing new out > there relevant to the video codecs constraints. No change from > MPEG-LA on H.264 costs and restrictions for use freely by everyone > (including the open source space), as expected when having to > implement an open standard from IETF. No final decisions on patent > claims to VP8. > > Let's hope soon there will be news about: > - MPEG-LA makes H.264 completely free > - VP8 pattent claims get to a final decision in court, so either > they are dismissed there or they can be dealt differently > - a new completely free video codec shows up > > I expect IETF is going to stand against monopolistic trends and > particular business interests, being the standardization body for > open protocols in an open internet. It is no excuse to > release/propose IETF standards that force someone either to pay to > or be tracked by specific group of interests. > > Let's not forget that not so many years ago there were completely > different communication means -- under monopoly, with high costs > and very rigid -- without open standards with no barriers for > anyone, the level of innovation we benefited in the past years > wouldn't have happened. > > Daniel > > > On 04/11/14 06:44, Alexandre GOUAILLARD wrote: >> Apple had 264, but there was no API to make 264 HW acceleration >> available to developers. It was mentioned as one of the reason >> why cisco open264 felt short of addressing some concerns voiced >> in the MTI pool. the iOS 8's 264 API changed this. >> >> In any case, I support the chair decision to try to revisit the >> question. >> >> On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman >> > wrote: >> >> A "substantive change" would be *any* of the parties who >> participate in these discussions having a different position >> than before. >> >> Yes, Cisco, who already supported H.264 and had announced an >> intention to ship an open source and binary module, shipped >> H.264. >> >> And Firefox, reluctant supporter of H.264 when available but >> preferring VP8 and some future even more free codec that >> isn't yet shipped, is reluctantly supporting H.264 when >> available. >> >> And iOS 8 has H.264, but of course Apple already had access >> to that H.264 if they were to put WEBRTC into their browser... >> >> Etc. >> >> Where's the "Google has decided to pull their support for VP8 >> and fully back H.264 for real-time communications on the web" >> announcement? Or the "Microsoft open-sources Internet >> Explorer, adds native VP8 to Windows" announcement? Or the >> "MPEG-LA drops all fees for H.264 encoding and decoding" >> announcement? Or really *anything* that substantially changes >> things from where we were six months ago? >> >> I don't get the desire to spend time on this topic... and I >> especially don't understand the call to pack as many people >> into a room as possible to conduct a hum, when the outcome >> will need to be discussed and confirmed on the list anyway. >> >> Matthew Kaufman >> >> >> On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote: >>> Matthew, >>> >>> You wrote: >>> "I'm going to ask what I asked when I first saw this on the >>> agenda: What has substantively changed since then? >>> >>> As far as I can tell, nothing.: >>> >>> Actually several things have substantively changed since >>> then. The list includes but is not limited to: >>> >>> * Cisco shipped its H264 open source and binary module >>> * Firefox is using the Cisco binary module and as such >>> Firefox now supports both H264 and VP8 >>> * IOS8 has shipped with API support for H264 (you may recall >>> that lack of a solution for H264 on IOS was an objection >>> many had regarding the Cisco h264 binary module solution; >>> this is now addressed) >>> * there has been progress in the ongoing legal proceedings >>> around VP8 >>> * there are new IPR statements regarding VP8 in ongoing >>> standards processes >>> >>> >>> I think this is far beyond "nothing". And given the >>> importance of this topic to progress on adoption of webRTC, >>> it warrants discussion at the mic. >>> >>> -Jonathan R. >>> >>> >>> On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand >>> > wrote: >>> >>> Hm. >>> >>> I don’t think there’s much value in revisiting the “one >>> codec” alternatives. We tried that, and know that we >>> found no consensus. Nobody’s changed their minds. >>> >>> It would be very sad if we give up on interoperability >>> for WebRTC devices. Accepting “either” means that there >>> will be 2 groups of them, and they need a gateway to >>> talk to each other, even when they can all talk to all >>> compatible browsers. Having an MTI would be better - but >>> one purpose of the “device” category is to allow fully >>> compliant devices that don’t need the kind of corporate >>> backing a browser needs - which means that licensed >>> codecs are an issue. We’ve had that discussion before. >>> >>> Of course, WebRTC-compatible devices (as currently >>> defined) can do whatever they want. >>> >>> But still, it seems that there’s a chance that >>> discussing this again is worth it. We might find an >>> agreement this time. >>> >>> Harald >>> >>> >>> >>> >>> On 11/03/2014 03:32 PM, Sean Turner wrote: >>>> All, >>>> >>>> One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be MTI. The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91. To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs). We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked. >>>> >>>> Without further ado, these are the proposed questions: >>>> >>>> Question #0 (hum) >>>> >>>> Do you want to discuss this issue at this meeting? >>>> >>>> Question #1 (stand up) >>>> >>>> Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process. >>>> >>>> To many this might seem like a silly question, >>>> but the chairs believe the problem is well enough >>>> understood by those actively involved WG >>>> participants so we would like to confirm this >>>> understanding. The chairs will also use to the >>>> determine the informed pool of WG participants. >>>> >>>> Question #2 (hum) >>>> >>>> Do you believe we need an MTI codec to avoid negotiation failures? >>>> >>>> Previous attempts at determining the MTI did not >>>> yield a result but did confirm that there is a desire >>>> for an MTI to avoid negotiation failures. Recently, >>>> some on the mailing list have expressed an interest >>>> in postponing this discussion until after IETF 91. The >>>> purpose of this question is to reconfirm the original >>>> consensus. >>>> >>>> Question #3 (open mic) >>>> >>>> Are there any codecs that were not included in the previous consensus calls that warrant consideration? If yes, which one and why. >>>> >>>> The assumption is that the viable codecs are a) VP8, >>>> b) H.264, or c) VP8 and H.264. This is based on the >>>> extensive poll results from the last consensus calls. >>>> But time has passed so we need to entertain the ever >>>> so slight possibility that another codec has miraculously >>>> appeared. Remember, we want to ensure we’re going >>>> to get maximum interoperability. >>>> >>>> Question #4 (open mic) >>>> >>>> Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264? >>>> >>>> We do not want to revisit previous discussions; we only >>>> want new or unaddressed technical issues and will throttle >>>> the discussion accordingly. We’ll rely on WG participants >>>> and our former RAI AD (Mr. Sparks) for help in this area. >>>> >>>> We believe the technical discussion will fall into two >>>> buckets: >>>> - New or unresolved technical points. >>>> - Licensing. WRT licensing, the IETF tries not discuss >>>> whether IPR is valid, but an IPR issue that can be used >>>> as input to the decision making process is if enough >>>> people say they can’t/won’t implement because of the IPR. >>>> >>>> Question #5 (hum) >>>> >>>> With respect to the MTI codec: >>>> - Who can live with a requirement that WebRTC User Agents >>>> MUST support both VP8 and H.264 and WebRTC devices >>>> MUST support either VP8 or H.264? >>>> - Who can live with a requirement that all endpoints MUST support VP8? >>>> - Who can live with a requirement that all endpoints MUST support H.264? >>>> >>>> Thanks for your time, >>>> t/c/s >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> >>> >>> -- >>> Jonathan Rosenberg, Ph.D. >>> jdrosen@jdrosen.net >>> http://www.jdrosen.net >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> -- >> Alex. Gouaillard, PhD, PhD, MBA >> ------------------------------------------------------------------------------------ >> CTO - Temasys Communications, S'pore / Mountain View >> President - CoSMo Software, Cambridge, MA >> ------------------------------------------------------------------------------------ >> sg.linkedin.com/agouaillard >> >> * >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com --------------040007020005090503060501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I don't find anything contrary to the RFC paragraph you refer to. No technology (video codec in this case) is superior enough to the other for taking that in consideration (there were results from tests over tests and re-tests done by various entities), nothing changed, so this is not an excuse/reason to be considered. I did use 'I' not 'IETF' for my opinions, there is no 'equate' but 'expect'. Also, no IPR assumptions, just stated that nothing relevant changed related to them, given the conclusions from the past discussions.

I did read most of the RFCs out there and worked for the past almost 15 years with the specs from IETF, therefore to be clear, my 'expect' comes from how IETF worked so far and I hope the future activity still tries to follow the 'preferred' guidelines rather than the 'exceptions'.

Those being said, unless you can point case by case the specific parts in my initial opinions, I don't really get what you targeted with your answer.

Daniel

On 04/11/14 15:03, DRAGE, Keith (Keith) wrote:
Your statements about what the IETF should expect are somewhat different from the statements in RFC 3979. I quote:
 
   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

 
 
You are perfectly entitled to have your own personal view of what you desire, but please do not equate your desires with IETF policy in this area.  
I'd also note you are making your own assumptions about the IPR encumbrance of various solutions, and those assumptions may not match those of other participants. IETF itself does not evaluate IPR encumbrance.
regards
 
Keith Drage

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Daniel-Constantin Mierla
Sent: 04 November 2014 13:09
To: Alexandre GOUAILLARD; Matthew Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)

If there are groups of people willing to discuss the evolution of the surrounding environment around video codecs, that's their time, can be done anywhere at their wish.

Related to the substance of webrtc MTI, there is nothing new out there relevant to the video codecs constraints. No change from MPEG-LA on H.264 costs and restrictions for use freely by everyone (including the open source space), as expected when having to implement an open standard from IETF. No final decisions on patent claims to VP8.

Let's hope soon there will be news about:
- MPEG-LA makes H.264 completely free
- VP8 pattent claims get to a final decision in court, so either they are dismissed there or they can be dealt differently
- a new completely free video codec shows up

I expect IETF is going to stand against monopolistic trends and particular business interests, being the standardization body for open protocols in an open internet. It is no excuse to release/propose IETF standards that force someone either to pay to or be tracked by specific group of interests.

Let's not forget that not so many years ago there were completely different communication means -- under monopoly, with high costs and very rigid -- without open standards with no barriers for anyone, the level of innovation we benefited in the past years wouldn't have happened.

Daniel


On 04/11/14 06:44, Alexandre GOUAILLARD wrote:
Apple had 264, but there was no API to make 264 HW acceleration available to developers. It was mentioned as one of the reason why cisco open264 felt short of addressing some concerns voiced in the MTI pool. the iOS 8's 264 API changed this.

In any case, I support the chair decision to try to revisit the question.

On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman <matthew@matthew.at> wrote:
A "substantive change" would be *any* of the parties who participate in these discussions having a different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention to ship an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring VP8 and some future even more free codec that isn't yet shipped, is reluctantly supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that H.264 if they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their support for VP8 and fully back H.264 for real-time communications on the web" announcement? Or the "Microsoft open-sources Internet Explorer, adds native VP8 to Windows" announcement? Or the "MPEG-LA drops all fees for H.264 encoding and decoding" announcement? Or really *anything* that substantially changes things from where we were six months ago?

I don't get the desire to spend time on this topic... and I especially don't understand the call to pack as many people into a room as possible to conduct a hum, when the outcome will need to be discussed and confirmed on the list anyway.

Matthew Kaufman


On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
Matthew,

You wrote:
"I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then?

As far as I can tell, nothing.:

Actually several things have substantively changed since then. The list includes but is not limited to:

* Cisco shipped its H264 open source and binary module
* Firefox is using the Cisco binary module and as such Firefox now supports both H264 and VP8
* IOS8 has shipped with API support for H264 (you may recall that lack of a solution for H264 on IOS was an objection many had regarding the Cisco h264 binary module solution; this is now addressed)
* there has been progress in the ongoing legal proceedings around VP8
* there are new IPR statements regarding VP8 in ongoing standards processes


I think this is far beyond "nothing". And given the importance of this topic to progress on adoption of webRTC, it warrants discussion at the mic.

-Jonathan R.


On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
Hm.

I don’t think there’s much value in revisiting the “one codec” alternatives. We tried that, and know that we found no consensus. Nobody’s changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. Accepting “either” means that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the “device” category is to allow fully compliant devices that don’t need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We’ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there’s a chance that discussing this again is worth it. We might find an agreement this time.

Harald




On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which codec(s) should be  MTI.  The issue has been on hold for over 6 months and the original plan to was the re-attempt determining consensus at the IETF 91.  To make the best use of the WG’s face-to-face time at IETF 91, we want to give the WG ample time to digest/discuss the questions the chairs intend to ask the WG concerning the MTI codec (or codecs).  We want to know before the meeting whether to ask the questions and then what questions to ask - in other words we want to inform the WG of the questions before the WG session so as to not waste time debating what questions should be asked.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that consensus process for this question. If you're here to read email or watch the show, we want to know that your sitting throughout this isn't expressing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants.  

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we’re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We’ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can’t/won’t implement because of the IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.

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




-- 


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


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




--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------



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


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com
--------------040007020005090503060501-- From nobody Tue Nov 4 07:17:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694431A8983 for ; Tue, 4 Nov 2014 07:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kjnF1XhQpmD for ; Tue, 4 Nov 2014 07:17:11 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B131A8978 for ; Tue, 4 Nov 2014 07:17:10 -0800 (PST) Received: from mail-pa0-f50.google.com ([209.85.220.50]:39427) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xlfqz-0003Rv-0q for rtcweb@ietf.org; Tue, 04 Nov 2014 10:17:09 -0500 Received: by mail-pa0-f50.google.com with SMTP id eu11so14474900pac.23 for ; Tue, 04 Nov 2014 07:17:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.184.47 with SMTP id er15mr50142103pac.5.1415114223150; Tue, 04 Nov 2014 07:17:03 -0800 (PST) Received: by 10.70.23.36 with HTTP; Tue, 4 Nov 2014 07:17:03 -0800 (PST) In-Reply-To: <5458E8D6.6090809@gmail.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> <545844CC.5010000@matthew.at> <5458CFDC.4020401@gmail.com> <949EF20990823C4C85C18D59AA11AD8B2703CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5458E8D6.6090809@gmail.com> Date: Tue, 4 Nov 2014 10:17:03 -0500 Message-ID: From: Jonathan Rosenberg To: miconda@gmail.com Content-Type: multipart/alternative; boundary=047d7bdc9c8696cbc7050709f434 X-OutGoing-Spam-Status: No, score=0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nv-KJGeqv49RzdBeszHqfAeHIGg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 15:17:16 -0000 --047d7bdc9c8696cbc7050709f434 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Matthew, You wrote: "A "substantive change" would be *any* of the parties who participate in these discussions having a different position than before." Let us not forget that this working group is a large set of people, many of whom are not amongst the frequent posters and/or highly opinionated folks on this and other threads. While the changes over the last year are unlikely to sway the opinions of those who are entrenched, they may make enough difference to folks in the middle. Enough, at least, for us to achieve rough consensus, since that is the best we can hope for. Given the importance of this issue to making webRTC viable in the market, and given the relatively low cost of running a brief discussion (updates only!) and hum at IETF, I see only a possibility of great progress and almost no negative costs to trying. -Jonathan R. On Tue, Nov 4, 2014 at 9:55 AM, Daniel-Constantin Mierla wrote: > I don't find anything contrary to the RFC paragraph you refer to. No > technology (video codec in this case) is superior enough to the other for > taking that in consideration (there were results from tests over tests an= d > re-tests done by various entities), nothing changed, so this is not an > excuse/reason to be considered. I did use 'I' not 'IETF' for my opinions, > there is no 'equate' but 'expect'. Also, no IPR assumptions, just stated > that nothing relevant changed related to them, given the conclusions from > the past discussions. > > I did read most of the RFCs out there and worked for the past almost 15 > years with the specs from IETF, therefore to be clear, my 'expect' comes > from how IETF worked so far and I hope the future activity still tries to > follow the 'preferred' guidelines rather than the 'exceptions'. > > Those being said, unless you can point case by case the specific parts in > my initial opinions, I don't really get what you targeted with your answe= r. > > Daniel > > > On 04/11/14 15:03, DRAGE, Keith (Keith) wrote: > > Your statements about what the IETF should expect are somewhat different > from the statements in RFC 3979. I quote: > > > In general, IETF working groups prefer technologies with no known IPR > claims or, for technologies with claims against them, an offer of > royalty-free licensing. But IETF working groups have the discretion > to adopt technology with a commitment of fair and non-discriminatory > terms, or even with no licensing commitment, if they feel that this > technology is superior enough to alternatives with fewer IPR claims > or free licensing to outweigh the potential cost of the licenses. > > > > You are perfectly entitled to have your own personal view of what you de= sire, but please do not equate your desires with IETF policy in this area. > > I'd also note you are making your own assumptions about the IPR encumbran= ce of various solutions, and those assumptions may not match those of other= participants. IETF itself does not evaluate IPR encumbrance. > > regards > > > > Keith Drage > > > ------------------------------ > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Daniel-Constantin Mierla > *Sent:* 04 November 2014 13:09 > *To:* Alexandre GOUAILLARD; Matthew Kaufman > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] The MTI Codec Questions (what to ask and how to > ask them) > > If there are groups of people willing to discuss the evolution of the > surrounding environment around video codecs, that's their time, can be do= ne > anywhere at their wish. > > Related to the substance of webrtc MTI, there is nothing new out there > relevant to the video codecs constraints. No change from MPEG-LA on H.264 > costs and restrictions for use freely by everyone (including the open > source space), as expected when having to implement an open standard from > IETF. No final decisions on patent claims to VP8. > > Let's hope soon there will be news about: > - MPEG-LA makes H.264 completely free > - VP8 pattent claims get to a final decision in court, so either they are > dismissed there or they can be dealt differently > - a new completely free video codec shows up > > I expect IETF is going to stand against monopolistic trends and particula= r > business interests, being the standardization body for open protocols in = an > open internet. It is no excuse to release/propose IETF standards that for= ce > someone either to pay to or be tracked by specific group of interests. > > Let's not forget that not so many years ago there were completely > different communication means -- under monopoly, with high costs and very > rigid -- without open standards with no barriers for anyone, the level of > innovation we benefited in the past years wouldn't have happened. > > Daniel > > > On 04/11/14 06:44, Alexandre GOUAILLARD wrote: > > Apple had 264, but there was no API to make 264 HW acceleration available > to developers. It was mentioned as one of the reason why cisco open264 fe= lt > short of addressing some concerns voiced in the MTI pool. the iOS 8's 264 > API changed this. > > In any case, I support the chair decision to try to revisit the question= . > > On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman > wrote: > >> A "substantive change" would be *any* of the parties who participate in >> these discussions having a different position than before. >> >> Yes, Cisco, who already supported H.264 and had announced an intention t= o >> ship an open source and binary module, shipped H.264. >> >> And Firefox, reluctant supporter of H.264 when available but preferring >> VP8 and some future even more free codec that isn't yet shipped, is >> reluctantly supporting H.264 when available. >> >> And iOS 8 has H.264, but of course Apple already had access to that H.26= 4 >> if they were to put WEBRTC into their browser... >> >> Etc. >> >> Where's the "Google has decided to pull their support for VP8 and fully >> back H.264 for real-time communications on the web" announcement? Or the >> "Microsoft open-sources Internet Explorer, adds native VP8 to Windows" >> announcement? Or the "MPEG-LA drops all fees for H.264 encoding and >> decoding" announcement? Or really *anything* that substantially changes >> things from where we were six months ago? >> >> I don't get the desire to spend time on this topic... and I especially >> don't understand the call to pack as many people into a room as possible= to >> conduct a hum, when the outcome will need to be discussed and confirmed = on >> the list anyway. >> >> Matthew Kaufman >> >> >> On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote: >> >> Matthew, >> >> You wrote: >> "I'm going to ask what I asked when I first saw this on the agenda: What >> has substantively changed since then? >> >> As far as I can tell, nothing.: >> >> Actually several things have substantively changed since then. The list >> includes but is not limited to: >> >> * Cisco shipped its H264 open source and binary module >> * Firefox is using the Cisco binary module and as such Firefox now >> supports both H264 and VP8 >> * IOS8 has shipped with API support for H264 (you may recall that lack o= f >> a solution for H264 on IOS was an objection many had regarding the Cisco >> h264 binary module solution; this is now addressed) >> * there has been progress in the ongoing legal proceedings around VP8 >> * there are new IPR statements regarding VP8 in ongoing standards >> processes >> >> >> I think this is far beyond "nothing". And given the importance of this >> topic to progress on adoption of webRTC, it warrants discussion at the m= ic. >> >> -Jonathan R. >> >> >> On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand >> wrote: >> >>> Hm. >>> >>> I don=E2=80=99t think there=E2=80=99s much value in revisiting the =E2= =80=9Cone codec=E2=80=9D >>> alternatives. We tried that, and know that we found no consensus. Nobod= y=E2=80=99s >>> changed their minds. >>> >>> It would be very sad if we give up on interoperability for WebRTC >>> devices. Accepting =E2=80=9Ceither=E2=80=9D means that there will be 2 = groups of them, and >>> they need a gateway to talk to each other, even when they can all talk = to >>> all compatible browsers. Having an MTI would be better - but one purpos= e of >>> the =E2=80=9Cdevice=E2=80=9D category is to allow fully compliant devic= es that don=E2=80=99t need >>> the kind of corporate backing a browser needs - which means that licens= ed >>> codecs are an issue. We=E2=80=99ve had that discussion before. >>> >>> Of course, WebRTC-compatible devices (as currently defined) can do >>> whatever they want. >>> >>> But still, it seems that there=E2=80=99s a chance that discussing this = again is >>> worth it. We might find an agreement this time. >>> >>> Harald >>> >>> >>> >>> >>> On 11/03/2014 03:32 PM, Sean Turner wrote: >>> >>> All, >>> >>> One of the remaining major technical decisions for the RTCweb WG is whi= ch codec(s) should be MTI. The issue has been on hold for over 6 months a= nd the original plan to was the re-attempt determining consensus at the IET= F 91. To make the best use of the WG=E2=80=99s face-to-face time at IETF 9= 1, we want to give the WG ample time to digest/discuss the questions the ch= airs intend to ask the WG concerning the MTI codec (or codecs). We want to= know before the meeting whether to ask the questions and then what questio= ns to ask - in other words we want to inform the WG of the questions before= the WG session so as to not waste time debating what questions should be a= sked. >>> >>> Without further ado, these are the proposed questions: >>> >>> Question #0 (hum) >>> >>> Do you want to discuss this issue at this meeting? >>> >>> Question #1 (stand up) >>> >>> Please stand (or signal in the jabber chat) if you will be part of that= consensus process for this question. If you're here to read email or watch= the show, we want to know that your sitting throughout this isn't expressi= ng opinions for the consensus process. >>> >>> To many this might seem like a silly question, >>> but the chairs believe the problem is well enough >>> understood by those actively involved WG >>> participants so we would like to confirm this >>> understanding. The chairs will also use to the >>> determine the informed pool of WG participants. >>> >>> Question #2 (hum) >>> >>> Do you believe we need an MTI codec to avoid negotiation failures? >>> >>> Previous attempts at determining the MTI did not >>> yield a result but did confirm that there is a desire >>> for an MTI to avoid negotiation failures. Recently, >>> some on the mailing list have expressed an interest >>> in postponing this discussion until after IETF 91. The >>> purpose of this question is to reconfirm the original >>> consensus. >>> >>> Question #3 (open mic) >>> >>> Are there any codecs that were not included in the previous consensus c= alls that warrant consideration? If yes, which one and why. >>> >>> The assumption is that the viable codecs are a) VP8, >>> b) H.264, or c) VP8 and H.264. This is based on the >>> extensive poll results from the last consensus calls. >>> But time has passed so we need to entertain the ever >>> so slight possibility that another codec has miraculously >>> appeared. Remember, we want to ensure we=E2=80=99re going >>> to get maximum interoperability. >>> >>> Question #4 (open mic) >>> >>> Are there any new or unaddressed technical issues that will not allow u= s to narrow the field to VP8 and H.264? >>> >>> We do not want to revisit previous discussions; we only >>> want new or unaddressed technical issues and will throttle >>> the discussion accordingly. We=E2=80=99ll rely on WG participants >>> and our former RAI AD (Mr. Sparks) for help in this area. >>> >>> We believe the technical discussion will fall into two >>> buckets: >>> - New or unresolved technical points. >>> - Licensing. WRT licensing, the IETF tries not discuss >>> whether IPR is valid, but an IPR issue that can be used >>> as input to the decision making process is if enough >>> people say they can=E2=80=99t/won=E2=80=99t implement because o= f the IPR. >>> >>> Question #5 (hum) >>> >>> With respect to the MTI codec: >>> - Who can live with a requirement that WebRTC User Agents >>> MUST support both VP8 and H.264 and WebRTC devices >>> MUST support either VP8 or H.264? >>> - Who can live with a requirement that all endpoints MUST support V= P8? >>> - Who can live with a requirement that all endpoints MUST support H= .264? >>> >>> Thanks for your time, >>> t/c/s >>> _______________________________________________ >>> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo= /rtcweb >>> >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> >> >> -- >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> >> >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/= rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > Alex. Gouaillard, PhD, PhD, MBA > > -------------------------------------------------------------------------= ----------- > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > > -------------------------------------------------------------------------= ----------- > sg.linkedin.com/agouaillard > > - > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linked= in.com/in/miconda > > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linked= in.com/in/miconda > > Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7bdc9c8696cbc7050709f434 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Matthew,

You wrote:
"A "substantiv= e change" would be *any* of the parties who participate in these discu= ssions having a different position than before."

Let us not f= orget that this working group is a large set of people, many of whom are no= t amongst the frequent posters and/or highly opinionated folks on this and = other threads. While the changes over the last year are unlikely to sway th= e opinions of those who are entrenched, they may make enough difference to = folks in the middle. Enough, at least, for us to achieve rough consensus, s= ince that is the best we can hope for.

Given the importance of this issue to making webRTC = viable in the market, and given the relatively low cost of running a brief = discussion (updates only!) and hum at IETF, I see only a possibility of gre= at progress and almost no negative costs to trying.

-Jonathan R.

On Tue, Nov 4, 2014 at 9:55 AM, Daniel-Constant= in Mierla <miconda@gmail.com> wrote:
=20 =20 =20
I don't find anything contrary to the RFC paragraph you refer to. N= o technology (video codec in this case) is superior enough to the other for taking that in consideration (there were results from tests over tests and re-tests done by various entities), nothing changed, so this is not an excuse/reason to be considered. I did use 'I' not 'IETF' for my opinions, there is no 'equate= ' but 'expect'. Also, no IPR assumptions, just stated that nothing relevant changed related to them, given the conclusions from the past discussions.

I did read most of the RFCs out there and worked for the past almost 15 years with the specs from IETF, therefore to be clear, my 'expect' comes from how IETF worked so far and I hope the futur= e activity still tries to follow the 'preferred' guidelines rathe= r than the 'exceptions'.

Those being said, unless you can point case by case the specific parts in my initial opinions, I don't really get what you targeted with your answer.

Daniel


On 04/11/14 15:03, DRAGE, Keith (Keith) wrote:
=20 =20
Your statements about what the IETF should expect are somewhat different from the statements in RFC 3979. I quote:
=C2=A0
   In general, IETF working groups prefer technologies with =
no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

=C2=A0
 
You are perfectly ent=
itled to have your own personal view of what you desire, but please do not =
equate your desires with IETF policy in this area.=C2=A0=C2=A0
I'd also note you=
 are making your own assumptions about the IPR encumbrance of various solut=
ions, and those assumptions may not match those of other participants. IETF=
 itself does not evaluate IPR encumbrance.
regards
=C2=A0
Keith Drage

From: rtcweb [m= ailto:rtcweb-bounces@ietf.org] On Behalf Of Daniel-Constantin Mierla
Sent: 04 November 2014 13:09
To: Alexandre GOUAILLARD; Matthew Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)

If there are groups of people willing to discuss the evolution of the surrounding environment around video codecs, that's thei= r time, can be done anywhere at their wish.

Related to the substance of webrtc MTI, there is nothing new out there relevant to the video codecs constraints. No change from MPEG-LA on H.264 costs and restrictions for use freely by everyone (including the open source space), as expected when having to implement an open standard from IETF. No final decisions on patent claims to VP8.

Let's hope soon there will be news about:
- MPEG-LA makes H.264 completely free
- VP8 pattent claims get to a final decision in court, so either they are dismissed there or they can be dealt differently
- a new completely free video codec shows up

I expect IETF is going to stand against monopolistic trends and particular business interests, being the standardization body for open protocols in an open internet. It is no excuse to release/propose IETF standards that force someone either to pay to or be tracked by specific group of interests.

Let's not forget that not so many years ago there were completely different communication means -- under monopoly, with high costs and very rigid -- without open standards with no barriers for anyone, the level of innovation we benefited in the past years wouldn't have happened.

Daniel


On 04/11/14 06:44, Alexandre GOUAILLARD wrote:
Apple had 264, but there was no API to make 264 HW acceleration available to developers. It was mentioned as one of the reason why cisco open264 felt short of addressing some concerns voiced in the MTI pool. the iOS 8's 264 API changed this.

In any case, I support the chair decision to try to revisit the question.

On Tue, Nov 4, 2014 at 11:15 AM, Matthew Kaufman <matthew@matthew.at> wrote:
A "substanti= ve change" would be *any* of the parties who participat= e in these discussions having a different position than before.

Yes, Cisco, who already supported H.264 and had announced an intention to ship an open source and binary module, shipped H.264.

And Firefox, reluctant supporter of H.264 when available but preferring VP8 and some future even more free codec that isn't yet shipped, is reluctantly supporting H.264 when available.

And iOS 8 has H.264, but of course Apple already had access to that H.264 if they were to put WEBRTC into their browser...

Etc.

Where's the "Google has decided to pull their su= pport for VP8 and fully back H.264 for real-time communications on the web" announcement? Or the "Microsoft open-sources Internet Explorer, adds nati= ve VP8 to Windows" announcement? Or the "MPEG-LA d= rops all fees for H.264 encoding and decoding" announcement? Or really *anything* that substantially changes things from where we were six months ago?

I don't get the desire to spend time on this topic... and I especially don't understand the call to pack as many people into a room as possible to conduct a hum, when the outcome will need to be discussed and confirmed on the list anyway.

Matthew Kaufman


On 11/3/14, 5:13 PM, Jonathan Rosenberg wrote:
Matthew,

You wrote:
"I'm going to ask what I asked when I first saw this on the agenda: What has substantively changed since then?

As far as I can tell, nothing.:

Actually several things have substantively changed since then. The list includes but is not limited to:

* Cisco shipped its H264 open source and binary module
* Firefox is using the Cisco binary module and as such Firefox now supports both H264 and VP8
* IOS8 has shipped with API support for H264 (you may recall that lack of a solution for H264 on IOS was an objection many had regarding the Cisco h264 binary module solution; this is now addressed)
* there has been progress in the ongoing legal proceedings around VP8
* there are new IPR statements regarding VP8 in ongoing standards processes


I think this is far beyond "nothing". And g= iven the importance of this topic to progress on adoption of webRTC, it warrants discussion at the mic.

-Jonathan R.


On Mon, Nov 3, 2014 at 8:02 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
Hm.

I don=E2=80=99t think there=E2=80=99s muc= h value in revisiting the =E2=80=9Cone codec=E2=80= =9D alternatives. We tried that, and know that we found no consensus. Nobody=E2=80= =99s changed their minds.

It would be very sad if we give up on interoperability for WebRTC devices. Accepting =E2=80=9Ceither=E2=80=9D means = that there will be 2 groups of them, and they need a gateway to talk to each other, even when they can all talk to all compatible browsers. Having an MTI would be better - but one purpose of the =E2=80=9Cdevice=E2=80=9D category is = to allow fully compliant devices that don=E2=80=99= t need the kind of corporate backing a browser needs - which means that licensed codecs are an issue. We=E2=80=99= ve had that discussion before.

Of course, WebRTC-compatible devices (as currently defined) can do whatever they want.

But still, it seems that there=E2=80=99s = a chance that discussing this again is worth it. We might find an agreement this time.

Harald




On 11/03/2014 03:32 PM, Sean Turner wrote:
All,

One of the remaining major technical decisions for the RTCweb WG is which c=
odec(s) should be  MTI.  The issue has been on hold for over 6 months and t=
he original plan to was the re-attempt determining consensus at the IETF 91=
.  To make the best use of the WG=E2=80=99s face-to-face time at IETF 91, w=
e want to give the WG ample time to digest/discuss the questions the chairs=
 intend to ask the WG concerning the MTI codec (or codecs).  We want to kno=
w before the meeting whether to ask the questions and then what questions t=
o ask - in other words we want to inform the WG of the questions before the=
 WG session so as to not waste time debating what questions should be asked=
.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that con=
sensus process for this question. If you're here to read email or watch=
 the show, we want to know that your sitting throughout this isn't expr=
essing opinions for the consensus process.

    To many this might seem like a silly question,
    but the chairs believe the problem is well enough
    understood by those actively involved WG
    participants so we would like to confirm this
    understanding.  The chairs will also use to the
    determine the informed pool of WG participants. =20

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

    Previous attempts at determining the MTI did not
    yield a result but did confirm that there is a desire
    for an MTI to avoid negotiation failures.   Recently,
    some on the mailing list have expressed an interest
    in postponing this discussion until after IETF 91.  The
    purpose of this question is to reconfirm the original
    consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls=
 that warrant consideration?  If yes, which one and why.

    The assumption is that the viable codecs are a) VP8,
    b) H.264, or c) VP8 and H.264.  This is based on the
    extensive poll results from the last consensus calls.
    But time has passed so we need to entertain the ever
    so slight possibility that another codec has miraculously
    appeared.  Remember, we want to ensure we=E2=80=99re going
    to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to=
 narrow the field to VP8 and H.264?

    We do not want to revisit previous discussions; we only
    want new or unaddressed technical issues and will throttle
    the discussion accordingly.  We=E2=80=99ll rely on WG participants
    and our former RAI AD (Mr. Sparks) for help in this area.

    We believe the technical discussion will fall into two
    buckets:
      - New or unresolved technical points.
      - Licensing.  WRT licensing, the IETF tries not discuss
        whether IPR is valid, but an IPR issue that can be used
        as input to the decision making process is if enough
        people say they can=E2=80=99t/won=E2=80=99t implement because of th=
e IPR.

Question #5 (hum)

With respect to the MTI codec:
    - Who can live with a requirement that WebRTC User Agents
      MUST support  both VP8 and H.264 and WebRTC devices
      MUST support  either VP8 or H.264?
    - Who can live with a requirement that all endpoints MUST support VP8?
    - Who can live with a requirement that all endpoints MUST support H.264=
?

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Surveillance is pervasive. Go Dark.

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




-- 


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


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




--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------= ------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------= ------------------------------



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


--=20
Daniel-Constantin Mierla
http://twitte=
r.com/#!/miconda - http://www.linkedin.com/in/miconda



Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com

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




--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net<= br>http://www.jdrosen.= net
--047d7bdc9c8696cbc7050709f434-- From nobody Tue Nov 4 07:24:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F491A89F0 for ; Tue, 4 Nov 2014 07:24:26 -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 qw1rmKef2OjG for ; Tue, 4 Nov 2014 07:24:23 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B1D1A89EB for ; Tue, 4 Nov 2014 07:24:23 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id rp18so7655944iec.40 for ; Tue, 04 Nov 2014 07:24: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=BfGixdWuRRKJlFo9RpiInC+67YYIJCMQa4EjGZLY+pA=; b=gCDjRNQ6Dfr8Z7pBuJoPKFMk/K6+VULTUo149qbclJw6JrmSf3hpQXGMJVN0iYQMnY zAxwhizsW5E2SRh4/i4DlMvMPigleDirgkHeXVv7tXUswcZHt8fYRekAr1bYNCv+zv/T LoJr3nS7huW1PiMvogbMFkv/2P0som9m6WJOuoFVjDSNAEH/AUOeFOP0+ZJWeEp1ox0r Dix7Qfjo1liznO1EcIJ4U7ntiTpVvaNKMkD5SMIFGDT0ueTtYDbqzAVBWeWHKo0jrild TwH73DNNxX5i13qtVrb77TWKW3ZXfO2fQDZssmGJvC2YRjZFHYR6fFcYw009EttXfGEN Xx0Q== X-Gm-Message-State: ALoCoQmFs74C79WUBmDrCj4VsBTtomGVhBWs9g6exxoGsIObLGKnMPSh7a9Bx+msBd5DZTnncDJ8 X-Received: by 10.107.12.222 with SMTP id 91mr3387316iom.71.1415114663054; Tue, 04 Nov 2014 07:24:23 -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 f20sm421148igz.13.2014.11.04.07.24.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Nov 2014 07:24:22 -0800 (PST) Message-ID: <5458EF94.2080901@bbs.darktech.org> Date: Tue, 04 Nov 2014 10:24:04 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54582599.6070806@alvestrand.no> <545844CC.5010000@matthew.at> <5458CFDC.4020401@gmail.com> <949EF20990823C4C85C18D59AA11AD8B2703CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5458E8D6.6090809@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040405080307020005090701" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aI3UUxZNfSZKDZlCKnHHqPz_lZU Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 15:24:26 -0000 This is a multi-part message in MIME format. --------------040405080307020005090701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/11/2014 10:17 AM, Jonathan Rosenberg wrote: > Matthew, > > You wrote: > "A "substantive change" would be *any* of the parties who participate > in these discussions having a different position than before." > > Let us not forget that this working group is a large set of people, > many of whom are not amongst the frequent posters and/or highly > opinionated folks on this and other threads. While the changes over > the last year are unlikely to sway the opinions of those who are > entrenched, they may make enough difference to folks in the middle. > Enough, at least, for us to achieve rough consensus, since that is the > best we can hope for. > > Given the importance of this issue to making webRTC viable in the > market, and given the relatively low cost of running a brief > discussion (updates only!) and hum at IETF, I see only a possibility > of great progress and almost no negative costs to trying. > > -Jonathan R. > I think Matthew is referring to "/Insanity/: doing the same thing over and over again and expecting different results."-Albert/Einstein/ :) I'd like to understand whether there has been any progress on friendlier licensing terms for H264 or a royalty-free profile. The H264 crowd made a lot of noise about these possibilities but nothing seems to have come out of them. If you want the community to adopt H264 over VP8, then you need to make some serious progress on these two points. Gili --------------040405080307020005090701 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 04/11/2014 10:17 AM, Jonathan Rosenberg wrote:
Matthew,

You wrote:
"A "substantive change" would be *any* of the parties who participate in these discussions having a different position than before."

Let us not forget that this working group is a large set of people, many of whom are not amongst the frequent posters and/or highly opinionated folks on this and other threads. While the changes over the last year are unlikely to sway the opinions of those who are entrenched, they may make enough difference to folks in the middle. Enough, at least, for us to achieve rough consensus, since that is the best we can hope for.

Given the importance of this issue to making webRTC viable in the market, and given the relatively low cost of running a brief discussion (updates only!) and hum at IETF, I see only a possibility of great progress and almost no negative costs to trying.

-Jonathan R.


I think Matthew is referring to "Insanity: doing the same thing over and over again and expecting different results." -Albert Einstein

:)

I'd like to understand whether there has been any progress on friendlier licensing terms for H264 or a royalty-free profile. The H264 crowd made a lot of noise about these possibilities but nothing seems to have come out of them.

If you want the community to adopt H264 over VP8, then you need to make some serious progress on these two points.

Gili
 --------------040405080307020005090701-- From nobody Tue Nov 4 07:46:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481C21A8A72 for ; Tue, 4 Nov 2014 07:46:04 -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 vVnl0CD4_ZuF for ; Tue, 4 Nov 2014 07:46:00 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029541A8A70 for ; Tue, 4 Nov 2014 07:46:00 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id mc6so1078253lab.40 for ; Tue, 04 Nov 2014 07:45:58 -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=rzT3hGf2QRvRqoiA6GawJXmnFIaKBD0jJMB1MDZD9jE=; b=NA7nwX3KhtqkyPIFKDFT+g4qR3LpSjQ+8SnbMgMpBP/+JFGQe+2Jot2amACV798SnX F/mxO8bX2G493iNzp0ocTERBTnGODZ1XsOpFV9BgV01c3AbSMU+UbI6GO2Maattsvk42 c2PU4JdU20CIah64D01QyEebyLrsRHMVr2MS182vFLsOp13Y6vBaeFL9VobJQCPBwXVM Ed8VGwMxXzhnDZyUGLLau8Zr4MB4LQNiff/s6Lkv4WyVoh9R4fpN1ue/5dO309aWpHbk tQgP4ah5VdpBJEybQhe2gnqaQLPENc1uuYvSsBQNxCjHV/ngKcMx+zeq+C6W0wmPlvag ajzQ== MIME-Version: 1.0 X-Received: by 10.112.85.138 with SMTP id h10mr60172901lbz.33.1415115958139; Tue, 04 Nov 2014 07:45:58 -0800 (PST) Received: by 10.25.42.134 with HTTP; Tue, 4 Nov 2014 07:45:57 -0800 (PST) In-Reply-To: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Date: Tue, 4 Nov 2014 09:45:57 -0600 Message-ID: From: Mary Barnes To: Sean Turner Content-Type: multipart/alternative; boundary=001a1134716800411905070a5c87 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0AlFpiJ9GJYvQ1HMvl13YbBrzkI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 15:46:04 -0000 --001a1134716800411905070a5c87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Comments below on the questions [MB]. Mary. On Mon, Nov 3, 2014 at 5:32 PM, Sean Turner wrote: > All, > > One of the remaining major technical decisions for the RTCweb WG is which > codec(s) should be MTI. The issue has been on hold for over 6 months an= d > the original plan to was the re-attempt determining consensus at the IETF > 91. To make the best use of the WG=E2=80=99s face-to-face time at IETF 9= 1, we want > to give the WG ample time to digest/discuss the questions the chairs inte= nd > to ask the WG concerning the MTI codec (or codecs). We want to know befo= re > the meeting whether to ask the questions and then what questions to ask - > in other words we want to inform the WG of the questions before the WG > session so as to not waste time debating what questions should be asked. > > Without further ado, these are the proposed questions: > > Question #0 (hum) > > Do you want to discuss this issue at this meeting? > [MB] I'll answer this now - NO. [/MB] > > Question #1 (stand up) > > Please stand (or signal in the jabber chat) if you will be part of that > consensus process for this question. If you're here to read email or watc= h > the show, we want to know that your sitting throughout this isn't > expressing opinions for the consensus process. > [MB] I'm assuming that even if one hums NO for the question above that one can still stand at this point? [/MB] > > To many this might seem like a silly question, > but the chairs believe the problem is well enough > understood by those actively involved WG > participants so we would like to confirm this > understanding. The chairs will also use to the > determine the informed pool of WG participants. > > Question #2 (hum) > > Do you believe we need an MTI codec to avoid negotiation failures? > > Previous attempts at determining the MTI did not > yield a result but did confirm that there is a desire > for an MTI to avoid negotiation failures. Recently, > some on the mailing list have expressed an interest > in postponing this discussion until after IETF 91. The > purpose of this question is to reconfirm the original > consensus. > > Question #3 (open mic) > > Are there any codecs that were not included in the previous consensus > calls that warrant consideration? If yes, which one and why. > > The assumption is that the viable codecs are a) VP8, > b) H.264, or c) VP8 and H.264. This is based on the > extensive poll results from the last consensus calls. > But time has passed so we need to entertain the ever > so slight possibility that another codec has miraculously > appeared. Remember, we want to ensure we=E2=80=99re going > to get maximum interoperability. > > Question #4 (open mic) > > Are there any new or unaddressed technical issues that will not allow us > to narrow the field to VP8 and H.264? > > We do not want to revisit previous discussions; we only > want new or unaddressed technical issues and will throttle > the discussion accordingly. We=E2=80=99ll rely on WG participants > and our former RAI AD (Mr. Sparks) for help in this area. > > We believe the technical discussion will fall into two > buckets: > - New or unresolved technical points. > - Licensing. WRT licensing, the IETF tries not discuss > whether IPR is valid, but an IPR issue that can be used > as input to the decision making process is if enough > people say they can=E2=80=99t/won=E2=80=99t implement because of = the IPR. > > Question #5 (hum) > > With respect to the MTI codec: > - Who can live with a requirement that WebRTC User Agents > MUST support both VP8 and H.264 and WebRTC devices > MUST support either VP8 or H.264? > - Who can live with a requirement that all endpoints MUST support VP8= ? > - Who can live with a requirement that all endpoints MUST support > H.264? > [MB] So, are you going to let people hum more than once? If so, I cannot see how the outcome will be any different than the last time we had this discussion. I didn't hum twice last time because it made no sense to me. I would hum for all of those and my guess is that many others are in the same boat. I was going to suggest you separate the questions under number 5, but I don't think that will change the outcome either. [/MB] > > Thanks for your time, > t/c/s > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1134716800411905070a5c87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Comments below on the questions [MB].

M= ary.

On Mon,= Nov 3, 2014 at 5:32 PM, Sean Turner <turners@ieca.com> wrote= :
All,

One of the remaining major technical decisions for the RTCweb WG is which c= odec(s) should be=C2=A0 MTI.=C2=A0 The issue has been on hold for over 6 mo= nths and the original plan to was the re-attempt determining consensus at t= he IETF 91.=C2=A0 To make the best use of the WG=E2=80=99s face-to-face tim= e at IETF 91, we want to give the WG ample time to digest/discuss the quest= ions the chairs intend to ask the WG concerning the MTI codec (or codecs).= =C2=A0 We want to know before the meeting whether to ask the questions and = then what questions to ask - in other words we want to inform the WG of the= questions before the WG session so as to not waste time debating what ques= tions should be asked.

Without further ado, these are the proposed questions:

Question #0 (hum)

Do you want to discuss this issue at this meeting?
[MB= ] I'll answer this now - NO. [/MB]=C2=A0

Question #1 (stand up)

Please stand (or signal in the jabber chat) if you will be part of that con= sensus process for this question. If you're here to read email or watch= the show, we want to know that your sitting throughout this isn't expr= essing opinions for the consensus process.
[MB] I'= m assuming that even if one hums NO for the question above that one can sti= ll stand at this point? =C2=A0 [/MB]=C2=A0

=C2=A0 =C2=A0 To many this might seem like a silly question,
=C2=A0 =C2=A0 but the chairs believe the problem is well enough
=C2=A0 =C2=A0 understood by those actively involved WG
=C2=A0 =C2=A0 participants so we would like to confirm this
=C2=A0 =C2=A0 understanding.=C2=A0 The chairs will also use to the
=C2=A0 =C2=A0 determine the informed pool of WG participants.

Question #2 (hum)

Do you believe we need an MTI codec to avoid negotiation failures?

=C2=A0 =C2=A0 Previous attempts at determining the MTI did not
=C2=A0 =C2=A0 yield a result but did confirm that there is a desire
=C2=A0 =C2=A0 for an MTI to avoid negotiation failures.=C2=A0 =C2=A0Recentl= y,
=C2=A0 =C2=A0 some on the mailing list have expressed an interest
=C2=A0 =C2=A0 in postponing this discussion until after IETF 91.=C2=A0 The<= br> =C2=A0 =C2=A0 purpose of this question is to reconfirm the original
=C2=A0 =C2=A0 consensus.

Question #3 (open mic)

Are there any codecs that were not included in the previous consensus calls= that warrant consideration?=C2=A0 If yes, which one and why.

=C2=A0 =C2=A0 The assumption is that the viable codecs are a) VP8,
=C2=A0 =C2=A0 b) H.264, or c) VP8 and H.264.=C2=A0 This is based on the
=C2=A0 =C2=A0 extensive poll results from the last consensus calls.
=C2=A0 =C2=A0 But time has passed so we need to entertain the ever
=C2=A0 =C2=A0 so slight possibility that another codec has miraculously
=C2=A0 =C2=A0 appeared.=C2=A0 Remember, we want to ensure we=E2=80=99re goi= ng
=C2=A0 =C2=A0 to get maximum interoperability.

Question #4 (open mic)

Are there any new or unaddressed technical issues that will not allow us to= narrow the field to VP8 and H.264?

=C2=A0 =C2=A0 We do not want to revisit previous discussions; we only
=C2=A0 =C2=A0 want new or unaddressed technical issues and will throttle =C2=A0 =C2=A0 the discussion accordingly.=C2=A0 We=E2=80=99ll rely on WG pa= rticipants
=C2=A0 =C2=A0 and our former RAI AD (Mr. Sparks) for help in this area.

=C2=A0 =C2=A0 We believe the technical discussion will fall into two
=C2=A0 =C2=A0 buckets:
=C2=A0 =C2=A0 =C2=A0 - New or unresolved technical points.
=C2=A0 =C2=A0 =C2=A0 - Licensing.=C2=A0 WRT licensing, the IETF tries not d= iscuss
=C2=A0 =C2=A0 =C2=A0 =C2=A0 whether IPR is valid, but an IPR issue that can= be used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as input to the decision making process is if e= nough
=C2=A0 =C2=A0 =C2=A0 =C2=A0 people say they can=E2=80=99t/won=E2=80=99t imp= lement because of the IPR.

Question #5 (hum)

With respect to the MTI codec:
=C2=A0 =C2=A0 - Who can live with a requirement that WebRTC User Agents
=C2=A0 =C2=A0 =C2=A0 MUST support=C2=A0 both VP8 and H.264 and WebRTC devic= es
=C2=A0 =C2=A0 =C2=A0 MUST support=C2=A0 either VP8 or H.264?
=C2=A0 =C2=A0 - Who can live with a requirement that all endpoints MUST sup= port VP8?
=C2=A0 =C2=A0 - Who can live with a requirement that all endpoints MUST sup= port H.264?

[MB] So, are you going to l= et people hum more than once?=C2=A0 If so, I cannot see how the outcome wil= l be any different than the last time we had this discussion.=C2=A0 I didn&= #39;t hum twice last time because it made no sense to me.=C2=A0 I would hum= for all of those and my guess is that many others are in the same boat. = =C2=A0 I was going to suggest you separate the questions under number 5, bu= t I don't think that will change the outcome either.=C2=A0
[/= MB]

Thanks for your time,
t/c/s
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--001a1134716800411905070a5c87-- From nobody Tue Nov 4 08:55:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92771A9141 for ; Tue, 4 Nov 2014 08:55:20 -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, 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 ojUGgmqeCAos for ; Tue, 4 Nov 2014 08:55:18 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80D41A913B for ; Tue, 4 Nov 2014 08:55:17 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-fa-545904f37111 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.22.24955.3F409545; Tue, 4 Nov 2014 17:55:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 17:55:14 +0100 From: Christer Holmberg To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) Thread-Index: AQHP976YJR9qOmOInEu0eE83OjGPx5xQr4Ug Date: Tue, 4 Nov 2014 16:55:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> In-Reply-To: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje5nlsgQg84tqhZr/7WzW+w4N4HF gcnjzpwPrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4vbGZveAya8W61u9MDYyzWboYOTkkBEwk rk87ygphi0lcuLeerYuRi0NI4AijxPf3d8ASQgKLGSWm3nXvYuTgYBOwkOj+pw0SFhFwlzjQ 8JoJxBYWCJRoOreTHSIeJLHv6kco20hi4YF3YGNYBFQkWm5eZQSxeQV8Jab3zoUaby2x+Nd6 sDmcAjYSx44sBathBLrn+6k1YHFmAXGJW0/mM0HcKSCxZM95ZghbVOLl439Q9ytJrD28nQWi Xkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny042M 9VKLMpOLi/Pz9PJSSzYxAqPk4JbfqjsYL79xPMQowMGoxMNr4BgRIsSaWFZcmXuIUZqDRUmc d+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGG0e3jBonRAv/DbbR4/dlqvnzBMmN6fQ rsBc8aOHRd8s1PeJUOaIuft51lzzCna30OcGjNWBLQ6O+4+muGzXPWz9IGZyz64Vb6oSZ3eJ ldVI73I7uiD5aeS8YPctGmvPNntxvxMSSzsg2GjQzq8nfHnScrEdk8Ue+chXXL2wT1SlNHim bGq2EktxRqKhFnNRcSIAriVaL3MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2PX-y8HxgunD3203yGU0OJFqDBM Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 16:55:21 -0000 Hi Sean, > Question #5 (hum) > > With respect to the MTI codec: > - Who can live with a requirement that WebRTC User Agents > MUST support both VP8 and H.264 and WebRTC devices > MUST support either VP8 or H.264? > - Who can live with a requirement that all endpoints MUST support VP8? > - Who can live with a requirement that all endpoints MUST support H.26= 4? As far as I know, we are still discussing the terminology, and meaning of "= WebRTC User Agent", "WebRTC device", etc, so I don't think it is a good ide= a to use that in a hum at this point. Or, if you want to use it, please provide a definition, to be used in the h= um, of the terminology. Regards, Christer From nobody Tue Nov 4 09:02:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655C61A90D6 for ; Tue, 4 Nov 2014 09:01:59 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o3LlKQeMeaC for ; Tue, 4 Nov 2014 09:01:57 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529FC1A19E6 for ; Tue, 4 Nov 2014 09:01:57 -0800 (PST) Received: (qmail 45598 invoked from network); 4 Nov 2014 17:01:55 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 12891 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 4 Nov 2014 17:01:55 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 0D07718A1D8E; Tue, 4 Nov 2014 17:01:50 +0000 (GMT) Received: from [10.7.79.176] (unknown [193.120.74.172]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 90B1518A0B9A; Tue, 4 Nov 2014 17:01:49 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> Date: Tue, 4 Nov 2014 17:01:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rlJ0x2F2QCJiBDcK_Hy5bJBW7U4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 17:01:59 -0000 On 4 Nov 2014, at 16:55, Christer Holmberg = wrote: > Hi Sean, >=20 >> Question #5 (hum) >>=20 >> With respect to the MTI codec: >> - Who can live with a requirement that WebRTC User Agents >> MUST support both VP8 and H.264 and WebRTC devices >> MUST support either VP8 or H.264? >> - Who can live with a requirement that all endpoints MUST support = VP8? >> - Who can live with a requirement that all endpoints MUST support = H.264? >=20 > As far as I know, we are still discussing the terminology, and meaning = of "WebRTC User Agent", "WebRTC device", etc, so I don't think it is a = good idea to use that in a hum at this point. >=20 > Or, if you want to use it, please provide a definition, to be used in = the hum, of the terminology. I think it may be possible to dodge the device definition problem by = saying: All implementations of the rtcweb specification must implement at least = one of VP8 or H.264,=20 implementations that also implement the w3c=92s webRTC javascript API = must implement both VP8 and H264 - The latter requirement would also need to be blessed by the w3c of = course. T. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Nov 4 13:52:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01F31A0151 for ; Tue, 4 Nov 2014 13:52:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv-TBvx-dh2G for ; Tue, 4 Nov 2014 13:52:29 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00C11A014F for ; Tue, 4 Nov 2014 13:52:28 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-03v.sys.comcast.net with comcast id BZro1p00457bBgG01ZsUSL; Tue, 04 Nov 2014 21:52:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id BZsT1p00L3Ge9ey01ZsUCS; Tue, 04 Nov 2014 21:52:28 +0000 Message-ID: <54594A9B.9090703@alum.mit.edu> Date: Tue, 04 Nov 2014 16:52:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415137948; bh=PXdHf+vfthRvbrCVLL5R8H4TQC4ZWfq0i23fNpE/5Dg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gt1lz0boiFinnTMijIm1dlYh6ZFz3svpDV6NXbLgNGdDZQ7Xs8RJyie7XQWx4aLeS henN2BWtDIqzrU7VseL97zWoIfvxm2sSMjCogvcArB1aXlGtNc0oDebHq2RD+Rurbw D+aHDl5q9wCcChKN4umh4di+gdaVcHKNsiIhyo7P4ANdTmbsgMqs11os9jJUSAu64i qf1zQYtqiptV+1DQFGKbBXixk+LcTWWkd2lAWbk724wgIyRAdQwM7yi9Jzqgd5fUHV 6q3YAoP36zd0ywss90UDwPmbmODzZV4HIuxluh4Ej11Mk8FyOKzdf3pGkfZkEGI7gM 6XduvdwO8JCEg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2cKSLYOXTmvfdiGmYnlrJdKa5yA Subject: [rtcweb] draft-ietf-rtcweb-jsep-08 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 04 Nov 2014 21:52:30 -0000 I have a few related comments on jsep-08: Section 4.1.1 defines the BUNDLE policy values. It certainly appears that when you are using the default "balanced" policy there will be *separate* bundle groups for audio and video, and that the SCTP m-line will not be bundled. However section 5.2.1 says: Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in [RFC5888]. This attribute MUST have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. The effect of this is that the browser offers all m= sections as one BUNDLE group. However, whether the m= sections are bundle-only or not depends on the BUNDLE policy. This doesn't deal with bundle policy - this rule seems to apply only to max-compat policy. Section 7.1 says that both Alice and Bob are using the "balanced" policy, which should lead to separate bundles for audio and video, but the example shows a single bundle - consistent with a "max-bundle" policy. There are no examples that show more than one bundle group. Thanks, Paul From nobody Tue Nov 4 16:58:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA211A1AB7 for ; Tue, 4 Nov 2014 16:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 owzv0APHLxaL for ; Tue, 4 Nov 2014 16:58:43 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24661A1AA6 for ; Tue, 4 Nov 2014 16:58:42 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id wn1so11786354obc.18 for ; Tue, 04 Nov 2014 16:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yseesXzUPenkbjIB/6l2lSwwUoavvA3WETuefmj1QHQ=; b=ZDItVdIsQThgb2yfr1VeNoisYgoFSH9ma00MOAftRxGQEp6fd9rkN1wKTwsODj4LIu 6imi03n9t6lEuwRUXLJA83LbM2ivjmSYf0Ek13XZ6m2ijcYFDkmZdyka/YpqYRvdWe2/ 7hz/u2Wm3L/qzg1ZyfTu/NFct3yHeRSHIl3+eWey+XpfY/chbN1ngf/UDyMh5cDvZtwi ARst0IoCg6anA1618xAmd+3TUyMkBhFOQR+iEZ9IPTIuJzfA0On94SQQrHu60ZAm5eud UBtc1xZ/RvVr2yVzNEqHcoVjATLOKEBPYx9lyHK7mJsULJRb7P+rNYgVYZMedd8J8y1K xd2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yseesXzUPenkbjIB/6l2lSwwUoavvA3WETuefmj1QHQ=; b=hhXvo2bg+KQyp0MBkR/K6D8gPwaia9vYA82aBG6iLJ/xl6ImnU4baQ6EjYAalIy6yq kU37OMqG1Y4GD6pX5/qjwrP5aL0MPlTIBdsPPCeYUqjrxVzp21L3FMxiAu8wr3USYhVb IdqHw3xMWM8xWlR4Z5HBENfDy7rS+ouXKNgPdfv5sQjqjXd+RN4xkvOlInwVfIkdew8I n4KvPcI9FiiWr7PXAELvBaW2EZ5CmsP5KlDC63kJs7KpUc/fA/m5T1VYmpmQp+Dknz2J rnsJ4YQ9P3VFDPXaIrbueAZRqBVPJAmbngVkuklwTmdHR7q+jVIqI2X3+EiRV/4i7C2n G7qA== X-Gm-Message-State: ALoCoQlkJl1MRHrwQflWRn0sCUp86jqz0WDIIDQlLxWgrJeP+JBAhdsJS4RgYLpR9K/moJgxv1Tn X-Received: by 10.182.46.168 with SMTP id w8mr4948359obm.56.1415149122128; Tue, 04 Nov 2014 16:58:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Tue, 4 Nov 2014 16:58:20 -0800 (PST) In-Reply-To: <54594A9B.9090703@alum.mit.edu> References: <54594A9B.9090703@alum.mit.edu> From: Justin Uberti Date: Tue, 4 Nov 2014 16:58:20 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bfeaf70baac6e0507121470 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VduLtsaIHt7AYVQH6qIdyhuflxU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-08 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 00:58:47 -0000 --047d7bfeaf70baac6e0507121470 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat wrote: > I have a few related comments on jsep-08: > > Section 4.1.1 defines the BUNDLE policy values. It certainly appears that > when you are using the default "balanced" policy there will be *separate* > bundle groups for audio and video, and that the SCTP m-line will not be > bundled. > This is not correct. Rather, the m= lines for these groups will not be marked as a=bundle-only. > > However section 5.2.1 says: > > Once all m= sections have been generated, a session-level "a=group" > attribute MUST be added as specified in [RFC5888]. This attribute > MUST have semantics "BUNDLE", and MUST include the mid identifiers of > each m= section. The effect of this is that the browser offers all > m= sections as one BUNDLE group. However, whether the m= sections > are bundle-only or not depends on the BUNDLE policy. > > This doesn't deal with bundle policy - this rule seems to apply only to > max-compat policy. > Section 7.1 says that both Alice and Bob are using the "balanced" policy, > which should lead to separate bundles for audio and video, but the example > shows a single bundle - consistent with a "max-bundle" policy. There are no > examples that show more than one bundle group. > > Right. JSEP endpoints always try to BUNDLE (and rtcp-mux). Legacy endpoints can of course reject this. --047d7bfeaf70baac6e0507121470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat <pkyzivat@alum.mit.ed= u> wrote:
I have a few related comments o= n jsep-08:

Section 4.1.1 defines the BUNDLE policy values. It certainly appears that w= hen you are using the default "balanced" policy there will be *se= parate* bundle groups for audio and video, and that the SCTP m-line will no= t be bundled.

This is not correct. Rath= er, the m=3D lines for these groups will not be marked as a=3Dbundle-only.= =C2=A0

However section 5.2.1 says:

=C2=A0 =C2=A0Once all m=3D sections have been generated, a session-level &q= uot;a=3Dgroup"
=C2=A0 =C2=A0attribute MUST be added as specified in [RFC5888].=C2=A0 This = attribute
=C2=A0 =C2=A0MUST have semantics "BUNDLE", and MUST include the m= id identifiers of
=C2=A0 =C2=A0each m=3D section.=C2=A0 The effect of this is that the browse= r offers all
=C2=A0 =C2=A0m=3D sections as one BUNDLE group.=C2=A0 However, whether the = m=3D sections
=C2=A0 =C2=A0are bundle-only or not depends on the BUNDLE policy.

This doesn't deal with bundle policy - this rule seems to apply only to= max-compat policy.=C2=A0

Section 7.1 says that both Alice and Bob are using the "balanced"= policy, which should lead to separate bundles for audio and video, but the= example shows a single bundle - consistent with a "max-bundle" p= olicy. There are no examples that show more than one bundle group.


Right. JSEP endpoints always try to BU= NDLE (and rtcp-mux). Legacy endpoints can of course reject this.
<= div>=C2=A0
--047d7bfeaf70baac6e0507121470-- From nobody Tue Nov 4 18:28:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F371A8798 for ; Tue, 4 Nov 2014 18:28:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fno1jseEPryG for ; Tue, 4 Nov 2014 18:28:17 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0004B1A8795 for ; Tue, 4 Nov 2014 18:28:15 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-11v.sys.comcast.net with comcast id BeU81p0034s37d401eUF1T; Wed, 05 Nov 2014 02:28:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-01v.sys.comcast.net with comcast id BeUE1p00T3Ge9ey01eUFkB; Wed, 05 Nov 2014 02:28:15 +0000 Message-ID: <54598B3E.3040207@alum.mit.edu> Date: Tue, 04 Nov 2014 21:28:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti References: <54594A9B.9090703@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415154495; bh=dLvA5ItuqIOyjdvXL51isTHhMBu+h5NHRlMd9/ez+wM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GbMcX+7ls9ApXaDtmfoV3mKPIDnPTSGXfqB8mAiU1d1HJVGB+24a7re4opuPPR5t8 7rrs3NXPAaY069ApGZ9nfGLUUGuD/VVZ4BWYVipDdIhmTaQGr1p3mUypAipXpFnIz2 0u6jXUYxjcb40bOK2yC6z8i4xnKLfWhm5ojfvKu9TWtS2Jj3hJAWPh7+Gvc7+435/J eCApzVLoe2KXVqqfmbPHKEDaxJW0A7XCj6cWJFeJ7n0IUId8TMyvE+u5Sg35bE9mXG +VpPKY0F8majyRPEmJWJKkje8czXrtTaGfFoIHlfqSo9h0MM0E3Z5HYmvKze5Ldx4M OR8RJ3fovjGbg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6N3D0si6zJ7HchixwzrqZal3jUQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-08 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 02:28:18 -0000 On 11/4/14 7:58 PM, Justin Uberti wrote: > > > On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat > wrote: > > I have a few related comments on jsep-08: > > Section 4.1.1 defines the BUNDLE policy values. It certainly appears > that when you are using the default "balanced" policy there will be > *separate* bundle groups for audio and video, and that the SCTP > m-line will not be bundled. > > > This is not correct. Rather, the m= lines for these groups will not be > marked as a=bundle-only. Well, it is your draft, so you should know what you intended for it to say. But I didn't get that from the words: balanced: The application will BUNDLE all media streams *of the same type* together. That is, if there are multiple audio and multiple video MediaStreamTracks attached to a PeerConnection, all but the first audio and video tracks will be marked as bundle-only, and candidates will only be gathered for N media streams, where N is the number of distinct media types. When talking to a non-BUNDLE- aware endpoint, only the non-bundle-only streams will be negotiated. This policy balances desire to multiplex with the need to ensure basic audio and video still works in legacy cases. Data channels will be in a separate bundle group. max-bundle: The application will BUNDLE *all of its media streams, including data channels, on a single transport*. All streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. The presence of *all media streams of the same type* and *all of its media streams* suggests that those are key distinctions in those two definitions. If that wasn't the intent, then I suggest revising the above words to be more in line with your intent. Perhaps: balanced: The application will BUNDLE all media streams together. If there are multiple MediaStreamTracks attached to a PeerConnection, candidates will be gathered for the first of each distinct media type, and the others will be marked as bundle-only. When talking to a non-BUNDLE-aware endpoint, only the non-bundle-only streams will be negotiated. This policy balances desire to multiplex with the need to ensure basic audio and video still works in legacy cases. Data channels will be in a separate bundle group. Thanks, Paul From nobody Tue Nov 4 21:07:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36B1A87BB for ; Tue, 4 Nov 2014 21:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 NXI0UIUy1LNv for ; Tue, 4 Nov 2014 21:06:56 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156811A1BCC for ; Tue, 4 Nov 2014 21:06:55 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so2387obc.25 for ; Tue, 04 Nov 2014 21:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bW+AzG7MIkLbbZcqmi5TIGA7gBORlr1oZsYgyGy6HHc=; b=MtJcs3Qx3cESKBFCGnHw7eHvBmhaj3hrLVyfZZVfx9NGDv+IoOZ9QL6y3WwuOE0TeN TzPix+t7MbpvHTMgUUIVeUO2V+kMFpaTysLAxeirnFhOLteOvg8RToLlu3ICwJPExr7f EwU7Sla47sEphhZruPCCiDUuS0OuA35fIgyLRFstyTLQ18J7gc1L7tLzhPJD2DPUyLbE SoJE5UhioUqNTOcYF2m9D3Vu7lbELPWRx1XV26RBsvhVOqTDKK6VcDWF2VCznUa4jkeJ piR1sRKzhimjmZYe/BWusXmw2W2l5auBfnr8c/t7aFCl05PduKGHOUy36GLffbJjFovc HL6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bW+AzG7MIkLbbZcqmi5TIGA7gBORlr1oZsYgyGy6HHc=; b=Sky14RrNGnwPWxE5D1wXiv/WGMLklMeVMcgQ0IjOUExwzVV8dvx0z+VxA/IowmQeQp R9mANNnRNnzZv+4GIOsIU3ij7QsgBjYF1zyuAFumv7rcxsf73kX5GWvnPxWoL2afcGsW //pz/pqijvvZ7A7H9pMfI3WjjlYJPHDNlwvx+4J5Ft5A5fKwnIjvPKYV7qx4BMS8B0My 4+V6nueGLX+Cd32wnFTiuRry7ByIUQRK+aj821ItdYy8eBTodxrLLjA2wH0/wuG3vNe5 GglFoZsKKyT+kosPzcVnAZy0POpuzbsWFn3iiuDhKMifuTZKyC2RHZypYE/2eOsBtTEz zT0g== X-Gm-Message-State: ALoCoQkKBN6rPz1oO+QTktph51r/8Oad7oLSxopHj3vgdAXTysyn9Tix1cf0QhSEXIMiZCJHRvOJ X-Received: by 10.60.74.169 with SMTP id u9mr6177800oev.50.1415164014801; Tue, 04 Nov 2014 21:06:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Tue, 4 Nov 2014 21:06:34 -0800 (PST) In-Reply-To: <54598B3E.3040207@alum.mit.edu> References: <54594A9B.9090703@alum.mit.edu> <54598B3E.3040207@alum.mit.edu> From: Justin Uberti Date: Tue, 4 Nov 2014 21:06:34 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1135ef1c66e3370507158c90 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eEkqYjF6XRmZvAp9tQVCmdVhEgA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-08 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 05:07:00 -0000 --001a1135ef1c66e3370507158c90 Content-Type: text/plain; charset=UTF-8 That's good feedback. I'll file an issue to improve this text. On Tue, Nov 4, 2014 at 6:28 PM, Paul Kyzivat wrote: > On 11/4/14 7:58 PM, Justin Uberti wrote: > >> >> >> On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat > > wrote: >> >> I have a few related comments on jsep-08: >> >> Section 4.1.1 defines the BUNDLE policy values. It certainly appears >> that when you are using the default "balanced" policy there will be >> *separate* bundle groups for audio and video, and that the SCTP >> m-line will not be bundled. >> >> >> This is not correct. Rather, the m= lines for these groups will not be >> marked as a=bundle-only. >> > > Well, it is your draft, so you should know what you intended for it to > say. But I didn't get that from the words: > > balanced: The application will BUNDLE all media streams *of the same > type* together. That is, if there are multiple audio and multiple > video MediaStreamTracks attached to a PeerConnection, all but the > first audio and video tracks will be marked as bundle-only, and > candidates will only be gathered for N media streams, where N is > the number of distinct media types. When talking to a non-BUNDLE- > aware endpoint, only the non-bundle-only streams will be > negotiated. This policy balances desire to multiplex with the > need to ensure basic audio and video still works in legacy cases. > Data channels will be in a separate bundle group. > > max-bundle: The application will BUNDLE *all of its media streams, > including data channels, on a single transport*. All streams other > than the first will be marked as bundle-only. This policy aims to > minimize candidate gathering and maximize multiplexing, at the > cost of less compatibility with legacy endpoints. > > The presence of *all media streams of the same type* and *all of its media > streams* suggests that those are key distinctions in those two definitions. > If that wasn't the intent, then I suggest revising the above words to be > more in line with your intent. Perhaps: > > balanced: The application will BUNDLE all media streams > together. If there are multiple MediaStreamTracks attached to a > PeerConnection, candidates will be gathered for the first of > each distinct media type, and the others will be marked as > bundle-only. When talking to a non-BUNDLE-aware endpoint, only > the non-bundle-only streams will be negotiated. This policy > balances desire to multiplex with the need to ensure basic audio > and video still works in legacy cases. Data channels will be in a > separate bundle group. > > Thanks, > Paul > --001a1135ef1c66e3370507158c90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's good feedback. I'll file an issue to improv= e this text.

On Tue, Nov 4, 2014 at 6:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On = 11/4/14 7:58 PM, Justin Uberti wrote:


On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 I have a few related comments on jsep-08:

=C2=A0 =C2=A0 Section 4.1.1 defines the BUNDLE policy values. It certainly = appears
=C2=A0 =C2=A0 that when you are using the default "balanced" poli= cy there will be
=C2=A0 =C2=A0 *separate* bundle groups for audio and video, and that the SC= TP
=C2=A0 =C2=A0 m-line will not be bundled.


This is not correct. Rather, the m=3D lines for these groups will not be marked as a=3Dbundle-only.

Well, it is your draft, so you should know what you intended for it to say.= But I didn't get that from the words:

=C2=A0 =C2=A0balanced:=C2=A0 The application will BUNDLE all media streams = *of the same
=C2=A0 =C2=A0 =C2=A0 type* together.=C2=A0 That is, if there are multiple a= udio and multiple
=C2=A0 =C2=A0 =C2=A0 video MediaStreamTracks attached to a PeerConnection, = all but the
=C2=A0 =C2=A0 =C2=A0 first audio and video tracks will be marked as bundle-= only, and
=C2=A0 =C2=A0 =C2=A0 candidates will only be gathered for N media streams, = where N is
=C2=A0 =C2=A0 =C2=A0 the number of distinct media types.=C2=A0 When talking= to a non-BUNDLE-
=C2=A0 =C2=A0 =C2=A0 aware endpoint, only the non-bundle-only streams will = be
=C2=A0 =C2=A0 =C2=A0 negotiated.=C2=A0 This policy balances desire to multi= plex with the
=C2=A0 =C2=A0 =C2=A0 need to ensure basic audio and video still works in le= gacy cases.
=C2=A0 =C2=A0 =C2=A0 Data channels will be in a separate bundle group.

=C2=A0 =C2=A0max-bundle:=C2=A0 The application will BUNDLE *all of its medi= a streams,
=C2=A0 =C2=A0 =C2=A0 including data channels, on a single transport*. All s= treams other
=C2=A0 =C2=A0 =C2=A0 than the first will be marked as bundle-only.=C2=A0 Th= is policy aims to
=C2=A0 =C2=A0 =C2=A0 minimize candidate gathering and maximize multiplexing= , at the
=C2=A0 =C2=A0 =C2=A0 cost of less compatibility with legacy endpoints.

The presence of *all media streams of the same type* and *all of its media = streams* suggests that those are key distinctions in those two definitions.= If that wasn't the intent, then I suggest revising the above words to = be more in line with your intent. Perhaps:

=C2=A0 =C2=A0balanced:=C2=A0 The application will BUNDLE all media streams<= br> =C2=A0 =C2=A0 =C2=A0 together. If there are multiple MediaStreamTracks atta= ched to a
=C2=A0 =C2=A0 =C2=A0 PeerConnection, candidates will be gathered for the fi= rst of
=C2=A0 =C2=A0 =C2=A0 each distinct media type, and the others will be marke= d as
=C2=A0 =C2=A0 =C2=A0 bundle-only. When talking to a non-BUNDLE-aware endpoi= nt, only
=C2=A0 =C2=A0 =C2=A0 the non-bundle-only streams will be negotiated.=C2=A0 = This policy
=C2=A0 =C2=A0 =C2=A0 balances desire to multiplex with the need to ensure b= asic audio
=C2=A0 =C2=A0 =C2=A0 and video still works in legacy cases. Data channels w= ill be in a
=C2=A0 =C2=A0 =C2=A0 separate bundle group.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

--001a1135ef1c66e3370507158c90-- From nobody Wed Nov 5 03:22:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891081A1B3C for ; Wed, 5 Nov 2014 03:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFu1bQU6WUIg for ; Wed, 5 Nov 2014 03:22:27 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936FE1A0461 for ; Wed, 5 Nov 2014 03:22:26 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-97-545a08700a65 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 33.3A.04231.0780A545; Wed, 5 Nov 2014 12:22:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 12:22:22 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Justin Uberti , Matthew Kaufman Thread-Topic: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) Thread-Index: AQHP98apw9sJ+ptHqEebD4kL7UMK2g== Date: Wed, 5 Nov 2014 11:22:21 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0B1EE5@ESESSMB209.ericsson.se> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54581E56.10407@matthew.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+JvjW4BR1SIwY4HhhZbpwpZtM0+wmKx 9l87uwOzx4JNpR5Llvxk8jjV6RXAHMVlk5Kak1mWWqRvl8CVsevbD9aCk5wVUybPZWtgvMPe xcjBISFgIrFpT2QXIyeQKSZx4d56ti5GLg4hgSOMEgcv72CFcBYzSmy49YMdpIpNIFBi674F bCC2iICPxLoXncwgNrOAusSdxefAaoSBap7vuMcCURMkceTxXyhbT2Lb0kNgNSwCKhLTLraD 9fIK+Er0fPsOtXkBo0T7o4tMIAlGoJO+n1rDBLFAXOLWk/lMEKcKSCzZc54ZwhaVePn4HyuE rSSx6PZnqHo9iRtTp7BB2NoSyxa+hlomKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1O LS7OTTcy1kstykwuLs7P08tLLdnECIybg1t+6+5gXP3a8RCjAAejEg/vhkmRIUKsiWXFlbmH GKU5WJTEeRedmxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHFdZMNd+aSA3W3Y+acfHLf R1hogVlHhfO31RnLpjV4qnsaKKVxb9Tvu3Tcr3v9taTpxtuWMfs9WrXgaEpTZaTAwTb3DyLL f6uxXawz/HilcH+4/ByNhltTa0ROSCy1m5EVYqIxdy1/j0rNPtljbGqrtI61iH+bOmeR6Isr TcU5BVf3z5h/OluJpTgj0VCLuag4EQBvUVQafAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q83ZD0fzKfqBqN5Z4k1gVrEz47k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 11:22:28 -0000 On 04/11/14 07:36, Justin Uberti wrote:=0A= > ps. Doing this with hums at a meeting just encourages filling the=0A= > room with people who aren't participating in the process but whose=0A= > employers have asked them to stuff the room to increase the hum=0A= > volume. Those people will all stand up for question #1, then leave=0A= > immediately after the hums are completed. Just like last time.=0A= >=0A= > I am shocked -- shocked -- at these allegations of room stuffing in our= =0A= > beloved IETF. Surely the blue=0A= > =0A= > sheets=0A= > =0A= > from IETF 88 (the last time we discussed codecs, on day 2) will put to=0A= > rest these claims.=0A= >=0A= > Wait...=0A= >=0A= > Company Day2 RTCWEB Attendees Day1 RTCWEB Attendees Delta=0A= > cisco 25 15 10=0A= > mozilla 12 12 0=0A= > ericsson 10 5 5=0A= =0A= When I read the blue sheets I get 9 and 6 respectively. One of the three = =0A= delta persons was Bo Burman who presented =0A= http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-8.pdf.=0A= From nobody Wed Nov 5 07:47:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45221ACE86 for ; Wed, 5 Nov 2014 07:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrYYWdTU3zuf for ; Wed, 5 Nov 2014 07:47:44 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB301A8888 for ; Wed, 5 Nov 2014 07:47:44 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id s7so675222qap.0 for ; Wed, 05 Nov 2014 07:47:43 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=TQRINA6hllD3JUJzdQ8L7N3W8qt0/e0bg4EsnMG5gZA=; b=Q5gvRynNrEbPfNDl1zyb2Mlt/H0NbLjAC0nDZzClNQjv45baWGTi6YxnV2LIba4W5u I/WYXrazf55WL9fgny8xK4f/BxNTJZNqozwbI9wznVW+PmcJAdzyNao0aXL9gaSoIST2 LVwZnMunpT1txbXY1kkQSZYQp4D8DltPtKLLxIMMRET0DNGWoQUAFvi/pMFFyBCH1k6T u6fEF7tJOTo/f4rC0Bdz5fdhHpShGnC2FjLVn6FO1zHlR7NMtpMmfpZq22KEr0VJdlBp 4ljwYuIvPkvTo8YRxeIADQWDY0UYoVRQKm7/BYW+oXSrXzKXozOrDcXgcKCJ3er+F1zz nM+Q== X-Gm-Message-State: ALoCoQnL7IwZeIWKvuxtn6eGxCrwL6xddUJssLKkB838FjHVGNSdGm8ZYca1e+Cd6OLHQZKr2faR X-Received: by 10.140.19.9 with SMTP id 9mr33802339qgg.98.1415202463328; Wed, 05 Nov 2014 07:47:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 5 Nov 2014 07:47:23 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 5 Nov 2014 16:47:23 +0100 Message-ID: To: tim panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y2a5pZRZzCQtPSD6uhWt1eYNZ7A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 15:47:45 -0000 2014-11-04 18:01 GMT+01:00 tim panton : > All implementations of the rtcweb specification must implement at least o= ne of VP8 or H.264, > implementations that also implement the w3c=E2=80=99s webRTC javascript = API must implement both VP8 and H264 +1 This is obviously the only way-to-go and the only reasonable and feasible decision. BTW and given that this is a W3C business, I would replace: "implementations that also implement the w3c=E2=80=99s webRTC javascript = API" with: "browsers" --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 5 08:58:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A9E1A8978 for ; Wed, 5 Nov 2014 08:58:57 -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 yKIIhHuwPWyU for ; Wed, 5 Nov 2014 08:58:52 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E071A8983 for ; Wed, 5 Nov 2014 08:58:52 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id rp18so1099469iec.37 for ; Wed, 05 Nov 2014 08:58:51 -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=Uc8WcFwZN/HO4HOEwtzmTo1FzVugjQdO4yl9G/q/SIo=; b=LqU6OSWj0l4H4zdjMX1/oLtKJvPPPSJSvsrlbse1AwH5UkLRBPdH7CdfA+JjbezuRM mby8zwVAp6rsKbMyJ8QLNkBlJ2Y6iFUpcN+aVSh6wuoZMh0S2CyWOzxY61luIoUmj0jH 6Rn1LCS6Hl3auvWyAxK3V4ytUknNK1Ac6AD0+WJa10LwODwYGfx2eMBcrMgnpXmOu+FK DCCj4UF6NfmsIHb7HGi64ovd31NteLYPCwKQ2mZqm1IRJpbmFYAUhXHWLYnj8kAiNXqB 6FJRntI7z8yHXr0TZYUnkJTvu9jFULBu++aMoou12yMGoUn4q+w4eX0WKASjjSS0gLgI QrWQ== X-Gm-Message-State: ALoCoQnuENp17ZLs9zrpoPILTuLO/CA9ZykOfPZ1u6YS/Ekm18wkzKTkoCxEa55kjoplWF/dRGPu X-Received: by 10.107.128.146 with SMTP id k18mr4456758ioi.69.1415206731810; Wed, 05 Nov 2014 08:58:51 -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 199sm1727375ion.7.2014.11.05.08.58.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 08:58:51 -0800 (PST) Message-ID: <545A5739.9050604@bbs.darktech.org> Date: Wed, 05 Nov 2014 11:58:33 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Bq9WjztWklOVNzlnlrA2bkooFEs Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 16:58:57 -0000 On 05/11/2014 10:47 AM, Iñaki Baz Castillo wrote: > 2014-11-04 18:01 GMT+01:00 tim panton : >> All implementations of the rtcweb specification must implement at least one of VP8 or H.264, >> implementations that also implement the w3c’s webRTC javascript API must implement both VP8 and H264 > +1 > > This is obviously the only way-to-go and the only reasonable and > feasible decision. > > BTW and given that this is a W3C business, I would replace: > "implementations that also implement the w3c’s webRTC javascript API" > with: > "browsers" Why should we treat non-browsers any differently? Gili From nobody Wed Nov 5 09:17:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4800F1A89AD for ; Wed, 5 Nov 2014 09:17:31 -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 N-6QYf6ZKIRc for ; Wed, 5 Nov 2014 09:17:30 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F41D1A8A62 for ; Wed, 5 Nov 2014 09:16:04 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id q1so1077858lam.24 for ; Wed, 05 Nov 2014 09:16:02 -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=gnTb+4Hu6TQNt+I+f4WWeAbwuEdnee3o6tGnZv0lsUM=; b=I9vYaaOXS7uOfz4QhgyIN0rrLWe29oh6Ocgp/78Oh0oYnQtZOKGJMYp1G3oWRMluiw Uiey8u7BEDSTb+cmRtyNrPch9fQw2YrJegkb9JAMeT6nmWmVKb0tOlfNI05wEYt7sf/H n6sw/wfawHbrpzx0lP/SDQzAk2iJ/YHWauysexKmQM+Tv44ferWHBAJOvEAin4dwlWl0 I7ECWV8NGLu4ZfI3O3oUOwzYINzkc4j0hfW6uSpIrDU0l/KM5TH4eJ/MzVk8IpsYx1n2 xgR1nkoKhy72mKFjn33Z4M33yVDpm9GOXG+wzDSCfGo+9SQHFZezWJjGc6ZsQtCYtV6W kOsQ== MIME-Version: 1.0 X-Received: by 10.152.42.226 with SMTP id r2mr38355978lal.29.1415207760829; Wed, 05 Nov 2014 09:16:00 -0800 (PST) Received: by 10.25.77.208 with HTTP; Wed, 5 Nov 2014 09:16:00 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> Date: Wed, 5 Nov 2014 18:16:00 +0100 Message-ID: From: Victor Pascual Avila To: tim panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6v1Ktr5WETLzGXhPR3_C394eOAM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 17:17:31 -0000 On Tue, Nov 4, 2014 at 6:01 PM, tim panton wrote: > All implementations of the rtcweb specification must implement at least o= ne of VP8 or H.264, > implementations that also implement the w3c=E2=80=99s webRTC javascript = API must implement both VP8 and H264 I'd be OK with that -Victor --=20 Victor Pascual =C3=81vila From nobody Wed Nov 5 09:28:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D7F1A8AF7 for ; Wed, 5 Nov 2014 09:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, 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 cfmxW_FgRye2 for ; Wed, 5 Nov 2014 09:28:10 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C33A1A8A0D for ; Wed, 5 Nov 2014 09:28:10 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id u20so12259593oif.39 for ; Wed, 05 Nov 2014 09:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IxZDg6jRCFBNFz4WwPrt6b2Z7v19SvGpnYFf/0t9R7k=; b=n961tpEEn4Xt2EHeEzN52j64CNIuY3dzeF75uw2/XTx8osXY5EPUJRxx137b4HMN9V sWwuZo+OHDT4yqpNm78+hIBkNdi29BIpFN0ZgQjkFll9WCMV+EOkOgT+qelrYALOUzCH NAqOa5HxIEB2u1lf8PN1H/axAc9UPnwDUknMsMfKkgBiapluadPeWOXePAWarm3pD+Sz tTTNAJC9o/GgXiqSRFG7Jvg7SR0GmbLftig6qYPhnOL+h2ppcGBkoE6i6T/n/rWsVYZj MYmldVNlIfPH1f+UTlumIn8m9YshuTrfGsWaObZUrgHKZg/uHKfo++Wd6k//3C6I0dft Vzbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IxZDg6jRCFBNFz4WwPrt6b2Z7v19SvGpnYFf/0t9R7k=; b=BKkZomd8SYN0s27rt2pVpi315AXm+z6sJS7/mztxnPACPLFi0DzR28bP3kMtD7VXD2 4kJDHnvbjomI5vtnJPvGeLvZQFCzJnIYwYURbutEEvgLB8LPYzJ25YL1rJE9vXVIFjIu YoFpf/hvc0FVrbQF5ZJr6Dkbj3/lYfGdgzYoaU+gTjbeO0VNdJQ3tfLJIptvwkZngtyX Da2NBdbnkt3rxp4+ImFjZc9MsyQESCBAj1te1EmMFHHS67DH1N3iPRuGheUexX/OmgF+ HBgrQC1GDXzeHr1OZxCfx5wMZXX62Qr6N7jcCYyVdSakYao4kKusYfQH8HKiWKEigRrJ BwKg== X-Gm-Message-State: ALoCoQnj4mxsmzMai9UwlTFuEiM0WP54nzydVWaUE05bnXQbB3yhwUmtL0ELxXL7bx34acLZy78o X-Received: by 10.202.49.65 with SMTP id x62mr13905451oix.17.1415208489522; Wed, 05 Nov 2014 09:28:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.248.170 with HTTP; Wed, 5 Nov 2014 09:27:49 -0800 (PST) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0B1EE5@ESESSMB209.ericsson.se> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <54581E56.10407@matthew.at> <1447FA0C20ED5147A1AA0EF02890A64B1D0B1EE5@ESESSMB209.ericsson.se> From: Justin Uberti Date: Wed, 5 Nov 2014 09:27:49 -0800 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=001a113ccb684d549105071fe739 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zcLyWokj1k-phF3WdW6KW_3BdUU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 17:28:11 -0000 --001a113ccb684d549105071fe739 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 5, 2014 at 3:22 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 04/11/14 07:36, Justin Uberti wrote: > > ps. Doing this with hums at a meeting just encourages filling the > > room with people who aren't participating in the process but whose > > employers have asked them to stuff the room to increase the hum > > volume. Those people will all stand up for question #1, then leave > > immediately after the hums are completed. Just like last time. > > > > I am shocked -- shocked -- at these allegations of room stuffing in our > > beloved IETF. Surely the blue > > < > http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-rtcweb-01.pdf= > > > sheets > > < > http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-rtcweb-02.pdf= > > > from IETF 88 (the last time we discussed codecs, on day 2) will put to > > rest these claims. > > > > Wait... > > > > Company Day2 RTCWEB Attendees Day1 RTCWEB Attendees Delta > > cisco 25 15 10 > > mozilla 12 12 0 > > ericsson 10 5 5 > > When I read the blue sheets I get 9 and 6 respectively. One of the three > delta persons was Bo Burman who presented > http://www.ietf.org/proceedings/88/slides/slides-88-rtcweb-8.pdf. > Yes, this was a counting error on my part, apologies for that. --001a113ccb684d549105071fe739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 5, 2014 at 3:22 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 04/11/14 07:36, Justin Uberti wrote: >=C2=A0 =C2=A0 =C2=A0ps. Doing this with hums at= a meeting just encourages filling the
>=C2=A0 =C2=A0 =C2=A0room with people who aren't participating in th= e process but whose
>=C2=A0 =C2=A0 =C2=A0employers have asked them to stuff the room to incr= ease the hum
>=C2=A0 =C2=A0 =C2=A0volume. Those people will all stand up for question= #1, then leave
>=C2=A0 =C2=A0 =C2=A0immediately after the hums are completed. Just like= last time.
>
> I am shocked -- shocked -- at these allegations of room stuffing in ou= r
> beloved IETF.=C2=A0 Surely the blue
> <http://www.ie= tf.org/proceedings/88/bluesheets/bluesheets-88-rtcweb-01.pdf>
> sheets
> <http://www.ietf.org/proceedings/88/bl= uesheets/bluesheets-88-rtcweb-02.pdf>
> from IETF 88 (the last time we discussed codec= s, on day 2) will put to
> rest these claims.
>
> Wait...
>
> Company=C2=A0 =C2=A0 =C2=A0 =C2=A0Day2 RTCWEB Attendees=C2=A0 =C2=A0Da= y1 RTCWEB Attendees=C2=A0 =C2=A0Delta
> cisco=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A025=C2=A0 =C2=A0 =C2=A0 15=C2=A0= =C2=A0 =C2=A0 10
> mozilla=C2=A0 =C2=A0 =C2=A0 =C2=A012=C2=A0 =C2=A0 =C2=A0 12=C2=A0 =C2= =A0 =C2=A0 0
> ericsson=C2=A0 =C2=A0 =C2=A0 10=C2=A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2= =A0 =C2=A05

When I read the blue sheets I get 9 and 6 respectively. One of the t= hree
delta persons was Bo Burman who presented
http://www.ietf.org/proceedings/88/slides/slides-88-rtc= web-8.pdf.

Yes, this was a counting= error on my part, apologies for that.

--001a113ccb684d549105071fe739-- From nobody Wed Nov 5 09:29:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCDC1A8AE3 for ; Wed, 5 Nov 2014 09:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC4qZwDpl2Fh for ; Wed, 5 Nov 2014 09:29:33 -0800 (PST) Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F9A1A8A0D for ; Wed, 5 Nov 2014 09:29:32 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id i57so550317yha.12 for ; Wed, 05 Nov 2014 09:29:31 -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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3C0hILtob+rFX+B/Opbkezr97tqkZxhZcWmvKqlbP7A=; b=IgGnosC0/Avl5GuZOAQG6jPn90VT2VXKiBpzd9p8bTrRxCshlz/RAHMiTw/Fed87TI 8XL+nxjUUQ6NKBjkaEMoPQLDPyphE9rAU/IWBD8mVZTzKzb7fYD6nmvJnOXsH4BlNb1K C5TfOFrfBimczfY1j4VcHepByLm4sJU1FFtiWYh+6l5gpwD5OCbJySMg6cD9+oott9aM SKjNlnRYHyfI8Fkw7CN+fHbZLMWEaurvfk83F2RXlq3UBYYDUxFkh0h6dfZSgevwWn0F wZ5uvu0i7kCIKzkIJh9kUV/Yi4Oquhq6fAJR6GTYyMTPZdALoNRpxBCMkeRbe6wCigQt 49Xw== X-Gm-Message-State: ALoCoQnK+ScL5Dqu7beTIIBxYAsXRZQ3FzTQwOXvHtkg7u71PIyuJ5Up40uISMuu52PpkQuJGKa2 MIME-Version: 1.0 X-Received: by 10.236.20.71 with SMTP id o47mr42570011yho.119.1415208571865; Wed, 05 Nov 2014 09:29:31 -0800 (PST) Sender: neils@vipadia.com Received: by 10.170.194.203 with HTTP; Wed, 5 Nov 2014 09:29:31 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> Date: Wed, 5 Nov 2014 17:29:31 +0000 X-Google-Sender-Auth: 8yOpWFYkwc9tEYTRAA8oCDuRloE Message-ID: From: Neil Stratford To: tim panton Content-Type: multipart/alternative; boundary=089e0153833035a77405071fec29 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jhVLYSJhCSZwtwR0vq1x8imcZvI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 17:29:34 -0000 --089e0153833035a77405071fec29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 4, 2014 at 5:01 PM, tim panton wrote: > All implementations of the rtcweb specification must implement at least > one of VP8 or H.264, > implementations that also implement the w3c=E2=80=99s webRTC javascript = API must > implement both VP8 and H264 > That gets my support. Neil --089e0153833035a77405071fec29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 4, 2014 at 5:01 PM, tim panton <tim@phonefromhere.com><= /span> wrote:
All implementations of the = rtcweb specification must implement at least one of=C2=A0 VP8 or H.264,
implementations that also implement the w3c=E2=80=99s webRTC javascript=C2= =A0 API must implement=C2=A0 both VP8 and H264

That gets my support.=C2=A0

Neil=C2=A0
--089e0153833035a77405071fec29-- From nobody Wed Nov 5 09:46:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD401A903E for ; Wed, 5 Nov 2014 09:46:47 -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 bk6oHAyLtTLt for ; Wed, 5 Nov 2014 09:46:46 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6BF91A9039 for ; Wed, 5 Nov 2014 09:46:45 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id gq15so1170107lab.35 for ; Wed, 05 Nov 2014 09:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=u/VB9nnBQi3SpdfG7zc/Y738yu1H44Y+heSdvS8fn4E=; b=RRtH3rEK9uSaJyVCN9TWXjNxGc+znzSZ6rWm2QxWCintmzkAtkGCu7zZcabFs69xmD Y3TWqr+Ew6L65+GZ75rR9ngfjQYPIcY9bXszX/o8F0uq3XqMNgO6uZDgD6zGdM7u1s28 G1sUfb7N/Qb4e9K8zMv+oTbSg9g696Y6XyVvUNfAHqWnccFFLFm+YsxRpT4JVDWiNmro zwFqnTg0vVxKX8a/eIHDoWCy4y7NjloAjvY2udZ6FLzD8aTa9bvuoneSJg04WRwadEUD bZbYU5kltZpmxfQ0AxMi0Dc9QUopNhIJlc+dPJe9+gPXUzQNjCCP8HXKzWwiM2UaAHdp p9cw== X-Received: by 10.112.132.34 with SMTP id or2mr70246850lbb.75.1415209604319; Wed, 05 Nov 2014 09:46:44 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ba19sm1554676lab.31.2014.11.05.09.46.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 09:46:43 -0800 (PST) Message-ID: <545A6281.4050601@gmail.com> Date: Wed, 05 Nov 2014 18:46:41 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Victor Pascual Avila , tim panton References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/596ST0kSsDUeLLcFAqvxod1f16c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:46:48 -0000 On 05/11/14 18:16, Victor Pascual Avila wrote: > On Tue, Nov 4, 2014 at 6:01 PM, tim panton wrote: >> All implementations of the rtcweb specification must implement at least one of VP8 or H.264, >> implementations that also implement the w3c’s webRTC javascript API must implement both VP8 and H264 > I'd be OK with that I don't see any reason to split on JavaScript API implementations and the rest. Moreover, looking back, the web browsers (and the web ecosystem itself) got to this level mainly due to open source implementations, via khtml/webkit and gecko/firefox (then servers and other tools), which at some point were small and not benefiting of any substantial resources. If any of "must implement" requirements adds limits (financial or not) to the usage in any kind of major open source licensing models, it is going to block a lot of innovation and disruption in the field. Better the freedom to negotiate anything and fail to find some common grounds in a session than building a walled garden for 'the chosen ones' -- hopefully the aim is not to build a new pstn-like ecosystem. Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Wed Nov 5 10:30:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898A21A9109 for ; Wed, 5 Nov 2014 10:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptqjFr4pHDwn for ; Wed, 5 Nov 2014 10:30:34 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB15E1A910E for ; Wed, 5 Nov 2014 10:30:33 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id w7so1017727qcr.40 for ; Wed, 05 Nov 2014 10:30:33 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=1lioW0+gjSPU6hyzgRnCO2oMsGf9DTk6ciU4vY9olI8=; b=dXwZyquuiVuKXI8U5+jVQZfNw1MliMe0Ixg5zm0ICAYW4QsUJWVZQtQ2s4gp7c/mlm HF/afHME4NmNH4HcPGXtC49+zYCH6Vbz8gC4gfQdwE5QZCHPLUGnTINh2BGyj7tXDxou 7g9X/NYt2i4VeKRdInujfEBIqpK5XRMMtDVzLyS24MepshVIyHa/ibQNKcCrwvogb62n ygJs5x2d/ugbC5ftiPETWj5bjpfVKB2uVqHfZnMgmg7ujLZZCJW4nZvreZZrMkFa4FvQ 9xbyIet1s288ZXRGK/VzNPW98HejHEOCfzrfFDrQ0iYDY5NVM0VHNxX5b3dJNCrhP6+l lPeQ== X-Gm-Message-State: ALoCoQnieOcbICrWHzCeI/YMwi5RKQtGET3emrpTOuBkaObcdw/Pyfc2kNZhQnz5+Cve9XNGIq0P X-Received: by 10.140.39.113 with SMTP id u104mr13357802qgu.86.1415212232934; Wed, 05 Nov 2014 10:30:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 5 Nov 2014 10:30:12 -0800 (PST) In-Reply-To: <545A5739.9050604@bbs.darktech.org> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A5739.9050604@bbs.darktech.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 5 Nov 2014 19:30:12 +0100 Message-ID: To: cowwoc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/v_UXx7t805PM3wHoxrvdryQwhDM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 18:30:34 -0000 2014-11-05 17:58 GMT+01:00 cowwoc : > Why should we treat non-browsers any differently? Because the W3C can just standardize stuff for browsers, and not for mobile/desktop native apps. --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 5 10:38:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277FE1A1AE4 for ; Wed, 5 Nov 2014 10:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anQSPUGhYAtV for ; Wed, 5 Nov 2014 10:38:56 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459711A1A19 for ; Wed, 5 Nov 2014 10:38:56 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id q107so12753374qgd.14 for ; Wed, 05 Nov 2014 10:38:55 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4GjnhN1KzMHEkQe5qrMrASsU2cxCECGQak4m5tS4X1o=; b=INZBqj1roWVjPqhjizmkVeUxaojNb4iXcr45l/MSWcjUg+cxGq4l5SLBxNfj2gFdg+ WX8075Tq6M3ObW/aUaFMyM7Uuw1hCqG5/GZaQUYYYjBO360/FGFKKlmf0tEejlWLO/dY QbWILCAgBLHIq8kxD8N3UIdNtsfuMv/yd0hr9SZLf8Q9WwvcmzhaM6PmTg3dZZzqVEyA vSxUYd4hw741JYm/7pbJhK+zXqrsNuU3FDlvrLT9M/FBR+F00BFWaMh1McFq1tCfLGq9 7nnPQd2/wwofUjSBo+LmW7J4aIE0tu87aWKb9h+5q/v8bGW51llA4i8eGA6kuZKby6YD 5sYQ== X-Gm-Message-State: ALoCoQkqV57zp+KpIbQVLa17icAdjGh9KzK2y2mNYQiR+O46NkBVbmlfvNo+71aO/Xzfyjr57W0z X-Received: by 10.229.209.136 with SMTP id gg8mr7509748qcb.16.1415212735477; Wed, 05 Nov 2014 10:38:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 5 Nov 2014 10:38:35 -0800 (PST) In-Reply-To: <545A6281.4050601@gmail.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 5 Nov 2014 19:38:35 +0100 Message-ID: To: Daniel-Constantin Mierla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/x1olhpBZov0gqKJY8q85PrQXgFA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 18:38:57 -0000 2014-11-05 18:46 GMT+01:00 Daniel-Constantin Mierla : > I don't see any reason to split on JavaScript API implementations and > the rest. > > Moreover, looking back, the web browsers (and the web ecosystem itself) > got to this level mainly due to open source implementations, via > khtml/webkit and gecko/firefox (then servers and other tools), which at > some point were small and not benefiting of any substantial resources. > If any of "must implement" requirements adds limits (financial or not) > to the usage in any kind of major open source licensing models, it is > going to block a lot of innovation and disruption in the field. > > Better the freedom to negotiate anything and fail to find some common > grounds in a session than building a walled garden for 'the chosen ones' > -- hopefully the aim is not to build a new pstn-like ecosystem. Very good point. Chrome exists thanks to an open source project. It wouldn't be fair that now Chrome gets something that other users of the same source project are not allowed to use due to the licensing business model of the "Industry" (Industry =3D those that do not really contribute to *Web*RTC, but just expect WebRTC satisfies some requirements for their legacy business). Of course, if VP8 or H264 or both become a MTI codec for WebRTC browsers, then any future effort to introduce a new open and 100% rollalty-free video codec will be unfeasible. Said that, then what? no MTI codec at all? --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 5 11:05:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F1E1A1BA5 for ; Wed, 5 Nov 2014 11:05:38 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttuGRCzr0vKK for ; Wed, 5 Nov 2014 11:05:35 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061A01A1B91 for ; Wed, 5 Nov 2014 11:05:34 -0800 (PST) Received: (qmail 94023 invoked from network); 5 Nov 2014 19:05:33 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 14376 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Nov 2014 19:05:33 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9F50C18A0E38; Wed, 5 Nov 2014 19:05:29 +0000 (GMT) Received: from [192.168.42.25] (unknown [85.255.234.98]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0BA0618A0C55; Wed, 5 Nov 2014 19:05:28 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: <545A5739.9050604@bbs.darktech.org> Date: Wed, 5 Nov 2014 19:05:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3377C8F3-40F8-49F4-82A3-30F1886CDE06@phonefromhere.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A5739.9050604@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/m5LbXJAccUFQeOBFoAzq32URxoQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 19:05:38 -0000 On 5 Nov 2014, at 16:58, cowwoc wrote: > On 05/11/2014 10:47 AM, I=F1aki Baz Castillo wrote: >> 2014-11-04 18:01 GMT+01:00 tim panton : >>> All implementations of the rtcweb specification must implement at = least one of VP8 or H.264, >>> implementations that also implement the w3c=92s webRTC javascript = API must implement both VP8 and H264 >> +1 >>=20 >> This is obviously the only way-to-go and the only reasonable and >> feasible decision. >>=20 >> BTW and given that this is a W3C business, I would replace: >> "implementations that also implement the w3c=92s webRTC javascript = API" >> with: >> "browsers" >=20 > Why should we treat non-browsers any differently? My logic for this is that non-browsers are typically statically = programmed, to do a single task well, so don=92t have the same over-riding need for interop with everything = else. A browser has no pre-defined use case and so has to be as flexible as = possible to accommodate anything. >=20 > Gili >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Nov 5 11:08:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0403B1A1B8F for ; Wed, 5 Nov 2014 11:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh_lW5v1E7u1 for ; Wed, 5 Nov 2014 11:08:00 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id DB5811A1B87 for ; Wed, 5 Nov 2014 11:07:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id ED23C7C5101 for ; Wed, 5 Nov 2014 20:07:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu8MiK8zAoJZ for ; Wed, 5 Nov 2014 20:07:48 +0100 (CET) Received: from [IPv6:2620:0:1000:167d:e5cb:9126:6dca:f5a4] (unknown [IPv6:2620:0:1000:167d:e5cb:9126:6dca:f5a4]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6F0CC7C50FA for ; Wed, 5 Nov 2014 20:07:48 +0100 (CET) Message-ID: <545A7581.7050904@alvestrand.no> Date: Wed, 05 Nov 2014 11:07:45 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vknp-2GbVVpPjiWr7M76V76gQp0 Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 19:08:03 -0000 On 11/05/2014 10:38 AM, Iñaki Baz Castillo wrote: > Of course, if VP8 or H264 or both become a MTI codec for WebRTC > browsers, then any future effort to introduce a new open and 100% > rollalty-free video codec will be unfeasible. There's no barrier to introducing non-MTI codecs. They just won't have universal support (like any new feature). VP9 is the obvious candidate for trying that one out. -- Surveillance is pervasive. Go Dark. From nobody Wed Nov 5 11:09:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324491A6F07 for ; Wed, 5 Nov 2014 11:09:42 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77khwemyB-m6 for ; Wed, 5 Nov 2014 11:09:40 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00D81A1BE3 for ; Wed, 5 Nov 2014 11:09:39 -0800 (PST) Received: (qmail 95216 invoked from network); 5 Nov 2014 19:09:38 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 14407 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 5 Nov 2014 19:09:38 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 7596818A0E38; Wed, 5 Nov 2014 19:09:32 +0000 (GMT) Received: from [192.168.42.25] (unknown [85.255.234.98]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9E70618A0C55; Wed, 5 Nov 2014 19:09:31 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: <545A6281.4050601@gmail.com> Date: Wed, 5 Nov 2014 19:09:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> To: miconda@gmail.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EFPYdfQ-qc0vVmgv_Gk35m29ixw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 19:09:42 -0000 On 5 Nov 2014, at 17:46, Daniel-Constantin Mierla = wrote: >=20 > On 05/11/14 18:16, Victor Pascual Avila wrote: >> On Tue, Nov 4, 2014 at 6:01 PM, tim panton = wrote: >>> All implementations of the rtcweb specification must implement at = least one of VP8 or H.264, >>> implementations that also implement the w3c=92s webRTC javascript = API must implement both VP8 and H264 >> I'd be OK with that > I don't see any reason to split on JavaScript API implementations and > the rest. >=20 > Moreover, looking back, the web browsers (and the web ecosystem = itself) > got to this level mainly due to open source implementations, via > khtml/webkit and gecko/firefox (then servers and other tools), which = at > some point were small and not benefiting of any substantial resources. > If any of "must implement" requirements adds limits (financial or not) > to the usage in any kind of major open source licensing models, it is > going to block a lot of innovation and disruption in the field. >=20 > Better the freedom to negotiate anything and fail to find some common > grounds in a session than building a walled garden for 'the chosen = ones' > -- hopefully the aim is not to build a new pstn-like ecosystem. I accept that argument, to an extent. However I think the costs of = producing an all new browser are now so high that the H264 license won=92t be the blocker. I have no = evidence for this opinion. The combination of the Cisco h264 plugin ugliness and the exposure of = h264 hardware on iOS also mitigate the problem. It is however still a problem, but on balance = having no webRTC MTI for video is=20 worse IMHO. >=20 > Daniel >=20 > --=20 > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >=20 From nobody Wed Nov 5 11:13:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7BF1A1A30 for ; Wed, 5 Nov 2014 11:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 ipWQJk46JFBT for ; Wed, 5 Nov 2014 11:13:04 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324831A1BE4 for ; Wed, 5 Nov 2014 11:13:04 -0800 (PST) Received: (qmail 85552 invoked from network); 5 Nov 2014 19:13:02 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 14432 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Nov 2014 19:13:02 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 956FA18A0E38; Wed, 5 Nov 2014 19:12:56 +0000 (GMT) Received: from [192.168.42.25] (unknown [85.255.234.98]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C6E4418A0C55; Wed, 5 Nov 2014 19:12:55 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: Date: Wed, 5 Nov 2014 19:12:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> To: =?windows-1252?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-cTvpVT5Hm_c098dq4ttXVlDm3U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 19:13:05 -0000 On 5 Nov 2014, at 15:47, I=F1aki Baz Castillo wrote: > 2014-11-04 18:01 GMT+01:00 tim panton : >> All implementations of the rtcweb specification must implement at = least one of VP8 or H.264, >> implementations that also implement the w3c=92s webRTC javascript = API must implement both VP8 and H264 >=20 > +1 >=20 > This is obviously the only way-to-go and the only reasonable and > feasible decision. >=20 > BTW and given that this is a W3C business, I would replace: > "implementations that also implement the w3c=92s webRTC javascript = API" > with: > =93browsers" Yes, that is the intention, but I think it is easier to get agreement on = this clear, if clumsy, definition. If you want to come up with a good definition of a browser, feel free = :-) Me, I=92m dodging that bullet! T. >=20 > --=20 > I=F1aki Baz Castillo > From nobody Wed Nov 5 11:44:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9171AC408 for ; Wed, 5 Nov 2014 11:44:19 -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 k0dn6u-WAwx3 for ; Wed, 5 Nov 2014 11:44:17 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046831AC3F6 for ; Wed, 5 Nov 2014 11:44:16 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id p9so1312034lbv.33 for ; Wed, 05 Nov 2014 11:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aNJyNNSn7nmlRG30NZVWiItf0iLul81mJ4bZEdjj7+0=; b=vGFiEKfcyLXWPSTgK14kI1SCg00ihDeabZaUx8utTaVKCjq9/BUf3kKtI/4ygoRe6g Sg/ODna0uKD4h7TkssvcjZvYC4jyBSfLbpcUYE1mg4rHBKp3upZWpsKe1wxfJzARhzDg CmjVz35mbiD79C6e04SDOltT9JtsZR7W877wNl/YAyJzreDjkBm+Ioc64S702HfYqzSL xaCm2sU5lKiVV6HEqtQ6qcY4Giggey7032vuyH/Z68Hc7DSZ5/wsoxLo46RvsopUFwjo gjLLALwDSVB7ddJadL2mqqn6RgXsx8QRPoLwikn5hIgRwAWf0OPymPnvnmxVku/0HjAU GPgw== X-Received: by 10.112.146.229 with SMTP id tf5mr25886870lbb.73.1415216655376; Wed, 05 Nov 2014 11:44:15 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id xe10sm1651214lbb.37.2014.11.05.11.44.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 11:44:14 -0800 (PST) Message-ID: <545A7E0B.4070505@gmail.com> Date: Wed, 05 Nov 2014 20:44:11 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: tim panton References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oVLlF2lABvwPBjjiIAmwUhY5mYs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 19:44:19 -0000 On 05/11/14 20:09, tim panton wrote: > On 5 Nov 2014, at 17:46, Daniel-Constantin Mierla wrote: > >> On 05/11/14 18:16, Victor Pascual Avila wrote: >>> On Tue, Nov 4, 2014 at 6:01 PM, tim panton wrote: >>>> All implementations of the rtcweb specification must implement at least one of VP8 or H.264, >>>> implementations that also implement the w3c’s webRTC javascript API must implement both VP8 and H264 >>> I'd be OK with that >> I don't see any reason to split on JavaScript API implementations and >> the rest. >> >> Moreover, looking back, the web browsers (and the web ecosystem itself) >> got to this level mainly due to open source implementations, via >> khtml/webkit and gecko/firefox (then servers and other tools), which at >> some point were small and not benefiting of any substantial resources. >> If any of "must implement" requirements adds limits (financial or not) >> to the usage in any kind of major open source licensing models, it is >> going to block a lot of innovation and disruption in the field. >> >> Better the freedom to negotiate anything and fail to find some common >> grounds in a session than building a walled garden for 'the chosen ones' >> -- hopefully the aim is not to build a new pstn-like ecosystem. > I accept that argument, to an extent. However I think the costs of producing an all new browser > are now so high that the H264 license won’t be the blocker. I have no evidence for this opinion. I don't want to rule out the possibility of having a completely new implementation. Anyhow, by the nature of open source, if someone doesn't like the path a project goes, then the project can forked. Even the big players that could eventually afford plenty of resources do that: webkit was started by apple as fork of khtml, (afaik) blink from chrome is forked from webkit. We already have small players around (khtml is still there, popular within kde) or tailored versions (debian ships own browser built out of mozilla code - http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project). > The combination of the Cisco h264 plugin ugliness and the exposure of h264 hardware on iOS also > mitigate the problem. It is however still a problem, but on balance having no webRTC MTI for video is > worse IMHO. Any kind of restricting the freedom to implement open protocols/specs is worse than no MTI for video, IMO. Daniel > > >> Daniel >> >> -- >> Daniel-Constantin Mierla >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com From nobody Wed Nov 5 11:55:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DAB1AC449 for ; Wed, 5 Nov 2014 11:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x935SKZu7wg for ; Wed, 5 Nov 2014 11:55:33 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6661AC43B for ; Wed, 5 Nov 2014 11:55:33 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id j107so12532712qga.20 for ; Wed, 05 Nov 2014 11:55:32 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=j6HV7umoUhTqK3ocakrq2F41ebWjKnizvSOZgK0KK4s=; b=OLL4sRlwnCKNYiAtRwDq+2ARty4NUAchFeix8Zf9/pd699LRBnXo7qssmXrpfECpyA wwtOl1QXpe4+RE4DLloseuqptzAYZcGSaMqyARZkNXCy3yyBztPMOWzlr07PRCemy25b 4TQ5s+lIveTYwVOJpcbjBDT6OBueNgaPQiKmgMRowwcd6NJdETE/aamEi8SW4b7t5C6y gCbcehhYyibXxQxCDyNqzDX1uDIn2r/S8uLW1CQsX7nCtF518yxb3CIoRRxMRchBg6xS SGDSWDlyd93pj9agB4j1LDaaXPnUTtK/vYygi3Jjy8iGjloRWm6ykwNyY8Gx8Q2db2GB oAwA== X-Gm-Message-State: ALoCoQnk3XvrHHLfbeDuvIyACW5DWt58Oo3WCft93Ni9DTuy8R/kAYhjaN0oxdGHcVdPcIb1jV2x X-Received: by 10.224.96.195 with SMTP id i3mr53150519qan.76.1415217332422; Wed, 05 Nov 2014 11:55:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 5 Nov 2014 11:55:12 -0800 (PST) In-Reply-To: <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 5 Nov 2014 20:55:12 +0100 Message-ID: To: tim panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IiSxMUIAE19o4RgVbZlO1qHn2dw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 19:55:34 -0000 2014-11-05 20:12 GMT+01:00 tim panton : > If you want to come up with a good definition of a browser, feel free :-= ) Please enlighten me... do we also have problems to define what a browser is= ? --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 5 11:57:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7494E1A6FDE for ; Wed, 5 Nov 2014 11:56:59 -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 8qjFawxBSBb4 for ; Wed, 5 Nov 2014 11:56:58 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D621A6F1E for ; Wed, 5 Nov 2014 11:56:57 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id u10so1283534lbd.25 for ; Wed, 05 Nov 2014 11:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hkv+3i0magQ4t9qcfQE2JvfFzZnd0ZWG76es3chmcg4=; b=ztr+XXBpW7m/0njtLNENIp/RqKKUxGTA3Dky+l6MqdnuIeGAkcNqnV+tn0ezcty7xe efbzZwUqaSbKK8edvp2HLUHVFcZ8HRLT0YzqjGpNU+gGdO5oUENLWWE3eQTrgUNbfYIv NE/GKpS1rAqL7K3DvXB7qXAoKGlHP4Gd/K9c626dduwCunddM314VJzvbKjUain3MV7h IhzPIzwk7J2sB/DXl4DuVgRiNrr/8AqhDGjgxzTyV0Pr9UXNBP8dzypYoUwnVWuCLcDn UC8+cR/XiWY4OGN3OZ4uHULOx0w0IwE76FQOFOL2Dw1lnXadMBWSCat8ZhAYgsu3q/j4 3PfA== X-Received: by 10.152.170.131 with SMTP id am3mr69778000lac.15.1415217415892; Wed, 05 Nov 2014 11:56:55 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ja9sm1664446lbc.30.2014.11.05.11.56.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 11:56:55 -0800 (PST) Message-ID: <545A8103.70009@gmail.com> Date: Wed, 05 Nov 2014 20:56:51 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OL5LdspFViVUX4G4zQboOv20YB8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 19:56:59 -0000 On 05/11/14 19:38, Iñaki Baz Castillo wrote: > 2014-11-05 18:46 GMT+01:00 Daniel-Constantin Mierla : >> I don't see any reason to split on JavaScript API implementations and >> the rest. >> >> Moreover, looking back, the web browsers (and the web ecosystem itself) >> got to this level mainly due to open source implementations, via >> khtml/webkit and gecko/firefox (then servers and other tools), which at >> some point were small and not benefiting of any substantial resources. >> If any of "must implement" requirements adds limits (financial or not) >> to the usage in any kind of major open source licensing models, it is >> going to block a lot of innovation and disruption in the field. >> >> Better the freedom to negotiate anything and fail to find some common >> grounds in a session than building a walled garden for 'the chosen ones' >> -- hopefully the aim is not to build a new pstn-like ecosystem. > > Very good point. > > Chrome exists thanks to an open source project. It wouldn't be fair > that now Chrome gets something that other users of the same source > project are not allowed to use due to the licensing business model of > the "Industry" (Industry = those that do not really contribute to > *Web*RTC, but just expect WebRTC satisfies some requirements for their > legacy business). > > Of course, if VP8 or H264 or both become a MTI codec for WebRTC > browsers, then any future effort to introduce a new open and 100% > rollalty-free video codec will be unfeasible. > > Said that, then what? no MTI codec at all? Yes, better no MTI for video than a MTI allowing only some 'particular' players. If the "Industry" wants to make MTI a codec they control, then they have to make it completely free to everyone. Most of the web ecosystem (browsers, servers, languages, etc ...) was made free by others and they don't have to pay to benefit of it, then, whatever is not free, it is not enforced to anyone in order to be 'on web'. Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Wed Nov 5 12:19:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5091ACC8C for ; Wed, 5 Nov 2014 12:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4s9BHSDV2gu for ; Wed, 5 Nov 2014 12:19:49 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437D61AC445 for ; Wed, 5 Nov 2014 12:16:14 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id i13so1068618qae.22 for ; Wed, 05 Nov 2014 12:16:13 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=BK1+H0aHYTubcNH5QShu39Boe3GtF5R8JDTVRzfvoMQ=; b=V26X7oxjLnMhY+mWczooSjNfw4drAFTjwHCQ+a3myQlL9rhT7Sx8IeV+GtW6j+lsPj 02dVOPvxTebifILJkLgQjT2au0wZngxV1pYOkl3rCt1wYzfWld6b0AFQCAkbhWZGeyAG U0/fHpN3Smb+oujZRvNkgdg/6jxNP4COrqevY1tPu00Bb2L8igtUhFyfat+go0JTYxX/ /qtMcPdYYdTeHMnkgbfXxL8BVFdIOE6+4Xl7z+X/hzJqt373TBVaNcwx9sQiPrFKXkHM 3XjuFiozTpUwBHsIwXNKK+3cbHPXPtatbdoIOh3cdfIVr4G08lbTBZ2Ci75tEmZ/S+BW Cylg== X-Gm-Message-State: ALoCoQmDIx0ZXZ3B+/9DgN4WX93KeWM7nZDVn/KMmWWApIq5OrEHxv/5WIUhIAsN4uh1lNvMd7tG X-Received: by 10.140.105.164 with SMTP id c33mr85125616qgf.11.1415218573452; Wed, 05 Nov 2014 12:16:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 5 Nov 2014 12:15:53 -0800 (PST) In-Reply-To: <545A8103.70009@gmail.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A8103.70009@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 5 Nov 2014 21:15:53 +0100 Message-ID: To: Daniel-Constantin Mierla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5F3qTVm-Z5GQq9cMLVrwUb8OFk8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 20:19:51 -0000 2014-11-05 20:56 GMT+01:00 Daniel-Constantin Mierla : > If the "Industry" wants to make MTI a codec they control, then they have > to make it completely free to everyone. Most of the web ecosystem > (browsers, servers, languages, etc ...) was made free by others and they > don't have to pay to benefit of it, then, whatever is not free, it is > not enforced to anyone in order to be 'on web'. 100% agreed. Just be careful when you say "free" as Cisco may argument that their binary is "free". I will keep a modified version of your perfect statement: "If the 'Industry' wants to make MTI a codec they control, then they have to make it completely free and open to everyone." --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 5 12:22:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10231ACC87 for ; Wed, 5 Nov 2014 12:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hbTkR3ecD0d for ; Wed, 5 Nov 2014 12:22:09 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BD31ACCFE for ; Wed, 5 Nov 2014 12:21:06 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id n8so1081954qaq.5 for ; Wed, 05 Nov 2014 12:21:05 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=PftlqydKkA/rJRMxTf9g+Opovhqji7fmJb0XpGataF8=; b=cyO0aTO8RapyZ6aTYrPCdH+htXR6FvHQHJlTuKdFIGaKL+7bWWJxKbDr9RfSI6a76A oWbgwlp7GIVLWW9+WYssIR5QVVCk+lQn320BK/z4LI9odPdsE+OUOlyOfGbIFd0GIlaX ukcOiEofWhS9Zi57PmQ61KHPzdA/9D87GWS4n+dxyaqfYj+rPzSOyjDsWa/GyYkAeHaf zLc4dgxJn3GiFsB64yv3B7RSiViWkLpr/zvWpKJYyYhx0U1hVN2XgF2vXlgDrxv67Yf9 E8IRZdHiUCjaEBkMKSOPnrPM4qFISiD2BXvJwP6pXpb0fhe1gsjQx8nOheQtJviBsBiG 1ldQ== X-Gm-Message-State: ALoCoQlA3t3MDQAGUtKU4vzYBgM/DmsXxOYgvdt5wr+eyXsjugplq1/hzhVzp5zxoG3t554XDuov X-Received: by 10.224.53.131 with SMTP id m3mr90337006qag.85.1415218865605; Wed, 05 Nov 2014 12:21:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 5 Nov 2014 12:20:45 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A8103.70009@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 5 Nov 2014 21:20:45 +0100 Message-ID: To: Daniel-Constantin Mierla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l0f7n9k8O9bcTbu-abf-4IXPTKE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 20:22:10 -0000 2014-11-05 21:15 GMT+01:00 I=C3=B1aki Baz Castillo : > "If the 'Industry' wants to make MTI a codec they control, then they > have to make it completely free and open to everyone." BTW note that if such a codec becomes free and open, then the "Industry" would not control it anymore. So expect a big "NO" from the "Industry" on this topic. --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 5 12:27:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734B71A6FEC for ; Wed, 5 Nov 2014 12:27:37 -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 zkooyfj_yuT9 for ; Wed, 5 Nov 2014 12:27:36 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4681A7016 for ; Wed, 5 Nov 2014 12:27:35 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so13554698wiv.12 for ; Wed, 05 Nov 2014 12:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YeD43BD/H3cO8s3Vu1UawrrzJqTrRdUU1t+xNBZbMv8=; b=Ky7SGNL615M8Lvb/3STkBMYpFqX7IuqRnoSh2AiaE3jtAmLlGW4q4+IxkhwDdcYWti 4y+PXvAmbs1zS6CuD7lSOUJum+Y0Zdd5B5m1vkxqAQ1C4ExC4hXVS1A/tH/RUOBR/OgU cFsZJu72LkhPzl+mxH36gNjtwuIqUfgaMjGQGjCzpGuReD64G3DKkg8UHIQhpFpyf9Uo zVFfJQE9hqdkGvmDSVsjhlfCzPS+6d9dhCAZQXGzKCILUUOZo6rUHe4gvx7YpUz3T2qI JhbUTkePMDOXyGUkN+dMVY+VOdXxf5SGPeo4AhnAidugJk6gs2frcdqYe4kYutkQdNPm Wdxw== X-Received: by 10.194.91.176 with SMTP id cf16mr66922299wjb.60.1415219254647; Wed, 05 Nov 2014 12:27:34 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id mu4sm7189267wib.2.2014.11.05.12.27.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 12:27:33 -0800 (PST) Message-ID: <545A8833.6070207@gmail.com> Date: Wed, 05 Nov 2014 21:27:31 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A8103.70009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3siUroSBtJNRa4E1VOllywXWhkM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:27:37 -0000 On 05/11/14 21:15, Iñaki Baz Castillo wrote: > 2014-11-05 20:56 GMT+01:00 Daniel-Constantin Mierla : >> If the "Industry" wants to make MTI a codec they control, then they have >> to make it completely free to everyone. Most of the web ecosystem >> (browsers, servers, languages, etc ...) was made free by others and they >> don't have to pay to benefit of it, then, whatever is not free, it is >> not enforced to anyone in order to be 'on web'. > 100% agreed. Just be careful when you say "free" as Cisco may argument > that their binary is "free". > > I will keep a modified version of your perfect statement: > > "If the 'Industry' wants to make MTI a codec they control, then they > have to make it completely free and open to everyone." OK, I see - some time any nuance can be employed :-) . Indeed, I meant 'free' as in complete freedom (no barrier to use any kind of implementation - own one, an open one or paid one - definitely, not restricted to use a particular implementation claimed to be free at a moment). Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Wed Nov 5 14:00:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CFE1A000A for ; Wed, 5 Nov 2014 14:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 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, 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 6tTasYBOmFyz for ; Wed, 5 Nov 2014 14:00:49 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE0A1ACE42 for ; Wed, 5 Nov 2014 14:00:49 -0800 (PST) Received: by mail-yk0-f170.google.com with SMTP id 19so750533ykq.29 for ; Wed, 05 Nov 2014 14:00:48 -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=+HM4Uol+vWQY6VNoWoyRAPfTdHCbtHBoceumm8BWDq0=; b=Wvqcrixk0+fx4LdUBjF4P/AtaJYdNZKs8xu+xuFUTPi2KtiLBSElS0dMm7VFSBxc55 XrTboyaeu34IDDsf4pjSMuM+Wj1KBqgbwEK4GD+hhAERWIoSaugJBBUx8En3ta0ty8f2 47Ww0h1nwiN2bZw1tiRWgYuKYCeTd0BKaJAKwnNUlXbS5o0gBvO9l1lt3jHWasRQF9Ry GjWj9pumhSldEQg8hFQImqpdWg5LwKnXA7m6DYoUYC8gyW9xxuEl+T46a0k2rxqnXPpV YgpfrqxEZ+82TvKjYh2ErkJmCDJYXX8TZTc8ik32y/QnHhP1JUVWug5LvLvs4rxo7ufz gMrA== MIME-Version: 1.0 X-Received: by 10.170.186.74 with SMTP id c71mr236588yke.46.1415224848399; Wed, 05 Nov 2014 14:00:48 -0800 (PST) Received: by 10.170.171.193 with HTTP; Wed, 5 Nov 2014 14:00:48 -0800 (PST) Received: by 10.170.171.193 with HTTP; Wed, 5 Nov 2014 14:00:48 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> Date: Thu, 6 Nov 2014 09:00:48 +1100 Message-ID: From: Silvia Pfeiffer To: =?UTF-8?B?ScODwrFha2kgQmF6IENhc3RpbGxv?= Content-Type: multipart/alternative; boundary=001a113972d65dc4c2050723b6a1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lmACnWP1fHl2nf0Ua57-e2Zr6yE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 22:00:50 -0000 --001a113972d65dc4c2050723b6a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6 Nov 2014 06:55, "I=C3=B1aki Baz Castillo" wrote: > > 2014-11-05 20:12 GMT+01:00 tim panton : > > If you want to come up with a good definition of a browser, feel free :-) > > Please enlighten me... do we also have problems to define what a browser is? In the W3C the word UA (user agent) is often used in place of browser because "browser" means different things to different people. Cheers, Silvia. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --001a113972d65dc4c2050723b6a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 Nov 2014 06:55, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
>
> 2014-11-05 20:12 GMT+01:00 tim panton <tim@phonefromhere.com>:
> > If you want to come up with a good=C2=A0 definition of a browser,= feel free :-)
>
> Please enlighten me... do we also have problems to define what a brows= er is?

In the W3C the word UA (user agent) is often used in place o= f browser because "browser" means different things to different p= eople.

Cheers,
Silvia.

>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--001a113972d65dc4c2050723b6a1-- From nobody Wed Nov 5 14:39:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B0A1A00B5 for ; Wed, 5 Nov 2014 14:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx7Ydz6nTvon for ; Wed, 5 Nov 2014 14:39:52 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B9A1A008C for ; Wed, 5 Nov 2014 14:39:51 -0800 (PST) Received: (qmail 46851 invoked from network); 5 Nov 2014 22:39:49 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 15339 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Nov 2014 22:39:49 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 7D29F18A17A9; Wed, 5 Nov 2014 22:39:40 +0000 (GMT) Received: from [192.168.42.153] (unknown [85.255.234.98]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7F96B18A1157; Wed, 5 Nov 2014 22:39:39 +0000 (GMT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_344D3BFC-EFDC-4327-9DB3-4F1ACED033B8" From: tim panton In-Reply-To: <545A7E0B.4070505@gmail.com> Date: Wed, 5 Nov 2014 22:39:36 +0000 Message-Id: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> To: miconda@gmail.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F_WN1cNV3KL5EPM8pOaE4bgYvtk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 22:39:54 -0000 --Apple-Mail=_344D3BFC-EFDC-4327-9DB3-4F1ACED033B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 5 Nov 2014, at 19:44, Daniel-Constantin Mierla = wrote: >=20 > On 05/11/14 20:09, tim panton wrote: >> On 5 Nov 2014, at 17:46, Daniel-Constantin Mierla = wrote: >>=20 >>> On 05/11/14 18:16, Victor Pascual Avila wrote: >>>> On Tue, Nov 4, 2014 at 6:01 PM, tim panton = wrote: >>>>> All implementations of the rtcweb specification must implement at = least one of VP8 or H.264, >>>>> implementations that also implement the w3c=92s webRTC javascript = API must implement both VP8 and H264 >>>> I'd be OK with that >>> I don't see any reason to split on JavaScript API implementations = and >>> the rest. >>>=20 >>> Moreover, looking back, the web browsers (and the web ecosystem = itself) >>> got to this level mainly due to open source implementations, via >>> khtml/webkit and gecko/firefox (then servers and other tools), which = at >>> some point were small and not benefiting of any substantial = resources. >>> If any of "must implement" requirements adds limits (financial or = not) >>> to the usage in any kind of major open source licensing models, it = is >>> going to block a lot of innovation and disruption in the field. >>>=20 >>> Better the freedom to negotiate anything and fail to find some = common >>> grounds in a session than building a walled garden for 'the chosen = ones' >>> -- hopefully the aim is not to build a new pstn-like ecosystem. >> I accept that argument, to an extent. However I think the costs of = producing an all new browser >> are now so high that the H264 license won=92t be the blocker. I have = no evidence for this opinion. >=20 > I don't want to rule out the possibility of having a completely new > implementation. >=20 I=92m not ruling it out, I just claim that any full fresh implementation = of all the w3c specs would be an order of magnitude more expensive to produce than the = maximum cost of the H264 license. I admit that I have no evidence to back that view. > Anyhow, by the nature of open source, if someone doesn't like the path = a > project goes, then the project can forked. Even the big players that > could eventually afford plenty of resources do that: webkit was = started > by apple as fork of khtml, (afaik) blink from chrome is forked from = webkit. >=20 > We already have small players around (khtml is still there, popular > within kde) or tailored versions (debian ships own browser built out = of > mozilla code - > = http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the= _Debian_project). Agreed, the worst aspect of any adoption of H264 is that it makes it = significantly more difficult to produce a custom =92secure=92 build of firefox that has been = independently reviewed for special use-cases (press, humanitarian workers etc). I suspect those users might be = prepared to forego the =91w3c webRTC compliant=92 logo in exchange for increased security. Khtml is interesting - it isn=92t a browser, it is a component (I think) = - ideally it would come under the =91either=92 codec rule - but since it implements a javascript API it falls into the = =91wrong=92 category. Konquorer is the browser app I think? >=20 >> The combination of the Cisco h264 plugin ugliness and the exposure of = h264 hardware on iOS also >> mitigate the problem. It is however still a problem, but on balance = having no webRTC MTI for video is=20 >> worse IMHO. >=20 > Any kind of restricting the freedom to implement open protocols/specs = is > worse than no MTI for video, IMO. I am very keen to avoid a restriction at the protocol (IETF) level, but = feel it is marginally acceptable at the API (w3c) layer for those who choose to implement the full spec. Tim. =20= --Apple-Mail=_344D3BFC-EFDC-4327-9DB3-4F1ACED033B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 5 Nov 2014, at 19:44, = Daniel-Constantin Mierla <miconda@gmail.com> = wrote:


On 05/11/14 20:09, tim panton = wrote:
On 5 Nov 2014, at 17:46, = Daniel-Constantin Mierla <miconda@gmail.com> = wrote:

On 05/11/14 18:16, Victor = Pascual Avila wrote:
On Tue, Nov 4, 2014 at = 6:01 PM, tim panton <tim@phonefromhere.com> = wrote:
All implementations of the rtcweb = specification must implement at least one of  VP8 or = H.264,
implementations that also implement the w3c=92s webRTC = javascript  API must implement  both VP8 and = H264
I'd be OK with that
I don't see any = reason to split on JavaScript API implementations and
the = rest.

Moreover, looking back, the web browsers (and the web = ecosystem itself)
got to this level mainly due to open source = implementations, via
khtml/webkit and gecko/firefox (then servers and = other tools), which at
some point were small and not benefiting of = any substantial resources.
If any of "must implement" requirements = adds limits (financial or not)
to the usage in any kind of major open = source licensing models, it is
going to block a lot of innovation and = disruption in the field.

Better the freedom to negotiate anything = and fail to find some common
grounds in a session than building a = walled garden for 'the chosen ones'
-- hopefully the aim is not to = build a new pstn-like ecosystem.
I accept that argument, = to an extent. However I think the costs of producing an all new = browser
are now so high that the H264 license won=92t be the blocker. = I have no evidence for this opinion.

I don't want to = rule out the possibility of having a completely = new
implementation.


I=92m not = ruling it out, I just claim that any full fresh implementation of all = the w3c specs
would be an order of magnitude more expensive to = produce than the maximum cost of the H264 license.
I admit = that I have no evidence to back that view.

Anyhow, by the nature of open = source, if someone doesn't like the path a
project goes, then the = project can forked. Even the big players that
could eventually afford = plenty of resources do that: webkit was started
by apple as fork of = khtml, (afaik) blink from chrome is forked from webkit.

We = already have small players around (khtml is still there, = popular
within kde) or tailored versions (debian ships own browser = built out of
mozilla code -
http://en.wikipedia.org/wiki/Mozilla_Corporation_= software_rebranded_by_the_Debian_project).
=
Agreed, the worst aspect of any adoption of H264 is that = it makes it significantly more difficult to
produce a custom = =92secure=92 build of firefox that has been independently reviewed for = special use-cases
(press, humanitarian workers etc). I suspect = those users might be prepared to forego the =91w3c webRTC = compliant=92
logo in exchange for increased = security.

Khtml is interesting - it isn=92t a = browser, it is a component (I think) - ideally it would come under the = =91either=92 codec
rule - but since it implements a javascript = API it falls into the =91wrong=92 category. Konquorer is the browser app = I think?


The combination of the Cisco h264 = plugin ugliness and the exposure of h264 hardware on iOS = also
mitigate the problem. It is however still a problem, but on = balance having no webRTC MTI for video is 
worse = IMHO.

Any kind of restricting the freedom to = implement open protocols/specs is
worse than no MTI for video, = IMO.

I am very keen to avoid a = restriction at the protocol (IETF) level, but feel it is marginally = acceptable at the
API (w3c) layer for those who choose to = implement the full = spec.

Tim.
 
= --Apple-Mail=_344D3BFC-EFDC-4327-9DB3-4F1ACED033B8-- From nobody Wed Nov 5 15:00:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EEC1ACED1 for ; Wed, 5 Nov 2014 15:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSbNHLbf37Dy for ; Wed, 5 Nov 2014 15:00:34 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA121ACED0 for ; Wed, 5 Nov 2014 15:00:34 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id u7so1257511qaz.13 for ; Wed, 05 Nov 2014 15:00:33 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Tas1uimWoKvWuHcqmSoHqrhRx/qlg97/sGWK7A9sblI=; b=Ue2JLCr8k+5pSVhTDZ1/JQoVjWbCJ9o5VdngnTihR994t7MvD/SVu9H+9Ve2fnatXL HCWXAHbrhjlncGi32bsxmeEU87pbqYoIG9juAGhxRuxSEqLboJdBEVulsaVMpqDLCDYF +FzjL7h3ZbAaSLy88h7whOsb1anvOP0LjbeNj1VYeHO11n9yhKMx+gKGDaWltmoDaXcB Sjtom5KVzUBeNEQOme2wSG43inteNJiqtbPdIQk6esx+lOUy/rsbefcIayAUqUhd+L2p w2y6ZEmIHhNGi82fm9nhNyWmB44oAUpmyErANyk/1mqgSfaqGpL3rO8MiI0mTd9ZBYt3 iq/A== X-Gm-Message-State: ALoCoQmljv665feBNSTqZl+RE/nmF35eoJc+Z7jG5JKHe+8NwM55RHzHTbSjPVpTPIqAsFXxCWeX X-Received: by 10.140.19.9 with SMTP id 9mr719856qgg.98.1415228433504; Wed, 05 Nov 2014 15:00:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 5 Nov 2014 15:00:13 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 6 Nov 2014 00:00:13 +0100 Message-ID: To: tim panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P2z2bjvyFQApnCQosEfC8lJav_A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Nov 2014 23:00:37 -0000 2014-11-05 23:39 GMT+01:00 tim panton : > Khtml is interesting - it isn=E2=80=99t a browser, it is a component (I t= hink) - KHTML is a HTML/CSS/JS rendered, right. > ideally it would come under the =E2=80=98either=E2=80=99 codec > rule - but since it implements a javascript API it falls into the =E2=80= =98wrong=E2=80=99 > category. Konquorer is the browser app I think? Right, Konqueror is a web browser. But there are lot of KDE apps (which are not web browsers) than include a KHTML view to get and render web pages (for example KTorrent and many others). Said that, I'm not sure whether WebRTC should be implemented in KHTML or in Konqueror. --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 5 17:36:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2571A0010 for ; Wed, 5 Nov 2014 17:36:56 -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 kpZOJ2ZvqSqq for ; Wed, 5 Nov 2014 17:36:54 -0800 (PST) Received: from mail12.bp.ipcortex.net (mail12.bp.ipcortex.net [37.122.192.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667DB1A000C for ; Wed, 5 Nov 2014 17:36:54 -0800 (PST) Received: from Robs-MBP.home (host86-133-242-159.range86-133.btcentralplus.com [86.133.242.159]) (authenticated bits=0) by mail12.bp.ipcortex.net (8.14.6/8.14.0) with ESMTP id sA61an0o014347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 6 Nov 2014 01:36:51 GMT Message-ID: <545AD0AC.4010204@pickering.org> Date: Thu, 06 Nov 2014 01:36:44 +0000 From: Rob Pickering User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> In-Reply-To: <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00, HELO_LH_HOME, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_SORBS_DUL Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/R_nh9Cf3yfB8Jom9v2sOp_a6RnM Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:36:56 -0000 On 05/11/2014 19:12, tim panton wrote: > On 5 Nov 2014, at 15:47, Iñaki Baz Castillo wrote: > >> 2014-11-04 18:01 GMT+01:00 tim panton : >>> All implementations of the rtcweb specification must implement at least one of VP8 or H.264, >>> implementations that also implement the w3c’s webRTC javascript API must implement both VP8 and H264 >> +1 >> >> This is obviously the only way-to-go and the only reasonable and >> feasible decision. >> >> BTW and given that this is a W3C business, I would replace: >> "implementations that also implement the w3c’s webRTC javascript API" >> with: >> “browsers" > Yes, that is the intention, but I think it is easier to get agreement on this clear, if clumsy, definition. > If you want to come up with a good definition of a browser, feel free :-) > Me, I’m dodging that bullet! +1 to the proposal and sane to dodge the bullet Perhaps that should read "implementations that also *expose* the w3c's javascript API" otherwise there is an interesting case where a compiled mobile app isn't a "browser", but the same app using one of the JS app frameworks internally is. Externally they have essentially the same characteristics. -- Rob. From nobody Wed Nov 5 19:03:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632071A0210 for ; Wed, 5 Nov 2014 19:03:20 -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 vXlmdZrfu1HH for ; Wed, 5 Nov 2014 19:03:17 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8771A014A for ; Wed, 5 Nov 2014 19:03:16 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id h11so231651wiw.12 for ; Wed, 05 Nov 2014 19:03:15 -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=GJvLk0RKGS85tBpe4qAj7UzNXmAkokb8ZdyZuCRJ79c=; b=eeSXfAvGmHAKwNO8lpuE5w1rfy6YNrFIJ9o0vbEZ0/J7dDdPUOzQ9vyp9ziFzPKZcg Alzqcz5ZcU7FaIyalUY74u4gtvC2e9idXOPAT8/crPuYGa294agVk+VLt/uy00KvqZ5x vnRem7Wunt662l8l3YvK67g3PMnpCdtN8Y2k6EGDisXS/1lw2wFr6t0E/LEexcpeGz3v r75dI+LtuDKJeVpojmnSBCC0eL1FPjxFvgNbpPdttUnqqj/cyDEHW9MdcJ9CP6/pGp1/ 2uxlCodSL2kDtV/ak4D6kkHYQzMZeQZKe26m96oi46TF4JIPGhT82vdfQwQ0XiqEF9NT KAOA== X-Gm-Message-State: ALoCoQlZfAy1j3PiG70vg8wtjdYIsIcZ7pTSjFLsE0+8UnFMJwV01jIi0IUHnnn4W7SQc+CDcRx4 X-Received: by 10.180.212.78 with SMTP id ni14mr10501368wic.2.1415242995280; Wed, 05 Nov 2014 19:03:15 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com. [209.85.212.178]) by mx.google.com with ESMTPSA id td9sm6593445wic.15.2014.11.05.19.03.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 19:03:14 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so231507wib.11 for ; Wed, 05 Nov 2014 19:03:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.181.8.72 with SMTP id di8mr675857wid.1.1415242993578; Wed, 05 Nov 2014 19:03:13 -0800 (PST) Received: by 10.216.176.65 with HTTP; Wed, 5 Nov 2014 19:03:13 -0800 (PST) In-Reply-To: <545AD0AC.4010204@pickering.org> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> <545AD0AC.4010204@pickering.org> Date: Wed, 5 Nov 2014 22:03:13 -0500 Message-ID: From: Roman Shpount To: Rob Pickering Content-Type: multipart/alternative; boundary=001a1134cdeee7386c050727ef74 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yrlTEiMqkPt78iPK9MM6kR5mDvM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 03:03:20 -0000 --001a1134cdeee7386c050727ef74 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 5, 2014 at 8:36 PM, Rob Pickering wrote: > > +1 to the proposal and sane to dodge the bullet > > Perhaps that should read "implementations that also *expose* the w3c's > javascript API" otherwise there is an interesting case where a compiled > mobile app isn't a "browser", but the same app using one of the JS app > frameworks internally is. Externally they have essentially the same > characteristics. > Does this mean that node.js, must support H.264 if it implements W3C javascript API? I doubt anybody will call it a browser. _____________ Roman Shpount --001a1134cdeee7386c050727ef74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 5, 2014 at 8:36 PM, Rob Pickering <rob@pickering.org> wrote:

+1 to the proposal and sane to dodge the b= ullet

Perhaps that should read "implementations that also *expose* the w3c&#= 39;s javascript API" otherwise there is an interesting case where a co= mpiled mobile app isn't a "browser", but the same app using o= ne of the JS app frameworks internally is. Externally they have essentially= the same characteristics.

Does this me= an that node.js, must support H.264 if it implements W3C javascript API? I = doubt anybody will call it a browser.
_____________
Roman Shpount
=C2=A0
=
--001a1134cdeee7386c050727ef74-- From nobody Wed Nov 5 21:15:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45C01A1A31 for ; Wed, 5 Nov 2014 21:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIvw0dCfHkQf for ; Wed, 5 Nov 2014 21:15:09 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD9B1A1A18 for ; Wed, 5 Nov 2014 21:15:08 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so379960wiw.9 for ; Wed, 05 Nov 2014 21:15:07 -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:from:date :message-id:subject:to:cc:content-type; bh=yppUbtYUG5LxBmyIYSKQorjzhFfuzSkghnC+qtXQSm0=; b=RZ/Xm1dTu2/znFDr2PzJHRXZ6ZzM+cksGnohDbNSFEhFophtED7ErlfTxe2kOqH8o0 GFbJ99muR72zGYBbAICtjTKgCDup1sbpm/YLmZ2MEGMYkhF97XeqbkPT3dDrOQw1sDBy +axMlj3dLfJAZ8UxnlVY01fY5FZB8gyZOdqgaV8tN4ubJ2vKrA71GrrK7ZWUAGsG55W9 TBEz/xM+dP7nGf4L5WnI0p/W5gbH8upE9jd5PIbGWqJa+wIIHYG6v2M5/ccd6ju4StRr lR8A8d8TwqDyQaLPUMIxn8+Q/rAVTj/Jv8DS1l3yAaUL009uEkoKzO6xZpIjr/sIvBB0 ct4Q== X-Gm-Message-State: ALoCoQlo6zj9T88kMMAPyGC4AtamipRp9QJytYe35JXuj7ejErV4jpwiVC8R1020xegVTPTYhGTp X-Received: by 10.180.107.136 with SMTP id hc8mr37090722wib.78.1415250907461; Wed, 05 Nov 2014 21:15:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Wed, 5 Nov 2014 21:14:27 -0800 (PST) In-Reply-To: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> From: Eric Rescorla Date: Wed, 5 Nov 2014 21:14:27 -0800 Message-ID: To: tim panton Content-Type: multipart/alternative; boundary=e89a8f3bad459b9037050729c703 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rzZZPiTg0cquke1bxW4eBbLu3Qg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 05:15:12 -0000 --e89a8f3bad459b9037050729c703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 5, 2014 at 2:39 PM, tim panton wrote: > > On 5 Nov 2014, at 19:44, Daniel-Constantin Mierla > wrote: > > > On 05/11/14 20:09, tim panton wrote: > > On 5 Nov 2014, at 17:46, Daniel-Constantin Mierla > wrote: > > On 05/11/14 18:16, Victor Pascual Avila wrote: > > On Tue, Nov 4, 2014 at 6:01 PM, tim panton wrote: > > All implementations of the rtcweb specification must implement at least > one of VP8 or H.264, > implementations that also implement the w3c=E2=80=99s webRTC javascript = API must > implement both VP8 and H264 > > I'd be OK with that > > I don't see any reason to split on JavaScript API implementations and > the rest. > > Moreover, looking back, the web browsers (and the web ecosystem itself) > got to this level mainly due to open source implementations, via > khtml/webkit and gecko/firefox (then servers and other tools), which at > some point were small and not benefiting of any substantial resources. > If any of "must implement" requirements adds limits (financial or not) > to the usage in any kind of major open source licensing models, it is > going to block a lot of innovation and disruption in the field. > > Better the freedom to negotiate anything and fail to find some common > grounds in a session than building a walled garden for 'the chosen ones' > -- hopefully the aim is not to build a new pstn-like ecosystem. > > I accept that argument, to an extent. However I think the costs of > producing an all new browser > are now so high that the H264 license won=E2=80=99t be the blocker. I hav= e no > evidence for this opinion. > > > I don't want to rule out the possibility of having a completely new > implementation. > > > I=E2=80=99m not ruling it out, I just claim that any full fresh implement= ation of > all the w3c specs > would be an order of magnitude more expensive to produce than the maximum > cost of the H264 license. > I admit that I have no evidence to back that view. > > Anyhow, by the nature of open source, if someone doesn't like the path a > project goes, then the project can forked. Even the big players that > could eventually afford plenty of resources do that: webkit was started > by apple as fork of khtml, (afaik) blink from chrome is forked from webki= t. > > We already have small players around (khtml is still there, popular > within kde) or tailored versions (debian ships own browser built out of > mozilla code - > > http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_th= e_Debian_project > ). > > > Agreed, the worst aspect of any adoption of H264 is that it makes it > significantly more difficult to > produce a custom =E2=80=99secure=E2=80=99 build of firefox that has been = independently > reviewed for special use-cases > (press, humanitarian workers etc). > Why is this true? We currently build OpenH264 and then send the binary to Cisco but keep a hash for comparison. Why is it more difficult to review this? -Ekr I suspect those users might be prepared to forego the =E2=80=98w3c webRTC c= ompliant=E2=80=99 > logo in exchange for increased security. > > Khtml is interesting - it isn=E2=80=99t a browser, it is a component (I t= hink) - > ideally it would come under the =E2=80=98either=E2=80=99 codec > rule - but since it implements a javascript API it falls into the =E2=80= =98wrong=E2=80=99 > category. Konquorer is the browser app I think? > > > The combination of the Cisco h264 plugin ugliness and the exposure of h26= 4 > hardware on iOS also > mitigate the problem. It is however still a problem, but on balance havin= g > no webRTC MTI for video is > worse IMHO. > > > Any kind of restricting the freedom to implement open protocols/specs is > worse than no MTI for video, IMO. > > > I am very keen to avoid a restriction at the protocol (IETF) level, but > feel it is marginally acceptable at the > API (w3c) layer for those who choose to implement the full spec. > > Tim. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8f3bad459b9037050729c703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 5, 2014 at 2:39 PM, tim panton <tim@phonefromhere.com<= /a>> wrote:


=

On 0= 5/11/14 20:09, tim panton wrote:
On 5 Nov 2014= , at 17:46, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

On 05/11/14 18:16, Victor Pascual Avila wrote:
On Tue, Nov 4, 2014 at 6:01 PM, tim panton <tim@phonefromhere.com> w= rote:
All implementations of the rtcweb specif= ication must implement at least one of =C2=A0VP8 or H.264,
implementatio= ns that also implement the w3c=E2=80=99s webRTC javascript =C2=A0API must i= mplement =C2=A0both VP8 and H264
I'd be OK with that
I don't see any reason to split on JavaScript API impleme= ntations and
the rest.

Moreover, looking back, the web browsers (= and the web ecosystem itself)
got to this level mainly due to open sourc= e implementations, via
khtml/webkit and gecko/firefox (then servers and = other tools), which at
some point were small and not benefiting of any s= ubstantial resources.
If any of "must implement" requirements = adds limits (financial or not)
to the usage in any kind of major open so= urce licensing models, it is
going to block a lot of innovation and disr= uption in the field.

Better the freedom to negotiate anything and fa= il to find some common
grounds in a session than building a walled garde= n for 'the chosen ones'
-- hopefully the aim is not to build a n= ew pstn-like ecosystem.
I accept that argument, to an exten= t. However I think the costs of producing an all new browser
are now so = high that the H264 license won=E2=80=99t be the blocker. I have no evidence= for this opinion.

I don't want to rule out the pos= sibility of having a completely new
implementation.


I=E2=80=99m not ruling it out, I just claim that any = full fresh implementation of all the w3c specs
would be an order = of magnitude more expensive to produce than the maximum cost of the H264 li= cense.
I admit that I have no evidence to back that view.

Anyhow, by the nature of open source, = if someone doesn't like the path a
project goes, then the project ca= n forked. Even the big players that
could eventually afford plenty of re= sources do that: webkit was started
by apple as fork of khtml, (afaik) b= link from chrome is forked from webkit.

We already have small player= s around (khtml is still there, popular
within kde) or tailored versions= (debian ships own browser built out of
mozilla code -
http://en.wikipedia.org/wiki/Mozilla_Corpora= tion_software_rebranded_by_the_Debian_project).
<= div>
Agreed, the worst aspect of any adoption of H264 = is that it makes it significantly more difficult to
produce a cus= tom =E2=80=99secure=E2=80=99 build of firefox that has been independently r= eviewed for special use-cases
(press, humanitarian workers etc).<= /div>

Why is this true? We curr= ently build OpenH264 and then send the binary to
Cisco but keep a= hash for comparison. Why is it more difficult to review this?
-Ekr

I suspect those users might be pre= pared to forego the =E2=80=98w3c webRTC compliant=E2=80=99
logo i= n exchange for increased security.

Khtml is intere= sting - it isn=E2=80=99t a browser, it is a component (I think) - ideally i= t would come under the =E2=80=98either=E2=80=99 codec
rule - but = since it implements a javascript API it falls into the =E2=80=98wrong=E2=80= =99 category. Konquorer is the browser app I think?
<= br>

The combination of the C= isco h264 plugin ugliness and the exposure of h264 hardware on iOS also
= mitigate the problem. It is however still a problem, but on balance having = no webRTC MTI for video is=C2=A0
worse IMHO.

Any kind of restricting the freedom to implement open protocols/specs= is
worse than no MTI for video, IMO.

I am very keen to avoid a restriction at the protocol (IETF)= level, but feel it is marginally acceptable at the
API (w3c) lay= er for those who choose to implement the full spec.

Tim.
=C2=A0

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


--e89a8f3bad459b9037050729c703-- From nobody Wed Nov 5 23:27:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E121A0178 for ; Wed, 5 Nov 2014 23:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze0E_XwAKjyz for ; Wed, 5 Nov 2014 23:27:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049DB1A1A9C for ; Wed, 5 Nov 2014 23:09:29 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-b9-545b1e74b4a8 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.5F.04387.47E1B545; Thu, 6 Nov 2014 08:08:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Thu, 6 Nov 2014 08:08:36 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "Daniel-Constantin Mierla" Thread-Topic: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) Thread-Index: AQHP+FAjdcYQh7hIuECI9qcwsQmDVQ== Date: Thu, 6 Nov 2014 07:08:34 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0B29AA@ESESSMB209.ericsson.se> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW6JXHSIQcc8DYvp+2wsNs1bwGKx 9l87uwOzx7mG9+weO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAlfGkyUn2AtecFcc3n+bqYHx LGcXIweHhICJxPn9bl2MnECmmMSFe+vZuhi5OIQEjjBKTDk0ixnCWcwo8eD2ZWaQKjaBQImt +xawgdgiAtkSp2asYwKxmQXUJe4sPscOYgsD1TzfcY8FoiZI4sjjv1C2nsTip99YQWwWARWJ SVtvMYLYvAK+Eu/23Yfa/JxJ4vPeF2ALGIFO+n5qDdQCcYlbT+YzQZwqILFkz3lmCFtU4uXj f6wQtpLEotufoer1JG5MncIGYWtLLFv4mhlimaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiy ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwdg5u+W21g/Hgc8dDjAIcjEo8vAZPokKEWBPL iitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjvL1HY4JDdki0U6Jh gy13xML67oRysT/rNs/6L2Pze/kL5fUHjBOKVtbIs02XjL9a+l3hkvO97AW64coHUgPYj3II HfNry9JwbK/0zU0VdxbLr5jTNU3Hv1Dpvb6ADXuFUJ4It9rzg6c4VRhDPZZlaBqky2RuilJr Cfcz/KGZ7lz98sMJJZbijERDLeai4kQAzOCNSH4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L_RihO5b68O7tS2_SR5Mod78yf8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 07:27:13 -0000 On 05/11/14 19:39, I=F1aki Baz Castillo wrote:=0A= > 2014-11-05 18:46 GMT+01:00 Daniel-Constantin Mierla := =0A= >> I don't see any reason to split on JavaScript API implementations and=0A= >> the rest.=0A= >>=0A= >> Moreover, looking back, the web browsers (and the web ecosystem itself)= =0A= >> got to this level mainly due to open source implementations, via=0A= >> khtml/webkit and gecko/firefox (then servers and other tools), which at= =0A= >> some point were small and not benefiting of any substantial resources.= =0A= >> If any of "must implement" requirements adds limits (financial or not)= =0A= >> to the usage in any kind of major open source licensing models, it is=0A= >> going to block a lot of innovation and disruption in the field.=0A= >>=0A= >> Better the freedom to negotiate anything and fail to find some common=0A= >> grounds in a session than building a walled garden for 'the chosen ones'= =0A= >> -- hopefully the aim is not to build a new pstn-like ecosystem.=0A= >=0A= >=0A= > Very good point.=0A= >=0A= > Chrome exists thanks to an open source project. It wouldn't be fair=0A= > that now Chrome gets something that other users of the same source=0A= > project are not allowed to use due to the licensing business model of=0A= =0A= (To my understanding Chrome already contains a lot that is not part of =0A= Chromium - e.g. H.264, Flash, and pdf support. Not meant as an argument =0A= in any direction, just FYI.)=0A= =0A= =0A= From nobody Wed Nov 5 23:27:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510A31A0378 for ; Wed, 5 Nov 2014 23:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgbBbWqnqytX for ; Wed, 5 Nov 2014 23:27:43 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCC71A0117 for ; Wed, 5 Nov 2014 23:27:38 -0800 (PST) Received: (qmail 68576 invoked from network); 6 Nov 2014 07:27:34 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 674 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 6 Nov 2014 07:27:34 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 8ED5E18A0690; Thu, 6 Nov 2014 07:27:34 +0000 (GMT) Received: from [192.168.42.182] (unknown [212.183.140.50]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id ADFEC18A01B0; Thu, 6 Nov 2014 07:27:33 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB9C3AD9-ABF1-40D4-BA97-EDF974323F85" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: Date: Thu, 6 Nov 2014 07:27:33 +0000 Message-Id: <960E08D9-D916-4091-ADF8-4BF08E0A150D@phonefromhere.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VZHIZtB5JpR89w_XaSNp6tt442g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 07:27:46 -0000 --Apple-Mail=_DB9C3AD9-ABF1-40D4-BA97-EDF974323F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 6 Nov 2014, at 05:14, Eric Rescorla wrote: >=20 >=20 > On Wed, Nov 5, 2014 at 2:39 PM, tim panton = wrote: >=20 > On 5 Nov 2014, at 19:44, Daniel-Constantin Mierla = wrote: >=20 >>=20 >> On 05/11/14 20:09, tim panton wrote: >>> On 5 Nov 2014, at 17:46, Daniel-Constantin Mierla = wrote: >>>=20 >>>> On 05/11/14 18:16, Victor Pascual Avila wrote: >>>>> On Tue, Nov 4, 2014 at 6:01 PM, tim panton = wrote: >>>>>> All implementations of the rtcweb specification must implement at = least one of VP8 or H.264, >>>>>> implementations that also implement the w3c=92s webRTC javascript = API must implement both VP8 and H264 >>>>> I'd be OK with that >>>> I don't see any reason to split on JavaScript API implementations = and >>>> the rest. >>>>=20 >>>> Moreover, looking back, the web browsers (and the web ecosystem = itself) >>>> got to this level mainly due to open source implementations, via >>>> khtml/webkit and gecko/firefox (then servers and other tools), = which at >>>> some point were small and not benefiting of any substantial = resources. >>>> If any of "must implement" requirements adds limits (financial or = not) >>>> to the usage in any kind of major open source licensing models, it = is >>>> going to block a lot of innovation and disruption in the field. >>>>=20 >>>> Better the freedom to negotiate anything and fail to find some = common >>>> grounds in a session than building a walled garden for 'the chosen = ones' >>>> -- hopefully the aim is not to build a new pstn-like ecosystem. >>> I accept that argument, to an extent. However I think the costs of = producing an all new browser >>> are now so high that the H264 license won=92t be the blocker. I have = no evidence for this opinion. >>=20 >> I don't want to rule out the possibility of having a completely new >> implementation. >>=20 >=20 > I=92m not ruling it out, I just claim that any full fresh = implementation of all the w3c specs > would be an order of magnitude more expensive to produce than the = maximum cost of the H264 license. > I admit that I have no evidence to back that view. >=20 >> Anyhow, by the nature of open source, if someone doesn't like the = path a >> project goes, then the project can forked. Even the big players that >> could eventually afford plenty of resources do that: webkit was = started >> by apple as fork of khtml, (afaik) blink from chrome is forked from = webkit. >>=20 >> We already have small players around (khtml is still there, popular >> within kde) or tailored versions (debian ships own browser built out = of >> mozilla code - >> = http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the= _Debian_project). >=20 > Agreed, the worst aspect of any adoption of H264 is that it makes it = significantly more difficult to > produce a custom =92secure=92 build of firefox that has been = independently reviewed for special use-cases > (press, humanitarian workers etc). >=20 > Why is this true? We currently build OpenH264 and then send the binary = to > Cisco but keep a hash for comparison. Why is it more difficult to = review this? >=20 > -Ekr I can=92t speak for people who actually do that build, but I imagine = that they would also need to review the plug-in mechanism, decide if downloading the plugin on first use = represents a threat in itself, decide how to protect the hash they use to do the comparison and factor in any = mechanisms for upgrades of the=20 plugin (and therefor changes in the hash). All of which would represent a significant effort beyond the pure code = review. I imagine most will simply remove the module from the build to save themselves the work. Tim. --Apple-Mail=_DB9C3AD9-ABF1-40D4-BA97-EDF974323F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 6 Nov 2014, at 05:14, Eric Rescorla = <ekr@rtfm.com> wrote:



On Wed, Nov 5, 2014 at 2:39 PM, tim panton <tim@phonefromhere.com> wrote:

On 5 Nov 2014, at 19:44, = Daniel-Constantin Mierla <miconda@gmail.com> wrote:


On = 05/11/14 20:09, tim panton wrote:
On 5 Nov = 2014, at 17:46, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

On 05/11/14 18:16, Victor Pascual Avila = wrote:
On Tue, Nov 4, 2014 at 6:01 PM, tim = panton <tim@phonefromhere.com> wrote:
All implementations of the rtcweb specification must = implement at least one of  VP8 or H.264,
implementations that = also implement the w3c=92s webRTC javascript  API must implement =  both VP8 and H264
I'd be OK with = that
I don't see any reason to split on JavaScript API = implementations and
the rest.

Moreover, looking back, the web = browsers (and the web ecosystem itself)
got to this level mainly due = to open source implementations, via
khtml/webkit and gecko/firefox = (then servers and other tools), which at
some point were small and = not benefiting of any substantial resources.
If any of "must = implement" requirements adds limits (financial or not)
to the usage = in any kind of major open source licensing models, it is
going to = block a lot of innovation and disruption in the field.

Better the = freedom to negotiate anything and fail to find some common
grounds in = a session than building a walled garden for 'the chosen ones'
-- = hopefully the aim is not to build a new pstn-like = ecosystem.
I accept that argument, to an extent. However = I think the costs of producing an all new browser
are now so high = that the H264 license won=92t be the blocker. I have no evidence for = this opinion.

I don't want to rule out the = possibility of having a completely = new
implementation.


I=92m = not ruling it out, I just claim that any full fresh implementation of = all the w3c specs
would be an order of magnitude more = expensive to produce than the maximum cost of the H264 = license.
I admit that I have no evidence to back that = view.

Anyhow, by the nature of open source, if = someone doesn't like the path a
project goes, then the project can = forked. Even the big players that
could eventually afford plenty of = resources do that: webkit was started
by apple as fork of khtml, = (afaik) blink from chrome is forked from webkit.

We already have = small players around (khtml is still there, popular
within kde) or = tailored versions (debian ships own browser built out of
mozilla code = -
http://en.wikipedia.org/wiki/Mozilla_Corporation_softwar= e_rebranded_by_the_Debian_project).

Agreed, the worst aspect of any adoption of H264 is that = it makes it significantly more difficult to
produce a custom = =92secure=92 build of firefox that has been independently reviewed for = special use-cases
(press, humanitarian workers = etc).

Why is this = true? We currently build OpenH264 and then send the binary = to
Cisco but keep a hash for comparison. Why is it more = difficult to review = this?

-Ekr

I can=92t speak for people who actually do that build, but I imagine = that they would also need to review
the plug-in mechanism, = decide if downloading the plugin on first use represents a threat in = itself, decide
how to protect the hash they use to do the = comparison and factor in any mechanisms for upgrades of = the 
plugin (and therefor changes in the = hash).
All of which would represent a significant effort = beyond the pure code review. I imagine most will simply remove = the
module from the build to save themselves the = work.

Tim.


= --Apple-Mail=_DB9C3AD9-ABF1-40D4-BA97-EDF974323F85-- From nobody Wed Nov 5 23:34:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5751A1A19E3 for ; Wed, 5 Nov 2014 23:34:30 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnEiuhZAnN9A for ; Wed, 5 Nov 2014 23:34:28 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE561A07BE for ; Wed, 5 Nov 2014 23:34:28 -0800 (PST) Received: (qmail 79652 invoked from network); 6 Nov 2014 07:34:27 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 702 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 6 Nov 2014 07:34:27 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 54FC218A0690; Thu, 6 Nov 2014 07:34:27 +0000 (GMT) Received: from [192.168.42.182] (unknown [212.183.140.50]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9A89518A01B0; Thu, 6 Nov 2014 07:34:26 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: Date: Thu, 6 Nov 2014 07:34:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <71320B71-FFC2-40A1-B1AF-F6EB8FDA8073@phonefromhere.com> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <6CFBDDC9-E38B-4354-BCB1-B0DA93D533E2@phonefromhere.com> <545AD0AC.4010204@pickering.org> To: Roman Shpount X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GEjmKZdldl4jBza_w6adk4HlKZ4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 07:34:30 -0000 On 6 Nov 2014, at 03:03, Roman Shpount wrote: > On Wed, Nov 5, 2014 at 8:36 PM, Rob Pickering = wrote: >=20 > +1 to the proposal and sane to dodge the bullet >=20 > Perhaps that should read "implementations that also *expose* the w3c's = javascript API" otherwise there is an interesting case where a compiled = mobile app isn't a "browser", but the same app using one of the JS app = frameworks internally is. Externally they have essentially the same = characteristics. >=20 > Does this mean that node.js, must support H.264 if it implements W3C = javascript API? I doubt anybody will call it a browser. My formulation was "implementations that also implement the w3c=92s = webRTC javascript API must implement both VP8 and H264" I=92d be surprised if node implemented all of w3c=92s webRTC api - for = example the
--047d7bf0d0f61c2d0d0507371bc3-- From nobody Thu Nov 6 13:46:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002D1A90BA for ; Thu, 6 Nov 2014 13:46:22 -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 KNWCUejlDZgB for ; Thu, 6 Nov 2014 13:46:20 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CC61A90BF for ; Thu, 6 Nov 2014 13:46:19 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id i57so649626yha.0 for ; Thu, 06 Nov 2014 13:46: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=WsOnvFnG0VocA1F6+KWsrwbgqaqdvDWs99Am74O2L4s=; b=f7cwZ1b7dYJNWohmzCE8bFeeBF09kENSjb29ODZ2lp2F9kf7X6+qpmyS/UU1zrwses 4vysWSdR1XDZjgDU15T6fRa8b7zhbwgsaBXknhhi7ENQeTtzZaBcnHeZk1R3g6gDVIpb DhxEJv6V2yaWQhqltvHRQJxPtGl7nrzXH2wusJ1FfP+yMjSfHhjVQ9DKidScUX6IpEwb 23yXjLVp7R2BjMdXmmIdBmgSAI1Uesegc8VWfU3w7t0ss23Nq1981cUQLMmS8KJ9WM5C ex8OjGkDmV+J4Ne5ip//1MJyLxHzZzMNyBveZoJXci/FuvaU/CRRL8kZx0piNM6K/qE8 HPGg== MIME-Version: 1.0 X-Received: by 10.170.37.75 with SMTP id 72mr7774598ykf.15.1415310378807; Thu, 06 Nov 2014 13:46:18 -0800 (PST) Received: by 10.170.171.193 with HTTP; Thu, 6 Nov 2014 13:46:18 -0800 (PST) Received: by 10.170.171.193 with HTTP; Thu, 6 Nov 2014 13:46:18 -0800 (PST) In-Reply-To: <20141106210038.GI8092@hex.shelbyville.oz> References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <20141106210038.GI8092@hex.shelbyville.oz> Date: Fri, 7 Nov 2014 08:46:18 +1100 Message-ID: From: Silvia Pfeiffer To: Ron Content-Type: multipart/alternative; boundary=001a113787a2603aaf050737a053 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IqJtbnz6X4jKdQ4wxV4-_6UFpX0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:46:22 -0000 --001a113787a2603aaf050737a053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 That's the best summary of our current state wrt MTI that I've heard. Best Regards, Silvia. On 7 Nov 2014 08:01, "Ron" wrote: > On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote: > > We are also working with Red Hat on a potential Gstreamer plugin. > > We would be happy to work with Debian or anyone else on other wrappers > > for projects that want to download some wrapper format beyond the raw > > library. > > > > It would be ideal to have a single binary (per platform) that works for > > all applications, without many different wrappers. That was the goal of > > the raw library, but apparently this is not sufficient for most project= s. > > Until we reach an acceptable common wrapper (with verifiable builds), > > we=C2=B9re happy to have folks contribute their desired wrapper for hos= ting. > > Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They > > were first to contribute, so they were hosted first, not due to any > > special privilege. > > For Debian, this gets complicated really quickly on lots of fronts, > not the least being the basic principle of not entering into licence > agreements that don't apply equally to everybody. If someone with a > copy of Debian doesn't have the same rights to use/distribute/modify > it as Debian itself does, then it doesn't meet even the most basic > test of "is it Free/Open". > > While the IETF does give working groups some freedom to make exceptions > where exceptional circumstances might justify it, I do think that the > aspirational requirements for freedom to implement proposed standards > are fairly closely aligned to what Debian requires more strictly. > > > I agree that reproducible builds would go some way toward making a > "single binary" more viable - but that also is a Hard Problem, and > while people are working on it, I don't see it being universally > solved before H.264 has gone the same way as H.261 has. It does > also still leave the problem of people needing custom and/or urgent > fixes, whether for security reasons or simply because of some show > stopper bug that might be specific to some narrow use case. > > What happens when fixing that bug for your app causes somebody else's > app to break because of some other assumption they made in their code? > Who gets to decide whose app gets to stay broken? > > > I definitely appreciate the good will that Cisco has put into trying > to find viable answers for other groups that would allow its preferred > choice to actually be a viable one, but at the end of the day it is a > hack around the H.264 licencing, and I don't think we're really even > close to having charted the full extent of the thin ice that it is > currently floating on. The cap announced for H.265 definitely appears > to have responded to this challenge already ... > > So the question for me at this stage still really is: > > What exceptional circumstances exist to justify this group deciding > to go out on such a thin and completely untested limb, to mandate a > technology that is so obviously, and undisputedly, encumbered? > > Especially when we have an alternative choice available to us which is > its technical equal, and for which the equivalent encumberance is, at > best, still the untested assertion of a few far-from-unbiased parties. > > > I'm not ruling out that there may be *some* solution which makes H.264 > viable without needing to resort to Clever Hacks, but so far we seem > to be still well short of that. At the same time, VP8 is currently > under consideration to become an international standard. And there are > other codecs under development which may change the facts on the ground > too before the work of this group is completed. > > I do think we want an MTI video codec, but it's less clear we need to > rush this decision while things that may be quite pertinent to it are > still evolving in new and potentially game changing ways. > > > > On 11/6/14, 1:29 PM, Ron wrote: > > On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: > > > On Wed, Nov 5, 2014 at 2:39 PM, tim panton > wrote: > > > > > > > > Agreed, the worst aspect of any adoption of H264 is that it makes i= t > > > > significantly more difficult to > > > > produce a custom =C2=B9secure=C2=B9 build of firefox that has been > independently > > > > reviewed for special use-cases > > > > (press, humanitarian workers etc). > > > > > > Why is this true? We currently build OpenH264 and then send the binar= y > to > > > Cisco but keep a hash for comparison. Why is it more difficult to > review > > > this? > > > > Is Cisco offering to ship such binaries for anyone who wants to build > > them, or is this a special privilege they offered to you to win your > > support for their scheme? > > > > Ron > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113787a2603aaf050737a053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1
That's the best summary of our current state wrt MTI that I've hear= d.

Best Regards,
Silvia.

On 7 Nov 2014 08:01, "Ron" <ron@debian.org> wrote:
On Thu, Nov 06, 2014 at 07:11:21PM +00= 00, Mo Zanaty (mzanaty) wrote:
> We are also working with Red Hat on a potential Gstreamer plugin.
> We would be happy to work with Debian or anyone else on other wrappers=
> for projects that want to download some wrapper format beyond the raw<= br> > library.
>
> It would be ideal to have a single binary (per platform) that works fo= r
> all applications, without many different wrappers. That was the goal o= f
> the raw library, but apparently this is not sufficient for most projec= ts.
> Until we reach an acceptable common wrapper (with verifiable builds),<= br> > we=C2=B9re happy to have folks contribute their desired wrapper for ho= sting.
> Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They=
> were first to contribute, so they were hosted first, not due to any > special privilege.

For Debian, this gets complicated really quickly on lots of fronts,
not the least being the basic principle of not entering into licence
agreements that don't apply equally to everybody.=C2=A0 If someone with= a
copy of Debian doesn't have the same rights to use/distribute/modify it as Debian itself does, then it doesn't meet even the most basic
test of "is it Free/Open".

While the IETF does give working groups some freedom to make exceptions
where exceptional circumstances might justify it, I do think that the
aspirational requirements for freedom to implement proposed standards
are fairly closely aligned to what Debian requires more strictly.


I agree that reproducible builds would go some way toward making a
"single binary" more viable - but that also is a Hard Problem, an= d
while people are working on it, I don't see it being universally
solved before H.264 has gone the same way as H.261 has.=C2=A0 It does
also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case.

What happens when fixing that bug for your app causes somebody else's app to break because of some other assumption they made in their code?
Who gets to decide whose app gets to stay broken?


I definitely appreciate the good will that Cisco has put into trying
to find viable answers for other groups that would allow its preferred
choice to actually be a viable one, but at the end of the day it is a
hack around the H.264 licencing, and I don't think we're really eve= n
close to having charted the full extent of the thin ice that it is
currently floating on.=C2=A0 The cap announced for H.265 definitely appears=
to have responded to this challenge already ...

So the question for me at this stage still really is:

=C2=A0What exceptional circumstances exist to justify this group deciding =C2=A0to go out on such a thin and completely untested limb, to mandate a =C2=A0technology that is so obviously, and undisputedly, encumbered?

Especially when we have an alternative choice available to us which is
its technical equal, and for which the equivalent encumberance is, at
best, still the untested assertion of a few far-from-unbiased parties.


I'm not ruling out that there may be *some* solution which makes H.264<= br> viable without needing to resort to Clever Hacks, but so far we seem
to be still well short of that.=C2=A0 At the same time, VP8 is currently under consideration to become an international standard. And there are
other codecs under development which may change the facts on the ground
too before the work of this group is completed.

I do think we want an MTI video codec, but it's less clear we need to rush this decision while things that may be quite pertinent to it are
still evolving in new and potentially game changing ways.


> On 11/6/14, 1:29 PM, Ron <ron@deb= ian.org> wrote:
> On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote:
> > On Wed, Nov 5, 2014 at 2:39 PM, tim panton <tim@phonefromhere.com> wrote:
> > >
> > > Agreed, the worst aspect of any adoption of H264 is that it = makes it
> > > significantly more difficult to
> > > produce a custom =C2=B9secure=C2=B9 build of firefox that ha= s been independently
> > > reviewed for special use-cases
> > > (press, humanitarian workers etc).
> >
> > Why is this true? We currently build OpenH264 and then send the b= inary to
> > Cisco but keep a hash for comparison. Why is it more difficult to= review
> > this?
>
> Is Cisco offering to ship such binaries for anyone who wants to build<= br> > them, or is this a special privilege they offered to you to win your > support for their scheme?
>
>=C2=A0 =C2=A0Ron

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--001a113787a2603aaf050737a053-- From nobody Thu Nov 6 13:52:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0557B1A701A for ; Thu, 6 Nov 2014 13:52:13 -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 9EAKRl4GsNC2 for ; Thu, 6 Nov 2014 13:52:09 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7801A90C9 for ; Thu, 6 Nov 2014 13:52:09 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id r20so2830700wiv.16 for ; Thu, 06 Nov 2014 13:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1bK8SnE9h41NycfKj2ZZJTq5nFNTBkLJyBC8tv6M0wI=; b=lHK1tL8DFEgcw57ne8XoUub7DjBFk1w8gJXPA+bmCpR7hWsul86FTk2dOmOU7WeICQ uiYB9m6+ij9kTMbjeRxXKPw5z+VYMacUzonAJl0CZnymxPExQ2hRvPVQcEL8T3YTwdgh lPN2fIjOCtdeZTRQNV8+gafR/ZgbqI24k/e5ILxd0sI9rkzeIXs5LwJDjP7PIWCWUxKl i/dDHaYwlzx6rWIjBM2L1ruaxEeuURUzl5R2IkyWxGie8c94hvlfQBZtDPDxRzRrlIZz dmgXHeUrxPyhqLyyJlTg3hb4zjx4f6YR9dZlezx9SOaFP1/VsTd7NZwdoH1uc38dZsmy 1dhA== X-Received: by 10.194.222.162 with SMTP id qn2mr10018374wjc.74.1415310728352; Thu, 06 Nov 2014 13:52:08 -0800 (PST) Received: from [192.168.0.195] ([95.61.111.78]) by mx.google.com with ESMTPSA id q9sm21078547wix.6.2014.11.06.13.52.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 13:52:07 -0800 (PST) Message-ID: <545BED88.7090702@gmail.com> Date: Thu, 06 Nov 2014 22:52:08 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p_nDUY86gpd_4GTVb8DG6JI5Ipg Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:52:13 -0000 On of my biggest concerns with VP8 is the lack of alternatives, as libvpx has been quite unstable for a while (too many seg-faults if input was corrupted), but at least I had the ability to compile and use my own version. With Cisco binary, not only I don't have any free-alternative, but I can't even compile and use my own version! No way. BR Sergio On 06/11/2014 20:11, Mo Zanaty (mzanaty) wrote: > We are also working with Red Hat on a potential Gstreamer plugin. > We would be happy to work with Debian or anyone else on other wrappers > for projects that want to download some wrapper format beyond the raw > library. > > It would be ideal to have a single binary (per platform) that works for > all applications, without many different wrappers. That was the goal of > the raw library, but apparently this is not sufficient for most projects. > Until we reach an acceptable common wrapper (with verifiable builds), > we¹re happy to have folks contribute their desired wrapper for hosting. > Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They > were first to contribute, so they were hosted first, not due to any > special privilege. > > Mo > > On 11/6/14, 1:29 PM, Ron wrote: > On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: >> On Wed, Nov 5, 2014 at 2:39 PM, tim panton wrote: >>> Agreed, the worst aspect of any adoption of H264 is that it makes it >>> significantly more difficult to >>> produce a custom ¹secure¹ build of firefox that has been independently >>> reviewed for special use-cases >>> (press, humanitarian workers etc). >> Why is this true? We currently build OpenH264 and then send the binary to >> Cisco but keep a hash for comparison. Why is it more difficult to review >> this? > Is Cisco offering to ship such binaries for anyone who wants to build > them, or is this a special privilege they offered to you to win your > support for their scheme? > Ron > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Nov 6 13:55:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5F11A90E0 for ; Thu, 6 Nov 2014 13:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvnVBoz_AWwG for ; Thu, 6 Nov 2014 13:55:52 -0800 (PST) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFC31A9051 for ; Thu, 6 Nov 2014 13:55:51 -0800 (PST) Received: by mail-qg0-f50.google.com with SMTP id a108so1487390qge.37 for ; Thu, 06 Nov 2014 13:55:51 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=AVxQZ3JqEkYI9cR7OMSl2aqsweD7Nnn6NJJTez7VlMs=; b=X/uQr0iCF121E8uh6385ClYC7CrUgm2WQ0HYQR+kVAOqoRv91M9KLTakHgW/LU1VOF Dg5IjpjxR/Jp1DEGcOHjuOnOnOor9xoMKT0pdRUgbk4oe5FPKnN18tZsdpTW5XEE8AnL BofO8W9/0bU5KBJ/xvVUKH8XXR9+F8Y/EbvnuQFpUBdhQLPwu2EPypM2oQ+lk0FpMDIy gWp2YoGSVxDZ3E5QXE3RAo3a8ImXCrsJfVWmq5h8/qxKwU5bJsRwKWs6tCb4HHB0NOgI inVR/q0RsaZ48Waof0oNKc3Ulho3PKYfMIheqb1/rFEaFYMicAYKEQGTIKpmYUZd5Ekl i9Yg== X-Gm-Message-State: ALoCoQnLN/ut/muMjmErSJC6CPse1nKjeZyxfv3+isz+mDPnNGTq+Led6gpvXw9QKYuyXCZTlW80 X-Received: by 10.224.151.67 with SMTP id b3mr11376520qaw.6.1415310951247; Thu, 06 Nov 2014 13:55:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 6 Nov 2014 13:55:30 -0800 (PST) In-Reply-To: <20141106210038.GI8092@hex.shelbyville.oz> References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <20141106210038.GI8092@hex.shelbyville.oz> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 6 Nov 2014 22:55:30 +0100 Message-ID: To: Ron Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r6luSS7PJYKulzyy9dN4Z3RFk-4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:55:53 -0000 +1 I just hope that those promoting H264 have something to say about this instead of ignoring this great and realistic rationale. 2014-11-06 22:00 GMT+01:00 Ron : > On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote: >> We are also working with Red Hat on a potential Gstreamer plugin. >> We would be happy to work with Debian or anyone else on other wrappers >> for projects that want to download some wrapper format beyond the raw >> library. >> >> It would be ideal to have a single binary (per platform) that works for >> all applications, without many different wrappers. That was the goal of >> the raw library, but apparently this is not sufficient for most projects= . >> Until we reach an acceptable common wrapper (with verifiable builds), >> we=C2=B9re happy to have folks contribute their desired wrapper for host= ing. >> Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They >> were first to contribute, so they were hosted first, not due to any >> special privilege. > > For Debian, this gets complicated really quickly on lots of fronts, > not the least being the basic principle of not entering into licence > agreements that don't apply equally to everybody. If someone with a > copy of Debian doesn't have the same rights to use/distribute/modify > it as Debian itself does, then it doesn't meet even the most basic > test of "is it Free/Open". > > While the IETF does give working groups some freedom to make exceptions > where exceptional circumstances might justify it, I do think that the > aspirational requirements for freedom to implement proposed standards > are fairly closely aligned to what Debian requires more strictly. > > > I agree that reproducible builds would go some way toward making a > "single binary" more viable - but that also is a Hard Problem, and > while people are working on it, I don't see it being universally > solved before H.264 has gone the same way as H.261 has. It does > also still leave the problem of people needing custom and/or urgent > fixes, whether for security reasons or simply because of some show > stopper bug that might be specific to some narrow use case. > > What happens when fixing that bug for your app causes somebody else's > app to break because of some other assumption they made in their code? > Who gets to decide whose app gets to stay broken? > > > I definitely appreciate the good will that Cisco has put into trying > to find viable answers for other groups that would allow its preferred > choice to actually be a viable one, but at the end of the day it is a > hack around the H.264 licencing, and I don't think we're really even > close to having charted the full extent of the thin ice that it is > currently floating on. The cap announced for H.265 definitely appears > to have responded to this challenge already ... > > So the question for me at this stage still really is: > > What exceptional circumstances exist to justify this group deciding > to go out on such a thin and completely untested limb, to mandate a > technology that is so obviously, and undisputedly, encumbered? > > Especially when we have an alternative choice available to us which is > its technical equal, and for which the equivalent encumberance is, at > best, still the untested assertion of a few far-from-unbiased parties. > > > I'm not ruling out that there may be *some* solution which makes H.264 > viable without needing to resort to Clever Hacks, but so far we seem > to be still well short of that. At the same time, VP8 is currently > under consideration to become an international standard. And there are > other codecs under development which may change the facts on the ground > too before the work of this group is completed. > > I do think we want an MTI video codec, but it's less clear we need to > rush this decision while things that may be quite pertinent to it are > still evolving in new and potentially game changing ways. > > >> On 11/6/14, 1:29 PM, Ron wrote: >> On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: >> > On Wed, Nov 5, 2014 at 2:39 PM, tim panton wro= te: >> > > >> > > Agreed, the worst aspect of any adoption of H264 is that it makes it >> > > significantly more difficult to >> > > produce a custom =C2=B9secure=C2=B9 build of firefox that has been i= ndependently >> > > reviewed for special use-cases >> > > (press, humanitarian workers etc). >> > >> > Why is this true? We currently build OpenH264 and then send the binary= to >> > Cisco but keep a hash for comparison. Why is it more difficult to revi= ew >> > this? >> >> Is Cisco offering to ship such binaries for anyone who wants to build >> them, or is this a special privilege they offered to you to win your >> support for their scheme? >> >> Ron > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 I=C3=B1aki Baz Castillo From nobody Thu Nov 6 13:56:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280FB1A90E5 for ; Thu, 6 Nov 2014 13:56:07 -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 PlyoDJXTKW5p for ; Thu, 6 Nov 2014 13:56:02 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E571A9084 for ; Thu, 6 Nov 2014 13:56:01 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so2850531wiv.13 for ; Thu, 06 Nov 2014 13:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=gi0rlJUGvH8bVBtsDmuYcNpAzv+mBd1Q35eds2sKB8Y=; b=I5Y83otuJtHPN+j+Bcl72H5jnCt8w4PfHV7Tgv2nL4cWI2BI4KSgKNd1glE+c4Wypl CiWfqGCyP/S8ZaaUD4OUHKXetm4cudcVfqAac+EHDuuMvAubc7DHgOGIES3Hd3D61W/D edq0/V1Egkrf1fU/WUfU3DnUgQxL24bu56Jw4HJjBdkDGdp76nFxnSYa2bAO6LxJn20S GlVZR0Rn+uwFHTtkpNMXIx3C73oa4MGV3033VMIkwluUmVIlqTtj1naCi+LGT/8YlPdk VkoScIiPZrXJ5wJhdzB5Io+P7gw3ynqdwJ+Tzi0EETvtSIjnB7+IvKb5O3miw+vOkgx8 WMJw== X-Received: by 10.180.186.175 with SMTP id fl15mr18890241wic.38.1415310960597; Thu, 06 Nov 2014 13:56:00 -0800 (PST) Received: from [192.168.0.195] ([95.61.111.78]) by mx.google.com with ESMTPSA id ht9sm21085555wib.8.2014.11.06.13.55.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 13:55:59 -0800 (PST) Message-ID: <545BEE70.8060402@gmail.com> Date: Thu, 06 Nov 2014 22:56:00 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <20141106210038.GI8092@hex.shelbyville.oz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040607040107010300040908" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4RibG3Vnv0klgdo9rx5Qljy3R6c Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:56:07 -0000 This is a multi-part message in MIME format. --------------040607040107010300040908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit +1, agree on all statements expecially: "It does also still leave the problem of people needing custom and/or urgent fixes, whether for security reasons or simply because of some show stopper bug that might be specific to some narrow use case." Been there too many times to not worry about it. BR Sergio On 06/11/2014 22:46, Silvia Pfeiffer wrote: > > +1 > That's the best summary of our current state wrt MTI that I've heard. > > Best Regards, > Silvia. > > On 7 Nov 2014 08:01, "Ron" > wrote: > > On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote: > > We are also working with Red Hat on a potential Gstreamer plugin. > > We would be happy to work with Debian or anyone else on other > wrappers > > for projects that want to download some wrapper format beyond > the raw > > library. > > > > It would be ideal to have a single binary (per platform) that > works for > > all applications, without many different wrappers. That was the > goal of > > the raw library, but apparently this is not sufficient for most > projects. > > Until we reach an acceptable common wrapper (with verifiable > builds), > > we¹re happy to have folks contribute their desired wrapper for > hosting. > > Mozilla contributed the Firefox Gecko Media Plugin (GMP) > wrapper. They > > were first to contribute, so they were hosted first, not due to any > > special privilege. > > For Debian, this gets complicated really quickly on lots of fronts, > not the least being the basic principle of not entering into licence > agreements that don't apply equally to everybody. If someone with a > copy of Debian doesn't have the same rights to use/distribute/modify > it as Debian itself does, then it doesn't meet even the most basic > test of "is it Free/Open". > > While the IETF does give working groups some freedom to make > exceptions > where exceptional circumstances might justify it, I do think that the > aspirational requirements for freedom to implement proposed standards > are fairly closely aligned to what Debian requires more strictly. > > > I agree that reproducible builds would go some way toward making a > "single binary" more viable - but that also is a Hard Problem, and > while people are working on it, I don't see it being universally > solved before H.264 has gone the same way as H.261 has. It does > also still leave the problem of people needing custom and/or urgent > fixes, whether for security reasons or simply because of some show > stopper bug that might be specific to some narrow use case. > > What happens when fixing that bug for your app causes somebody else's > app to break because of some other assumption they made in their code? > Who gets to decide whose app gets to stay broken? > > > I definitely appreciate the good will that Cisco has put into trying > to find viable answers for other groups that would allow its preferred > choice to actually be a viable one, but at the end of the day it is a > hack around the H.264 licencing, and I don't think we're really even > close to having charted the full extent of the thin ice that it is > currently floating on. The cap announced for H.265 definitely appears > to have responded to this challenge already ... > > So the question for me at this stage still really is: > > What exceptional circumstances exist to justify this group deciding > to go out on such a thin and completely untested limb, to mandate a > technology that is so obviously, and undisputedly, encumbered? > > Especially when we have an alternative choice available to us which is > its technical equal, and for which the equivalent encumberance is, at > best, still the untested assertion of a few far-from-unbiased parties. > > > I'm not ruling out that there may be *some* solution which makes H.264 > viable without needing to resort to Clever Hacks, but so far we seem > to be still well short of that. At the same time, VP8 is currently > under consideration to become an international standard. And there are > other codecs under development which may change the facts on the > ground > too before the work of this group is completed. > > I do think we want an MTI video codec, but it's less clear we need to > rush this decision while things that may be quite pertinent to it are > still evolving in new and potentially game changing ways. > > > > On 11/6/14, 1:29 PM, Ron > wrote: > > On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: > > > On Wed, Nov 5, 2014 at 2:39 PM, tim panton > > wrote: > > > > > > > > Agreed, the worst aspect of any adoption of H264 is that it > makes it > > > > significantly more difficult to > > > > produce a custom ¹secure¹ build of firefox that has been > independently > > > > reviewed for special use-cases > > > > (press, humanitarian workers etc). > > > > > > Why is this true? We currently build OpenH264 and then send > the binary to > > > Cisco but keep a hash for comparison. Why is it more difficult > to review > > > this? > > > > Is Cisco offering to ship such binaries for anyone who wants to > build > > them, or is this a special privilege they offered to you to win your > > support for their scheme? > > > > Ron > > _______________________________________________ > 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 --------------040607040107010300040908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
+1, agree on all statements expecially:

"It does also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case."

Been there too many times to not worry about it.

BR
Sergio

On 06/11/2014 22:46, Silvia Pfeiffer wrote:

+1
That's the best summary of our current state wrt MTI that I've heard.

Best Regards,
Silvia.

On 7 Nov 2014 08:01, "Ron" <ron@debian.org> wrote:
On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote:
> We are also working with Red Hat on a potential Gstreamer plugin.
> We would be happy to work with Debian or anyone else on other wrappers
> for projects that want to download some wrapper format beyond the raw
> library.
>
> It would be ideal to have a single binary (per platform) that works for
> all applications, without many different wrappers. That was the goal of
> the raw library, but apparently this is not sufficient for most projects.
> Until we reach an acceptable common wrapper (with verifiable builds),
> we¹re happy to have folks contribute their desired wrapper for hosting.
> Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They
> were first to contribute, so they were hosted first, not due to any
> special privilege.

For Debian, this gets complicated really quickly on lots of fronts,
not the least being the basic principle of not entering into licence
agreements that don't apply equally to everybody.  If someone with a
copy of Debian doesn't have the same rights to use/distribute/modify
it as Debian itself does, then it doesn't meet even the most basic
test of "is it Free/Open".

While the IETF does give working groups some freedom to make exceptions
where exceptional circumstances might justify it, I do think that the
aspirational requirements for freedom to implement proposed standards
are fairly closely aligned to what Debian requires more strictly.


I agree that reproducible builds would go some way toward making a
"single binary" more viable - but that also is a Hard Problem, and
while people are working on it, I don't see it being universally
solved before H.264 has gone the same way as H.261 has.  It does
also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case.

What happens when fixing that bug for your app causes somebody else's
app to break because of some other assumption they made in their code?
Who gets to decide whose app gets to stay broken?


I definitely appreciate the good will that Cisco has put into trying
to find viable answers for other groups that would allow its preferred
choice to actually be a viable one, but at the end of the day it is a
hack around the H.264 licencing, and I don't think we're really even
close to having charted the full extent of the thin ice that it is
currently floating on.  The cap announced for H.265 definitely appears
to have responded to this challenge already ...

So the question for me at this stage still really is:

 What exceptional circumstances exist to justify this group deciding
 to go out on such a thin and completely untested limb, to mandate a
 technology that is so obviously, and undisputedly, encumbered?

Especially when we have an alternative choice available to us which is
its technical equal, and for which the equivalent encumberance is, at
best, still the untested assertion of a few far-from-unbiased parties.


I'm not ruling out that there may be *some* solution which makes H.264
viable without needing to resort to Clever Hacks, but so far we seem
to be still well short of that.  At the same time, VP8 is currently
under consideration to become an international standard. And there are
other codecs under development which may change the facts on the ground
too before the work of this group is completed.

I do think we want an MTI video codec, but it's less clear we need to
rush this decision while things that may be quite pertinent to it are
still evolving in new and potentially game changing ways.


> On 11/6/14, 1:29 PM, Ron <ron@debian.org> wrote:
> On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote:
> > On Wed, Nov 5, 2014 at 2:39 PM, tim panton <tim@phonefromhere.com> wrote:
> > >
> > > Agreed, the worst aspect of any adoption of H264 is that it makes it
> > > significantly more difficult to
> > > produce a custom ¹secure¹ build of firefox that has been independently
> > > reviewed for special use-cases
> > > (press, humanitarian workers etc).
> >
> > Why is this true? We currently build OpenH264 and then send the binary to
> > Cisco but keep a hash for comparison. Why is it more difficult to review
> > this?
>
> Is Cisco offering to ship such binaries for anyone who wants to build
> them, or is this a special privilege they offered to you to win your
> support for their scheme?
>
>   Ron

_______________________________________________
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

--------------040607040107010300040908-- From nobody Thu Nov 6 13:56:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99291A90EF for ; Thu, 6 Nov 2014 13:56: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 nvGDwTq6GJaD for ; Thu, 6 Nov 2014 13:56:16 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B121A90EA for ; Thu, 6 Nov 2014 13:56:15 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so2850984wiv.13 for ; Thu, 06 Nov 2014 13:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=zOZk9P+I2KzmUFhn9JxBT00Wv/WhB62bv0KhOR5iniU=; b=RgqHYfKSFBFTNfgj6ZtdgAAb7Lam7Y4wKHk4G2pPaUaRIt9bUl2DvWaMdvezyqazcQ RTf1CbkYF4D63JitjVFlija/Q0j6ZHwYsgNsF+teUrbppPwmhGoPcxnosNyCbm/0b5Bw nCuWIgfN/RyR/fESm8T7PZ36CDNaGXgzKeENVGWW+0Y4IBnFg8p5ZgDCO2tmItFtGW2L qJMKhE9h3XxGGSD9TxBVHaqaBxpvYKJMapCIi13M6P4ddvulmbIuh/UQ0aIcD3cQ47ej yAj6XpFH/wg3AzUhL0WzqB08GACy646yW1Y5CfQSCiuZt26Shhg8rZ+CWbKqEjr2rIoa PErA== X-Received: by 10.180.104.105 with SMTP id gd9mr44616429wib.65.1415310974266; Thu, 06 Nov 2014 13:56:14 -0800 (PST) Received: from [192.168.0.195] ([95.61.111.78]) by mx.google.com with ESMTPSA id ud9sm9383113wjc.20.2014.11.06.13.56.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 13:56:13 -0800 (PST) Message-ID: <545BEE7E.1020501@gmail.com> Date: Thu, 06 Nov 2014 22:56:14 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <20141106210038.GI8092@hex.shelbyville.oz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040501060404060707040401" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0qtXiMcPVwMsRFImFMws_-N9QIE Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:56:21 -0000 This is a multi-part message in MIME format. --------------040501060404060707040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit +1, agree on all statements, especially: "It does also still leave the problem of people needing custom and/or urgent fixes, whether for security reasons or simply because of some show stopper bug that might be specific to some narrow use case." Been there too many times to not worry about it. BR Sergio On 06/11/2014 22:46, Silvia Pfeiffer wrote: > > +1 > That's the best summary of our current state wrt MTI that I've heard. > > Best Regards, > Silvia. > > On 7 Nov 2014 08:01, "Ron" > wrote: > > On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote: > > We are also working with Red Hat on a potential Gstreamer plugin. > > We would be happy to work with Debian or anyone else on other > wrappers > > for projects that want to download some wrapper format beyond > the raw > > library. > > > > It would be ideal to have a single binary (per platform) that > works for > > all applications, without many different wrappers. That was the > goal of > > the raw library, but apparently this is not sufficient for most > projects. > > Until we reach an acceptable common wrapper (with verifiable > builds), > > we¹re happy to have folks contribute their desired wrapper for > hosting. > > Mozilla contributed the Firefox Gecko Media Plugin (GMP) > wrapper. They > > were first to contribute, so they were hosted first, not due to any > > special privilege. > > For Debian, this gets complicated really quickly on lots of fronts, > not the least being the basic principle of not entering into licence > agreements that don't apply equally to everybody. If someone with a > copy of Debian doesn't have the same rights to use/distribute/modify > it as Debian itself does, then it doesn't meet even the most basic > test of "is it Free/Open". > > While the IETF does give working groups some freedom to make > exceptions > where exceptional circumstances might justify it, I do think that the > aspirational requirements for freedom to implement proposed standards > are fairly closely aligned to what Debian requires more strictly. > > > I agree that reproducible builds would go some way toward making a > "single binary" more viable - but that also is a Hard Problem, and > while people are working on it, I don't see it being universally > solved before H.264 has gone the same way as H.261 has. It does > also still leave the problem of people needing custom and/or urgent > fixes, whether for security reasons or simply because of some show > stopper bug that might be specific to some narrow use case. > > What happens when fixing that bug for your app causes somebody else's > app to break because of some other assumption they made in their code? > Who gets to decide whose app gets to stay broken? > > > I definitely appreciate the good will that Cisco has put into trying > to find viable answers for other groups that would allow its preferred > choice to actually be a viable one, but at the end of the day it is a > hack around the H.264 licencing, and I don't think we're really even > close to having charted the full extent of the thin ice that it is > currently floating on. The cap announced for H.265 definitely appears > to have responded to this challenge already ... > > So the question for me at this stage still really is: > > What exceptional circumstances exist to justify this group deciding > to go out on such a thin and completely untested limb, to mandate a > technology that is so obviously, and undisputedly, encumbered? > > Especially when we have an alternative choice available to us which is > its technical equal, and for which the equivalent encumberance is, at > best, still the untested assertion of a few far-from-unbiased parties. > > > I'm not ruling out that there may be *some* solution which makes H.264 > viable without needing to resort to Clever Hacks, but so far we seem > to be still well short of that. At the same time, VP8 is currently > under consideration to become an international standard. And there are > other codecs under development which may change the facts on the > ground > too before the work of this group is completed. > > I do think we want an MTI video codec, but it's less clear we need to > rush this decision while things that may be quite pertinent to it are > still evolving in new and potentially game changing ways. > > > > On 11/6/14, 1:29 PM, Ron > wrote: > > On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: > > > On Wed, Nov 5, 2014 at 2:39 PM, tim panton > > wrote: > > > > > > > > Agreed, the worst aspect of any adoption of H264 is that it > makes it > > > > significantly more difficult to > > > > produce a custom ¹secure¹ build of firefox that has been > independently > > > > reviewed for special use-cases > > > > (press, humanitarian workers etc). > > > > > > Why is this true? We currently build OpenH264 and then send > the binary to > > > Cisco but keep a hash for comparison. Why is it more difficult > to review > > > this? > > > > Is Cisco offering to ship such binaries for anyone who wants to > build > > them, or is this a special privilege they offered to you to win your > > support for their scheme? > > > > Ron > > _______________________________________________ > 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 --------------040501060404060707040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
+1, agree on all statements, especially:

"It does also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case."

Been there too many times to not worry about it.

BR
Sergio

On 06/11/2014 22:46, Silvia Pfeiffer wrote:

+1
That's the best summary of our current state wrt MTI that I've heard.

Best Regards,
Silvia.

On 7 Nov 2014 08:01, "Ron" <ron@debian.org> wrote:
On Thu, Nov 06, 2014 at 07:11:21PM +0000, Mo Zanaty (mzanaty) wrote:
> We are also working with Red Hat on a potential Gstreamer plugin.
> We would be happy to work with Debian or anyone else on other wrappers
> for projects that want to download some wrapper format beyond the raw
> library.
>
> It would be ideal to have a single binary (per platform) that works for
> all applications, without many different wrappers. That was the goal of
> the raw library, but apparently this is not sufficient for most projects.
> Until we reach an acceptable common wrapper (with verifiable builds),
> we¹re happy to have folks contribute their desired wrapper for hosting.
> Mozilla contributed the Firefox Gecko Media Plugin (GMP) wrapper. They
> were first to contribute, so they were hosted first, not due to any
> special privilege.

For Debian, this gets complicated really quickly on lots of fronts,
not the least being the basic principle of not entering into licence
agreements that don't apply equally to everybody.  If someone with a
copy of Debian doesn't have the same rights to use/distribute/modify
it as Debian itself does, then it doesn't meet even the most basic
test of "is it Free/Open".

While the IETF does give working groups some freedom to make exceptions
where exceptional circumstances might justify it, I do think that the
aspirational requirements for freedom to implement proposed standards
are fairly closely aligned to what Debian requires more strictly.


I agree that reproducible builds would go some way toward making a
"single binary" more viable - but that also is a Hard Problem, and
while people are working on it, I don't see it being universally
solved before H.264 has gone the same way as H.261 has.  It does
also still leave the problem of people needing custom and/or urgent
fixes, whether for security reasons or simply because of some show
stopper bug that might be specific to some narrow use case.

What happens when fixing that bug for your app causes somebody else's
app to break because of some other assumption they made in their code?
Who gets to decide whose app gets to stay broken?


I definitely appreciate the good will that Cisco has put into trying
to find viable answers for other groups that would allow its preferred
choice to actually be a viable one, but at the end of the day it is a
hack around the H.264 licencing, and I don't think we're really even
close to having charted the full extent of the thin ice that it is
currently floating on.  The cap announced for H.265 definitely appears
to have responded to this challenge already ...

So the question for me at this stage still really is:

 What exceptional circumstances exist to justify this group deciding
 to go out on such a thin and completely untested limb, to mandate a
 technology that is so obviously, and undisputedly, encumbered?

Especially when we have an alternative choice available to us which is
its technical equal, and for which the equivalent encumberance is, at
best, still the untested assertion of a few far-from-unbiased parties.


I'm not ruling out that there may be *some* solution which makes H.264
viable without needing to resort to Clever Hacks, but so far we seem
to be still well short of that.  At the same time, VP8 is currently
under consideration to become an international standard. And there are
other codecs under development which may change the facts on the ground
too before the work of this group is completed.

I do think we want an MTI video codec, but it's less clear we need to
rush this decision while things that may be quite pertinent to it are
still evolving in new and potentially game changing ways.


> On 11/6/14, 1:29 PM, Ron <ron@debian.org> wrote:
> On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote:
> > On Wed, Nov 5, 2014 at 2:39 PM, tim panton <tim@phonefromhere.com> wrote:
> > >
> > > Agreed, the worst aspect of any adoption of H264 is that it makes it
> > > significantly more difficult to
> > > produce a custom ¹secure¹ build of firefox that has been independently
> > > reviewed for special use-cases
> > > (press, humanitarian workers etc).
> >
> > Why is this true? We currently build OpenH264 and then send the binary to
> > Cisco but keep a hash for comparison. Why is it more difficult to review
> > this?
>
> Is Cisco offering to ship such binaries for anyone who wants to build
> them, or is this a special privilege they offered to you to win your
> support for their scheme?
>
>   Ron

_______________________________________________
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

--------------040501060404060707040401-- From nobody Thu Nov 6 13:59:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7F41A9128 for ; Thu, 6 Nov 2014 13:59:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM7eEELS6Cb1 for ; Thu, 6 Nov 2014 13:59:14 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id DAF2F1A9126 for ; Thu, 6 Nov 2014 13:59:13 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Nov 2014 08:29:12 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id C4419FFEEC for ; Fri, 7 Nov 2014 08:29:11 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id H43X2EA4Ojag for ; Fri, 7 Nov 2014 08:29:11 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 1B4C9FF90E for ; Fri, 7 Nov 2014 08:29:11 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 0D9A580470; Fri, 7 Nov 2014 08:29:11 +1030 (ACDT) Date: Fri, 7 Nov 2014 08:29:11 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141106215910.GJ8092@hex.shelbyville.oz> References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TH733GMtQJM8H3cVuuhuy5g-l2s Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:59:15 -0000 On Thu, Nov 06, 2014 at 01:08:21PM -0800, Eric Rescorla wrote: > On Thu, Nov 6, 2014 at 10:29 AM, Ron wrote: > > > On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: > > > On Wed, Nov 5, 2014 at 2:39 PM, tim panton > > wrote: > > > > > > > > Agreed, the worst aspect of any adoption of H264 is that it makes it > > > > significantly more difficult to > > > > produce a custom ’secure’ build of firefox that has been independently > > > > reviewed for special use-cases > > > > (press, humanitarian workers etc). > > > > > > Why is this true? We currently build OpenH264 and then send the binary to > > > Cisco but keep a hash for comparison. Why is it more difficult to review > > > this? > > > > Is Cisco offering to ship such binaries for anyone who wants to build > > them > > I think Mo has answered this. > > > , or is this a special privilege they offered to you to win your > > support for their scheme? > > It certainly wasn't this. When we agreed to do this, the intent was to do > reproducible builds, but then as we got closer to ship engineering > realities intervened and it became clear that it was easier for Mozilla > to do the builds in the interim, but that decision was only made > recently and we would prefer to have reproducible builds, as Mo > says.. Right, that was sort of the point I elaborated on in my reply to Mo, there's a very real gulf between how we might like to imagine things could work, and what's actually going to happen or be possible in the real world that we actually have to work within. It's perfectly fine for Mozilla and Cisco to take shortcuts that they agree serves them both well to make things happen in a timely way. Where that leaves everyone else is the question I was asking here. This isn't a shortcut that would seem to scale well to other users, or one that seems likely to cease to be "necessary" any time soon. (I believe I already noted the difficulty of doing this when it was first proposed, so I'm definitely not surprised at it remaining just a promise at this stage) I've seen enough engineering realities to be pretty sure that any untested and novel scheme isn't going to end exactly how the people who pitched it said it would. Mozilla's experience with this will definitely be an interesting datapoint, but it's not clear how well that will extrapolate to the more general case or the users that Tim indicated concern for yet. Ron From nobody Thu Nov 6 18:46:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57EA1ACE98 for ; Thu, 6 Nov 2014 18:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7lroVIh4Rrx for ; Thu, 6 Nov 2014 18:46:25 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id EE9AB1A0037 for ; Thu, 6 Nov 2014 18:46:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0DE3B7C529F; Fri, 7 Nov 2014 03:46:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERZV_ktvcNVC; Fri, 7 Nov 2014 03:46:14 +0100 (CET) Received: from [IPv6:2620:0:1000:167d:e5cb:9126:6dca:f5a4] (unknown [IPv6:2620:0:1000:167d:e5cb:9126:6dca:f5a4]) by mork.alvestrand.no (Postfix) with ESMTPSA id CDC247C52A8; Fri, 7 Nov 2014 03:46:13 +0100 (CET) Message-ID: <545C3272.2050405@alvestrand.no> Date: Thu, 06 Nov 2014 18:46:10 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141013095115.8167.86416.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8B2729AB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <545BD871.3030009@alvestrand.no> In-Reply-To: <545BD871.3030009@alvestrand.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Gm97uqxbFijdLYvWN8P8jRZHqaw Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 02:46:28 -0000 On 11/06/2014 12:22 PM, Harald Alvestrand wrote: > >> 5: My understanding is that one of the security documents is a require= ments document, which leads to the other document containing the security= specification. Therefore the reference to the first should be at most in= formative, and the normative reference only to the second. I sought clari= fication on this at the last meeting, and that was the understanding I re= ceived.=20 > Good point. Unless someone argues the contrary, I'll move the reference= > to "-security" to the informative section. Followup: I reviewed -security and -security-arch briefly. There is a lot of normative language in -security (MUST), but all the examples that I was able to follow were matched by more specific normative language in -security-arch. (The exception I could find is the requirement for masking on TCP, which seems to have beeen overtaken by events - we don't have any way to generate any content that needs masking, so it's hard to see that it needs to be normative for that reaso= n.) Editors of -security*: Is the intent that one should be able to refer to only -security-arch normatively? Harald From nobody Fri Nov 7 01:56:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892B61ACF72 for ; Fri, 7 Nov 2014 01:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBJQ3qc6HLt0 for ; Fri, 7 Nov 2014 01:56:49 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEEF1ACF73 for ; Fri, 7 Nov 2014 01:56:48 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-ec-545c975e3010 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B1.32.04387.E579C545; Fri, 7 Nov 2014 10:56:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Fri, 7 Nov 2014 10:56:46 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: cowwoc , "rtcweb@ietf.org" Thread-Topic: Warning gstreamer commercial (was Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them)) Thread-Index: AQHP+nEjwvzN8N6gGU+2cI6yBrRWjw== Date: Fri, 7 Nov 2014 09:56:45 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0B4353@ESESSMB209.ericsson.se> References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <545BD51B.9060907@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvjW7c9JgQg9kPFS3O3PzPbrH2Xzu7 A5PHkwnT2T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxrvM2a8Fp7ooz7bdZGxj3cHYxcnJICJhI rLj7ngXCFpO4cG89G4gtJHCEUaLvlSeEvZhR4nZrDIjNJhAosXXfArAaEQFPib/T34PZwgIl Eo2T97BDxCslbmx/xARh60lcWN7D3MXIwcEioCJx9C9YCa+Ar8TTrXcYIcZ/YpHov+INYjMC nfD91BqwVmYBcYlbT+YzQZwmILFkz3lmCFtU4uXjf6wgIyUElCSmbU2DKNeTuDF1ChuErS2x bOFrZohVghInZz5hmcAoMgvJ1FlIWmYhaZmFpGUBI8sqRtHi1OLi3HQjI73Uoszk4uL8PL28 1JJNjMBIOLjlt9UOxoPPHQ8xCnAwKvHwbjCNCRFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYwRS3qkGZdMPvfJSONr68OEz6FzpfymponzbpghX8q2YtPa 1zFuMxZ26xx3mb4/fU//ksqXcrJvAvZplbdHM7fpbHhxPMTk06vjol/NgC6957y9Ma3GOWj7 onolZw0V1Z8MJWuP5F1uX2TDnlNtwGJv53iTT2Pi9SsS8h0fGLY7TZBabpm4TImlOCPRUIu5 qDgRAI6wt6NlAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XakkomGsQNFe8qMy4-Vl2sqKcB4 Subject: [rtcweb] Warning gstreamer commercial (was Re: The MTI Codec Questions (what to ask and how to ask them)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 09:56:52 -0000 On 06/11/14 21:08, cowwoc wrote:=0A= > First a question and then a rant :)=0A= >=0A= > Question: What are you proposing to replace with a GStreamer plugin?=0A= > Rant: 2 years ago I tried to get Gstreamer working on iOS. Let's just=0A= > say it felt like taking a drill to the head. The codebase depended on=0A= > many Linux-specific dependencies (which did not exist on BSD) and some=0A= > of them were very poorly maintained (committers who were unreachable or= =0A= > dead .. no joke .. for years). Once I got past that point, it used to=0A= > break randomly in mysterious ways (i.e. the API's error handling sucks,= =0A= > once you report a bug it sits unfixed for months)=0A= >=0A= > I know that GStreamer is very popular and that GStreamer SDK has since=0A= > been published for iOS and OSX, but I still don't trust that codebase. I= =0A= > wouldn't want to have to maintain a project on top of it.=0A= =0A= Perhaps http://www.openwebrtc.io/ (which supports both codecs talked =0A= about) is of interest to you.=0A= Regarding gstreamer and openh264: =0A= http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/openh264 =0A= is available.=0A= And for iOS specifically there is also http://www.openwebrtc.io/bowser.=0A= =0A= (I know, I should not have sent this on the list. I could not help =0A= myself, sorry. Please do not respond to the list - if you're interested =0A= head over to the gstreamer or openwebrtc channels.)=0A= =0A= =0A= From nobody Fri Nov 7 07:31:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955361A875D for ; Fri, 7 Nov 2014 07:31:56 -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, 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 HYLvYCQ0jkOT for ; Fri, 7 Nov 2014 07:31:54 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7D11A876F for ; Fri, 7 Nov 2014 07:31:38 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-88-545ce5d8acf1 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1E.62.04387.8D5EC545; Fri, 7 Nov 2014 16:31:36 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.247]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Fri, 7 Nov 2014 16:31:36 +0100 From: Bo Burman To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) Thread-Index: AQHP+FAjpnpRKPynNE6ag2/b0xZHEpxQoKYAgAGWTQCAAAiSgIAAFyWAgAAJr4CAADEDAIAAblKAgADeK4CAACxZgIAADjSAgAEpAmA= Date: Fri, 7 Nov 2014 15:31:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <20141106215910.GJ8092@hex.shelbyville.oz> In-Reply-To: <20141106215910.GJ8092@hex.shelbyville.oz> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje6NpzEhBt/eKFus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJMrdAq2qFbMP+7WwLhDpYuRk0NCwESi8UUvK4QtJnHh3nq2 LkYuDiGBI4wSDYdPskM4ixklrm2fA1bFJqAhMX/HXUYQW0RAXeLywwvsILawQKDEz3+3WSDi QRJHHv+Fsssktux4yAZiswioSJx5uAQszivgK/F9xk5GiAWvWSSaL/9lBklwCphLXG06CjaU UUBW4v73e2ANzALiEreezGeCOFVAYsme88wQtqjEy8f/oF5Qkmhc8gTI5gCq15RYv0sfolVR Ykr3Q3aIvYISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFaNocWpxcW66kZFealFmcnFxfp5e XmrJJkZgPBzc8ttqB+PB546HGAU4GJV4eDeYxoQIsSaWFVfmHmKU5mBREuddeG5esJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbG3nm7rhw0mb1yYtXNeXvsTroH3Ztofd3wQ4ut9LcS/6TZ rBcddHYtCdp9s25/0Cd152yLb7sXsXhubkrzdn2uP/nvh5O/cn/4JU7z6lt6TPqDw/Wvjh2+ MnM6f0wX37duZviCDpNFgd84NL60OlspPxb/YDBDr91sO5/7stmBrGJHVx1YWaTXrMRSnJFo qMVcVJwIAJGXnOBoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8wMq7Rgeoe_yBUyuowmHqH6ibTI Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:31:56 -0000 SSB0aGluaywgYXMgd2FzIGFsc28gc2FpZCBieSBvdGhlcnMsIHdlIGFyZSBtb3ZpbmcgaW4gY2ly Y2xlcyB3aXRob3V0IHZlcnkgbXVjaCBwcm9ncmVzcy4gV2hhdCBzZWVtcyB0byBiZSB0aGUgbW9z dCBwcmVzc2luZyBpc3N1ZSwgdGhlIGxpY2Vuc2luZyBsYW5kc2NhcGUsIGhhcyBjaGFuZ2VkIHNv bWV3aGF0IHNpbmNlIGxhc3QgdGltZSB3ZSB0cmllZCB0byBkZWNpZGUgb24gdmlkZW8gTVRJLCBi dXQgdGhlcmUgYXJlIHN0aWxsIG1ham9yIG9iamVjdGlvbnMgdG8gdGhhdCBsYW5kc2NhcGUgYW5k IGl0IGlzIGFsc28gc3RpbGwgY2hhbmdpbmcuIFdoaWxlIEkgZG8gdGhpbmsgd2UgbmVlZCBhbiBN VEkgdmlkZW8gY29kZWMsIEkgYmVsaWV2ZSB3ZSB3b3VsZCBtYWtlIGJldHRlciB1c2Ugb2Ygb3Vy IHRpbWUgcG9zdHBvbmluZyB0aGUgZGVjaXNpb24gYSBiaXQgbG9uZ2VyLCBhdCBsZWFzdCB1bnRp bCBWQ0IgaXMgZnVsbHkgc2V0dGxlZCBpbiBNUEVHLg0KDQovQm8NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFJvbg0KPiBTZW50OiBkZW4gNiBub3ZlbWJlciAyMDE0IDIyOjU5 DQo+IFRvOiBydGN3ZWJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtydGN3ZWJdIFRoZSBNVEkg Q29kZWMgUXVlc3Rpb25zICh3aGF0IHRvIGFzayBhbmQgaG93IHRvIGFzayB0aGVtKQ0KPiANCj4g T24gVGh1LCBOb3YgMDYsIDIwMTQgYXQgMDE6MDg6MjFQTSAtMDgwMCwgRXJpYyBSZXNjb3JsYSB3 cm90ZToNCj4gPiBPbiBUaHUsIE5vdiA2LCAyMDE0IGF0IDEwOjI5IEFNLCBSb24gPHJvbkBkZWJp YW4ub3JnPiB3cm90ZToNCj4gPg0KPiA+ID4gT24gV2VkLCBOb3YgMDUsIDIwMTQgYXQgMDk6MTQ6 MjdQTSAtMDgwMCwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gPiA+ID4gT24gV2VkLCBOb3YgNSwg MjAxNCBhdCAyOjM5IFBNLCB0aW0gcGFudG9uIDx0aW1AcGhvbmVmcm9taGVyZS5jb20+DQo+ID4g PiB3cm90ZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEFncmVlZCwgdGhlIHdvcnN0IGFzcGVjdCBv ZiBhbnkgYWRvcHRpb24gb2YgSDI2NCBpcyB0aGF0IGl0DQo+ID4gPiA+ID4gbWFrZXMgaXQgc2ln bmlmaWNhbnRseSBtb3JlIGRpZmZpY3VsdCB0byBwcm9kdWNlIGEgY3VzdG9tDQo+ID4gPiA+ID4g 4oCZc2VjdXJl4oCZIGJ1aWxkIG9mIGZpcmVmb3ggdGhhdCBoYXMgYmVlbiBpbmRlcGVuZGVudGx5 IHJldmlld2VkDQo+ID4gPiA+ID4gZm9yIHNwZWNpYWwgdXNlLWNhc2VzIChwcmVzcywgaHVtYW5p dGFyaWFuIHdvcmtlcnMgZXRjKS4NCj4gPiA+ID4NCj4gPiA+ID4gV2h5IGlzIHRoaXMgdHJ1ZT8g V2UgY3VycmVudGx5IGJ1aWxkIE9wZW5IMjY0IGFuZCB0aGVuIHNlbmQgdGhlDQo+ID4gPiA+IGJp bmFyeSB0byBDaXNjbyBidXQga2VlcCBhIGhhc2ggZm9yIGNvbXBhcmlzb24uIFdoeSBpcyBpdCBt b3JlDQo+ID4gPiA+IGRpZmZpY3VsdCB0byByZXZpZXcgdGhpcz8NCj4gPiA+DQo+ID4gPiBJcyBD aXNjbyBvZmZlcmluZyB0byBzaGlwIHN1Y2ggYmluYXJpZXMgZm9yIGFueW9uZSB3aG8gd2FudHMg dG8NCj4gPiA+IGJ1aWxkIHRoZW0NCj4gPg0KPiA+IEkgdGhpbmsgTW8gaGFzIGFuc3dlcmVkIHRo aXMuDQo+ID4NCj4gPiA+ICwgb3IgaXMgdGhpcyBhIHNwZWNpYWwgcHJpdmlsZWdlIHRoZXkgb2Zm ZXJlZCB0byB5b3UgdG8gd2luIHlvdXINCj4gPiA+IHN1cHBvcnQgZm9yIHRoZWlyIHNjaGVtZT8N Cj4gPg0KPiA+IEl0IGNlcnRhaW5seSB3YXNuJ3QgdGhpcy4gV2hlbiB3ZSBhZ3JlZWQgdG8gZG8g dGhpcywgdGhlIGludGVudCB3YXMgdG8NCj4gPiBkbyByZXByb2R1Y2libGUgYnVpbGRzLCBidXQg dGhlbiBhcyB3ZSBnb3QgY2xvc2VyIHRvIHNoaXAgZW5naW5lZXJpbmcNCj4gPiByZWFsaXRpZXMg aW50ZXJ2ZW5lZCBhbmQgaXQgYmVjYW1lIGNsZWFyIHRoYXQgaXQgd2FzIGVhc2llciBmb3INCj4g PiBNb3ppbGxhIHRvIGRvIHRoZSBidWlsZHMgaW4gdGhlIGludGVyaW0sIGJ1dCB0aGF0IGRlY2lz aW9uIHdhcyBvbmx5DQo+ID4gbWFkZSByZWNlbnRseSBhbmQgd2Ugd291bGQgcHJlZmVyIHRvIGhh dmUgcmVwcm9kdWNpYmxlIGJ1aWxkcywgYXMgTW8NCj4gPiBzYXlzLi4NCj4gDQo+IFJpZ2h0LCB0 aGF0IHdhcyBzb3J0IG9mIHRoZSBwb2ludCBJIGVsYWJvcmF0ZWQgb24gaW4gbXkgcmVwbHkgdG8g TW8sIHRoZXJlJ3MgYSB2ZXJ5IHJlYWwgZ3VsZiBiZXR3ZWVuIGhvdyB3ZSBtaWdodCBsaWtlIHRv DQo+IGltYWdpbmUgdGhpbmdzIGNvdWxkIHdvcmssIGFuZCB3aGF0J3MgYWN0dWFsbHkgZ29pbmcg dG8gaGFwcGVuIG9yIGJlIHBvc3NpYmxlIGluIHRoZSByZWFsIHdvcmxkIHRoYXQgd2UgYWN0dWFs bHkgaGF2ZSB0bw0KPiB3b3JrIHdpdGhpbi4NCj4gDQo+IEl0J3MgcGVyZmVjdGx5IGZpbmUgZm9y IE1vemlsbGEgYW5kIENpc2NvIHRvIHRha2Ugc2hvcnRjdXRzIHRoYXQgdGhleSBhZ3JlZSBzZXJ2 ZXMgdGhlbSBib3RoIHdlbGwgdG8gbWFrZSB0aGluZ3MgaGFwcGVuIGluDQo+IGEgdGltZWx5IHdh eS4NCj4gDQo+IFdoZXJlIHRoYXQgbGVhdmVzIGV2ZXJ5b25lIGVsc2UgaXMgdGhlIHF1ZXN0aW9u IEkgd2FzIGFza2luZyBoZXJlLg0KPiBUaGlzIGlzbid0IGEgc2hvcnRjdXQgdGhhdCB3b3VsZCBz ZWVtIHRvIHNjYWxlIHdlbGwgdG8gb3RoZXIgdXNlcnMsIG9yIG9uZSB0aGF0IHNlZW1zIGxpa2Vs eSB0byBjZWFzZSB0byBiZSAibmVjZXNzYXJ5IiBhbnkNCj4gdGltZSBzb29uLg0KPiANCj4gKEkg YmVsaWV2ZSBJIGFscmVhZHkgbm90ZWQgdGhlIGRpZmZpY3VsdHkgb2YgZG9pbmcgdGhpcyB3aGVu IGl0IHdhcyBmaXJzdCBwcm9wb3NlZCwgc28gSSdtIGRlZmluaXRlbHkgbm90IHN1cnByaXNlZCBh dCBpdA0KPiByZW1haW5pbmcganVzdCBhIHByb21pc2UgYXQgdGhpcyBzdGFnZSkNCj4gDQo+IEkn dmUgc2VlbiBlbm91Z2ggZW5naW5lZXJpbmcgcmVhbGl0aWVzIHRvIGJlIHByZXR0eSBzdXJlIHRo YXQgYW55IHVudGVzdGVkIGFuZCBub3ZlbCBzY2hlbWUgaXNuJ3QgZ29pbmcgdG8gZW5kIGV4YWN0 bHkNCj4gaG93IHRoZSBwZW9wbGUgd2hvIHBpdGNoZWQgaXQgc2FpZCBpdCB3b3VsZC4gIE1vemls bGEncyBleHBlcmllbmNlIHdpdGggdGhpcyB3aWxsIGRlZmluaXRlbHkgYmUgYW4gaW50ZXJlc3Rp bmcgZGF0YXBvaW50LCBidXQNCj4gaXQncyBub3QgY2xlYXIgaG93IHdlbGwgdGhhdCB3aWxsIGV4 dHJhcG9sYXRlIHRvIHRoZSBtb3JlIGdlbmVyYWwgY2FzZSBvciB0aGUgdXNlcnMgdGhhdCBUaW0g aW5kaWNhdGVkIGNvbmNlcm4gZm9yIHlldC4NCj4gDQo+ICAgUm9uDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxp bmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCg== From nobody Fri Nov 7 08:07:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5E1A8869 for ; Fri, 7 Nov 2014 08:06:56 -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 3GcPr9Y672zc for ; Fri, 7 Nov 2014 08:06:54 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5D21A87D0 for ; Fri, 7 Nov 2014 08:06:45 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id r10so13029886igi.12 for ; Fri, 07 Nov 2014 08:06:44 -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=Wu3ofv9XrHtFhn/eII/JRtE1FgVrnu7nFFKJKmMdjHU=; b=g5UbcKDcft4wldXseRvoXZ+GKBm6l+w8hon73RgCRtdpoQkYCkQg37CnQ5wHoHI2C7 raZ9NbU2x6TcYTbIhr4jHyCqf9TnGndOAHp2ZtuVQm/jkwVt8oamYrSlMS/DtUy26Uru vUg/5ZQ3oz9NOsLNojhlSpZRtdE81mL+Gym6URJmoXaa+1W4mlop4XLBnTjh8RqDnIeJ giivrYl2WCe5pa1HNaRw87Vdaz88xC9jVom8Ro9b7+jbs+sNLTqYFTmjf4NxreQeQbnQ UycVfNFoCaxkYtUqo29iJBNvRTcZqQ55llyDgjePA523j522AVAePkQ92GOfPmV/SsMN WN6w== X-Gm-Message-State: ALoCoQnIwAyGrsFZ+FXrZSMm4AH9KcV+bVsXxc6JpO+UOr9OcKxmk6FFyKCQMgWhnYNJ40mroUgk X-Received: by 10.42.30.7 with SMTP id t7mr19368949icc.66.1415376404296; Fri, 07 Nov 2014 08:06:44 -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 i184sm4427178ioi.33.2014.11.07.08.06.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Nov 2014 08:06:43 -0800 (PST) Message-ID: <545CEDFD.3020805@bbs.darktech.org> Date: Fri, 07 Nov 2014 11:06:21 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <20141106215910.GJ8092@hex.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Yl0V95-3y0p16bQc5qkp9CVzIfk Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:06:57 -0000 Or design based on the de-facto situation (no MTI) until the situation changes to the point where we can revisit this issue. Hopefully things will improve. But if they don't... we shouldn't wait forever. Gili On 07/11/2014 10:31 AM, Bo Burman wrote: > I think, as was also said by others, we are moving in circles without very much progress. What seems to be the most pressing issue, the licensing landscape, has changed somewhat since last time we tried to decide on video MTI, but there are still major objections to that landscape and it is also still changing. While I do think we need an MTI video codec, I believe we would make better use of our time postponing the decision a bit longer, at least until VCB is fully settled in MPEG. > > /Bo > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron >> Sent: den 6 november 2014 22:59 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) >> >> On Thu, Nov 06, 2014 at 01:08:21PM -0800, Eric Rescorla wrote: >>> On Thu, Nov 6, 2014 at 10:29 AM, Ron wrote: >>> >>>> On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: >>>>> On Wed, Nov 5, 2014 at 2:39 PM, tim panton >>>> wrote: >>>>>> Agreed, the worst aspect of any adoption of H264 is that it >>>>>> makes it significantly more difficult to produce a custom >>>>>> ’secure’ build of firefox that has been independently reviewed >>>>>> for special use-cases (press, humanitarian workers etc). >>>>> Why is this true? We currently build OpenH264 and then send the >>>>> binary to Cisco but keep a hash for comparison. Why is it more >>>>> difficult to review this? >>>> Is Cisco offering to ship such binaries for anyone who wants to >>>> build them >>> I think Mo has answered this. >>> >>>> , or is this a special privilege they offered to you to win your >>>> support for their scheme? >>> It certainly wasn't this. When we agreed to do this, the intent was to >>> do reproducible builds, but then as we got closer to ship engineering >>> realities intervened and it became clear that it was easier for >>> Mozilla to do the builds in the interim, but that decision was only >>> made recently and we would prefer to have reproducible builds, as Mo >>> says.. >> Right, that was sort of the point I elaborated on in my reply to Mo, there's a very real gulf between how we might like to >> imagine things could work, and what's actually going to happen or be possible in the real world that we actually have to >> work within. >> >> It's perfectly fine for Mozilla and Cisco to take shortcuts that they agree serves them both well to make things happen in >> a timely way. >> >> Where that leaves everyone else is the question I was asking here. >> This isn't a shortcut that would seem to scale well to other users, or one that seems likely to cease to be "necessary" any >> time soon. >> >> (I believe I already noted the difficulty of doing this when it was first proposed, so I'm definitely not surprised at it >> remaining just a promise at this stage) >> >> I've seen enough engineering realities to be pretty sure that any untested and novel scheme isn't going to end exactly >> how the people who pitched it said it would. Mozilla's experience with this will definitely be an interesting datapoint, but >> it's not clear how well that will extrapolate to the more general case or the users that Tim indicated concern for yet. >> >> Ron >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Nov 7 08:09:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2921A6F5B for ; Fri, 7 Nov 2014 08:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-uV9dv6rtSs for ; Fri, 7 Nov 2014 08:09:16 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226A41A8838 for ; Fri, 7 Nov 2014 08:09:14 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id i17so2785740qcy.14 for ; Fri, 07 Nov 2014 08:09:13 -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=9DstdKKY3xntjvghshcEqbOw55wx/znHduNh52R9mOc=; b=SYaTNRjRYXHO99qFqmfiaWOqn5AhtfR+sHIWfCYMxM/1sHdRjnp5vdqDVmzKgMlw/J 7E0AaDz7/7T1bhEbxbEqPwjexEy2kaA5EDsA/x7RJpKbxH3pvgSlOXHvyKE4sPuNR/kf ZgO29mJ5HA8zUOyScepBYoXpfeKpePt6uDh70aQur23wxQLJ7mHj0QTofZjk7PjkkHEf 0hHxL+RQTiKzMDZbyFHRF1j0s5VNmp5n1+Bk/RcApXJexIed9dNzJdtFHZDYesvclFC6 qMevuTj8g0bcE3iZzlFoHiOykM/2HZDmhv0yc77wwz+YEAlQgEsXIg7YThUXmlNoZlYF E8eA== X-Gm-Message-State: ALoCoQmK15B1PiVqyQ/XNK+6sCTT3qmKa4jHsBQ0u1KAwWpAQAJ7/IMuws6dm5HGSgWlsj3Avq+p MIME-Version: 1.0 X-Received: by 10.229.209.136 with SMTP id gg8mr12470207qcb.16.1415376553024; Fri, 07 Nov 2014 08:09:13 -0800 (PST) Received: by 10.96.69.200 with HTTP; Fri, 7 Nov 2014 08:09:12 -0800 (PST) Received: by 10.96.69.200 with HTTP; Fri, 7 Nov 2014 08:09:12 -0800 (PST) In-Reply-To: <545CEDFD.3020805@bbs.darktech.org> References: <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> <20141106182937.GH8092@hex.shelbyville.oz> <20141106215910.GJ8092@hex.shelbyville.oz> <545CEDFD.3020805@bbs.darktech.org> Date: Fri, 7 Nov 2014 17:09:12 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: cowwoc Content-Type: multipart/alternative; boundary=001a113390ccaabafa0507470867 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5x9GlgvonegPlcUrIkUBsa4jXjs Cc: rtcweb@ietf.org Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:09:20 -0000 --001a113390ccaabafa0507470867 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If "things will improve" means a non royalty-polluted codec then I agree. Until that no MTI codec, because WebRTC is for the web, not for the Industry. On 7 Nov 2014 17:07, "cowwoc" wrote: > Or design based on the de-facto situation (no MTI) until the situation > changes to the point where we can revisit this issue. > > Hopefully things will improve. But if they don't... we shouldn't wait > forever. > > Gili > > On 07/11/2014 10:31 AM, Bo Burman wrote: > >> I think, as was also said by others, we are moving in circles without >> very much progress. What seems to be the most pressing issue, the licens= ing >> landscape, has changed somewhat since last time we tried to decide on vi= deo >> MTI, but there are still major objections to that landscape and it is al= so >> still changing. While I do think we need an MTI video codec, I believe w= e >> would make better use of our time postponing the decision a bit longer, = at >> least until VCB is fully settled in MPEG. >> >> /Bo >> >> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron >>> Sent: den 6 november 2014 22:59 >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to >>> ask them) >>> >>> On Thu, Nov 06, 2014 at 01:08:21PM -0800, Eric Rescorla wrote: >>> >>>> On Thu, Nov 6, 2014 at 10:29 AM, Ron wrote: >>>> >>>> On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote: >>>>> >>>>>> On Wed, Nov 5, 2014 at 2:39 PM, tim panton >>>>>> >>>>> wrote: >>>>> >>>>>> Agreed, the worst aspect of any adoption of H264 is that it >>>>>>> makes it significantly more difficult to produce a custom >>>>>>> =E2=80=99secure=E2=80=99 build of firefox that has been independent= ly reviewed >>>>>>> for special use-cases (press, humanitarian workers etc). >>>>>>> >>>>>> Why is this true? We currently build OpenH264 and then send the >>>>>> binary to Cisco but keep a hash for comparison. Why is it more >>>>>> difficult to review this? >>>>>> >>>>> Is Cisco offering to ship such binaries for anyone who wants to >>>>> build them >>>>> >>>> I think Mo has answered this. >>>> >>>> , or is this a special privilege they offered to you to win your >>>>> support for their scheme? >>>>> >>>> It certainly wasn't this. When we agreed to do this, the intent was to >>>> do reproducible builds, but then as we got closer to ship engineering >>>> realities intervened and it became clear that it was easier for >>>> Mozilla to do the builds in the interim, but that decision was only >>>> made recently and we would prefer to have reproducible builds, as Mo >>>> says.. >>>> >>> Right, that was sort of the point I elaborated on in my reply to Mo, >>> there's a very real gulf between how we might like to >>> imagine things could work, and what's actually going to happen or be >>> possible in the real world that we actually have to >>> work within. >>> >>> It's perfectly fine for Mozilla and Cisco to take shortcuts that they >>> agree serves them both well to make things happen in >>> a timely way. >>> >>> Where that leaves everyone else is the question I was asking here. >>> This isn't a shortcut that would seem to scale well to other users, or >>> one that seems likely to cease to be "necessary" any >>> time soon. >>> >>> (I believe I already noted the difficulty of doing this when it was >>> first proposed, so I'm definitely not surprised at it >>> remaining just a promise at this stage) >>> >>> I've seen enough engineering realities to be pretty sure that any >>> untested and novel scheme isn't going to end exactly >>> how the people who pitched it said it would. Mozilla's experience with >>> this will definitely be an interesting datapoint, but >>> it's not clear how well that will extrapolate to the more general case >>> or the users that Tim indicated concern for yet. >>> >>> Ron >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113390ccaabafa0507470867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If "things will improve" means a non royalty-pollu= ted codec then I agree. Until that no MTI codec, because WebRTC is for the = web, not for the Industry.

On 7 Nov 2014 17:07, "cowwoc" <cowwoc@bbs.darktech.org> wrot= e:
Or design based o= n the de-facto situation (no MTI) until the situation changes to the point = where we can revisit this issue.

Hopefully things will improve. But if they don't... we shouldn't wa= it forever.

Gili

On 07/11/2014 10:31 AM, Bo Burman wrote:
I think, as was also said by others, we are moving in circles without very = much progress. What seems to be the most pressing issue, the licensing land= scape, has changed somewhat since last time we tried to decide on video MTI= , but there are still major objections to that landscape and it is also sti= ll changing. While I do think we need an MTI video codec, I believe we woul= d make better use of our time postponing the decision a bit longer, at leas= t until VCB is fully settled in MPEG.

/Bo

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron
Sent: den 6 november 2014 22:59
To: rtcweb@ietf.org
Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask t= hem)

On Thu, Nov 06, 2014 at 01:08:21PM -0800, Eric Rescorla wrote:
On Thu, Nov 6, 2014 at 10:29 AM, Ron <ron@debian.org> wrote:

On Wed, Nov 05, 2014 at 09:14:27PM -0800, Eric Rescorla wrote:
On Wed, Nov 5, 2014 at 2:39 PM, tim panton <tim@phonefromhere.com>
wrote:
Agreed, the worst aspect of any adoption of H264 is that it
makes it significantly more difficult to produce a custom
=E2=80=99secure=E2=80=99 build of firefox that has been independently revie= wed
for special use-cases (press, humanitarian workers etc).
Why is this true? We currently build OpenH264 and then send the
binary to Cisco but keep a hash for comparison. Why is it more
difficult to review this?
Is Cisco offering to ship such binaries for anyone who wants to
build them
I think Mo has answered this.

, or is this a special privilege they offered to you to win your
support for their scheme?
It certainly wasn't this. When we agreed to do this, the intent was to<= br> do reproducible builds, but then as we got closer to ship engineering
realities intervened and it became clear that it was easier for
Mozilla to do the builds in the interim, but that decision was only
made recently and we would prefer to have reproducible builds, as Mo
says..
Right, that was sort of the point I elaborated on in my reply to Mo, there&= #39;s a very real gulf between how we might like to
imagine things could work, and what's actually going to happen or be po= ssible in the real world that we actually have to
work within.

It's perfectly fine for Mozilla and Cisco to take shortcuts that they a= gree serves them both well to make things happen in
a timely way.

Where that leaves everyone else is the question I was asking here.
This isn't a shortcut that would seem to scale well to other users, or = one that seems likely to cease to be "necessary" any
time soon.

(I believe I already noted the difficulty of doing this when it was first p= roposed, so I'm definitely not surprised at it
remaining just a promise at this stage)

I've seen enough engineering realities to be pretty sure that any untes= ted and novel scheme isn't going to end exactly
how the people who pitched it said it would.=C2=A0 Mozilla's experience= with this will definitely be an interesting datapoint, but
it's not clear how well that will extrapolate to the more general case = or the users that Tim indicated concern for yet.

=C2=A0 =C2=A0Ron


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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
--001a113390ccaabafa0507470867-- From nobody Fri Nov 7 16:02:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B751A0035 for ; Fri, 7 Nov 2014 16:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.581 X-Spam-Level: X-Spam-Status: No, score=-13.581 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.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 uVKfuuGh9YWv for ; Fri, 7 Nov 2014 16:01:56 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0FE1A0029 for ; Fri, 7 Nov 2014 16:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1208; q=dns/txt; s=iport; t=1415404917; x=1416614517; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hiu5crfgC1fVhfo4eoJFd8kHSNEK8tbe0ZP4BVs6/zY=; b=Tt4J9NQnb2F+Nofa/yJGAEzytktreRbQU2aOp1jWYVhDwm1g5TOm2d0/ o2s5mKAt8kxVEUtxOUEoMLFFXECthKF7yVxUENwa4nPGNoLv7WyjYK8Qe p6hbaKs8nbvbEI4TQYjTwTwm8ipX2jVyIFn/O3td4LDBNvuo2RUqZTxfk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJBcXVStJV2Y/2dsb2JhbABbgw5UWQTLXIdNAoEaFgEBAQEBcguEAgEBAQICOj0OBAIBCBEEAQELFBAyHQgCBBMIiDkNzyUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkGAPKQaDJ4EeBZInhFSIUY14hzKDeWwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,336,1413244800"; d="scan'208";a="94602703" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 08 Nov 2014 00:01:56 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA801tL6017358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 8 Nov 2014 00:01:56 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.151]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Fri, 7 Nov 2014 18:01:55 -0600 From: "David Benham (dbenham)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-00.txt Thread-Index: AQHP86qeP1IbB0/WF06uIvrpj7U+DJxV43UQ Date: Sat, 8 Nov 2014 00:01:55 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC564EF20AB@xmb-aln-x10.cisco.com> References: <0683D6CB32AC424D8AF52C0F660E5DC564ECD7F4@xmb-aln-x10.cisco.com> In-Reply-To: <0683D6CB32AC424D8AF52C0F660E5DC564ECD7F4@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.68.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NevdplXOsy2p_jwCy62AGv4u4Cw Subject: Re: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 00:01:59 -0000 Updated summary draft that will get uploaded on Monday (**) https://github.com/dabenham/ietf/blob/master/draft-benham-rtcweb-vp8litigat= ion-01 Duane Morris report updated (**) http://www.duanemorris.com/memo/VP8Compilation.pdf ** Highlights of update; Adds info regarding two nullification lawsuits, o= ne patent each, in German court that are active. Also adds new info on IPR= declarations to ISO/IEC for VCB/VP8 from Dolby Labs, Panasonic, MEC - all = type 2 / RAND - as well as confirms of previously noted Nokia type 3 (no li= cense) declaration for the same. > -----Original Message----- > From: David Benham (dbenham) > Sent: Wednesday, October 29, 2014 10:21 AM > To: Harald Alvestrand (harald@alvestrand.no); rtcweb@ietf.org > Subject: Re: [rtcweb] Notification for draft-benham-rtcweb-vp8litigation-= 00.txt >=20 > We'll be having those looked in to and report/draft subsequently updated. >=20 > > Nice to have this information available. > > > >The Duane Morris report is missing information about a couple of on-goin= g > invalidity actions. We've > >sent information to the I-D editors. Hopefully, they will update the doc= ument > to be more complete. >=20 From nobody Sun Nov 9 18:08:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A793D1A8872 for ; Sun, 9 Nov 2014 18:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuMm2jQYEjiF for ; Sun, 9 Nov 2014 18:08:27 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1B41A886E for ; Sun, 9 Nov 2014 18:08:27 -0800 (PST) Received: from dhcp-b419.meeting.ietf.org (dhcp-b419.meeting.ietf.org [31.133.180.25]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAA28Ph0038936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 Nov 2014 20:08:26 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <54601E19.8080203@nostrum.com> Date: Sun, 09 Nov 2014 16:08:25 -1000 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------040503070102040402080201" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/juVsZKp-AmRpYLCgy-uwartuNrY Subject: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 02:08:32 -0000 This is a multi-part message in MIME format. --------------040503070102040402080201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and "either one as long as it's *only* one", respectively. However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, with the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbre in the messages of other participants (and the key stakeholders in particular). So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I’ve discussed this extensively with representatives of all three of the players I mention above, and they are willing to sign on. This proposal is based on the definitions of "WebRTC User Agent", "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: 1. WebRTC User Agents MUST implement both VP8 and H.264. 2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. 3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible). This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so. /a --------------040503070102040402080201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and "either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, with the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbre in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I’ve discussed this extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent", "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a
--------------040503070102040402080201-- From nobody Sun Nov 9 18:27:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29531A8880 for ; Sun, 9 Nov 2014 18:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq_JeYqGcL-h for ; Sun, 9 Nov 2014 18:27:00 -0800 (PST) Received: from smtpdb9.aruba.it (smtpdb9.aruba.it [62.149.158.251]) by ietfa.amsl.com (Postfix) with ESMTP id CBD011A887B for ; Sun, 9 Nov 2014 18:26:59 -0800 (PST) Received: from lminiero ([31.133.163.233]) by smtpcmd03.ad.aruba.it with bizsmtp id DeSu1p00g52TFVb01eSwvY; Mon, 10 Nov 2014 03:26:57 +0100 Date: Mon, 10 Nov 2014 03:26:52 +0100 From: Lorenzo Miniero To: Adam Roach Message-ID: <20141110032652.21edac74@lminiero> In-Reply-To: <54601E19.8080203@nostrum.com> References: <54601E19.8080203@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PHyg7H_V9yqV9cobLFMVf0AFo10 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 02:27:01 -0000 Hi Adam, I was one of the "VP8 or die" advocates, but I can definitely understand your points and frustration about where this endless fight lead and left us. As long as all the major user agents will actually comply (I'm especially thinking about the one that are currently "missing"), I'd be ok with mandating both as you suggest. Lorenzo On Sun, 09 Nov 2014 16:08:25 -1000 Adam Roach wrote: > It appears that we're running headlong into another in-person > discussion about the relative merits of H.264 and VP8 as MTI > candidates again. Matthew Kaufman has argued that this conversation > is doomed to failure because no major player has been willing to > change their position. The players he cited were Cisco, Google, and > Mozilla, who have represented the three main positions on this topic > pretty effectively. Although we participate as individuals in the > IETF, I think it's fair to say that the last time we had this > conversation, the median positions of participants from those > companies were "H.264 or die", "VP8 or die", and "either one as long > as it's *only* one", respectively. >=20 > However, even if nothing else has changed, I think one salient point > may have become quite important: we're all tired of this. Over two > years ago, in March of 2012 -- before I even had an particular > interest in WebRTC except as a user -- this had already become such a > long-running acrimonious debate that I was brought in as a neutral > third party to try to mediate. I'm weary of this argument; and, with > the exception of a few aggressive voices who seem to enjoy the battle > more than the outcome, I'm hearing a similar exhausted timbre in the > messages of other participants (and the key stakeholders in > particular). >=20 > So, I want to float a proposal that represents a compromise, to see > if we can finally close this issue. First, I want to start out by=20 > reiterating a well-worn observation that the hallmark of a good=20 > compromise is that nobody leaves happy, but everyone can force=20 > themselves to accept it. And I want to be crystal clear: the solution=20 > I'm about to float just barely clears the bar of what I think I can > live with. This proposal is based on an observation that the > dominating issues in this conversation remain those of licensing, not > technology or even incumbency. I=E2=80=99ve discussed this extensively wi= th > representatives of all three of the players I mention above, and they > are willing to sign on. >=20 > This proposal is based on the definitions of "WebRTC User Agent",=20 > "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of=20 > draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: >=20 > 1. WebRTC User Agents MUST implement both VP8 and H.264. >=20 > 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the > codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will > change this normative statement to indicate that only that codec is > required. For absolute, crystal clarity, this provision is only > applicable to WebRTC devices, and not to WebRTC User Agents. >=20 > 3. WebRTC-compatible endpoints are free to implement any video codecs > they see fit, if any (this follows logically from the definition > of "WebRTC-compatible endpoint," and doesn't really need to be stated, > but I want this proposal to be as explicit as possible). >=20 >=20 > This has the property of ensuring that all devices and user agents > can work with all devices and user agents. This has the property of > giving no one exactly what they want. And, unlike any other previous > plans, this has the property of coming to a decision while > maintaining pressure on the only parties who can make a change in the > IPR landscape to do so. >=20 > /a From nobody Sun Nov 9 18:27:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEA31A8888 for ; Sun, 9 Nov 2014 18:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmY_giKXC_F1 for ; Sun, 9 Nov 2014 18:27:41 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8713C1A887B for ; Sun, 9 Nov 2014 18:27:41 -0800 (PST) Received: from mail-pd0-f178.google.com ([209.85.192.178]:39965) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xnehf-00066T-D1 for rtcweb@ietf.org; Sun, 09 Nov 2014 21:27:40 -0500 Received: by mail-pd0-f178.google.com with SMTP id fp1so6834425pdb.37 for ; Sun, 09 Nov 2014 18:27:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.68.100.197 with SMTP id fa5mr29586318pbb.22.1415586459092; Sun, 09 Nov 2014 18:27:39 -0800 (PST) Received: by 10.70.114.7 with HTTP; Sun, 9 Nov 2014 18:27:39 -0800 (PST) In-Reply-To: <54601E19.8080203@nostrum.com> References: <54601E19.8080203@nostrum.com> Date: Sun, 9 Nov 2014 21:27:39 -0500 Message-ID: From: Jonathan Rosenberg To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b6d89340c2aa9050777e847 X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qx4Z3ibqLA6HXZ6Hoyo1CggPIxg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 02:27:43 -0000 --047d7b6d89340c2aa9050777e847 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adam - I'm willing to sign up for this. As you point out, this issue has been brewing for a long time and is slowing the adoption of webrtc. We need to find a solution that works and move the industry forward. For the "incumbents" as you call them - the presence of h264 in browsers will allow interop between their browser apps and existing h264 devices which can be webrtc compatible. That is the primary use case to be solved for them and this proposal addresses it. I hope others can get behind this as well. Thx, Jonathan R. On Sunday, November 9, 2014, Adam Roach wrote: > It appears that we're running headlong into another in-person discussion > about the relative merits of H.264 and VP8 as MTI candidates again. Matth= ew > Kaufman has argued that this conversation is doomed to failure because no > major player has been willing to change their position. The players he > cited were Cisco, Google, and Mozilla, who have represented the three mai= n > positions on this topic pretty effectively. Although we participate as > individuals in the IETF, I think it's fair to say that the last time we h= ad > this conversation, the median positions of participants from those > companies were "H.264 or die", "VP8 or die", and "either one as long as > it's *only* one", respectively. > > However, even if nothing else has changed, I think one salient point may > have become quite important: we're all tired of this. Over two years ago, > in March of 2012 -- before I even had an particular interest in WebRTC > except as a user -- this had already become such a long-running acrimonio= us > debate that I was brought in as a neutral third party to try to mediate. > I'm weary of this argument; and, with the exception of a few aggressive > voices who seem to enjoy the battle more than the outcome, I'm hearing a > similar exhausted timbre in the messages of other participants (and the k= ey > stakeholders in particular). > > So, I want to float a proposal that represents a compromise, to see if we > can finally close this issue. First, I want to start out by reiterating a > well-worn observation that the hallmark of a good compromise is that nobo= dy > leaves happy, but everyone can force themselves to accept it. And I want = to > be crystal clear: the solution I'm about to float just barely clears the > bar of what I think I can live with. This proposal is based on an > observation that the dominating issues in this conversation remain those = of > licensing, not technology or even incumbency. I=E2=80=99ve discussed this > extensively with representatives of all three of the players I mention > above, and they are willing to sign on. > > This proposal is based on the definitions of "WebRTC User Agent", "WebRTC > device", and "WebRTC-compatible endpoint" in section 2.2 of > draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: > > > 1. WebRTC User Agents MUST implement both VP8 and H.264. > > 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the codec b= eing > of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this norm= ative > statement to indicate that only that codec is required. For absolute, > crystal clarity, this provision is only applicable to WebRTC devices, = and > not to WebRTC User Agents. > > 3. WebRTC-compatible endpoints are free to implement any video codecs > they see fit, if any (this follows logically from the definition of > "WebRTC-compatible endpoint," and doesn't really need to be stated, bu= t I > want this proposal to be as explicit as possible). > > > This has the property of ensuring that all devices and user agents can > work with all devices and user agents. This has the property of giving no > one exactly what they want. And, unlike any other previous plans, this ha= s > the property of coming to a decision while maintaining pressure on the on= ly > parties who can make a change in the IPR landscape to do so. > > /a > --=20 Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7b6d89340c2aa9050777e847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adam -

I'm willing to sign up for this.
As you point out, this issue has been brewing for a=C2=A0long = time and is slowing the adoption of webrtc. We need to find a solution that= works and move the industry forward.

For the &quo= t;incumbents" as you call them - the presence of h264 in browsers=C2= =A0will allow interop between their browser apps and existing h264 devices = which can be webrtc compatible. That is the primary use case to be solved f= or them=C2=A0and this proposal addresses it.

I hope others can get behind this as well.

Thx,
Jonathan R.

On Sunday, November 9, 2014, Adam Roach = <adam@nostrum.com> wrote:
=
=20 =20 =20
It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and &q= uot;either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, wit= h the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbr= e in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed th= is extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent&qu= ot;, "WebRTC device", and "WebRTC-compatible endpoint" i= n section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn'= ;t really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a


--

--047d7b6d89340c2aa9050777e847-- From nobody Sun Nov 9 20:01:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B681A88D8 for ; Sun, 9 Nov 2014 20:01:03 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3wjQvCRPh5t for ; Sun, 9 Nov 2014 20:01:02 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 08A7A1A88E6 for ; Sun, 9 Nov 2014 20:00:57 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail06.adl6.internode.on.net with ESMTP; 10 Nov 2014 14:30:45 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id ED61CFFA19 for ; Mon, 10 Nov 2014 14:30:42 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1hDcm6RkcRoE for ; Mon, 10 Nov 2014 14:30:42 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 5B30EFF88C for ; Mon, 10 Nov 2014 14:30:42 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 4BB5D80470; Mon, 10 Nov 2014 14:30:42 +1030 (ACDT) Date: Mon, 10 Nov 2014 14:30:42 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141110040042.GO8092@hex.shelbyville.oz> References: <54601E19.8080203@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54601E19.8080203@nostrum.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/giGTyDfNnn4fksK3PSSWujULcE0 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 04:01:04 -0000 Hi Adam, I do need to say that I really appreciate the effort you've put into trying to help guide this discussion, both previously and now. You speak an uncommon amount of good common sense. It's not clear to me exactly how you expect this part to work though: On Sun, Nov 09, 2014 at 04:08:25PM -1000, Adam Roach wrote: > 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the codec > being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change > this normative statement to indicate that only that codec is > required. For absolute, crystal clarity, this provision is only > applicable to WebRTC devices, and not to WebRTC User Agents. What would constitute "compelling evidence" in this context? Since the IETF doesn't take any position on the validity of IPR declarations, I'm not seeing how the conditional clause here can be anything but a no-op that would be essentially impossible to trigger. There are plenty of proposed standards which have IPR declarations made against them, which pretty much everyone who has analysed them in any detail agree are utterly bogus and inapplicable, but for which the organisation which declared them refuses to withdraw. What am I missing that would encourage different behaviour to that in this case? Cheers, Ron From nobody Sun Nov 9 23:34:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7221A19FB for ; Sun, 9 Nov 2014 23:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaG0ibnELWt1 for ; Sun, 9 Nov 2014 23:34:39 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D209B1A8957 for ; Sun, 9 Nov 2014 23:34:38 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 01A6D89520E62; Mon, 10 Nov 2014 07:34:36 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sAA7Yahq004504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 08:34:36 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 08:34:36 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/ItDFWMeXG1KFEOVaXuFJ8cIl5xZdbZw Date: Mon, 10 Nov 2014 07:34:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B2760AD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <54601E19.8080203@nostrum.com> In-Reply-To: <54601E19.8080203@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B2760ADFR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nFeyysQo0x52K5iTQe_Y9qSxJl8 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 07:34:43 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B2760ADFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First of all can I point out that the correct point of reference within the= overview document is I believe section 2.4, not 2.2. Section 2.2 is merely= the introduction saying these terms will be defined. 2.4 is the definitive= material. I think your proposal thinks this is all about IPR, and it is not. The argument from the H.264 side is about interoperability, both in making = use of existing embedded H.264 codecs in devices that will support webrtc, = and in the ability to interwork through gateways with other devices where t= he inherent population is H.264. So the parallel conditional on your item 2) which currently states "If compelling evidence arises that one of the codecs is available for use = on a royalty-free basis, such as all IPR declarations known for the codec b= eing of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this norm= ative statement to indicate that only that codec is required. For absolute,= crystal clarity, this provision is only applicable to WebRTC devices, and = not to WebRTC User Agents." would be something like... "If evidence arises that a significant population of webrtc devices and oth= er video capable IP devices beyond gateways support (or are otherwise manda= ted to support, e.g. by a GSMA specification) a specific video codec (eithe= r one of these two or a third) the IETF will change this normative statemen= t to indicate that only that codec is required." And this condition would need to be ANDed with the first condition. I can work with 1) 3) and otherwise the first half of 2) regards Keith ________________________________ From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: 10 November 2014 02:08 To: rtcweb@ietf.org Subject: [rtcweb] MTI Video Codec: a novel proposal It appears that we're running headlong into another in-person discussion ab= out the relative merits of H.264 and VP8 as MTI candidates again. Matthew K= aufman has argued that this conversation is doomed to failure because no ma= jor player has been willing to change their position. The players he cited = were Cisco, Google, and Mozilla, who have represented the three main positi= ons on this topic pretty effectively. Although we participate as individual= s in the IETF, I think it's fair to say that the last time we had this conv= ersation, the median positions of participants from those companies were "H= .264 or die", "VP8 or die", and "either one as long as it's *only* one", re= spectively. However, even if nothing else has changed, I think one salient point may ha= ve become quite important: we're all tired of this. Over two years ago, in = March of 2012 -- before I even had an particular interest in WebRTC except = as a user -- this had already become such a long-running acrimonious debate= that I was brought in as a neutral third party to try to mediate. I'm wear= y of this argument; and, with the exception of a few aggressive voices who = seem to enjoy the battle more than the outcome, I'm hearing a similar exhau= sted timbre in the messages of other participants (and the key stakeholders= in particular). So, I want to float a proposal that represents a compromise, to see if we c= an finally close this issue. First, I want to start out by reiterating a we= ll-worn observation that the hallmark of a good compromise is that nobody l= eaves happy, but everyone can force themselves to accept it. And I want to = be crystal clear: the solution I'm about to float just barely clears the ba= r of what I think I can live with. This proposal is based on an observation= that the dominating issues in this conversation remain those of licensing,= not technology or even incumbency. I've discussed this extensively with re= presentatives of all three of the players I mention above, and they are wil= ling to sign on. This proposal is based on the definitions of "WebRTC User Agent", "WebRTC d= evice", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcwe= b-overview-12.txt. My proposal would be as follows: 1. WebRTC User Agents MUST implement both VP8 and H.264. 2. WebRTC devices MUST implement both VP8 and H.264. If compelling evide= nce arises that one of the codecs is available for use on a royalty-free ba= sis, such as all IPR declarations known for the codec being of (IETF) Royal= ty-Free or (ISO) type 1, the IETF will change this normative statement to i= ndicate that only that codec is required. For absolute, crystal clarity, th= is provision is only applicable to WebRTC devices, and not to WebRTC User A= gents. 3. WebRTC-compatible endpoints are free to implement any video codecs th= ey see fit, if any (this follows logically from the definition of "WebRTC-c= ompatible endpoint," and doesn't really need to be stated, but I want this = proposal to be as explicit as possible). This has the property of ensuring that all devices and user agents can work= with all devices and user agents. This has the property of giving no one e= xactly what they want. And, unlike any other previous plans, this has the p= roperty of coming to a decision while maintaining pressure on the only part= ies who can make a change in the IPR landscape to do so. /a --_000_949EF20990823C4C85C18D59AA11AD8B2760ADFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
First of all can I point out that= the correct point of reference within the overview document is I believe s= ection 2.4, not 2.2. Section 2.2 is merely the introduction saying these terms will be defined. 2.4 is the definitive mat= erial.
 
I think your proposal thinks this= is all about IPR, and it is not.
 
The argument from the H.264 side = is about interoperability, both in making use of existing embedded H.264 co= decs in devices that will support webrtc, and in the ability to interwork through gateways with other devices where the = inherent population is H.264.
 
So the parallel conditional on yo= ur item 2) which currently states
 
"If compelling evidence arises that one of = the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-F= ree or (ISO) type 1, the IETF will change this normative statement to indic= ate that only that codec is required. For absolute, crystal clarity, this p= rovision is only applicable to WebRTC devices, and not to WebRTC User Agents."
 
would be something like...=
 
"If evidence arises that a s= ignificant population of webrtc devices and other video capable IP devices = beyond gateways support (or are otherwise mandated to support, e.g. by a GSMA specification) a specific video codec (either o= ne of these two or a third) the IETF will change this normative statement t= o indicate that only that codec is required."
 
And this condition would need to = be ANDed with the first condition.
 
I can work with 1) 3) and otherwi= se the first half of 2)
 
regards
 
Keith
 
 

From: rtcweb [mailto:rtcweb-bounces= @ietf.org] On Behalf Of Adam Roach
Sent: 10 November 2014 02:08
To: rtcweb@ietf.org
Subject: [rtcweb] MTI Video Codec: a novel proposal

It appears that we're running headlong into another in-person discussion ab= out the relative merits of H.264 and VP8 as MTI candidates again. Matthew K= aufman has argued that this conversation is doomed to failure because no ma= jor player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who = have represented the three main positions on this topic pretty effectively.= Although we participate as individuals in the IETF, I think it's fair to s= ay that the last time we had this conversation, the median positions of participants from those companies we= re "H.264 or die", "VP8 or die", and "either one a= s long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may ha= ve become quite important: we're all tired of this. Over two years ago, in = March of 2012 -- before I even had an particular interest in WebRTC except = as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral = third party to try to mediate. I'm weary of this argument; and, with the ex= ception of a few aggressive voices who seem to enjoy the battle more than t= he outcome, I'm hearing a similar exhausted timbre in the messages of other participants (and the key stakeh= olders in particular).

So, I want to float a proposal that represents a compromise, to see if we c= an finally close this issue. First, I want to start out by reiterating a we= ll-worn observation that the hallmark of a good compromise is that nobody l= eaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm = about to float just barely clears the bar of what I think I can live with. = This proposal is based on an observation that the dominating issues in this= conversation remain those of licensing, not technology or even incumbency. I’ve discussed this extensively w= ith representatives of all three of the players I mention above, and they a= re willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent",= "WebRTC device", and "WebRTC-compatible endpoint" in s= ection 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as fo= llows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling ev= idence arises that one of the codecs is available for use on a royalty-free= basis, such as all IPR declarations known for the codec being of (IETF) Ro= yalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is r= equired. For absolute, crystal clarity, this provision is only applicable t= o WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs= they see fit, if any (this follows logically from the definition of "= WebRTC-compatible endpoint," and doesn't really need to be stated, but= I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work= with all devices and user agents. This has the property of giving no one e= xactly what they want. And, unlike any other previous plans, this has the p= roperty of coming to a decision while maintaining pressure on the only parties who can make a change in th= e IPR landscape to do so.

/a
--_000_949EF20990823C4C85C18D59AA11AD8B2760ADFR712WXCHMBA11zeu_-- From nobody Mon Nov 10 00:00:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F371A895B for ; Mon, 10 Nov 2014 00:00:38 -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 km2w2mOQNUWH for ; Mon, 10 Nov 2014 00:00:37 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106CD1A88CE for ; Mon, 10 Nov 2014 00:00:37 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y10so7362945pdj.12 for ; Mon, 10 Nov 2014 00:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=IdJ9vL7ANqQ9Y4q6btSXwzPZzLC0DQZCpHYE/KEtyKE=; b=Tki9molRpcYV1gOHHkO7A7jYiaSdYG7KSGz1X2RvGkE60cqAVTG3UdVp7TFau5rJlS So5UkeEBD7MoAInTeFk/u/obmOm4BGPI1DPF8Mr3XiIw9JKxMoJfSQtwNn1yYyJ1jIOy zCrjm5pJ9Ovk3JUTQK+W5TCwPrNhL5/CKqV+6+jaMXOOB/CAISA+990xd3UmsdSLVj/N +jA0h5hSL4ReWEIJOI9PrT8nN9UW/NqjByIAuLr7pqWKCsMaV/yKYHOAzFB2ejIrcB6z kGJz6SZuYjO8TlvivaeOULZH5dDLqaDxF5Lnd2vdW1zayxUQ+onVLXq/Yfs65Sk//fGP V6dA== X-Received: by 10.68.197.41 with SMTP id ir9mr30537487pbc.116.1415606436336; Mon, 10 Nov 2014 00:00:36 -0800 (PST) Received: from [10.219.121.254] ([166.170.51.122]) by mx.google.com with ESMTPSA id gm11sm15668338pbd.63.2014.11.10.00.00.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 00:00:34 -0800 (PST) References: <54601E19.8080203@nostrum.com> <20141110040042.GO8092@hex.shelbyville.oz> Mime-Version: 1.0 (1.0) In-Reply-To: <20141110040042.GO8092@hex.shelbyville.oz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <43945E76-9C03-4A50-A3DD-354D9B038639@gmail.com> X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Sun, 9 Nov 2014 22:00:30 -1000 To: Ron Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/N8t5ibSq9MKrqMUNZxNpQGDLBg0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 08:00:38 -0000 On Nov 9, 2014, at 6:00 PM, Ron wrote: >=20 > What am I missing that would encourage different behaviour to that in this= case? [BA] The IETF professes no expertise in assessing legal risk, nor does it ma= ke any warranties or provide indemnification. As a result implementers need t= o make their own risk assessments based on legal counsel, independent of any= IETF recommendations. It is particularly telling that perhaps the most sali= ent piece of new information is a draft summarizing legal proceedings. Given that the key issue involves licensing fees and legal risk, the fullnes= s of time is probably our best ally. Unfortunately time only provides legal c= larity in spoonfuls, and a lengthy discussion between engineers about a lega= l matter probably would add a grain at best.=20 From nobody Mon Nov 10 01:01:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FB51A8974 for ; Mon, 10 Nov 2014 01:01:30 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQCl9iXfNLOR for ; Mon, 10 Nov 2014 01:01:29 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 32AF21A8965 for ; Mon, 10 Nov 2014 01:01:28 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Nov 2014 19:31:27 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 0FB6CFFEDC for ; Mon, 10 Nov 2014 19:31:15 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eUIDrFr3ge6v for ; Mon, 10 Nov 2014 19:31:14 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 90565FF81E for ; Mon, 10 Nov 2014 19:31:14 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7D4B380470; Mon, 10 Nov 2014 19:31:14 +1030 (ACDT) Date: Mon, 10 Nov 2014 19:31:14 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141110090114.GQ8092@hex.shelbyville.oz> References: <54601E19.8080203@nostrum.com> <20141110040042.GO8092@hex.shelbyville.oz> <43945E76-9C03-4A50-A3DD-354D9B038639@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43945E76-9C03-4A50-A3DD-354D9B038639@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2TBuBVMjLXsyKbutuEla0euQGXM Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 09:01:30 -0000 On Sun, Nov 09, 2014 at 10:00:30PM -1000, Bernard Aboba wrote: > On Nov 9, 2014, at 6:00 PM, Ron wrote: > > > > What am I missing that would encourage different behaviour to that in this case? > > [BA] The IETF professes no expertise in assessing legal risk, nor does > it make any warranties or provide indemnification. As a result > implementers need to make their own risk assessments based on legal > counsel, independent of any IETF recommendations. Yes, I believe that's more or less exactly what I said in the part of my question that you snipped :) If you agree with that part, then I assume you also don't see how the "compelling evidence" clause could ever be triggered? So maybe someone can explain what both you and I are missing here ... > It is particularly telling that perhaps the most salient piece of > new information is a draft summarizing legal proceedings. I've heard it said that one of the most telling things about that document is that some of the proceedings it mentions are *also* being prosecuted against H.264, yet strangely it doesn't seem to mention that at all ... But I profess no expertise in assessing legal risk, so maybe the experts who compiled that document can enlighten us on that too. I assume it was not their intention to somehow mislead this group. Ron From nobody Mon Nov 10 02:29:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19EB1A89AD for ; Mon, 10 Nov 2014 02:29:18 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZyaMG2u_7jw for ; Mon, 10 Nov 2014 02:29:17 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8039A1A899A for ; Mon, 10 Nov 2014 02:29:16 -0800 (PST) Received: (qmail 566 invoked from network); 10 Nov 2014 10:29:14 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 3509 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 10 Nov 2014 10:29:14 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 05FE818A0E62; Mon, 10 Nov 2014 10:29:15 +0000 (GMT) Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id D21B118A0CD3; Mon, 10 Nov 2014 10:29:14 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: <54601E19.8080203@nostrum.com> Date: Mon, 10 Nov 2014 10:29:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com> References: <54601E19.8080203@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/geKbuLOFVp4ccAIbiI7yliy0b8c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 10:29:18 -0000 Adam, thanks for sticking you head above the parapet !=20 I=92m largely in favour of this solution, further, I think it represents = the realities on the ground better than any other proposal to date, as such it merits support. On 10 Nov 2014, at 02:08, Adam Roach wrote: > WebRTC devices MUST implement both VP8 and H.264. If compelling = evidence arises that one of the codecs is available for use on a = royalty-free basis, such as all IPR declarations known for the codec = being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this = normative statement to indicate that only that codec is required. For = absolute, crystal clarity, this provision is only applicable to WebRTC = devices, and not to WebRTC User Agents.=20 I do have a slight qualm about the " =91both=92 or perhaps only =91one=92 = =93 language above. I think irrespective of new data, there will=20 always be devices who=92s hardware or business model is best served by a = specific codec, but that can meet every other requirement of a webRTC device. I feel the appropriate language here is =91either=92 , ensuring that = every device can always interact with a user agent but that devices can=92t necessarily communicate video between each = other without a transcoding middle man. This leaves WebRTC-compatible endpoint as a category for things that = implement neither video codec (e.g. audio only devices), or don=92t implement the data channel because it isn=92t relevant to their = application domain or only implement SDES (etc) - This gives a=20 clearer separation. This language choice matters most for developers who are selecting a = native library to use when building a webRTC device. They need to know what is supported - 'WebRTC-compatible=92 means that they have to = look very carefully at all the missing features, WebRTC-device says that it will work with any user agent.=20 With the current formulation there are no libraries that I know of = suitable for building a webRTC device, making it an empty category. Tim. From nobody Mon Nov 10 06:48:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBCD1A9009; Mon, 10 Nov 2014 06:48:04 -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 KBxSzHXfqYNv; Mon, 10 Nov 2014 06:48:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1806F1A8F50; Mon, 10 Nov 2014 06:48:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141110144803.26685.33097.idtracker@ietfa.amsl.com> Date: Mon, 10 Nov 2014 06:48:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DhCnl5DBOSuWrvkHe21PFIOV_Uo Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-20.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 14:48:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-20.txt Pages : 44 Date : 2014-11-10 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 10 06:55:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8678B1A8FD4 for ; Mon, 10 Nov 2014 06:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] 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 4EN9cQUE7LsL for ; Mon, 10 Nov 2014 06:55:23 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE711A9007 for ; Mon, 10 Nov 2014 06:55:23 -0800 (PST) Received: from [130.209.247.112] (port=56970 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XnqNB-0000x4-Si for rtcweb@ietf.org; Mon, 10 Nov 2014 14:55:21 +0000 From: Colin Perkins Content-Type: multipart/alternative; boundary="Apple-Mail=_7CE8BFA8-BBF1-4BD2-A010-F931BEFB0890" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 10 Nov 2014 14:55:15 +0000 References: <5446ACD8.1010004@gmail.com> <544E7586.4080703@gmail.com> <22D97583-2E07-417C-84CC-923FD83C008C@csperkins.org> <544E781D.50305@gmail.com> <17742E9C-CCDD-4EFE-A2C1-C84531A0523F@csperkins.org> <544E7E2B.6040809@gmail.com> <9DEB3428-1B9E-4876-A6B5-B4CCE69D84AE@csperkins.org> <790697E2-9C87-4B17-A49F-786292CF22AC@csperkins.org> To: "rtcweb@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e8IzrAS9vCiFt5AiFFUGGmEdbR0 Subject: Re: [rtcweb] Drop RFC 4588 RTX session multiplexing support requirement from RTP USAGE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 14:55:25 -0000 --Apple-Mail=_7CE8BFA8-BBF1-4BD2-A010-F931BEFB0890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I just submitted draft-ietf-rtcweb-rtp-usage-20, that makes this change. Colin On 3 Nov 2014, at 19:15, Varun Singh wrote: > +1 as well. >=20 > On 3 Nov 2014 07:25, "Colin Perkins" wrote: > I would have thought the compatibility arguments offered to support = non-BUNDLE media applied here too, but okay. If I change the last = paragraph of rtp-usage, section 6.1 to: >=20 > Receivers are REQUIRED to implement support for RTP retransmission > packets [RFC4588] sent using SSRC multiplexing, and MAY also = support > RTP retransmission packets sent using session multiplexing. = Senders > MAY send RTP retransmission packets in response to NACKs if support > for the RTP retransmission payload format has been negotiated, and = if > the sender believes it is useful to send a retransmission of the > packet(s) referenced in the NACK. Senders do not need to = retransmit > every NACKed packet. >=20 > is this acceptable? >=20 > Colin >=20 >=20 >=20 >=20 > On 28 Oct 2014, at 03:41, Bernard Aboba = wrote: >> Justin said:=20 >>=20 >> "I don't think the WG ever explicitly signed up for = session-multiplexing of RTX data" >>=20 >> [BA] I agree, and in addition would say the same thing with respect = to FEC - one of the fundamental objections to RFC 5109 is that it only = support session-multiplexing, not SSRC multiplexing. =20 >>=20 >> On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti = wrote: >>=20 >>=20 >> On Mon, Oct 27, 2014 at 12:16 PM, Colin Perkins = wrote: >> On 27 Oct 2014, at 17:17, Sergio Garcia Murillo = wrote: >>> On 27/10/2014 18:10, Colin Perkins wrote: >>>> On 27 Oct 2014, at 16:51, Sergio Garcia Murillo = wrote: >>>>> On 27/10/2014 17:45, Colin Perkins wrote: >>>>>> On 27 Oct 2014, at 16:40, Sergio Garcia Murillo = wrote: >>>>>>> On 27/10/2014 17:36, Colin Perkins wrote: >>>>>>>> On 21 Oct 2014, at 19:58, Sergio Garcia Murillo = wrote: >>>>>>>>> Not sure if it is done on pourpose, but according to the RTP = usage draft, it may seem that full RFC 4588 is mandated at the recevier = side: >>>>>>>>>=20 >>>>>>>>> Receivers are REQUIRED to implement support for RTP = retransmission >>>>>>>>> packets [RFC4588]. >>>>>>>>>=20 >>>>>>>>> That would include both modes, session and ssrc multiplexing. = Given the extensive usage of bundle and current implementations, session = multiplexing support doesn't make much sense. >>>>>>>>>=20 >>>>>>>>> Should we drop it, and state that only ssrc-multiplexing shall = be supported at the receiving end? >>>>>>>>=20 >>>>>>>> I don=92t see any advantage to doing so, given that support for = non-BUNDLE sessions is REQUIRED. You need to implement the signalling = needed for session-multiplexing of retransmission packet anyway, so = disallowing it buys you nothing. >>>>>>>=20 >>>>>>> You can do SSRC multiplexing with BUNDLE and non-BUNDLE = sessions, what I don't see is how to do session multiplexing with BUNDLE = sessions.=20 >>>>>>=20 >>>>>> You can=92t do session multiplexing for BUNDLE sessions; by = definition they use SSRC multiplexing. You could do non-BUNDLE sessions, = with retransmission sent on a separate RTP session though. >>>>>>=20 >>>>> So, you are saying exactly the same than me. SSRC multiplexing = supports both BUNDLE and NON-BUNDLE. So, why require support for session = multiplexing at all? As a developer, I don't see why I would have to = implement something that would be rarely used and provide no extra = benefit. >>>>=20 >>>> Non-BUNDLE is session multiplexing. It uses a separate RTP session = for the retransmissions.=20 >>> Maybe I am the missing something, if you don't use bundle to send = the audio/video on same rtpsession, you can still send rtx+video on same = session. That's it non-bundle with ssrc-multiplexing. Are we referring = to different things? >>=20 >> Sure, but that doesn=92t alter the fact that the group decided that = non-BUNDLE media needs to be supported. Sending retransmission on a = separate RTP session is as needed for interoperability with legacy = systems as sending audio and video on separate RTP sessions (and = shouldn=92t be hard to support, since it uses the same mechanisms). >>=20 >> Non-BUNDLE media needs to be supported, but I don't think the WG ever = explicitly signed up for session-multiplexing of RTX data. Unified plan = is quite clear in its assertion that the primary, RTX, and FEC flows for = a given media stream should all be represented by a single m=3D line, = e.g. SSRC-multiplexed.=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_7CE8BFA8-BBF1-4BD2-A010-F931BEFB0890 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I just = submitted draft-ietf-rtcweb-rtp-usage-20, that makes this = change.

Colin


<= br>

On 3 Nov 2014, at 19:15, Varun Singh = <vsingh.ietf@gmail.com>= wrote:

+1 as well.

On 3 Nov 2014 07:25, "Colin Perkins" <csp@csperkins.org> wrote:
I would have thought the compatibility = arguments offered to support non-BUNDLE media applied here too, but = okay. If I change the last paragraph of rtp-usage, section 6.1 = to:

   Receivers = are REQUIRED to implement support for RTP retransmission
   packets [RFC4588] sent using SSRC = multiplexing, and MAY also support
   RTP retransmission packets sent using = session multiplexing.  Senders
   MAY send RTP retransmission packets in = response to NACKs if support
   = for the RTP retransmission payload format has been negotiated, and = if
   the sender believes it is = useful to send a retransmission of the
   packet(s) referenced in the = NACK.  Senders do not need to retransmit
   every NACKed packet.

is this = acceptable?

Colin




On 28 Oct 2014, at 03:41, Bernard Aboba = <bernard.aboba@gmail.com> = wrote:
Justin = said: 

"I don't think the = WG ever explicitly signed up for session-multiplexing of RTX = data"

[BA] I agree, and in addition = would say the same thing with respect to FEC - one of the fundamental = objections to RFC 5109 is that it only support session-multiplexing, not = SSRC multiplexing.  

On Mon, Oct 27, 2014 at 5:18 PM, Justin Uberti = <juberti@google.com> = wrote:


On Mon, Oct 27, 2014 at 12:16 PM, Colin = Perkins <csp@csperkins.org> wrote:
On 27 = Oct 2014, at 17:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> = wrote:
=20 =20 =20
On 27/10/2014 18:10, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:51, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
=20
On 27/10/2014 17:45, Colin Perkins wrote:
=20 On 27 Oct 2014, at 16:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
=20
On 27/10/2014 17:36, Colin Perkins wrote:
On 21 Oct 2014, at 19:58, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Not sure if it is done on pourpose, but according to the RTP usage draft, it may seem that full RFC 4588 is mandated at the recevier side:

    Receivers are REQUIRED to implement support for RTP =
retransmission
    packets [RFC4588].

That would include both modes, session and ssrc multiplexing. Given the extensive usage of bundle and current implementations, session multiplexing support doesn't make much sense.

Should we drop it, and state that only ssrc-multiplexing shall be supported at the receiving end?

I don=92t see any advantage to doing so, given that support for non-BUNDLE sessions is REQUIRED. You need to implement the signalling needed for session-multiplexing of retransmission packet anyway, so disallowing it buys you nothing.

You can do SSRC multiplexing with BUNDLE and non-BUNDLE sessions, what I don't see is how to do session multiplexing with BUNDLE sessions.

You can=92t do session multiplexing for BUNDLE sessions; by definition they use SSRC multiplexing. You could do non-BUNDLE sessions, with retransmission sent on a separate RTP session though.

So, you are saying exactly the same than me. SSRC multiplexing supports both BUNDLE and NON-BUNDLE. So, why require support for session multiplexing at all? As a developer, I don't see why I would have to implement something that would be rarely used and provide no extra benefit.

Non-BUNDLE is session multiplexing. It uses a separate RTP session for the retransmissions.
Maybe I am the missing something, if you don't use bundle to send the audio/video on same rtpsession, you can still send rtx+video on same session. That's it non-bundle with ssrc-multiplexing. Are we referring to different = things?

Sure, but that = doesn=92t alter the fact that the group decided that non-BUNDLE media = needs to be supported. Sending retransmission on a separate RTP session = is as needed for interoperability with legacy systems as sending audio = and video on separate RTP sessions (and shouldn=92t be hard to support, = since it uses the same mechanisms).

No= n-BUNDLE media needs to be supported, but I don't think the WG ever = explicitly signed up for session-multiplexing of RTX data. Unified plan = is quite clear in its assertion that the primary, RTX, and FEC flows for = a given media stream should all be represented by a single m=3D line, = e.g. SSRC-multiplexed. 

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





<= div>-- 
Colin Perkins


=

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




-- 
Colin Perkins

<= /div>


= --Apple-Mail=_7CE8BFA8-BBF1-4BD2-A010-F931BEFB0890-- From nobody Mon Nov 10 08:51:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B201A011E for ; Mon, 10 Nov 2014 08:51:21 -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 7Sj1y7sSUg_w for ; Mon, 10 Nov 2014 08:51:14 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BCE1A00A8 for ; Mon, 10 Nov 2014 08:51:14 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so11124273wiv.0 for ; Mon, 10 Nov 2014 08:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6ejra7ClBn4xi8Nv4kGRDp+EgjyHA+zSAT8fUNqluyU=; b=rDdQ+Ek3jKi+doNjWu2M2MnyK6RCMFC2jngjXpOJiZMgpK/ctkDItKZGRQzflrq59Y 6ozlyFIprvHBTZXNBLtxO9ySL5BrTCwlkRt0nK5FrTfddIJVCjHkC1PHmMSQedGARjnW ZppiI4JU/+expEVQ476Nu1VvF0w7EdH5g+FfkJouYnT9fNMY4exhLenv290Zd92XYklH EqWp2peufp6z9G0zyyJT0Fk3Y8UeqY9Q7s69nK3H0cneeb0HXyv3YflOZ2YAa3LogsGe DPZEvxgT4ztnnJq3Jgz9mHJU/BccLtpjlcCTpsufa6U2kCzzw4dn3bkoEygF7f3U0FBm utew== X-Received: by 10.194.52.3 with SMTP id p3mr45352804wjo.93.1415638273062; Mon, 10 Nov 2014 08:51:13 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id s10sm14071619wix.14.2014.11.10.08.51.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 08:51:12 -0800 (PST) Message-ID: <5460ECFE.4000900@gmail.com> Date: Mon, 10 Nov 2014 17:51:10 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <54601E19.8080203@nostrum.com> <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com> In-Reply-To: <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mmR3pOq_zulpPDvh-vTmqMPc8kI Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 16:51:21 -0000 On 10/11/14 11:29, tim panton wrote: > Adam, thanks for sticking you head above the parapet ! > I’m largely in favour of this solution, further, I think it represents the realities on the ground It looks more like the reality on the ground of a few groups of interests (e.g, GSMA, telco vendors) trying to protect themselves. But again, in the web/internet world I don't see the same reality, they must stay competitive with features, not with restrictions or barriers to potential competitors. If something costly or with other restrictions is technically better or improving the user experience a lot in some medium of communication, then the developer of some app can decide to use/implement it. There is no reason of enforcing limits and financial constraints to everyone in open web via specs supposed to become standard. Rather than forcing now something inconvenient to be re-evaluated later for removal, better don't force anything now and re-evaluate later for inclusion. It will allow the market (besides the big players) to decide freely where it wants to move. The current proposal looks like: let's close the group now and later decide if we allow others in. Why not the other way around, keep the market fully open for new comers now and see what is going to be out there in few years, whether it makes sense to start building the walls at that moment. Daniel > better > than any other proposal to date, as such it merits support. > > On 10 Nov 2014, at 02:08, Adam Roach wrote: > >> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. > I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ language above. I think irrespective of new data, there will > always be devices who’s hardware or business model is best served by a specific codec, but that can meet every other requirement > of a webRTC device. > > I feel the appropriate language here is ‘either’ , ensuring that every device can always interact with a user agent > but that devices can’t necessarily communicate video between each other without a transcoding middle man. > > This leaves WebRTC-compatible endpoint as a category for things that implement neither video codec (e.g. audio only devices), or > don’t implement the data channel because it isn’t relevant to their application domain or only implement SDES (etc) - This gives a > clearer separation. > > This language choice matters most for developers who are selecting a native library to use when building a webRTC device. They need to > know what is supported - 'WebRTC-compatible’ means that they have to look very carefully at all the missing features, WebRTC-device > says that it will work with any user agent. > > With the current formulation there are no libraries that I know of suitable for building a webRTC device, making it an empty category. > > Tim. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Mon Nov 10 09:08:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9CE1A01F6 for ; Mon, 10 Nov 2014 09:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.872 X-Spam-Level: X-Spam-Status: No, score=-3.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMFDc_2W7YW2 for ; Mon, 10 Nov 2014 09:08:37 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBC81A0111 for ; Mon, 10 Nov 2014 09:08:37 -0800 (PST) Received: from [192.168.0.14] (cpe-72-130-133-154.hawaii.res.rr.com [72.130.133.154]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 98AC7F2054 for ; Mon, 10 Nov 2014 09:08:36 -0800 (PST) Message-ID: <5460F113.4090504@mozilla.com> Date: Mon, 10 Nov 2014 09:08:35 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <54601E19.8080203@nostrum.com> In-Reply-To: <54601E19.8080203@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0THsihJNRWI_Yq95Ptw5Ytc6Llw Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 17:08:40 -0000 Adam Roach wrote: > This has the property of ensuring that all devices and user agents can > work with all devices and user agents. This has the property of giving > no one exactly what they want. And, unlike any other previous plans, > this has the property of coming to a decision while maintaining pressure > on the only parties who can make a change in the IPR landscape to do so. I think this is a good proposal, and I can support it. It's obviously not my preferred outcome, but it's better than a lot of other places we could have wound up. Of course, with Daala/VP10/etc. I'll still be working to get us to that better place, but for now I want to thank the fine folks at Cisco and Google for being willing to discuss this in a productive manner and help WebRTC move forward. From nobody Mon Nov 10 09:29:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500051A1B80 for ; Mon, 10 Nov 2014 09:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 tjOyffEHQmWZ for ; Mon, 10 Nov 2014 09:29:15 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD631A1B86 for ; Mon, 10 Nov 2014 09:21:40 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 10 Nov 2014 09:15:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,353,1413270000"; d="scan'208";a="620059504" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga001.fm.intel.com with ESMTP; 10 Nov 2014 09:21:02 -0800 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Nov 2014 09:21:01 -0800 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by ORSMSX158.amr.corp.intel.com (10.22.240.20) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Nov 2014 09:21:01 -0800 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.180]) by FMSMSX102.amr.corp.intel.com ([10.18.124.200]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 09:21:01 -0800 From: "Cavigioli, Chris" To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/Qj2t1Us8NWOVUi3Mlc5jH+l4pxaGz8w Date: Mon, 10 Nov 2014 17:21:00 +0000 Message-ID: References: <54601E19.8080203@nostrum.com> <5460F113.4090504@mozilla.com> In-Reply-To: <5460F113.4090504@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TDohsnKLhV6kyPEroVJGNaz2AEQ Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 17:29:17 -0000 +1 -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Timothy B. Terri= berry Sent: Monday, November 10, 2014 9:09 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] MTI Video Codec: a novel proposal Adam Roach wrote: > This has the property of ensuring that all devices and user agents can=20 > work with all devices and user agents. This has the property of giving=20 > no one exactly what they want. And, unlike any other previous plans,=20 > this has the property of coming to a decision while maintaining=20 > pressure on the only parties who can make a change in the IPR landscape t= o do so. I think this is a good proposal, and I can support it. It's obviously not m= y preferred outcome, but it's better than a lot of other places we could ha= ve wound up. Of course, with Daala/VP10/etc. I'll still be working to get u= s to that better place, but for now I want to thank the fine folks at Cisco= and Google for being willing to discuss this in a productive manner and he= lp WebRTC move forward. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 09:46:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2411A1A4D for ; Mon, 10 Nov 2014 09:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amnfxjxYhzZQ for ; Mon, 10 Nov 2014 09:46:15 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC001A1A4C for ; Mon, 10 Nov 2014 09:40:34 -0800 (PST) Received: (qmail 65281 invoked from network); 10 Nov 2014 17:40:32 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 14345 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Nov 2014 17:40:32 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 185FD18A0E78; Mon, 10 Nov 2014 17:40:29 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id F3B2D18A056B; Mon, 10 Nov 2014 17:40:28 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3C902EBD-4044-4AE5-A9BC-D2DEF78BB730" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Tim Panton In-Reply-To: <5460ECFE.4000900@gmail.com> Date: Mon, 10 Nov 2014 17:40:27 +0000 Message-Id: References: <54601E19.8080203@nostrum.com> <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com> <5460ECFE.4000900@gmail.com> To: miconda@gmail.com X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pC2LfTrFHcYTUSCbsK-dVfiy5UY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 17:46:19 -0000 --Apple-Mail=_3C902EBD-4044-4AE5-A9BC-D2DEF78BB730 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 10 Nov 2014, at 16:51, Daniel-Constantin Mierla > wrote: >=20 >=20 > On 10/11/14 11:29, tim panton wrote: >> Adam, thanks for sticking you head above the parapet !=20 >> I=92m largely in favour of this solution, further, I think it = represents the realities on the ground >=20 > It looks more like the reality on the ground of a few groups of > interests (e.g, GSMA, telco vendors) trying to protect themselves. But > again, in the web/internet world I don't see the same reality, they = must > stay competitive with features, not with restrictions or barriers to > potential competitors. On the subject of codecs, I discount the opinion of the GSMA utterly, they have had 10 years to make video calling (and wideband audio) a desirable user proposition and have failed completely.=20 The realities I=92m thinking of are the ones facing someone building a video enabled pet phone (for example). I can get H264 hardware very cheaply (eg a raspberry Pi) and have it communicate with an ios App or firefox on a laptop without any license (as far as I can tell). Getting the same setup to work with VP8 will consume significantly=20 more battery power at both ends. I wish this were not the case, but that=92s the reality I see. >=20 > If something costly or with other restrictions is technically better = or > improving the user experience a lot in some medium of communication, > then the developer of some app can decide to use/implement it. There = is > no reason of enforcing limits and financial constraints to everyone in > open web via specs supposed to become standard. If we mandate both codecs for devices, I agree, we are imposing an = unacceptable burden on everyone. However I=92m doubtful that any entity who can afford to build a new w3c standards compatible browser will be unable to afford the (capped) = h264 fee, that=92s simply a measure of how much work I think it is to do a new = user agent now. So the penalty in terms of restricting new browser innovation is small = (IMHO) I=92m much more worried about innovative devices. >=20 > Rather than forcing now something inconvenient to be re-evaluated = later > for removal, better don't force anything now and re-evaluate later for > inclusion. It will allow the market (besides the big players) to = decide > freely where it wants to move. The current proposal looks like: let's > close the group now and later decide if we allow others in. Why not = the > other way around, keep the market fully open for new comers now and = see > what is going to be out there in few years, whether it makes sense to > start building the walls at that moment. That=92s where we disagree. I really do not want to have to have a = complex matrix of versions of my parrot phone that correctly interop with other = devices and other pairings that don=92t. (E.G. buy a new android tablet and our android app if you use chrome, = but if you reuse an old ipad, you=92ll have to use firefox). We need an MTI statement. If we don=92t get one we will be stuck with = little facetime-like islands again. >=20 > Daniel >=20 >> better >> than any other proposal to date, as such it merits support. >>=20 >> On 10 Nov 2014, at 02:08, Adam Roach > wrote: >>=20 >>> WebRTC devices MUST implement both VP8 and H.264. If compelling = evidence arises that one of the codecs is available for use on a = royalty-free basis, such as all IPR declarations known for the codec = being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this = normative statement to indicate that only that codec is required. For = absolute, crystal clarity, this provision is only applicable to WebRTC = devices, and not to WebRTC User Agents.=20 >> I do have a slight qualm about the " =91both=92 or perhaps only =91one=92= =93 language above. I think irrespective of new data, there will=20 >> always be devices who=92s hardware or business model is best served = by a specific codec, but that can meet every other requirement >> of a webRTC device. >>=20 >> I feel the appropriate language here is =91either=92 , ensuring that = every device can always interact with a user agent >> but that devices can=92t necessarily communicate video between each = other without a transcoding middle man. >>=20 >> This leaves WebRTC-compatible endpoint as a category for things that = implement neither video codec (e.g. audio only devices), or >> don=92t implement the data channel because it isn=92t relevant to = their application domain or only implement SDES (etc) - This gives a=20 >> clearer separation. >>=20 >> This language choice matters most for developers who are selecting a = native library to use when building a webRTC device. They need to >> know what is supported - 'WebRTC-compatible=92 means that they have = to look very carefully at all the missing features, WebRTC-device >> says that it will work with any user agent.=20 >>=20 >> With the current formulation there are no libraries that I know of = suitable for building a webRTC device, making it an empty category. >>=20 >> Tim. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > --=20 > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - = http://www.linkedin.com/in/miconda >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_3C902EBD-4044-4AE5-A9BC-D2DEF78BB730 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 10 = Nov 2014, at 16:51, Daniel-Constantin Mierla <miconda@gmail.com> = wrote:


On 10/11/14 11:29, tim panton wrote:
Adam, thanks for sticking you head above the = parapet !
I=92m largely in favour of this solution, = further, I think it represents the realities on the ground

It looks more like the reality on = the ground of a few groups of
interests (e.g, GSMA, telco = vendors) trying to protect themselves. But
again, in the = web/internet world I don't see the same reality, they must
stay competitive with features, not with restrictions or = barriers to
potential competitors.

On the subject of codecs, I discount the opinion of the GSMA = utterly,
they have had 10 years  to make video = calling (and wideband audio)
a desirable user = proposition and have failed completely. 

The realities I=92m thinking of are the = ones facing someone building a
video enabled pet = phone (for example). I can get H264 hardware very
cheaply (eg a raspberry Pi) and have it communicate with an = ios App
or firefox on a laptop without any license = (as far as I can tell).
Getting the same setup to = work with VP8 will consume significantly 
more = battery power at both ends.

I wish this were not the case, but that=92s the reality I = see.


If something costly or with = other restrictions is technically better or
improving the = user experience a lot in some medium of communication,
then = the developer of some app can decide to use/implement it. There is
no reason of enforcing limits and financial constraints to = everyone in
open web via specs supposed to become = standard.

If we mandate both codecs for devices, = I agree, we are imposing an unacceptable
burden on = everyone.
However I=92m doubtful that any entity = who can afford to build a new
w3c standards = compatible browser will be unable to afford the (capped) h264 = fee,
that=92s simply a measure of how much work I = think it is to do a new user agent now.
So the = penalty in terms of restricting new browser innovation is small =  (IMHO)
I=92m much more worried about = innovative devices.


Rather than forcing now = something inconvenient to be re-evaluated later
for = removal, better don't force anything now and re-evaluate later for
inclusion. It will allow the market (besides the big players) = to decide
freely where it wants to move. The current = proposal looks like: let's
close the group now and later = decide if we allow others in. Why not the
other way = around, keep the market fully open for new comers now and see
what is going to be out there in few years, whether it makes = sense to
start building the walls at that moment.

That=92s where we disagree. I really do not want to have to = have a complex
matrix of versions of my parrot = phone that correctly interop with other devices and
other pairings that don=92t.

(E.G. buy a new android tablet and our = android app if you use chrome, but if you reuse
an = old ipad, you=92ll have to use firefox).

We need an MTI statement. If we don=92t = get one we will be stuck with little
facetime-like = islands again.


Daniel

better
than= any other proposal to date, as such it merits support.

On 10 Nov 2014, at 02:08, Adam Roach <adam@nostrum.com> = wrote:

WebRTC devices MUST implement both VP8 and H.264. If = compelling evidence arises that one of the codecs is available for use = on a royalty-free basis, such as all IPR declarations known for the = codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change = this normative statement to indicate that only that codec is required. = For absolute, crystal clarity, this provision is only applicable to = WebRTC devices, and not to WebRTC User Agents.
I do have a slight qualm about the " =91both=92 = or perhaps only =91one=92 =93 language above. I think irrespective of = new data, there will
always be devices who=92s hardware = or business model is best served by a specific codec, but that can meet = every other requirement
of a webRTC device.

I feel the appropriate language here is = =91either=92 , ensuring that every device can always interact with a = user agent
but that devices can=92t necessarily = communicate video between each other without a transcoding middle = man.

This leaves WebRTC-compatible endpoint = as a category for things that implement neither video codec (e.g. audio = only devices), or
don=92t implement the data channel = because it isn=92t relevant to their application domain or only = implement SDES (etc) - This gives a
clearer = separation.

This language choice matters = most for developers who are selecting a native library to use when = building a webRTC device. They need to
know what is = supported -  'WebRTC-compatible=92 means that they have to look = very carefully at all the missing features, WebRTC-device
says that it will work with any user agent.

With the current formulation there are no libraries that I = know of suitable for building a webRTC device, making it an empty = category.

Tim.

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

--
Daniel-Constantin= Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

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

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



= --Apple-Mail=_3C902EBD-4044-4AE5-A9BC-D2DEF78BB730-- From nobody Mon Nov 10 10:29:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3ABA1A82E2 for ; Mon, 10 Nov 2014 10:29:44 -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 xFKstFnJGRNu for ; Mon, 10 Nov 2014 10:29:42 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F342E1A9102 for ; Mon, 10 Nov 2014 10:27:22 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id x19so9525360ier.5 for ; Mon, 10 Nov 2014 10:27:22 -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=vPvXmMLhpLXY5yz3BJON6y8pMXIqq6U0WnRt1OaVdww=; b=kTFoCGIj8gcVldTbclscpSra8wfimuY13Z2JuW50VTv2oVJZmoaJUMxK3JO2XxC92m DqTtOF0faKE0c7pLQUyQxMp1OwRBgLO2JkqWEMTOCnt3zvc+MCORzpFhQpy+lmkYC7/N ST726DMFVSP3/E9GR5cYv0hny3aE/pXWbYaxlfIlreLxTu6hP3x7GiRBlPcRE6pkKwcx XXwxnZzbZwsofqUOUmEENGDn8yLY6jemgDNxWWHSSer+Q5O+x/bvKlaJQ8Z98SmdTCGM NBjDTO1Ts/SH1qHzGXbQ1WWGjfX2E7Otrq8ItCtTSJp0RdqhpxZjulY4375+cnOMzaVl VX0A== X-Gm-Message-State: ALoCoQnGQoMpx/JOfwPbvYU3MtrVTQcIM7FC1/EQ+AXWjrThR8S2NjzYFU9KOq8Qpymt9Q9Zg694 X-Received: by 10.50.134.9 with SMTP id pg9mr26822879igb.28.1415644042328; Mon, 10 Nov 2014 10:27:22 -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 w7sm5098691igl.7.2014.11.10.10.27.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 10:27:21 -0800 (PST) Message-ID: <54610389.7060103@bbs.darktech.org> Date: Mon, 10 Nov 2014 13:27:21 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com> <5460ECFE.4000900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xagQHS7_hmqDCIy3NLuOeazZ4GI Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 18:29:44 -0000 On 10/11/2014 12:40 PM, Tim Panton wrote: > The realities I’m thinking of are the ones facing someone building a > video enabled pet phone (for example). I can get H264 hardware very > cheaply (eg a raspberry Pi) and have it communicate with an ios App > or firefox on a laptop without any license (as far as I can tell). > Getting the same setup to work with VP8 will consume significantly > more battery power at both ends. > > I wish this were not the case, but that’s the reality I see. I was/am under the impression that this reality will change over the coming year as devices roll out with hardware VP8 support. According to http://wiki.webmproject.org/hardware/devices Raspberry Pi already supports hardware decoding. The assumption is that they are working on hardware encoding in a future release. Gili From nobody Mon Nov 10 10:30:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C801A6FF5 for ; Mon, 10 Nov 2014 10:30:19 -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 w7_U9eBzbUGq for ; Mon, 10 Nov 2014 10:30:15 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931FD1A700E for ; Mon, 10 Nov 2014 10:28:00 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so11309318wib.11 for ; Mon, 10 Nov 2014 10:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=FEJ+FzUcyPDoJnqe22V9feOqChhOGi+iP/EnWLdH2YY=; b=NFXEQYF2/Fc3cY/O05wqx9DyxYRGFQSHjMXZ1XUrkIx987uiUKYUnOPpjjhkpjOKoi B1RF9FHK5G/SMs1T2hrIojD6pcYlQWPlFJQRRKGBaql4/8+o/YIsC1dK3Yx/0NYmaYLR fqeC1SLACNLSYzrfb+C55NqHTCmvUZjkCSQFUG6jd33fCTIHPwnIJRScZRJZNenSZjSA 5Wb088rHkzbm6GMvfNHBG8P6aQNCX44xn7JFXW5COPlVXKxHk2UeJ2ZROAECfqANKb+r VF7LC9gWtHyXDIoBChn1qVIpGAD0q+IiGT+vfc9UtutUcqEgoOZnlfv0J1/fZ+YyEvci Lrrw== X-Received: by 10.181.13.208 with SMTP id fa16mr32334170wid.61.1415644078027; Mon, 10 Nov 2014 10:27:58 -0800 (PST) Received: from [127.0.0.1] ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ua8sm24174424wjc.7.2014.11.10.10.27.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 10:27:57 -0800 (PST) Message-ID: <546103AB.7040501@gmail.com> Date: Mon, 10 Nov 2014 19:27:55 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Tim Panton References: <54601E19.8080203@nostrum.com> <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com> <5460ECFE.4000900@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020901030703000804030302" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gkk39QZWj3eBgXXCV8gnJ8SarIE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 18:30:19 -0000 This is a multi-part message in MIME format. --------------020901030703000804030302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 10/11/14 18:40, Tim Panton wrote: > >> On 10 Nov 2014, at 16:51, Daniel-Constantin Mierla > > wrote: >> >> >> On 10/11/14 11:29, tim panton wrote: >>> Adam, thanks for sticking you head above the parapet ! >>> I’m largely in favour of this solution, further, I think it >>> represents the realities on the ground >> >> It looks more like the reality on the ground of a few groups of >> interests (e.g, GSMA, telco vendors) trying to protect themselves. But >> again, in the web/internet world I don't see the same reality, they must >> stay competitive with features, not with restrictions or barriers to >> potential competitors. > > On the subject of codecs, I discount the opinion of the GSMA utterly, > they have had 10 years to make video calling (and wideband audio) > a desirable user proposition and have failed completely. > > The realities I’m thinking of are the ones facing someone building a > video enabled pet phone (for example). I can get H264 hardware very > cheaply (eg a raspberry Pi) and have it communicate with an ios App > or firefox on a laptop without any license (as far as I can tell). > Getting the same setup to work with VP8 will consume significantly > more battery power at both ends. > > I wish this were not the case, but that’s the reality I see. Very cheaply for one user, but can be very costly for a service or an app distributed to the masses. Then it was not clear (unless I missed some resolution on the topic during the summer) if you can rely on the license given to the hardware. Why not standardize the h264 and vp8 hardware control API, the manufactures of hardware devices have to implement it and the app developers have to use them?!? Then practically, the apps devs don't need to mess with ipr of h264 or vp8 -- if there is hardware support with appropriate API, then will be enabled. > >> >> If something costly or with other restrictions is technically better or >> improving the user experience a lot in some medium of communication, >> then the developer of some app can decide to use/implement it. There is >> no reason of enforcing limits and financial constraints to everyone in >> open web via specs supposed to become standard. > > If we mandate both codecs for devices, I agree, we are imposing an > unacceptable > burden on everyone. > However I’m doubtful that any entity who can afford to build a new > w3c standards compatible browser will be unable to afford the (capped) > h264 fee, You can have one in minutes by making own built of firefox or chromium, discarding the non-source-code licensed/copyrighted items such as logos, icons, etc ... then tailor it for your specific needs (e.g., more privacy, no automatic reports, etc.) The problem is that the new built app doesn't have the financial power as the original one, but still distributed to the masses in an uncontrollable way (e.g., linux distros, with mirrors, etc.). I already pointed that such cases exists already (e.g., debian). Also, repeating, some those big browsers started as forks from rather small and non-financial-powerful projects. I see I missed to follow up on a previous discussion thread -- KHTML is on more or less the same level with WebKit (which started as a fork of the former, getting on board some extra libs), the browsers relies on them as html/js engines. Now opera is using chorme html engine and benefits of all webrtc features chrome has -- in reality they are still different browsers with the specific features mainly related to interaction to the users rather than the protocol or other specific technical aspects (html/http). > that’s simply a measure of how much work I think it is to do a new > user agent now. > So the penalty in terms of restricting new browser innovation is small > (IMHO) > I’m much more worried about innovative devices. > >> >> Rather than forcing now something inconvenient to be re-evaluated later >> for removal, better don't force anything now and re-evaluate later for >> inclusion. It will allow the market (besides the big players) to decide >> freely where it wants to move. The current proposal looks like: let's >> close the group now and later decide if we allow others in. Why not the >> other way around, keep the market fully open for new comers now and see >> what is going to be out there in few years, whether it makes sense to >> start building the walls at that moment. > > That’s where we disagree. I really do not want to have to have a complex > matrix of versions of my parrot phone that correctly interop with > other devices and > other pairings that don’t. > > (E.G. buy a new android tablet and our android app if you use chrome, > but if you reuse > an old ipad, you’ll have to use firefox). > > We need an MTI statement. If we don’t get one we will be stuck with little > facetime-like islands again. Otherwise we get stuck to some browsers that can vanish your expectations on security. And if there is a different set of requirements for a WebRTC device and a WebRT UA, you still have to keep a matrix: it is working with Chrome, but not working with X-Lite Communicator. I don't see an easy way to explain to an end user that webrtc endpoints don't have same capabilities on media. There are benefits on having a MTI for video codec, but one that doesn't impose any kind of restrictions, otherwise it brings more disadvantages now and in long term. Daniel >>> better >>> than any other proposal to date, as such it merits support. >>> >>> On 10 Nov 2014, at 02:08, Adam Roach >> > wrote: >>> >>>> WebRTC devices MUST implement both VP8 and H.264. If compelling >>>> evidence arises that one of the codecs is available for use on a >>>> royalty-free basis, such as all IPR declarations known for the >>>> codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will >>>> change this normative statement to indicate that only that codec is >>>> required. For absolute, crystal clarity, this provision is only >>>> applicable to WebRTC devices, and not to WebRTC User Agents. >>> I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ >>> language above. I think irrespective of new data, there will >>> always be devices who’s hardware or business model is best served by >>> a specific codec, but that can meet every other requirement >>> of a webRTC device. >>> >>> I feel the appropriate language here is ‘either’ , ensuring that >>> every device can always interact with a user agent >>> but that devices can’t necessarily communicate video between each >>> other without a transcoding middle man. >>> >>> This leaves WebRTC-compatible endpoint as a category for things that >>> implement neither video codec (e.g. audio only devices), or >>> don’t implement the data channel because it isn’t relevant to their >>> application domain or only implement SDES (etc) - This gives a >>> clearer separation. >>> >>> This language choice matters most for developers who are selecting a >>> native library to use when building a webRTC device. They need to >>> know what is supported - 'WebRTC-compatible’ means that they have >>> to look very carefully at all the missing features, WebRTC-device >>> says that it will work with any user agent. >>> >>> With the current formulation there are no libraries that I know of >>> suitable for building a webRTC device, making it an empty category. >>> >>> Tim. >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> -- >> Daniel-Constantin Mierla >> http://twitter.com/#!/miconda - >> http://www.linkedin.com/in/miconda >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > Tim Panton - Web/VoIP consultant and implementor > www.westhawk.co.uk > > > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com --------------020901030703000804030302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/11/14 18:40, Tim Panton wrote:

On 10 Nov 2014, at 16:51, Daniel-Constantin Mierla <miconda@gmail.com> wrote:


On 10/11/14 11:29, tim panton wrote:
Adam, thanks for sticking you head above the parapet !
I’m largely in favour of this solution, further, I think it represents the realities on the ground

It looks more like the reality on the ground of a few groups of
interests (e.g, GSMA, telco vendors) trying to protect themselves. But
again, in the web/internet world I don't see the same reality, they must
stay competitive with features, not with restrictions or barriers to
potential competitors.

On the subject of codecs, I discount the opinion of the GSMA utterly,
they have had 10 years  to make video calling (and wideband audio)
a desirable user proposition and have failed completely. 

The realities I’m thinking of are the ones facing someone building a
video enabled pet phone (for example). I can get H264 hardware very
cheaply (eg a raspberry Pi) and have it communicate with an ios App
or firefox on a laptop without any license (as far as I can tell).
Getting the same setup to work with VP8 will consume significantly 
more battery power at both ends.

I wish this were not the case, but that’s the reality I see.

Very cheaply for one user, but can be very costly for a service or an app distributed to the masses. Then it was not clear (unless I missed some resolution on the topic during the summer) if you can rely on the license given to the hardware.

Why not standardize the h264 and vp8 hardware control API, the manufactures of hardware devices have to implement it and the app developers have to use them?!? Then practically, the apps devs don't need to mess with ipr of h264 or vp8 -- if there is hardware support with appropriate API, then will be enabled.



If something costly or with other restrictions is technically better or
improving the user experience a lot in some medium of communication,
then the developer of some app can decide to use/implement it. There is
no reason of enforcing limits and financial constraints to everyone in
open web via specs supposed to become standard.

If we mandate both codecs for devices, I agree, we are imposing an unacceptable
burden on everyone.
However I’m doubtful that any entity who can afford to build a new
w3c standards compatible browser will be unable to afford the (capped) h264 fee,

You can have one in minutes by making own built of firefox or chromium, discarding the non-source-code licensed/copyrighted items such as logos, icons, etc ... then tailor it for your specific needs (e.g., more privacy, no automatic reports, etc.) The problem is that the new built app doesn't have the financial power as the original one, but still distributed to the masses in an uncontrollable way (e.g., linux distros, with mirrors, etc.).

I already pointed that such cases exists already (e.g., debian). Also, repeating, some those big browsers started as forks from rather small and non-financial-powerful projects.

I see I missed to follow up on a previous discussion thread -- KHTML is on more or less the same level with WebKit (which started as a fork of the former, getting on board some extra libs), the browsers relies on them as html/js engines. Now opera is using chorme html engine and benefits of all webrtc features chrome has -- in reality they are still different browsers with the specific features mainly related to interaction to the users rather than the protocol or other specific technical aspects (html/http).

that’s simply a measure of how much work I think it is to do a new user agent now.
So the penalty in terms of restricting new browser innovation is small  (IMHO)
I’m much more worried about innovative devices.


Rather than forcing now something inconvenient to be re-evaluated later
for removal, better don't force anything now and re-evaluate later for
inclusion. It will allow the market (besides the big players) to decide
freely where it wants to move. The current proposal looks like: let's
close the group now and later decide if we allow others in. Why not the
other way around, keep the market fully open for new comers now and see
what is going to be out there in few years, whether it makes sense to
start building the walls at that moment.

That’s where we disagree. I really do not want to have to have a complex
matrix of versions of my parrot phone that correctly interop with other devices and
other pairings that don’t.

(E.G. buy a new android tablet and our android app if you use chrome, but if you reuse
an old ipad, you’ll have to use firefox).

We need an MTI statement. If we don’t get one we will be stuck with little
facetime-like islands again.

Otherwise we get stuck to some browsers that can vanish your expectations on security.

And if there is a different set of requirements for a WebRTC device and a WebRT UA, you still have to keep a matrix: it is working with Chrome, but not working with X-Lite Communicator. I don't see an easy way to explain to an end user that webrtc endpoints don't have same capabilities on media.

There are benefits on having a MTI for video codec, but one that doesn't impose any kind of restrictions, otherwise it brings more disadvantages now and in long term.

Daniel

better
than any other proposal to date, as such it merits support.

On 10 Nov 2014, at 02:08, Adam Roach <adam@nostrum.com> wrote:

WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.
I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ language above. I think irrespective of new data, there will
always be devices who’s hardware or business model is best served by a specific codec, but that can meet every other requirement
of a webRTC device.

I feel the appropriate language here is ‘either’ , ensuring that every device can always interact with a user agent
but that devices can’t necessarily communicate video between each other without a transcoding middle man.

This leaves WebRTC-compatible endpoint as a category for things that implement neither video codec (e.g. audio only devices), or
don’t implement the data channel because it isn’t relevant to their application domain or only implement SDES (etc) - This gives a
clearer separation.

This language choice matters most for developers who are selecting a native library to use when building a webRTC device. They need to
know what is supported -  'WebRTC-compatible’ means that they have to look very carefully at all the missing features, WebRTC-device
says that it will work with any user agent.

With the current formulation there are no libraries that I know of suitable for building a webRTC device, making it an empty category.

Tim.

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

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

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

Tim Panton - Web/VoIP consultant and implementor




-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com
--------------020901030703000804030302-- From nobody Mon Nov 10 10:50:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB021A9110 for ; Mon, 10 Nov 2014 10:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u56Mbt6FV7l0 for ; Mon, 10 Nov 2014 10:50:50 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996F41A910A for ; Mon, 10 Nov 2014 10:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=462; q=dns/txt; s=iport; t=1415645450; x=1416855050; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LwwMDrStLaX1Q0rBbaDoxTLl9An5MOTIrn4LptTmfdU=; b=YiemeOq2+0vQ7ui1dOv8UyvSEZTeWYX3YK27XOPtgrEHZscPhtBjsvSW ixCiFplEC7KhzUeQHGtfjYLaWtXWkZGYGu5CnBv9uelpnPOcPF8CC95jC eMbuX/nIlyfAzQv4zumsLiUDz8VNvfeahvSIi+BqPY+BOz1q1mwGyf8K2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcLAPYHYVStJA2E/2dsb2JhbABcgw6BLbgoBQF0miwCgScWAQEBAQF9hAMBAQMBOj8FCwtGVwYTiDgIAc5BAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Y6iigzB4MtgR4BBJ4lh3qOZoQeSIJLAQEB X-IronPort-AV: E=Sophos;i="5.07,354,1413244800"; d="scan'208";a="370957101" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 10 Nov 2014 18:50:50 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAAIonON007551; Mon, 10 Nov 2014 18:50:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Cullen Jennings In-Reply-To: <5460F113.4090504@mozilla.com> Date: Mon, 10 Nov 2014 08:50:49 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54601E19.8080203@nostrum.com> <5460F113.4090504@mozilla.com> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nitfQdkPPlyP8AXxL_-hRCR1R5k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 18:50:51 -0000 On Nov 10, 2014, at 7:08 AM, Timothy B. Terriberry = wrote: > I think this is a good proposal, and I can support it. It's obviously = not my preferred outcome, but it's better than a lot of other places we = could have wound up. Of course, with Daala/VP10/etc. I'll still be = working to get us to that better place,=20 +1 - Tim text above pretty much gets my feeling on this. Cullen (in my individual contributor role) From nobody Mon Nov 10 10:56:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ED81A90F3 for ; Mon, 10 Nov 2014 10:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 z5p3a4NbQ_OH for ; Mon, 10 Nov 2014 10:56:46 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id DE7D51A86E0 for ; Mon, 10 Nov 2014 10:56:44 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 10 Nov 2014 10:56:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,354,1413270000"; d="scan'208";a="634616185" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga002.jf.intel.com with ESMTP; 10 Nov 2014 10:56:16 -0800 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Nov 2014 10:56:16 -0800 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.180]) by fmsmsx117.amr.corp.intel.com ([10.18.116.17]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 10:56:16 -0800 From: "Cavigioli, Chris" To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/RP3t1Us8NWOVUi3Mlc5jH+l4pxaM8fA Date: Mon, 10 Nov 2014 18:56:15 +0000 Message-ID: References: <54601E19.8080203@nostrum.com> <6689CD42-C046-45DE-9871-16538A799810@phonefromhere.com> <5460ECFE.4000900@gmail.com> <54610389.7060103@bbs.darktech.org> In-Reply-To: <54610389.7060103@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j8CMloVb22gysrOa25hioL10fJ0 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 18:56:48 -0000 As a preview of future devices, see this page: http://wiki.webmproject.org/= hardware/socs showing several chips (SoCs) supporting full HD VP8 (and H.26= 4) encode AND decode hardware acceleration. Intel launched phone/tablet platforms at MWC in February that demonstrated = hardware WebRTC. Thus our codec neutrality in this debate. -chris -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc Sent: Monday, November 10, 2014 10:27 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] MTI Video Codec: a novel proposal On 10/11/2014 12:40 PM, Tim Panton wrote: > The realities I'm thinking of are the ones facing someone building a=20 > video enabled pet phone (for example). I can get H264 hardware very=20 > cheaply (eg a raspberry Pi) and have it communicate with an ios App or=20 > firefox on a laptop without any license (as far as I can tell). > Getting the same setup to work with VP8 will consume significantly=20 > more battery power at both ends. > > I wish this were not the case, but that's the reality I see. I was/am under the impression that this reality will change over the coming= year as devices roll out with hardware VP8 support. According to http://wiki.webmproject.org/hardware/devices Raspberry Pi alre= ady supports hardware decoding. The assumption is that they are working on = hardware encoding in a future release. Gili _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 11:02:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7241A1BBF for ; Mon, 10 Nov 2014 11:02:34 -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, 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 VfjTLPiNZ6GR for ; Mon, 10 Nov 2014 11:02:32 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066D31A6F02 for ; Mon, 10 Nov 2014 11:02:30 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-c8-54610bc4c1a4 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.25.24955.4CB01645; Mon, 10 Nov 2014 20:02:29 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.247]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Mon, 10 Nov 2014 20:02:28 +0100 From: Bo Burman To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-burman-rtcweb-h264-proposal-05.txt Thread-Index: AQHP8joWdmadj6GaeEaCL5egsVSID5xaS4wg Date: Mon, 10 Nov 2014 19:02:27 +0000 Message-ID: References: <20141027230127.2525.28778.idtracker@ietfa.amsl.com> In-Reply-To: <20141027230127.2525.28778.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje5R7sQQg6lT2S3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqI5QgUXBCq6284xNTDOEOhi5OSQEDCROL7nOSuELSZx4d56 ti5GLg4hgSOMEqvvfoFyljBKvLn4nwmkik1AQ2L+jruMILaIgLrE5YcX2EFsYYEQid4rr5gh 4qES35c8YYKwjSR+Xe8Cq2ERUJW4PGMaWC+vgK/EnUcLgeo5gBY4SBzfXQsS5hRwlDiw4jZY K6OArMT97/dYQGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl439QDyhJLLr9mQlkJLOApsT6XfoQ rYoSU7ofskNsFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGEWLU4uTctONjPVSizKTi4vz 8/TyUks2MQKj4eCW36o7GC+/cTzEKMDBqMTD++FjfIgQa2JZcWXuIUZpDhYlcd6F5+YFCwmk J5akZqemFqQWxReV5qQWH2Jk4uCUamCsWDHzP7MPoyNjqcXv3D0buPzDzhRb1m2LrfDymzLl 4ubN15TmezCLePnyTriXrXrsWXinFO8lJsYD81btviB5u0iir2Wl9X3BnfOCHslu+fzn4+GL kxY6dk/nSdDYf5T/wB3BbI54scabod/aVFse8O5Z+oDhQWfJ+YvvBB07bkouMH0yb76PEktx RqKhFnNRcSIAAtyqLWcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TzqDek9WFxDw0wXD7RebxJq70B0 Subject: [rtcweb] FW: New Version Notification for draft-burman-rtcweb-h264-proposal-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:02:34 -0000 QWxsLA0KDQpJIGp1c3QgcmVhbGl6ZWQgaXQgd2FzIG5vdCBhbm5vdW5jZWQgdG8gdGhpcyBsaXN0 LCBidXQgdGhpcyBkcmFmdCB3YXMgc3VibWl0dGVkIGp1c3QgYmVmb3JlIHRoZSBkcmFmdCBkZWFk bGluZSB0d28gd2Vla3MgYWdvLiBUaGVyZSBhcmUgbm8gcmVhbGx5IHNpZ25pZmljYW50IGNoYW5n ZXMsIGJ1dCBvbmx5IHNvbWUgbWlub3IgdXBkYXRlcyB0byBtYWtlIHRoZSBpbmZvcm1hdGlvbiBt b3JlIHVwIHRvIGRhdGUuDQoNCkNoZWVycywNCkJvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogZGVuIDI3IG9rdG9iZXIgMjAxNCAxMzowMQ0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1idXJtYW4tcnRjd2ViLWgyNjQtcHJv cG9zYWwtMDUudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1idXJtYW4tcnRjd2Vi LWgyNjQtcHJvcG9zYWwtMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEJvIEJ1cm1hbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlk cmFmdC1idXJtYW4tcnRjd2ViLWgyNjQtcHJvcG9zYWwNClJldmlzaW9uOgkwNQ0KVGl0bGU6CQlI LjI2NCBhcyBNYW5kYXRvcnkgdG8gSW1wbGVtZW50IFZpZGVvIENvZGVjIGZvciBXZWJSVEMNCkRv Y3VtZW50IGRhdGU6CTIwMTQtMTAtMjcNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczoJCTIxDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYnVybWFuLXJ0Y3dlYi1oMjY0LXByb3Bvc2FsLTA1LnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ1cm1hbi1ydGN3 ZWItaDI2NC1wcm9wb3NhbC8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1idXJtYW4tcnRjd2ViLWgyNjQtcHJvcG9zYWwtMDUNCkRpZmY6ICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1idXJtYW4tcnRjd2ViLWgy NjQtcHJvcG9zYWwtMDUNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRo YXQsIGFuZCBtb3RpdmF0ZXMgd2h5LCBILjI2NCBzaG91bGQgYmUgYQ0KICAgTWFuZGF0b3J5IFRv IEltcGxlbWVudCB2aWRlbyBjb2RlYyBmb3IgV2ViUlRDLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From nobody Mon Nov 10 11:15:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D171AC3AD for ; Mon, 10 Nov 2014 11:15:26 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eErHEPO8GFcC for ; Mon, 10 Nov 2014 11:15:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111CE1A1B3B for ; Mon, 10 Nov 2014 11:15:01 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) with Microsoft SMTP Server (TLS) id 15.1.16.15; Mon, 10 Nov 2014 19:14:38 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0016.006; Mon, 10 Nov 2014 19:14:38 +0000 From: Stephan Wenger To: Adam Roach , "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/ItBpFNPg+hX/0+kjwh/lYHl/ZxZlGAA Date: Mon, 10 Nov 2014 19:14:37 +0000 Message-ID: References: <54601E19.8080203@nostrum.com> In-Reply-To: <54601E19.8080203@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.161.244] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275; x-forefront-prvs: 039178EF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(199003)(189002)(19580395003)(2501002)(66066001)(50986999)(16236675004)(19580405001)(31966008)(106356001)(105586002)(122556002)(106116001)(76176999)(95666004)(99286002)(99396003)(54356999)(40100003)(120916001)(107886001)(107046002)(86362001)(92566001)(92726001)(97736003)(20776003)(77156002)(101416001)(62966003)(87936001)(36756003)(2656002)(46102003)(64706001)(4396001)(21056001)(561944003)(77096003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1275; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D08625BB4ACA8stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZP1lgPzN5DuBUvR8F57THHmX2w8 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 19:15:26 -0000 --_000_D08625BB4ACA8stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I like and support the spirit of this proposal, but have one issue with the= formulation below, and would like to see it clarified. Stephan From: Adam Roach > Date: Sunday, November 9, 2014 at 18:08 To: "rtcweb@ietf.org" > Subject: [rtcweb] MTI Video Codec: a novel proposal [...] If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. [...] First: "the IETF WILL CHANGE": I don't think that such forward looking, abs= olute statements are appropriate. And probably also not correct. Some of = the objections here are not over royalties, but over ecosystem dominance; n= ever mind the money. Whether or not the IETF changes its opinion will at l= east partly be based based on the power distribution of players subscribing= to ecosystem agendas at the time the situation changes. Second, "all IPR declarations known for the codec being of (IETF) Royalty-F= ree or (ISO) type 1" is IMO not compelling evidence for a royalty free code= c; for many reasons that have been spelled out before. Similarly, type 2 R= AND statements are not evidence that royalties are necessarily being paid. To me, evidence for a (practically) RF H.264 codec would be an MPEG-LA pool= rightholder decision not to require the payment of royalties. For VP[8,9]= , the licensing arrangement google has made got a long way to convince me, = but what would be needed in addition is to overcome known objections by pla= yers, however expressed. (Note that legal departments will typically be ve= ry reluctant to submit type 1 statements, whereas the business groups may b= e more easily able to communicate a company decision for zero royalty.) Fo= r newer codecs, what would be needed is both very wide participation (inclu= ding all the key players in both IETF and VCEG/MPEG) and RF declarations in= whatever organization doing the work. Clearly, at this point, none of H.2= 65, VP10, or Daala fulfill those conditions. Thanks, Stephan --_000_D08625BB4ACA8stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,
I like and support the spirit of this proposal, but have one issue wit= h the formulation below, and would like to see it clarified.
Stephan


From: Adam Roach <adam@nostrum.com>
Date: Sunday, November 9, 2014 at 1= 8:08
To: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: [rtcweb] MTI Video Codec: = a novel proposal

[…]
If com= pelling evidence arises that one of the codecs is
availa= ble for use on a royalty-free basis, such as all IPR 
declar= ations known for the codec being of (IETF) Royalty-Free 
or (IS= O) type 1, the IETF will change this normative statement
to ind= icate that only that codec is required. 
[̷= 0;]

First: “the IETF WILL CHANGE”: I don’t think that su= ch forward looking, absolute statements are appropriate.  And probably= also not correct.  Some of the objections here are not over royalties= , but over ecosystem dominance; never mind the money.  Whether or not the IETF changes its opinion will at least partly be based based on= the power distribution of players subscribing to ecosystem agendas at the = time the situation changes.

Second, “all IPR declarations known for the codec being of (IETF= ) Royalty-Free or (ISO) type 1” is IMO not compelling evidence for a = royalty free codec; for many reasons that have been spelled out before. &nb= sp;Similarly, type 2 RAND statements are not evidence that royalties are necessarily being paid.  
To me, evidence for a (practically) RF H.264 codec would be an MPEG-LA= pool rightholder decision not to require the payment of royalties.  F= or VP[8,9], the licensing arrangement google has made got a long way to con= vince me, but what would be needed in addition is to overcome known objections by players, however expressed. &n= bsp;(Note that legal departments will typically be very reluctant to submit= type 1 statements, whereas the business groups may be more easily able to = communicate a company decision for zero royalty.)  For newer codecs, what would be needed is both very wide p= articipation (including all the key players in both IETF and VCEG/MPEG) and= RF declarations in whatever organization doing the work.  Clearly, at= this point, none of H.265, VP10, or Daala fulfill those conditions.

Thanks,
Stephan
--_000_D08625BB4ACA8stewesteweorg_-- From nobody Mon Nov 10 11:42:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A383C1AC3CD for ; Mon, 10 Nov 2014 11:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnY13VG3FLNJ for ; Mon, 10 Nov 2014 11:42:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698CF1A9150 for ; Mon, 10 Nov 2014 11:42:37 -0800 (PST) Received: from dhcp-b419.meeting.ietf.org (dhcp-b419.meeting.ietf.org [31.133.180.25]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAAJgXCY035004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2014 13:42:34 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <54611529.7010007@nostrum.com> Date: Mon, 10 Nov 2014 09:42:33 -1000 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ron , rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <20141110040042.GO8092@hex.shelbyville.oz> In-Reply-To: <20141110040042.GO8092@hex.shelbyville.oz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/i-CA8sdBrCsp_Ofp8e1gvt7v2kk Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 19:42:39 -0000 Ron: You are correct in that the IETF doesn't take a position on the validity of IPR declarations, and I'd like to thank you for bringing the topic up so that I could clarify the proposal. Rather than evaluating the *validity* of declarations, we would be evaluating the licensing statements associated with those declarations (where applicable). In terms of what would constitute "compelling evidence", that's going to have to be something that the working group (or some successor group, depending on timing) comes to consensus around. I believe that examples of such situations would include things like "MPEG-LA announces non-discriminatory, royalty-free H.264 licensing for WebRTC" or "ISO publishes VP8 specification with only Type-1 IPR declarations". With regards to bad actors' impact on the process, I fear this is an unfortunate consequence of international IPR law as it is currently defined that we are not in a position to fix. The best we can hope for is that the associated parties recognize the goodwill implications of standing in the way of progress, and the potential implications of developing bad blood between their company and the rest of the standards community. It's not awesome, but it's better than anything else that I've seen proposed so far. /a On 11/9/14 18:00, Ron wrote: > Hi Adam, > > I do need to say that I really appreciate the effort you've put into > trying to help guide this discussion, both previously and now. You > speak an uncommon amount of good common sense. > > It's not clear to me exactly how you expect this part to work though: > > On Sun, Nov 09, 2014 at 04:08:25PM -1000, Adam Roach wrote: >> 2. WebRTC devices MUST implement both VP8 and H.264. If compelling >> evidence arises that one of the codecs is available for use on a >> royalty-free basis, such as all IPR declarations known for the codec >> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change >> this normative statement to indicate that only that codec is >> required. For absolute, crystal clarity, this provision is only >> applicable to WebRTC devices, and not to WebRTC User Agents. > What would constitute "compelling evidence" in this context? > > Since the IETF doesn't take any position on the validity of IPR > declarations, I'm not seeing how the conditional clause here can > be anything but a no-op that would be essentially impossible to > trigger. > > There are plenty of proposed standards which have IPR declarations > made against them, which pretty much everyone who has analysed them > in any detail agree are utterly bogus and inapplicable, but for > which the organisation which declared them refuses to withdraw. > > What am I missing that would encourage different behaviour to that > in this case? > > Cheers, > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 11:55:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A752E1ACD4E for ; Mon, 10 Nov 2014 11:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 KtIOJ6UIZLQ8 for ; Mon, 10 Nov 2014 11:55:22 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6941ACD4A for ; Mon, 10 Nov 2014 11:55:19 -0800 (PST) Received: by mail-yk0-f182.google.com with SMTP id q9so1554551ykb.41 for ; Mon, 10 Nov 2014 11:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nJeu530+YUlKAiRPrZXgTs7S8L8bdYVl6GtfLmZoJLw=; b=pnKuyHHqSCARKB49qLzVQ/0+NwSFH5U6vrd+3oaTHf4xIF51KIZ53ENKoJcoVNwLiU x0HLXs1FETyipFTDGqH8pa1T8zhI03C2xH/f1UH18QybdLkp8JqUSvPILX2n1Sqd9Lmv ZIOOlnM8HZcS+G9PwOipzvmWKsEoyysE7GiX/ck2loKXE/g66o3wJvEYoEeOUKzxU4cL t5/x5Sl8N3b8q11RLG/03G/ZlYtW5lPPYHD6KALbtaGaOxUASjcs59woErMEgUxiS+j5 tM1hlKq5SUUGFh5Xo6/Y8bqm5c9newDI8rFb/0REjKc4ejbd3JYywkwq3qkwfcGpzZsc IeRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nJeu530+YUlKAiRPrZXgTs7S8L8bdYVl6GtfLmZoJLw=; b=FT6TnbiXp7f9LLKh7N7brLhXjTBKsEw8wZla4/UmEqFKuIR2K7eQaA9v1nJoN9VFc8 9gAuLzXyQEbvgNeKxQtIAZLg1xwZOULWIkorVrVwx+93Xhq7xbFup7UCBEZxxyIuMCIG 0Lk6A/KgENfNuAf9R5aTrJupkVI9NanxXOfy76wNDFEWtli2nKaNG/a1MUPRLCdgX2TX xHnRcNlNx0iAnZquKhTU3al0UfRBjiSWcIxdBHSrtRzkQTBc4DqjgoLlhQjpw32Og0dk zEvcepSJLWmAj7MXcEq3FZUj82QiVSzE9IFjxMd1BqGQ8HMQLlNXsEZLOfF/RKdujhCn uECg== X-Gm-Message-State: ALoCoQkxSfA6H61JmYjDoNd6K7w/xHGb113j6S03O1c4y2nqhG9yxjwuZhYTl2VZS0HQp9BvnmWS X-Received: by 10.221.22.136 with SMTP id qw8mr13430vcb.77.1415649317191; Mon, 10 Nov 2014 11:55:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 10 Nov 2014 11:54:55 -0800 (PST) In-Reply-To: <54601E19.8080203@nostrum.com> References: <54601E19.8080203@nostrum.com> From: Justin Uberti Date: Mon, 10 Nov 2014 11:54:55 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11337688ada0120507868a89 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IiH-FY0pwe_Vtvy57OZn-IeV4qs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 19:55:27 -0000 --001a11337688ada0120507868a89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adam, thanks for your work on this. I think this plan represents a legitimate compromise in what had previously seemed like a stalemate. While not our (Google's) ideal outcome, we think this is good for the WebRTC ecosystem - it ensures interoperability, and provides a reasonably clear path for reaching a completely RF solution. In the meantime, WebRTC devices can use APIs such as Android's MediaCodec or iOS' VideoToolkit to provide H.264 support without having to distribute it themselves. (MediaCodec, of course, can also be used for VP8, and soon, VP9). Lastly, on the point of whether any codec can meet the bar of being considered RF, note that the text provides some discretion: *If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, *such as* all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, ...* This allows the IETF to make a decision based on the preponderance of the evidence. On Sun, Nov 9, 2014 at 6:08 PM, Adam Roach wrote: > It appears that we're running headlong into another in-person discussion > about the relative merits of H.264 and VP8 as MTI candidates again. Matth= ew > Kaufman has argued that this conversation is doomed to failure because no > major player has been willing to change their position. The players he > cited were Cisco, Google, and Mozilla, who have represented the three mai= n > positions on this topic pretty effectively. Although we participate as > individuals in the IETF, I think it's fair to say that the last time we h= ad > this conversation, the median positions of participants from those > companies were "H.264 or die", "VP8 or die", and "either one as long as > it's *only* one", respectively. > > However, even if nothing else has changed, I think one salient point may > have become quite important: we're all tired of this. Over two years ago, > in March of 2012 -- before I even had an particular interest in WebRTC > except as a user -- this had already become such a long-running acrimonio= us > debate that I was brought in as a neutral third party to try to mediate. > I'm weary of this argument; and, with the exception of a few aggressive > voices who seem to enjoy the battle more than the outcome, I'm hearing a > similar exhausted timbre in the messages of other participants (and the k= ey > stakeholders in particular). > > So, I want to float a proposal that represents a compromise, to see if we > can finally close this issue. First, I want to start out by reiterating a > well-worn observation that the hallmark of a good compromise is that nobo= dy > leaves happy, but everyone can force themselves to accept it. And I want = to > be crystal clear: the solution I'm about to float just barely clears the > bar of what I think I can live with. This proposal is based on an > observation that the dominating issues in this conversation remain those = of > licensing, not technology or even incumbency. I=E2=80=99ve discussed this > extensively with representatives of all three of the players I mention > above, and they are willing to sign on. > > This proposal is based on the definitions of "WebRTC User Agent", "WebRTC > device", and "WebRTC-compatible endpoint" in section 2.2 of > draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: > > > 1. WebRTC User Agents MUST implement both VP8 and H.264. > > 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the codec b= eing > of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this norm= ative > statement to indicate that only that codec is required. For absolute, > crystal clarity, this provision is only applicable to WebRTC devices, = and > not to WebRTC User Agents. > > 3. WebRTC-compatible endpoints are free to implement any video codecs > they see fit, if any (this follows logically from the definition of > "WebRTC-compatible endpoint," and doesn't really need to be stated, bu= t I > want this proposal to be as explicit as possible). > > > This has the property of ensuring that all devices and user agents can > work with all devices and user agents. This has the property of giving no > one exactly what they want. And, unlike any other previous plans, this ha= s > the property of coming to a decision while maintaining pressure on the on= ly > parties who can make a change in the IPR landscape to do so. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11337688ada0120507868a89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam, thanks for your work on this.

I t= hink this plan represents a legitimate compromise in what had previously se= emed like a stalemate. While not our (Google's) ideal outcome, we think= this is good for the WebRTC ecosystem - it ensures interoperability, and p= rovides a reasonably clear path for reaching a completely RF solution.

In the meantime, WebRTC devices can use APIs such as A= ndroid's MediaCodec or iOS' VideoToolkit to provide H.264 support w= ithout having to distribute it themselves. (MediaCodec, of course, can also= be used for VP8, and soon, VP9).

Lastly, on the po= int of whether any codec can meet the bar of being considered RF, note that= the text provides some discretion:
=C2=A0
If compe= lling evidence arises that one of the codecs is available for use on a roya= lty-free basis, *such as* all IPR declarations known for the codec b= eing of (IETF) Royalty-Free or (ISO) type 1, ...
This allows the IETF to make a decision b= ased on the preponderance of the evidence.

On Sun, Nov 9, 2014 at 6:08 PM= , Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and &q= uot;either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, wit= h the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbr= e in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed th= is extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent&qu= ot;, "WebRTC device", and "WebRTC-compatible endpoint" i= n section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn'= ;t really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a

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


--001a11337688ada0120507868a89-- From nobody Mon Nov 10 12:07:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500091A90CC for ; Mon, 10 Nov 2014 12:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j3AlYB5EByI for ; Mon, 10 Nov 2014 12:06:54 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 774691A6F86 for ; Mon, 10 Nov 2014 12:06:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 885307C04A6 for ; Mon, 10 Nov 2014 21:06:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb18mDG5_tPr for ; Mon, 10 Nov 2014 21:06:30 +0100 (CET) Received: from [31.133.167.224] (dhcp-a7e0.meeting.ietf.org [31.133.167.224]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3100B7C0495 for ; Mon, 10 Nov 2014 21:06:29 +0100 (CET) Message-ID: <54611AC1.7020509@alvestrand.no> Date: Mon, 10 Nov 2014 12:06:25 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010203020406060005040604" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H3Vusn79aF1sB9rVZ7p4nl49X5M Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 20:07:00 -0000 This is a multi-part message in MIME format. --------------010203020406060005040604 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FWIW, I'm firmly with Tim on the proposal: I don't like to declare that a royalty-bearing technology is mandatory to implement in an IETF standard, but given the realities of the situation, I think it is better to adopt this proposal than continuing to leave the MTI decision in flux.= About the language on "reconsideration": Given all the legal issues involved, it would in my opinion be foolhardy to adopt a prescriptive, mechanical trigger for a reclassification - but I would be unhappy about abandoning all hope that the situation could improve - if we are in a situation (years from now?) where it's obvious that we have a royalty free, safely deployable codec available, it would be a strange thing not to say "the way is clear, let's pick the freely available alternative!" I do expect that, if the proposal is adopted, browsers will support both codecs for the foreseeable future (and probably longer than that - "the foreseeable future" tends to be short these days). Adam's "reconsideration" proposal applies only to the class of non-browser things that implement RTCWEB (aka "devices"). Harald On 11/10/2014 11:14 AM, Stephan Wenger wrote: > Hi, > I like and support the spirit of this proposal, but have one issue > with the formulation below, and would like to see it clarified. > Stephan > > > From: Adam Roach > > Date: Sunday, November 9, 2014 at 18:08 > To: "rtcweb@ietf.org " > > Subject: [rtcweb] MTI Video Codec: a novel proposal > > [=85] > If compelling evidence arises that one of the codecs is > available for use on a royalty-free basis, such as all IPR=20 > declarations known for the codec being of (IETF) Royalty-Free=20 > or (ISO) type 1, the IETF will change this normative statement > to indicate that only that codec is required.=20 > [=85] > > First: =93the IETF WILL CHANGE=94: I don=92t think that such forward > looking, absolute statements are appropriate. And probably also not > correct. Some of the objections here are not over royalties, but over > ecosystem dominance; never mind the money. Whether or not the IETF > changes its opinion will at least partly be based based on the power > distribution of players subscribing to ecosystem agendas at the time > the situation changes. > > Second, =93all IPR declarations known for the codec being of (IETF) > Royalty-Free or (ISO) type 1=94 is IMO not compelling evidence for a > royalty free codec; for many reasons that have been spelled out > before. Similarly, type 2 RAND statements are not evidence that > royalties are necessarily being paid. =20 > To me, evidence for a (practically) RF H.264 codec would be an MPEG-LA > pool rightholder decision not to require the payment of royalties. > For VP[8,9], the licensing arrangement google has made got a long way > to convince me, but what would be needed in addition is to overcome > known objections by players, however expressed. (Note that legal > departments will typically be very reluctant to submit type 1 > statements, whereas the business groups may be more easily able to > communicate a company decision for zero royalty.) For newer codecs, > what would be needed is both very wide participation (including all > the key players in both IETF and VCEG/MPEG) and RF declarations in > whatever organization doing the work. Clearly, at this point, none of > H.265, VP10, or Daala fulfill those conditions. > > Thanks, > Stephan > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. --------------010203020406060005040604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
FWIW, I'm firmly with Tim on the proposal: I don't like to declare that a royalty-bearing technology is mandatory to implement in an IETF standard, but given the realities of the situation, I think it is better to adopt this proposal than continuing to leave the MTI decision in flux.

About the language on "reconsideration": Given all the legal issues involved, it would in my opinion be foolhardy to adopt a prescriptive, mechanical trigger for a reclassification - but I would be unhappy about abandoning all hope that the situation could improve - if we are in a situation (years from now?) where it's obvious that we have a royalty free, safely deployable codec available, it would be a strange thing not to say "the way is clear, let's pick the freely available alternative!"

I do expect that, if the proposal is adopted, browsers will support both codecs for the foreseeable future (and probably longer than that - "the foreseeable future" tends to be short these days). Adam's "reconsideration" proposal applies only to the class of non-browser things that implement RTCWEB (aka "devices").

Harald


On 11/10/2014 11:14 AM, Stephan Wenger wrote:
Hi,
I like and support the spirit of this proposal, but have one issue with the formulation below, and would like to see it clarified.
Stephan


From: Adam Roach <adam@nostrum.com>
Date: Sunday, November 9, 2014 at 18:08
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [rtcweb] MTI Video Codec: a novel proposal

[…]
If compelling evidence arises that one of the codecs is
available for use on a royalty-free basis, such as all IPR 
declarations known for the codec being of (IETF) Royalty-Free 
or (ISO) type 1, the IETF will change this normative statement
to indicate that only that codec is required. 
[…]

First: “the IETF WILL CHANGE”: I don’t think that such forward looking, absolute statements are appropriate.  And probably also not correct.  Some of the objections here are not over royalties, but over ecosystem dominance; never mind the money.  Whether or not the IETF changes its opinion will at least partly be based based on the power distribution of players subscribing to ecosystem agendas at the time the situation changes.

Second, “all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1” is IMO not compelling evidence for a royalty free codec; for many reasons that have been spelled out before.  Similarly, type 2 RAND statements are not evidence that royalties are necessarily being paid.  
To me, evidence for a (practically) RF H.264 codec would be an MPEG-LA pool rightholder decision not to require the payment of royalties.  For VP[8,9], the licensing arrangement google has made got a long way to convince me, but what would be needed in addition is to overcome known objections by players, however expressed.  (Note that legal departments will typically be very reluctant to submit type 1 statements, whereas the business groups may be more easily able to communicate a company decision for zero royalty.)  For newer codecs, what would be needed is both very wide participation (including all the key players in both IETF and VCEG/MPEG) and RF declarations in whatever organization doing the work.  Clearly, at this point, none of H.265, VP10, or Daala fulfill those conditions.

Thanks,
Stephan


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



-- 
Surveillance is pervasive. Go Dark.
--------------010203020406060005040604-- From nobody Mon Nov 10 12:13:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8D81ACCF6 for ; Mon, 10 Nov 2014 12:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKjvEZzJ_JyA for ; Mon, 10 Nov 2014 12:13:51 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DE71ACD61 for ; Mon, 10 Nov 2014 12:13:50 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so9728536wgg.23 for ; Mon, 10 Nov 2014 12:13:49 -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:from:date :message-id:subject:to:cc:content-type; bh=DvZd1+6+2mcAuYlmvpP8Ka52ybSxVpb1BRaK5I+d1RE=; b=W21nCA6gjYvzcQsNRtV7yk+G7gZ6Q5X4UkWNuMqvzjHRCP22FRenltUzUj0RMn+oi/ YZ74tTJF7iwX4rCPQ8hoezK5yXlTe7z5U1EyZmUO62HkGk2AfnL4yTsel63KOyX/Qjp6 aWM6pdLlnCFARzElMk0M1vz7JD81fHsSeHDoxH6DrjJmri+Fmd2nU3LT/Wie9XQyUlDY alAtv+KscXoO8I83uDpCVHQ0LnjfCxdSLTCEKE9N99godr69lvZLa/MgNXFiNBwcf1/l H76xNSxPN0vpFhW4mVrnDx4BdyL24SatgFyAcAOXrh+B1eXLtlkK8fpFXHLrsEl27fjk 8Mfg== X-Gm-Message-State: ALoCoQmMqqnI9BC26cy5VwqdA1sBlJa27x3CYqYbt/4TQrwPlDpZ61AQM8Bw7cHTvuUM3X899EUw X-Received: by 10.180.104.232 with SMTP id gh8mr986103wib.78.1415650429283; Mon, 10 Nov 2014 12:13:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Mon, 10 Nov 2014 12:13:08 -0800 (PST) In-Reply-To: References: <54601E19.8080203@nostrum.com> From: Eric Rescorla Date: Mon, 10 Nov 2014 10:13:08 -1000 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d04428dc6f6c2ab050786ccc7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qkqq4wzk2uX4xqEgbW5JweSi6Ls Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 20:13:54 -0000 --f46d04428dc6f6c2ab050786ccc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 As should be obvious from Mozilla's decision to implement both VP8 and H.264 in Firefox, we believe that supporting both codecs is the best path forward for now. In the future, hopefully we can have one MTI best-in-class codec that is also RF -- as Opus is for audio -- but in the meantime this seems like the solution that is best for helping the ecosystem move forward. -Ekr On Mon, Nov 10, 2014 at 9:54 AM, Justin Uberti wrote: > Adam, thanks for your work on this. > > I think this plan represents a legitimate compromise in what had > previously seemed like a stalemate. While not our (Google's) ideal outcom= e, > we think this is good for the WebRTC ecosystem - it ensures > interoperability, and provides a reasonably clear path for reaching a > completely RF solution. > > In the meantime, WebRTC devices can use APIs such as Android's MediaCodec > or iOS' VideoToolkit to provide H.264 support without having to distribut= e > it themselves. (MediaCodec, of course, can also be used for VP8, and soon= , > VP9). > > Lastly, on the point of whether any codec can meet the bar of being > considered RF, note that the text provides some discretion: > > > *If compelling evidence arises that one of the codecs is available for us= e > on a royalty-free basis, *such as* all IPR declarations known for the cod= ec > being of (IETF) Royalty-Free or (ISO) type 1, ...* > > This allows the IETF to make a decision based on the preponderance of the > evidence. > > On Sun, Nov 9, 2014 at 6:08 PM, Adam Roach wrote: > >> It appears that we're running headlong into another in-person discussio= n >> about the relative merits of H.264 and VP8 as MTI candidates again. Matt= hew >> Kaufman has argued that this conversation is doomed to failure because n= o >> major player has been willing to change their position. The players he >> cited were Cisco, Google, and Mozilla, who have represented the three ma= in >> positions on this topic pretty effectively. Although we participate as >> individuals in the IETF, I think it's fair to say that the last time we = had >> this conversation, the median positions of participants from those >> companies were "H.264 or die", "VP8 or die", and "either one as long as >> it's *only* one", respectively. >> >> However, even if nothing else has changed, I think one salient point may >> have become quite important: we're all tired of this. Over two years ago= , >> in March of 2012 -- before I even had an particular interest in WebRTC >> except as a user -- this had already become such a long-running acrimoni= ous >> debate that I was brought in as a neutral third party to try to mediate. >> I'm weary of this argument; and, with the exception of a few aggressive >> voices who seem to enjoy the battle more than the outcome, I'm hearing a >> similar exhausted timbre in the messages of other participants (and the = key >> stakeholders in particular). >> >> So, I want to float a proposal that represents a compromise, to see if w= e >> can finally close this issue. First, I want to start out by reiterating = a >> well-worn observation that the hallmark of a good compromise is that nob= ody >> leaves happy, but everyone can force themselves to accept it. And I want= to >> be crystal clear: the solution I'm about to float just barely clears the >> bar of what I think I can live with. This proposal is based on an >> observation that the dominating issues in this conversation remain those= of >> licensing, not technology or even incumbency. I=E2=80=99ve discussed thi= s >> extensively with representatives of all three of the players I mention >> above, and they are willing to sign on. >> >> This proposal is based on the definitions of "WebRTC User Agent", "WebRT= C >> device", and "WebRTC-compatible endpoint" in section 2.2 of >> draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: >> >> >> 1. WebRTC User Agents MUST implement both VP8 and H.264. >> >> 2. WebRTC devices MUST implement both VP8 and H.264. If compelling >> evidence arises that one of the codecs is available for use on a >> royalty-free basis, such as all IPR declarations known for the codec = being >> of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this nor= mative >> statement to indicate that only that codec is required. For absolute, >> crystal clarity, this provision is only applicable to WebRTC devices,= and >> not to WebRTC User Agents. >> >> 3. WebRTC-compatible endpoints are free to implement any video >> codecs they see fit, if any (this follows logically from the definiti= on of >> "WebRTC-compatible endpoint," and doesn't really need to be stated, b= ut I >> want this proposal to be as explicit as possible). >> >> >> This has the property of ensuring that all devices and user agents can >> work with all devices and user agents. This has the property of giving n= o >> one exactly what they want. And, unlike any other previous plans, this h= as >> the property of coming to a decision while maintaining pressure on the o= nly >> parties who can make a change in the IPR landscape to do so. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d04428dc6f6c2ab050786ccc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

As should be obvious= from Mozilla's decision to implement both VP8
and H.264 in F= irefox, we believe that supporting both codecs is the
best path f= orward for now.

In the future, hopefully we can ha= ve one MTI best-in-class codec that
is also RF -- as Opus is for = audio -- but in the meantime this
seems like the solution that is= best for helping the ecosystem
move forward.

-Ekr




On Mon, Nov 10, 201= 4 at 9:54 AM, Justin Uberti <juberti@google.com> wrote:
=
Adam, thanks for your work = on this.

I think this plan represents a legitimate compr= omise in what had previously seemed like a stalemate. While not our (Google= 's) ideal outcome, we think this is good for the WebRTC ecosystem - it = ensures interoperability, and provides a reasonably clear path for reaching= a completely RF solution.

In the meantime, WebRTC= devices can use APIs such as Android's MediaCodec or iOS' VideoToo= lkit to provide H.264 support without having to distribute it themselves. (= MediaCodec, of course, can also be used for VP8, and soon, VP9).
=
Lastly, on the point of whether any codec can meet the bar of= being considered RF, note that the text provides some discretion:
=C2=A0
If compelling evidence arises that one of the codecs= is available for use on a royalty-free basis, *such as* all IPR dec= larations known for the codec being of (IETF) Royalty-Free or (ISO) type 1,= ...

This allow= s the IETF to make a decision based on the preponderance of the evidence.

On Sun, Nov 9, 2014 at 6:08 PM, Adam Roach <adam@no= strum.com> wrote:
=20 =20 =20
It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and &q= uot;either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, wit= h the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbr= e in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed th= is extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent&qu= ot;, "WebRTC device", and "WebRTC-compatible endpoint" i= n section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn'= ;t really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a

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



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


--f46d04428dc6f6c2ab050786ccc7-- From nobody Mon Nov 10 12:57:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35BB1AC3A2 for ; Mon, 10 Nov 2014 12:57:34 -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 GkfsyHX-zw6b for ; Mon, 10 Nov 2014 12:57:31 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB44C1ACDF2 for ; Mon, 10 Nov 2014 12:57:30 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id p9so3363307lbv.29 for ; Mon, 10 Nov 2014 12:57: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=Rlf/96VqIud+ay4lS9k1Vu8faMjlL8j5+G4EjkwtY88=; b=yP6DK6LpDSo3rq3M0XICNoOzgEsgeN0Vbic5q7e/a0MSqbY4AqJFcmTv7bMaVb38aO Iawd4sPt7TubqSs9nNPqc72ghvSOqHNcrpOSKoZWdcwU6d+omlf86RtHXKbHoyRZKmwv m7PQhDtW5DPBhVBqLRckJPCXRP8q9U2IJOXpylTd2ycb1XZ8svOVziMKKLdHQeyfZOnn 5eRHSjJWa2I8xfTnQW8/EzK0jYOxNpTUHr62XT8Z1WG6et8BqmABJeuDL6Q7fVpebC0a 51Ap03BZ0JSCCZ13A/C+llM9gy88YC3Qb8HQCrqYBDfQc9n7NZCNMFVzTtDY8MnYCjIn ifxQ== MIME-Version: 1.0 X-Received: by 10.152.204.230 with SMTP id lb6mr19519295lac.35.1415653049265; Mon, 10 Nov 2014 12:57:29 -0800 (PST) Received: by 10.25.42.134 with HTTP; Mon, 10 Nov 2014 12:57:29 -0800 (PST) In-Reply-To: <54601E19.8080203@nostrum.com> References: <54601E19.8080203@nostrum.com> Date: Mon, 10 Nov 2014 14:57:29 -0600 Message-ID: From: Mary Barnes To: Adam Roach Content-Type: multipart/alternative; boundary=001a1134d87020750b05078769e3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bFXICGGsZ6EX4r6DJ3HUh7tfkdg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 20:57:35 -0000 --001a1134d87020750b05078769e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with the proposal - I think this is as close as we will ever get on an agreed way forward. Regards, Mary. On Sun, Nov 9, 2014 at 8:08 PM, Adam Roach wrote: > It appears that we're running headlong into another in-person discussion > about the relative merits of H.264 and VP8 as MTI candidates again. Matth= ew > Kaufman has argued that this conversation is doomed to failure because no > major player has been willing to change their position. The players he > cited were Cisco, Google, and Mozilla, who have represented the three mai= n > positions on this topic pretty effectively. Although we participate as > individuals in the IETF, I think it's fair to say that the last time we h= ad > this conversation, the median positions of participants from those > companies were "H.264 or die", "VP8 or die", and "either one as long as > it's *only* one", respectively. > > However, even if nothing else has changed, I think one salient point may > have become quite important: we're all tired of this. Over two years ago, > in March of 2012 -- before I even had an particular interest in WebRTC > except as a user -- this had already become such a long-running acrimonio= us > debate that I was brought in as a neutral third party to try to mediate. > I'm weary of this argument; and, with the exception of a few aggressive > voices who seem to enjoy the battle more than the outcome, I'm hearing a > similar exhausted timbre in the messages of other participants (and the k= ey > stakeholders in particular). > > So, I want to float a proposal that represents a compromise, to see if we > can finally close this issue. First, I want to start out by reiterating a > well-worn observation that the hallmark of a good compromise is that nobo= dy > leaves happy, but everyone can force themselves to accept it. And I want = to > be crystal clear: the solution I'm about to float just barely clears the > bar of what I think I can live with. This proposal is based on an > observation that the dominating issues in this conversation remain those = of > licensing, not technology or even incumbency. I=E2=80=99ve discussed this > extensively with representatives of all three of the players I mention > above, and they are willing to sign on. > > This proposal is based on the definitions of "WebRTC User Agent", "WebRTC > device", and "WebRTC-compatible endpoint" in section 2.2 of > draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: > > > 1. WebRTC User Agents MUST implement both VP8 and H.264. > > 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the codec b= eing > of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this norm= ative > statement to indicate that only that codec is required. For absolute, > crystal clarity, this provision is only applicable to WebRTC devices, = and > not to WebRTC User Agents. > > 3. WebRTC-compatible endpoints are free to implement any video codecs > they see fit, if any (this follows logically from the definition of > "WebRTC-compatible endpoint," and doesn't really need to be stated, bu= t I > want this proposal to be as explicit as possible). > > > This has the property of ensuring that all devices and user agents can > work with all devices and user agents. This has the property of giving no > one exactly what they want. And, unlike any other previous plans, this ha= s > the property of coming to a decision while maintaining pressure on the on= ly > parties who can make a change in the IPR landscape to do so. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1134d87020750b05078769e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with the proposal - I think this is as close as we= will ever get on an agreed way forward.

Regards,
<= div>Mary.

On Sun, Nov 9, 2014 at 8:08 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and &q= uot;either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, wit= h the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbr= e in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed th= is extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent&qu= ot;, "WebRTC device", and "WebRTC-compatible endpoint" i= n section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn'= ;t really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a

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


--001a1134d87020750b05078769e3-- From nobody Mon Nov 10 12:57:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AA11AC3A2 for ; Mon, 10 Nov 2014 12:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpp7lAMzUDpC for ; Mon, 10 Nov 2014 12:57:33 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BB11ACDF5 for ; Mon, 10 Nov 2014 12:57:33 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id kq14so8975106pab.24 for ; Mon, 10 Nov 2014 12:57:32 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4wr0wXsD1levcc9VU1tKoWop3mHC+Jy5u9hpepdeqVc=; b=EVQ9ZPpvEdtFAvRT4lax9hTUsTMocy6inTzcZNMNOfcEImwSe7xUVmq7w5ImvpC47A n1uHYtu0CfED6gKaveZmqRRZ6+zFfv1LEvP0psLejRRIBI++QSkpltqU9nhhKNwjwuIp BT5oNaaC/AxB8a+XUB+hkHs2kA1FcK4HGWYExfe7FsQTWKxLo6f6LMRjMK3EXZdA2F1D TiaDLfzU9N4rrZnqTQXU/St19Ec48EKSzaprrf1sHHogPIrRQRmc5DXI8dBiNtXo7hwF eGeAQ8EL+0pPmJvxvLU2Ecz86qM0TLvh2oU9/rmu1maoYX6sEfIC50uxDcwy08ozYUm/ oEiw== X-Gm-Message-State: ALoCoQkruKNHL2+vDZNVK2cPyajeHelnTqturrpOAy4fREbH3AkFmE++Gmz/JMBQazXYF+/5ul94 X-Received: by 10.70.119.2 with SMTP id kq2mr35398941pdb.54.1415653052498; Mon, 10 Nov 2014 12:57:32 -0800 (PST) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com. [209.85.192.177]) by mx.google.com with ESMTPSA id ki6sm14975444pdb.85.2014.11.10.12.57.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 12:57:31 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id v10so8509850pde.22 for ; Mon, 10 Nov 2014 12:57:31 -0800 (PST) X-Received: by 10.70.96.104 with SMTP id dr8mr35329438pdb.58.1415653051481; Mon, 10 Nov 2014 12:57:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.100.227 with HTTP; Mon, 10 Nov 2014 12:57:11 -0800 (PST) In-Reply-To: <54601E19.8080203@nostrum.com> References: <54601E19.8080203@nostrum.com> From: Emil Ivov Date: Mon, 10 Nov 2014 21:57:11 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9eso0aN3HpJWVkeXGZNG1lTWT_A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 20:57:35 -0000 Thanks for coming up with that Adam! It does look like a reasonable compromise! In our project's community we are happy that it would provide a means for people with different browsers to participate in conferences based on video routing/selective forwarding (as opposed to mixing), which we consider to be a big win for WebRTC! So, +1 to that! Emil On Mon, Nov 10, 2014 at 3:08 AM, Adam Roach wrote: > It appears that we're running headlong into another in-person discussion > about the relative merits of H.264 and VP8 as MTI candidates again. Matth= ew > Kaufman has argued that this conversation is doomed to failure because no > major player has been willing to change their position. The players he ci= ted > were Cisco, Google, and Mozilla, who have represented the three main > positions on this topic pretty effectively. Although we participate as > individuals in the IETF, I think it's fair to say that the last time we h= ad > this conversation, the median positions of participants from those compan= ies > were "H.264 or die", "VP8 or die", and "either one as long as it's *only* > one", respectively. > > However, even if nothing else has changed, I think one salient point may > have become quite important: we're all tired of this. Over two years ago,= in > March of 2012 -- before I even had an particular interest in WebRTC excep= t > as a user -- this had already become such a long-running acrimonious deba= te > that I was brought in as a neutral third party to try to mediate. I'm wea= ry > of this argument; and, with the exception of a few aggressive voices who > seem to enjoy the battle more than the outcome, I'm hearing a similar > exhausted timbre in the messages of other participants (and the key > stakeholders in particular). > > So, I want to float a proposal that represents a compromise, to see if we > can finally close this issue. First, I want to start out by reiterating a > well-worn observation that the hallmark of a good compromise is that nobo= dy > leaves happy, but everyone can force themselves to accept it. And I want = to > be crystal clear: the solution I'm about to float just barely clears the = bar > of what I think I can live with. This proposal is based on an observation > that the dominating issues in this conversation remain those of licensing= , > not technology or even incumbency. I=E2=80=99ve discussed this extensivel= y with > representatives of all three of the players I mention above, and they are > willing to sign on. > > This proposal is based on the definitions of "WebRTC User Agent", "WebRTC > device", and "WebRTC-compatible endpoint" in section 2.2 of > draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: > > WebRTC User Agents MUST implement both VP8 and H.264. > > WebRTC devices MUST implement both VP8 and H.264. If compelling evidence > arises that one of the codecs is available for use on a royalty-free basi= s, > such as all IPR declarations known for the codec being of (IETF) > Royalty-Free or (ISO) type 1, the IETF will change this normative stateme= nt > to indicate that only that codec is required. For absolute, crystal clari= ty, > this provision is only applicable to WebRTC devices, and not to WebRTC Us= er > Agents. > > WebRTC-compatible endpoints are free to implement any video codecs they s= ee > fit, if any (this follows logically from the definition of > "WebRTC-compatible endpoint," and doesn't really need to be stated, but I > want this proposal to be as explicit as possible). > > > This has the property of ensuring that all devices and user agents can wo= rk > with all devices and user agents. This has the property of giving no one > exactly what they want. And, unlike any other previous plans, this has th= e > property of coming to a decision while maintaining pressure on the only > parties who can make a change in the IPR landscape to do so. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 https://jitsi.org From nobody Mon Nov 10 13:15:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715EB1A1A63 for ; Mon, 10 Nov 2014 13:15:14 -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 0pOl7SGFVd9E for ; Mon, 10 Nov 2014 13:15:07 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5351ACEE6 for ; Mon, 10 Nov 2014 13:14:49 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so12277636wiv.7 for ; Mon, 10 Nov 2014 13:14:48 -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=t8R1dE0V6g0nR2gRZ2blWruJx3pDgWB4LRmGIayZF2I=; b=PXB2FMVFmSG2/fNrefckVEMifxMyHY0zLA1TQlR+uD/++EiXVgB7HfYBHcsz+LFrg7 Kp1KFzHXTIHeR7a09NFMkOJfB3QmqlsqXPsRfkH5TDUVEYVievkRoPSeQ3NLFz7RRb5G FSDvSG92HCs7HOQQikcAvpG0sJKf7D71nbvgvuftzZ95MZRZAgLqSOHKslammfUX91bB KR+CiM9hXFxZaTZSkaDkmLiW1rFAVZHBlgoPl82u3RVJaCfoTLaTAV6wJw+PGR4BhENs BKm9z09wZRw22g3OlycacjMgFmVJfOMK9UywsVAG/K/oRZ3glkADkCLYgsYWnvB3IWNN hDKA== X-Gm-Message-State: ALoCoQnZqzfZjMPC3jT/dFCSIveCfKx28hC6/frmfXoa0DuP9dhS4CoNwiwpdlApsjedv8gu3z6O X-Received: by 10.180.186.175 with SMTP id fl15mr34947650wic.38.1415654088706; Mon, 10 Nov 2014 13:14:48 -0800 (PST) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com. [74.125.82.41]) by mx.google.com with ESMTPSA id vm8sm9689278wjc.6.2014.11.10.13.14.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 13:14:47 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id k14so9995529wgh.28 for ; Mon, 10 Nov 2014 13:14:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.58.8 with SMTP id m8mr47837851wjq.43.1415654087581; Mon, 10 Nov 2014 13:14:47 -0800 (PST) Received: by 10.216.176.65 with HTTP; Mon, 10 Nov 2014 13:14:47 -0800 (PST) In-Reply-To: <54601E19.8080203@nostrum.com> References: <54601E19.8080203@nostrum.com> Date: Mon, 10 Nov 2014 16:14:47 -0500 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=047d7ba9763203e90c050787a73e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tw7vM7E2uA_Jbub_6fqAzIsoC8w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 21:15:14 -0000 --047d7ba9763203e90c050787a73e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Even though I am not 100% happy with this proposal and that it probably needs a bit of language clean up, I do support this proposal. _____________ Roman Shpount On Sun, Nov 9, 2014 at 9:08 PM, Adam Roach wrote: > It appears that we're running headlong into another in-person discussion > about the relative merits of H.264 and VP8 as MTI candidates again. Matth= ew > Kaufman has argued that this conversation is doomed to failure because no > major player has been willing to change their position. The players he > cited were Cisco, Google, and Mozilla, who have represented the three mai= n > positions on this topic pretty effectively. Although we participate as > individuals in the IETF, I think it's fair to say that the last time we h= ad > this conversation, the median positions of participants from those > companies were "H.264 or die", "VP8 or die", and "either one as long as > it's *only* one", respectively. > > However, even if nothing else has changed, I think one salient point may > have become quite important: we're all tired of this. Over two years ago, > in March of 2012 -- before I even had an particular interest in WebRTC > except as a user -- this had already become such a long-running acrimonio= us > debate that I was brought in as a neutral third party to try to mediate. > I'm weary of this argument; and, with the exception of a few aggressive > voices who seem to enjoy the battle more than the outcome, I'm hearing a > similar exhausted timbre in the messages of other participants (and the k= ey > stakeholders in particular). > > So, I want to float a proposal that represents a compromise, to see if we > can finally close this issue. First, I want to start out by reiterating a > well-worn observation that the hallmark of a good compromise is that nobo= dy > leaves happy, but everyone can force themselves to accept it. And I want = to > be crystal clear: the solution I'm about to float just barely clears the > bar of what I think I can live with. This proposal is based on an > observation that the dominating issues in this conversation remain those = of > licensing, not technology or even incumbency. I=E2=80=99ve discussed this > extensively with representatives of all three of the players I mention > above, and they are willing to sign on. > > This proposal is based on the definitions of "WebRTC User Agent", "WebRTC > device", and "WebRTC-compatible endpoint" in section 2.2 of > draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: > > > 1. WebRTC User Agents MUST implement both VP8 and H.264. > > 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the codec b= eing > of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this norm= ative > statement to indicate that only that codec is required. For absolute, > crystal clarity, this provision is only applicable to WebRTC devices, = and > not to WebRTC User Agents. > > 3. WebRTC-compatible endpoints are free to implement any video codecs > they see fit, if any (this follows logically from the definition of > "WebRTC-compatible endpoint," and doesn't really need to be stated, bu= t I > want this proposal to be as explicit as possible). > > > This has the property of ensuring that all devices and user agents can > work with all devices and user agents. This has the property of giving no > one exactly what they want. And, unlike any other previous plans, this ha= s > the property of coming to a decision while maintaining pressure on the on= ly > parties who can make a change in the IPR landscape to do so. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7ba9763203e90c050787a73e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even though I am not 100% happy with this proposal and tha= t it probably needs a bit of language clean up, I do support this proposal.=

_____________
Roman Shpount

On Sun, Nov 9, 2014 at 9:08 PM, Adam Roach <= span dir=3D"ltr"><= adam@nostrum.com> wrote:
=20 =20 =20
It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and &q= uot;either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, wit= h the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbr= e in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed th= is extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent&qu= ot;, "WebRTC device", and "WebRTC-compatible endpoint" i= n section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn'= ;t really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a

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


--047d7ba9763203e90c050787a73e-- From nobody Mon Nov 10 13:55:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7A11A6FF1 for ; Mon, 10 Nov 2014 13:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 7GmOht3sfM5x for ; Mon, 10 Nov 2014 13:55:20 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7077F1A7007 for ; Mon, 10 Nov 2014 13:55:20 -0800 (PST) Received: from [10.190.46.26] (unknown [166.170.38.35]) (Authenticated sender: matthew@matthew.at) by mail.eeph.com (Postfix) with ESMTPSA id 38E6F463EC4; Mon, 10 Nov 2014 13:55:15 -0800 (PST) References: <54601E19.8080203@nostrum.com> Mime-Version: 1.0 (1.0) In-Reply-To: <54601E19.8080203@nostrum.com> Content-Type: multipart/alternative; boundary=Apple-Mail-681A313D-24D2-41F5-865B-16B920F709AF Content-Transfer-Encoding: 7bit Message-Id: <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> X-Mailer: iPhone Mail (12A405) From: Matthew Kaufman Date: Mon, 10 Nov 2014 13:55:13 -0800 To: Adam Roach Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QeB_GKOFXBARafHzE5cmz8jHqSU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 21:55:22 -0000 --Apple-Mail-681A313D-24D2-41F5-865B-16B920F709AF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I cited those three players just as examples of known positions. There are s= everal others, of course. This proposal puts the large initial burden of IPR risk and/or cost on the b= rowser vendors...=20 I think we would need to know how happy Apple, Google, Microsoft, and Mozill= a (plus the other major browser vendors ) are with a requirement that both H= .264 and VP8 be included with their browser and/or operating system. We may be tired of this, but it isn't like we have a royalty-free option for= H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed fo= r the browser makers? Matthew Kaufman (Sent from my iPhone) > On Nov 9, 2014, at 6:08 PM, Adam Roach wrote: >=20 > It appears that we're running headlong into another in-person discussion a= bout the relative merits of H.264 and VP8 as MTI candidates again. Matthew K= aufman has argued that this conversation is doomed to failure because no maj= or player has been willing to change their position. The players he cited we= re Cisco, Google, and Mozilla, who have represented the three main positions= on this topic pretty effectively. Although we participate as individuals in= the IETF, I think it's fair to say that the last time we had this conversat= ion, the median positions of participants from those companies were "H.264 o= r die", "VP8 or die", and "either one as long as it's *only* one", respectiv= ely. >=20 > However, even if nothing else has changed, I think one salient point may h= ave become quite important: we're all tired of this. Over two years ago, in M= arch of 2012 -- before I even had an particular interest in WebRTC except as= a user -- this had already become such a long-running acrimonious debate th= at I was brought in as a neutral third party to try to mediate. I'm weary of= this argument; and, with the exception of a few aggressive voices who seem t= o enjoy the battle more than the outcome, I'm hearing a similar exhausted ti= mbre in the messages of other participants (and the key stakeholders in part= icular). >=20 > So, I want to float a proposal that represents a compromise, to see if we c= an finally close this issue. First, I want to start out by reiterating a wel= l-worn observation that the hallmark of a good compromise is that nobody lea= ves happy, but everyone can force themselves to accept it. And I want to be c= rystal clear: the solution I'm about to float just barely clears the bar of w= hat I think I can live with. This proposal is based on an observation that t= he dominating issues in this conversation remain those of licensing, not tec= hnology or even incumbency. I=E2=80=99ve discussed this extensively with rep= resentatives of all three of the players I mention above, and they are willi= ng to sign on. >=20 > This proposal is based on the definitions of "WebRTC User Agent", "WebRTC d= evice", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcweb= -overview-12.txt. My proposal would be as follows: >=20 > WebRTC User Agents MUST implement both VP8 and H.264. >=20 > WebRTC devices MUST implement both VP8 and H.264. If compelling evidence a= rises that one of the codecs is available for use on a royalty-free basis, s= uch as all IPR declarations known for the codec being of (IETF) Royalty-Free= or (ISO) type 1, the IETF will change this normative statement to indicate t= hat only that codec is required. For absolute, crystal clarity, this provisi= on is only applicable to WebRTC devices, and not to WebRTC User Agents.=20 >=20 > WebRTC-compatible endpoints are free to implement any video codecs they se= e fit, if any (this follows logically from the definition of "WebRTC-compati= ble endpoint," and doesn't really need to be stated, but I want this proposa= l to be as explicit as possible). >=20 > This has the property of ensuring that all devices and user agents can wor= k with all devices and user agents. This has the property of giving no one e= xactly what they want. And, unlike any other previous plans, this has th= e property of coming to a decision while maintaining pressure on the only pa= rties who can make a change in the IPR landscape to do so. >=20 > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-681A313D-24D2-41F5-865B-16B920F709AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I cited those three players just as ex= amples of known positions. There are several others, of course.
This proposal puts the large initial burden of IPR risk and/or c= ost on the browser vendors... 

I think we woul= d need to know how happy Apple, Google, Microsoft, and Mozilla (plus the oth= er major browser vendors ) are with a requirement that both H.264 and VP8 be= included with their browser and/or operating system.

We may be tired= of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA o= r IP risk indemnification from Google.. So what's changed for the browser ma= kers?

Matthew Kaufman

(Sent from my iPhone)

On Nov 9, 2014, at 6:08 PM, Adam Roach <adam@nostrum.com> wrote:

=20 =20 =20 It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and "either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, with the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbre in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed thi= s extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent", "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a
=20
____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-681A313D-24D2-41F5-865B-16B920F709AF-- From nobody Mon Nov 10 14:21:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794691A1B80 for ; Mon, 10 Nov 2014 14:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0ZRE3vpJW_2 for ; Mon, 10 Nov 2014 14:21:21 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A32A1A1B74 for ; Mon, 10 Nov 2014 14:21:21 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id x3so6494497qcv.7 for ; Mon, 10 Nov 2014 14:21:20 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Uf29pScjlH7kVEGmpq69h8KPLx4LDGYxohW3Pg9QAkk=; b=ZxsLS/+7v3RDhzKXPgTGAlhM7WcTvTipp6yFYvDXE2zJ6eK0SivyD0BFXPfutsmx8c jdgHTKv66hVw0Ic7xoD6oGvxmNPIp7GDgwRScYnXstO+F52e2Yf6Knu9SlFfHB+h9Irl 5ZGTp3+x+5OWCZwZse3wS6kE1l13u4LZhmWu5ZC4StHARVYT7ixa2zv+07z5RpaDOKu1 7h630zhdBOVzcQiyUpRSQdiRVLgnedKfL1nBDJ+81fwq1BzuoY4QufcIum4WhAniHS3d U+goY3si/iyetIcmWOvHgXOkZBcxwXhAjIuBhaj02ytjbCg/hACqyTpM6rxlCf2BLfOg z8Ng== X-Gm-Message-State: ALoCoQm7JHXjj97sdzacVYildKNwokdp6kJrSdsX1XDvvdttETozCmtG23noiWv+zV9jvPHVTCN6 X-Received: by 10.140.84.71 with SMTP id k65mr44858083qgd.76.1415658080174; Mon, 10 Nov 2014 14:21:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.49.100 with HTTP; Mon, 10 Nov 2014 14:20:59 -0800 (PST) In-Reply-To: <54601E19.8080203@nostrum.com> References: <54601E19.8080203@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 10 Nov 2014 23:20:59 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n7kHDOT0ppt7HtLzYb3Bfaalv4U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 22:21:22 -0000 2014-11-10 3:08 GMT+01:00 Adam Roach : > 1. WebRTC User Agents MUST implement both VP8 and H.264. If "WebRTC User Agent" means web browser (and I think so), I am in favour of non mandating web browsers to implement non-free&open codecs. This is, a MTI codec must be open, free, and free of royalty/licensing stuf= f. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 10 14:41:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E85E1ACF58 for ; Mon, 10 Nov 2014 14:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 6jMPDH5bktu9 for ; Mon, 10 Nov 2014 14:41:08 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD4C1ACF54 for ; Mon, 10 Nov 2014 14:41:08 -0800 (PST) Received: from [10.190.46.26] (unknown [166.170.38.35]) (Authenticated sender: matthew@matthew.at) by mail.eeph.com (Postfix) with ESMTPSA id 075CE4644FA; Mon, 10 Nov 2014 14:41:08 -0800 (PST) References: <54601E19.8080203@nostrum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12A405) From: Matthew Kaufman Date: Mon, 10 Nov 2014 14:41:06 -0800 To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Di4lyfOxYwxk2lU0QgalxKG8TUI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 22:41:09 -0000 Do you believe that making a codec mandatory in an IETF spec will force the c= orporate lawyers at the browser vendors to drop their objections to that cod= ec? Matthew Kaufman (Sent from my iPhone) > On Nov 10, 2014, at 2:20 PM, I=C3=B1aki Baz Castillo wrote= : >=20 > 2014-11-10 3:08 GMT+01:00 Adam Roach : >> 1. WebRTC User Agents MUST implement both VP8 and H.264. >=20 > If "WebRTC User Agent" means web browser (and I think so), I am in > favour of non mandating web browsers to implement non-free&open > codecs. >=20 > This is, a MTI codec must be open, free, and free of royalty/licensing stu= ff. >=20 >=20 >=20 >=20 > --=20 > I=C3=B1aki Baz Castillo > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 14:54:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB91ACF7C for ; Mon, 10 Nov 2014 14:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgbQcBPX8QiZ for ; Mon, 10 Nov 2014 14:54:14 -0800 (PST) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329301A6F71 for ; Mon, 10 Nov 2014 14:54:14 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id i50so6187284qgf.33 for ; Mon, 10 Nov 2014 14:54:13 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=sJ8l3Yb7JXEk5x4SsunTgctFOhFtpnZwr0JpnBD4ndg=; b=Z8/iuylPRdIdBMpygjwn733F+rHSBV6vQhSG4ZhTNMtiQCLUIdvs9WogkVaecdH6Tj Ur+W/cSjexQYTZqJOBJd086ae2lgHPyiNgmO2XcrnPvZwZ2sEBxh5iFSnYLXRAb/unXT qFbwkIxh55hKPW5sW80NrqtlC9lNqdxUyYW+q/V0+7ZjjaY6gKBuISZs28gPa8sYN+Kr 2yppoMbc6eWYJkxMV8rcCEUDPw1YX5xStKz6icYMxz+3ffdtwiR5YrYOL0RC219Kjuty mSkCc/ECl1/GGYHr8jLFp+pfLJw5ZGh95v0WS2Iqq98LQMedJMsgPAZYgxNKjRrKsBbV huYA== X-Gm-Message-State: ALoCoQk70Ijg8wduH7vOjwY6kZcgVdzhJxcPY8sKvoHp5CTu48yTdgGNOa3lGujC5/5z2NA0iRWn X-Received: by 10.140.19.9 with SMTP id 9mr45420732qgg.98.1415660052880; Mon, 10 Nov 2014 14:54:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.49.100 with HTTP; Mon, 10 Nov 2014 14:53:52 -0800 (PST) In-Reply-To: References: <54601E19.8080203@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 10 Nov 2014 23:53:52 +0100 Message-ID: To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cprGo1swlXA_im-Wc97jGYVse1E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 22:54:15 -0000 2014-11-10 23:41 GMT+01:00 Matthew Kaufman : > Do you believe that making a codec mandatory in an IETF spec will force t= he corporate lawyers at the browser vendors to drop their objections to tha= t codec? And do you believe that avoiding MTI privative codecs an IETF spec will force the corporate lawyers at browser vendors to drop their interest in using privative codecs? I'm not proposing that browsers MUST NOT implement non-open-and-free codecs, but just that those codecs MUST NOT be MTI given their nature. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 10 14:58:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B341ACF89 for ; Mon, 10 Nov 2014 14:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR9ZGIahdtdc for ; Mon, 10 Nov 2014 14:58:54 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACBE31ACF76 for ; Mon, 10 Nov 2014 14:58:53 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x13so10098178wgg.22 for ; Mon, 10 Nov 2014 14:58:52 -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:from:date :message-id:subject:to:cc:content-type; bh=D8vec+H0S1Y34uYY+dcdEjUVLwAzkh+SHbK8yxhO1Oo=; b=JlvhHLz2u2PPKCrs3WRPrw3ZkTa605Y/IFXJdPP3PHqyMh+jjLz693jfTYLhfM5lqq pQ2AvQU5WbSMeZcEROi5Tm6+cvZDoillx22Vghf+jUtwmWevURfekgFd54cOHUa2w3/g 2LH5yizHEXBsj7RHtij3nAnQgKpVxH0Kfsx5QRWGMI7euPEKtc4jWqsEVZCTAW325zKO Jz4kJo76tu6rCA22wFX/usQRg3Hy0Bk69vRI5g2GymjTDKCbq88058FBTWNC4ejHRVk8 aogF4d9ZuHXJ+AIVAJYHzKgCGY8pknUkRdRv1s/pLmaXoPbnocI2Ghb2SCj9x+ywX0d4 jY3Q== X-Gm-Message-State: ALoCoQm5PKQ9EMkyCURk0nfY2bXSO5f2mz7u6TeLDPfYeILF0LLh0+fatql9bUTC05OVg582TzqW X-Received: by 10.194.93.168 with SMTP id cv8mr23937556wjb.114.1415660332440; Mon, 10 Nov 2014 14:58:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.49.198 with HTTP; Mon, 10 Nov 2014 14:58:12 -0800 (PST) In-Reply-To: <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> From: Eric Rescorla Date: Mon, 10 Nov 2014 12:58:12 -1000 Message-ID: To: Matthew Kaufman Content-Type: multipart/alternative; boundary=047d7bb0399e3cf8910507891b3a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0GKrGlPXlN-ejZH6F3GKtT3Z55Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 22:58:55 -0000 --047d7bb0399e3cf8910507891b3a Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman wrote: > I cited those three players just as examples of known positions. There are > several others, of course. > > This proposal puts the large initial burden of IPR risk and/or cost on the > browser vendors... > > I think we would need to know how happy Apple, Google, Microsoft, and > Mozilla (plus the other major browser vendors ) are with a requirement that > both H.264 and VP8 be included with their browser and/or operating system. > As I said previously, we're fine with this requirement. -Ekr --047d7bb0399e3cf8910507891b3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman <= ;matthew@matthew.at= > wrote:
=
I cited those three players just as examples of known positions. There= are several others, of course.

This proposal puts= the large initial burden of IPR risk and/or cost on the browser vendors...= =C2=A0

I think we would need to know how happy App= le, Google, Microsoft, and Mozilla (plus the other major browser vendors ) = are with a requirement that both H.264 and VP8 be included with their brows= er and/or operating system.

As I said previously, we're fine with this requirement.

=
-Ekr

--047d7bb0399e3cf8910507891b3a-- From nobody Mon Nov 10 15:04:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1C21ACEF0 for ; Mon, 10 Nov 2014 15:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NtCx6q8Cae0 for ; Mon, 10 Nov 2014 15:04:04 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C35C61A8704 for ; Mon, 10 Nov 2014 15:04:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 110387C048D for ; Tue, 11 Nov 2014 00:04:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkL-BYNFlPoM for ; Tue, 11 Nov 2014 00:03:58 +0100 (CET) Received: from [IPv6:2001:67c:370:176:4805:b828:f652:a1bd] (t2001067c037001764805b828f652a1bd.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7493B7C03B3 for ; Tue, 11 Nov 2014 00:03:57 +0100 (CET) Message-ID: <54614458.2070204@alvestrand.no> Date: Mon, 10 Nov 2014 15:03:52 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010901090602050808060005" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TzNFMa2W7r2nA-nYRY-XYx1eN_w Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 23:04:06 -0000 This is a multi-part message in MIME format. --------------010901090602050808060005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/10/2014 02:58 PM, Eric Rescorla wrote: > > > On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman > wrote: > > I cited those three players just as examples of known positions. > There are several others, of course. > > This proposal puts the large initial burden of IPR risk and/or > cost on the browser vendors... > > I think we would need to know how happy Apple, Google, Microsoft, > and Mozilla (plus the other major browser vendors ) are with a > requirement that both H.264 and VP8 be included with their browser > and/or operating system. > > > As I said previously, we're fine with this requirement. Google is also fine with this requirement. --------------010901090602050808060005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/10/2014 02:58 PM, Eric Rescorla wrote:


On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman <matthew@matthew.at> wrote:
I cited those three players just as examples of known positions. There are several others, of course.

This proposal puts the large initial burden of IPR risk and/or cost on the browser vendors... 

I think we would need to know how happy Apple, Google, Microsoft, and Mozilla (plus the other major browser vendors ) are with a requirement that both H.264 and VP8 be included with their browser and/or operating system.

As I said previously, we're fine with this requirement.

Google is also fine with this requirement.

--------------010901090602050808060005-- From nobody Mon Nov 10 15:04:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95FF1ACEF0 for ; Mon, 10 Nov 2014 15:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 IfkVx1QxFh_r for ; Mon, 10 Nov 2014 15:04:05 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E7B1A893A for ; Mon, 10 Nov 2014 15:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1415660644; x=2279574244; h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iQvKn0ExWBAAM/hDT4kup9yMd8iJ40dAux9C/ynLI7w=; b=yy+zGrZCTybJOu8KkFe2eD7EztpsLOLr4vgBB/tdmlefiN4NFQteeDizjlhYsO0N iaasoBfuA4up8sQ+UtyY9oW+zH/ELQ7fHTfBqptHeLbUMRgcHBL7+iGFhFEF/aYr aLijpAFVfdEcxFbkYjxyfr2igMutOcm7M06ma5VQpPwigYROB8fcuQTSJUHihU6P ABTqA8TAdgNHjS/Uo/YWWnKT1bfTvEo76EEvXyO9vdk6o5elf9VG7P6A5PDTKRZt q7+W8h7Tbz1DvSBDLgnwRlB9BvR/zMF+hM4o+4bQ18yCri38krP0XMn3zme1dwQP 8WL36OfMA3xILCtjqKHEhQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id F2.63.02334.46441645; Mon, 10 Nov 2014 15:04:04 -0800 (PST) X-AuditID: 11973e13-f79ee6d00000091e-de-546144649308 Received: from singda.apple.com (singda.apple.com [17.201.24.241]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 9F.09.30150.F5441645; Mon, 10 Nov 2014 15:03:59 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Singer In-Reply-To: <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> Date: Mon, 10 Nov 2014 15:04:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FDorJvikhhisP+qoMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmDr5L2vBN+2K0z/DGxj3K3cxcnJICJhIvF15lx3CFpO4cG89 WxcjF4eQwF5GiY873rHDFPU+72SCSExgknh0sosNJMEsoCex4/ovVhCbV8BAYsmuTcwgtrCA ucSdD//BmtkEVCUezDnG2MXIwcEpYCfxYY88SJgFKHxp72ImiDHaEssWvmaGGGMj8fHkP7Dx QgIxEg+/3GABsUUE1CUuP7wAdY+8xIcPx9lB7pEQuMkqMfPjQqYJjIKzkJw0C8lJs5DsWMDI vIpRKDcxM0c3M89UL7GgICdVLzk/dxMjKCin2wnvYDy9yuoQowAHoxIPr8Pb+BAh1sSy4src Q4zSHCxK4ryTtBNDhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOKNfl1xP+EuAwaQnH0m87 gle5bNpqZJi9562EbrGYl9jNpKXPq/elVZ3wm+hV5jKHS0PMbGJN+YrsaVcidk/9ff9+bJK9 XnyI7TnhI6y8Nk/8/89fNCXp5py/Dv/5Lkk9yX3bKfBi7gy3TzwrFm+55hnZ9f98bHZXVmdD 8o1CC/fZC7tn3b2qxFKckWioxVxUnAgA5CzfcysCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42IRPCnxUTfeJTHEYOlTRYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMXXyX9aCb9oVp3+GNzDuV+5i5OSQEDCR6H3eyQRhi0lcuLee rYuRi0NIYAKTxKOTXWwgCWYBPYkd13+xgti8AgYSS3ZtYgaxhQXMJe58+M8OYrMJqEo8mHOM sYuRg4NTwE7iwx55kDALUPjS3sVMEGO0JZYtfM0MMcZG4uPJf2DjhQRiJB5+ucECYosIqEtc fniBHeIeeYkPH46zT2Dkm4XkillIrpiFZOwCRuZVjAJFqTmJlUZ6iQUFOal6yfm5mxhBQdRQ 6LyD8dgyq0OMAhyMSjy8Dm/jQ4RYE8uKK3MPMUpwMCuJ8PpoJIYI8aYkVlalFuXHF5XmpBYf YpTmYFES5w2Ljg0REkhPLEnNTk0tSC2CyTJxcEo1MJ7eE8rW92lWN8M8rnDv1k8bP+pw+M/1 usu5UHe9nqjZ7ys/r4XmCvpuVUyWEzI4VL7g3LnCBZtaZeazWFqk9l4VcvgnFDuD85/U/GMi R+/tFP+/9rmlh9FH6Z9p9xzu8rrKcM1gCrxy01z62z/x46Lbe+yOTYx3r+jbwKEdqXK4YOKd 5JC0diWW4oxEQy3mouJEAMlKvXEeAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_nQ7FnQ1Jxm_ym8FvVyz0cGD5GQ Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 23:04:07 -0000 On Nov 10, 2014, at 13:55 , Matthew Kaufman wrote: > I cited those three players just as examples of known positions. There = are several others, of course. >=20 > This proposal puts the large initial burden of IPR risk and/or cost on = the browser vendors...=20 >=20 > I think we would need to know how happy Apple, Google, Microsoft, and = Mozilla (plus the other major browser vendors ) are with a requirement = that both H.264 and VP8 be included with their browser and/or operating = system. >=20 > We may be tired of this, but it isn't like we have a royalty-free = option for H.264 MPEG-LA or IP risk indemnification from Google.. So = what's changed for the browser makers? That is my question too; what has changed since this was (effectively) = one of the options in the notorious long-ago poll? On the face of it, this requires proponents of =91must be free=92 to = take on a non-free license (in principle, though rarely in practice), = which is unacceptable to them, and for the =91must be reasonably clear = of IPR risk and independently implementable=92 people to have to take on = IPR risk and try (?) to implement from the specs, which seems = unacceptable to them. So, am puzzled. Yes, this proposal would make everyone unhappy (if they = actually do it), or non-compliant (if, as I suspect, people implement = only what they were going to implement anyway, no matter what the spec. = says). (A mandate is only effective if followed.) Can anyone explain what=92s changed, or what I am missing? >=20 > Matthew Kaufman >=20 > (Sent from my iPhone) >=20 > On Nov 9, 2014, at 6:08 PM, Adam Roach wrote: >=20 >> It appears that we're running headlong into another in-person = discussion about the relative merits of H.264 and VP8 as MTI candidates = again. Matthew Kaufman has argued that this conversation is doomed to = failure because no major player has been willing to change their = position. The players he cited were Cisco, Google, and Mozilla, who have = represented the three main positions on this topic pretty effectively. = Although we participate as individuals in the IETF, I think it's fair to = say that the last time we had this conversation, the median positions of = participants from those companies were "H.264 or die", "VP8 or die", and = "either one as long as it's *only* one", respectively. >>=20 >> However, even if nothing else has changed, I think one salient point = may have become quite important: we're all tired of this. Over two years = ago, in March of 2012 -- before I even had an particular interest in = WebRTC except as a user -- this had already become such a long-running = acrimonious debate that I was brought in as a neutral third party to try = to mediate. I'm weary of this argument; and, with the exception of a few = aggressive voices who seem to enjoy the battle more than the outcome, = I'm hearing a similar exhausted timbre in the messages of other = participants (and the key stakeholders in particular). >>=20 >> So, I want to float a proposal that represents a compromise, to see = if we can finally close this issue. First, I want to start out by = reiterating a well-worn observation that the hallmark of a good = compromise is that nobody leaves happy, but everyone can force = themselves to accept it. And I want to be crystal clear: the solution = I'm about to float just barely clears the bar of what I think I can live = with. This proposal is based on an observation that the dominating = issues in this conversation remain those of licensing, not technology or = even incumbency. I=92ve discussed this extensively with representatives = of all three of the players I mention above, and they are willing to = sign on. >>=20 >> This proposal is based on the definitions of "WebRTC User Agent", = "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of = draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: >>=20 >> =95 WebRTC User Agents MUST implement both VP8 and H.264. >>=20 >> =95 WebRTC devices MUST implement both VP8 and H.264. If = compelling evidence arises that one of the codecs is available for use = on a royalty-free basis, such as all IPR declarations known for the = codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change = this normative statement to indicate that only that codec is required. = For absolute, crystal clarity, this provision is only applicable to = WebRTC devices, and not to WebRTC User Agents.=20 >>=20 >> =95 WebRTC-compatible endpoints are free to implement any video = codecs they see fit, if any (this follows logically from the definition = of "WebRTC-compatible endpoint," and doesn't really need to be stated, = but I want this proposal to be as explicit as possible). >>=20 >> This has the property of ensuring that all devices and user agents = can work with all devices and user agents. This has the property of = giving no one exactly what they want. And, unlike any other previous = plans, this has the property of coming to a decision while maintaining = pressure on the only parties who can make a change in the IPR landscape = to do so. >>=20 >> /a >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb David Singer Manager, Software Standards, Apple Inc. From nobody Mon Nov 10 15:06:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F282E1ACF9E for ; Mon, 10 Nov 2014 15:06:38 -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 vzdQ1euZcDqj for ; Mon, 10 Nov 2014 15:06:32 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA131A89B0 for ; Mon, 10 Nov 2014 15:06:32 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id ey11so9204356pad.7 for ; Mon, 10 Nov 2014 15:06:31 -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=2hZUT4weYq5otLCpBa7yTn299F7D9gvzeWqAQp8D+zc=; b=0w7S+VBpEJjdnI/XvO4ifrEsd5lec53Pcd90d7r/zEe+PguU/zrcrYbgYNQ7OvVy/0 ZmmYQ0UkPNL67LzkQRizprEAR4Ol0bqX2tQpsnyojEAE1PPsO7vf1FTjeq+RlZ18jACB gpjnk9mygGf15ABRiHxtgxMFf6/KDzovwKhqRhS2PC9JtMKtxvlWuDmGR4WHbI6lQQ0+ kF4kFHxejLpqCOYXUHgOJrz6INT2NvDkfc5gO/XDZpdfqrakUjgzx/grQoUSbtNM+VgF JnbummsQkFhUXbnZf30lKHofRRCQi4JtdJwe2KYYapnpdxvr/qfXJezuVQJ1exemIrXy V4Gw== MIME-Version: 1.0 X-Received: by 10.66.146.71 with SMTP id ta7mr36144647pab.16.1415660791329; Mon, 10 Nov 2014 15:06:31 -0800 (PST) Received: by 10.70.60.201 with HTTP; Mon, 10 Nov 2014 15:06:31 -0800 (PST) In-Reply-To: References: <54601E19.8080203@nostrum.com> Date: Mon, 10 Nov 2014 13:06:31 -1000 Message-ID: From: Suhas Nandakumar To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7b6da6ee96fa2805078936d4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1O7AlC0X8lOw2r6SeXVi4HLZm7o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 23:06:39 -0000 --047d7b6da6ee96fa2805078936d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 on this proposal . Hope IETF91 would be a decision making for this pending item Cheers Suhas On Mon, Nov 10, 2014 at 11:14 AM, Roman Shpount wrote: > Even though I am not 100% happy with this proposal and that it probably > needs a bit of language clean up, I do support this proposal. > > _____________ > Roman Shpount > > On Sun, Nov 9, 2014 at 9:08 PM, Adam Roach wrote: > >> It appears that we're running headlong into another in-person discussio= n >> about the relative merits of H.264 and VP8 as MTI candidates again. Matt= hew >> Kaufman has argued that this conversation is doomed to failure because n= o >> major player has been willing to change their position. The players he >> cited were Cisco, Google, and Mozilla, who have represented the three ma= in >> positions on this topic pretty effectively. Although we participate as >> individuals in the IETF, I think it's fair to say that the last time we = had >> this conversation, the median positions of participants from those >> companies were "H.264 or die", "VP8 or die", and "either one as long as >> it's *only* one", respectively. >> >> However, even if nothing else has changed, I think one salient point may >> have become quite important: we're all tired of this. Over two years ago= , >> in March of 2012 -- before I even had an particular interest in WebRTC >> except as a user -- this had already become such a long-running acrimoni= ous >> debate that I was brought in as a neutral third party to try to mediate. >> I'm weary of this argument; and, with the exception of a few aggressive >> voices who seem to enjoy the battle more than the outcome, I'm hearing a >> similar exhausted timbre in the messages of other participants (and the = key >> stakeholders in particular). >> >> So, I want to float a proposal that represents a compromise, to see if w= e >> can finally close this issue. First, I want to start out by reiterating = a >> well-worn observation that the hallmark of a good compromise is that nob= ody >> leaves happy, but everyone can force themselves to accept it. And I want= to >> be crystal clear: the solution I'm about to float just barely clears the >> bar of what I think I can live with. This proposal is based on an >> observation that the dominating issues in this conversation remain those= of >> licensing, not technology or even incumbency. I=E2=80=99ve discussed thi= s >> extensively with representatives of all three of the players I mention >> above, and they are willing to sign on. >> >> This proposal is based on the definitions of "WebRTC User Agent", "WebRT= C >> device", and "WebRTC-compatible endpoint" in section 2.2 of >> draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: >> >> >> 1. WebRTC User Agents MUST implement both VP8 and H.264. >> >> 2. WebRTC devices MUST implement both VP8 and H.264. If compelling >> evidence arises that one of the codecs is available for use on a >> royalty-free basis, such as all IPR declarations known for the codec = being >> of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this nor= mative >> statement to indicate that only that codec is required. For absolute, >> crystal clarity, this provision is only applicable to WebRTC devices,= and >> not to WebRTC User Agents. >> >> 3. WebRTC-compatible endpoints are free to implement any video >> codecs they see fit, if any (this follows logically from the definiti= on of >> "WebRTC-compatible endpoint," and doesn't really need to be stated, b= ut I >> want this proposal to be as explicit as possible). >> >> >> This has the property of ensuring that all devices and user agents can >> work with all devices and user agents. This has the property of giving n= o >> one exactly what they want. And, unlike any other previous plans, this h= as >> the property of coming to a decision while maintaining pressure on the o= nly >> parties who can make a change in the IPR landscape to do so. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b6da6ee96fa2805078936d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on this proposal . Hope IETF91 =C2=A0would be a decisio= n making for this pending item


Cheers
Suhas

On Mon, Nov 10, 2014 at 11:14 AM, Roman Shpount &l= t;roman@telurix.com<= /a>> wrote:
Ev= en though I am not 100% happy with this proposal and that it probably needs= a bit of language clean up, I do support this proposal.

_____________
Roman Shpount

On Sun, Nov 9, 2014 at 9:08= PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and &q= uot;either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, wit= h the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbr= e in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed th= is extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent&qu= ot;, "WebRTC device", and "WebRTC-compatible endpoint" i= n section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn'= ;t really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a

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



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


--047d7b6da6ee96fa2805078936d4-- From nobody Mon Nov 10 15:10:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52B61ACF9C for ; Mon, 10 Nov 2014 15:10:48 -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 9AKoTftO-MMZ for ; Mon, 10 Nov 2014 15:10:47 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFA81ACF9B for ; Mon, 10 Nov 2014 15:10:46 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id ft15so8769378pdb.21 for ; Mon, 10 Nov 2014 15:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=/RriDt8JKOh/Ne141qVNyZn4ygCXa3piHhgFDHio1W4=; b=ZtpWleW//B7hvW7wJyNo4GDcVRrTPKDtMbappCCMsTcjBQv06Hvnaw/EPVdrl4t1ZS oEEPIIZ5rv+NIuzPzrbpHfO1fjbbGw91UPbyeFaozIdwX9Dki9VhpZpQibLvRCEOrvsA vYuv2hg+n4NckwYIHIZMc5OgjO6Kkj6JjjWTWq062+/cEZU7uK+PznFirKUiZUYPbgK8 +1KKSjJrKvhcX1ox0ViKlNczHeTvXAa9VUSH14ZFe+7ka9WNU4gZPls1d3Bjt+VznPok gSKeVbdyBQEqLepCA+bfyuDruqyY2OgbaiLVuWVGAwiQVOBqVHYww4CoQDkL5RJkew9J DgWQ== X-Received: by 10.66.124.228 with SMTP id ml4mr35676330pab.42.1415661046221; Mon, 10 Nov 2014 15:10:46 -0800 (PST) Received: from [10.219.121.254] ([166.170.51.122]) by mx.google.com with ESMTPSA id bz3sm17597561pab.41.2014.11.10.15.10.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 15:10:44 -0800 (PST) References: <54601E19.8080203@nostrum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Mon, 10 Nov 2014 13:10:40 -1000 To: Matthew Kaufman Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bxjawTYccpgaywEeiBTILVwgWBs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 23:10:48 -0000 Are there any browser vendors beyond Mozilla indicating they would ship both= codecs simply as a result of the proposal being adopted (no other condition= s)? =20 > On Nov 10, 2014, at 12:41 PM, Matthew Kaufman wrote: >=20 > Do you believe that making a codec mandatory in an IETF spec will force th= e corporate lawyers at the browser vendors to drop their objections to that c= odec? >=20 > Matthew Kaufman >=20 > (Sent from my iPhone) >=20 >> On Nov 10, 2014, at 2:20 PM, I=C3=B1aki Baz Castillo wrot= e: >>=20 >> 2014-11-10 3:08 GMT+01:00 Adam Roach : >>> 1. WebRTC User Agents MUST implement both VP8 and H.264. >>=20 >> If "WebRTC User Agent" means web browser (and I think so), I am in >> favour of non mandating web browsers to implement non-free&open >> codecs. >>=20 >> This is, a MTI codec must be open, free, and free of royalty/licensing st= uff. >>=20 >>=20 >>=20 >>=20 >> --=20 >> I=C3=B1aki Baz Castillo >> >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 15:41:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CAF1AD071 for ; Mon, 10 Nov 2014 15:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHjTAG_lp2TN for ; Mon, 10 Nov 2014 15:41:52 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06A281A90DF for ; Mon, 10 Nov 2014 15:41:52 -0800 (PST) Received: from dhcp-b419.meeting.ietf.org (dhcp-b419.meeting.ietf.org [31.133.180.25]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAANfmDA056386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2014 17:41:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <54614D3C.5060208@nostrum.com> Date: Mon, 10 Nov 2014 13:41:48 -1000 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Tim Lindsey , Matthew Kaufman References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9dfHyEw5BJEkddCNCSKtqlvmGys Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 23:41:53 -0000 On 11/10/14 12:30, Tim Lindsey wrote: > Last I read Apple did not support and had no definitive plan to begin > support for VP8/9. I'm curious about what you read and where: Apple is quite famous for not publishing its plans, definitive or otherwise. /a From timwlindsey@gmail.com Mon Nov 10 14:30:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059101ACEF9 for ; Mon, 10 Nov 2014 14:30:27 -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 5eXAbmElfLZD for ; Mon, 10 Nov 2014 14:30:24 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B749A1ACEF1 for ; Mon, 10 Nov 2014 14:30:23 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id g201so6137189oib.19 for ; Mon, 10 Nov 2014 14:30:23 -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=d8Tru51s04RWtQOMps5FeTzOo813D93wzs5HfMoIhkU=; b=Oa/ZoqQliG6hU9y4h8AZxCt9II8VIQlaO0Me01iIm2bGIsKvucZ7K6MlyRyCYMwlKF S+rdvC6lWmKWFK9GnbpLr1l+I5LscUToNjWm6/Pj2gMjyrzk11SRaear/lzlmcTN4xnN SNDGR+dPSA5v164mga4XXuuVQTyM6z8RwZopH+6Kw7SxxwXwyWJHDuG/IjeHSInw+JW/ KsFHBqXd+ZHfjXNRibN2X79kPyb63vfeCYwSDwrEM+nL9RmltmGA25889J8WF0HrQmjD q+7UHu0gcbGd139dqACovmFNbR+vi9qc9BJ0Z4ALi1TT/Dne/M8g7R+tKcw1AdThY4lw 17bQ== MIME-Version: 1.0 X-Received: by 10.182.89.161 with SMTP id bp1mr29394577obb.19.1415658622901; Mon, 10 Nov 2014 14:30:22 -0800 (PST) Received: by 10.202.227.6 with HTTP; Mon, 10 Nov 2014 14:30:22 -0800 (PST) In-Reply-To: <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> Date: Mon, 10 Nov 2014 16:30:22 -0600 Message-ID: From: Tim Lindsey To: Matthew Kaufman Content-Type: multipart/alternative; boundary=089e013d0e0257639b050788b503 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/K2MJI8tUpSWKTj0M5E3KF_RXWZo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 10 Nov 2014 23:42:17 -0000 --089e013d0e0257639b050788b503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. Last I read Apple did not support and had no definitive plan to begin support for VP8/9. If this stance hasn't wavered I think it presents an immediate and significant road block to ever making this proposal a reality, however reasonable it may seem. On Mon, Nov 10, 2014 at 3:55 PM, Matthew Kaufman wrote= : > I cited those three players just as examples of known positions. There ar= e > several others, of course. > > This proposal puts the large initial burden of IPR risk and/or cost on th= e > browser vendors... > > I think we would need to know how happy Apple, Google, Microsoft, and > Mozilla (plus the other major browser vendors ) are with a requirement th= at > both H.264 and VP8 be included with their browser and/or operating system= . > > We may be tired of this, but it isn't like we have a royalty-free option > for H.264 MPEG-LA or IP risk indemnification from Google.. So what's > changed for the browser makers? > > Matthew Kaufman > > (Sent from my iPhone) > > On Nov 9, 2014, at 6:08 PM, Adam Roach wrote: > > It appears that we're running headlong into another in-person discussion > about the relative merits of H.264 and VP8 as MTI candidates again. Matth= ew > Kaufman has argued that this conversation is doomed to failure because no > major player has been willing to change their position. The players he > cited were Cisco, Google, and Mozilla, who have represented the three mai= n > positions on this topic pretty effectively. Although we participate as > individuals in the IETF, I think it's fair to say that the last time we h= ad > this conversation, the median positions of participants from those > companies were "H.264 or die", "VP8 or die", and "either one as long as > it's *only* one", respectively. > > However, even if nothing else has changed, I think one salient point may > have become quite important: we're all tired of this. Over two years ago, > in March of 2012 -- before I even had an particular interest in WebRTC > except as a user -- this had already become such a long-running acrimonio= us > debate that I was brought in as a neutral third party to try to mediate. > I'm weary of this argument; and, with the exception of a few aggressive > voices who seem to enjoy the battle more than the outcome, I'm hearing a > similar exhausted timbre in the messages of other participants (and the k= ey > stakeholders in particular). > > So, I want to float a proposal that represents a compromise, to see if we > can finally close this issue. First, I want to start out by reiterating a > well-worn observation that the hallmark of a good compromise is that nobo= dy > leaves happy, but everyone can force themselves to accept it. And I want = to > be crystal clear: the solution I'm about to float just barely clears the > bar of what I think I can live with. This proposal is based on an > observation that the dominating issues in this conversation remain those = of > licensing, not technology or even incumbency. I=E2=80=99ve discussed this > extensively with representatives of all three of the players I mention > above, and they are willing to sign on. > > This proposal is based on the definitions of "WebRTC User Agent", "WebRTC > device", and "WebRTC-compatible endpoint" in section 2.2 of > draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: > > > 1. WebRTC User Agents MUST implement both VP8 and H.264. > > 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the codec b= eing > of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this norm= ative > statement to indicate that only that codec is required. For absolute, > crystal clarity, this provision is only applicable to WebRTC devices, = and > not to WebRTC User Agents. > > 3. WebRTC-compatible endpoints are free to implement any video codecs > they see fit, if any (this follows logically from the definition of > "WebRTC-compatible endpoint," and doesn't really need to be stated, bu= t I > want this proposal to be as explicit as possible). > > > This has the property of ensuring that all devices and user agents can > work with all devices and user agents. This has the property of giving no > one exactly what they want. And, unlike any other previous plans, this ha= s > the property of coming to a decision while maintaining pressure on the on= ly > parties who can make a change in the IPR landscape to do so. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e013d0e0257639b050788b503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed. Last I read Apple did not support and had no defin= itive plan to begin support for VP8/9. If this stance hasn't wavered I = think it presents an immediate and significant road block to ever making th= is proposal a reality, however reasonable it may seem.

On Mon, Nov 10, 2014 at 3:55 PM,= Matthew Kaufman <matthew@matthew.at> wrote:
I cited those three players just= as examples of known positions. There are several others, of course.
=

This proposal puts the large initial burden of IPR risk= and/or cost on the browser vendors...=C2=A0

I thi= nk we would need to know how happy Apple, Google, Microsoft, and Mozilla (p= lus the other major browser vendors ) are with a requirement that both H.26= 4 and VP8 be included with their browser and/or operating system.

We= may be tired of this, but it isn't like we have a royalty-free option = for H.264 MPEG-LA or IP risk indemnification from Google.. So what's ch= anged for the browser makers?

Matthew Kaufman

(Sent f= rom my iPhone)

On Nov 9, 2014, a= t 6:08 PM, Adam Roach <adam@nostrum.com> wrote:

=20 =20 =20 =20 It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and &q= uot;either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, wit= h the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbr= e in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I=E2=80=99ve discussed th= is extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent&qu= ot;, "WebRTC device", and "WebRTC-compatible endpoint" i= n section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1. WebRTC User Agents MUST implement both VP8 and H.264.

  2. WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.

  3. WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn'= ;t really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a
=20
___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb=

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


--089e013d0e0257639b050788b503-- From nobody Mon Nov 10 16:25:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444291A8799 for ; Mon, 10 Nov 2014 16:25:41 -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 8aWy6sR341QQ for ; Mon, 10 Nov 2014 16:25:39 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839BE1AC449 for ; Mon, 10 Nov 2014 16:25:39 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so82190wib.17 for ; Mon, 10 Nov 2014 16:25:38 -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=XmeNmBs+7kF/l4HLj+w1QREs5W3tPYjUyq48gw3h670=; b=ZMqHX2cP/B7mK/XqdKNfFN9H8MLP4QyNixbyulAaJH68p8IPKpH5qecG5tx+XV1pRm 9tbl8BiCA8sRzoHfhJLV0dU1L7PWOOMY0CZvSASCZzSOHbSNZ5/zMkvRm8ruabp7wcCm PGAmg4nwmrf5R91AtfYwacPLJPS+ofYgLfwIGjX2AvwFD3XHqADrgCTW8XXjv29Wjmaf fuNXHDwWFOz/7iMukIHOBZagWa6hNJ6DWdNlWGI80eKElGDrYPgWvQ3vGIpxHvjWrrIC 7HiBxs4o3HosN4yKNfbo/Jpdjt4qh9omVbNK5T1IeXaictuJlwYauwJ5wD9owUCoH8+a RDkg== X-Gm-Message-State: ALoCoQkIepis51XxJApk4UcV+G+oTXVX6kDIQFXgFPpAwmOtXpHc5iZoQ5JL/AYkJT5WaEAilabT X-Received: by 10.194.236.232 with SMTP id ux8mr48873219wjc.96.1415665538283; Mon, 10 Nov 2014 16:25:38 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com. [209.85.212.173]) by mx.google.com with ESMTPSA id wr9sm25088985wjb.42.2014.11.10.16.25.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 16:25:36 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so94982wiv.12 for ; Mon, 10 Nov 2014 16:25:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.107.35 with SMTP id gz3mr36204025wib.38.1415665536666; Mon, 10 Nov 2014 16:25:36 -0800 (PST) Received: by 10.216.176.65 with HTTP; Mon, 10 Nov 2014 16:25:36 -0800 (PST) In-Reply-To: <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> Date: Mon, 10 Nov 2014 19:25:36 -0500 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=e89a8f3b9b696f147805078a5122 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UHXmGwsgzpX2puz4c7xSUThrbg4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 00:25:41 -0000 --e89a8f3b9b696f147805078a5122 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman wrote: > We may be tired of this, but it isn't like we have a royalty-free option > for H.264 MPEG-LA or IP risk indemnification from Google.. So what's > changed for the browser makers? > > May be I am missing something, but MPEG-LA does not provide IP risk indemnification for H.264. All they sell is a very limited license to the patent pool from the group members. --e89a8f3b9b696f147805078a5122 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 10, 2014 at 4:55 PM, Matthew Kaufman <matthew@matthew.at>= wrote:
We = may be tired of this, but it isn't like we have a royalty-free option f= or H.264 MPEG-LA or IP risk indemnification from Google.. So what's cha= nged for the browser makers?


May be I am missing something, but MPEG-LA does= not provide IP risk indemnification for H.264. All they sell is a very lim= ited license to the patent pool from the group members.
--e89a8f3b9b696f147805078a5122-- From nobody Mon Nov 10 17:11:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CED1A700C for ; Mon, 10 Nov 2014 17:11:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1wS2MnwGUU1 for ; Mon, 10 Nov 2014 17:11:22 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 069D01A87E0 for ; Mon, 10 Nov 2014 17:11:09 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail07.adl2.internode.on.net with ESMTP; 11 Nov 2014 11:41:08 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 5EE15FFEDC for ; Tue, 11 Nov 2014 11:40:56 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0YTAYeO6KZt7 for ; Tue, 11 Nov 2014 11:40:55 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 20821FFC3E for ; Tue, 11 Nov 2014 11:40:55 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 0CFB680470; Tue, 11 Nov 2014 11:40:55 +1030 (ACDT) Date: Tue, 11 Nov 2014 11:40:55 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141111011054.GR8092@hex.shelbyville.oz> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/A7I_KhY0u2PG29vZ_KrXEYPoV14 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 01:11:28 -0000 On Mon, Nov 10, 2014 at 03:04:04PM -0800, David Singer wrote: > > On Nov 10, 2014, at 13:55 , Matthew Kaufman wrote: > > > I cited those three players just as examples of known positions. There are several others, of course. > > > > This proposal puts the large initial burden of IPR risk and/or cost on the browser vendors... > > > > I think we would need to know how happy Apple, Google, Microsoft, and Mozilla (plus the other major browser vendors ) are with a requirement that both H.264 and VP8 be included with their browser and/or operating system. > > > > We may be tired of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed for the browser makers? > > That is my question too; what has changed since this was > (effectively) one of the options in the notorious long-ago poll? I think Adam explained this in his original rationale. There appears to be a growing consensus that, "The only thing worse than this current stalemate is people wanting us to remain stalled indefinitely in a state of stalemate over this decision". His option guarantees that anyone implementing only their preferred codec will be able to interop with any compliant implementation, though it may not be able to do so with another non-compliant implementation that similarly opted out of supporting that codec. It also gives the people who are ultimately in the position of prolonging this stalemate indefinitely a mechanism whereby they could, at their option, end it in favour of their preferred codec becoming the sole MTI. Whatever the odds of that actually happening may be, we'll all know exactly who to blame if this compromise ends in its worst case outcome for everyone rather than its best one. > On the face of it, this requires proponents of ‘must be free’ to take > on a non-free license (in principle, though rarely in practice), which > is unacceptable to them, and for the ‘must be reasonably clear of IPR > risk and independently implementable’ people to have to take on IPR > risk and try (?) to implement from the specs, which seems unacceptable > to them. It doesn't "require" any such thing. It requires a compliant implementation to be fully compatible with any non-compliant implementation that for one reason or another finds it impossible to achieve full compliance with the MTI video codec(s). If the escape clause is exercised, we all win and everyone can interop. If it isn't there may be some implementations which give a poorer experience to their users than others do. That's still better than the state of total chaos which would exist if no MTI at all was specified. > So, am puzzled. Yes, this proposal would make everyone unhappy (if > they actually do it), or non-compliant (if, as I suspect, people > implement only what they were going to implement anyway, no matter > what the spec. says). (A mandate is only effective if followed.) > > Can anyone explain what’s changed, or what I am missing? All of the major players in the browser market have said they are on board and will follow this mandate. If some of the remainder don't, or won't, or can't, they get to weigh up their reasons for that against the possibility of having their users simply switch to a browser that does. If some of those players are in a position to be able to exert the pressure they feel upon the other people who are blocking us from being able to exercise the tie-breaker clause, then maybe our odds of triggering it are slightly improved too. Nobody can be forced into providing a fully compliant implementation, but even in the worst case under this, given the assurances we already have, the people who have protested that they absolutely can't ship one of these codecs will still be able to interop with all the major players if they can find no other way around that problem. It's certainly not my preferred solution, but it's definitely not the worst one I can imagine, and is both measurably better than the status quo, and seems to provide reasonable incentives for the people who turn the screws to still try to improve the situation further in their favour, should they actually choose to do so. I eagerly await the next surprising announcement of something we all thought was simply unimaginable a year or two ago! Ron From nobody Mon Nov 10 17:20:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C1F1AD359 for ; Mon, 10 Nov 2014 17:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 kI7DPrCRsbch for ; Mon, 10 Nov 2014 17:20:29 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C371A1BCA for ; Mon, 10 Nov 2014 17:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1415668827; x=2279582427; h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wUbPFb6FIH3Rme8dsqxAhGmZWbQtJRwBB9l6V6pTYrw=; b=JFEbWq3g+V1OcFAmUGE/Wod7DCTk/lJtkxfoHKAPnCviLJ/Mtai34dJwdWllvoKs Ei/3AZbYDlwNlq9y+6JGJ8rg67sPR5EUvbVyphFN/VWxGJlbQeF73IbrJRtdgtQR P6mDOfT0ESmFIsE6R2QPEelghiM0zHQFyz+iAaIjO1TFFHXUGvQV+aUgY42jAEfp sUaOC9oZcxSXFiUWdG/wtCCxztpf/fxXXIABBL3qylFdpR4jJHRnmqNa0uKeBi29 ud8MeGTcy7LLpCGUub3FhtJ/8VrxeEgohhzFIjPCIzZPwHRDHLIXR0hz6dEehui6 ypELU2WCdLhrhEa+EX8E9g==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id BF.2B.05330.B5461645; Mon, 10 Nov 2014 17:20:27 -0800 (PST) X-AuditID: 11973e15-f791b6d0000014d2-5f-5461645bee4f Received: from singda.apple.com (singda.apple.com [17.201.24.241]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 96.83.23239.04461645; Mon, 10 Nov 2014 17:20:01 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Singer In-Reply-To: <20141111011054.GR8092@hex.shelbyville.oz> Date: Mon, 10 Nov 2014 17:20:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> To: Ron X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FCYqhudkhhicKDT0mLzixvsFmv/tbM7 MHn8apvL7LFkyU+mAKYoLpuU1JzMstQifbsErow//c9ZCw5wVrzvbmNvYDzB3sXIySEhYCIx 5+sMRghbTOLCvfVsXYxcHEIC+xglTs+9wQRTNLXvAzNEYgKTxJyrK8E6mAX0JHZc/8UKYvMK GEgs2bWJGcQWFjCXuPPhP9gGNgFViQdzjoHVcwLFn+67BFbPAhSfMO8vM8QcYYnvj++xQNja EssWvmaGmGkjcX3qb7B6IYEdjBJd53hBbBEBCYk37x8zQxwnL/Hhw3F2kOMkBF6ySlzbPJ9l AqPQLCT3zUJy3ywkOxYwMq9iFMpNzMzRzcwz00ssKMhJ1UvOz93ECAri6XaiOxjPrLI6xCjA wajEw6vhnxgixJpYVlyZe4hRmoNFSZyXKwQoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXFq 5rLZrjzMza9TMyzrsp9ue3JXWX3vhOMGfzU3JygfCBRQeXDnzeqgrCkvtzjMLLr28Nj6HZE2 L2Wec6l+ORG/zDX3GMuxDhbnr57HbSY2TI3KzI/wND8zOeCa8FWjjmDd1f2bVzELib55x9e7 pJOtfRL/u/IAy3dLzN7s0y3esWtmesbcI01KLMUZiYZazEXFiQBd6NB9QwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUieFLio65jSmKIwb61bBabX9xgt1j7r53d gcnjV9tcZo8lS34yBTBFcdmkpOZklqUW6dslcGX86X/OWnCAs+J9dxt7A+MJ9i5GTg4JAROJ qX0fmCFsMYkL99azdTFycQgJTGCSmHN1JSNIgllAT2LH9V+sIDavgIHEkl2bwBqEBcwl7nz4 DzaITUBV4sGcY2D1nEDxp/sugdWzAMUnzPvLDDFHWOL743ssELa2xLKFr5khZtpIXJ/6G6xe SGAHo0TXOV4QW0RAQuLN+8dQx8lLfPhwnH0CI/8sJCfNQnLSLCRjFzAyr2IUKErNSaw010ss KMhJ1UvOz93ECAq6hsLUHYyNy60OMQpwMCrx8Gr4J4YIsSaWFVfmHmKU4GBWEuGtTwAK8aYk VlalFuXHF5XmpBYfYpTmYFES53WMjg0REkhPLEnNTk0tSC2CyTJxcEo1MLZdqY2pLZ5kouaV 3Pc+7/jx3qrYVj/36P2hJ98fXTDxb2zQUv/0AO3QxY38rIv+lLvMMgt8sLS1YHHKye2lpm/q j9aJP1T4/L+Gd/svz4QJ9zZadanzb1q3avfCavHZOnn2veaVO7Zrx8vJyM3L9f5z8bhDQ8lF xY0Hw46Wp/VYdTXkJ3MHKrEUZyQaajEXFScCABiD2Hg2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Gc-7ZFuQp3KxxBqIB0nbIspVyTI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 01:20:30 -0000 On Nov 10, 2014, at 17:10 , Ron wrote: > His option guarantees that anyone implementing only their preferred > codec will be able to interop with any compliant implementation, > though it may not be able to do so with another non-compliant > implementation that similarly opted out of supporting that codec. I am sorry, I don=92t get it. The spec. defines =93WebRTC-compatible = endpoint=94 A WebRTC-compatible endpoint is an endpoint that is capable of successfully communicating with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. but says nothing about it being =91non-compliant=92. So anyone can say = =93I claim that this is compliant to the spec.=94 (as a = webrtc-compatible endpoint) =97 and it might not interoperate. = Basically, this proposal assigns different names to the devices that = implement both, and those that implement only one or none, but does that = really further the cause of interoperability? David Singer Manager, Software Standards, Apple Inc. From nobody Mon Nov 10 17:45:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86931AD3C1 for ; Mon, 10 Nov 2014 17:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGf4Ee5V2IO5 for ; Mon, 10 Nov 2014 17:45:40 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4201A1A4D for ; Mon, 10 Nov 2014 17:45:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 712737C0536 for ; Tue, 11 Nov 2014 02:45:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqY6NOctFf7q for ; Tue, 11 Nov 2014 02:45:38 +0100 (CET) Received: from [IPv6:2001:67c:370:168:4805:b828:f652:a1bd] (t2001067c037001684805b828f652a1bd.wireless-1x.v6.meeting.ietf.org [IPv6:2001:67c:370:168:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 245EF7C00DD for ; Tue, 11 Nov 2014 02:45:37 +0100 (CET) Message-ID: <54616A3B.4090606@alvestrand.no> Date: Mon, 10 Nov 2014 17:45:31 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OLTfgzO1g_DADVYjy18pz95jqAk Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 01:45:43 -0000 On 11/10/2014 05:20 PM, David Singer wrote: > On Nov 10, 2014, at 17:10 , Ron wrote: > >> His option guarantees that anyone implementing only their preferred >> codec will be able to interop with any compliant implementation, >> though it may not be able to do so with another non-compliant >> implementation that similarly opted out of supporting that codec. > I am sorry, I don=92t get it. The spec. defines =93WebRTC-compatible e= ndpoint=94 > > A WebRTC-compatible endpoint is an endpoint that is capable of > successfully communicating with a WebRTC endpoint, but may fail t= o > meet some requirements of a WebRTC endpoint. This may limit wher= e > in the network such an endpoint can be attached, or may limit the= > security guarantees that it offers to others. > > but says nothing about it being =91non-compliant=92. So anyone can say= =93I claim that this is compliant to the spec.=94 (as a webrtc-compatibl= e endpoint) =97 and it might not interoperate. Basically, this proposal a= ssigns different names to the devices that implement both, and those that= implement only one or none, but does that really further the cause of in= teroperability? Video codecs weren't part of the discussion when we introduced those term= s. The obvious examples were ICE-Lite for gateways that reside at public IP addresses, and datachannel and video for POTS telephone gateways - and yes, also OPUS codecs for POTS gateways. (those that have *only* g.711 on the other side - there are better codecs in that environment too, where bridging to OPUS may make sense.) The theory is that those devices will exist and do what they will do no matter what we specify here, so we might as well We'll go through terminology in an hour or so in the meeting. > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. From nobody Mon Nov 10 18:30:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9101AD467 for ; Mon, 10 Nov 2014 18:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O9FkONxdCvN for ; Mon, 10 Nov 2014 18:30:31 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3611AD45C for ; Mon, 10 Nov 2014 18:30:28 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id v10so8970361pde.8 for ; Mon, 10 Nov 2014 18:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/NsC7BceNMb2g/3KWHq9tYmjwCsJQzBGfLuLQFwXoy8=; b=KpIcmL6hdg8CJNXHumWzsrM55BzCK5vS838lxXJd+2rjsB6UFihuVJV160eecHKYY8 tjsgEyTuu/qVfYQmoyP2QJcsh6cBVQkVo/09irf1hCyj/5QpJJWizJEazSOYNjrOHUi7 mklmSE8BnJypC1n9CnOxF788emM9V09sR6gMM6Gjy8qQP5TeG9pqC6KIHQquVl1YJtr4 Ey7Gko+ccsU9zkGXyXwJmjRiXeZOA9fBUX8GvnNRHZFClqci98AM8muT1mjEeC2tKpp3 WpOvYT8CNIabLbeYM3j9xaY8UXf3DOKTJphmnGkRJv/7cDh7fey8jiwK9b4PTV9TmQA1 Bmvw== MIME-Version: 1.0 X-Received: by 10.67.22.99 with SMTP id hr3mr6692263pad.20.1415673027681; Mon, 10 Nov 2014 18:30:27 -0800 (PST) Received: by 10.70.60.201 with HTTP; Mon, 10 Nov 2014 18:30:27 -0800 (PST) Date: Mon, 10 Nov 2014 16:30:27 -1000 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5da53beee32405078c0f50 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uNeKYbGSVIPci_poFC4qyljVgZk Subject: [rtcweb] Death of a one-way stream (#76) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 02:30:32 -0000 --047d7b5da53beee32405078c0f50 Content-Type: text/plain; charset=UTF-8 For the issue in subject line , how about we use a=sendonly/inactive to differentiate the scenarios Use a=inactive : if as a remote end I want to permanently stop getting media and sending media , such a media line can be recycled Use a=sendonly : if as a remote end I want to temporarily pause the incoming media (putting on hold) and such a media line must not be recycled. If this is not enough, we can always add an attribute to clarify the exact semantics .. Cheers Suhas --047d7b5da53beee32405078c0f50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

For the issue in subject line , how ab= out we use a=3Dsendonly/inactive to differentiate the scenarios=C2=A0
=


Use a=3Dinactive : if as a remote end I = want to permanently stop getting media and sending media , such a media lin= e can be recycled

Use a=3Dsendonly : if as a remot= e end I want to temporarily pause the incoming media (putting on hold) and = such a media line must not be recycled.


=
If this is not enough, we can always add an attribute to clarify the e= xact semantics ..


Cheers
= Suhas



--047d7b5da53beee32405078c0f50-- From nobody Mon Nov 10 18:41:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C91A8843 for ; Mon, 10 Nov 2014 18:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 6TNFZ3U7V3ST for ; Mon, 10 Nov 2014 18:41:22 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542461A882F for ; Mon, 10 Nov 2014 18:41:22 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id i57so4012953yha.28 for ; Mon, 10 Nov 2014 18:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mASM/QgQhOG85k+Pwj3LKGpeo/W72757USdvJ3KtceQ=; b=Zh5l6tLOrBM8qa8CB/cK7Od1J9PfYpDSQFS/Xxi8yUhYAxy/9z3i9mTa0TLja0rWmD ZYPQGXfzAoZkv5RvocaPjDxYD21O811dF7+s4XMfoqL9Zqm8L9K8dGMOCCtWfkWnqGbZ f/IP9M1AeT1nXuca9ubOaj8t72Nh7J4kerYBvKCSwkmR0/A93IKEdlsG2g9HDLseBc8F VjxXn1wCZfeDwP51inr3d6NynMbuGT+b/reIxlWSyA8hrOyRT4YKp0MS3hEq6DVF8bE+ Go8X3yGbcEKMuzFfPscgjVJh7loc35B6pGwIpjAKPdqzYyDox6lJFXuLad/HFxObgBvw CvJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mASM/QgQhOG85k+Pwj3LKGpeo/W72757USdvJ3KtceQ=; b=CHy0+W7zfzlm9pO0NwIansc+oalHepbjGH6SFzGOCO8Yu94ihnzVWoGmp+Ck1/eeJ7 2RR57rL53upoDtirySqYXsOwpQGQVj75Z6RUXW8hcioBsEws6YfgbSUDEI88H9xZYf06 9OhGXrTsQdEPER7MI+IKTpOHJr+28jUYjl6lQipYGd+1mc3vH+VcZs5vTaUrSnvI38/w +2iYTaHhq8Bb1KNUdPBpYas1W9Jgkh4TFnVUP5M2SYLfnsYz+c0QJEgvR40rNlq8fBMm WGbeomwgKSPco0U9hd9gbsZv5rRExZ91Ew/3eJAX+aZqJDUj43313CvZh1XI2nBSkeph O64w== X-Gm-Message-State: ALoCoQmKncYhZXFl/akY9q9MEY4ZxYGsXhn8wkTyxdGuzQUEqWdjnnHHUCdEroujT9B2hlGUYN0x X-Received: by 10.52.163.202 with SMTP id yk10mr3795231vdb.14.1415673681417; Mon, 10 Nov 2014 18:41:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 10 Nov 2014 18:41:01 -0800 (PST) In-Reply-To: <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> From: Justin Uberti Date: Mon, 10 Nov 2014 18:41:01 -0800 Message-ID: To: David Singer Content-Type: multipart/alternative; boundary=001a11c22bf0e6395d05078c36fb Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P9_3bv6kZj8QcfQeKlVCstyrMSY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 02:41:24 -0000 --001a11c22bf0e6395d05078c36fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 10, 2014 at 3:04 PM, David Singer wrote: > > On Nov 10, 2014, at 13:55 , Matthew Kaufman wrote: > > > I cited those three players just as examples of known positions. There > are several others, of course. > > > > This proposal puts the large initial burden of IPR risk and/or cost on > the browser vendors... > > > > I think we would need to know how happy Apple, Google, Microsoft, and > Mozilla (plus the other major browser vendors ) are with a requirement th= at > both H.264 and VP8 be included with their browser and/or operating system= . > > > > We may be tired of this, but it isn't like we have a royalty-free optio= n > for H.264 MPEG-LA or IP risk indemnification from Google.. So what's > changed for the browser makers? > > That is my question too; what has changed since this was (effectively) > one of the options in the notorious long-ago poll? > > On the face of it, this requires proponents of =E2=80=98must be free=E2= =80=99 to take on a > non-free license (in principle, though rarely in practice), which is > unacceptable to them, and for the =E2=80=98must be reasonably clear of IP= R risk and > independently implementable=E2=80=99 people to have to take on IPR risk a= nd try (?) > to implement from the specs, which seems unacceptable to them. > > I'm not sure what you are implying with your comment of "independently implementable" and parenthetical question mark, but there are multiple independent implementations of VP8 at this time. Besides the software implementations in libvpx and ffvp8, there are also many independent implementations in SoCs from Qualcomm, Nvidia, and Samsung, amongst others. --001a11c22bf0e6395d05078c36fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 10, 2014 at 3:04 PM, David Singer <singer@apple.com>= wrote:

On Nov 10, 2014, at 13:55 , Matthew Kaufman <matthew@matthew.at> wrote:

> I cited those three players just as examples of known positions. There= are several others, of course.
>
> This proposal puts the large initial burden of IPR risk and/or cost on= the browser vendors...
>
> I think we would need to know how happy Apple, Google, Microsoft, and = Mozilla (plus the other major browser vendors ) are with a requirement that= both H.264 and VP8 be included with their browser and/or operating system.=
>
> We may be tired of this, but it isn't like we have a royalty-free = option for H.264 MPEG-LA or IP risk indemnification from Google.. So what&#= 39;s changed for the browser makers?

That is my question too;=C2=A0 what has changed since this was (effe= ctively) one of the options in the notorious long-ago poll?

On the face of it, this requires proponents of =E2=80=98must be free=E2=80= =99 to take on a non-free license (in principle, though rarely in practice)= , which is unacceptable to them, and for the =E2=80=98must be reasonably cl= ear of IPR risk and independently implementable=E2=80=99 people to have to = take on IPR risk and try (?) to implement from the specs, which seems unacc= eptable to them.

=
I'm not sure what you are implying with your comment of = "independently implementable" and parenthetical question mark, bu= t there are multiple independent implementations of VP8 at this time.
=

Besides the software implementations in libvpx and ffvp= 8, there are also many independent implementations in SoCs from Qualcomm, N= vidia, and Samsung, amongst others.
--001a11c22bf0e6395d05078c36fb-- From nobody Mon Nov 10 18:53:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891EC1AD4BD for ; Mon, 10 Nov 2014 18:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.594, 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 Nndq4PcytrlG for ; Mon, 10 Nov 2014 18:53:19 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060641AD4BF for ; Mon, 10 Nov 2014 18:53:12 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 19so182081ykq.22 for ; Mon, 10 Nov 2014 18:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O6zqUOnPiH+bdXe7k92AyN+9nvvGl3AmqFMzH+xjGNI=; b=IGxh0XyrkNB9CJJKy3WKP+/Ui0sXPeivjqCVAPLe9yM6LZagYomS/Lk5aDOz4zH4e8 BHTWwWajKvLfGTydE5LhyMlx4fRlX/BLUL3AwtwJPzTG5XZPlJuZR0fEAkNeL/mZRPWb Zwd/8CAE0nSXYXfHFu9ZwzKEOBlFdFgeUYcprUsckzWcpsjx6nTv+pPhrxam28rSj4i4 8t4rbTcfwTjeQ2/V8w+mjhsXHkxoxpW3UvKexjRdRMUojdHbYlmsLBeSH7bBMG2pqF+X kWv2LMHRzoKdztFstB8qE2owFneNrZ+ei9bFN63BXF/5NGH7rRwOJw4uUFYzBUJzK02W /dgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=O6zqUOnPiH+bdXe7k92AyN+9nvvGl3AmqFMzH+xjGNI=; b=l3Wi7Caj+DwoYYPuhlcaOhAS5IEzmGJ+E0iqgVrxmbrw4K3IRaWya7dKK6aVyzDtpv Q3PdsY69/sefW2DMCDn138knFewxVUewUdYMbqZr+vXplrYDlkuzoC5CLvrp/ursvVY3 b8HKfrrPc9rsK1PkOUP+GchmNk4vgCY5OGbkWIem4nczb31dQl2PlAUx30+VYuYGf9GT HInOWU701oJaqHqkyKALYgpS2KIp+mN1Kp/iPd3gcZVE4gdxhA79XXxMgNwTTklowTOT dMmJuhdJyco/KUOi6Ntqp7l0I8nAw89y3QuG/5r2eTiDi23qBH2+86OQCuGMw2NENiKJ yk7g== X-Gm-Message-State: ALoCoQnz5bgWv4dyYvdSU2g6JOa8tgZ5C3rmk3BKJum7y8Tj6d6QKkZkeIwlt9yFW/S3UyHGOCXX X-Received: by 10.52.111.202 with SMTP id ik10mr3639198vdb.48.1415674391300; Mon, 10 Nov 2014 18:53:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 10 Nov 2014 18:52:51 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 10 Nov 2014 18:52:51 -0800 Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=bcaec548a13d362a6805078c612a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IFTfNJSnsJHtHMWEKWXYsMVU3CU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Death of a one-way stream (#76) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 02:53:20 -0000 --bcaec548a13d362a6805078c612a Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 6:30 PM, Suhas Nandakumar wrote: > > For the issue in subject line , how about we use a=sendonly/inactive to > differentiate the scenarios > > > Use a=inactive : if as a remote end I want to permanently stop getting > media and sending media , such a media line can be recycled > This unfortunately doesn't work. Consider the following scenario: A and B are exchanging media. B stops A's stream, i.e., it no longer wants to receive media from A. However, B still wants to send media to A. So if B changes the m= line to a=inactive, B's stream stops as well. > Use a=sendonly : if as a remote end I want to temporarily pause the > incoming media (putting on hold) and such a media line must not be recycled. > > > If this is not enough, we can always add an attribute to clarify the exact > semantics .. > > > Cheers > Suhas > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec548a13d362a6805078c612a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 10, 2014 at 6:30 PM, Suhas Nandakumar <= ;suhasietf@gmail.c= om> wrote:

For the issue in subject line , how about we use a=3Ds= endonly/inactive to differentiate the scenarios=C2=A0

<= div>
Use a=3Dinactive : if as a remote end I want to permanen= tly stop getting media and sending media , such a media line can be recycle= d

This unfortunately doesn'= t work. Consider the following scenario:

A and B a= re exchanging media.
B stops A's stream, i.e., it no longer w= ants to receive media from A.
However, B still wants to send medi= a to A.
So if B changes the m=3D line to a=3Dinactive, B's st= ream stops as well.


Use a=3Dsendonly : if as a remote end I wa= nt to temporarily pause the incoming media (putting on hold) and such a med= ia line must not be recycled.


If th= is is not enough, we can always add an attribute to clarify the exact seman= tics ..


Cheers
Suhas




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


--bcaec548a13d362a6805078c612a-- From nobody Mon Nov 10 19:09:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99031AC3BB for ; Mon, 10 Nov 2014 19:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpx7Rc6MhM44 for ; Mon, 10 Nov 2014 19:09:07 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89231ACD7E for ; Mon, 10 Nov 2014 19:09:07 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so7766181lbj.9 for ; Mon, 10 Nov 2014 19:09:06 -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=n3ujljW5Fd1if3UAR/+1NDpCSD7friCThREfbgrg7oE=; b=PrqOMDi8hHRSCfp+YUf6BGV8wdNHOkskOePekM1IO0gjSbpPtPKwFbXe94TzHpalb0 rsa71MePqFrYmjZPFpVu+/0GNmbR6JyMPF8lFUDWDC16GhFDLBeauesLuUZYZ0ZJIDGq UaGVlxTPG8XBLJS1uzBczF7nd6qsO5hQoJMzFyPRmY8rxXKc9g9BtY0Ip46rPX6mlgIQ 9F5A9xd1Qmnn9P9e5KOrbqhzkq9vZWbnPayyjv5brzR2/OWj3Xc1FAo34WCQ8T4zwZWu qr5JQa9Cu8JKvH/nOW9LHNO0R9UqRFsO73yTlqs7EXjBdesygzmQvNUjTnbdZkSIsyU4 1wGw== MIME-Version: 1.0 X-Received: by 10.152.18.166 with SMTP id x6mr33017786lad.18.1415675346023; Mon, 10 Nov 2014 19:09:06 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 19:09:05 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Nov 2014 19:09:05 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p1Do-XYvEeBVFy78mB6b5TMNdIY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Death of a one-way stream (#76) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 03:09:08 -0000 On 10 November 2014 18:52, Justin Uberti wrote: > A and B are exchanging media. > B stops A's stream, i.e., it no longer wants to receive media from A. > However, B still wants to send media to A. > So if B changes the m= line to a=inactive, B's stream stops as well. Yep, and then there is the case where B disposes of their stream and can't resurrect it. A doesn't know that this is a terminal state for that media section. From nobody Mon Nov 10 19:10:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A171AD0D6 for ; Mon, 10 Nov 2014 19:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHzI_ueSzR8A for ; Mon, 10 Nov 2014 19:10:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F961ACD7E for ; Mon, 10 Nov 2014 19:10:01 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAB39xrw017298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 03:09:59 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sAB39vqR024615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 04:09:58 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 04:09:57 +0100 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: User Agent / Non-browser terminology Thread-Index: Ac/9XPeMqPxFfEXKRRWfY0RofhmGtw== Date: Tue, 11 Nov 2014 03:09:56 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF819517AF2@DEMUMBX005.nsn-intra.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF819517AF2DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1747 X-purgate-ID: 151667::1415675399-00001FC1-434CFB4C/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7vRjfhEImD0Gailci4A5138tO0E Subject: [rtcweb] User Agent / Non-browser terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 03:10:04 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF819517AF2DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald, The mic line is closed so I share this comment on the list. Doesn't it sound odd to have "WebRTC User Agent" vs. "WebRTC non-browser"? If we want to follow this path - shouldn't it then rather be "WebRTC browse= r" vs. "WebRTC non-browser"? Sounds more consistent to me. Kind regards, Uwe --_000_56C2F665D49E0341B9DF5938005ACDF819517AF2DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Harald,
 
The mic line is closed so I share this comment on the list.
 
Doesn’t it sound odd to have “WebRTC User Agent” vs.= “WebRTC non-browser”?
If we want to follow this path - shouldn’t it then rather be = 220;WebRTC browser” vs. “WebRTC non-browser”?
Sounds more consistent to me.
 
Kind r= egards,
Uwe
 
 
 --_000_56C2F665D49E0341B9DF5938005ACDF819517AF2DEMUMBX005nsnin_-- From nobody Mon Nov 10 19:19:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1061AD44F for ; Mon, 10 Nov 2014 19:19:16 -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 5lflgYW-fDvw for ; Mon, 10 Nov 2014 19:19:14 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E031A887C for ; Mon, 10 Nov 2014 19:19:14 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kx10so9671050pab.34 for ; Mon, 10 Nov 2014 19:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+mp2XlK6Mr/Zz3XtbKOy9SbpORvb3rNh9uEeuHY/T9c=; b=SvGUBstHYLiZ77kGBVh/w3HevjzuswL1mtznBFUA0Z8YDLl6b4cffhsqB/IzwCu/Oj kWR7jF34unWs0UjcsjuJUgaLDpSrhIs3qoiaFLseWbK+90XhrzJr9E23qfGhR0HwKmrx x7QnmERWKcnVXXDal2W/agudbSWTCM7+IWyKuMuUJ8p5gCbF8yG+f1pkhR2i+S1Pfm9+ srhCPFfZABBXm5lb+ry6iq6FMrVehletrBZr1jfB7M6SlykxC02GyaQwprhiNEvZXu/2 zKNX5YMqhOSatJPcEwiAnEPo61omswAG01XejnIoQv2YXx7LHBFmkam5UB9V2QALzzp/ nH9w== X-Received: by 10.69.26.38 with SMTP id iv6mr8493578pbd.154.1415675954035; Mon, 10 Nov 2014 19:19:14 -0800 (PST) Received: from [10.219.121.254] ([166.170.51.122]) by mx.google.com with ESMTPSA id oc2sm17735108pbb.90.2014.11.10.19.19.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 19:19:12 -0800 (PST) References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Mon, 10 Nov 2014 17:19:08 -1000 To: David Singer Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vNwPyXSLejhRhDmuw5usrfQJI0Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 03:19:16 -0000 I do not get it either. It seems like mobile apps (which count as devices) u= sing a WEBRTC stack now have to include both codecs regardless of whether th= ey need them. Do we really think app developers will pay attention? Why shou= ld they? > On Nov 10, 2014, at 3:20 PM, David Singer wrote: >=20 >=20 >> On Nov 10, 2014, at 17:10 , Ron wrote: >>=20 >> His option guarantees that anyone implementing only their preferred >> codec will be able to interop with any compliant implementation, >> though it may not be able to do so with another non-compliant >> implementation that similarly opted out of supporting that codec. >=20 > I am sorry, I don=E2=80=99t get it. The spec. defines =E2=80=9CWebRTC-com= patible endpoint=E2=80=9D >=20 > A WebRTC-compatible endpoint is an endpoint that is capable of > successfully communicating with a WebRTC endpoint, but may fail to > meet some requirements of a WebRTC endpoint. This may limit where > in the network such an endpoint can be attached, or may limit the > security guarantees that it offers to others. >=20 > but says nothing about it being =E2=80=98non-compliant=E2=80=99. So anyon= e can say =E2=80=9CI claim that this is compliant to the spec.=E2=80=9D (as a= webrtc-compatible endpoint) =E2=80=94 and it might not interoperate. Basica= lly, this proposal assigns different names to the devices that implement bot= h, and those that implement only one or none, but does that really further t= he cause of interoperability? >=20 > David Singer > Manager, Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 19:27:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB271AD0D6 for ; Mon, 10 Nov 2014 19:26:59 -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 ZfhT5-R7yfSQ for ; Mon, 10 Nov 2014 19:26:58 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B911A6F38 for ; Mon, 10 Nov 2014 19:26:58 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so6973142lbv.38 for ; Mon, 10 Nov 2014 19:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/Rifc894dbMMVpNXaMq/FDuWJ+4vLcklbwp0AVkLA6A=; b=nuGesnbABm6g7SsX7vB9h15+8X5hw+jS57tYKQ1vFl4QmTBSy2yR1tvB2O9+Wf0Fry i0HLi4hjdCyFXnFSs775+9inMAfv98BqbtPy4ezyS3JeEApGFhC0QkLBiLrPdKks2FDT RHZYeAm1URtxMRo0aylzwASa4J1EffWyCeRSz2im6wQH3i2/zItq8hHLZ/C/K3u3zNDG e4Sxh34UMzt1KuYi17E2PFkLeVhwjMIR7UrdHFlfHRA8+eLLC6wKUloW+t4ZvSeB9GRh qB3WlFcnVITAcd2xrOIls3NNKVhv+BNU0+Z+/l4sl3X3e/V5juKbV50jcvO3ZgqqYDeM tYKg== MIME-Version: 1.0 X-Received: by 10.112.199.100 with SMTP id jj4mr13092799lbc.71.1415676416385; Mon, 10 Nov 2014 19:26:56 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 19:26:56 -0800 (PST) Date: Mon, 10 Nov 2014 19:26:56 -0800 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j2zeKXripcil8YtrLCjiTqNIVck Subject: [rtcweb] Gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:27:00 -0000 I'm not sure that this is the comment Ted was looking for here. I don't think that we need this document, as Keith observes, a short note in -overview suffices: A gateway is a webrtc endpoint or webrtc-compatible endpoint that forwards stuff (media or data) to other endpoints. This is useful. From nobody Mon Nov 10 19:33:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9381AD506 for ; Mon, 10 Nov 2014 19:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs5NrsZ2eEs4 for ; Mon, 10 Nov 2014 19:33:00 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6EB1AD47A for ; Mon, 10 Nov 2014 19:33:00 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-23-5461836ae819 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.2B.04231.A6381645; Tue, 11 Nov 2014 04:32:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Tue, 11 Nov 2014 04:32:58 +0100 From: Christer Holmberg To: Suhas Nandakumar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Death of a one-way stream (#76) Thread-Index: AQHP/VeC5iGoo0UKRkqG67+GI50K8pxaxPJg Date: Tue, 11 Nov 2014 03:32:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4F0558@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4F0558ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+JvjW5Wc2KIweOXGhZr/7WzW+yc28Hs wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGWcO9zIXNDhUrFjawNTA+MUpy5GTg4JAROJ SS8mMkHYYhIX7q1n62Lk4hASOMIosa/hJiOEs4RR4sfT7cxdjBwcbAIWEt3/tEEaRAQCJX7s PQrWLCxgKnHmwVJmiLiZxPXWTnYI20ji5rqFjCCtLAKqEnOP6IOEeQV8JR7+vQVWLiQQIHHp 1AxWkBJOoJENl/lAwoxA53w/tQZsOrOAuMStJ/OhzhSQWLLnPDOELSrx8vE/VghbSWLt4e0s EPX5EhfnzWeGWCUocXLmE5YJjCKzkIyahaRsFpKyWUBXMAtoSqzfpQ9RoigxpfshO4StIdE6 Zy47svgCRvZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIERdXDLb90djKtfOx5iFOBgVOLh 3VCdGCLEmlhWXJl7iFGag0VJnHfRuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhjNP5d 1XhcGf9ve+y1Z6p2XP6Od0ruTq/bfMP1wdrWB2u339xo5vhrotsNsedzuG8/XxgeEl3u4b8n KvrpOZVd0Syc3G+PXL77MMmvP5at1SGlNZMneWvb2uao6spchZuicm3T6ySu+/LKiXbtS3Q2 aT/RW/zJ0qy1/5DF142nVggYpSue11diKc5INNRiLipOBABlKyugiQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4Ml7ZRgHuwmohSt60WNoSIDheEU Subject: Re: [rtcweb] Death of a one-way stream (#76) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 03:33:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4F0558ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG9u4oCZdCB0aGluayB3ZSBjYW4gY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgdGhl IGluYWN0aXZlIGF0dHJpYnV0ZS4gWW91IG1heSByZWNlaXZlIHN1Y2ggZnJvbSBhIGxlZ2FjeSBk ZXZpY2UgKOKAnFdlYlJUQyBjb21wbGlhbnQgZW5kcG9pbnTigJ0pLCB3aGljaCBkb2VzIE5PVCB3 YW50IHRvIHBlcm1hbmVudGx5IHN0b3Agc2VuZGluZy9yZWNlaXZpbmcgbWVkaWEuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgU3VoYXMgTmFuZGFrdW1hcg0KU2VudDogMTEgTm92ZW1iZXIg MjAxNCAwNDozMA0KVG86IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gRGVhdGgg b2YgYSBvbmUtd2F5IHN0cmVhbSAoIzc2KQ0KDQoNCkZvciB0aGUgaXNzdWUgaW4gc3ViamVjdCBs aW5lICwgaG93IGFib3V0IHdlIHVzZSBhPXNlbmRvbmx5L2luYWN0aXZlIHRvIGRpZmZlcmVudGlh dGUgdGhlIHNjZW5hcmlvcw0KDQoNClVzZSBhPWluYWN0aXZlIDogaWYgYXMgYSByZW1vdGUgZW5k IEkgd2FudCB0byBwZXJtYW5lbnRseSBzdG9wIGdldHRpbmcgbWVkaWEgYW5kIHNlbmRpbmcgbWVk aWEgLCBzdWNoIGEgbWVkaWEgbGluZSBjYW4gYmUgcmVjeWNsZWQNCg0KVXNlIGE9c2VuZG9ubHkg OiBpZiBhcyBhIHJlbW90ZSBlbmQgSSB3YW50IHRvIHRlbXBvcmFyaWx5IHBhdXNlIHRoZSBpbmNv bWluZyBtZWRpYSAocHV0dGluZyBvbiBob2xkKSBhbmQgc3VjaCBhIG1lZGlhIGxpbmUgbXVzdCBu b3QgYmUgcmVjeWNsZWQuDQoNCg0KSWYgdGhpcyBpcyBub3QgZW5vdWdoLCB3ZSBjYW4gYWx3YXlz IGFkZCBhbiBhdHRyaWJ1dGUgdG8gY2xhcmlmeSB0aGUgZXhhY3Qgc2VtYW50aWNzIC4uDQoNCg0K Q2hlZXJzDQpTdWhhcw0KDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4F0558ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkb27igJl0IHRoaW5rIHdlIGNhbiBj aGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgaW5hY3RpdmUgYXR0cmlidXRlLiBZb3UgbWF5IHJl Y2VpdmUgc3VjaCBmcm9tIGEgbGVnYWN5IGRldmljZSAo4oCcV2ViUlRDIGNvbXBsaWFudCBlbmRw b2ludOKAnSksDQogd2hpY2ggZG9lcyBOT1Qgd2FudCB0byBwZXJtYW5lbnRseSBzdG9wIHNlbmRp bmcvcmVjZWl2aW5nIG1lZGlhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlz dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2ViIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN1aGFzIE5hbmRha3Vt YXI8YnI+DQo8Yj5TZW50OjwvYj4gMTEgTm92ZW1iZXIgMjAxNCAwNDozMDxicj4NCjxiPlRvOjwv Yj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3ZWJdIERlYXRoIG9m IGEgb25lLXdheSBzdHJlYW0gKCM3Nik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gb3IgdGhlIGlzc3VlIGluIHN1YmplY3QgbGluZSAsIGhvdyBhYm91dCB3 ZSB1c2UgYT1zZW5kb25seS9pbmFjdGl2ZSB0byBkaWZmZXJlbnRpYXRlIHRoZSBzY2VuYXJpb3Mm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Vc2UgYT1pbmFjdGl2ZSA6IGlmIGFzIGEgcmVtb3RlIGVuZCBJIHdhbnQgdG8gcGVybWFu ZW50bHkgc3RvcCBnZXR0aW5nIG1lZGlhIGFuZCBzZW5kaW5nIG1lZGlhICwgc3VjaCBhIG1lZGlh IGxpbmUgY2FuIGJlIHJlY3ljbGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlVzZSBhPXNlbmRvbmx5IDogaWYgYXMgYSByZW1vdGUgZW5kIEkg d2FudCB0byB0ZW1wb3JhcmlseSBwYXVzZSB0aGUgaW5jb21pbmcgbWVkaWEgKHB1dHRpbmcgb24g aG9sZCkgYW5kIHN1Y2ggYSBtZWRpYSBsaW5lIG11c3Qgbm90IGJlIHJlY3ljbGVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoaXMg aXMgbm90IGVub3VnaCwgd2UgY2FuIGFsd2F5cyBhZGQgYW4gYXR0cmlidXRlIHRvIGNsYXJpZnkg dGhlIGV4YWN0IHNlbWFudGljcyAuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VoYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D4F0558ESESSMB209erics_-- From nobody Mon Nov 10 19:38:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6886E1AD519 for ; Mon, 10 Nov 2014 19:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 qpEnaHEwLfjh for ; Mon, 10 Nov 2014 19:38:24 -0800 (PST) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id B5D201AD506 for ; Mon, 10 Nov 2014 19:38:19 -0800 (PST) Received: from lminiero ([31.133.183.36]) by smtpcmd02.ad.aruba.it with bizsmtp id E3eF1p00B0nXt2P013eG74; Tue, 11 Nov 2014 04:38:17 +0100 Date: Tue, 11 Nov 2014 04:38:12 +0100 From: Lorenzo Miniero To: Martin Thomson Message-ID: <20141111043812.629e8f9f@lminiero> In-Reply-To: References: Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Djhh0JvVX-5EBMlU6kOXdnbu1Vg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:38:26 -0000 On Mon, 10 Nov 2014 19:26:56 -0800 Martin Thomson wrote: > I'm not sure that this is the comment Ted was looking for here. > > I don't think that we need this document, as Keith observes, a short > note in -overview suffices: > > A gateway is a webrtc endpoint or webrtc-compatible endpoint that > forwards stuff (media or data) to other endpoints. This is useful. > Having worked on one I think we need more than that, so I'd support such a document. There are several things that can go wrong (see the stuff we're discussing in STRAW, for instance) so gateways are indeed special IMHO. I can help/contribute text if deemed useful. Lorenzo > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 19:54:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187BC1AD53D for ; Mon, 10 Nov 2014 19:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMVrauPaobSi for ; Mon, 10 Nov 2014 19:54:44 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 907A11A88AF for ; Mon, 10 Nov 2014 19:54:44 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Nov 2014 22:54:38 -0500 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 10 Nov 2014 22:54:38 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Mon, 10 Nov 2014 22:54:38 -0500 From: Andrew Allen To: "rtcweb@ietf.org" Thread-Topic: Gateways draft Thread-Index: Ac/9YzaE4Jf1gPATTiGmh8DmnJoxhA== Date: Tue, 11 Nov 2014 03:54:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C4rntwAnFtHFrPB9agKyKttHpfk Subject: [rtcweb] Gateways draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 03:54:46 -0000 One comment on one of Harald's statements during the brief presentation. Harald said we might allow Gateways not to support OPUS. Is this a good idea?=20 Use of G.711 by WebRTC clients connected via narrowband networks is not a g= ood idea so the gateway needs to support OPUS even if it is going to do PCM= on the other side. Andrew= From nobody Mon Nov 10 20:11:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3321A8849 for ; Mon, 10 Nov 2014 20:11:12 -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, 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 gLvhtIYYnzzm for ; Mon, 10 Nov 2014 20:11:09 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11DE1AD44C for ; Mon, 10 Nov 2014 20:10:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sAB4AXqM014149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Nov 2014 04:10:34 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sAB4AX8X008301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 05:10:33 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 05:10:33 +0100 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Gateways Thread-Index: AQHP/V9fxC9yv929H0iU/MBraqxtKpxazM/g Date: Tue, 11 Nov 2014 04:10:33 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF819517C2A@DEMUMBX005.nsn-intra.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.156] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1402 X-purgate-ID: 151667::1415679034-0000437E-5D73ADF2/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zV4m1gpMHMWt6KjMo-qPrd4Povo Subject: Re: [rtcweb] Gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 04:11:12 -0000 Hi Martin, In Toronto, we have discussed that we need a home for statements regarding = relaxing of requirements for gateways, such as support for ICE lite. The -g= ateways draft provides this home; I would be OK with another home as long a= s the necessary text can be provided.=20 On the value of this, I think we should remind developers somewhere in our = documentation that WebRTC browsers / "non-browsers" should be aware that th= ey may meet end points that have a restricted feature set and that they nee= d to be able to interwork with them. The statement you propose below is too short to capture the specific requir= ements relaxations for WebRTC gateways.=A0 Kind regards, Uwe=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Martin > Thomson > Sent: Monday, November 10, 2014 5:27 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Gateways >=20 > I'm not sure that this is the comment Ted was looking for here. >=20 > I don't think that we need this document, as Keith observes, a short > note in -overview suffices: >=20 > A gateway is a webrtc endpoint or webrtc-compatible endpoint that > forwards stuff (media or data) to other endpoints. This is useful. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Nov 10 20:18:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6431ACEDC for ; Mon, 10 Nov 2014 20:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6tDlXC5_B48 for ; Mon, 10 Nov 2014 20:17:57 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id DE6341ACE91 for ; Mon, 10 Nov 2014 20:17:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 77E0F7C0538; Tue, 11 Nov 2014 05:17:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHDt-H3EVGay; Tue, 11 Nov 2014 05:17:50 +0100 (CET) Received: from [30.59.35.90] (unknown [172.56.16.81]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6723F7C0536; Tue, 11 Nov 2014 05:17:49 +0100 (CET) User-Agent: K-9 Mail for Android In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF819517AF2@DEMUMBX005.nsn-intra.net> References: <56C2F665D49E0341B9DF5938005ACDF819517AF2@DEMUMBX005.nsn-intra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----G4MI6ZN26I3860VL4U5A3WV9M6H0XZ" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Mon, 10 Nov 2014 18:17:36 -1000 To: "Rauschenbach, Uwe (NSN - DE/Munich)" , "rtcweb@ietf.org" Message-ID: <7A0C5DCA-66CE-4E5C-A6E5-C6BD4ECFBC9D@alvestrand.no> Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xzSDwM8XRHeYWAGwiulaC9u68ns Subject: Re: [rtcweb] User Agent / Non-browser terminology X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 04:18:01 -0000 ------G4MI6ZN26I3860VL4U5A3WV9M6H0XZ Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Non-ua sounds even weirder... The reason for mentioning both UA and browser is that w3c tends to prefer UA. But we seem to be most comfortable with browser. Den 10. november 2014 17.09.56 GMT-10:00, skrev "Rauschenbach, Uwe (NSN - DE/Munich)" : >Hi Harald, > >The mic line is closed so I share this comment on the list. > >Doesn't it sound odd to have "WebRTC User Agent" vs. "WebRTC >non-browser"? >If we want to follow this path - shouldn't it then rather be "WebRTC >browser" vs. "WebRTC non-browser"? >Sounds more consistent to me. > >Kind regards, >Uwe -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------G4MI6ZN26I3860VL4U5A3WV9M6H0XZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Non-ua sounds even weirder... The reason for mentioning both UA and browser is that w3c tends to prefer UA. But we seem to be most comfortable with browser.

Den 10. november 2014 17.09.56 GMT-10:00, skrev "Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com>:
Hi Harald,
 
The mic line is closed so I share this comment on the list.
 
Doesn’t it sound odd to have “WebRTC User Agent” vs. “WebRTC non-browser”?
If we want to follow this path - shouldn’t it then rather be “WebRTC browser” vs. “WebRTC non-browser”?
Sounds more consistent to me.
 
Kind regards,
Uwe
 
 

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------G4MI6ZN26I3860VL4U5A3WV9M6H0XZ-- From nobody Mon Nov 10 21:23:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD42F1A8714 for ; Mon, 10 Nov 2014 21:23:19 -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 UtOLWEHqmtM2 for ; Mon, 10 Nov 2014 21:23:17 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913EE1A6FE9 for ; Mon, 10 Nov 2014 21:23:17 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id a141so6537004oig.13 for ; Mon, 10 Nov 2014 21:23:16 -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 :content-type; bh=pHezftruDGf7248S3tcQxUhHXJCHAEk3B1TGHGR6zj8=; b=hYrD9SkRXrLzBAZMU0jZDiGQ356Rxn9pHIJEPItKVXZ61gEszg1dQCNgUe7yyZL9SK gV/WzakevpltV2hwKyTh+KdajnFj+U6K6WQ0YgYcF1/1tW4p9xFwym1+1PwnHStFoHQm BTg0v+GZaTOlzG5ycs+fxlKrp6BB+BDjV59q/9Z8L40LApOoAxN535j594Q1Tc1b/fD1 DQc1V2rdROWLvzbSKKgxg5fk/u5oaIkDLsk/MGi2yqN+GzlW05TLuh6l7k1WUyWnZ9qu F/JhnqT+/hZFxSv+0vN/jmj+xd8qRk5bhM8uT0J79YKr4v+1O/VzS1GSMl2t4mLQYpvs BK9Q== MIME-Version: 1.0 X-Received: by 10.60.173.39 with SMTP id bh7mr31321395oec.32.1415683396777; Mon, 10 Nov 2014 21:23:16 -0800 (PST) Received: by 10.202.209.8 with HTTP; Mon, 10 Nov 2014 21:23:16 -0800 (PST) In-Reply-To: References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> Date: Tue, 11 Nov 2014 13:23:16 +0800 Message-ID: From: Alexandre GOUAILLARD To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6ba9afabe1105078e79f8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OEDJUMFA-vdspjrybNzzId87PsQ Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 05:23:20 -0000 --047d7bd6ba9afabe1105078e79f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for this proposal. Thanks adam for doing the background work to bring some parties closer to a consensus. On Tue, Nov 11, 2014 at 11:19 AM, Bernard Aboba wrote: > I do not get it either. It seems like mobile apps (which count as devices= ) > using a WEBRTC stack now have to include both codecs regardless of whethe= r > they need them. Do we really think app developers will pay attention? Why > should they? > > > > > On Nov 10, 2014, at 3:20 PM, David Singer wrote: > > > > > >> On Nov 10, 2014, at 17:10 , Ron wrote: > >> > >> His option guarantees that anyone implementing only their preferred > >> codec will be able to interop with any compliant implementation, > >> though it may not be able to do so with another non-compliant > >> implementation that similarly opted out of supporting that codec. > > > > I am sorry, I don=E2=80=99t get it. The spec. defines =E2=80=9CWebRTC-= compatible > endpoint=E2=80=9D > > > > A WebRTC-compatible endpoint is an endpoint that is capable of > > successfully communicating with a WebRTC endpoint, but may fail to > > meet some requirements of a WebRTC endpoint. This may limit where > > in the network such an endpoint can be attached, or may limit the > > security guarantees that it offers to others. > > > > but says nothing about it being =E2=80=98non-compliant=E2=80=99. So an= yone can say =E2=80=9CI > claim that this is compliant to the spec.=E2=80=9D (as a webrtc-compatibl= e > endpoint) =E2=80=94 and it might not interoperate. Basically, this propos= al assigns > different names to the devices that implement both, and those that > implement only one or none, but does that really further the cause of > interoperability? > > > > David Singer > > Manager, Software Standards, Apple Inc. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --047d7bd6ba9afabe1105078e79f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for this proposal.

Thanks adam for d= oing the background work to bring some parties closer to a consensus.
=

On Tue, Nov= 11, 2014 at 11:19 AM, Bernard Aboba <bernard.aboba@gmail.com>= ; wrote:
I do not get it either. I= t seems like mobile apps (which count as devices) using a WEBRTC stack now = have to include both codecs regardless of whether they need them. Do we rea= lly think app developers will pay attention? Why should they?



> On Nov 10, 2014, at 3:20 PM, David Singer <singer@apple.com> wrote:
>
>
>> On Nov 10, 2014, at 17:10 , Ron <ron@debian.org> wrote:
>>
>> His option guarantees that anyone implementing only their preferre= d
>> codec will be able to interop with any compliant implementation, >> though it may not be able to do so with another non-compliant
>> implementation that similarly opted out of supporting that codec.<= br> >
> I am sorry, I don=E2=80=99t get it.=C2=A0 The spec. defines =E2=80=9CW= ebRTC-compatible endpoint=E2=80=9D
>
> A WebRTC-compatible endpoint is an endpoint that is capable of
>=C2=A0 =C2=A0 =C2=A0 successfully communicating with a WebRTC endpoint,= but may fail to
>=C2=A0 =C2=A0 =C2=A0 meet some requirements of a WebRTC endpoint.=C2=A0= This may limit where
>=C2=A0 =C2=A0 =C2=A0 in the network such an endpoint can be attached, o= r may limit the
>=C2=A0 =C2=A0 =C2=A0 security guarantees that it offers to others.
>
> but says nothing about it being =E2=80=98non-compliant=E2=80=99.=C2=A0= So anyone can say =E2=80=9CI claim that this is compliant to the spec.=E2= =80=9D (as a webrtc-compatible endpoint) =E2=80=94 and it might not interop= erate. Basically, this proposal assigns different names to the devices that= implement both, and those that implement only one or none, but does that r= eally further the cause of interoperability?
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> 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



--
=
Alex. Gouaillard, PhD, PhD,= MBA
------------------------------------------------------------------= ------------------
CTO - Temasys Communications, S'pore / Mou= ntain View
President - CoSMo Software, Cambridge, MA
--= ---------------------------------------------------------------------------= -------

<= /div>
--047d7bd6ba9afabe1105078e79f8-- From nobody Mon Nov 10 21:26:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82E21ACD67 for ; Mon, 10 Nov 2014 21:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyqBCuAVGDFg for ; Mon, 10 Nov 2014 21:26:48 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3763F1AC446 for ; Mon, 10 Nov 2014 21:26:48 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id DC6C1E32FD7B0; Tue, 11 Nov 2014 05:26:43 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sAB5Qjcn010742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 06:26:45 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 06:26:45 +0100 From: "DRAGE, Keith (Keith)" To: Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Gateways Thread-Index: AQHP/V9j0b9ypGvtnU+ZHDitQTVoRpxa4wBg Date: Tue, 11 Nov 2014 05:26:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B277459@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ze8jN67Fc_7WoxxwiZyuSbwv3AA Subject: Re: [rtcweb] Gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 05:26:50 -0000 That is not what I was suggesting. I still believe that the gateways draft should be integrated into the overv= iew, but independent of that it does need to quantify in some what what a w= ebrtc gateway should conform to. So I believe that there should be a structure similar to that given in sect= ions 4 through 9 of the overview document. The statements made there will o= bviously not be quite so mandating as those for the endpoints, but for exam= ple it should be perfectly reasonable to state that for example: "If the WebRTC gateway terminates RTP, then the WebRTC gateway MUST impleme= nt draft-ietf-rtcweb-rtp-usage." I would like it to focus on thet parts of the protocol suite that the gatew= ay is likely to terminate. Regards Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Martin Thomson > Sent: 11 November 2014 03:27 > To: rtcweb@ietf.org > Subject: [rtcweb] Gateways >=20 > I'm not sure that this is the comment Ted was looking for here. >=20 > I don't think that we need this document, as Keith observes,=20 > a short note in -overview suffices: >=20 > A gateway is a webrtc endpoint or webrtc-compatible endpoint=20 > that forwards stuff (media or data) to other endpoints. This=20 > is useful. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Mon Nov 10 21:29:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420351ACDEB for ; Mon, 10 Nov 2014 21:29:00 -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 T-xOs4GRk4fI for ; Mon, 10 Nov 2014 21:28:59 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA361ACDB8 for ; Mon, 10 Nov 2014 21:28:58 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id b6so7019451lbj.16 for ; Mon, 10 Nov 2014 21:28:57 -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=xIlWfkvP8XT8YcTZfZcd/pW6MeJvYlKuTdlB9O8ah/Y=; b=Xtl10fPl2efYrSbN0iyxk3H0B18Q6AHr2uHmURdbjdW8wb6lCsgCmbm7aO0K3dBSBm ImEEz0zXCRxO1hZTqQS+3tPHm6fMKjRv1dCBjjH9IT/wiYZdDS+z2jGcA/RUVWrmGmyG YI1QPL8Q5nxv4UuFM1fp9xUSSQvxfjxa2/Tzf19K8QZw1Lo60fOFoLYXl3TTu2AhJ0nw ZyrIjVWrbwi8932ppbLJuz9W8gj5BxKl3MBS/hQhbYalvWhdR1jAG8+z6krXbJv43oYt A+RfqstO/G7AQ1mFtx9ZXgEnzQBpvObVl3gjm/JkBBzxGm9mzR5bRDzlu9FGLabfX4WG aw4Q== MIME-Version: 1.0 X-Received: by 10.113.5.7 with SMTP id ci7mr34775507lbd.9.1415683737150; Mon, 10 Nov 2014 21:28:57 -0800 (PST) Received: by 10.25.215.33 with HTTP; Mon, 10 Nov 2014 21:28:57 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B277459@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B277459@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 10 Nov 2014 21:28:57 -0800 Message-ID: From: Martin Thomson To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MHejPckA9vRFODHyLlJQvdctzBk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 05:29:00 -0000 On 10 November 2014 21:26, DRAGE, Keith (Keith) wrote: > That is not what I was suggesting. I didn't mean to suggest that. I agreed with the integration suggestion you provided, but added my own: There is no value to *WebRTC* in having a thorough and robust description of the things that are outside of WebRTC other than to note that they exist and might interface in a somewhat rough fashion with WebRTC. From nobody Mon Nov 10 21:29:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631681ACE3D for ; Mon, 10 Nov 2014 21:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfpKgDyUGKpJ for ; Mon, 10 Nov 2014 21:29:41 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8C1ACDEB for ; Mon, 10 Nov 2014 21:29:41 -0800 (PST) Received: from [172.20.14.50] (unknown [12.1.203.3]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id F27C0464CA6; Mon, 10 Nov 2014 21:29:40 -0800 (PST) Message-ID: <54619EC4.2070802@matthew.at> Date: Mon, 10 Nov 2014 21:29:40 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roman Shpount References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070202010200050800000206" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8JpbJDQA9aNk7QekeoGmaNDYooM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 05:29:42 -0000 This is a multi-part message in MIME format. --------------070202010200050800000206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/10/2014 4:25 PM, Roman Shpount wrote: > On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman > wrote: > > We may be tired of this, but it isn't like we have a royalty-free > option for H.264 MPEG-LA or IP risk indemnification from Google.. > So what's changed for the browser makers? > > > May be I am missing something, but MPEG-LA does not provide IP risk > indemnification for H.264. All they sell is a very limited license to > the patent pool from the group members. I am not my employer's lawyers, nor am I the lawyers for any of the other folks who've spoken up about the IPR issues over the years. But these folks apparently feel that there's something different between "specification developed in an open standards process" + "licenses to listed IPR available from patent pool" and "some code Google says is free" for whatever reasons they have. You'd have to ask them to see why that's different. Matthew Kaufman --------------070202010200050800000206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 11/10/2014 4:25 PM, Roman Shpount wrote:
On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman <matthew@matthew.at> wrote:
We may be tired of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed for the browser makers?


May be I am missing something, but MPEG-LA does not provide IP risk indemnification for H.264. All they sell is a very limited license to the patent pool from the group members.

I am not my employer's lawyers, nor am I the lawyers for any of the other folks who've spoken up about the IPR issues over the years. But these folks apparently feel that there's something different between "specification developed in an open standards process" + "licenses to listed IPR available from patent pool" and "some code Google says is free" for whatever reasons they have.

You'd have to ask them to see why that's different.

Matthew Kaufman
--------------070202010200050800000206-- From nobody Mon Nov 10 21:32:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BDB1A88F9 for ; Mon, 10 Nov 2014 21:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl2bp7TizB6I for ; Mon, 10 Nov 2014 21:32:31 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id C044E1A88F6 for ; Mon, 10 Nov 2014 21:32:31 -0800 (PST) Received: from [172.20.14.50] (unknown [12.1.203.3]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id A38BE46500E for ; Mon, 10 Nov 2014 21:32:31 -0800 (PST) Message-ID: <54619F6E.6030703@matthew.at> Date: Mon, 10 Nov 2014 21:32:30 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <54614458.2070204@alvestrand.no> In-Reply-To: <54614458.2070204@alvestrand.no> Content-Type: multipart/alternative; boundary="------------070103010401070103000902" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7ItJGmmFcBWUHPEBXBiXpSLtUmU Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 05:32:33 -0000 This is a multi-part message in MIME format. --------------070103010401070103000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/10/2014 3:03 PM, Harald Alvestrand wrote: > On 11/10/2014 02:58 PM, Eric Rescorla wrote: >> >> >> On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman > > wrote: >> >> I cited those three players just as examples of known positions. >> There are several others, of course. >> >> This proposal puts the large initial burden of IPR risk and/or >> cost on the browser vendors... >> >> I think we would need to know how happy Apple, Google, Microsoft, >> and Mozilla (plus the other major browser vendors ) are with a >> requirement that both H.264 and VP8 be included with their >> browser and/or operating system. >> >> >> As I said previously, we're fine with this requirement. > > Google is also fine with this requirement. So that's two browser vendors who are fine with that requirement. I can't speak for my employer, but I hear that we are a well-known browser vendor as well. Nor can I speak for Apple, but I know they're a browser vendor as I use their browser on some of my personal devices. Would sure be nice to get closer to 100% agreement from the people who actually ship the code in question. Matthew Kaufman --------------070103010401070103000902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/10/2014 3:03 PM, Harald Alvestrand wrote:
On 11/10/2014 02:58 PM, Eric Rescorla wrote:


On Mon, Nov 10, 2014 at 11:55 AM, Matthew Kaufman <matthew@matthew.at> wrote:
I cited those three players just as examples of known positions. There are several others, of course.

This proposal puts the large initial burden of IPR risk and/or cost on the browser vendors... 

I think we would need to know how happy Apple, Google, Microsoft, and Mozilla (plus the other major browser vendors ) are with a requirement that both H.264 and VP8 be included with their browser and/or operating system.

As I said previously, we're fine with this requirement.

Google is also fine with this requirement.

So that's two browser vendors who are fine with that requirement.

I can't speak for my employer, but I hear that we are a well-known browser vendor as well.

Nor can I speak for Apple,  but I know they're a browser vendor as I use their browser on some of my personal devices.

Would sure be nice to get closer to 100% agreement from the people who actually ship the code in question.

Matthew Kaufman
--------------070103010401070103000902-- From nobody Mon Nov 10 21:35:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC91ACFEB for ; Mon, 10 Nov 2014 21:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWb5Usv4ppL1 for ; Mon, 10 Nov 2014 21:35:40 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id C88D81A88F6 for ; Mon, 10 Nov 2014 21:35:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D74CA7C053A for ; Tue, 11 Nov 2014 06:35:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw4zLZSIw1WI for ; Tue, 11 Nov 2014 06:35:28 +0100 (CET) Received: from [IPv6:2001:67c:370:176:4805:b828:f652:a1bd] (t2001067c037001764805b828f652a1bd.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4EE287C0531 for ; Tue, 11 Nov 2014 06:35:28 +0100 (CET) Message-ID: <5461A019.6030108@alvestrand.no> Date: Mon, 10 Nov 2014 21:35:21 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mG36G3__kQ7biQzRKUp8WqBDc-U Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 05:35:41 -0000 On 11/10/2014 07:19 PM, Bernard Aboba wrote: > I do not get it either. It seems like mobile apps (which count as devices) using a WEBRTC stack now have to include both codecs regardless of whether they need them. Do we really think app developers will pay attention? Why should they? Because they can then depend on interoperability with other non-browsers? From nobody Mon Nov 10 21:47:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F871ACDC6 for ; Mon, 10 Nov 2014 21:47:09 -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 vYOTCsw7yVKs for ; Mon, 10 Nov 2014 21:47:08 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09C41ACD85 for ; Mon, 10 Nov 2014 21:47:07 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id x12so10682415wgg.4 for ; Mon, 10 Nov 2014 21:47:06 -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=mdByfzRnnYp4YdSwOFwS+b9lzsN/Nsflm7kAYzSX14A=; b=CQISpDwlUdvRBkF/IuaDDD2sJ40OqU66vSO87jvxsR1TCQsedAXCLzy8gj9oIAGjXv QeqbYHOo1iruYaX7LqsqQ+IXuADzxkzWqc9XBJXMPNGUoiDiyEQk/FtHw7CPUIM5EtOJ HWE9ilWw++mkGq0+a9OnYBUcr1jNb9C41184lPbBFnlmP1mjbqe03ltENUTz9FIG/p8w grqE7aR1cJiznn0vlTGaO0QPsbLIdxcVo0Xj/wRAFB95FIa4x8bsWpZ4Qdyhxc3X/Pcj v0vYC+vmxJGXTVKCm3xcWAkVbJOTuv0gQeuF6lgRqC5LHd3ujSzjskaP7029KJvLQUNr QckQ== X-Gm-Message-State: ALoCoQkXzLvYysatAWXiuBPT/9KZ35s7ZC053xByhXtNin7c7re/ZSZ1c7SoX42mTtPWpgcWpsoP X-Received: by 10.194.185.68 with SMTP id fa4mr31106428wjc.83.1415684826525; Mon, 10 Nov 2014 21:47:06 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com. [74.125.82.44]) by mx.google.com with ESMTPSA id b6sm16001574wiy.22.2014.11.10.21.47.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 21:47:05 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id x12so10729559wgg.31 for ; Mon, 10 Nov 2014 21:47:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr52529643wjb.78.1415684825046; Mon, 10 Nov 2014 21:47:05 -0800 (PST) Received: by 10.216.176.65 with HTTP; Mon, 10 Nov 2014 21:47:04 -0800 (PST) In-Reply-To: <54619EC4.2070802@matthew.at> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <54619EC4.2070802@matthew.at> Date: Tue, 11 Nov 2014 00:47:04 -0500 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=089e0102fc521c66d505078ecf01 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dM6_e2GhytYoBEKqhpVMU5qKuVw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 05:47:10 -0000 --089e0102fc521c66d505078ecf01 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 11, 2014 at 12:29 AM, Matthew Kaufman wrote: > On 11/10/2014 4:25 PM, Roman Shpount wrote: > > On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman > wrote: > >> We may be tired of this, but it isn't like we have a royalty-free >> option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's >> changed for the browser makers? >> >> > May be I am missing something, but MPEG-LA does not provide IP risk > indemnification for H.264. All they sell is a very limited license to the > patent pool from the group members. > > > I am not my employer's lawyers, nor am I the lawyers for any of the other > folks who've spoken up about the IPR issues over the years. But these folks > apparently feel that there's something different between "specification > developed in an open standards process" + "licenses to listed IPR available > from patent pool" and "some code Google says is free" for whatever reasons > they have. > > You'd have to ask them to see why that's different. > > I am not the lawyer either, but there is a difference between "specification developed in an open standards process" + "licenses to listed IPR available from patent pool" vs Google offering indemnity against third party IPR claims. I believe everyone can agree that "open standards process" is a requirement for an MTI video codec. Royalty free RAND terms are highly desired. The indemnity is just wishful thinking. I cannot think of a single codec patent pool that offer indemnity. I also do not see much difference between "licenses to listed IPR available from patent pool" and "licenses to listed IPR are available from Google" as long as they are available under royalty free RAND terms. I doubt anybody will form the patent pool to collect no money. _____________ Roman Shpount --089e0102fc521c66d505078ecf01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Nov 11, 2014 at 12:29 AM, Matthew Kaufman <matthew@matthew.at> wrote:
=20 =20 =20
On 11/10/2014 4:25 PM, Roman Shpount wrote:
On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman <matthew@matthew.at> wrote:
We may be tired of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed for the browser makers?


May be I am missing something, but MPEG-LA does not provide IP risk indemnification for H.264. All they sell is a very limited license to the patent pool from the group members.

I am not my employer's lawyers, nor am I the lawyers for any of the other folks who've spoken up about the IPR issues over the years. But these folks apparently feel that there's something different between "specification developed in an open standards process"= ; + "licenses to listed IPR available from patent pool" and "= ;some code Google says is free" for whatever reasons they have.

You'd have to ask them to see why that's different.


I am not the l= awyer either, but there is a difference between=C2=A0"specification de= veloped in an open standards process" + "licenses to listed IPR a= vailable from patent pool"=C2=A0vs Google offering indemnity against t= hird party IPR claims. I believe everyone can agree that "open standar= ds process"=C2=A0=C2=A0is a requirement for an=C2=A0MTI video codec. R= oyalty free RAND terms are highly desired. The indemnity is just wishful th= inking. I cannot think of a single codec patent pool that offer indemnity. = I also do not see much difference between =C2=A0"licenses to listed IP= R available from patent pool" and "licenses to listed IPR are ava= ilable from Google" as long as they are available under royalty free R= AND terms. I doubt anybody will form the patent pool to collect no money.
_____________
Roman Shpount

=C2=A0
--089e0102fc521c66d505078ecf01-- From nobody Mon Nov 10 21:51:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213CE1AD553 for ; Mon, 10 Nov 2014 21:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBKcsqOj7J69 for ; Mon, 10 Nov 2014 21:51:27 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9F91AD546 for ; Mon, 10 Nov 2014 21:51:27 -0800 (PST) Received: from [172.20.14.50] (unknown [12.1.203.3]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 1B16E4645CE; Mon, 10 Nov 2014 21:51:27 -0800 (PST) Message-ID: <5461A3DE.6020409@matthew.at> Date: Mon, 10 Nov 2014 21:51:26 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roman Shpount References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <54619EC4.2070802@matthew.at> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030402060502000709040006" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mNpIR2nBooPl7YXJcA-Tag08SKw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 05:51:29 -0000 This is a multi-part message in MIME format. --------------030402060502000709040006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/10/2014 9:47 PM, Roman Shpount wrote: > > On Tue, Nov 11, 2014 at 12:29 AM, Matthew Kaufman > wrote: > > On 11/10/2014 4:25 PM, Roman Shpount wrote: >> On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman >> > wrote: >> >> We may be tired of this, but it isn't like we have a >> royalty-free option for H.264 MPEG-LA or IP risk >> indemnification from Google.. So what's changed for the >> browser makers? >> >> >> May be I am missing something, but MPEG-LA does not provide IP >> risk indemnification for H.264. All they sell is a very limited >> license to the patent pool from the group members. > > I am not my employer's lawyers, nor am I the lawyers for any of > the other folks who've spoken up about the IPR issues over the > years. But these folks apparently feel that there's something > different between "specification developed in an open standards > process" + "licenses to listed IPR available from patent pool" and > "some code Google says is free" for whatever reasons they have. > > You'd have to ask them to see why that's different. > > > I am not the lawyer either, but there is a difference > between "specification developed in an open standards process" + > "licenses to listed IPR available from patent pool" vs Google offering > indemnity against third party IPR claims. I believe everyone can agree > that "open standards process" is a requirement for an MTI video > codec. Royalty free RAND terms are highly desired. The indemnity is > just wishful thinking. I cannot think of a single codec patent pool > that offer indemnity. I also do not see much difference between > "licenses to listed IPR available from patent pool" and "licenses to > listed IPR are available from Google" as long as they are available > under royalty free RAND terms. I doubt anybody will form the patent > pool to collect no money. > _____________ > Roman Shpount > I was giving examples like "royalty-free option for H.264 MPEG-LA" or "IP risk indemnification from Google" as things that would indicate real change in the IPR landscape, which is one of the major things driving the positions of the browser makers. Neither has happened. They're both equivalently "wishful thinking" at this point. If and when something changes, we should discuss what that means. Until then, I ask again: what's changed? Matthew Kaufman --------------030402060502000709040006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 11/10/2014 9:47 PM, Roman Shpount wrote:

On Tue, Nov 11, 2014 at 12:29 AM, Matthew Kaufman <matthew@matthew.at> wrote:
On 11/10/2014 4:25 PM, Roman Shpount wrote:
On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman <matthew@matthew.at> wrote:
We may be tired of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed for the browser makers?


May be I am missing something, but MPEG-LA does not provide IP risk indemnification for H.264. All they sell is a very limited license to the patent pool from the group members.

I am not my employer's lawyers, nor am I the lawyers for any of the other folks who've spoken up about the IPR issues over the years. But these folks apparently feel that there's something different between "specification developed in an open standards process" + "licenses to listed IPR available from patent pool" and "some code Google says is free" for whatever reasons they have.

You'd have to ask them to see why that's different.


I am not the lawyer either, but there is a difference between "specification developed in an open standards process" + "licenses to listed IPR available from patent pool" vs Google offering indemnity against third party IPR claims. I believe everyone can agree that "open standards process"  is a requirement for an MTI video codec. Royalty free RAND terms are highly desired. The indemnity is just wishful thinking. I cannot think of a single codec patent pool that offer indemnity. I also do not see much difference between  "licenses to listed IPR available from patent pool" and "licenses to listed IPR are available from Google" as long as they are available under royalty free RAND terms. I doubt anybody will form the patent pool to collect no money.
_____________
Roman Shpount

 

I was giving examples like "royalty-free option for H.264 MPEG-LA" or "IP risk indemnification from Google" as things that would indicate real change in the IPR landscape, which is one of the major things driving the positions of the browser makers. Neither has happened. They're both equivalently "wishful thinking" at this point. If and when something changes, we should discuss what that means. Until then, I ask again: what's changed?

Matthew Kaufman
--------------030402060502000709040006-- From nobody Mon Nov 10 22:02:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126681AD44C for ; Mon, 10 Nov 2014 22:02:14 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkUAnZ6OELVX for ; Mon, 10 Nov 2014 22:02:11 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8253E1ACD85 for ; Mon, 10 Nov 2014 22:02:11 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Nov 2014 16:32:09 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 58DCBFFEDC for ; Tue, 11 Nov 2014 16:32:08 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AL6EroOkVxDh for ; Tue, 11 Nov 2014 16:32:07 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 2D7FEFFDBC for ; Tue, 11 Nov 2014 16:32:07 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 1A45E80470; Tue, 11 Nov 2014 16:32:07 +1030 (ACDT) Date: Tue, 11 Nov 2014 16:32:07 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141111060206.GT8092@hex.shelbyville.oz> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <54619EC4.2070802@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54619EC4.2070802@matthew.at> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P4a5SiHUjSMOG4EjIvOJqANbbIQ Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 06:02:14 -0000 On Mon, Nov 10, 2014 at 09:29:40PM -0800, Matthew Kaufman wrote: > On 11/10/2014 4:25 PM, Roman Shpount wrote: > >On Mon, Nov 10, 2014 at 4:55 PM, Matthew Kaufman >> wrote: > > > > We may be tired of this, but it isn't like we have a royalty-free > > option for H.264 MPEG-LA or IP risk indemnification from Google.. > > So what's changed for the browser makers? > > > > > >May be I am missing something, but MPEG-LA does not provide IP risk > >indemnification for H.264. All they sell is a very limited license to the > >patent pool from the group members. > > I am not my employer's lawyers, nor am I the lawyers for any of the other > folks who've spoken up about the IPR issues over the years. But these folks > apparently feel that there's something different between "specification > developed in an open standards process" + "licenses to listed IPR available > from patent pool" and "some code Google says is free" for whatever reasons > they have. Something other than "we invested a lot in being a member of that pool, and a whole bunch more in buying a company with lots of H.264 patents which remain outside of it"? > You'd have to ask them to see why that's different. If you do that, ask them what's different about bottled water too. I've always been curious about that. From nobody Mon Nov 10 22:48:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E311A88E6 for ; Mon, 10 Nov 2014 22:48:31 -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 KAUTHgbSlq3g for ; Mon, 10 Nov 2014 22:48:29 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073841A6EE8 for ; Mon, 10 Nov 2014 22:48:29 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id fp1so9559241pdb.9 for ; Mon, 10 Nov 2014 22:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=luCizQ1H2p5DeD4xkmxbbwPw43DHQfcoGFmcurg3cc4=; b=VKoIY1MbEskN+IHru8WLMwC1/yaO+mEyRAVU+zBctXujlqmlKXtS0GgmHJXdDeGlwp BAIFNrUd1YKcDCC51oXm1Zf4Qy6dgWjciwyWyUO+L+1AVV64pzuUgAPRQGqkXy5AuiNj EAIPsMjNmP5LvIeulezJ1DAgO9xVKaevN2nRHcTLFL2fN8UNOIw8aqLMFGwt9Dh0CqpS 0id0vkipHk7nkaK7fD4jJru6UFCElwjf8SoheVDLKNTtRT4dD2Uc6+qMieN/WrceFpCQ pdlf2Zt9WCWhBYxhxWzevyDXKmg4DraAqlXkgGw70E77rGmartBjqLv91F+dNx4AMkBp uUGA== X-Received: by 10.70.35.1 with SMTP id d1mr9498146pdj.141.1415688508316; Mon, 10 Nov 2014 22:48:28 -0800 (PST) Received: from [10.219.121.254] ([166.170.51.122]) by mx.google.com with ESMTPSA id yw3sm18244183pbc.88.2014.11.10.22.48.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 22:48:26 -0800 (PST) References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: <5461A019.6030108@alvestrand.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> X-Mailer: iPhone Mail (12B411) From: Bernard Aboba Date: Mon, 10 Nov 2014 20:48:23 -1000 To: Harald Alvestrand Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hxEYHYE1DJbd_fypZoOR1sohLHo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 06:48:31 -0000 > On Nov 10, 2014, at 7:35 PM, Harald Alvestrand wrot= e: >=20 >> On 11/10/2014 07:19 PM, Bernard Aboba wrote: >> I do not get it either. It seems like mobile apps (which count as devices= ) using a WEBRTC stack now have to include both codecs regardless of whether= they need them. Do we really think app developers will pay attention? Why s= hould they? >=20 > Because they can then depend on interoperability with other non-browsers? [BA] Isn't the non-browser in question the mobile app the developer wrote? M= ost of these apps only need to interop with the app on another platform, a b= rowser app and/or their own service. So they typically only need one codec o= r the other not both.= From nobody Tue Nov 11 00:49:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378161A8966 for ; Tue, 11 Nov 2014 00:49:24 -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 BMuVSTDTuGz1 for ; Tue, 11 Nov 2014 00:49:22 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425BA1A895B for ; Tue, 11 Nov 2014 00:49:22 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id s18so9037631lam.41 for ; Tue, 11 Nov 2014 00:49:20 -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=yme3bcJEHDUG9O8LtlgmaMr/zCNreWUeDlsfse+Lxdw=; b=UGZveGbbHZ2HbSOGBqjebOeY1VCeaXVx10mu/nJIeK0mXkJrFMAghf/cOL04yS4Xad Ui9CBLbDlz28m2krTNBDuxJUJjyLpa9iVr3gy3kcdnYjFoky/mP4PHdVvW2puNE31x6Y 9iz8DtnwGL4OUJiAdCx/75iQV4FaqDhuTMLL5XFNC9/Oj1O/jpt1k0qXE60k0dHTYrL2 JpIT5YHUMcy5ztQbFmYIGxxilR9259zUHe9ebe82rGfjszldtbK8rcSQuDBO+5mwgFMi 61rUIbERCL/NjcKPJW2TXjB2BcwB2xDrzRmWHCJNnpI6K2J9U7Nx79MECiDewEBVLI73 eCBw== MIME-Version: 1.0 X-Received: by 10.112.180.198 with SMTP id dq6mr34278743lbc.56.1415695760741; Tue, 11 Nov 2014 00:49:20 -0800 (PST) Received: by 10.25.77.208 with HTTP; Tue, 11 Nov 2014 00:49:20 -0800 (PST) In-Reply-To: <20141111043812.629e8f9f@lminiero> References: <20141111043812.629e8f9f@lminiero> Date: Tue, 11 Nov 2014 09:49:20 +0100 Message-ID: From: Victor Pascual Avila To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kkyagfEZMW51ULjbxOGIfr4nPaw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 08:49:24 -0000 On Tue, Nov 11, 2014 at 4:38 AM, Lorenzo Miniero wrote: > On Mon, 10 Nov 2014 19:26:56 -0800 > Martin Thomson wrote: > >> I'm not sure that this is the comment Ted was looking for here. >> >> I don't think that we need this document, as Keith observes, a short >> note in -overview suffices: >> >> A gateway is a webrtc endpoint or webrtc-compatible endpoint that >> forwards stuff (media or data) to other endpoints. This is useful. >> > > > Having worked on one I think we need more than that, so I'd support such > a document. There are several things that can go wrong (see the stuff > we're discussing in STRAW, for instance) so gateways are indeed > special IMHO. Agree. Some examples: https://tools.ietf.org/html/draft-ietf-straw-b2bua-stun-00 https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-02 https://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-00 -Victor From nobody Tue Nov 11 00:55:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2671AD5F0 for ; Tue, 11 Nov 2014 00:55:03 -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 LtSjHjPRo21m for ; Tue, 11 Nov 2014 00:55:01 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C0D1A8549 for ; Tue, 11 Nov 2014 00:55:01 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id 10so7255690lbg.14 for ; Tue, 11 Nov 2014 00:54:59 -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=iwNOki9MPyA2OmNuHg6xHWvFoDlFhOJj7bKPa/JDIgI=; b=CwnGAReUPf1E3bglTLYg3tLQBcW6u3BZJ+fWjy0QgG7EyXNf0yCPil/63LUgmkZwUP e/+oe3w81dWghbmtk7cTFIhUGWRsCrx7uV9KqV9YNVS6acFyo2ohLGnng/d72Za13jTA 39CrJLmD9Y5Zzok5AOmqTV7dozl5ekq4BTzp6fkqPX3cSS55L+tcVDmrPGWz7dGFl/BK 0U0PXNzD3LANdJ3s0su1ff+jbljhkGIWefsYX5OS0VqwYQCprNDRXzb0T9e9V6pJSSJA V8mw/epeXEd67m5H7a7yLqZbd3fcnClt9J1ip0X3uWYvKciQO8D3r7HQuGmkmuoDZAsA RGxQ== MIME-Version: 1.0 X-Received: by 10.152.1.130 with SMTP id 2mr1247343lam.89.1415696099323; Tue, 11 Nov 2014 00:54:59 -0800 (PST) Received: by 10.25.77.208 with HTTP; Tue, 11 Nov 2014 00:54:59 -0800 (PST) In-Reply-To: References: <54601E19.8080203@nostrum.com> Date: Tue, 11 Nov 2014 09:54:59 +0100 Message-ID: From: Victor Pascual Avila To: Mary Barnes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cCakAYSN0kISltGcAmoJu0W8OeY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 08:55:03 -0000 +1 On Mon, Nov 10, 2014 at 9:57 PM, Mary Barnes w= rote: > I agree with the proposal - I think this is as close as we will ever get = on > an agreed way forward. > > Regards, > Mary. > > On Sun, Nov 9, 2014 at 8:08 PM, Adam Roach wrote: >> >> It appears that we're running headlong into another in-person discussion >> about the relative merits of H.264 and VP8 as MTI candidates again. Matt= hew >> Kaufman has argued that this conversation is doomed to failure because n= o >> major player has been willing to change their position. The players he c= ited >> were Cisco, Google, and Mozilla, who have represented the three main >> positions on this topic pretty effectively. Although we participate as >> individuals in the IETF, I think it's fair to say that the last time we = had >> this conversation, the median positions of participants from those compa= nies >> were "H.264 or die", "VP8 or die", and "either one as long as it's *only= * >> one", respectively. >> >> However, even if nothing else has changed, I think one salient point may >> have become quite important: we're all tired of this. Over two years ago= , in >> March of 2012 -- before I even had an particular interest in WebRTC exce= pt >> as a user -- this had already become such a long-running acrimonious deb= ate >> that I was brought in as a neutral third party to try to mediate. I'm we= ary >> of this argument; and, with the exception of a few aggressive voices who >> seem to enjoy the battle more than the outcome, I'm hearing a similar >> exhausted timbre in the messages of other participants (and the key >> stakeholders in particular). >> >> So, I want to float a proposal that represents a compromise, to see if w= e >> can finally close this issue. First, I want to start out by reiterating = a >> well-worn observation that the hallmark of a good compromise is that nob= ody >> leaves happy, but everyone can force themselves to accept it. And I want= to >> be crystal clear: the solution I'm about to float just barely clears the= bar >> of what I think I can live with. This proposal is based on an observatio= n >> that the dominating issues in this conversation remain those of licensin= g, >> not technology or even incumbency. I=E2=80=99ve discussed this extensive= ly with >> representatives of all three of the players I mention above, and they ar= e >> willing to sign on. >> >> This proposal is based on the definitions of "WebRTC User Agent", "WebRT= C >> device", and "WebRTC-compatible endpoint" in section 2.2 of >> draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows: >> >> WebRTC User Agents MUST implement both VP8 and H.264. >> >> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence >> arises that one of the codecs is available for use on a royalty-free bas= is, >> such as all IPR declarations known for the codec being of (IETF) >> Royalty-Free or (ISO) type 1, the IETF will change this normative statem= ent >> to indicate that only that codec is required. For absolute, crystal clar= ity, >> this provision is only applicable to WebRTC devices, and not to WebRTC U= ser >> Agents. >> >> WebRTC-compatible endpoints are free to implement any video codecs they >> see fit, if any (this follows logically from the definition of >> "WebRTC-compatible endpoint," and doesn't really need to be stated, but = I >> want this proposal to be as explicit as possible). >> >> >> This has the property of ensuring that all devices and user agents can >> work with all devices and user agents. This has the property of giving n= o >> one exactly what they want. And, unlike any other previous plans, this h= as >> the property of coming to a decision while maintaining pressure on the o= nly >> parties who can make a change in the IPR landscape to do so. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Victor Pascual =C3=81vila From nobody Tue Nov 11 06:16:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844D51A89E9 for ; Tue, 11 Nov 2014 06:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4T7s-_gD4hC for ; Tue, 11 Nov 2014 06:16:25 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3C61A1A9F for ; Tue, 11 Nov 2014 06:16:24 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 11 Nov 2014 09:16:19 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.03.0174.001; Tue, 11 Nov 2014 09:16:18 -0500 From: Andrew Allen To: "adam@nostrum.com" , "ron@debian.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/ItBvCDjc5Yj2EadELDNEhEwy5xZkIUAgAEHJ4CAAONbRQ== Date: Tue, 11 Nov 2014 14:16:17 +0000 Message-ID: In-Reply-To: <54611529.7010007@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6kW-lPRYa1ztzRbqzguiGta1ImA Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 14:16:28 -0000 Adam "In terms of what would constitute "compelling evidence", that's going to=20 have to be something that the working group (or some successor group,=20 depending on timing) comes to consensus around" If this compromise was to move forward I think any "compelling evidence", i= s likely to be many years down the road (things will likely need to play ou= t in the courts first etc) which means that the RTCweb group likely doesn't= exist anymore or is by then a rump group that doesn't have the broad indus= try participation that we have now. Would we really go through the process to constitute a new WG just in order= to debate whether there is "compelling evidence"? I certainly would have a big concern if a much smaller group like IESG or a= rump remnants of RTCweb were in the end to make such a determination witho= ut a full long (months) high profiled public discussion. Also a BoF would n= ot in my view be appropriate to make this determination either. So if we go this approach aren't we effectively mandating both codecs for R= TCweb 1.0 with the possibility that in any future RTCweb 2.0 we might revis= it that decision? We need to be cast iron now about the process for revisiting this if this g= oes forward and also with some guidance as to what developments are appropr= iate to trigger revisiting it, as we can't have someone just propose at eve= ry IETF to reopen this discussion until they get the decision they want. Andrew ----- Original Message ----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Monday, November 10, 2014 02:42 PM Eastern Standard Time=0A= To: Ron ; rtcweb@ietf.org Subject: Re: [rtcweb] MTI Video Codec: a novel proposal Ron: You are correct in that the IETF doesn't take a position on the validity=20 of IPR declarations, and I'd like to thank you for bringing the topic up=20 so that I could clarify the proposal. Rather than evaluating the=20 *validity* of declarations, we would be evaluating the licensing=20 statements associated with those declarations (where applicable). In terms of what would constitute "compelling evidence", that's going to=20 have to be something that the working group (or some successor group,=20 depending on timing) comes to consensus around. I believe that examples=20 of such situations would include things like "MPEG-LA announces=20 non-discriminatory, royalty-free H.264 licensing for WebRTC" or "ISO=20 publishes VP8 specification with only Type-1 IPR declarations". With regards to bad actors' impact on the process, I fear this is an=20 unfortunate consequence of international IPR law as it is currently=20 defined that we are not in a position to fix. The best we can hope for=20 is that the associated parties recognize the goodwill implications of=20 standing in the way of progress, and the potential implications of=20 developing bad blood between their company and the rest of the standards=20 community. It's not awesome, but it's better than anything else that I've seen=20 proposed so far. /a On 11/9/14 18:00, Ron wrote: > Hi Adam, > > I do need to say that I really appreciate the effort you've put into > trying to help guide this discussion, both previously and now. You > speak an uncommon amount of good common sense. > > It's not clear to me exactly how you expect this part to work though: > > On Sun, Nov 09, 2014 at 04:08:25PM -1000, Adam Roach wrote: >> 2. WebRTC devices MUST implement both VP8 and H.264. If compelling >> evidence arises that one of the codecs is available for use on a >> royalty-free basis, such as all IPR declarations known for the codec >> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change >> this normative statement to indicate that only that codec is >> required. For absolute, crystal clarity, this provision is only >> applicable to WebRTC devices, and not to WebRTC User Agents. > What would constitute "compelling evidence" in this context? > > Since the IETF doesn't take any position on the validity of IPR > declarations, I'm not seeing how the conditional clause here can > be anything but a no-op that would be essentially impossible to > trigger. > > There are plenty of proposed standards which have IPR declarations > made against them, which pretty much everyone who has analysed them > in any detail agree are utterly bogus and inapplicable, but for > which the organisation which declared them refuses to withdraw. > > What am I missing that would encourage different behaviour to that > in this case? > > Cheers, > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Nov 11 11:39:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F00C1A883D for ; Tue, 11 Nov 2014 11:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QwehdfdJmeN for ; Tue, 11 Nov 2014 11:39:23 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 41C8F1A883B for ; Tue, 11 Nov 2014 11:39:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4AD177C0045; Tue, 11 Nov 2014 20:39:22 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phh23hje6i8C; Tue, 11 Nov 2014 20:39:21 +0100 (CET) Received: from [IPv6:2001:67c:370:160:4805:b828:f652:a1bd] (t2001067c037001604805b828f652a1bd.wireless.v6.meeting.ietf.org [IPv6:2001:67c:370:160:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id A8B4F7C0034; Tue, 11 Nov 2014 20:39:20 +0100 (CET) Message-ID: <546265E3.7060300@alvestrand.no> Date: Tue, 11 Nov 2014 11:39:15 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bernard Aboba References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> In-Reply-To: <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8OWy-KGd7tLyegGoGjPDZ7FkYHQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 19:39:26 -0000 On 11/10/2014 10:48 PM, Bernard Aboba wrote: > > > >> On Nov 10, 2014, at 7:35 PM, Harald Alvestrand = wrote: >> >>> On 11/10/2014 07:19 PM, Bernard Aboba wrote: >>> I do not get it either. It seems like mobile apps (which count as dev= ices) using a WEBRTC stack now have to include both codecs regardless of = whether they need them. Do we really think app developers will pay attent= ion? Why should they? >> Because they can then depend on interoperability with other non-browse= rs? > [BA] Isn't the non-browser in question the mobile app the developer wro= te? Most of these apps only need to interop with the app on another platf= orm, a browser app and/or their own service. So they typically only need = one codec or the other not both. I'm pretty certain that will be the most common scenario. I'm also pretty certain this will not be the only scenario; there will be services that are usable from multiple applications. I don't want to foreclose that possibility. --=20 Surveillance is pervasive. Go Dark. From nobody Tue Nov 11 11:46:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4A1A8851 for ; Tue, 11 Nov 2014 11:46:08 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csIk6YoFIOCW for ; Tue, 11 Nov 2014 11:46:07 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 87D201A8875 for ; Tue, 11 Nov 2014 11:46:06 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail06.adl2.internode.on.net with ESMTP; 12 Nov 2014 06:16:05 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 7F50EFFEDC for ; Wed, 12 Nov 2014 06:16:04 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CktybTogdJmK for ; Wed, 12 Nov 2014 06:16:03 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 8BD32FFA19 for ; Wed, 12 Nov 2014 06:16:03 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7996080470; Wed, 12 Nov 2014 06:16:03 +1030 (ACDT) Date: Wed, 12 Nov 2014 06:16:03 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141111194603.GU8092@hex.shelbyville.oz> References: <54611529.7010007@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G7qQm0sq5_fWUjOKBZvfPYYJPAA Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 19:46:09 -0000 On Tue, Nov 11, 2014 at 02:16:17PM +0000, Andrew Allen wrote: > > Adam > > "In terms of what would constitute "compelling evidence", that's going to > have to be something that the working group (or some successor group, > depending on timing) comes to consensus around" > > If this compromise was to move forward I think any "compelling > evidence", is likely to be many years down the road (things will > likely need to play out in the courts first etc) which means that the > RTCweb group likely doesn't exist anymore or is by then a rump group > that doesn't have the broad industry participation that we have now. I think Adam clarified this already too. The shell game of IP law effectively makes it impossible to consider questions of validity, and that includes not just the IETF, but court rulings too (since another court in another jurisdiction could rule differently and both judgements could stand simultaneously). So the only thing we can look at is the formal declarations that have been made (and not withdrawn). In that environment, the only court ruling that might be relevant would be an injunction to withdraw a blatantly false and anti-competitive declaration, and I'm not aware of any such cases actually being prosecuted. None of the court cases people have currently indicated would be directly relevant to this question for us afaics. > Would we really go through the process to constitute a new WG just in > order to debate whether there is "compelling evidence"? > > I certainly would have a big concern if a much smaller group like IESG > or a rump remnants of RTCweb were in the end to make such a > determination without a full long (months) high profiled public > discussion. Also a BoF would not in my view be appropriate to make > this determination either. > > So if we go this approach aren't we effectively mandating both codecs > for RTCweb 1.0 with the possibility that in any future RTCweb 2.0 we > might revisit that decision? > > We need to be cast iron now about the process for revisiting this if > this goes forward and also with some guidance as to what developments > are appropriate to trigger revisiting it, as we can't have someone > just propose at every IETF to reopen this discussion until they get > the decision they want. I thought about the question of what the window for triggering this would be too, but it seemed like a relatively small yak to shave if we had in-principle agreement on the other details of it (and quite pointless to worry about if we didn't). Given that the examples Adam elaborated on (H.264 becomes RF, VP8 is certified RF by ISO) are possibly the only realistic triggers here unless something Really surprising happens, we kind of have a natural bound on this being decided anyway. Either the H.264 cabal gets its shit together before the ISO process is completed, and tips it in their favour, or we find out whether what comes out of the ISO will do so or not. It doesn't seem likely that much will happen after that point until declared IPR expires, or the IETF forms a video codec WG and gives us all an Opus for video. Possibly the only outcome that would have our bowl of petunias thinking "Oh no, not again" would be if team H.264 bottles it on the eve of an RF announcement for VP8 by ISO and declares their codec to be also RF at the same time. Which might be good for the world in general, but would leave us back at a stalemate again over our decision trigger. Whether it's worth adding some "you acted in bad faith, so you lose" clause to cover that outcome, or whether we just say "everybody has already implemented both, and now they're both free so stuff it we can keep both" I'm undecided on. That would kind of depend on how strongly someone might argue the cost of supporting both if both were RF. And maybe how much we think that might apply positive pressure on the H.264 patent holders to act in a timely way if they are going to ever act at all. Either way, the natural bound would seem to be "This has to happen before WGLC on the relevant documents" since after that they become immutable unless we publish a superseding proposed standard. It will be this group that gets to decide if there is anything we should wait before before taking that step. What any future group decides is a matter for them, we can't constrain them for all time here and now. Do you see some other way this might unexpectedly come unstuck? > ----- Original Message ----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Monday, November 10, 2014 02:42 PM Eastern Standard Time > To: Ron ; rtcweb@ietf.org > Subject: Re: [rtcweb] MTI Video Codec: a novel proposal > > Ron: > > You are correct in that the IETF doesn't take a position on the validity > of IPR declarations, and I'd like to thank you for bringing the topic up > so that I could clarify the proposal. Rather than evaluating the > *validity* of declarations, we would be evaluating the licensing > statements associated with those declarations (where applicable). > > In terms of what would constitute "compelling evidence", that's going to > have to be something that the working group (or some successor group, > depending on timing) comes to consensus around. I believe that examples > of such situations would include things like "MPEG-LA announces > non-discriminatory, royalty-free H.264 licensing for WebRTC" or "ISO > publishes VP8 specification with only Type-1 IPR declarations". > > With regards to bad actors' impact on the process, I fear this is an > unfortunate consequence of international IPR law as it is currently > defined that we are not in a position to fix. The best we can hope for > is that the associated parties recognize the goodwill implications of > standing in the way of progress, and the potential implications of > developing bad blood between their company and the rest of the standards > community. > > It's not awesome, but it's better than anything else that I've seen > proposed so far. > > /a > > On 11/9/14 18:00, Ron wrote: > > Hi Adam, > > > > I do need to say that I really appreciate the effort you've put into > > trying to help guide this discussion, both previously and now. You > > speak an uncommon amount of good common sense. > > > > It's not clear to me exactly how you expect this part to work though: > > > > On Sun, Nov 09, 2014 at 04:08:25PM -1000, Adam Roach wrote: > >> 2. WebRTC devices MUST implement both VP8 and H.264. If compelling > >> evidence arises that one of the codecs is available for use on a > >> royalty-free basis, such as all IPR declarations known for the codec > >> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change > >> this normative statement to indicate that only that codec is > >> required. For absolute, crystal clarity, this provision is only > >> applicable to WebRTC devices, and not to WebRTC User Agents. > > > > What would constitute "compelling evidence" in this context? > > > > Since the IETF doesn't take any position on the validity of IPR > > declarations, I'm not seeing how the conditional clause here can > > be anything but a no-op that would be essentially impossible to > > trigger. > > > > There are plenty of proposed standards which have IPR declarations > > made against them, which pretty much everyone who has analysed them > > in any detail agree are utterly bogus and inapplicable, but for > > which the organisation which declared them refuses to withdraw. > > > > What am I missing that would encourage different behaviour to that > > in this case? > > > > Cheers, > > Ron From nobody Tue Nov 11 11:47:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E17C1A88DD for ; Tue, 11 Nov 2014 11:47:12 -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 tbGlraafSBDn for ; Tue, 11 Nov 2014 11:47:09 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013011A8851 for ; Tue, 11 Nov 2014 11:47:09 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id x19so11761979ier.5 for ; Tue, 11 Nov 2014 11:47:08 -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 :content-transfer-encoding; bh=3PmNvcVkih37LBphCwrujzGm2jk7END4NJnBKhM1PbE=; b=a4B+Z7ym2G4/5LFjHSOMR1O9XCacV8Eq6PxFOrBbxZeriXo/smjW4qcLNWl78vIAFV g4Oq/tSuprdCcrSvzS3CTd4QbA47Ni1Y31ok4HNIG2aNAzyFndlrDz0X8GBL5We78vnp tG+TCWpsRRC/hUr41dZCwIH+HD3m1RjkQJ0W9bdy9kMc4vQuF3SRIeWaDms1IB0WGqcd 20iTGxDIEq+tQmLV6SkCx+M6aamGw/Xz020LiwJFGVtpcM6DHWZzLdbWxtMC7B31W3gC /2marHbUfol9ZhKUZvG+pAaNNp5Pqplyp5F/lmiT5vu+R8NcB2p9QRPTiDnBnLw7i3xo Z8HA== X-Gm-Message-State: ALoCoQnzdP7CeLKpAFZsSLJbJAEpk/qvTMzxP5SueCRUfHh7YVIpPy6bM4MoVz/5nts6wm4Zn0yJ X-Received: by 10.42.27.9 with SMTP id h9mr45429219icc.32.1415735228415; Tue, 11 Nov 2014 11:47:08 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 64sm10194447iol.37.2014.11.11.11.47.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 11:47:07 -0800 (PST) Message-ID: <546267B9.8020605@andyet.net> Date: Tue, 11 Nov 2014 12:47:05 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Harald Alvestrand , Bernard Aboba References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> <546265E3.7060300@alvestrand.no> In-Reply-To: <546265E3.7060300@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G4DNkx2VON-V35NTSUjg5leS6EY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 19:47:12 -0000 On 11/11/14, 12:39 PM, Harald Alvestrand wrote: > On 11/10/2014 10:48 PM, Bernard Aboba wrote: >> >>> On Nov 10, 2014, at 7:35 PM, Harald Alvestrand wrote: >>> >>>> On 11/10/2014 07:19 PM, Bernard Aboba wrote: >>>> I do not get it either. It seems like mobile apps (which count as devices) using a WEBRTC stack now have to include both codecs regardless of whether they need them. Do we really think app developers will pay attention? Why should they? >>> Because they can then depend on interoperability with other non-browsers? >> [BA] Isn't the non-browser in question the mobile app the developer wrote? Most of these apps only need to interop with the app on another platform, a browser app and/or their own service. So they typically only need one codec or the other not both. > I'm pretty certain that will be the most common scenario. > > I'm also pretty certain this will not be the only scenario; there will > be services that are usable from multiple applications. > > I don't want to foreclose that possibility. What is a non-browser mobile app or native app in terms of the entity taxonomy from draft-ietf-rtcweb-overview? Is it a WebRTC device or a WebRTC-compatible endpoint? It's nice that people don't want to foreclose possibilities, but I think it's important to recognize that one person's desire might turn out to be someone else's significant work effort. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Nov 11 11:56:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EAE1A8912 for ; Tue, 11 Nov 2014 11:56:25 -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 FMnrV1VqKnie for ; Tue, 11 Nov 2014 11:56:21 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30B81A19E2 for ; Tue, 11 Nov 2014 11:56:20 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id 10so8027383lbg.7 for ; Tue, 11 Nov 2014 11:56:19 -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=9dOlHK2z8PotG7zJyMU0/AvvVLqDALThTzSGHBSpaDQ=; b=TaVTpQ6/jNRd9iKpVRaQEfqfOntvnC0XIS1n6Wy0YUVidrJ4hpBMmWiCN9dlIWCpys c0IWbRYwCYfemxUU5MWj8DzbZnq1ruCAz/kOhrQzXI0VU2Q9cL67mi5WaNXr1hj5fiov 5jzZ902IG/2A15nVWMX+caEHTphsQfu+neZUKl2f1M7mfCY9WiXEURmrCjw5PMkwEVWK /YcZHsyr3p8Xkaptfj5Su3hJlS6vy9A0eSgq7MIR80BBGU8yegA4lH/DxZzoheo/UVPn AK3IB85mFSznPaytWJcNVTdxL7/Xs0UNiyhp0M0V3ovqh9fkOHgRErJh5uuku4tNKrMI bVCw== MIME-Version: 1.0 X-Received: by 10.152.204.99 with SMTP id kx3mr38351145lac.53.1415735779123; Tue, 11 Nov 2014 11:56:19 -0800 (PST) Received: by 10.25.215.33 with HTTP; Tue, 11 Nov 2014 11:56:18 -0800 (PST) In-Reply-To: References: <54611529.7010007@nostrum.com> Date: Tue, 11 Nov 2014 11:56:18 -0800 Message-ID: From: Martin Thomson To: Andrew Allen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fhre_aefuflO_2rmymSka_M13O4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 19:56:25 -0000 On 11 November 2014 06:16, Andrew Allen wrote: > Would we really go through the process to constitute a new WG just in order to debate whether there is "compelling evidence"? I think that all we can do right now is try to establish what the intent is. Whether any future effort happens will depend on whether there is sufficient will (and a venue) to have that discussion at that time. We can't predict that that will happen, so I don't think that there is much value in spending a whole lot of time on the subject. Getting the text of a statement like this precisely right is going to be tricky, but I suggest that we give Adam a little discretion in producing it. From nobody Tue Nov 11 12:13:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D551A89AA for ; Tue, 11 Nov 2014 12:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IEyj-BgEQ0x for ; Tue, 11 Nov 2014 12:13:29 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB211A89B9 for ; Tue, 11 Nov 2014 12:13:27 -0800 (PST) Received: (qmail 68111 invoked from network); 11 Nov 2014 20:13:25 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 14860 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Nov 2014 20:13:25 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 47A5B18A0EC9; Tue, 11 Nov 2014 20:13:17 +0000 (GMT) Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id EEB7018A0C4D; Tue, 11 Nov 2014 20:13:16 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_861D5092-5E72-46DF-8FF8-178F5876E71A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: tim panton In-Reply-To: <546267B9.8020605@andyet.net> Date: Tue, 11 Nov 2014 20:13:16 +0000 Message-Id: <4E528337-ED7A-41ED-B196-A4CF6C4D84DF@phonefromhere.com> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> <546265E3.7060300@alvestrand.no> <546267B9.8020605@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UBlFEy76-BiMprTUpHoGYZrJyAg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 20:13:33 -0000 --Apple-Mail=_861D5092-5E72-46DF-8FF8-178F5876E71A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 Nov 2014, at 19:47, Peter Saint-Andre - &yet = wrote: > What is a non-browser mobile app or native app in terms of the entity = taxonomy from draft-ietf-rtcweb-overview? Is it a WebRTC device or a = WebRTC-compatible endpoint? If it implements all the wire protocol (DataChannel etc) including both = video codecs it is a WebRTC device. If it omits a protocol feature (or codec) but can usefully interoperate, = it is a WebRTC-compatible endpoint.=20 At least that=92s my reading. My personal preference would be to replace =91both=92 with =91either=92 = in the device rule, but I understand the thinking behind the =91both=92 phrasing. T.= --Apple-Mail=_861D5092-5E72-46DF-8FF8-178F5876E71A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 11 Nov 2014, at 19:47, Peter = Saint-Andre - &yet <peter@andyet.net> = wrote:

What is a non-browser mobile app or = native app in terms of the entity taxonomy from = draft-ietf-rtcweb-overview? Is it a WebRTC device or a WebRTC-compatible = endpoint?

If it implements all the wire protocol = (DataChannel etc) including both video codecs it is a WebRTC = device.
If it omits a protocol feature (or codec) but can = usefully interoperate, it is a WebRTC-compatible = endpoint. 
At least that=92s my = reading.

My personal preference would be to = replace =91both=92 with =91either=92 in the device rule, but I = understand
the thinking behind the =91both=92 = phrasing.

T.
= --Apple-Mail=_861D5092-5E72-46DF-8FF8-178F5876E71A-- From nobody Tue Nov 11 12:15:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892B81A90C7 for ; Tue, 11 Nov 2014 12:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2mrAwwSI16J for ; Tue, 11 Nov 2014 12:15:39 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E891A902E for ; Tue, 11 Nov 2014 12:14:36 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kx10so11295860pab.20 for ; Tue, 11 Nov 2014 12:14:35 -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=x+fcxxrmruIZr9q1PKvfHjvJ8G5SGcSEpDcO8oqYI10=; b=dUqprnevZATLLXP/k7sibMMQupFZcBMYsKab4VDVv16JtWN+JD7Cw6DcjLGPmEaMVe KKmeEKZfHZ/NffFrkFpwA9sEW/l5UMCRs+7RzIWTZRk0nYcNLjUfPSzyC87eS7XV9kQ3 VUyna28uwgvpcz6K7ZhQB8Kbj9lJa7zQlBWX8fkVle5LyNiUOqxDYEqtssYFKMQXk9Zn 8NPS0khTGy4ACBIo/GH9tqbOMAbm825XVOD+SyUPcgC5Fzwafyd03SpWS1SjWqDov5AF 177iglGFTVEwTz4cfFtpsn+JI7W+zH4EbgXoQ15Cp8O79uXSBSEcUfDtjn/uxH0/Y/GX 9AgA== MIME-Version: 1.0 X-Received: by 10.70.33.195 with SMTP id t3mr14567663pdi.135.1415736875820; Tue, 11 Nov 2014 12:14:35 -0800 (PST) Received: by 10.70.60.201 with HTTP; Tue, 11 Nov 2014 12:14:35 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Nov 2014 10:14:35 -1000 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bf18e58942e4a05079aedef Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d2ivHXo0TG91nSMCYkFGlOl6u8U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Death of a one-way stream (#76) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 20:15:41 -0000 --047d7bf18e58942e4a05079aedef Content-Type: text/plain; charset=UTF-8 here is one possible way ..... *New SDP Attributes : Media intent for Unidirectional Streams * m=recv-intent: m=send-intent: These attributes express the intent of the end-point generating the SDP on the send and receive state of the media stream : pause | end there is no default action other than what gets implied from the media direction and/or port number configuration. *For the use-case from Justin:* A and B are exchanging media. B stops A's stream, i.e., it no longer wants to receive media from A. However, B still wants to send media to A. So if B changes the m= line to a=inactive, B's stream stops as well. B's SDP Offer m=sendonly m=recv-intent:end [ saying i don't want inbound media on this m= line anymore] A's SDP Answer m=recvonly m=send-intent:end [ m= line can be recycled] *For the use-case from Martin:* where B disposes of their stream and can't resurrect it. A doesn't know that this is a terminal state for that media section. B's SDP Offer m=recvonly m=send-intent:end [ saying i will not be sending and thus m= line can be recycled] A's SDP Answer m=sendonly m=recv-intent:end *Use-case for temporarily pausing the stream* A and B are exchanging media. B pauses A's stream, However, B still wants to send media to A. B's SDP Offer m=sendonly m=recv-intent:pause A's SDP Answer m=recvonly m=send-intent:pause [ m= line cannot be recycled] Now B want's to start receiving media from A B's SDP Offer m=sendrecv [ bidirectional stream, overrides any unidirectional intents] A's SDP Answer m=sendrecv In this scheme the action is non-negotiable and thus has to be replied in the answer. Thanks Suhas Also to note, this attribute can be used at the media level or the source level. On Mon, Nov 10, 2014 at 5:09 PM, Martin Thomson wrote: > On 10 November 2014 18:52, Justin Uberti wrote: > > A and B are exchanging media. > > B stops A's stream, i.e., it no longer wants to receive media from A. > > However, B still wants to send media to A. > > So if B changes the m= line to a=inactive, B's stream stops as well. > > > Yep, and then there is the case where B disposes of their stream and > can't resurrect it. A doesn't know that this is a terminal state for > that media section. > --047d7bf18e58942e4a05079aedef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
here is one possible way .....=C2=A0

New SDP Attributes : Media intent for Unidirectiona= l Streams=C2=A0

m=3Drecv-intent: <action>
m=3Dsend-intent: <action>

These attributes express the int= ent of the end-point generating the SDP on the send and receive state of th= e media stream

&l= t;action> : pause | end

there is no default action other than what gets implied from the = media direction and/or port number configuration.=C2=A0


For the use-case from Justin:
=
A and B are exch= anging media.
B stops A's stream, i.e., it no longer wants to receive media from A= .
However, = B still wants to send media to A.
So if B changes the m=3D line to a=3Dinactive, B'= ;s stream stops as well.

B's SDP Offer
=C2=A0m=3Dsendonly
=C2=A0m=3Drecv-intent:end =C2=A0 [ saying i= don't want inbound media on this m=3D line anymore]

A's SDP Answer
m=3Drecvonly
m=3Dsend-in= tent:end =C2=A0 [ m=3D line can be recycled]


For the use-case from Martin:
where B disposes of their = stream and
= can't resur= rect it.=C2=A0 A doesn't know that this is a terminal state for<= br style=3D"font-family:arial,sans-serif;font-size:13px">that media section.

B's SDP Offer
=C2=A0m=3Drecvonly<= br>
=C2=A0m=3Dsend-intent:end =C2=A0 [ saying i will not be sendi= ng and thus m=3D line can be recycled]

A's SDP= Answer
=C2=A0m=3Dsendonly
=C2=A0m=3Drecv-inte= nt:end=C2=A0


Use-cas= e for temporarily pausing the stream
A and B are exchanging media.
B pauses A's stre= am,=C2=A0
H= owever, B still wants to send media to A.

B'= ;s SDP Offer
=C2=A0m= =3Dsendonly
=C2=A0m= =3Drecv-intent:pause
=
A's SDP Answ= er
=C2=A0m=3Drec= vonly
=C2=A0m=3Dsend-intent:pause [ m=3D line cannot be recycled]=

Now B want's to start receiving media from A<= /div>
B's SDP Offer
=C2=A0m=3Dsendrecv =C2=A0[ bidir= ectional stream, overrides any unidirectional intents]

=
A's SDP Answer
=C2=A0m=3Dsendrecv


In this scheme the action is non-negotia= ble and thus has to be replied in the answer.




Thanks
Suhas
=





=
Also to note, this attribute can be used at the media level or t= he source level.




On Mon, Nov 10, 201= 4 at 5:09 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 November= 2014 18:52, Justin Uberti <jubert= i@google.com> wrote:
> A and B are exchanging media.
> B stops A's stream, i.e., it no longer wants to receive media from= A.
> However, B still wants to send media to A.
> So if B changes the m=3D line to a=3Dinactive, B's stream stops as= well.


Yep, and then there is the case where B disposes of their stream and=
can't resurrect it.=C2=A0 A doesn't know that this is a terminal st= ate for
that media section.

--047d7bf18e58942e4a05079aedef-- From nobody Tue Nov 11 12:37:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3053F1A1BCE for ; Tue, 11 Nov 2014 12:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUBY3bj6p3Vj for ; Tue, 11 Nov 2014 12:37:41 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7872E1A913E for ; Tue, 11 Nov 2014 12:37:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8A23B7C0045; Tue, 11 Nov 2014 21:37:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwoXHJLG2G7u; Tue, 11 Nov 2014 21:37:10 +0100 (CET) Received: from [IPv6:2001:67c:370:160:4805:b828:f652:a1bd] (t2001067c037001604805b828f652a1bd.wireless.v6.meeting.ietf.org [IPv6:2001:67c:370:160:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id D7D767C0023; Tue, 11 Nov 2014 21:37:09 +0100 (CET) Message-ID: <54627370.30203@alvestrand.no> Date: Tue, 11 Nov 2014 12:37:04 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Bernard Aboba References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> <546265E3.7060300@alvestrand.no> <546267B9.8020605@andyet.net> In-Reply-To: <546267B9.8020605@andyet.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/72LPbUreOaNl8Sa7r8IvdNWfG7Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 20:37:43 -0000 On 11/11/2014 11:47 AM, Peter Saint-Andre - &yet wrote: > On 11/11/14, 12:39 PM, Harald Alvestrand wrote: >> On 11/10/2014 10:48 PM, Bernard Aboba wrote: >>> >>>> On Nov 10, 2014, at 7:35 PM, Harald Alvestrand >>>> wrote: >>>> >>>>> On 11/10/2014 07:19 PM, Bernard Aboba wrote: >>>>> I do not get it either. It seems like mobile apps (which count as >>>>> devices) using a WEBRTC stack now have to include both codecs >>>>> regardless of whether they need them. Do we really think app >>>>> developers will pay attention? Why should they? >>>> Because they can then depend on interoperability with other >>>> non-browsers? >>> [BA] Isn't the non-browser in question the mobile app the developer >>> wrote? Most of these apps only need to interop with the app on >>> another platform, a browser app and/or their own service. So they >>> typically only need one codec or the other not both. >> I'm pretty certain that will be the most common scenario. >> >> I'm also pretty certain this will not be the only scenario; there will >> be services that are usable from multiple applications. >> >> I don't want to foreclose that possibility. > > What is a non-browser mobile app or native app in terms of the entity > taxonomy from draft-ietf-rtcweb-overview? Is it a WebRTC device or a > WebRTC-compatible endpoint? The tendency in the room yesterday was to take the term "WebRTC device" and replace it with "WebRTC non-browser". Discussion also concluded that a mobile / native app is an example of a "WebRTC non-browser"; the term "WebRTC native application" was also suggested, but "WebRTC non-browser" had more support in the room. > > It's nice that people don't want to foreclose possibilities, but I > think it's important to recognize that one person's desire might turn > out to be someone else's significant work effort. Or - more relevant - one person's desire might turn out to be someone else's need to license codecs..... > > Peter > -- Surveillance is pervasive. Go Dark. From nobody Tue Nov 11 12:46:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9080C1A913E for ; Tue, 11 Nov 2014 12:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0b-Ikrcv31L for ; Tue, 11 Nov 2014 12:46:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A801A9108 for ; Tue, 11 Nov 2014 12:46:45 -0800 (PST) Received: from dhcp-b419.meeting.ietf.org (dhcp-b419.meeting.ietf.org [31.133.180.25]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sABKkdNi067836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 14:46:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <546275AF.10006@nostrum.com> Date: Tue, 11 Nov 2014 10:46:39 -1000 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ron , rtcweb@ietf.org References: <54611529.7010007@nostrum.com> <20141111194603.GU8092@hex.shelbyville.oz> In-Reply-To: <20141111194603.GU8092@hex.shelbyville.oz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1kWgXLfCzUQX3p5ZYgqTd7MICC4 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 20:46:46 -0000 On 11/11/14 09:46, Ron wrote: > Possibly the only outcome that would have our bowl of petunias thinking > "Oh no, not again" would be if team H.264 bottles it on the eve of an > RF announcement for VP8 by ISO and declares their codec to be also RF > at the same time. Which might be good for the world in general, but > would leave us back at a stalemate again over our decision trigger. This scenario certainly came up in thinking about the possible solution space. I simply filed it off into the "problems I wish I had" bucket and moved on. Given how remote this possibility is, I think we can cross this bridge when we come to it. /a From nobody Tue Nov 11 12:49:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FCF1AC3BA for ; Tue, 11 Nov 2014 12:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxHu0m3x1vBA for ; Tue, 11 Nov 2014 12:49:36 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9BB1AC3B5 for ; Tue, 11 Nov 2014 12:49:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 73B717C01F5 for ; Tue, 11 Nov 2014 21:49:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjU98k3MHfub for ; Tue, 11 Nov 2014 21:49:31 +0100 (CET) Received: from [IPv6:2001:67c:370:160:4805:b828:f652:a1bd] (t2001067c037001604805b828f652a1bd.wireless.v6.meeting.ietf.org [IPv6:2001:67c:370:160:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6015E7C01F3 for ; Tue, 11 Nov 2014 21:49:30 +0100 (CET) Message-ID: <54627654.5010408@alvestrand.no> Date: Tue, 11 Nov 2014 12:49:24 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030002050509090908090702" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qI8r3ds6Hn9bWWrjyOt9Z3hVnp8 Subject: Re: [rtcweb] Death of a one-way stream (#76) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 20:49:41 -0000 This is a multi-part message in MIME format. --------------030002050509090908090702 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit This seems like a wonderful spec, and clearly within the scope of MMUSIC. Once the 4 pages of boilerplate and the 9 sections of O/A semantics have been added, I think it would be a very reasonable draft, and will certainly be processed reasonably quickly - say, adopted before the end of 2015 and forwarded to the IESG before the end of 2016. (sorry if I seem a bit frustrated - I'm trying to figure out what to say about the status of MSID in MMUSIC). Or is it already in some spec that is in some stage of processing somewhere? On 11/11/2014 12:14 PM, Suhas Nandakumar wrote: > here is one possible way ..... > > *New SDP Attributes : Media intent for Unidirectional Streams > * > > m=recv-intent: > m=send-intent: > > These attributes express the intent of the end-point generating the > SDP on the send and receive state of the media stream > > : pause | end > > there is no default action other than what gets implied from the media > direction and/or port number configuration. > > > *For the use-case from Justin:* > A and B are exchanging media. > B stops A's stream, i.e., it no longer wants to receive media from A. > However, B still wants to send media to A. > So if B changes the m= line to a=inactive, B's stream stops as well. > > B's SDP Offer > m=sendonly > m=recv-intent:end [ saying i don't want inbound media on this m= > line anymore] > > A's SDP Answer > m=recvonly > m=send-intent:end [ m= line can be recycled] > > > *For the use-case from Martin:* > where B disposes of their stream and > can't resurrect it. A doesn't know that this is a terminal state for > that media section. > > B's SDP Offer > m=recvonly > m=send-intent:end [ saying i will not be sending and thus m= line > can be recycled] > > A's SDP Answer > m=sendonly > m=recv-intent:end > > > *Use-case for temporarily pausing the stream* > A and B are exchanging media. > B pauses A's stream, > However, B still wants to send media to A. > > B's SDP Offer > m=sendonly > m=recv-intent:pause > > A's SDP Answer > m=recvonly > m=send-intent:pause [ m= line cannot be recycled] > > Now B want's to start receiving media from A > B's SDP Offer > m=sendrecv [ bidirectional stream, overrides any unidirectional intents] > > A's SDP Answer > m=sendrecv > > > In this scheme the action is non-negotiable and thus has to be replied > in the answer. > > > > > Thanks > Suhas > > > > > > Also to note, this attribute can be used at the media level or the > source level. > > > > > On Mon, Nov 10, 2014 at 5:09 PM, Martin Thomson > > wrote: > > On 10 November 2014 18:52, Justin Uberti > wrote: > > A and B are exchanging media. > > B stops A's stream, i.e., it no longer wants to receive media > from A. > > However, B still wants to send media to A. > > So if B changes the m= line to a=inactive, B's stream stops as well. > > > Yep, and then there is the case where B disposes of their stream and > can't resurrect it. A doesn't know that this is a terminal state for > that media section. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------030002050509090908090702 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
This seems like a wonderful spec, and clearly within the scope of MMUSIC.

Once the 4 pages of boilerplate and the 9 sections of O/A semantics have been added, I think it would be a very reasonable draft, and will certainly be processed reasonably quickly - say, adopted before the end of 2015 and forwarded to the IESG before the end of 2016. (sorry if I seem a bit frustrated - I'm trying to figure out what to say about the status of MSID in MMUSIC).

Or is it already in some spec that is in some stage of processing somewhere?


On 11/11/2014 12:14 PM, Suhas Nandakumar wrote:
here is one possible way ..... 

New SDP Attributes : Media intent for Unidirectional Streams 

m=recv-intent: <action>
m=send-intent: <action>

These attributes express the intent of the end-point generating the SDP on the send and receive state of the media stream

<action> : pause | end

there is no default action other than what gets implied from the media direction and/or port number configuration. 


For the use-case from Justin:
A and B are exchanging media.
B stops A's stream, i.e., it no longer wants to receive media from A.
However, B still wants to send media to A.
So if B changes the m= line to a=inactive, B's stream stops as well.

B's SDP Offer
 m=sendonly
 m=recv-intent:end   [ saying i don't want inbound media on this m= line anymore]

A's SDP Answer
m=recvonly
m=send-intent:end   [ m= line can be recycled]


For the use-case from Martin:
where B disposes of their stream and
can't resurrect it.  A doesn't know that this is a terminal state for
that media section.

B's SDP Offer
 m=recvonly
 m=send-intent:end   [ saying i will not be sending and thus m= line can be recycled]

A's SDP Answer
 m=sendonly
 m=recv-intent:end 


Use-case for temporarily pausing the stream
A and B are exchanging media.
B pauses A's stream, 
However, B still wants to send media to A.

B's SDP Offer
 m=sendonly
 m=recv-intent:pause

A's SDP Answer
 m=recvonly
 m=send-intent:pause [ m= line cannot be recycled]

Now B want's to start receiving media from A
B's SDP Offer
 m=sendrecv  [ bidirectional stream, overrides any unidirectional intents]

A's SDP Answer
 m=sendrecv


In this scheme the action is non-negotiable and thus has to be replied in the answer.




Thanks
Suhas





Also to note, this attribute can be used at the media level or the source level.




On Mon, Nov 10, 2014 at 5:09 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 November 2014 18:52, Justin Uberti <juberti@google.com> wrote:
> A and B are exchanging media.
> B stops A's stream, i.e., it no longer wants to receive media from A.
> However, B still wants to send media to A.
> So if B changes the m= line to a=inactive, B's stream stops as well.


Yep, and then there is the case where B disposes of their stream and
can't resurrect it.  A doesn't know that this is a terminal state for
that media section.



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



-- 
Surveillance is pervasive. Go Dark.
--------------030002050509090908090702-- From nobody Tue Nov 11 13:02:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7441AC42C for ; Tue, 11 Nov 2014 13:02:43 -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 LYQsKMYhmAun for ; Tue, 11 Nov 2014 13:02:42 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525D41A7003 for ; Tue, 11 Nov 2014 13:02:31 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so12197387ieb.22 for ; Tue, 11 Nov 2014 13:02: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=tI1tibAwRtTV6HUPd+yL59cjpCYMBlwodpiufEshco4=; b=m1k5SL8v7XqDT/YPCqYPHsRHj3+VKuFXTpObu2iqUinGkMHz6n3us7AizCZkBYqgK1 DdTwoh5DnNv4zjEDX4vGyilhkLrzGP/TXJobDx/xKWexGCYpURy1m811TL5YejOpgXN0 EhxQFCdtN9ddPuV9YhqNjVAWvPlZ8a11cufollg5Zh2YIk+24p1RWibhEG2WJaLnrX1A iNMy3Q9CdSSD4soNbECIfYljyzAbG85B1i9n8ZrU962tEL7hKrW9fAK70RZ5oQvD3ufB RfJuW2S2noGF01eCs/T1BbMHZhXORdBLpwirk7ePWKr+Ee/RFOE5MreTsUzlYGNbUUb+ Es5Q== X-Gm-Message-State: ALoCoQmPBPtod1ezDnRISkuoqdtaVrmMMlDbZduw07BbWf4g+dZHXULhnOIaY2yYPVqIEDecs8N+ X-Received: by 10.50.103.3 with SMTP id fs3mr19794657igb.6.1415739750670; Tue, 11 Nov 2014 13:02:30 -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 fm2sm6838750igb.6.2014.11.11.13.02.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 13:02:30 -0800 (PST) Message-ID: <54627964.7040709@bbs.darktech.org> Date: Tue, 11 Nov 2014 16:02:28 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> <546265E3.7060300@alvestrand.no> <546267B9.8020605@andyet.net> <4E528337-ED7A-41ED-B196-A4CF6C4D84DF@phonefromhere.com> In-Reply-To: <4E528337-ED7A-41ED-B196-A4CF6C4D84DF@phonefromhere.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qvdMTdlP4peFS7n-ZYxQr7hqvd0 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 21:02:43 -0000 On 11/11/2014 3:13 PM, tim panton wrote: > My personal preference would be to replace ‘both’ with ‘either’ in the > device rule, but I understand > the thinking behind the ‘both’ phrasing. Same here. I would also prefer replacing "both" with "either" in the device rule. What is the practical benefit of forcing both codecs on non-browsers? If you proceed this way, won't most applications accept being declared non-compliant instead of investing the extra work/cost of implementing both codecs? Implementing both codecs only makes sense when you need interoperability between applications written by different authors. The same argument does not apply when both endpoints are written by the same author. Furthermore, I would argue that when separate authors want their applications to inter-operate they will have the necessary incentive to make that happen, with or without the specification dictating how it should be done. Another spin on this would be to say: all libraries/platforms (abstraction layers used to write applications) must implement both codecs, whereas applications (end-users) can implement as many codecs as they'd like. Gili From nobody Tue Nov 11 13:13:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CC61ACDA8 for ; Tue, 11 Nov 2014 13:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBwP3FQUq-hK for ; Tue, 11 Nov 2014 13:13:12 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B89B1ACDAA for ; Tue, 11 Nov 2014 13:13:12 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id w7so8405039qcr.12 for ; Tue, 11 Nov 2014 13:13:11 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=VnGEbIDSd9PH2aDC4SEB8SyJkQDDvZbx5vR5nB4Cih0=; b=ahnlXIE444UNEujrjaArG2/NfkEM+hvfsfVtqxxXOqBXkTNCcmCItNkJ377zKRlOZB AK4uWbWsclbvW9ZMRAG+MD4PUh3F02cQfQGLo9Nt3AzIINqVXdw6yESWCWy0ZJwhYoQX IHDHolYvccPeFfwQzXZgNp/V+23JWKoRR3AofehWrkKj4n94Al1lumowe4ZVnPdw3KFo JMsoqKmVIheCgFaUdko5CRBiAzZoYxqWiAoSCoIWUvFNPUegr8unpeDVaoMr/0wM7cMR /PGQdWDo1nOzrrwGyGhSil65EMzfov05nGGn6ESZmIh5Y5T5Pv+5fl6D/ftmEoPICAW4 8J+g== X-Gm-Message-State: ALoCoQmFWarNWvToGtnrYfvc7sQrDsQhYTQPZO9Ti1FdoCfRiUJ7NCVpPWXFCNSilgkC1MgUNweA X-Received: by 10.224.53.132 with SMTP id m4mr6825391qag.85.1415740391342; Tue, 11 Nov 2014 13:13:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.49.100 with HTTP; Tue, 11 Nov 2014 13:12:51 -0800 (PST) In-Reply-To: <54627964.7040709@bbs.darktech.org> References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> <546265E3.7060300@alvestrand.no> <546267B9.8020605@andyet.net> <4E528337-ED7A-41ED-B196-A4CF6C4D84DF@phonefromhere.com> <54627964.7040709@bbs.darktech.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 11 Nov 2014 22:12:51 +0100 Message-ID: To: cowwoc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DIyeCEd6XzjTVH4xPyYWUWnkHpI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 21:13:14 -0000 2014-11-11 22:02 GMT+01:00 cowwoc : > Same here. I would also prefer replacing "both" with "either" in the devi= ce > rule. What is the practical benefit of forcing both codecs on non-browser= s? > If you proceed this way, won't most applications accept being declared > non-compliant instead of investing the extra work/cost of implementing bo= th > codecs? Is just that? Without the royalty/patents/licensing stuff being clear in both H264 and VP8, the current agreement means that someone building a new browser will be mandated to include two non-open-royalty-free codecs in order to be "compliant" with a ***W3C specification***. This is insane IMHO, even more given that nobody here can claim whether no legal actions could be made in the future against the author of this such a new browser. And of course, by "including both codecs" I don't mean "including the Cisco binary+wrapper". --=20 I=C3=B1aki Baz Castillo From nobody Tue Nov 11 14:41:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE2C1A1A2A for ; Tue, 11 Nov 2014 14:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7Jb4PtH2Tet for ; Tue, 11 Nov 2014 14:41:31 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3E1A01A8 for ; Tue, 11 Nov 2014 14:41:30 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 11 Nov 2014 17:41:03 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0174.001; Tue, 11 Nov 2014 17:41:02 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/ItBc8la/WTkdEq+gk4aCR6lE5xbaqcggACZwKA= Date: Tue, 11 Nov 2014 22:41:02 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF312676@XMB111CNC.rim.net> References: <54601E19.8080203@nostrum.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF312676XMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AiyWMxZ3sf9rv0RZvUNx9XOmBcI Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 22:41:34 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF312676XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZWZmb3J0IEFkYW0uDQoNCg0KDQpXZSB3b3VsZCBzdGlsbCBwcmVmZXIg YSBzaW5nbGUgdmlkZW8gTVRJIGNvZGVjLiBUaGF0IHNhaWQsIGhlcmUgaXMgYW4gYWx0ZXJuYXRp dmUgdG8vbW9kaWZpY2F0aW9uIG9mIHRoZSDigJhub3ZlbCBwcm9wb3NhbOKAmSB0byB0cnkgdG8g bWl0aWdhdGUgdGhlIGNvbmNlcm5zLg0KDQoNCg0KV2hlbiB2aWRlbyBpbnRlcm9wZXJhYmlsaXR5 IGlzIHJlcXVpcmVkLCB0aGUgZm9sbG93aW5nIGFwcGxpZXM6DQoNCi0gQWxsIFdlYlJUQyBlbmRw b2ludHMgU0hPVUxEIGltcGxlbWVudCBkZWNvZGluZyBmb3IgYXQgbGVhc3QNCg0KICAgVlA4IGFu ZCBILjI2NC4NCg0KDQoNCi0gSW4gb3BlcmF0aW5nIGVudmlyb25tZW50cyB0aGF0IGV4cG9zZSBh IHBsYXRmb3JtIHByb3ZpZGVkDQoNCiAgIGltcGxlbWVudGF0aW9uIG9mIEguMjY0LCBXZWJSVEMg ZW5kcG9pbnRzIE1VU1QgaW1wbGVtZW50IEguMjY0DQoNCg0KDQotIEluIG9wZXJhdGluZyBlbnZp cm9ubWVudHMgdGhhdCBleHBvc2UgYSBwbGF0Zm9ybSBwcm92aWRlZA0KDQogICBpbXBsZW1lbnRh dGlvbiBvZiBWUDgsIFdlYlJUQyBlbmRwb2ludHMgTVVTVCBpbXBsZW1lbnQgVlA4DQoNCg0KDQot IE90aGVyd2lzZSAoaW4gb3BlcmF0aW5nIGVudmlyb25tZW50cyB0aGF0IGRvIG5vdCBleHBvc2Ug YQ0KDQogICBwbGF0Zm9ybSBwcm92aWRlZCBpbXBsZW1lbnRhdGlvbiBvZiBILjI2NCBhbmQvb3Ig VlA4KToNCg0KICAgICAtIFdlYlJUQyAiRGV2aWNlcy9ub24tYnJvd3NlciIgU0hBTEwgaW1wbGVt ZW50IGF0IGxlYXN0DQoNCiAgICAgICBvbmUgb2YgVlA4IGFuZCBILjI2NC4NCg0KICAgICAtIFdl YlJUQyAiVUFzL2Jyb3dzZXJzIiBTSEFMTCBpbXBsZW1lbnQgZW5jb2RpbmcgZm9yIGF0DQoNCiAg ICAgICBsZWFzdCBvbmUgb2YgVlA4IGFuZCBILjI2NC4NCg0KDQoNCg0KDQpUaGUgcmF0aW9uYWxl cyBhcmUgYXMgZm9sbG93Og0KDQoNCg0KSWYgUkYgaXMgYSByZXF1aXJlbWVudCwgSSBkb24ndCBz ZWUgaG93IHRoZSBwcm9wb3NhbCBtZWV0cyB0aGUgcmVxdWlyZW1lbnQuDQoNCklmIGludGVyb3Bl cmFiaWxpdHkgaXMgYSByZXF1aXJlbWVudCwgb25lIGFncmVlZCB1cG9uIGNvZGVjL0FQSSBpcyBl bm91Z2guDQoNCk11bHRpcGx5aW5nIG5vbi1hZ3JlZWQgdXBvbiBjb2RlY3MsIGF0IGFsbCBvciBh dCBkaWZmZXJlbnQgbGV2ZWxzLCBkb2VzIG5vdCBzZWVtIHRvIGZ1bGZpbGwgYW55IG9mIHRob3Nl IHR3byByZXF1aXJlbWVudHMgYW5kIGlzIG1lY2hhbmljYWxseSBpbmNyZWFzaW5nIHRoZSBjb3N0 IG9mIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KDQpJIGJlbGlldmUgd2Ugc2hvdWxkIGFp bSBhdCBiZWluZyBpbmNsdXNpdmUgYW5kIG5vdCBtYWtpbmcgc29tZSBvZiB0aGUgV2ViUlRDIGVu ZHBvaW50cywgcGFydGljdWxhcmx5IGRldmljZS9ub24gYnJvd3Nlciwgd2ViUlRDLWNvbXBhdGli bGUgZW5kcG9pbnRzIG9ubHkgaWYgdGhleSB3b3VsZCBkaWZmZXIganVzdCBieSBvbmUgY29kZWMu DQoNCkVsc2V3aGVyZSB0aGF0IGlzIGNhbGxlZCBwcm9maWxpbmcuIElzIHRoYXQgYSB3YXkgdG8g Z28/IFRoYXQgaXMgc29tZXdoYXQgd2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBsb29rcyBsaWtlLg0K DQoNCg0KU29tZSBkZXZpY2UvT1MgdmVuZG9ycyBoYXZlIHJlbGVhc2VkIEFQSSB0byBoYXJkd2Fy ZSBzdXBwb3J0ZWQgY29kZWMgKEJsYWNrQmVycnkgaW5jbHVkZWQpLiBPbmUgb2YgdGhlIGdvYWwg aXMgdG8gb2ZmZXIgY29kZWMgYWNjZXNzIHdpdGhvdXQgYWRkaXRpb25hbCBjb3N0IHRvIG5vbi1w bGF0Zm9ybS1uYXRpdmUgVUEvYnJvd3Nlci9kZXZpY2Uvbm9uLWJyb3dzZXIsIGhlbmNlIG1heGlt aXppbmcgaW50ZXJvcGVyYWJpbGl0eSBmb3IgV2ViUlRDIGVuZHBvaW50cy4gQW5kIHdpdGhvdXQg aGF2aW5nIG11bHRpcGxlIG9jY3VycmVuY2VzIG9mIGNvZGVjcyBiZWluZyBsb2FkZWQgb24gdGhl IHBsYXRmb3JtLg0KDQpXZSBzaG91bGQgbGV2ZXJhZ2UgdGhpcyBwb3NzaWJpbGl0eSBhcyB0aGlz IGJlY29tZXMgbW9yZSB3aWRlbHkgYXZhaWxhYmxlIGFjcm9zcyBwbGF0Zm9ybXMuDQoNCg0KDQpU aGUgSUVURiBSRkNzIHdpbGwgc2VydmUgbWFueSB1c2UtY2FzZXMgYW5kIG1heSBiZSBpbXBsZW1l bnRlZCB3aXRoIG90aGVyIHNwZWNpZmljYXRpb25zIHRoYW4gdGhlIFczQyBXZWJSVEMgMS4wLiBv ciB3aXRob3V0IGFueSBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb25zLiBNb3N0IG5vbi1icm93c2Vy L2RldmljZSBlbmRwb2ludHMgd2hpbGUgaW1wbGVtZW50aW5nIChzb21lL2FsbCkgdGhlIElFVEYg V2ViUlRDIFJGQ3Mgd2lsbCBub3QgaW50ZXJvcCB3aXRoIG90aGVyIG5vbi1icm93c2VyL2Rldmlj ZSBlbmRwb2ludHMgYnkgY2hvaWNlIGFuZCB0aGF0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggY29k ZWMgc3VwcG9ydCAodGhleSBtaWdodCB3ZWxsIHN1cHBvcnQgdGhlIHNhbWUgY29kZWMpLiBJIHRo aW5rIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIG5hdGl2ZSBhbmQgbm9uLW5hdGl2ZSBlbmRwb2lu dHMgYWxzbyBtYXR0ZXJzIGEgbG90Lg0KDQpJbnRlcm9wZXJhYmlsaXR5IGF0IHRoZSBjb2RlYyBs ZXZlbCBmb3IgYXBwcy9Ob24tYnJvd3Nlci9kZXZpY2UgZW5kcG9pbnRzIGlzIG5vdCBhbiBvYnZp b3VzIHJlcXVpcmVtZW50IGZvciBhbGwgY2FzZXMuDQoNCg0KDQoiLi4uIHRoZSBJRVRGIHdpbGwg Y2hhbmdlIHRoaXMgbm9ybWF0aXZlIHN0YXRlbWVudC4uLiIgSXQgd2lsbCB0YWtlIHNvbWUgdGlt ZSB0byBoYXZlIGEgY2xlYXIgYXNzZXNzbWVudC4gVGhlIElTTyBwcm9jZXNzIGlzIG5vdCBmaW5p c2hlZC4gSXQgdGFrZXMgYW4gZXZlbiBsb25nZXIgdGltZSB0byBkZXByZWNhdGUgYSBjb2RlYyBm cm9tIGEgcGxhdGZvcm0vbm9uLWJyb3dzZXIvZGV2aWNlLiBJIGRvdWJ0IHRoaXMgd2lsbCBiZSBw cmFjdGljYWwuIE9waW5pb25zIGNoYW5nZXMgb3ZlciB0aW1lLiBBZ3JlZW1lbnQgdG8gcmV2aXNp dCBub3cgbWF5IG5vdCBzdGFuZCBpbiBmZXcgbW9udGhzLiBJbnN0ZWFkIG9mIGJlaW5nIHVuY2xl YXIgb24gd2hhdCB3aWxsIHRyaWdnZXIgdGhlIHJldmlzaXQgb2YgdGhhdCB0ZXh0LCBpdCB3b3Vs ZCBiZSBwcmVmZXJhYmxlIHRvIGF2b2lkIGNyZWF0aW5nIHN1Y2ggYSBidXJkZW4uDQoNCg0KDQoN CkkgaG9wZSB0aGlzIGhlbHBzLg0KDQoNCg0KR2HDq2xsZQ0KDQoNCg0KDQoNCkZyb206IHJ0Y3dl YiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRhbSBSb2Fj aA0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAwOSwgMjAxNCA5OjA4IFBNDQpUbzogcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbcnRjd2ViXSBNVEkgVmlk ZW8gQ29kZWM6IGEgbm92ZWwgcHJvcG9zYWwNCg0KSXQgYXBwZWFycyB0aGF0IHdlJ3JlIHJ1bm5p bmcgaGVhZGxvbmcgaW50byBhbm90aGVyIGluLXBlcnNvbiBkaXNjdXNzaW9uIGFib3V0IHRoZSBy ZWxhdGl2ZSBtZXJpdHMgb2YgSC4yNjQgYW5kIFZQOCBhcyBNVEkgY2FuZGlkYXRlcyBhZ2Fpbi4g TWF0dGhldyBLYXVmbWFuIGhhcyBhcmd1ZWQgdGhhdCB0aGlzIGNvbnZlcnNhdGlvbiBpcyBkb29t ZWQgdG8gZmFpbHVyZSBiZWNhdXNlIG5vIG1ham9yIHBsYXllciBoYXMgYmVlbiB3aWxsaW5nIHRv IGNoYW5nZSB0aGVpciBwb3NpdGlvbi4gVGhlIHBsYXllcnMgaGUgY2l0ZWQgd2VyZSBDaXNjbywg R29vZ2xlLCBhbmQgTW96aWxsYSwgd2hvIGhhdmUgcmVwcmVzZW50ZWQgdGhlIHRocmVlIG1haW4g cG9zaXRpb25zIG9uIHRoaXMgdG9waWMgcHJldHR5IGVmZmVjdGl2ZWx5LiBBbHRob3VnaCB3ZSBw YXJ0aWNpcGF0ZSBhcyBpbmRpdmlkdWFscyBpbiB0aGUgSUVURiwgSSB0aGluayBpdCdzIGZhaXIg dG8gc2F5IHRoYXQgdGhlIGxhc3QgdGltZSB3ZSBoYWQgdGhpcyBjb252ZXJzYXRpb24sIHRoZSBt ZWRpYW4gcG9zaXRpb25zIG9mIHBhcnRpY2lwYW50cyBmcm9tIHRob3NlIGNvbXBhbmllcyB3ZXJl ICJILjI2NCBvciBkaWUiLCAiVlA4IG9yIGRpZSIsIGFuZCAiZWl0aGVyIG9uZSBhcyBsb25nIGFz IGl0J3MgKm9ubHkqIG9uZSIsIHJlc3BlY3RpdmVseS4NCg0KSG93ZXZlciwgZXZlbiBpZiBub3Ro aW5nIGVsc2UgaGFzIGNoYW5nZWQsIEkgdGhpbmsgb25lIHNhbGllbnQgcG9pbnQgbWF5IGhhdmUg YmVjb21lIHF1aXRlIGltcG9ydGFudDogd2UncmUgYWxsIHRpcmVkIG9mIHRoaXMuIE92ZXIgdHdv IHllYXJzIGFnbywgaW4gTWFyY2ggb2YgMjAxMiAtLSBiZWZvcmUgSSBldmVuIGhhZCBhbiBwYXJ0 aWN1bGFyIGludGVyZXN0IGluIFdlYlJUQyBleGNlcHQgYXMgYSB1c2VyIC0tIHRoaXMgaGFkIGFs cmVhZHkgYmVjb21lIHN1Y2ggYSBsb25nLXJ1bm5pbmcgYWNyaW1vbmlvdXMgZGViYXRlIHRoYXQg SSB3YXMgYnJvdWdodCBpbiBhcyBhIG5ldXRyYWwgdGhpcmQgcGFydHkgdG8gdHJ5IHRvIG1lZGlh dGUuIEknbSB3ZWFyeSBvZiB0aGlzIGFyZ3VtZW50OyBhbmQsIHdpdGggdGhlIGV4Y2VwdGlvbiBv ZiBhIGZldyBhZ2dyZXNzaXZlIHZvaWNlcyB3aG8gc2VlbSB0byBlbmpveSB0aGUgYmF0dGxlIG1v cmUgdGhhbiB0aGUgb3V0Y29tZSwgSSdtIGhlYXJpbmcgYSBzaW1pbGFyIGV4aGF1c3RlZCB0aW1i cmUgaW4gdGhlIG1lc3NhZ2VzIG9mIG90aGVyIHBhcnRpY2lwYW50cyAoYW5kIHRoZSBrZXkgc3Rh a2Vob2xkZXJzIGluIHBhcnRpY3VsYXIpLg0KDQpTbywgSSB3YW50IHRvIGZsb2F0IGEgcHJvcG9z YWwgdGhhdCByZXByZXNlbnRzIGEgY29tcHJvbWlzZSwgdG8gc2VlIGlmIHdlIGNhbiBmaW5hbGx5 IGNsb3NlIHRoaXMgaXNzdWUuIEZpcnN0LCBJIHdhbnQgdG8gc3RhcnQgb3V0IGJ5IHJlaXRlcmF0 aW5nIGEgd2VsbC13b3JuIG9ic2VydmF0aW9uIHRoYXQgdGhlIGhhbGxtYXJrIG9mIGEgZ29vZCBj b21wcm9taXNlIGlzIHRoYXQgbm9ib2R5IGxlYXZlcyBoYXBweSwgYnV0IGV2ZXJ5b25lIGNhbiBm b3JjZSB0aGVtc2VsdmVzIHRvIGFjY2VwdCBpdC4gQW5kIEkgd2FudCB0byBiZSBjcnlzdGFsIGNs ZWFyOiB0aGUgc29sdXRpb24gSSdtIGFib3V0IHRvIGZsb2F0IGp1c3QgYmFyZWx5IGNsZWFycyB0 aGUgYmFyIG9mIHdoYXQgSSB0aGluayBJIGNhbiBsaXZlIHdpdGguIFRoaXMgcHJvcG9zYWwgaXMg YmFzZWQgb24gYW4gb2JzZXJ2YXRpb24gdGhhdCB0aGUgZG9taW5hdGluZyBpc3N1ZXMgaW4gdGhp cyBjb252ZXJzYXRpb24gcmVtYWluIHRob3NlIG9mIGxpY2Vuc2luZywgbm90IHRlY2hub2xvZ3kg b3IgZXZlbiBpbmN1bWJlbmN5LiBJ4oCZdmUgZGlzY3Vzc2VkIHRoaXMgZXh0ZW5zaXZlbHkgd2l0 aCByZXByZXNlbnRhdGl2ZXMgb2YgYWxsIHRocmVlIG9mIHRoZSBwbGF5ZXJzIEkgbWVudGlvbiBh Ym92ZSwgYW5kIHRoZXkgYXJlIHdpbGxpbmcgdG8gc2lnbiBvbi4NCg0KVGhpcyBwcm9wb3NhbCBp cyBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbnMgb2YgIldlYlJUQyBVc2VyIEFnZW50IiwgIldlYlJU QyBkZXZpY2UiLCBhbmQgIldlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IiBpbiBzZWN0aW9uIDIu MiBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMi50eHQuIE15IHByb3Bvc2FsIHdvdWxk IGJlIGFzIGZvbGxvd3M6DQoNCiAgMS4gIFdlYlJUQyBVc2VyIEFnZW50cyBNVVNUIGltcGxlbWVu dCBib3RoIFZQOCBhbmQgSC4yNjQuDQogIDIuICBXZWJSVEMgZGV2aWNlcyBNVVNUIGltcGxlbWVu dCBib3RoIFZQOCBhbmQgSC4yNjQuIElmIGNvbXBlbGxpbmcgZXZpZGVuY2UgYXJpc2VzIHRoYXQg b25lIG9mIHRoZSBjb2RlY3MgaXMgYXZhaWxhYmxlIGZvciB1c2Ugb24gYSByb3lhbHR5LWZyZWUg YmFzaXMsIHN1Y2ggYXMgYWxsIElQUiBkZWNsYXJhdGlvbnMga25vd24gZm9yIHRoZSBjb2RlYyBi ZWluZyBvZiAoSUVURikgUm95YWx0eS1GcmVlIG9yIChJU08pIHR5cGUgMSwgdGhlIElFVEYgd2ls bCBjaGFuZ2UgdGhpcyBub3JtYXRpdmUgc3RhdGVtZW50IHRvIGluZGljYXRlIHRoYXQgb25seSB0 aGF0IGNvZGVjIGlzIHJlcXVpcmVkLiBGb3IgYWJzb2x1dGUsIGNyeXN0YWwgY2xhcml0eSwgdGhp cyBwcm92aXNpb24gaXMgb25seSBhcHBsaWNhYmxlIHRvIFdlYlJUQyBkZXZpY2VzLCBhbmQgbm90 IHRvIFdlYlJUQyBVc2VyIEFnZW50cy4NCiAgMy4gIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50 cyBhcmUgZnJlZSB0byBpbXBsZW1lbnQgYW55IHZpZGVvIGNvZGVjcyB0aGV5IHNlZSBmaXQsIGlm IGFueSAodGhpcyBmb2xsb3dzIGxvZ2ljYWxseSBmcm9tIHRoZSBkZWZpbml0aW9uIG9mICJXZWJS VEMtY29tcGF0aWJsZSBlbmRwb2ludCwiIGFuZCBkb2Vzbid0IHJlYWxseSBuZWVkIHRvIGJlIHN0 YXRlZCwgYnV0IEkgd2FudCB0aGlzIHByb3Bvc2FsIHRvIGJlIGFzIGV4cGxpY2l0IGFzIHBvc3Np YmxlKS4NCg0KVGhpcyBoYXMgdGhlIHByb3BlcnR5IG9mIGVuc3VyaW5nIHRoYXQgYWxsIGRldmlj ZXMgYW5kIHVzZXIgYWdlbnRzIGNhbiB3b3JrIHdpdGggYWxsIGRldmljZXMgYW5kIHVzZXIgYWdl bnRzLiBUaGlzIGhhcyB0aGUgcHJvcGVydHkgb2YgZ2l2aW5nIG5vIG9uZSBleGFjdGx5IHdoYXQg dGhleSB3YW50LiBBbmQsIHVubGlrZSBhbnkgb3RoZXIgcHJldmlvdXMgcGxhbnMsIHRoaXMgaGFz IHRoZSBwcm9wZXJ0eSBvZiBjb21pbmcgdG8gYSBkZWNpc2lvbiB3aGlsZSBtYWludGFpbmluZyBw cmVzc3VyZSBvbiB0aGUgb25seSBwYXJ0aWVzIHdobyBjYW4gbWFrZSBhIGNoYW5nZSBpbiB0aGUg SVBSIGxhbmRzY2FwZSB0byBkbyBzby4NCg0KL2ENCg== --_000_92D0D52F3A63344CA478CF12DB0648AADF312676XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5N c29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QbGFpblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjk4Njc4MDc2NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE1NzM2NzI1 Njt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTUzODg1NDI4Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoxMDIyMTQ1MzA4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3Qt aWQ6MTU2MzYzMzY2MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTk5MzYzNjAwNCAxNjYwMDUzNDQ4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5UaGFua3MgZm9yIHRoZSBlZmZvcnQgQWRhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2Ugd291bGQgc3RpbGwg cHJlZmVyIGEgc2luZ2xlIHZpZGVvIE1USSBjb2RlYy4gVGhhdCBzYWlkLCBoZXJlIGlzIGFuIGFs dGVybmF0aXZlIHRvL21vZGlmaWNhdGlvbiBvZiB0aGUg4oCYbm92ZWwgcHJvcG9zYWzigJkgdG8g dHJ5IHRvIG1pdGlnYXRlIHRoZSBjb25jZXJucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+V2hlbiB2aWRlbyBpbnRlcm9wZXJhYmlsaXR5IGlzIHJlcXVpcmVkLCB0aGUgZm9sbG93aW5n IGFwcGxpZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tIEFsbCBX ZWJSVEMgZW5kcG9pbnRzIFNIT1VMRCBpbXBsZW1lbnQgZGVjb2RpbmcgZm9yIGF0IGxlYXN0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVlA4IGFu ZCBILjI2NC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSBJbiBvcGVyYXRpbmcgZW52 aXJvbm1lbnRzIHRoYXQgZXhwb3NlIGEgcGxhdGZvcm0gcHJvdmlkZWQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbiBvZiBI LjI2NCwgV2ViUlRDIGVuZHBvaW50cyBNVVNUIGltcGxlbWVudCBILjI2NDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4tIEluIG9wZXJhdGluZyBlbnZpcm9ubWVudHMgdGhhdCBleHBvc2Ug YSBwbGF0Zm9ybSBwcm92aWRlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGF0aW9uIG9mIFZQOCwgV2ViUlRDIGVuZHBvaW50cyBN VVNUIGltcGxlbWVudCBWUDg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSBPdGhlcndp c2UgKGluIG9wZXJhdGluZyBlbnZpcm9ubWVudHMgdGhhdCBkbyBub3QgZXhwb3NlIGE8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBwbGF0Zm9ybSBw cm92aWRlZCBpbXBsZW1lbnRhdGlvbiBvZiBILjI2NCBhbmQvb3IgVlA4KToNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7LSBXZWJSVEMgJnF1b3Q7RGV2aWNlcy9ub24tYnJvd3NlciZxdW90OyBTSEFMTCBpbXBsZW1l bnQgYXQgbGVhc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvbmUgb2YgVlA4IGFuZCBILjI2NC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtIFdlYlJUQyAmcXVvdDtVQXMvYnJvd3NlcnMmcXVvdDsgU0hBTEwgaW1wbGVtZW50IGVu Y29kaW5nIGZvciBhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYXN0IG9uZSBvZiBWUDggYW5kIEgu MjY0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIHJhdGlvbmFsZXMgYXJlIGFz IGZvbGxvdzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5JZiBSRiBpcyBhIHJlcXVpcmVtZW50LCBJIGRvbid0IHNlZSBob3cg dGhlIHByb3Bvc2FsIG1lZXRzIHRoZSByZXF1aXJlbWVudC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+SWYgaW50ZXJvcGVyYWJpbGl0eSBpcyBhIHJlcXVpcmVtZW50 LCBvbmUgYWdyZWVkIHVwb24gY29kZWMvQVBJIGlzIGVub3VnaC4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TXVsdGlwbHlpbmcgbm9uLWFncmVlZCB1cG9uIGNvZGVj cywgYXQgYWxsIG9yIGF0IGRpZmZlcmVudCBsZXZlbHMsIGRvZXMgbm90IHNlZW0gdG8gZnVsZmls bCBhbnkgb2YgdGhvc2UgdHdvIHJlcXVpcmVtZW50cyBhbmQgaXMgbWVjaGFuaWNhbGx5IGluY3Jl YXNpbmcgdGhlIGNvc3Qgb2YgV2ViUlRDIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+SSBiZWxpZXZlIHdlIHNob3VsZCBhaW0gYXQgYmVpbmcgaW5jbHVzaXZl IGFuZCBub3QgbWFraW5nIHNvbWUgb2YgdGhlIFdlYlJUQyBlbmRwb2ludHMsIHBhcnRpY3VsYXJs eSBkZXZpY2Uvbm9uIGJyb3dzZXIsIHdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50cyBvbmx5IGlm IHRoZXkgd291bGQgZGlmZmVyIGp1c3QgYnkgb25lIGNvZGVjLiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkVsc2V3aGVyZSB0aGF0IGlzIGNhbGxlZCBwcm9m aWxpbmcuIElzIHRoYXQgYSB3YXkgdG8gZ28/IFRoYXQgaXMgc29tZXdoYXQgd2hhdCB0aGUgZ2F0 ZXdheSBkcmFmdCBsb29rcyBsaWtlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Tb21l IGRldmljZS9PUyB2ZW5kb3JzIGhhdmUgcmVsZWFzZWQgQVBJIHRvIGhhcmR3YXJlIHN1cHBvcnRl ZCBjb2RlYyAoQmxhY2tCZXJyeSBpbmNsdWRlZCkuIE9uZSBvZiB0aGUgZ29hbCBpcyB0byBvZmZl ciBjb2RlYyBhY2Nlc3Mgd2l0aG91dCBhZGRpdGlvbmFsIGNvc3QgdG8gbm9uLXBsYXRmb3JtLW5h dGl2ZSBVQS9icm93c2VyL2RldmljZS9ub24tYnJvd3NlciwgaGVuY2UgbWF4aW1pemluZyBpbnRl cm9wZXJhYmlsaXR5DQogZm9yIFdlYlJUQyBlbmRwb2ludHMuIEFuZCB3aXRob3V0IGhhdmluZyBt dWx0aXBsZSBvY2N1cnJlbmNlcyBvZiBjb2RlY3MgYmVpbmcgbG9hZGVkIG9uIHRoZSBwbGF0Zm9y bS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2Ugc2hvdWxkIGxl dmVyYWdlIHRoaXMgcG9zc2liaWxpdHkgYXMgdGhpcyBiZWNvbWVzIG1vcmUgd2lkZWx5IGF2YWls YWJsZSBhY3Jvc3MgcGxhdGZvcm1zLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo ZSBJRVRGIFJGQ3Mgd2lsbCBzZXJ2ZSBtYW55IHVzZS1jYXNlcyBhbmQgbWF5IGJlIGltcGxlbWVu dGVkIHdpdGggb3RoZXIgc3BlY2lmaWNhdGlvbnMgdGhhbiB0aGUgVzNDIFdlYlJUQyAxLjAuIG9y IHdpdGhvdXQgYW55IGFkZGl0aW9uYWwgc3BlY2lmaWNhdGlvbnMuIE1vc3Qgbm9uLWJyb3dzZXIv ZGV2aWNlIGVuZHBvaW50cyB3aGlsZSBpbXBsZW1lbnRpbmcgKHNvbWUvYWxsKSB0aGUgSUVURiBX ZWJSVEMNCiBSRkNzIHdpbGwgbm90IGludGVyb3Agd2l0aCBvdGhlciBub24tYnJvd3Nlci9kZXZp Y2UgZW5kcG9pbnRzIGJ5IGNob2ljZSBhbmQgdGhhdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIGNv ZGVjIHN1cHBvcnQgKHRoZXkgbWlnaHQgd2VsbCBzdXBwb3J0IHRoZSBzYW1lIGNvZGVjKS4gSSB0 aGluayB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBuYXRpdmUgYW5kIG5vbi1uYXRpdmUgZW5kcG9p bnRzIGFsc28gbWF0dGVycyBhIGxvdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkludGVyb3BlcmFiaWxpdHkgYXQgdGhlIGNvZGVjIGxldmVsIGZvciBhcHBzL05vbi1i cm93c2VyL2RldmljZSBlbmRwb2ludHMgaXMgbm90IGFuIG9idmlvdXMgcmVxdWlyZW1lbnQgZm9y IGFsbCBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7Li4uIHRoZSBJ RVRGIHdpbGwgY2hhbmdlIHRoaXMgbm9ybWF0aXZlIHN0YXRlbWVudC4uLiZxdW90OyBJdCB3aWxs IHRha2Ugc29tZSB0aW1lIHRvIGhhdmUgYSBjbGVhciBhc3Nlc3NtZW50LiBUaGUgSVNPIHByb2Nl c3MgaXMgbm90IGZpbmlzaGVkLiBJdCB0YWtlcyBhbiBldmVuIGxvbmdlciB0aW1lIHRvIGRlcHJl Y2F0ZSBhIGNvZGVjIGZyb20gYSBwbGF0Zm9ybS9ub24tYnJvd3Nlci9kZXZpY2UuIEkgZG91YnQN CiB0aGlzIHdpbGwgYmUgcHJhY3RpY2FsLiBPcGluaW9ucyBjaGFuZ2VzIG92ZXIgdGltZS4gQWdy ZWVtZW50IHRvIHJldmlzaXQgbm93IG1heSBub3Qgc3RhbmQgaW4gZmV3IG1vbnRocy4gSW5zdGVh ZCBvZiBiZWluZyB1bmNsZWFyIG9uIHdoYXQgd2lsbCB0cmlnZ2VyIHRoZSByZXZpc2l0IG9mIHRo YXQgdGV4dCwgaXQgd291bGQgYmUgcHJlZmVyYWJsZSB0byBhdm9pZCBjcmVhdGluZyBzdWNoIGEg YnVyZGVuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SSBob3BlIHRoaXMgaGVscHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkdhw6ts bGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFkYW0gUm9hY2g8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5 LCBOb3ZlbWJlciAwOSwgMjAxNCA5OjA4IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWls dG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtydGN3ZWJdIE1USSBWaWRlbyBDb2RlYzogYSBub3ZlbCBwcm9wb3NhbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+SXQgYXBwZWFycyB0aGF0IHdlJ3JlIHJ1bm5pbmcgaGVhZGxvbmcgaW50byBhbm90 aGVyIGluLXBlcnNvbiBkaXNjdXNzaW9uIGFib3V0IHRoZSByZWxhdGl2ZSBtZXJpdHMgb2YgSC4y NjQgYW5kIFZQOCBhcyBNVEkgY2FuZGlkYXRlcyBhZ2Fpbi4gTWF0dGhldyBLYXVmbWFuIGhhcyBh cmd1ZWQgdGhhdCB0aGlzIGNvbnZlcnNhdGlvbiBpcyBkb29tZWQgdG8gZmFpbHVyZQ0KIGJlY2F1 c2Ugbm8gbWFqb3IgcGxheWVyIGhhcyBiZWVuIHdpbGxpbmcgdG8gY2hhbmdlIHRoZWlyIHBvc2l0 aW9uLiBUaGUgcGxheWVycyBoZSBjaXRlZCB3ZXJlIENpc2NvLCBHb29nbGUsIGFuZCBNb3ppbGxh LCB3aG8gaGF2ZSByZXByZXNlbnRlZCB0aGUgdGhyZWUgbWFpbiBwb3NpdGlvbnMgb24gdGhpcyB0 b3BpYyBwcmV0dHkgZWZmZWN0aXZlbHkuIEFsdGhvdWdoIHdlIHBhcnRpY2lwYXRlIGFzIGluZGl2 aWR1YWxzIGluIHRoZSBJRVRGLCBJIHRoaW5rDQogaXQncyBmYWlyIHRvIHNheSB0aGF0IHRoZSBs YXN0IHRpbWUgd2UgaGFkIHRoaXMgY29udmVyc2F0aW9uLCB0aGUgbWVkaWFuIHBvc2l0aW9ucyBv ZiBwYXJ0aWNpcGFudHMgZnJvbSB0aG9zZSBjb21wYW5pZXMgd2VyZSAmcXVvdDtILjI2NCBvciBk aWUmcXVvdDssICZxdW90O1ZQOCBvciBkaWUmcXVvdDssIGFuZCAmcXVvdDtlaXRoZXIgb25lIGFz IGxvbmcgYXMgaXQncyAqb25seSogb25lJnF1b3Q7LCByZXNwZWN0aXZlbHkuPGJyPg0KPGJyPg0K SG93ZXZlciwgZXZlbiBpZiBub3RoaW5nIGVsc2UgaGFzIGNoYW5nZWQsIEkgdGhpbmsgb25lIHNh bGllbnQgcG9pbnQgbWF5IGhhdmUgYmVjb21lIHF1aXRlIGltcG9ydGFudDogd2UncmUgYWxsIHRp cmVkIG9mIHRoaXMuIE92ZXIgdHdvIHllYXJzIGFnbywgaW4gTWFyY2ggb2YgMjAxMiAtLSBiZWZv cmUgSSBldmVuIGhhZCBhbiBwYXJ0aWN1bGFyIGludGVyZXN0IGluIFdlYlJUQyBleGNlcHQgYXMg YSB1c2VyIC0tIHRoaXMgaGFkIGFscmVhZHkgYmVjb21lDQogc3VjaCBhIGxvbmctcnVubmluZyBh Y3JpbW9uaW91cyBkZWJhdGUgdGhhdCBJIHdhcyBicm91Z2h0IGluIGFzIGEgbmV1dHJhbCB0aGly ZCBwYXJ0eSB0byB0cnkgdG8gbWVkaWF0ZS4gSSdtIHdlYXJ5IG9mIHRoaXMgYXJndW1lbnQ7IGFu ZCwgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIGEgZmV3IGFnZ3Jlc3NpdmUgdm9pY2VzIHdobyBzZWVt IHRvIGVuam95IHRoZSBiYXR0bGUgbW9yZSB0aGFuIHRoZSBvdXRjb21lLCBJJ20gaGVhcmluZyBh IHNpbWlsYXINCiBleGhhdXN0ZWQgdGltYnJlIGluIHRoZSBtZXNzYWdlcyBvZiBvdGhlciBwYXJ0 aWNpcGFudHMgKGFuZCB0aGUga2V5IHN0YWtlaG9sZGVycyBpbiBwYXJ0aWN1bGFyKS48YnI+DQo8 YnI+DQpTbywgSSB3YW50IHRvIGZsb2F0IGEgcHJvcG9zYWwgdGhhdCByZXByZXNlbnRzIGEgY29t cHJvbWlzZSwgdG8gc2VlIGlmIHdlIGNhbiBmaW5hbGx5IGNsb3NlIHRoaXMgaXNzdWUuIEZpcnN0 LCBJIHdhbnQgdG8gc3RhcnQgb3V0IGJ5IHJlaXRlcmF0aW5nIGEgd2VsbC13b3JuIG9ic2VydmF0 aW9uIHRoYXQgdGhlIGhhbGxtYXJrIG9mIGEgZ29vZCBjb21wcm9taXNlIGlzIHRoYXQgbm9ib2R5 IGxlYXZlcyBoYXBweSwgYnV0IGV2ZXJ5b25lIGNhbiBmb3JjZQ0KIHRoZW1zZWx2ZXMgdG8gYWNj ZXB0IGl0LiBBbmQgSSB3YW50IHRvIGJlIGNyeXN0YWwgY2xlYXI6IHRoZSBzb2x1dGlvbiBJJ20g YWJvdXQgdG8gZmxvYXQganVzdCBiYXJlbHkgY2xlYXJzIHRoZSBiYXIgb2Ygd2hhdCBJIHRoaW5r IEkgY2FuIGxpdmUgd2l0aC4gVGhpcyBwcm9wb3NhbCBpcyBiYXNlZCBvbiBhbiBvYnNlcnZhdGlv biB0aGF0IHRoZSBkb21pbmF0aW5nIGlzc3VlcyBpbiB0aGlzIGNvbnZlcnNhdGlvbiByZW1haW4g dGhvc2Ugb2YgbGljZW5zaW5nLA0KIG5vdCB0ZWNobm9sb2d5IG9yIGV2ZW4gaW5jdW1iZW5jeS4g SeKAmXZlIGRpc2N1c3NlZCB0aGlzIGV4dGVuc2l2ZWx5IHdpdGggcmVwcmVzZW50YXRpdmVzIG9m IGFsbCB0aHJlZSBvZiB0aGUgcGxheWVycyBJIG1lbnRpb24gYWJvdmUsIGFuZCB0aGV5IGFyZSB3 aWxsaW5nIHRvIHNpZ24gb24uPGJyPg0KPGJyPg0KVGhpcyBwcm9wb3NhbCBpcyBiYXNlZCBvbiB0 aGUgZGVmaW5pdGlvbnMgb2YgJnF1b3Q7V2ViUlRDIFVzZXIgQWdlbnQmcXVvdDssICZxdW90O1dl YlJUQyBkZXZpY2UmcXVvdDssIGFuZCAmcXVvdDtXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludCZx dW90OyBpbiBzZWN0aW9uIDIuMiBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMi50eHQu IE15IHByb3Bvc2FsIHdvdWxkIGJlIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8b2wgc3Rh cnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZv NSI+DQpXZWJSVEMgVXNlciBBZ2VudHMgTVVTVCBpbXBsZW1lbnQgYm90aCBWUDggYW5kIEguMjY0 LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm81 Ij4NCldlYlJUQyBkZXZpY2VzIE1VU1QgaW1wbGVtZW50IGJvdGggVlA4IGFuZCBILjI2NC4gSWYg Y29tcGVsbGluZyBldmlkZW5jZSBhcmlzZXMgdGhhdCBvbmUgb2YgdGhlIGNvZGVjcyBpcyBhdmFp bGFibGUgZm9yIHVzZSBvbiBhIHJveWFsdHktZnJlZSBiYXNpcywgc3VjaCBhcyBhbGwgSVBSIGRl Y2xhcmF0aW9ucyBrbm93biBmb3IgdGhlIGNvZGVjIGJlaW5nIG9mIChJRVRGKSBSb3lhbHR5LUZy ZWUgb3IgKElTTykgdHlwZSAxLCB0aGUgSUVURiB3aWxsDQogY2hhbmdlIHRoaXMgbm9ybWF0aXZl IHN0YXRlbWVudCB0byBpbmRpY2F0ZSB0aGF0IG9ubHkgdGhhdCBjb2RlYyBpcyByZXF1aXJlZC4g Rm9yIGFic29sdXRlLCBjcnlzdGFsIGNsYXJpdHksIHRoaXMgcHJvdmlzaW9uIGlzIG9ubHkgYXBw bGljYWJsZSB0byBXZWJSVEMgZGV2aWNlcywgYW5kIG5vdCB0byBXZWJSVEMgVXNlciBBZ2VudHMu DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZl bDEgbGZvNSI+DQpXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludHMgYXJlIGZyZWUgdG8gaW1wbGVt ZW50IGFueSB2aWRlbyBjb2RlY3MgdGhleSBzZWUgZml0LCBpZiBhbnkgKHRoaXMgZm9sbG93cyBs b2dpY2FsbHkgZnJvbSB0aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDtXZWJSVEMtY29tcGF0aWJsZSBl bmRwb2ludCwmcXVvdDsgYW5kIGRvZXNuJ3QgcmVhbGx5IG5lZWQgdG8gYmUgc3RhdGVkLCBidXQg SSB3YW50IHRoaXMgcHJvcG9zYWwgdG8gYmUgYXMgZXhwbGljaXQgYXMgcG9zc2libGUpLjxvOnA+ PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhpcyBoYXMgdGhl IHByb3BlcnR5IG9mIGVuc3VyaW5nIHRoYXQgYWxsIGRldmljZXMgYW5kIHVzZXIgYWdlbnRzIGNh biB3b3JrIHdpdGggYWxsIGRldmljZXMgYW5kIHVzZXIgYWdlbnRzLiBUaGlzIGhhcyB0aGUgcHJv cGVydHkgb2YgZ2l2aW5nIG5vIG9uZSBleGFjdGx5IHdoYXQgdGhleSB3YW50LiBBbmQsIHVubGlr ZSBhbnkgb3RoZXIgcHJldmlvdXMgcGxhbnMsIHRoaXMgaGFzIHRoZSBwcm9wZXJ0eSBvZiBjb21p bmcgdG8gYSBkZWNpc2lvbg0KIHdoaWxlIG1haW50YWluaW5nIHByZXNzdXJlIG9uIHRoZSBvbmx5 IHBhcnRpZXMgd2hvIGNhbiBtYWtlIGEgY2hhbmdlIGluIHRoZSBJUFIgbGFuZHNjYXBlIHRvIGRv IHNvLjxicj4NCjxicj4NCi9hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_92D0D52F3A63344CA478CF12DB0648AADF312676XMB111CNCrimnet_-- From nobody Tue Nov 11 16:36:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223461A88B7 for ; Tue, 11 Nov 2014 16:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA6ZB2bnteFM for ; Tue, 11 Nov 2014 16:35:59 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id CE54F1A885F for ; Tue, 11 Nov 2014 16:35:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 257F07C00BD for ; Wed, 12 Nov 2014 01:35:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEes9PM8q9q6 for ; Wed, 12 Nov 2014 01:35:53 +0100 (CET) Received: from [IPv6:2001:67c:370:176:4805:b828:f652:a1bd] (t2001067c037001764805b828f652a1bd.wireless-a.v6.meeting.ietf.org [IPv6:2001:67c:370:176:4805:b828:f652:a1bd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7240F7C0051 for ; Wed, 12 Nov 2014 01:35:53 +0100 (CET) Message-ID: <5462AB64.1070300@alvestrand.no> Date: Tue, 11 Nov 2014 16:35:48 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> <546265E3.7060300@alvestrand.no> <546267B9.8020605@andyet.net> <4E528337-ED7A-41ED-B196-A4CF6C4D84DF@phonefromhere.com> <54627964.7040709@bbs.darktech.org> In-Reply-To: <54627964.7040709@bbs.darktech.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BCBVYsIXBI6PfVZ7bnKkjNjElUQ Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 00:36:03 -0000 On 11/11/2014 01:02 PM, cowwoc wrote: > On 11/11/2014 3:13 PM, tim panton wrote: >> My personal preference would be to replace ‘both’ with ‘either’ in >> the device rule, but I understand >> the thinking behind the ‘both’ phrasing. > > Same here. I would also prefer replacing "both" with "either" in the > device rule. What is the practical benefit of forcing both codecs on > non-browsers? If you proceed this way, won't most applications accept > being declared non-compliant instead of investing the extra work/cost > of implementing both codecs? > > Implementing both codecs only makes sense when you need > interoperability between applications written by different authors. Don't forget the case where one author wants to write the same application in two different environments, and wants to use some toolkits not written by himself. If those toolkits don't support the same codecs ... he can't interoperate with himself. > The same argument does not apply when both endpoints are written by > the same author. Furthermore, I would argue that when separate authors > want their applications to inter-operate they will have the necessary > incentive to make that happen, with or without the specification > dictating how it should be done. > > Another spin on this would be to say: all libraries/platforms > (abstraction layers used to write applications) must implement both > codecs, whereas applications (end-users) can implement as many codecs > as they'd like. That would indeed be a possible spin, but a somewhat strange one. > > Gili > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Tue Nov 11 17:36:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361031A8A75 for ; Tue, 11 Nov 2014 17:36:24 -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 gKTTiAAq5QJP for ; Tue, 11 Nov 2014 17:36:20 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7321A8792 for ; Tue, 11 Nov 2014 17:36:20 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so12592313ieb.22 for ; Tue, 11 Nov 2014 17:36:20 -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=Vxq25pdCUhmns3qa0/bXVXcC2W2b+plpb/zS+5J3idI=; b=Q7qQjZIqlc6qWGrgYCT1bIjLbK8+/Yt4SyE/71BRcHhneJJP7IQMW8hGGq+ss+tB+6 A9XHpPxteKLulXsQYDBivbsoIWCyyeX58NW8Ipg3cFABWOiVhXahsyNqgSJbWotRRflj ANEwSJo5b9vM8lEo4009LY4fzv+TTZMO4aQsV0eHEuvhGXZMiOumI4dUg0U6rFJfLSTQ I0lMMj9uifDzJ18T8d5qtp/87HeSjS2yxydDzspXSNJZqaUITKiyUIAGmJu5IAIkFUEu 04TG2Mvom0hcAz36lVsadYCdJn/NHDlec+oTI4f18BTqbeAHAJ54REYkipqtVH7SS1gf ZnaQ== X-Gm-Message-State: ALoCoQnih22hr2UNA+qK8afLm/9ocTKNd+CEzvQMoiTr3gunAJfS+CGHZuN2p8NfOTMUaCnAQ/sy X-Received: by 10.43.129.196 with SMTP id hj4mr46698421icc.21.1415756179872; Tue, 11 Nov 2014 17:36:19 -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 qo2sm2603946igb.12.2014.11.11.17.36.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 17:36:19 -0800 (PST) Message-ID: <5462B991.4030700@bbs.darktech.org> Date: Tue, 11 Nov 2014 20:36:17 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> <5461A019.6030108@alvestrand.no> <1A6093A8-A7E9-4760-B790-CC767CAA2116@gmail.com> <546265E3.7060300@alvestrand.no> <546267B9.8020605@andyet.net> <4E528337-ED7A-41ED-B196-A4CF6C4D84DF@phonefromhere.com> <54627964.7040709@bbs.darktech.org> <5462AB64.1070300@alvestrand.no> In-Reply-To: <5462AB64.1070300@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/D3JFIIG4JfCmoT_tv3o62Qx22og Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 01:36:24 -0000 On 11/11/2014 7:35 PM, Harald Alvestrand wrote: > Don't forget the case where one author wants to write the same > application in two different environments, and wants to use some > toolkits not written by himself. If those toolkits don't support the > same codecs ... he can't interoperate with himself. Agreed. >> Another spin on this would be to say: all libraries/platforms >> (abstraction layers used to write applications) must implement both >> codecs, whereas applications (end-users) can implement as many codecs >> as they'd like. > That would indeed be a possible spin, but a somewhat strange one. I don't think a "WebRTC compliant" logo would be relevant for applications (the end-user couldn't care less) but for toolkits/frameworks/libraries this is suddenly relevant. Developers will look for such things when researching libraries. The same applies for browsers. So yes, this approach might sound weird at first but the more I think about it the more I think these groups would benefit from different expectations. Gili From nobody Tue Nov 11 18:11:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11E71A88C7 for ; Tue, 11 Nov 2014 18:11:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaQF9QcffU5u for ; Tue, 11 Nov 2014 18:11:44 -0800 (PST) Received: from relay.mailchannels.net (si-002-i39.relay.mailchannels.net [184.154.112.204]) by ietfa.amsl.com (Postfix) with ESMTP id 69C001A882E for ; Tue, 11 Nov 2014 18:11:42 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 14A95AD9C1 for ; Wed, 12 Nov 2014 02:11:39 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.245.44.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.3.3); Wed, 12 Nov 2014 02:11:40 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1415758300287:2348371723 X-MC-Ingress-Time: 1415758300287 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:54000 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XoNPG-00092v-UK for rtcweb@ietf.org; Tue, 11 Nov 2014 20:11:38 -0600 Message-ID: <5462C1BB.7050209@jesup.org> Date: Tue, 11 Nov 2014 21:11:07 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> <7594FB04B1934943A5C02806D1A2204B1D4E50D8@ESESSMB209.ericsson.se> <545A6281.4050601@gmail.com> <545A7E0B.4070505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4Z1JITQquOtHcpJmMLVKhyls54I Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 02:11:49 -0000 On 11/5/2014 5:39 PM, tim panton wrote: > > Agreed, the worst aspect of any adoption of H264 is that it makes it=20 > significantly more difficult to > produce a custom =92secure=92 build of firefox that has been independen= tly=20 > reviewed for special use-cases > (press, humanitarian workers etc). I suspect those users might be=20 > prepared to forego the =91w3c webRTC compliant=92 > logo in exchange for increased security. I'll note that we're running openH264 inside a pretty strong sandbox for=20 security reasons, so really one should be vetting the sandbox and=20 assuming the code inside is compromised. The sandbox exposes a lot less=20 than an NPAPI plugin exposes, for example. Perhaps this helps for your ca= se. --=20 Randell Jesup -- rjesup a t mozilla d o t com From nobody Wed Nov 12 00:00:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92FD1A883E for ; Wed, 12 Nov 2014 00:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 kschIYdPjLbH for ; Wed, 12 Nov 2014 00:00:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8FE1A87C1 for ; Wed, 12 Nov 2014 00:00:43 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 95EF818C350; Wed, 12 Nov 2014 09:00:41 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6FD7E23808D; Wed, 12 Nov 2014 09:00:41 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 09:00:41 +0100 From: To: 'Adam Roach' , "'rtcweb@ietf.org'" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/ItEa9FlPZRQu0qjsNi4+FcSzZxcnUsQ Date: Wed, 12 Nov 2014 08:00:40 +0000 Message-ID: <17118_1415779241_546313A9_17118_5052_1_2842AD9A45C83B44B57635FD4831E60A0C1EDAEF@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: <54601E19.8080203@nostrum.com> In-Reply-To: <54601E19.8080203@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_2842AD9A45C83B44B57635FD4831E60A0C1EDAEFPEXCVZYM14corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.65124 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kPTTN2aaSLCgSf6T3e4SWRyE5X8 Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 08:00:48 -0000 --_000_2842AD9A45C83B44B57635FD4831E60A0C1EDAEFPEXCVZYM14corpo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uc2lkZXJpbmcgdGhlIHRpbWUgc3BlbnQgb24gdGhpcyBpc3N1ZSwgSSBjb3VsZCBsaXZlIG5v dyB3aXRoIGFueSBjb21wcm9taXNlIHRoYXQgd291bGQgYXZvaWQgdGhlICJubyBkZWNpc2lvbiIg c2l0dWF0aW9uLiAgTm8gZGVjaXNpb24gb24gdmlkZW8gTVRJIGNvZGVjIGF0IHRoaXMgbWVldGlu ZyB3b3VsZCBiZSB2ZXJ5IGJhZCBuZXdzIGZvciB0aGUgV2ViUlRDIHRlY2hub2xvZ3kgYW5kIGZv ciBpdHMgZXh0ZW5kZWQgdXNhZ2UgaW4gc2VydmljZXMgYmVjYXVzZSBvZiB0aGUgaW50ZXJvcGVy YWJpbGl0eSBpc3N1ZS4gQW55IGtpbmQgb2YgcmVhc29uYWJsZSAidHdvIGNvZGVjcyIgY29tcHJv bWlzZSBsaWtlIHRoaXMgb25lIHdvdWxkIG1ha2UgYXQgbGVhc3QgYSBjbGVhciBzdGVwIGZvcndh cmQgd2l0aCByZXNwZWN0IHRvIHRoaXMgaW50ZXJvcC4gaXNzdWUuICBTbyBpZiBpdCBjYW4gZmx5 LCArMSBmb3IgbXlzZWxmICENCg0KU3TDqXBoYW5lDQoNCkRlIDogcnRjd2ViIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQWRhbSBSb2FjaA0KRW52b3nDqSA6 IGx1bmRpIDEwIG5vdmVtYnJlIDIwMTQgMDM6MDgNCsOAIDogcnRjd2ViQGlldGYub3JnDQpPYmpl dCA6IFtydGN3ZWJdIE1USSBWaWRlbyBDb2RlYzogYSBub3ZlbCBwcm9wb3NhbA0KDQpJdCBhcHBl YXJzIHRoYXQgd2UncmUgcnVubmluZyBoZWFkbG9uZyBpbnRvIGFub3RoZXIgaW4tcGVyc29uIGRp c2N1c3Npb24gYWJvdXQgdGhlIHJlbGF0aXZlIG1lcml0cyBvZiBILjI2NCBhbmQgVlA4IGFzIE1U SSBjYW5kaWRhdGVzIGFnYWluLiBNYXR0aGV3IEthdWZtYW4gaGFzIGFyZ3VlZCB0aGF0IHRoaXMg Y29udmVyc2F0aW9uIGlzIGRvb21lZCB0byBmYWlsdXJlIGJlY2F1c2Ugbm8gbWFqb3IgcGxheWVy IGhhcyBiZWVuIHdpbGxpbmcgdG8gY2hhbmdlIHRoZWlyIHBvc2l0aW9uLiBUaGUgcGxheWVycyBo ZSBjaXRlZCB3ZXJlIENpc2NvLCBHb29nbGUsIGFuZCBNb3ppbGxhLCB3aG8gaGF2ZSByZXByZXNl bnRlZCB0aGUgdGhyZWUgbWFpbiBwb3NpdGlvbnMgb24gdGhpcyB0b3BpYyBwcmV0dHkgZWZmZWN0 aXZlbHkuIEFsdGhvdWdoIHdlIHBhcnRpY2lwYXRlIGFzIGluZGl2aWR1YWxzIGluIHRoZSBJRVRG LCBJIHRoaW5rIGl0J3MgZmFpciB0byBzYXkgdGhhdCB0aGUgbGFzdCB0aW1lIHdlIGhhZCB0aGlz IGNvbnZlcnNhdGlvbiwgdGhlIG1lZGlhbiBwb3NpdGlvbnMgb2YgcGFydGljaXBhbnRzIGZyb20g dGhvc2UgY29tcGFuaWVzIHdlcmUgIkguMjY0IG9yIGRpZSIsICJWUDggb3IgZGllIiwgYW5kICJl aXRoZXIgb25lIGFzIGxvbmcgYXMgaXQncyAqb25seSogb25lIiwgcmVzcGVjdGl2ZWx5Lg0KDQpI b3dldmVyLCBldmVuIGlmIG5vdGhpbmcgZWxzZSBoYXMgY2hhbmdlZCwgSSB0aGluayBvbmUgc2Fs aWVudCBwb2ludCBtYXkgaGF2ZSBiZWNvbWUgcXVpdGUgaW1wb3J0YW50OiB3ZSdyZSBhbGwgdGly ZWQgb2YgdGhpcy4gT3ZlciB0d28geWVhcnMgYWdvLCBpbiBNYXJjaCBvZiAyMDEyIC0tIGJlZm9y ZSBJIGV2ZW4gaGFkIGFuIHBhcnRpY3VsYXIgaW50ZXJlc3QgaW4gV2ViUlRDIGV4Y2VwdCBhcyBh IHVzZXIgLS0gdGhpcyBoYWQgYWxyZWFkeSBiZWNvbWUgc3VjaCBhIGxvbmctcnVubmluZyBhY3Jp bW9uaW91cyBkZWJhdGUgdGhhdCBJIHdhcyBicm91Z2h0IGluIGFzIGEgbmV1dHJhbCB0aGlyZCBw YXJ0eSB0byB0cnkgdG8gbWVkaWF0ZS4gSSdtIHdlYXJ5IG9mIHRoaXMgYXJndW1lbnQ7IGFuZCwg d2l0aCB0aGUgZXhjZXB0aW9uIG9mIGEgZmV3IGFnZ3Jlc3NpdmUgdm9pY2VzIHdobyBzZWVtIHRv IGVuam95IHRoZSBiYXR0bGUgbW9yZSB0aGFuIHRoZSBvdXRjb21lLCBJJ20gaGVhcmluZyBhIHNp bWlsYXIgZXhoYXVzdGVkIHRpbWJyZSBpbiB0aGUgbWVzc2FnZXMgb2Ygb3RoZXIgcGFydGljaXBh bnRzIChhbmQgdGhlIGtleSBzdGFrZWhvbGRlcnMgaW4gcGFydGljdWxhcikuDQoNClNvLCBJIHdh bnQgdG8gZmxvYXQgYSBwcm9wb3NhbCB0aGF0IHJlcHJlc2VudHMgYSBjb21wcm9taXNlLCB0byBz ZWUgaWYgd2UgY2FuIGZpbmFsbHkgY2xvc2UgdGhpcyBpc3N1ZS4gRmlyc3QsIEkgd2FudCB0byBz dGFydCBvdXQgYnkgcmVpdGVyYXRpbmcgYSB3ZWxsLXdvcm4gb2JzZXJ2YXRpb24gdGhhdCB0aGUg aGFsbG1hcmsgb2YgYSBnb29kIGNvbXByb21pc2UgaXMgdGhhdCBub2JvZHkgbGVhdmVzIGhhcHB5 LCBidXQgZXZlcnlvbmUgY2FuIGZvcmNlIHRoZW1zZWx2ZXMgdG8gYWNjZXB0IGl0LiBBbmQgSSB3 YW50IHRvIGJlIGNyeXN0YWwgY2xlYXI6IHRoZSBzb2x1dGlvbiBJJ20gYWJvdXQgdG8gZmxvYXQg anVzdCBiYXJlbHkgY2xlYXJzIHRoZSBiYXIgb2Ygd2hhdCBJIHRoaW5rIEkgY2FuIGxpdmUgd2l0 aC4gVGhpcyBwcm9wb3NhbCBpcyBiYXNlZCBvbiBhbiBvYnNlcnZhdGlvbiB0aGF0IHRoZSBkb21p bmF0aW5nIGlzc3VlcyBpbiB0aGlzIGNvbnZlcnNhdGlvbiByZW1haW4gdGhvc2Ugb2YgbGljZW5z aW5nLCBub3QgdGVjaG5vbG9neSBvciBldmVuIGluY3VtYmVuY3kuIEnigJl2ZSBkaXNjdXNzZWQg dGhpcyBleHRlbnNpdmVseSB3aXRoIHJlcHJlc2VudGF0aXZlcyBvZiBhbGwgdGhyZWUgb2YgdGhl IHBsYXllcnMgSSBtZW50aW9uIGFib3ZlLCBhbmQgdGhleSBhcmUgd2lsbGluZyB0byBzaWduIG9u Lg0KDQpUaGlzIHByb3Bvc2FsIGlzIGJhc2VkIG9uIHRoZSBkZWZpbml0aW9ucyBvZiAiV2ViUlRD IFVzZXIgQWdlbnQiLCAiV2ViUlRDIGRldmljZSIsIGFuZCAiV2ViUlRDLWNvbXBhdGlibGUgZW5k cG9pbnQiIGluIHNlY3Rpb24gMi4yIG9mIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEyLnR4 dC4gTXkgcHJvcG9zYWwgd291bGQgYmUgYXMgZm9sbG93czoNCg0KICAxLiAgV2ViUlRDIFVzZXIg QWdlbnRzIE1VU1QgaW1wbGVtZW50IGJvdGggVlA4IGFuZCBILjI2NC4NCiAgMi4gIFdlYlJUQyBk ZXZpY2VzIE1VU1QgaW1wbGVtZW50IGJvdGggVlA4IGFuZCBILjI2NC4gSWYgY29tcGVsbGluZyBl dmlkZW5jZSBhcmlzZXMgdGhhdCBvbmUgb2YgdGhlIGNvZGVjcyBpcyBhdmFpbGFibGUgZm9yIHVz ZSBvbiBhIHJveWFsdHktZnJlZSBiYXNpcywgc3VjaCBhcyBhbGwgSVBSIGRlY2xhcmF0aW9ucyBr bm93biBmb3IgdGhlIGNvZGVjIGJlaW5nIG9mIChJRVRGKSBSb3lhbHR5LUZyZWUgb3IgKElTTykg dHlwZSAxLCB0aGUgSUVURiB3aWxsIGNoYW5nZSB0aGlzIG5vcm1hdGl2ZSBzdGF0ZW1lbnQgdG8g aW5kaWNhdGUgdGhhdCBvbmx5IHRoYXQgY29kZWMgaXMgcmVxdWlyZWQuIEZvciBhYnNvbHV0ZSwg Y3J5c3RhbCBjbGFyaXR5LCB0aGlzIHByb3Zpc2lvbiBpcyBvbmx5IGFwcGxpY2FibGUgdG8gV2Vi UlRDIGRldmljZXMsIGFuZCBub3QgdG8gV2ViUlRDIFVzZXIgQWdlbnRzLg0KICAzLiAgV2ViUlRD LWNvbXBhdGlibGUgZW5kcG9pbnRzIGFyZSBmcmVlIHRvIGltcGxlbWVudCBhbnkgdmlkZW8gY29k ZWNzIHRoZXkgc2VlIGZpdCwgaWYgYW55ICh0aGlzIGZvbGxvd3MgbG9naWNhbGx5IGZyb20gdGhl IGRlZmluaXRpb24gb2YgIldlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50LCIgYW5kIGRvZXNuJ3Qg cmVhbGx5IG5lZWQgdG8gYmUgc3RhdGVkLCBidXQgSSB3YW50IHRoaXMgcHJvcG9zYWwgdG8gYmUg YXMgZXhwbGljaXQgYXMgcG9zc2libGUpLg0KDQpUaGlzIGhhcyB0aGUgcHJvcGVydHkgb2YgZW5z dXJpbmcgdGhhdCBhbGwgZGV2aWNlcyBhbmQgdXNlciBhZ2VudHMgY2FuIHdvcmsgd2l0aCBhbGwg ZGV2aWNlcyBhbmQgdXNlciBhZ2VudHMuIFRoaXMgaGFzIHRoZSBwcm9wZXJ0eSBvZiBnaXZpbmcg bm8gb25lIGV4YWN0bHkgd2hhdCB0aGV5IHdhbnQuIEFuZCwgdW5saWtlIGFueSBvdGhlciBwcmV2 aW91cyBwbGFucywgdGhpcyBoYXMgdGhlIHByb3BlcnR5IG9mIGNvbWluZyB0byBhIGRlY2lzaW9u IHdoaWxlIG1haW50YWluaW5nIHByZXNzdXJlIG9uIHRoZSBvbmx5IHBhcnRpZXMgd2hvIGNhbiBt YWtlIGEgY2hhbmdlIGluIHRoZSBJUFIgbGFuZHNjYXBlIHRvIGRvIHNvLg0KDQovYQ0KCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91LgoK --_000_2842AD9A45C83B44B57635FD4831E60A0C1EDAEFPEXCVZYM14corpo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uVGV4dGVkZWJ1bGxl c0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6MzI5NDEyMDgyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTE5MTg4NDM4O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDox ODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDozODY2MTMzMjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODAwNzM4NTA0O30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij5Db25zaWRlcmluZyB0aGUgdGltZSBzcGVudCBvbiB0aGlzIGlzc3VlLCBJIGNvdWxkIGxpdmUg bm93IHdpdGggYW55IGNvbXByb21pc2UgdGhhdCB3b3VsZCBhdm9pZCB0aGUgJnF1b3Q7bm8gZGVj aXNpb24mcXVvdDsgc2l0dWF0aW9uLiAmbmJzcDtObyBkZWNpc2lvbiBvbg0KIHZpZGVvIE1USSBj b2RlYyBhdCB0aGlzIG1lZXRpbmcgd291bGQgYmUgdmVyeSBiYWQgbmV3cyBmb3IgdGhlIFdlYlJU QyB0ZWNobm9sb2d5IGFuZCBmb3IgaXRzIGV4dGVuZGVkIHVzYWdlIGluIHNlcnZpY2VzIGJlY2F1 c2Ugb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgaXNzdWUuIEFueSBraW5kIG9mIHJlYXNvbmFibGUg JnF1b3Q7dHdvIGNvZGVjcyZxdW90OyBjb21wcm9taXNlIGxpa2UgdGhpcyBvbmUgd291bGQgbWFr ZSBhdCBsZWFzdCBhIGNsZWFyIHN0ZXAgZm9yd2FyZA0KIHdpdGggcmVzcGVjdCB0byB0aGlzIGlu dGVyb3AuIGlzc3VlLiAmbmJzcDtTbyBpZiBpdCBjYW4gZmx5LCAmIzQzOzEgZm9yIG15c2VsZiAh PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPlN0w6lwaGFuZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gcnRjd2ViIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBBZGFtIFJvYWNoPGJy Pg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGx1bmRpIDEwIG5vdmVtYnJlIDIwMTQgMDM6MDg8YnI+ DQo8Yj7DgCZuYnNwOzo8L2I+IHJ0Y3dlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPmJAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFty dGN3ZWJdIE1USSBWaWRlbyBDb2RlYzogYSBub3ZlbCBwcm9wb3NhbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IGFwcGVhcnMgdGhhdCB3ZSdyZSBydW5uaW5nIGhlYWRs b25nIGludG8gYW5vdGhlciBpbi1wZXJzb24gZGlzY3Vzc2lvbiBhYm91dCB0aGUgcmVsYXRpdmUg bWVyaXRzIG9mIEguMjY0IGFuZCBWUDggYXMgTVRJIGNhbmRpZGF0ZXMgYWdhaW4uIE1hdHRoZXcg S2F1Zm1hbiBoYXMgYXJndWVkIHRoYXQgdGhpcyBjb252ZXJzYXRpb24NCiBpcyBkb29tZWQgdG8g ZmFpbHVyZSBiZWNhdXNlIG5vIG1ham9yIHBsYXllciBoYXMgYmVlbiB3aWxsaW5nIHRvIGNoYW5n ZSB0aGVpciBwb3NpdGlvbi4gVGhlIHBsYXllcnMgaGUgY2l0ZWQgd2VyZSBDaXNjbywgR29vZ2xl LCBhbmQgTW96aWxsYSwgd2hvIGhhdmUgcmVwcmVzZW50ZWQgdGhlIHRocmVlIG1haW4gcG9zaXRp b25zIG9uIHRoaXMgdG9waWMgcHJldHR5IGVmZmVjdGl2ZWx5LiBBbHRob3VnaCB3ZSBwYXJ0aWNp cGF0ZSBhcyBpbmRpdmlkdWFscw0KIGluIHRoZSBJRVRGLCBJIHRoaW5rIGl0J3MgZmFpciB0byBz YXkgdGhhdCB0aGUgbGFzdCB0aW1lIHdlIGhhZCB0aGlzIGNvbnZlcnNhdGlvbiwgdGhlIG1lZGlh biBwb3NpdGlvbnMgb2YgcGFydGljaXBhbnRzIGZyb20gdGhvc2UgY29tcGFuaWVzIHdlcmUgJnF1 b3Q7SC4yNjQgb3IgZGllJnF1b3Q7LCAmcXVvdDtWUDggb3IgZGllJnF1b3Q7LCBhbmQgJnF1b3Q7 ZWl0aGVyIG9uZSBhcyBsb25nIGFzIGl0J3MgKm9ubHkqIG9uZSZxdW90OywgcmVzcGVjdGl2ZWx5 Ljxicj4NCjxicj4NCkhvd2V2ZXIsIGV2ZW4gaWYgbm90aGluZyBlbHNlIGhhcyBjaGFuZ2VkLCBJ IHRoaW5rIG9uZSBzYWxpZW50IHBvaW50IG1heSBoYXZlIGJlY29tZSBxdWl0ZSBpbXBvcnRhbnQ6 IHdlJ3JlIGFsbCB0aXJlZCBvZiB0aGlzLiBPdmVyIHR3byB5ZWFycyBhZ28sIGluIE1hcmNoIG9m IDIwMTIgLS0gYmVmb3JlIEkgZXZlbiBoYWQgYW4gcGFydGljdWxhciBpbnRlcmVzdCBpbiBXZWJS VEMgZXhjZXB0IGFzIGEgdXNlciAtLSB0aGlzIGhhZCBhbHJlYWR5IGJlY29tZQ0KIHN1Y2ggYSBs b25nLXJ1bm5pbmcgYWNyaW1vbmlvdXMgZGViYXRlIHRoYXQgSSB3YXMgYnJvdWdodCBpbiBhcyBh IG5ldXRyYWwgdGhpcmQgcGFydHkgdG8gdHJ5IHRvIG1lZGlhdGUuIEknbSB3ZWFyeSBvZiB0aGlz IGFyZ3VtZW50OyBhbmQsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBhIGZldyBhZ2dyZXNzaXZlIHZv aWNlcyB3aG8gc2VlbSB0byBlbmpveSB0aGUgYmF0dGxlIG1vcmUgdGhhbiB0aGUgb3V0Y29tZSwg SSdtIGhlYXJpbmcgYSBzaW1pbGFyDQogZXhoYXVzdGVkIHRpbWJyZSBpbiB0aGUgbWVzc2FnZXMg b2Ygb3RoZXIgcGFydGljaXBhbnRzIChhbmQgdGhlIGtleSBzdGFrZWhvbGRlcnMgaW4gcGFydGlj dWxhcikuPGJyPg0KPGJyPg0KU28sIEkgd2FudCB0byBmbG9hdCBhIHByb3Bvc2FsIHRoYXQgcmVw cmVzZW50cyBhIGNvbXByb21pc2UsIHRvIHNlZSBpZiB3ZSBjYW4gZmluYWxseSBjbG9zZSB0aGlz IGlzc3VlLiBGaXJzdCwgSSB3YW50IHRvIHN0YXJ0IG91dCBieSByZWl0ZXJhdGluZyBhIHdlbGwt d29ybiBvYnNlcnZhdGlvbiB0aGF0IHRoZSBoYWxsbWFyayBvZiBhIGdvb2QgY29tcHJvbWlzZSBp cyB0aGF0IG5vYm9keSBsZWF2ZXMgaGFwcHksIGJ1dCBldmVyeW9uZSBjYW4gZm9yY2UNCiB0aGVt c2VsdmVzIHRvIGFjY2VwdCBpdC4gQW5kIEkgd2FudCB0byBiZSBjcnlzdGFsIGNsZWFyOiB0aGUg c29sdXRpb24gSSdtIGFib3V0IHRvIGZsb2F0IGp1c3QgYmFyZWx5IGNsZWFycyB0aGUgYmFyIG9m IHdoYXQgSSB0aGluayBJIGNhbiBsaXZlIHdpdGguIFRoaXMgcHJvcG9zYWwgaXMgYmFzZWQgb24g YW4gb2JzZXJ2YXRpb24gdGhhdCB0aGUgZG9taW5hdGluZyBpc3N1ZXMgaW4gdGhpcyBjb252ZXJz YXRpb24gcmVtYWluIHRob3NlIG9mIGxpY2Vuc2luZywNCiBub3QgdGVjaG5vbG9neSBvciBldmVu IGluY3VtYmVuY3kuIEnigJl2ZSBkaXNjdXNzZWQgdGhpcyBleHRlbnNpdmVseSB3aXRoIHJlcHJl c2VudGF0aXZlcyBvZiBhbGwgdGhyZWUgb2YgdGhlIHBsYXllcnMgSSBtZW50aW9uIGFib3ZlLCBh bmQgdGhleSBhcmUgd2lsbGluZyB0byBzaWduIG9uLjxicj4NCjxicj4NClRoaXMgcHJvcG9zYWwg aXMgYmFzZWQgb24gdGhlIGRlZmluaXRpb25zIG9mICZxdW90O1dlYlJUQyBVc2VyIEFnZW50JnF1 b3Q7LCAmcXVvdDtXZWJSVEMgZGV2aWNlJnF1b3Q7LCBhbmQgJnF1b3Q7V2ViUlRDLWNvbXBhdGli bGUgZW5kcG9pbnQmcXVvdDsgaW4gc2VjdGlvbiAyLjIgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItb3Zl cnZpZXctMTIudHh0LiBNeSBwcm9wb3NhbCB3b3VsZCBiZSBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5XZWJSVEMgVXNlciBB Z2VudHMgTVVTVCBpbXBsZW1lbnQgYm90aCBWUDggYW5kIEguMjY0LjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+V2ViUlRDIGRldmljZXMgTVVTVCBpbXBsZW1lbnQgYm90aCBWUDggYW5kIEgu MjY0LiBJZiBjb21wZWxsaW5nIGV2aWRlbmNlIGFyaXNlcyB0aGF0IG9uZSBvZiB0aGUgY29kZWNz IGlzIGF2YWlsYWJsZSBmb3IgdXNlIG9uIGEgcm95YWx0eS1mcmVlIGJhc2lzLCBzdWNoIGFzIGFs bCBJUFIgZGVjbGFyYXRpb25zIGtub3duIGZvciB0aGUgY29kZWMgYmVpbmcgb2YgKElFVEYpIFJv eWFsdHktRnJlZSBvciAoSVNPKSB0eXBlDQogMSwgdGhlIElFVEYgd2lsbCBjaGFuZ2UgdGhpcyBu b3JtYXRpdmUgc3RhdGVtZW50IHRvIGluZGljYXRlIHRoYXQgb25seSB0aGF0IGNvZGVjIGlzIHJl cXVpcmVkLiBGb3IgYWJzb2x1dGUsIGNyeXN0YWwgY2xhcml0eSwgdGhpcyBwcm92aXNpb24gaXMg b25seSBhcHBsaWNhYmxlIHRvIFdlYlJUQyBkZXZpY2VzLCBhbmQgbm90IHRvIFdlYlJUQyBVc2Vy IEFnZW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+V2ViUlRDLWNvbXBh dGlibGUgZW5kcG9pbnRzIGFyZSBmcmVlIHRvIGltcGxlbWVudCBhbnkgdmlkZW8gY29kZWNzIHRo ZXkgc2VlIGZpdCwgaWYgYW55ICh0aGlzIGZvbGxvd3MgbG9naWNhbGx5IGZyb20gdGhlIGRlZmlu aXRpb24gb2YgJnF1b3Q7V2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQsJnF1b3Q7IGFuZCBkb2Vz bid0IHJlYWxseSBuZWVkIHRvIGJlIHN0YXRlZCwgYnV0IEkgd2FudCB0aGlzIHByb3Bvc2FsIHRv IGJlIGFzIGV4cGxpY2l0DQogYXMgcG9zc2libGUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9v bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpUaGlzIGhh cyB0aGUgcHJvcGVydHkgb2YgZW5zdXJpbmcgdGhhdCBhbGwgZGV2aWNlcyBhbmQgdXNlciBhZ2Vu dHMgY2FuIHdvcmsgd2l0aCBhbGwgZGV2aWNlcyBhbmQgdXNlciBhZ2VudHMuIFRoaXMgaGFzIHRo ZSBwcm9wZXJ0eSBvZiBnaXZpbmcgbm8gb25lIGV4YWN0bHkgd2hhdCB0aGV5IHdhbnQuIEFuZCwg dW5saWtlIGFueSBvdGhlciBwcmV2aW91cyBwbGFucywgdGhpcyBoYXMgdGhlIHByb3BlcnR5IG9m IGNvbWluZyB0byBhIGRlY2lzaW9uDQogd2hpbGUgbWFpbnRhaW5pbmcgcHJlc3N1cmUgb24gdGhl IG9ubHkgcGFydGllcyB3aG8gY2FuIG1ha2UgYSBjaGFuZ2UgaW4gdGhlIElQUiBsYW5kc2NhcGUg dG8gZG8gc28uPGJyPg0KPGJyPg0KPC9zcGFuPi9hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxQ UkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2842AD9A45C83B44B57635FD4831E60A0C1EDAEFPEXCVZYM14corpo_-- From nobody Wed Nov 12 06:42:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D3E1A90DE for ; Wed, 12 Nov 2014 06:42:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdTtGygGevCu for ; Wed, 12 Nov 2014 06:42:12 -0800 (PST) Received: from relay.mailchannels.net (tkt-001-i372.relay.mailchannels.net [174.136.5.173]) by ietfa.amsl.com (Postfix) with ESMTP id 81A141A90D8 for ; Wed, 12 Nov 2014 06:42:10 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-33-12-218.us-west-2.compute.internal [10.33.12.218]) by relay.mailchannels.net (Postfix) with ESMTPA id 570D761245 for ; Wed, 12 Nov 2014 14:42:05 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.232.17.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.3.3); Wed, 12 Nov 2014 14:42:08 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1415803327688:2049864223 X-MC-Ingress-Time: 1415803326708 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:58391 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XoZ7U-000GzO-Ut for rtcweb@ietf.org; Wed, 12 Nov 2014 08:42:05 -0600 Message-ID: <5463719F.8010400@jesup.org> Date: Wed, 12 Nov 2014 09:41:35 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54601E19.8080203@nostrum.com> <92D0D52F3A63344CA478CF12DB0648AADF312676@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF312676@XMB111CNC.rim.net> Content-Type: multipart/alternative; boundary="------------090100000209030406000509" X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rUdh0T8euiwGonNd5UIBLKUmqBA Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 14:42:15 -0000 This is a multi-part message in MIME format. --------------090100000209030406000509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/11/2014 5:41 PM, Gaelle Martin-Cocher wrote: > > Thanks for the effort Adam. > Agreed. This is an incredibly thorny issue due to politics, ideology, money, etc - almost none of which is technical, except in the ramifications of various not-clean-1-codec-MTI options, as mentioned somewhat here. While I personally (this is the IETF) would prefer a pure VP8 MTI, I realize that isn't going to happen right now, and this may be (to steal a quote from B5) our last best hope for peace... I mean MTI. > We would still prefer a single video MTI codec. That said, here is an > alternative to/modification of the 'novel proposal' to try to mitigate > the concerns. > > When video interoperability is required, the following applies: > > - All WebRTC endpoints SHOULD implement decoding for at least > > VP8 and H.264. > > - In operating environments that expose a platform provided > > implementation of H.264, WebRTC endpoints MUST implement H.264 > You assume "platform" codec implementations (H.264 and VP8) are inherently useful for WebRTC. They often aren't. You can include wiggle words about "usable" or "realtime", which helps but certainly makes the decision the domain of the implementing device/browser (to decide if it's usable). I would extend this to must support both if they have "usable" platform-provided implementations. > Some device/OS vendors have released API to hardware supported codec > (BlackBerry included). One of the goal is to offer codec access > without additional cost to non-platform-native > UA/browser/device/non-browser, hence maximizing interoperability for > WebRTC endpoints. And without having multiple occurrences of codecs > being loaded on the platform. > > We should leverage this possibility as this becomes more widely > available across platforms. > Agreed - but this can be easier said than done, especially on Android, and may require per-device/OS-version validation to use. Older OS's (Windows pre 8.x for example) don't have viable realtime H.264 codecs by default, and we haven't yet verified if the Win8 codec meets the WebRTC needs (though likely it does), and so far as I know it's software-only. Others may not be available to applications (iOS? especially older iOS). -- Randell Jesup -- rjesup a t mozilla d o t com --------------090100000209030406000509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/11/2014 5:41 PM, Gaelle Martin-Cocher wrote:

Thanks for the effort Adam.


Agreed.  This is an incredibly thorny issue due to politics, ideology, money, etc - almost none of which is technical, except in the ramifications of various not-clean-1-codec-MTI options, as mentioned somewhat here.  While I personally (this is the IETF) would prefer a pure VP8 MTI, I realize that isn't going to happen right now, and this may be (to steal a quote from B5) our last best hope for peace... I mean MTI.

 

We would still prefer a single video MTI codec. That said, here is an alternative to/modification of the ‘novel proposal’ to try to mitigate the concerns.

 

When video interoperability is required, the following applies:

- All WebRTC endpoints SHOULD implement decoding for at least

   VP8 and H.264.

 

- In operating environments that expose a platform provided

   implementation of H.264, WebRTC endpoints MUST implement H.264


You assume "platform" codec implementations (H.264 and VP8) are inherently useful for WebRTC.  They often aren't.  You can include wiggle words about "usable" or "realtime", which helps but certainly makes the decision the domain of the implementing device/browser (to decide if it's usable).  I would extend this to must support both if they have "usable" platform-provided implementations.

Some device/OS vendors have released API to hardware supported codec (BlackBerry included). One of the goal is to offer codec access without additional cost to non-platform-native UA/browser/device/non-browser, hence maximizing interoperability for WebRTC endpoints. And without having multiple occurrences of codecs being loaded on the platform.

We should leverage this possibility as this becomes more widely available across platforms.


Agreed - but this can be easier said than done, especially on Android, and may require per-device/OS-version validation to use.  Older OS's (Windows pre 8.x for example) don't have viable realtime H.264 codecs by default, and we haven't yet verified if the Win8 codec meets the WebRTC needs (though likely it does), and so far as I know it's software-only.  Others may not be available to applications (iOS? especially older iOS).


-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------090100000209030406000509-- From nobody Wed Nov 12 07:40:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382551A1AB2 for ; Wed, 12 Nov 2014 07:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwjJO_z7qtdI for ; Wed, 12 Nov 2014 07:40:40 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D45F71A1A3B for ; Wed, 12 Nov 2014 07:40:39 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Nov 2014 10:40:24 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 10:40:23 -0500 From: Gaelle Martin-Cocher To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/ItBc8la/WTkdEq+gk4aCR6lE5xbaqcggACZwKCAAWPYgP//sW9g Date: Wed, 12 Nov 2014 15:40:22 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF312D5B@XMB111CNC.rim.net> References: <54601E19.8080203@nostrum.com> <92D0D52F3A63344CA478CF12DB0648AADF312676@XMB111CNC.rim.net> <5463719F.8010400@jesup.org> In-Reply-To: <5463719F.8010400@jesup.org> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF312D5BXMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hxqvgMI_UYwc9TXC9YB8ACocWBs Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 15:40:44 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF312D5BXMB111CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (gmc] Please see inline. From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup Sent: Wednesday, November 12, 2014 9:42 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] MTI Video Codec: a novel proposal On 11/11/2014 5:41 PM, Gaelle Martin-Cocher wrote: Thanks for the effort Adam. Agreed. This is an incredibly thorny issue due to politics, ideology, mone= y, etc - almost none of which is technical, except in the ramifications of = various not-clean-1-codec-MTI options, as mentioned somewhat here. While I= personally (this is the IETF) would prefer a pure VP8 MTI, I realize that = isn't going to happen right now, and this may be (to steal a quote from B5)= our last best hope for peace... I mean MTI. [GMC] except that it does not mitigate any issues. As an example, I can't think of a single good justification to implement tw= o encoders. Can anyone elaborate? Interop might not be in a better place if a number of WebRTC-compatible-end= points-that-are-compatible-endpoints-but-by-one-codec are not implementing = the same codec. We would still prefer a single video MTI codec. That said, here is an alter= native to/modification of the 'novel proposal' to try to mitigate the conce= rns. When video interoperability is required, the following applies: - All WebRTC endpoints SHOULD implement decoding for at least VP8 and H.264. - In operating environments that expose a platform provided implementation of H.264, WebRTC endpoints MUST implement H.264 You assume "platform" codec implementations (H.264 and VP8) are inherently = useful for WebRTC. They often aren't. You can include wiggle words about = "usable" or "realtime", which helps but certainly makes the decision the do= main of the implementing device/browser (to decide if it's usable). I woul= d extend this to must support both if they have "usable" platform-provided = implementations. [GMC] No that is not the assumption. The platform supplied implementation = would be "good enough" for many not for all endpoints. That is pretty clear= . An endpoints that wishes to have its own implementation of a required cod= ec would do it and would be willing to afford the additional cost implicati= ons. The proposed requirement here does not mandate an endpoint to use the suppl= ied platform codec implementation. It can chose to use it, or implement its= own. This is about mitigating the concerns and cost to various actors. Some device/OS vendors have released API to hardware supported codec (Black= Berry included). One of the goal is to offer codec access without additiona= l cost to non-platform-native UA/browser/device/non-browser, hence maximizi= ng interoperability for WebRTC endpoints. And without having multiple occur= rences of codecs being loaded on the platform. We should leverage this possibility as this becomes more widely available a= cross platforms. Agreed - but this can be easier said than done, especially on Android, and = may require per-device/OS-version validation to use. [GMC] I guess the (web) industry has demonstrated its willingness to suppor= t a variety of endpoints/actors by exposing platform codec implementations.= APIs will evolve. Yes, it might takes time before we reach a perfect world= . The 'novel proposal' will not remove the need of per-device/OS version vali= dation. Even in the 'novel proposal' some endpoints will leverage and use H= 264/VP8 codecs provided by a platform implementations to claim "H264/VP8 su= pport". Older OS's (Windows pre 8.x for example) don't have viable realtime H.264 c= odecs by default, and we haven't yet verified if the Win8 codec meets the W= ebRTC needs (though likely it does), and so far as I know it's software-onl= y. Others may not be available to applications (iOS? especially older iOS)= . [GMC] this is true for VP8 too. Hence the proposed "otherwise" requirement= s. -- Randell Jesup -- rjesup a t mozilla d o t com --_000_92D0D52F3A63344CA478CF12DB0648AADF312D5BXMB111CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(gmc] Please see inline.<= o:p>

 <= /p>

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup
Sent: Wednesday, November 12, 2014 9:42 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal

 

On 11/11/2014 5:41 PM, Gaelle Martin-Cocher wrote:

Thanks for the effort Adam.


Agreed.  This is an incredibly thorny issue due to politics, ideology,= money, etc - almost none of which is technical, except in the ramification= s of various not-clean-1-codec-MTI options, as mentioned somewhat here.&nbs= p; While I personally (this is the IETF) would prefer a pure VP8 MTI, I realize that isn't going to happen right now, and= this may be (to steal a quote from B5) our last best hope for peace... I m= ean MTI.
[GMC] except that it does not mitigate any is= sues.

As an example, I can&#= 8217;t think of a single good justification to implement two encoders. Can = anyone elaborate?
Interop might not be in a better place if a n= umber of WebRTC-compatible-endpoints-that-are-compatible-endpoints-but-by-o= ne-codec are not implementing the same codec.

 

We would still prefer a single video MTI codec. T= hat said, here is an alternative to/modification of the ‘novel propos= al’ to try to mitigate the concerns.

 

When video interoperability is required, the foll= owing applies:

- All WebRTC endpoints SHOULD implement decoding = for at least

   VP8 and H.264.

 

- In operating environments that expose a platfor= m provided

   implementation of H.264, WebRTC endp= oints MUST implement H.264


You assume "platform" codec implementations (H.264 and VP8) are i= nherently useful for WebRTC.  They often aren't.  You can include= wiggle words about "usable" or "realtime", which helps= but certainly makes the decision the domain of the implementing device/bro= wser (to decide if it's usable).  I would extend this to must support both= if they have "usable" platform-provided implementations.
[GMC] No that is not the assumption. The plat= form supplied  implementation would be “good enough” for m= any not for all endpoints. That is pretty clear. An endpoints that wishes t= o have its own implementation of a required codec would do it and would be willing to afford the additional cost implications.

The proposed requirement = here does not mandate an endpoint to use the supplied platform codec implem= entation. It can chose to use it, or implement its own. This is about mitigating the concerns = and cost to various actors.

 <= /p>

Some device/OS vendors have released API to hardware= supported codec (BlackBerry included). One of the goal is to offer codec a= ccess without additional cost to non-platform-native UA/browser/device/non-= browser, hence maximizing interoperability for WebRTC endpoints. And without having multiple occurrences of codecs be= ing loaded on the platform.

We should leverage this possibility as this becom= es more widely available across platforms.


Agreed - but this can be easier said than done, especially on Android, and = may require per-device/OS-version validation to use. 

[GMC] I guess the (web= ) industry has demonstrated its willingness to support a variety of endpoin= ts/actors by exposing platform codec implementations. APIs will evolve. Yes= , it might takes time before we reach a perfect world.

The ‘novel propo= sal’ will not remove the need of per-device/OS version validation. Ev= en in the ‘novel proposal’ some endpoints will leverage and use= H264/VP8 codecs provided by a platform implementations to claim “H264/VP8 support”.

Older OS's (Windows pre 8.x for example) don't have = viable realtime H.264 codecs by default, and we haven't yet verified if the= Win8 codec meets the WebRTC needs (though likely it does), and so far as I= know it's software-only.  Others may not be available to applications (iOS? especially older iOS).
[GMC] this is true for VP8 too.  Hence t= he proposed “otherwise” requirements. 

-- 
Randell Jesup -- rjesup a t mozilla d o t com
--_000_92D0D52F3A63344CA478CF12DB0648AADF312D5BXMB111CNCrimnet_-- From nobody Wed Nov 12 08:16:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F341A8716 for ; Wed, 12 Nov 2014 08:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 2Dn9MW54e6fU for ; Wed, 12 Nov 2014 08:16:23 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCF71A86F6 for ; Wed, 12 Nov 2014 08:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6172; q=dns/txt; s=iport; t=1415808983; x=1417018583; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eoBesrnqAy8ZxF4mrQMzZcK7+/xQbTPBAazQRmWgxrM=; b=itUcxczjs3LAbE5ZkVnCohAEVziki+PthNPvF4t8IWsH3kqygKGLrpDi VxWQVEVtDngh9lbgHZ2QF4XGf3OC5MhMmYRKh4RVEftd7W1rPDfqzKu2Q N4l8ncY1wFPTDR+0qsCmsaqNCAH+i/ZX5su2LUE2U6lBHCnc/lnm0ezV+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYIABSHY1StJA2J/2dsb2JhbABcgw6BLQSDAtB9Ahx/FgEBAQEBfYQCAQEBBDRRBAIBCBEDAQIFHwkCAjAdCAIEARKIQZwqnFcGllUBAQEBAQEBAQEBAQEBAQEBARuBJ490BoJrgVoFkjqLd4E0g0+NWoQKgjaBRm2BSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,369,1413244800"; d="scan'208";a="95941055" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 12 Nov 2014 16:16:22 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sACGGMcO012833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 16:16:22 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.222]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 10:16:21 -0600 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: AQHP/pP/dBCMjI/UmUKzOsZcpo+Fkg== Date: Wed, 12 Nov 2014 16:16:21 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.77.107] Content-Type: text/plain; charset="euc-kr" Content-ID: <0B903C97A3B31746B36610D3ED2ABAEA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kPKntqBGErylPg3tu3vMVHeB7tQ Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 16:16:26 -0000 SGkgQ2hyaXN0ZXIsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5l DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KRGF0ZTogTW9uZGF5LCAyNyBPY3RvYmVy IDIwMTQgMTE6NDAgcG0NClRvOiBDaXNjbyBFbXBsb3llZSA8cm1vaGFuckBjaXNjby5jb20+LCAi cnRjd2ViQGlldGYub3JnIiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtydGN3ZWJd IEktRCBBY3Rpb246DQpkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTA4 LnR4dCAtIFNvbWUgYWRkaXRpb25hbCBxdWVzdGlvbnMNCg0KPkhpLA0KPg0KPlRoYW5rcyBmb3Ig cHV0dGluZyB0b2dldGhlciB0aGUgbmV3IHZlcnNpb24hIEl0IG1ha2VzIGEgbnVtYmVyIG9mIHRo aW5ncw0KPm1vcmUgY2xlYXIgOikNCj4NCj5JIGRvIHN0aWxsIGhhdmUgYSBmZXcgY29tbWVudHMv cXVlc3Rpb25zIChob3BlZnVsbHkgZWRpdG9yaWFsIG9uZXMpLA0KPnRob3VnaDoNCj4NCj5RMToN Cj4tLS0tLQ0KPg0KPkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBleHBsaWNpdGx5IGNsYXJp ZnkgdGhhdCwgd2hlbiBjb25zZW50IGV4cGlyZXMNCj5vbiBhIDUtdHVwbGUvY2FuZGlkYXRlIHBh aXIsIGl0IGRvZXMgbm90IGFmZmVjdCBvdGhlciA1LXR1cGxlcyB3aXRoaW4gdGhlDQo+c2Vzc2lv bi4gSSBoYXZlIHJlY2VpdmVkIHF1ZXN0aW9ucyBvbiB0aGF0LCBzbyBJIHRoaW5rIHNvbWUgd29y ZHMgd291bGQNCj5iZSB1c2VmdWwgdG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KPg0KPihPZiBjb3Vy c2UsIG9uZSBDQU4gY2hvb3NlIHRvIHRlcm1pbmF0ZSB0aGUgd2hvbGUgc2Vzc2lvbiBpZiBjb25z ZW50DQo+ZXhwaXJlcyBvbiBhIGNhbmRpZGF0ZSBwYWlyLCBidXQgdGhhdCBkZXBlbmRzIG9uIGFw cGxpY2F0aW9uIHBvbGljeSkuDQoNCg0KU2VjdGlvbiA0LjEgNXRoIHBhcmFncmFwaCBjdXJyZW50 bHkgaGFzIHRoaXMgdGV4dDoNCg0KImlmIGEgdmFsaWQgU1RVTiBiaW5kaW5nIHJlc3BvbnNlDQog ICBjb3JyZXNwb25kaW5nIHRvIGFueSBTVFVOIHJlcXVlc3Qgc2VudCBpbiB0aGUgbGFzdCAzMCBz ZWNvbmRzIGhhcyBub3QNCiAgIGJlZW4gcmVjZWl2ZWQgZnJvbSB0aGUgcmVtb3RlIHBlZXIncyB0 cmFuc3BvcnQgYWRkcmVzcywgdGhlIGVuZHBvaW50DQogICBNVVNUIGNlYXNlIHRyYW5zbWlzc2lv biBvbiB0aGF0IDUtdHVwbGUuqfcNCg0KV2hlbiBDb25zZW50IGV4cGlyZXMgaXQgaXMgdXAgdG8g dGhlIGFwcGxpY2F0aW9uIHBvbGljeSB0byBkZWNpZGUgb24gd2hhdA0KdG8gZG8uIEFzIHlvdSBz YWlkIGl0IGNhbiBjaG9vc2UgdG8gdGVybWluYXRlIHRoZSB3aG9sZSBzZXNzaW9uIG9yDQpjb250 aW51ZSBzZW5kaW5nIGRhdGEgb24gb3RoZXIgNS10dXBsZXMuIEluIHRoaXMgZHJhZnQgd2Ugc2hv dWxkIGp1c3Qgc2F5DQp0aGF0IHRoZSBlbmRwb2ludCBzdG9wcyB0cmFuc21pc3Npb24gb24gdGhh dCA1LXR1cGxlIGZvciB3aGljaCBjb25zZW50DQpmYWlsZWQgd2hpY2ggaXMgd2hhdCB0aGUgYWJv dmUgdGV4dCBpbiB0aGUgZHJhZnQgc2F5cy4gSU1PIHRoYXQgaXMNCnN1ZmZpY2llbnQuDQoNCg0K Pg0KPg0KPlEyOg0KPi0tLS0tDQo+DQo+SWYgY29uc2VudCBleHBpcmVzLCBhbmQgSSBzdG9wIHNl bmRpbmcgYXBwbGljYXRpb24gZGF0YSwgd2lsbCBJIHN0aWxsDQo+c2VuZCBTVFVOIGtlZXAtYWxp dmVzIGV0YywgdG8ga2VlcCB0aGUgY2FuZGlkYXRlIHBhaXIsIE5BVCBiaW5kaW5ncyBldGMNCj5h bGl2ZT8gDQo+DQo+VGhlcmUgSVMgdGV4dCBzYXlpbmc6DQo+DQo+CSJBbiBlbmRwb2ludCB0aGF0 IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90IG5lZWQgdG8NCj4g ICAJbWFpbnRhaW4gY29uc2VudC4gIEhvd2V2ZXIsIHRoZSBlbmRwb2ludCBuZWVkcyB0byBlbnN1 cmUgaXRzIE5BVCBvcg0KPiAgIAlmaXJld2FsbCBtYXBwaW5ncyBwZXJzaXN0IHdoaWNoIGNhbiBi ZSBkb25lIHVzaW5nIGtlZXBhbGl2ZSBvciBvdGhlcg0KPiAgIAl0ZWNobmlxdWVzIChzZWUgU2Vj dGlvbiAxMCBvZiBbUkZDNTI0NV0gYW5kIHNlZSBbUkZDNjI2M10pLiINCj4NCj5Ib3dldmVyLCB0 aGF0IHNlZW1zIHRvIGJlIG1vcmUgcmVsYXRlZCB0byBjYXNlcyB3aGVyZSBJIGRvbid0IGludGVu ZCB0bw0KPnNlbmQgYXBwbGljYXRpb24gZGF0YSB0byBiZWdpbiB3aXRoLg0KPg0KPlNvLCBwZXJo YXBzIHRoZSB0ZXh0IGFib3ZlIGNhbiBiZSBtb2RpZmllZCwgdG8gY2xhcmlmeSB0aGF0IGtlZXBh bGl2ZXMNCj5ldGMgd2lsbCBzdGlsbCBiZSBzZW50IGlmIGNvbnNlbnQgZXhwaXJlcy4NCg0KDQpB cHBsaWNhdGlvbnMgY2FuIGNvbnRpbnVlcyB0byBkbyB3aGF0IHRoZXkgd2VyZSBkb2luZyBhcyBw YXJ0IG9mIFNUVU4vSUNFDQoobGlrZQ0Kc2VuZGluZyBTVFVOIGJpbmRpbmcgaW5kaWNhdGlvbnMg Zm9yIE5BVC9GVyBrZWVwYWxpdmVzIG9yIHdoYXRldmVyKS4NCiBJZiBzb21lIGFwcGxpY2F0aW9u IHdhbnRzIHRvIGFjdCBvbiBDb25zZW50IGV4cGlyeSBhbmQgZG8gc29tZSB0aGluZyBpdA0KY2Fu IGRvIHNvIGhvd2V2ZXIgc3VjaCBhIHRoaW5nDQppcyBub3QgaW4gdGhlIHNjb3BlIG9mIHRoaXMg ZHJhZnQuIFNvIElNTyB0aGlzIGlzIG91dHNpZGUgc2NvcGUgb2YgdGhpcw0KZHJhZnQgYW5kIGlz IGEgYXBwbGljYXRpb24gcG9saWN5Lg0KDQoNCg0KPg0KPg0KPlEzOg0KPi0tLS0tDQo+DQo+U2Vj dGlvbiA0LjEuIHNheXM6DQo+DQo+CSJJZiB0aGUgZW5kcG9pbnQgd2FudHMgdG8gc2VuZCBhcHBs aWNhdGlvbiBkYXRhLCBpdCBuZWVkcyB0byBmaXJzdCBvYnRhaW4NCj4gICAJY29uc2VudCBpZiBp dHMgY29uc2VudCBoYXMgZXhwaXJlZC4iDQo+DQo+SWYgbXkgY29uc2VudCBoYXMgZXhwaXJlZCwg aXMgdGhlIGEgdGltZSBwZXJpb2QgYmVmb3JlIEkgY2FuIHRyeSB0bw0KPm9idGFpbiBjb25zZW50 IGFnYWluPyBDYW4gSSBqdXN0IGNvbnRpbnVlIHNlbmRpbmcgU1RVTiBiaW5kaW5nIHJlcXVlc3Rz DQo+ZXZlbiBpZiBteSBjb25zZW50IGV4cGlyZXMsIGFuZCB3YWl0IHRvIG9idGFpbiBjb25zZW50 IGFnYWluPw0KDQpBZnRlciBjb25zZW50IGZhaWxzLCBicm93c2VyIG5vdGlmaWVzIHRoZSBqYXZh IHNjcmlwdCBhbmQgdGhlcmUgc2hvdWxkIGJlDQpubyBtZWNoYW5pc20gYXZhaWxhYmxlIGZvciBq YXZhIHNjcmlwdCB0byBhZ2FpbiB0ZWxsIHRoZSBicm93c2VyIHRvIHN0YXJ0DQphbGwgb3ZlciBh Z2FpbiAoY29uc2lkZXIgYSBtYWxpY2lvdXMgamF2YSBzY3JpcHQpOyBJTU8gY29uc2VudCBjYW4g YmUgb25seQ0KYmUgcmUtc3RhcnRlZCB3aXRoIElDRS1yZXN0YXJ0Lg0KDQo+DQo+KEkgb2J2aW91 c2x5IHdvbid0IHNlbmQgYW55IGFwcGxpY2F0aW9uIGRhdGEgdW50aWwgSSBvYnRhaW4gY29uc2Vu dA0KPmFnYWluLikNCj4NCj4NCj5RNDoNCj4tLS0tLQ0KPg0KPldoZW4gbXkgY29uc2VudCBleHBp cmVzLCBpcyBpdCBjb25zaWRlcmVkIGFuIGVycm9yIGlmIEkgYWxzbyBjaG9vc2UgdG8NCj5ub3Qg cmVjZWl2ZSBhbnkgZGF0YT8gSWYgbm90LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaW5k aWNhdGUgdGhhdA0KPm9uZSBtYXkgY2hvb3NlIHRvIGFsc28gc3RvcCByZWNlaXZpbmcgZGF0YSBp biBjYXNlIGNvbnNlbnQgZXhwaXJlcy4NCg0KQ29uc2VudCBjaGVjayBvbmx5IGRlYWxzIHdpdGgg d2hldGhlciB0byBzZW5kIG1lZGlhIG9yIG5vdC4gSWYgQ29uc2VudA0KZmFpbHMgaXQgaXMgdXAg dGhlIGFwcGxpY2F0aW9uIHRvIGRlY2lkZSBvbiB3aGF0IG90aGVyIGFjdGlvbnMgaXQgbmVlZCB0 bw0KdGFrZSAobGlrZSBzdG9wcGluZyByZWNlaXZpbmcgbWVkaWEgZS50LmMpDQoNCg0KDQo+DQo+ DQo+UTU6DQo+LS0tLS0NCj4NCj5Bc3N1bWluZyBJIHNlbmQgUlRQIGFuZCBSVENQIG9uIHNlcGFy YXRlIDUtdHVwbGVzLCBhbmQgY29uc2VudCBleHBpcmVzIG9uDQo+b25lIG9mIHRoZSA1LXR1cGxl cy4gSSBhc3N1bWUgdGhhdCB3aWxsIGltcGFjdCBib3RoIDUtdHVwbGVzLCBhbmQgaW4gdGhhdA0K PmNhc2UgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGNsYXJpZnkuDQoNCkFnYWluIHRoaXMg aXMgYXBwbGljYXRpb24gc3BlY2lmaWMgYmVoYXZpb3VyLiBJZiBjb25zZW50IGZhaWxzIGZvciBv bmUNCjUtdHVwbGUsDQp0aGUgYXBwbGljYXRpb24gY2FuIGNob29zZSB0byBzdG9wIGRhdGEgb24g cmVsYXRlZCA1LXR1cGxlcyBhcyB3ZWxsLiBEb26hr3QNCnNlZQ0KYSBuZWVkIHRvIGhhdmUgc3Vj aCBhIHRleHQgaW4gdGhpcyBkcmFmdC4gV2Ugd2lsbCBoYXZlIHRvIGRvY3VtZW50IHNldmVyYWwN CnN1Y2ggYXBwbGljYXRpb24gYmVoYXZpb3Vycw0KIGlmIHdlIHN0YXJ0IHRvIGRvLg0KDQoNCg0K UmVnYXJkcywNClJhbQ0KDQo+DQo+VGhhbmtzIQ0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXIN Cj4NCg0K From nobody Wed Nov 12 10:41:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F001A8AFA for ; Wed, 12 Nov 2014 10:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qpcxzhE_FM2d for ; Wed, 12 Nov 2014 10:41:33 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF641A0009 for ; Wed, 12 Nov 2014 10:41:33 -0800 (PST) Received: from BLUPR03MB408.namprd03.prod.outlook.com (10.141.78.25) by BLUPR03MB602.namprd03.prod.outlook.com (10.255.124.39) with Microsoft SMTP Server (TLS) id 15.1.16.15; Wed, 12 Nov 2014 18:41:10 +0000 Received: from BLUPR03MB405.namprd03.prod.outlook.com (10.141.78.15) by BLUPR03MB408.namprd03.prod.outlook.com (10.141.78.25) with Microsoft SMTP Server (TLS) id 15.1.11.14; Wed, 12 Nov 2014 18:41:10 +0000 Received: from BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) by BLUPR03MB405.namprd03.prod.outlook.com ([10.141.78.15]) with mapi id 15.01.0016.006; Wed, 12 Nov 2014 18:41:09 +0000 From: Shijun Sun To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal Thread-Index: AQHP/ItB+T0rXRwt30qjr7AkUJAh4JxbaqcggACZwKCAARAGgIAAPPBw Date: Wed, 12 Nov 2014 18:41:09 +0000 Message-ID: <077c566d7b2e4c25b2a16ee14689336a@BLUPR03MB405.namprd03.prod.outlook.com> References: <54601E19.8080203@nostrum.com> <92D0D52F3A63344CA478CF12DB0648AADF312676@XMB111CNC.rim.net> <5463719F.8010400@jesup.org> In-Reply-To: <5463719F.8010400@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1231:999:1eb:c661:539:b098] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB408;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB408; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(3905003)(243025005)(199003)(377454003)(164054003)(33646002)(54356999)(122556002)(105586002)(92566001)(4396001)(76176999)(108616004)(62966003)(77156002)(106116001)(106356001)(21056001)(101416001)(50986999)(19580395003)(97736003)(40100003)(76576001)(15202345003)(2501002)(2656002)(64706001)(31966008)(87936001)(120916001)(107046002)(86612001)(20776003)(107886001)(86362001)(15975445006)(74316001)(46102003)(99286002)(95666004)(99396003)(575784001)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB408; H:BLUPR03MB405.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB602; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GCznWxVgDqiQJeJQdDdoLnMkqco Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 18:41:35 -0000 On Wednesday, November 12, 2014 6:42 AM, Randell Jesup wrote > we haven't yet verified if the Win8 codec meets the WebRTC needs (though = likely it does), and so far as I know it's software-only. Folks interested in leveraging the hardware H.264 codec support on Windows = devices are welcome to check out the Windows Hardware Certification Require= ments [1]. Search for "H.264 encoder" once you have opened the pdf. BTW, = the Skype and Lync applications have been using the hw encoders on Win8.1 d= evices since the Win8.1 release. [1] http://download.microsoft.com/download/F/1/C/F1C62227-2D6A-4915-9EF2-0B= DAE0F323BD/windows8-1-hardware-cert-requirements-device.pdf Thanks, Shijun=20 From nobody Wed Nov 12 11:00:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9889A1ACEB8 for ; Wed, 12 Nov 2014 11:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Lu0bsLd3_2i for ; Wed, 12 Nov 2014 10:59:59 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.137.86]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5361ACEBE for ; Wed, 12 Nov 2014 10:59:59 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 45C21D00436CC; Wed, 12 Nov 2014 12:59:58 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 3385ED0043681 for ; Wed, 12 Nov 2014 12:59:58 -0600 (CST) Received: from [31.133.171.207] (port=54343 helo=dhcp-abcf.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xod93-0001z7-NR for rtcweb@ietf.org; Wed, 12 Nov 2014 12:59:57 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> Date: Wed, 12 Nov 2014 08:59:55 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98200BCB-ABC9-4BE0-B11D-B7AEC9F8B2A4@ieca.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.171.207 X-Exim-ID: 1Xod93-0001z7-NR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-abcf.meeting.ietf.org) [31.133.171.207]:54343 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cxHrSuBRuNTEIMmE64NFH_-fX4o Subject: Re: [rtcweb] The MTI Codec Questions (what to ask and how to ask them) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 12 Nov 2014 19:00:00 -0000 All, Based on the responses receive so far to our "The MTI Codec Questions=94 = mail, we are planning to discuss Adam Roach=92s proposal instead of the = questions that we proposed. At the end of the discussion, we will seek = consensus on it. spt On Nov 03, 2014, at 13:32, Sean Turner wrote: > All, >=20 > One of the remaining major technical decisions for the RTCweb WG is = which codec(s) should be MTI. The issue has been on hold for over 6 = months and the original plan to was the re-attempt determining consensus = at the IETF 91. To make the best use of the WG=92s face-to-face time at = IETF 91, we want to give the WG ample time to digest/discuss the = questions the chairs intend to ask the WG concerning the MTI codec (or = codecs). We want to know before the meeting whether to ask the = questions and then what questions to ask - in other words we want to = inform the WG of the questions before the WG session so as to not waste = time debating what questions should be asked. >=20 > Without further ado, these are the proposed questions: >=20 > Question #0 (hum) >=20 > Do you want to discuss this issue at this meeting? >=20 > Question #1 (stand up) >=20 > Please stand (or signal in the jabber chat) if you will be part of = that consensus process for this question. If you're here to read email = or watch the show, we want to know that your sitting throughout this = isn't expressing opinions for the consensus process. >=20 > To many this might seem like a silly question, > but the chairs believe the problem is well enough > understood by those actively involved WG > participants so we would like to confirm this > understanding. The chairs will also use to the > determine the informed pool of WG participants. =20 >=20 > Question #2 (hum) >=20 > Do you believe we need an MTI codec to avoid negotiation failures? >=20 > Previous attempts at determining the MTI did not > yield a result but did confirm that there is a desire > for an MTI to avoid negotiation failures. Recently, > some on the mailing list have expressed an interest > in postponing this discussion until after IETF 91. The > purpose of this question is to reconfirm the original > consensus. >=20 > Question #3 (open mic) >=20 > Are there any codecs that were not included in the previous consensus = calls that warrant consideration? If yes, which one and why. >=20 > The assumption is that the viable codecs are a) VP8, > b) H.264, or c) VP8 and H.264. This is based on the > extensive poll results from the last consensus calls. > But time has passed so we need to entertain the ever > so slight possibility that another codec has miraculously > appeared. Remember, we want to ensure we=92re going > to get maximum interoperability. >=20 > Question #4 (open mic) >=20 > Are there any new or unaddressed technical issues that will not allow = us to narrow the field to VP8 and H.264? >=20 > We do not want to revisit previous discussions; we only > want new or unaddressed technical issues and will throttle > the discussion accordingly. We=92ll rely on WG participants > and our former RAI AD (Mr. Sparks) for help in this area. >=20 > We believe the technical discussion will fall into two > buckets: > - New or unresolved technical points. > - Licensing. WRT licensing, the IETF tries not discuss > whether IPR is valid, but an IPR issue that can be used > as input to the decision making process is if enough > people say they can=92t/won=92t implement because of the IPR. >=20 > Question #5 (hum) >=20 > With respect to the MTI codec: > - Who can live with a requirement that WebRTC User Agents > MUST support both VP8 and H.264 and WebRTC devices > MUST support either VP8 or H.264? > - Who can live with a requirement that all endpoints MUST support = VP8? > - Who can live with a requirement that all endpoints MUST support = H.264? >=20 > Thanks for your time, > t/c/s > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Nov 12 21:20:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C74C1A1B9E for ; Wed, 12 Nov 2014 21:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 Av9NJm2xLSwv for ; Wed, 12 Nov 2014 21:20:47 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF0F1A1B99 for ; Wed, 12 Nov 2014 21:20:47 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id id10so2808080vcb.18 for ; Wed, 12 Nov 2014 21:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=aEMRGnhTPsPK9ISpV8+X8VjScIAPbJymxbErVpmcCps=; b=IwCsyW6p3sNXCb/ojd3jb8OTFcg3bYfGHPNI7KNfUnXO/4LUDpq1RFkmOy4MKxV9rD NdoZRqXOwuSewoXnE8hi0m+zHtHmw/pxhpFhwS8FPdoAt3XXcqEirMhoBn+g2X2PyYj4 Xm5V1K3ECOcu7MUkYcd5UROBnA/a5FNdRmhvZpx6YPzcsCi9ijdj7Mvys/3bmeAf0+YT P/5TzRx3zFiHgzs9abyc2aqerUkza4qtX8xHh33VeomVCEOpz8uETM6UgUVbFY6UKK7E VfgdsnS5OKMpDXSSGAyofGYIxc/M1EfGb3JH+M0iPkTacfPHym0yAFLnDApgCteSpdpr btqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=aEMRGnhTPsPK9ISpV8+X8VjScIAPbJymxbErVpmcCps=; b=RSmUW6IwwNtvjka7w24x1oO0ofuPU1ycsjGgM68qtRRivfrgF+yYXKv1GoeJtFwKVS xekYzxn+LQWv6iHwvAGdRKnK1eosASg0swVOFozq4P5YhgEzGY0Y3He1KPuRItamTJj0 gToqP6O2ibocZi0xOBbBrdKx5udioa8vWUud0+RbaKQMgW5llVJl6OtBV3ym/eNGWtg3 EwPvgIjJrEa1aTLpsblUZ83XGixCa/j/SyXEphpYT6HlzrdDKzgR3MPjZL/3hEn6e1ov YFkyGe5vLpqwLv+uULp7OcPdit/VxHGs8XLTkOqCToSKMXy6RFBOgWfOPoQE+pvpnvu5 LhBA== X-Gm-Message-State: ALoCoQk1iCRWfo4FhTHk1bb/QX+bzJzuQxWharSLL8lU4YMCe13c2qW2KxYAE4mRfAM3esQwWFZr X-Received: by 10.220.173.69 with SMTP id o5mr84135vcz.35.1415856046222; Wed, 12 Nov 2014 21:20:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Wed, 12 Nov 2014 21:20:26 -0800 (PST) From: Justin Uberti Date: Wed, 12 Nov 2014 21:20:26 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0149c4a6b0507d0507b6ace9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/W5MiInIf6qIYTBhwvMw_PR3KYEE Subject: [rtcweb] On the meaning of b= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 05:20:49 -0000 --089e0149c4a6b0507d0507b6ace9 Content-Type: text/plain; charset=UTF-8 Following up on the JSEP discussion on b= from Monday: Does anyone know whether b= in an offer represents the value the offerer wants to send, or receive? http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-04#section-6.3 seems to indicate it's a send declaration, but I was previously under the impression that it represents the amount to be received. RFC 4566 is ambiguous on the matter [http://tools.ietf.org/html/rfc4566#section-5.8]. --089e0149c4a6b0507d0507b6ace9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following up on the JSEP discussion on b=3D from Monday:
Does anyone know whether b=3D in an offer represents the = value the offerer wants to send, or receive? =C2=A0http://t= ools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-04#section-6.3 = seems to indicate it's a send declaration, but I was previously under t= he impression that it represents the amount to be received. RFC 4566 is amb= iguous on the matter [http://tools.ietf.org/html/rfc4566#section-5.8].


--089e0149c4a6b0507d0507b6ace9-- From nobody Thu Nov 13 08:49:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078941A8AAB for ; Thu, 13 Nov 2014 08:49:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFiqc1w-nBkf for ; Thu, 13 Nov 2014 08:49:46 -0800 (PST) Received: from relay.mailchannels.net (ar-005-i207.relay.mailchannels.net [162.253.144.89]) by ietfa.amsl.com (Postfix) with ESMTP id C92F31A8A7F for ; Thu, 13 Nov 2014 08:49:41 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-220-9-73.us-west-2.compute.internal [10.220.9.73]) by relay.mailchannels.net (Postfix) with ESMTPA id B801C605CB for ; Thu, 13 Nov 2014 16:49:38 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.224.1.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.3.3); Thu, 13 Nov 2014 16:49:38 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1415897378937:979293414 X-MC-Ingress-Time: 1415897378937 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:49297 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XoxaT-000Avv-GK for rtcweb@ietf.org; Thu, 13 Nov 2014 10:49:37 -0600 Message-ID: <5464E10A.6040403@jesup.org> Date: Thu, 13 Nov 2014 11:49:14 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q8hGQdPhbtx4ioI9_dktuQUtVxI Subject: Re: [rtcweb] On the meaning of b= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 16:49:48 -0000 On 11/13/2014 12:20 AM, Justin Uberti wrote: > Following up on the JSEP discussion on b= from Monday: > > Does anyone know whether b= in an offer represents the value the > offerer wants to send, or receive? > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-04#section-6.3 > seems to indicate it's a send declaration, but I was previously under > the impression that it represents the amount to be received. RFC 4566 > is ambiguous on the matter > [http://tools.ietf.org/html/rfc4566#section-5.8]. SDP is a description, but really we want to look at Offer-Answer. In rfc 3264 section 6.1: The answerer MAY include a bandwidth attribute for any media stream; this indicates the bandwidth that the answerer would like the offerer to use when sending media. The value of zero is allowed, interpreted as described in Section 5. and section 7: The offerer SHOULD send media according to the value of any ptime and bandwidth attribute in the answer. So, barring explicit instruction elsewhere for a b= type, those are receiver preferences. This matches something I found out many years ago (likely in AVT archives somewhere) after I had presumed they were "amount I plan to send" (since I had a config for that, I hooked it up to b= as it wasn't clear in the SDP spec alone). Later when I actually started caring about b= (TIAS, etc), I found the error. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Thu Nov 13 11:18:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917F81ACD2E for ; Thu, 13 Nov 2014 11:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 L32d_yfbKgsQ for ; Thu, 13 Nov 2014 11:18:38 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8661ACD39 for ; Thu, 13 Nov 2014 11:10:26 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id id10so3879406vcb.30 for ; Thu, 13 Nov 2014 11:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xuu6GLhRcAxbXwUJsND0Rlhczw70/MHRFGcwMzXlPYs=; b=lBUmq/iIJF4mYF9Kc8Dp6y7RsR8U2FEtLduG+QFBWJ6g0SyI+2oPJ55OAwblZNCCES NWHRp0xyqU3hzsruy1IPHSGmr5r7rIWmbF9de3PqQug6vVOibs+FbxG0c3hF7EaTvbcA hNIZ27eJKFCeYqcb8mBEUmUu5qBkvI3KRajucTMTJ8MquMfoRI4klFBY9LNhMPHOnA6F nyIRAm9KFB3+8hZpITamkDLSry4X6+NpLPc6jCMbwmiJov/9p1sideYssCLX6XA1g2iM /piKN4ch3bTHFOMyBBC28TUm26OL4d9n5AiCBn/PqRf0+D45iXogxDSSr8iXcFwj10mC POEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xuu6GLhRcAxbXwUJsND0Rlhczw70/MHRFGcwMzXlPYs=; b=GvrfUV3ZNAC/8nYghEIFhRHX6nyE5o7i/rb/ybcz0bsy8TlzlpSOkow3aKkp0PI8hb Y7Q8lvyMxonbOKreWGSM/RC5mq8PFtp/t39TvwoS5zxX9G4IQZYCznNP9iUGg8lPl+2z IbATCjyGNCi+XLxRPYtUz7YZ5PzUx9gYur3QPmHEKFc+rZG6FRfzirBQ2QLodMpBcnHv Bhcy7vHl+9kn+rX0blrM8v1qHEEQQfX/Sh9pMJmJtEPwE/YxoKjnqDJ+Mbnx/1bhwITE Kx1uGajqg5WDxPpDQjKc0tmS+oHtDr3CLJRkNMXGQUOCtNtKzG2YUvChmRuGxU3THxIQ /qjg== X-Gm-Message-State: ALoCoQn84Var7/EyV8H6AHPYjxe9H9HP9R3WdqG1y4x3n5kqhGd3ILLxHbr32aIzgnDoWk0/O6fN X-Received: by 10.220.195.132 with SMTP id ec4mr3463022vcb.16.1415905823959; Thu, 13 Nov 2014 11:10:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Thu, 13 Nov 2014 11:10:03 -0800 (PST) In-Reply-To: <5464E10A.6040403@jesup.org> References: <5464E10A.6040403@jesup.org> From: Justin Uberti Date: Thu, 13 Nov 2014 11:10:03 -0800 Message-ID: To: Randell Jesup , Suhas Nandakumar Content-Type: multipart/alternative; boundary=001a11c1ba98ac4f520507c24317 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DG_CbOLbmtQG2VQ6NzaMPsEayKI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] On the meaning of b= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:18:40 -0000 --001a11c1ba98ac4f520507c24317 Content-Type: text/plain; charset=UTF-8 +Suhas as FYI Thanks. That's pretty clear. On Thu, Nov 13, 2014 at 8:49 AM, Randell Jesup wrote: > On 11/13/2014 12:20 AM, Justin Uberti wrote: > >> Following up on the JSEP discussion on b= from Monday: >> >> Does anyone know whether b= in an offer represents the value the offerer >> wants to send, or receive? http://tools.ietf.org/html/ >> draft-ietf-mmusic-sdp-mux-attributes-04#section-6.3 seems to indicate >> it's a send declaration, but I was previously under the impression that it >> represents the amount to be received. RFC 4566 is ambiguous on the matter [ >> http://tools.ietf.org/html/rfc4566#section-5.8]. >> > > SDP is a description, but really we want to look at Offer-Answer. > > In rfc 3264 section 6.1: > > The answerer MAY include a bandwidth attribute for any media stream; > this indicates the bandwidth that the answerer would like the offerer > to use when sending media. The value of zero is allowed, interpreted > as described in Section 5. > > > and section 7: > > The offerer SHOULD send media according to the value of any ptime and > bandwidth attribute in the answer. > > > So, barring explicit instruction elsewhere for a b= type, those are > receiver preferences. This matches something I found out many years ago > (likely in AVT archives somewhere) after I had presumed they were "amount I > plan to send" (since I had a config for that, I hooked it up to b= as it > wasn't clear in the SDP spec alone). Later when I actually started caring > about b= (TIAS, etc), I found the error. > > -- > Randell Jesup -- rjesup a t mozilla d o t com > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c1ba98ac4f520507c24317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+Suhas as FYI

Thanks. That's = pretty clear.

On Thu, Nov 13, 2014 at 8:49 AM, Randell Jesup <randell-ietf@jesup.= org> wrote:
On 11/13/2014 12:20 AM, Justin Uberti wrote:
Following up on the JSEP discussion on b=3D from Monday:

Does anyone know whether b=3D in an offer represents the value the offerer = wants to send, or receive? http://tools.i= etf.org/html/draft-ietf-mmusic-sdp-mux-attributes-04#section-= 6.3 seems to indicate it's a send declaration, but I was previously= under the impression that it represents the amount to be received. RFC 456= 6 is ambiguous on the matter [http://tools.ietf.org/html/rfc4566#s= ection-5.8].

 SDP is a description, but really we want to look at Offer-Answer.

In rfc 3264 section 6.1:

=C2=A0 =C2=A0The answerer MAY include a bandwidth attribute for any media s= tream;
=C2=A0 =C2=A0this indicates the bandwidth that the answerer would like the = offerer
=C2=A0 =C2=A0to use when sending media.=C2=A0 The value of zero is allowed,= interpreted
=C2=A0 =C2=A0as described in Section 5.


and section 7:

=C2=A0 =C2=A0The offerer SHOULD send media according to the value of any pt= ime and
=C2=A0 =C2=A0bandwidth attribute in the answer.


So, barring explicit instruction elsewhere for a b=3D type, those are recei= ver preferences.=C2=A0 This matches something I found out many years ago (l= ikely in AVT archives somewhere) after I had presumed they were "amoun= t I plan to send" (since I had a config for that, I hooked it up to b= =3D as it wasn't clear in the SDP spec alone).=C2=A0 Later when I actua= lly started caring about b=3D (TIAS, etc), I found the error.

--
Randell Jesup -- rjesup a t mozilla d o t com

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

--001a11c1ba98ac4f520507c24317-- From nobody Thu Nov 13 16:51:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC15F1A1A32 for ; Thu, 13 Nov 2014 16:51:49 -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, 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 MV5dTz57Kcdm for ; Thu, 13 Nov 2014 16:51:48 -0800 (PST) Received: from nok-msg-3.service.capgemini.fi (nok-msg-3.service.capgemini.fi [145.247.12.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2971A1A52 for ; Thu, 13 Nov 2014 16:51:47 -0800 (PST) Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-3.service.capgemini.fi with ESMTP; 14 Nov 2014 02:51:45 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 14 Nov 2014 02:51:44 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.0775.031; Fri, 14 Nov 2014 02:51:44 +0200 From: To: , , , Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP7+LLZ1FATfQqEkuoDIJCcWSHI5xfXjHg Date: Fri, 14 Nov 2014 00:51:43 +0000 Message-ID: <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <544AE196.6080907@nostrum.com> In-Reply-To: <544AE196.6080907@nostrum.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.31.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QYXOq-RDFnsDrzXusJTz3n1Pgk4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 00:51:50 -0000 SGkgQWRhbSwgYWxsLA0KDQpTaW5jZSB3ZSBhcmUgZ29pbmcgdG8gZGlzY3VzcyB2aWRlbyBjb2Rl Y3MgdG9kYXksIEkgdGhvdWdodCB0byBjbGFyaWZ5IHNvbWV0aGluZyB0aGF0IHdhcyBzYWlkIGVh cmxpZXIuICANCg0KQWRhbSBSb2FjaCB3cm90ZSAyNS4gbG9rYWt1dXRhIDIwMTQgMjozMw0KPiAN Cj4gT24gMTAvMjIvMTQgMTQ6NDUsIFN0ZXBoYW4gV2VuZ2VyIHdyb3RlOg0KPiA+IC4uLg0KPiA+ IE5va2lhIGhhcyBtYWRlIE1QRUcgYW5kIElTTy9JRUMgb2ZmaWNpYWxseSBhd2FyZSB0aGF0IHRo ZXkgYXJlIG5vdA0KPiA+IHdpbGxpbmcgdG8gbGljZW5zZSBlc3NlbnRpYWwgcGF0ZW50cyB1bmRl ciBSQU5EIHRlcm1zLg0KPj4uLi4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCj4gDQo+ IFRoYXQncyBhY3R1YWxseSBldmVuIG1vcmUgaW50ZXJlc3RpbmcgdGhhbiBpdCBmaXJzdCBhcHBl YXJzIHRvIGJlLiBUaGUgb2ZmaWNpYWwNCj4gcmF0aW9uYWxlIHByZXZpb3VzbHkgb2ZmZXJlZCBi eSBOb2tpYSB3YXMgdGhhdCB0aGUgcmVmdXNhbCB0byBsaWNlbnNlIHBhdGVudHMNCj4gWzBdIGZv ciBWUDggd2FzIHRoYXQgVlA4IGhhZCBub3QgYmVlbiB0aHJvdWdoIGFuIGFwcHJvcHJpYXRlIHN0 YW5kYXJkcw0KPiBwcm9jZXNzIFsxXS4gVGhlIGZhY3QgdGhhdCBOb2tpYSBpcyBub3cgdXNpbmcg dGhvc2Ugc2FtZSBwYXRlbnRzIHRvICpibG9jayoNCj4gVlA4LWJhc2VkIHdvcmsgZnJvbSBnb2lu ZyB0aHJvdWdoIGFuIGFwcHJvcHJpYXRlIHN0YW5kYXJkcyBwcm9jZXNzIHByZXR0eQ0KPiBjbGVh cmx5IGV4cG9zZXMgdGhhdCBjbGFpbSBhcyBmYWxzZS4gVGhpcyBpc24ndCBhaW1lZCBhdCBlbnN1 cmluZyAib3BlbiBhbmQNCj4gY29sbGFib3JhdGl2ZSBlZmZvcnRzIGZvcg0KPiBzdGFuZGFyZGl6 YXRpb24iOiB0aGlzIGlzIGFpbWVkIGF0IHN1cHByZXNzaW5nIHRlY2hub2xvZ3kuDQo+IA0KDQpU aGUga2V5IGhlcmUgaXMgIm9wZW4gYW5kIGNvbGxhYm9yYXRpdmUgZWZmb3J0cyBmb3Igc3RhbmRh cmRpemF0aW9uIiwgdGhvdWdoLiBOb2tpYSBkb2VzIG5vdCB0aGluayB0aGUgKndheSogVlA4IGhh cyBiZWVuIGRlYWx0IHdpdGggaW4gTVBFRyBtZWV0cyB0aGF0IGNyaXRlcmlhLiBDb2xsYWJvcmF0 aXZlIGVmZm9ydCBtZWFucyB0aGF0IGFsbCBpbnRlcmVzdGVkIHBhcnRpZXMgYWN0dWFsbHkgaGF2 ZSBhIGZhaXIgY2hhbmNlIHRvIGNvbnRyaWJ1dGUuIFdpdGggVlA4IGluIE1QRUcgdGhpcyBoYXMg bm90IGJlZW4gdGhlIGNhc2UsIGJ1dCBpdCBoYXMgYmVlbiBqdXN0IGEgbWF0dGVyIG9mIHB1c2hp bmcgYSByZWFkeS1tYWRlIHRlY2hub2xvZ3kgdGhyb3VnaCB3aXRoIG5vIGNoYW5nZXMgaW4gcHJh Y3RpY2UgcG9zc2libGUuIEZvciB0aG9zZSB3aG8gYXJlIGp1c3QgYSB1c2VyIG9mIHZpZGVvIGNv ZGVjcyBsaWtlIFdlYlJUQyBpcywgaXQgbWF5IG5vdCBtYXR0ZXIgaG93IHRoZSBjb2RlY3MgYXJl IGRldmVsb3BlZCBvciB3aGVyZSB0aGV5IGNvbWUgZnJvbSBhcyBsb25nIGFzIHRoZXkgd29yaywg YnV0IGZvciB0aG9zZSB3aG8gYWN0dWFsbHkgZG8gY29kZWMgZGV2ZWxvcG1lbnQgaXQgZG9lcy4g VGhlcmUgaGFzIGJlZW4gc29tZSBjcml0aWNpc20gb3ZlciBob3cgT3B1cyB3YXMgZGV2ZWxvcGVk IHRvbywgYnV0IGl0IHdhcyBjZXJ0YWlubHkgYSBtdWNoIG1vcmUgb3BlbiBhbmQgY29sbGFib3Jh dGl2ZSBtb2RlbCB0aGFuIHdoYXQgaGFzIGhhcHBlbmVkIHdpdGggVlA4IGluIE1QRUcuIA0KDQpT byB0aGUgb3JpZ2luYWwgcmVhc29ucyBmb3IgTm9raWEncyAidW53aWxsaW5nIHRvIGxpY2Vuc2Ug dW5kZXIgUkYgb3IgUkFORCIgZGVjbGFyYXRpb25zIGFyZSBzdGlsbCB2YWxpZC4gSSdtIHN1cmUg cGVvcGxlIGhhdmUgYSBsb3Qgb2YgZGlmZmVyZW50IHZpZXdzIG9uIHRoaXMgYW5kIHRoZSBNUEVH IHByb2Nlc3MsIGJ1dCBJIGp1c3Qgd2FudGVkIHRvIGNvbnZleSBOb2tpYSdzIHZpZXdwb2ludC4g QW5kIEkga25vdyB0aGVyZSBhcmUgYWxzbyBsb3Qgb2YgY29tcGFuaWVzL3Blb3BsZSB3aG8gYWdy ZWUgd2l0aCBpdC4NCg0KUGVyc29uYWxseSBJJ20gc2FkIHRvIHNlZSB0aGVzZSB0eXBlcyBvZiBp c3N1ZXMgZ2V0dGluZyBpbiB0aGUgd2F5IG9mIGludGVyb3BlcmFiaWxpdHksIGJ1dCB0aGF0IGhh cyB1bmZvcnR1bmF0ZWx5IGJlZW4gdGhlIHN0b3J5IHdpdGggdGhlIHZpZGVvIGNvZGVjcyBmb3Ig YSB3aGlsZS4gSXQgc2VlbXMgdGhlIG5leHQgZ2VuZXJhdGlvbiB2aWRlbyBjb2RlY3MgYXJlIGZh Y2luZyB0aGUgZXhhY3Qgc2FtZSBpc3N1ZSwgaG9wZWZ1bGx5IHRoZSBuZXh0LW5leHQgZ2VuZXJh dGlvbiB3aWxsIGJlIGJldHRlciBvZmYuLi4NCg0KUmVnYXJkcywNCglNYXJrdXMgDQo= From nobody Thu Nov 13 16:52:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76BD1A1A32 for ; Thu, 13 Nov 2014 16:52:32 -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 OasurRQVaniL for ; Thu, 13 Nov 2014 16:52:26 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9047B1A1A58 for ; Thu, 13 Nov 2014 16:52:26 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so18200253wgh.20 for ; Thu, 13 Nov 2014 16:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=CC3JVXPMMGo3y7kC2hN1OHPz7pZlM/UJuH9+FaczrFU=; b=mpgO1gQzm3fYvITfa0D/P42EktfzjvMgL7Sk4eyalvQ1kIPEdWG1BsxcACkIYq8hQ7 DU8Tc9Jbm7r/dLKJlSL3Y/t6g+lKo+rTSfv0q4MoogoWna96OHqKI4WvhHFZ/etl0EDa 4wmFMJJAmQwCVR05Y8EsKR8mZYBkS/G63NZkIHtkYqOgH6PL0fNPLavVCwuPZ9ao6Tam DPlrxvJvyCiPBrguQ7WdDNl1YVYEzy0rCvP7b+joEhAbPBzxuUe6j98+bE1ZGb7ji+vg qU3Sd/BDdBn0JKhCJwN0u5Noia2A2EXAQw2YVcqka+Vha4IkAmrbdy+rjN8gACrMrPZc iukA== X-Received: by 10.180.80.39 with SMTP id o7mr2705631wix.37.1415926345363; Thu, 13 Nov 2014 16:52:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.217.134.196 with HTTP; Thu, 13 Nov 2014 16:52:05 -0800 (PST) From: Bernard Aboba Date: Thu, 13 Nov 2014 14:52:05 -1000 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d0418253ad7f8470507c70aae Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pLKvOMKVWroiDr0Kc-gH4_yOkk4 Subject: [rtcweb] Plan for discussion of MTI codec proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 00:52:34 -0000 --f46d0418253ad7f8470507c70aae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sean Turner said: "All, Based on the responses receive so far to our "The MTI Codec Questions=E2=80=9D mail, we are planning to discuss Adam Roach=E2=80=99s pr= oposal instead of the questions that we proposed. At the end of the discussion, we will seek consensus on it. spt" [BA] This is a major agenda change made a day before the meeting. Is one of the consequences of the above to preclude discussion of technical and licensing issues as originally proposed below? For example, I believe that there is new information worth discussing in both of the below categories in the following documents: https://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal https://tools.ietf.org/html/draft-benham-rtcweb-vp8litigation > We believe the technical discussion will fall into two > buckets: > - New or unresolved technical points. > - Licensing. WRT licensing, the IETF tries not discuss > whether IPR is valid, but an IPR issue that can be used > as input to the decision making process is if enough > people say they can=E2=80=99t/won=E2=80=99t implement because of t= he IPR. --f46d0418253ad7f8470507c70aae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sean Turner said:
"All, Based on the responses receive so far to our "The MTI Codec Questions= =E2=80=9D mail, we are planning to discuss Adam Roach=E2=80=99s proposal in= stead of the questions that we proposed. At the end of the discussion, we = will seek consensus on it. spt"

[BA] This is a major agenda change made = a day before the meeting. Is one=C2=A0of the consequences of the above to p= reclude discussion of technical and licensing issues as originally proposed= below?=C2=A0=C2=A0For example,=C2=A0I believe that there is new informatio= n=C2=A0worth discussing in both of the below categories in=C2=A0the followi= ng documents: =C2=A0


>=C2=A0=C2= =A0=C2=A0 We believe the technical discussion will fall into two
>=C2= =A0=C2=A0=C2=A0 buckets:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - New or unr= esolved technical points.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - Licensing= .=C2=A0 WRT licensing, the IETF tries not discuss
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 whether IPR is valid, but an IPR issue that can be= used
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as input to the dec= ision making process is if enough
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 people say they can=E2=80=99t/won=E2=80=99t implement because of = the IPR.
--f46d0418253ad7f8470507c70aae-- From nobody Thu Nov 13 18:21:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7E01A1B46 for ; Thu, 13 Nov 2014 18:21:23 -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 IhF7G_rcxvPl for ; Thu, 13 Nov 2014 18:21:20 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC7C1A1B27 for ; Thu, 13 Nov 2014 18:21:20 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so1291394wiw.15 for ; Thu, 13 Nov 2014 18:21:19 -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=x/iSFHx01J53Tof32zRFXEExZtRehDAEKU6O/3Mvw4w=; b=Q7oeE/4gSPFmScVGtUJezGtHrk6xAQFJqiiAzVeF+4OX1V0yqxTXdaDQxO2Xn7f9z5 4BK+64Dp5NB/YPudfuevdlOuzaxBxo/WVxZuzRrkpuTvKYgjL3gYy9ppCxgU4SixJEOi S1BM8EuYJXHK6opR5Tc/DtU+RxFccJU+l+in3lVuu3P4qzkgTG+4Ml+iviA7svBIMm+1 oVuuvILLQOYSxc0AId9hmKYoOy8IHb79iHne1rkkSR6Xd3G8dDGVtPG8xM5z9aRcOeXp QZRw4LKUcPl1j7JK9ata2muijdNZMqSchIsim316RMS1lTFqTbN44afGQ51b28VZ+DcD gl/A== X-Gm-Message-State: ALoCoQkyhiuTzXRO0sOaWIPNueAgp+sZDSUMVZqT+MIj9s72rfLZ99A+gJxLkxjgBkDoUdHMFYrO X-Received: by 10.194.176.198 with SMTP id ck6mr9023053wjc.25.1415931679074; Thu, 13 Nov 2014 18:21:19 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com. [74.125.82.52]) by mx.google.com with ESMTPSA id r10sm1531227wiy.13.2014.11.13.18.21.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 18:21:17 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so18143723wgh.25 for ; Thu, 13 Nov 2014 18:21:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr9422130wjb.71.1415931677502; Thu, 13 Nov 2014 18:21:17 -0800 (PST) Received: by 10.216.176.65 with HTTP; Thu, 13 Nov 2014 18:21:17 -0800 (PST) In-Reply-To: <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> References: <544035DE.8000606@matthew.at> <544117FB.6050706@alvestrand.no> <544AE196.6080907@nostrum.com> <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> Date: Thu, 13 Nov 2014 21:21:17 -0500 Message-ID: From: Roman Shpount To: markus.isomaki@nokia.com Content-Type: multipart/alternative; boundary=047d7bd910c2a9f4e80507c848c4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e1yOIxDbljT1A2yjImBVvukY5Ms Cc: watsonbladd@gmail.com, "rtcweb@ietf.org" Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 02:21:24 -0000 --047d7bd910c2a9f4e80507c848c4 Content-Type: text/plain; charset=UTF-8 Markus, Not to be harsh, but all of this to me this sounds like Nokia is trying to sabotage any chance for MTI in any foreseeable future since it was not consulted when VP8 was developed and is not part of VP9 development process. Since Nokia is not offering anything constructive, such as any concrete steps on how to resolve this situation, these motives seems to me childish at best. At worst this is typical patent trolling. _____________ Roman Shpount On Thu, Nov 13, 2014 at 7:51 PM, wrote: > Hi Adam, all, > > Since we are going to discuss video codecs today, I thought to clarify > something that was said earlier. > > Adam Roach wrote 25. lokakuuta 2014 2:33 > > > > On 10/22/14 14:45, Stephan Wenger wrote: > > > ... > > > Nokia has made MPEG and ISO/IEC officially aware that they are not > > > willing to license essential patents under RAND terms. > >>... > > > > Thanks for the update. > > > > That's actually even more interesting than it first appears to be. The > official > > rationale previously offered by Nokia was that the refusal to license > patents > > [0] for VP8 was that VP8 had not been through an appropriate standards > > process [1]. The fact that Nokia is now using those same patents to > *block* > > VP8-based work from going through an appropriate standards process pretty > > clearly exposes that claim as false. This isn't aimed at ensuring "open > and > > collaborative efforts for > > standardization": this is aimed at suppressing technology. > > > > The key here is "open and collaborative efforts for standardization", > though. Nokia does not think the *way* VP8 has been dealt with in MPEG > meets that criteria. Collaborative effort means that all interested parties > actually have a fair chance to contribute. With VP8 in MPEG this has not > been the case, but it has been just a matter of pushing a ready-made > technology through with no changes in practice possible. For those who are > just a user of video codecs like WebRTC is, it may not matter how the > codecs are developed or where they come from as long as they work, but for > those who actually do codec development it does. There has been some > criticism over how Opus was developed too, but it was certainly a much more > open and collaborative model than what has happened with VP8 in MPEG. > > So the original reasons for Nokia's "unwilling to license under RF or > RAND" declarations are still valid. I'm sure people have a lot of different > views on this and the MPEG process, but I just wanted to convey Nokia's > viewpoint. And I know there are also lot of companies/people who agree with > it. > > Personally I'm sad to see these types of issues getting in the way of > interoperability, but that has unfortunately been the story with the video > codecs for a while. It seems the next generation video codecs are facing > the exact same issue, hopefully the next-next generation will be better > off... > > Regards, > Markus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd910c2a9f4e80507c848c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Markus,

Not to be harsh, but all of thi= s to me this sounds like Nokia is trying to sabotage any chance for MTI in = any foreseeable future since it was not consulted when VP8 was developed an= d is not part of VP9 development process. Since Nokia is not offering anyth= ing constructive, such as any concrete steps on how to resolve this situati= on, these motives seems to me childish at best. At worst this is typical pa= tent trolling.=C2=A0

_____________
Roman Shpount
<= /div>
On Thu, Nov 13, 2014 at 7:51 PM, <= markus.isomaki@nokia.com> wrote:
Hi Adam, all,

Since we are going to discuss video codecs today, I thought to clarify some= thing that was said earlier.

Adam Roach wrote 25. lokakuuta 2014 2:33
>
> On 10/22/14 14:45, Stephan Wenger wrote:
> > ...
> > Nokia has made MPEG and ISO/IEC officially aware that they are no= t
> > willing to license essential patents under RAND terms.
>>...
>
> Thanks for the update.
>
> That's actually even more interesting than it first appears to be.= The official
> rationale previously offered by Nokia was that the refusal to license = patents
> [0] for VP8 was that VP8 had not been through an appropriate standards=
> process [1]. The fact that Nokia is now using those same patents to *b= lock*
> VP8-based work from going through an appropriate standards process pre= tty
> clearly exposes that claim as false. This isn't aimed at ensuring = "open and
> collaborative efforts for
> standardization": this is aimed at suppressing technology.
>

The key here is "open and collaborative efforts for standardization&qu= ot;, though. Nokia does not think the *way* VP8 has been dealt with in MPEG= meets that criteria. Collaborative effort means that all interested partie= s actually have a fair chance to contribute. With VP8 in MPEG this has not = been the case, but it has been just a matter of pushing a ready-made techno= logy through with no changes in practice possible. For those who are just a= user of video codecs like WebRTC is, it may not matter how the codecs are = developed or where they come from as long as they work, but for those who a= ctually do codec development it does. There has been some criticism over ho= w Opus was developed too, but it was certainly a much more open and collabo= rative model than what has happened with VP8 in MPEG.

So the original reasons for Nokia's "unwilling to license under RF= or RAND" declarations are still valid. I'm sure people have a lot= of different views on this and the MPEG process, but I just wanted to conv= ey Nokia's viewpoint. And I know there are also lot of companies/people= who agree with it.

Personally I'm sad to see these types of issues getting in the way of i= nteroperability, but that has unfortunately been the story with the video c= odecs for a while. It seems the next generation video codecs are facing the= exact same issue, hopefully the next-next generation will be better off...=

Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Markus
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bd910c2a9f4e80507c848c4-- From nobody Thu Nov 13 18:43:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD6C1A1AF8 for ; Thu, 13 Nov 2014 18:42:59 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO34G1GUs6EH for ; Thu, 13 Nov 2014 18:42:56 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 241B61A1ADA for ; Thu, 13 Nov 2014 18:42:55 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail05.adl6.internode.on.net with ESMTP; 14 Nov 2014 13:12:54 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id A6935FFEDC for ; Fri, 14 Nov 2014 13:12:53 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JVTIdejYnjdf for ; Fri, 14 Nov 2014 13:12:52 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 91AF8FFC9E for ; Fri, 14 Nov 2014 13:12:52 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7E50980470; Fri, 14 Nov 2014 13:12:52 +1030 (ACDT) Date: Fri, 14 Nov 2014 13:12:52 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141114024252.GD10827@hex.shelbyville.oz> References: <544117FB.6050706@alvestrand.no> <544AE196.6080907@nostrum.com> <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EkdSwaWfyGmaM7sK97whQCqq66o Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 02:42:59 -0000 On Fri, Nov 14, 2014 at 12:51:43AM +0000, markus.isomaki@nokia.com wrote: > Hi Adam, all, > > Since we are going to discuss video codecs today, I thought to clarify something that was said earlier. > > Adam Roach wrote 25. lokakuuta 2014 2:33 > > > > On 10/22/14 14:45, Stephan Wenger wrote: > > > ... > > > Nokia has made MPEG and ISO/IEC officially aware that they are not > > > willing to license essential patents under RAND terms. > >>... > > > > Thanks for the update. > > > > That's actually even more interesting than it first appears to be. The official > > rationale previously offered by Nokia was that the refusal to license patents > > [0] for VP8 was that VP8 had not been through an appropriate standards > > process [1]. The fact that Nokia is now using those same patents to *block* > > VP8-based work from going through an appropriate standards process pretty > > clearly exposes that claim as false. This isn't aimed at ensuring "open and > > collaborative efforts for > > standardization": this is aimed at suppressing technology. > > > > The key here is "open and collaborative efforts for standardization", > though. Nokia does not think the *way* VP8 has been dealt with in MPEG > meets that criteria. Collaborative effort means that all interested > parties actually have a fair chance to contribute. With VP8 in MPEG > this has not been the case, but it has been just a matter of pushing a > ready-made technology through with no changes in practice possible. I'm not clear on how you think you were denied a "fair chance" here? Is Nokia saying they *tried* to contribute something of real value to VP8 and were rebuffed? Or are you just saying the usual game of everybody trying to stack a proposed technology with their own "essential" patents didn't play out because this one was carefully written to avoid them? One of these would confirm Adam's observation. The other I believe, would actually be New Information. > For those who are just a user of video codecs like WebRTC is, it may > not matter how the codecs are developed or where they come from as > long as they work, but for those who actually do codec development it > does. There has been some criticism over how Opus was developed too, > but it was certainly a much more open and collaborative model than > what has happened with VP8 in MPEG. Was that "criticism" made in public somewhere, or do you mean there was some internal griping that it also sought to avoid proprietary encumbrances and you were unable to poison the well with it too? I certainly don't recall ever seeing such criticism about the process the IETF followed with it, and actual contributions which were warmly welcomed came from many individuals and organisations. Including several where IPR was donated under RF terms. IIRC Nokia did some listening tests, but I don't recall them ever actually attempting to contribute any technology or ideas to the development of it. If my memory is simply failing me, I'd welcome some pointers to things which back up your claims here to refresh it. From nobody Thu Nov 13 19:12:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF441A1BA3 for ; Thu, 13 Nov 2014 19:12:06 -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, 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 A0Jsfef9bwtV for ; Thu, 13 Nov 2014 19:12:04 -0800 (PST) Received: from nok-msg-3.service.capgemini.fi (nok-msg-3.service.capgemini.fi [145.247.12.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBF21A1BEC for ; Thu, 13 Nov 2014 19:12:02 -0800 (PST) Received: from unknown (HELO NOKWDCFIEXCH01P.nnok.nokia.com) ([10.50.38.49]) by noi-msg-3.service.capgemini.fi with ESMTP; 14 Nov 2014 05:12:01 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH01P.nnok.nokia.com (10.50.38.49) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 14 Nov 2014 05:12:00 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.0775.031; Fri, 14 Nov 2014 05:11:55 +0200 From: To: , Thread-Topic: [rtcweb] Plan for MTI video codec? Thread-Index: AQHP7+LLZ1FATfQqEkuoDIJCcWSHI5xfXjHggAAJ4QCAACXy0A== Date: Fri, 14 Nov 2014 03:11:54 +0000 Message-ID: <19c4eaabf2e9420c833f86a2ab0f9bdb@NOKWDCFIEXCH02P.nnok.nokia.com> References: <544117FB.6050706@alvestrand.no> <544AE196.6080907@nostrum.com> <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> <20141114024252.GD10827@hex.shelbyville.oz> In-Reply-To: <20141114024252.GD10827@hex.shelbyville.oz> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.31.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jsLe1wmLXXvCx3PTi7sW1Z4zjVI Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 03:12:06 -0000 Hi, Ron wrote: > > >There has been some criticism over how Opus was developed too, > > but it was certainly a much more open and collaborative model than > > what has happened with VP8 in MPEG. >=20 > Was that "criticism" made in public somewhere, ... > >... >=20 > If my memory is simply failing me, I'd welcome some pointers to things wh= ich > back up your claims here to refresh it. >=20 http://www.ietf.org/proceedings/85/slides/slides-85-videocodec-7.pdf (But I don't think we should continue this discussion at RTCWEB list. The p= oint was not to bash the Opus process, on the contrary.)=20 Markus=20 From nobody Thu Nov 13 21:49:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4141A7011 for ; Thu, 13 Nov 2014 21:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgEIsUbaqcj3 for ; Thu, 13 Nov 2014 21:49:30 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5BF1A6FFB for ; Thu, 13 Nov 2014 21:49:28 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id n3so4088450wiv.0 for ; Thu, 13 Nov 2014 21:49: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mcD3JAy2u0cmuNoYf7zbf9meDyPFx2dPag3rXLkCvo4=; b=j1D3setJYlfEAx8QgcDFSWiLBh3bj84tZVWT/YPKKudgLmOCVIDj/uqDpIam9Ytmpt F4kJLQGsECccCjJhWV44gzOBfKN4UMn6MsKcX6hldo8YJtF1eNmp55+0Ed1SZeOXmASq liMI9UKwLO/APhJeuP+GaN1YQ76KaCx8FORtXYmf1VZjuJwzkvGjhI7ShtMOP8r6MGw+ mmc3z0+mUsjX84aisoaWWUyQyKQ2Pi2i4T1fgHKKpgVJA4032pVrPADCiZih1v88Tl8V b4r4KAUB8AN1mzHeuEUVPFGXV6NsIihzq2kRtaHP4BJszityCJKZaYLHd9wyZBEDxhJA Stgg== X-Gm-Message-State: ALoCoQnkTaazfaphmRgpS3LkTW48EcF4QVsUXi3CLCyqHbAj2z4fiWJjCsl/g+Zx2JEdFIXA1yDS MIME-Version: 1.0 X-Received: by 10.180.78.234 with SMTP id e10mr4527065wix.32.1415944167414; Thu, 13 Nov 2014 21:49:27 -0800 (PST) Received: by 10.194.152.169 with HTTP; Thu, 13 Nov 2014 21:49:27 -0800 (PST) Received: by 10.194.152.169 with HTTP; Thu, 13 Nov 2014 21:49:27 -0800 (PST) In-Reply-To: <19c4eaabf2e9420c833f86a2ab0f9bdb@NOKWDCFIEXCH02P.nnok.nokia.com> References: <544117FB.6050706@alvestrand.no> <544AE196.6080907@nostrum.com> <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> <20141114024252.GD10827@hex.shelbyville.oz> <19c4eaabf2e9420c833f86a2ab0f9bdb@NOKWDCFIEXCH02P.nnok.nokia.com> Date: Fri, 14 Nov 2014 07:49:27 +0200 Message-ID: From: Mohammed Raad To: markus.isomaki@nokia.com Content-Type: multipart/alternative; boundary=f46d043be1d21ef42d0507cb314b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fzkhTJOERyMIDaL4f_n-TQDNrXk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 05:49:32 -0000 --f46d043be1d21ef42d0507cb314b Content-Type: text/plain; charset=UTF-8 Markus, Nokia made no technical contributions to VCB (the MPEG name for the VP8 compatible standard under development). Nokia had plenty of opportunities to do so. Google had even suggested to MPEG a technical criteria for accepting new technology into VCB. Nokia could have taken the initiative and made a technical contribution to at least test that offer. Instead Nokia sent us a patent declaration that said Nokia would not license it's patents reading on VCB without telling MPEG which patents the Nokia people think read on VCB. How you consider this a defence of open standards development is beyond me. The funny thing is that it was Nokia people pushing for more challenging visual tests at MPEG for VCB. Well, we know how that turned out. Mohammed On 14 Nov 2014 05:12, wrote: > Hi, > > Ron wrote: > > > > >There has been some criticism over how Opus was developed too, > > > but it was certainly a much more open and collaborative model than > > > what has happened with VP8 in MPEG. > > > > Was that "criticism" made in public somewhere, ... > > > >... > > > > If my memory is simply failing me, I'd welcome some pointers to things > which > > back up your claims here to refresh it. > > > > http://www.ietf.org/proceedings/85/slides/slides-85-videocodec-7.pdf > > (But I don't think we should continue this discussion at RTCWEB list. The > point was not to bash the Opus process, on the contrary.) > > Markus > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d043be1d21ef42d0507cb314b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Markus,

Nokia made no technical contributions to VCB (the MPEG name = for the VP8 compatible standard under development). Nokia had plenty of opp= ortunities to do so. Google had even suggested to MPEG a technical criteria= for accepting new technology into VCB. Nokia could have taken the initiati= ve and made a technical contribution to at least test that offer. Instead N= okia sent us a patent declaration that said Nokia would not license it'= s patents reading on VCB without telling MPEG which patents the Nokia peopl= e think read on VCB. How you consider this a defence of open standards deve= lopment is beyond me.

The funny thing is that it was Nokia people pushing for more= challenging visual tests at MPEG for VCB. Well, we know how that turned ou= t.

Mohammed

On 14 Nov 2014 05:12, <markus.isomaki@nokia.com> wrote:
Hi,

Ron wrote:
>
> >There has been some criticism over how Opus was developed too,
> > but it was certainly a much more open and collaborative model tha= n
> > what has happened with VP8 in MPEG.
>
> Was that "criticism" made in public somewhere, ...
>
>...
>
> If my memory is simply failing me, I'd welcome some pointers to th= ings which
> back up your claims here to refresh it.
>

http://www.ietf.org/proceedings/85/slides/slides-85= -videocodec-7.pdf

(But I don't think we should continue this discussion at RTCWEB list. T= he point was not to bash the Opus process, on the contrary.)

Markus

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--f46d043be1d21ef42d0507cb314b-- From nobody Thu Nov 13 23:18:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DC61A6EF1 for ; Thu, 13 Nov 2014 23:18:36 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq129C_wB6BG for ; Thu, 13 Nov 2014 23:18:34 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 498091A0104 for ; Thu, 13 Nov 2014 23:18:34 -0800 (PST) Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail06.adl6.internode.on.net with ESMTP; 14 Nov 2014 17:47:58 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 93E0EFFEDC for ; Fri, 14 Nov 2014 17:47:56 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ECxU8Q8W-PvV for ; Fri, 14 Nov 2014 17:47:53 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 40FA9FFCAD for ; Fri, 14 Nov 2014 17:47:53 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 2FA8A80470; Fri, 14 Nov 2014 17:47:53 +1030 (ACDT) Date: Fri, 14 Nov 2014 17:47:53 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141114071753.GE10827@hex.shelbyville.oz> References: <544AE196.6080907@nostrum.com> <5a86546928b841e9b063354de2aa279d@NOKWDCFIEXCH02P.nnok.nokia.com> <20141114024252.GD10827@hex.shelbyville.oz> <19c4eaabf2e9420c833f86a2ab0f9bdb@NOKWDCFIEXCH02P.nnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19c4eaabf2e9420c833f86a2ab0f9bdb@NOKWDCFIEXCH02P.nnok.nokia.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4HodAKL2Eo8D0jqOudhIPchXa1o Subject: Re: [rtcweb] Plan for MTI video codec? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 07:18:36 -0000 On Fri, Nov 14, 2014 at 03:11:54AM +0000, markus.isomaki@nokia.com wrote: > Hi, > > Ron wrote: > > > > >There has been some criticism over how Opus was developed too, > > > but it was certainly a much more open and collaborative model than > > > what has happened with VP8 in MPEG. > > > > Was that "criticism" made in public somewhere, ... > > > >... > > > > If my memory is simply failing me, I'd welcome some pointers to things which > > back up your claims here to refresh it. > > > > http://www.ietf.org/proceedings/85/slides/slides-85-videocodec-7.pdf I don't see any of that making a complaint about the process that was followed or its openness. Just a 20/20 hindsight look at things we learned that could have been done earlier in the process than they actually were. Considering the amount of new ground we were breaking in the IETF with that group, a "debrief" like that seems like both a valuable part of the process itself, and a measure of praise if that's really the worst mistakes we made somewhere along the line on the first attempt. > (But I don't think we should continue this discussion at RTCWEB list. > The point was not to bash the Opus process, on the contrary.) I wasn't really aiming to revisit Opus here, I was trying to figure out what your definition of "open and collaborative efforts for standardization" actually was. We've been told repeatedly that the ISO is an "open standards process" by the proponents of H.264. Now you seem to be telling us that it's not. I'm curious about the measure we are supposed to apply to tell the difference. From nobody Fri Nov 14 09:36:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C51A1B22; Fri, 14 Nov 2014 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjWwrsA2d4Ov; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B6A1A1B14; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9F109F68A2C77; Fri, 14 Nov 2014 17:36:05 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sAEHa86J013836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 18:36:08 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 18:36:08 +0100 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" , "mmusic@ietf.org" , CLUE , "avt@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Thread-Index: AQHQAAM2TU9IvAskwUumiAHVoVNISJxgYKPwgAABkqA= Date: Fri, 14 Nov 2014 17:36:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B27B43B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QROBpb-SGjjRzvgQ9MK2oD0sG8w Subject: [rtcweb] FW: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:36:12 -0000 This is to bring your attention to the following WGLC, in which your workin= g group may have some interest. Please send your comments to avtext@ietf.org If you are not a member of that list, then please still use that address, a= nd we will release it from the moderator queue when we receive notification= . Regards Keith=20 -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Ke= ith) Sent: 14 November 2014 17:32 To: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t (As WG cochair)=20 This is to start a working group last call on draft-ietf-avtext-rtp-groupin= g-taxonomy-03. To cater for the end of the IETF meeting, and for various national holidays= , this working group last call will last three weeks. Therefore please comment on this document by Friday 5th December 2014. Please send comments to the working group list. It is helpful to give some assessment of the nature of your comment, as to = whether you regard it as editorial, minor technical, or a rather more major= flaw. Regards Keith -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 14 November 2014 12:05 To: i-d-announce@ietf.org Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Working = Group of the IETF. Title : A Taxonomy of Grouping Semantics and Mechanisms f= or Real-Time Transport Protocol (RTP) Sources Authors : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Pages : 42 Date : 2014-11-14 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxonomy-= 03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Sat Nov 15 13:05:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096651A6FEB for ; Sat, 15 Nov 2014 13:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RHiyWLnU0EM for ; Sat, 15 Nov 2014 13:05:01 -0800 (PST) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D591A6FEE for ; Sat, 15 Nov 2014 13:05:00 -0800 (PST) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1XpkWf-0008Gf-AA; Sat, 15 Nov 2014 22:04:57 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1XpkWf-0007bc-2Q; Sat, 15 Nov 2014 22:04:57 +0100 From: Florian Weimer To: Gaelle Martin-Cocher References: <54601E19.8080203@nostrum.com> <92D0D52F3A63344CA478CF12DB0648AADF312676@XMB111CNC.rim.net> Date: Sat, 15 Nov 2014 22:04:57 +0100 In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF312676@XMB111CNC.rim.net> (Gaelle Martin-Cocher's message of "Tue, 11 Nov 2014 22:41:02 +0000") Message-ID: <87egt45g5i.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V5Xli-y1RxNSf9qb7RS2lQasAYY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Nov 2014 21:05:05 -0000 * Gaelle Martin-Cocher: > Some device/OS vendors have released API to hardware supported codec > (BlackBerry included). One of the goal is to offer codec access > without additional cost to non-platform-native > UA/browser/device/non-browser, hence maximizing interoperability for > WebRTC endpoints. And without having multiple occurrences of codecs > being loaded on the platform. The API maybe there, but it does not necessarily confer a patent license to application developers, just like a patent license obtained by a WebRTC implementor does not necessarily extend to a service that integrates WebRTC. From nobody Tue Nov 18 08:41:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6651A1A92 for ; Tue, 18 Nov 2014 08:41:04 -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, 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 E2tLDuURxwmY for ; Tue, 18 Nov 2014 08:41:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8224D1A1A4E for ; Tue, 18 Nov 2014 08:41:00 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-32-546b769ad0af Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C6.7A.24955.A967B645; Tue, 18 Nov 2014 17:40:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Tue, 18 Nov 2014 17:40:58 +0100 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIwMelQGAAS/qitA= Date: Tue, 18 Nov 2014 16:40:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6ssuwQgz2ntC2Wd+1gtFj7r53d gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4+76DraBFp+Lrv6WsDYx/lLoYOTkkBEwk Nkz+zAZhi0lcuLceyObiEBI4wigxY2k/I4SzhFGicdpuli5GDg42AQuJ7n/aIA0iAmES008s YAGxhQXyJVqPTmKHiBdInG44wwhhW0lM/XcPzGYRUJVoeNYLZvMK+EpcePkPbLGQQJHEzhfN YDangL7Eml//weYwAh30/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4StJNG45Akr RL2exI2pU9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYn5aYb GeulFmUmFxfn5+nlpZZsYgTGycEtv1V3MF5+43iIUYCDUYmH12BbVogQa2JZcWXuIUZpDhYl cd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMv2lZJZhXZJPEs/SfRO66yI/vJF4v Za7OeJmS6ekgvYGzPmj95qwvjswrNmdMWsO6ZPUUk/vq5W3eJZUmjwRZ7zgF/xXZdkl+ev2H lB2L1u48wx8U2P9ot0Yh85HF/b/iqw64+wdnKK0wW3Ks5qeDy44w84fP6m79UYzZYhlkf1tc XWmub4ASS3FGoqEWc1FxIgB4M3+NdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZUmA_IS111scCiIZ5se6kNJyeJM Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 18 Nov 2014 16:41:04 -0000 Hi, In general, it seems like you want to leave out text just because it is "ap= plication specific". In my experience, if something is application specific= , it should be stated. Otherwise people will argue in future about who is r= ight and wrong. Please see inline for more. >>Thanks for putting together the new version! It makes a number of=20 >>things more clear :) >> >>I do still have a few comments/questions (hopefully editorial ones), >>though: >> >>Q1: >>----- >> >>I think it would be good to explicitly clarify that, when consent=20 >>expires on a 5-tuple/candidate pair, it does not affect other 5-tuples=20 >>within the session. I have received questions on that, so I think some=20 >>words would be useful to make it more clear. >> >>(Of course, one CAN choose to terminate the whole session if consent=20 >>expires on a candidate pair, but that depends on application policy). > > > Section 4.1 5th paragraph currently has this text: > > "if a valid STUN binding response > corresponding to any STUN request sent in the last 30 seconds has not > been received from the remote peer's transport address, the endpoint > MUST cease transmission on that 5-tuple.=B2 > > When Consent expires it is up to the application policy to decide on what= to do. As you said=20 > it can choose to terminate the whole session or continue sending data on = other 5-tuples. In this=20 > draft we should just say that the endpoint stops transmission on that 5-t= uple for which consent=20 > failed which is what the above text in the draft says. IMO that is suffic= ient. I think it would be good to have some text regarding the impact on other 5-= tuples. Something like: "When consent expires for data sent on a given 5-tuple, the impact on data = sent on other 5-tuples associated with the session is application specific. Applications might cho= ose to send data on other 5-tuples, or they might choose to stop sending media on all 5-tuples associated with = the session (and possibly terminate the session."=20 >>Q2: >>----- >> >>If consent expires, and I stop sending application data, will I still=20 >>send STUN keep-alives etc, to keep the candidate pair, NAT bindings etc=20 >>alive? >> >>There IS text saying: >> >> "An endpoint that is not sending any application data does not need to >> maintain consent. However, the endpoint needs to ensure its NAT or >> firewall mappings persist which can be done using keepalive or other >> techniques (see Section 10 of [RFC5245] and see [RFC6263])." >> >>However, that seems to be more related to cases where I don't intend to=20 >>send application data to begin with. >> >>So, perhaps the text above can be modified, to clarify that keepalives=20 >>etc will still be sent if consent expires. > > > Applications can continues to do what they were doing as part of STUN/ICE= (like sending STUN=20 > binding indications for NAT/FW keepalives or whatever). If some applicati= on wants to act on Consent=20 > expiry and do some thing it can do so however such a thing is not in the = scope of this draft. So IMO this=20 > is outside scope of this draft and is a application policy. Below (Q3) you say that ICE restart would be required after consent expirat= ion, so I guess that means that one should NOT send keep-alives etc. >>Q3: >>----- >> >>Section 4.1. says: >> >> "If the endpoint wants to send application data, it needs to first obtai= n >> consent if its consent has expired." >> >>If my consent has expired, is the a time period before I can try to=20 >>obtain consent again? Can I just continue sending STUN binding requests=20 >>even if my consent expires, and wait to obtain consent again? > > After consent fails, browser notifies the java script and there should be= no mechanism available=20 > for java script to again tell the browser to start all over again (consid= er a malicious java script); IMO=20 > consent can be only be re-started with ICE-restart. First, Consent can be used by other devices than browsers :) Second, IF ICE-restart is required, I think the draft should state so. Third: IF ICE-restart is required, then I don't think keep-alives etc would= be needed once consent expires (see Q2 above). >>Q4: >>----- >> >>When my consent expires, is it considered an error if I also choose to=20 >>not receive any data? If not, I think it would be good to indicate that=20 >>one may choose to also stop receiving data in case consent expires. > > Consent check only deals with whether to send media or not. If Consent fa= ils it is up the application to=20 > decide on what other actions it need to take (like stopping receiving med= ia e.t.c) Again, I think all these "application decisions" should be stated in the dr= aft :) Also, if ICE restart is required in order to start sending media again, it = seems a little strange that one would still continue to receive media. Or? >>Q5: >>----- >> >>Assuming I send RTP and RTCP on separate 5-tuples, and consent expires=20 >>on one of the 5-tuples. I assume that will impact both 5-tuples, and in=20 >>that case I think it would be good to clarify. > > Again this is application specific behaviour. If consent fails for one 5-= tuple, the application can choose=20 > to stop data on related 5-tuples as well. Don't see a need to have such a= text in this draft. We will have to=20 > document several such application behaviours if we start to do. See above regarding application decisions. Regards, Christer From nobody Wed Nov 19 20:41:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EEC1A0043 for ; Wed, 19 Nov 2014 20:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 GSnNNQYQrFfJ for ; Wed, 19 Nov 2014 20:41:05 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1408F1A0041 for ; Wed, 19 Nov 2014 20:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9538; q=dns/txt; s=iport; t=1416458465; x=1417668065; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vQqENM9aua4FxOWHE11VwC5W9HVBQe/NBJU+JPJbrTY=; b=fCGCOrXxsIqgWitb2SV70nXyGPZguJU0ZJb2c8ZkoyXCf9d1LNLmuKkB i9w8NRuhaWXvg7jJCPcyKEngbuwEC4IjIqO5RUgGEYps00IpPaZgAbF1D RQtDCaMZ951h7fm5HX6LVaJzUIxEMF2Qk3eOHCziIRxY0BrfOjfVASfk9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUHAP1vbVStJV2c/2dsb2JhbABagw5VWQSDAsklh0kCHHEWAQEBAQF9hAIBAQEENFEEAgEIEQMBAgUfCQICMB0IAgQBEohBDaAkm16BDAaWZgEBAQEBAQQBAQEBHoEnjy46BoJrgVoFkleEXoJNhF+BMz2DGIo1hz6CNoFFbQEBAYFFgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,422,1413244800"; d="scan'208";a="373747804" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 20 Nov 2014 04:41:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sAK4f3rh005995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Nov 2014 04:41:03 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.185]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 19 Nov 2014 22:41:02 -0600 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: AQHQBHwvJjfjOKAbZ06T7Mg5VhaLYw== Date: Thu, 20 Nov 2014 04:41:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.64.70] Content-Type: text/plain; charset="euc-kr" Content-ID: <4B5D972801B21A4C961FE2E880DFFCE8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g1vrLrpXrxYV1j8bDK1RVxOD1cQ Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 04:41:08 -0000 SGkgQ2hyaXN0ZXIsDQoNClBsZWFzZSBzZWUgaW5saW5lDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPg0KRGF0ZTogVHVlc2RheSwgMTggTm92ZW1iZXIgMjAxNCAxMDoxMCBwbQ0KVG86IENp c2NvIEVtcGxveWVlIDxybW9oYW5yQGNpc2NvLmNvbT4sICJydGN3ZWJAaWV0Zi5vcmciIDxydGN3 ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gSS1EIEFjdGlvbjoNCmRyYWZ0LWll dGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMDgudHh0IC0gU29tZSBhZGRpdGlvbmFs IHF1ZXN0aW9ucw0KDQo+SGksDQo+DQo+SW4gZ2VuZXJhbCwgaXQgc2VlbXMgbGlrZSB5b3Ugd2Fu dCB0byBsZWF2ZSBvdXQgdGV4dCBqdXN0IGJlY2F1c2UgaXQgaXMNCj4iYXBwbGljYXRpb24gc3Bl Y2lmaWMiLiBJbiBteSBleHBlcmllbmNlLCBpZiBzb21ldGhpbmcgaXMgYXBwbGljYXRpb24NCj5z cGVjaWZpYywgaXQgc2hvdWxkIGJlIHN0YXRlZC4gT3RoZXJ3aXNlIHBlb3BsZSB3aWxsIGFyZ3Vl IGluIGZ1dHVyZQ0KPmFib3V0IHdobyBpcyByaWdodCBhbmQgd3JvbmcuDQo+DQo+UGxlYXNlIHNl ZSBpbmxpbmUgZm9yIG1vcmUuDQo+DQo+Pj5UaGFua3MgZm9yIHB1dHRpbmcgdG9nZXRoZXIgdGhl IG5ldyB2ZXJzaW9uISBJdCBtYWtlcyBhIG51bWJlciBvZg0KPj4+dGhpbmdzIG1vcmUgY2xlYXIg OikNCj4+Pg0KPj4+SSBkbyBzdGlsbCBoYXZlIGEgZmV3IGNvbW1lbnRzL3F1ZXN0aW9ucyAoaG9w ZWZ1bGx5IGVkaXRvcmlhbCBvbmVzKSwNCj4+PnRob3VnaDoNCj4+Pg0KPj4+UTE6DQo+Pj4tLS0t LQ0KPj4+DQo+Pj5JIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gZXhwbGljaXRseSBjbGFyaWZ5 IHRoYXQsIHdoZW4gY29uc2VudA0KPj4+ZXhwaXJlcyBvbiBhIDUtdHVwbGUvY2FuZGlkYXRlIHBh aXIsIGl0IGRvZXMgbm90IGFmZmVjdCBvdGhlciA1LXR1cGxlcw0KPj4+d2l0aGluIHRoZSBzZXNz aW9uLiBJIGhhdmUgcmVjZWl2ZWQgcXVlc3Rpb25zIG9uIHRoYXQsIHNvIEkgdGhpbmsgc29tZQ0K Pj4+d29yZHMgd291bGQgYmUgdXNlZnVsIHRvIG1ha2UgaXQgbW9yZSBjbGVhci4NCj4+Pg0KPj4+ KE9mIGNvdXJzZSwgb25lIENBTiBjaG9vc2UgdG8gdGVybWluYXRlIHRoZSB3aG9sZSBzZXNzaW9u IGlmIGNvbnNlbnQNCj4+PmV4cGlyZXMgb24gYSBjYW5kaWRhdGUgcGFpciwgYnV0IHRoYXQgZGVw ZW5kcyBvbiBhcHBsaWNhdGlvbiBwb2xpY3kpLg0KPj4NCj4+DQo+PiBTZWN0aW9uIDQuMSA1dGgg cGFyYWdyYXBoIGN1cnJlbnRseSBoYXMgdGhpcyB0ZXh0Og0KPj4NCj4+ICJpZiBhIHZhbGlkIFNU VU4gYmluZGluZyByZXNwb25zZQ0KPj4gICBjb3JyZXNwb25kaW5nIHRvIGFueSBTVFVOIHJlcXVl c3Qgc2VudCBpbiB0aGUgbGFzdCAzMCBzZWNvbmRzIGhhcyBub3QNCj4+ICAgYmVlbiByZWNlaXZl ZCBmcm9tIHRoZSByZW1vdGUgcGVlcidzIHRyYW5zcG9ydCBhZGRyZXNzLCB0aGUgZW5kcG9pbnQN Cj4+ICAgTVVTVCBjZWFzZSB0cmFuc21pc3Npb24gb24gdGhhdCA1LXR1cGxlLqn3DQo+Pg0KPj4g V2hlbiBDb25zZW50IGV4cGlyZXMgaXQgaXMgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHBvbGljeSB0 byBkZWNpZGUgb24NCj4+d2hhdCB0byBkby4gQXMgeW91IHNhaWQNCj4+IGl0IGNhbiBjaG9vc2Ug dG8gdGVybWluYXRlIHRoZSB3aG9sZSBzZXNzaW9uIG9yIGNvbnRpbnVlIHNlbmRpbmcgZGF0YQ0K Pj5vbiBvdGhlciA1LXR1cGxlcy4gSW4gdGhpcw0KPj4gZHJhZnQgd2Ugc2hvdWxkIGp1c3Qgc2F5 IHRoYXQgdGhlIGVuZHBvaW50IHN0b3BzIHRyYW5zbWlzc2lvbiBvbiB0aGF0DQo+PjUtdHVwbGUg Zm9yIHdoaWNoIGNvbnNlbnQNCj4+IGZhaWxlZCB3aGljaCBpcyB3aGF0IHRoZSBhYm92ZSB0ZXh0 IGluIHRoZSBkcmFmdCBzYXlzLiBJTU8gdGhhdCBpcw0KPj5zdWZmaWNpZW50Lg0KPg0KPkkgdGhp bmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHNvbWUgdGV4dCByZWdhcmRpbmcgdGhlIGltcGFj dCBvbiBvdGhlcg0KPjUtdHVwbGVzLiBTb21ldGhpbmcgbGlrZToNCj4NCj4iV2hlbiBjb25zZW50 IGV4cGlyZXMgZm9yIGRhdGEgc2VudCBvbiBhIGdpdmVuIDUtdHVwbGUsIHRoZSBpbXBhY3Qgb24N Cj5kYXRhIHNlbnQgb24gb3RoZXIgNS10dXBsZXMNCj5hc3NvY2lhdGVkIHdpdGggdGhlIHNlc3Np b24gaXMgYXBwbGljYXRpb24gc3BlY2lmaWMuIEFwcGxpY2F0aW9ucyBtaWdodA0KPmNob29zZSB0 byBzZW5kIGRhdGEgb24gb3RoZXIgNS10dXBsZXMsDQo+b3IgdGhleSBtaWdodCBjaG9vc2UgdG8g c3RvcCBzZW5kaW5nIG1lZGlhIG9uIGFsbCA1LXR1cGxlcyBhc3NvY2lhdGVkDQo+d2l0aCB0aGUg c2Vzc2lvbiAoYW5kIHBvc3NpYmx5DQo+dGVybWluYXRlIHRoZSBzZXNzaW9uLiINCg0KDQpTdXJl LiBJIHdpbGwgdXBkYXRlIHRoZSBhYm92ZSB0ZXh0IGluIHRoZSBuZXh0IHJldmlzaW9uLg0KDQoN Cj4gDQo+DQo+DQo+Pj5RMjoNCj4+Pi0tLS0tDQo+Pj4NCj4+PklmIGNvbnNlbnQgZXhwaXJlcywg YW5kIEkgc3RvcCBzZW5kaW5nIGFwcGxpY2F0aW9uIGRhdGEsIHdpbGwgSSBzdGlsbA0KPj4+c2Vu ZCBTVFVOIGtlZXAtYWxpdmVzIGV0YywgdG8ga2VlcCB0aGUgY2FuZGlkYXRlIHBhaXIsIE5BVCBi aW5kaW5ncyBldGMNCj4+PmFsaXZlPw0KPj4+DQo+Pj5UaGVyZSBJUyB0ZXh0IHNheWluZzoNCj4+ Pg0KPj4+CSJBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBk YXRhIGRvZXMgbm90IG5lZWQgdG8NCj4+PiAgIAltYWludGFpbiBjb25zZW50LiAgSG93ZXZlciwg dGhlIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yDQo+Pj4gICAJZmlyZXdhbGwg bWFwcGluZ3MgcGVyc2lzdCB3aGljaCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3Ro ZXINCj4+PiAgIAl0ZWNobmlxdWVzIChzZWUgU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0gYW5kIHNl ZSBbUkZDNjI2M10pLiINCj4+Pg0KPj4+SG93ZXZlciwgdGhhdCBzZWVtcyB0byBiZSBtb3JlIHJl bGF0ZWQgdG8gY2FzZXMgd2hlcmUgSSBkb24ndCBpbnRlbmQgdG8NCj4+PnNlbmQgYXBwbGljYXRp b24gZGF0YSB0byBiZWdpbiB3aXRoLg0KPj4+DQo+Pj5TbywgcGVyaGFwcyB0aGUgdGV4dCBhYm92 ZSBjYW4gYmUgbW9kaWZpZWQsIHRvIGNsYXJpZnkgdGhhdCBrZWVwYWxpdmVzDQo+Pj5ldGMgd2ls bCBzdGlsbCBiZSBzZW50IGlmIGNvbnNlbnQgZXhwaXJlcy4NCj4+DQo+Pg0KPj4gQXBwbGljYXRp b25zIGNhbiBjb250aW51ZXMgdG8gZG8gd2hhdCB0aGV5IHdlcmUgZG9pbmcgYXMgcGFydCBvZg0K Pj5TVFVOL0lDRSAobGlrZSBzZW5kaW5nIFNUVU4NCj4+IGJpbmRpbmcgaW5kaWNhdGlvbnMgZm9y IE5BVC9GVyBrZWVwYWxpdmVzIG9yIHdoYXRldmVyKS4gSWYgc29tZQ0KPj5hcHBsaWNhdGlvbiB3 YW50cyB0byBhY3Qgb24gQ29uc2VudA0KPj4gZXhwaXJ5IGFuZCBkbyBzb21lIHRoaW5nIGl0IGNh biBkbyBzbyBob3dldmVyIHN1Y2ggYSB0aGluZyBpcyBub3QgaW4NCj4+dGhlIHNjb3BlIG9mIHRo aXMgZHJhZnQuIFNvIElNTyB0aGlzDQo+PiBpcyBvdXRzaWRlIHNjb3BlIG9mIHRoaXMgZHJhZnQg YW5kIGlzIGEgYXBwbGljYXRpb24gcG9saWN5Lg0KPg0KPkJlbG93IChRMykgeW91IHNheSB0aGF0 IElDRSByZXN0YXJ0IHdvdWxkIGJlIHJlcXVpcmVkIGFmdGVyIGNvbnNlbnQNCj5leHBpcmF0aW9u LCBzbyBJIGd1ZXNzIHRoYXQgbWVhbnMgdGhhdCBvbmUgc2hvdWxkIE5PVCBzZW5kIGtlZXAtYWxp dmVzDQo+ZXRjLg0KPg0KPg0KPj4+UTM6DQo+Pj4tLS0tLQ0KPj4+DQo+Pj5TZWN0aW9uIDQuMS4g c2F5czoNCj4+Pg0KPj4+CSJJZiB0aGUgZW5kcG9pbnQgd2FudHMgdG8gc2VuZCBhcHBsaWNhdGlv biBkYXRhLCBpdCBuZWVkcyB0byBmaXJzdA0KPj4+b2J0YWluDQo+Pj4gICAJY29uc2VudCBpZiBp dHMgY29uc2VudCBoYXMgZXhwaXJlZC4iDQo+Pj4NCj4+PklmIG15IGNvbnNlbnQgaGFzIGV4cGly ZWQsIGlzIHRoZSBhIHRpbWUgcGVyaW9kIGJlZm9yZSBJIGNhbiB0cnkgdG8NCj4+Pm9idGFpbiBj b25zZW50IGFnYWluPyBDYW4gSSBqdXN0IGNvbnRpbnVlIHNlbmRpbmcgU1RVTiBiaW5kaW5nIHJl cXVlc3RzDQo+Pj5ldmVuIGlmIG15IGNvbnNlbnQgZXhwaXJlcywgYW5kIHdhaXQgdG8gb2J0YWlu IGNvbnNlbnQgYWdhaW4/DQo+Pg0KPj4gQWZ0ZXIgY29uc2VudCBmYWlscywgYnJvd3NlciBub3Rp ZmllcyB0aGUgamF2YSBzY3JpcHQgYW5kIHRoZXJlIHNob3VsZA0KPj5iZSBubyBtZWNoYW5pc20g YXZhaWxhYmxlDQo+PiBmb3IgamF2YSBzY3JpcHQgdG8gYWdhaW4gdGVsbCB0aGUgYnJvd3NlciB0 byBzdGFydCBhbGwgb3ZlciBhZ2Fpbg0KPj4oY29uc2lkZXIgYSBtYWxpY2lvdXMgamF2YSBzY3Jp cHQpOyBJTU8NCj4+IGNvbnNlbnQgY2FuIGJlIG9ubHkgYmUgcmUtc3RhcnRlZCB3aXRoIElDRS1y ZXN0YXJ0Lg0KPg0KPkZpcnN0LCBDb25zZW50IGNhbiBiZSB1c2VkIGJ5IG90aGVyIGRldmljZXMg dGhhbiBicm93c2VycyA6KQ0KDQpTdXJlLiBBZ3JlZQ0KDQo+DQo+U2Vjb25kLCBJRiBJQ0UtcmVz dGFydCBpcyByZXF1aXJlZCwgSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIHN0YXRlIHNvLg0KPg0K PlRoaXJkOiBJRiBJQ0UtcmVzdGFydCBpcyByZXF1aXJlZCwgdGhlbiBJIGRvbid0IHRoaW5rIGtl ZXAtYWxpdmVzIGV0Yw0KPndvdWxkIGJlIG5lZWRlZCBvbmNlIGNvbnNlbnQgZXhwaXJlcyAoc2Vl IFEyIGFib3ZlKS4NCg0KSSB0YWtlIGJhY2sgdGhhdC4gSXQgc2hvdWxkIG5vdCBiZSBJQ0UtcmVz dGFydCBJIGd1ZXNzLCBzaW5jZSBhcyBwZXIgdGhlDQpleHBsYW5hdGlvbiBpbiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tOS4xLjEuMSBmb3INCklDRS1yZXN0YXJ0 IGFuIGVuZHBvaW50IG1heSBjb250aW51ZSB0byBzZW5kIG1lZGlhIG9uIHByZXZpb3VzbHkgc2Vs ZWN0ZWQNCjUtdHVwbGUgd2hpY2ggaXMgbm90IHRoZSBjYXNlIGhlcmUuIEluIG91ciBjYXNlIG9u Y2UgQ29uc2VudCBmYWlscyB3ZSBqdXN0DQpzdG9wIHNlbmRpbmcgbWVkaWEgb24gdGhhdCA1LXR1 cGxlLg0KSSBndWVzcyBicmFuZCBuZXcgbWVkaWEgc2Vzc2lvbiBpcyByZXF1aXJlZCBhbmQgdGhl IGFwcGxpY2F0aW9uIGhhcyB0byBkbw0Kb2ZmZXIvYW5zd2VyIGFuZCBkbyBJQ0UgYWdhaW4gZm9y IHRoYXQgdHVwbGUuICBJZiB3ZSBnbyBieSB0aGF0IG5vDQpLZWVwYWxpdmVzIGFyZSBuZWVkZWQu IFdlIGNhbiBhZGQgc29tZSB0ZXh0IGZvciB0aGF0Lg0KDQoNCg0KPg0KPj4+UTQ6DQo+Pj4tLS0t LQ0KPj4+DQo+Pj5XaGVuIG15IGNvbnNlbnQgZXhwaXJlcywgaXMgaXQgY29uc2lkZXJlZCBhbiBl cnJvciBpZiBJIGFsc28gY2hvb3NlIHRvDQo+Pj5ub3QgcmVjZWl2ZSBhbnkgZGF0YT8gSWYgbm90 LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaW5kaWNhdGUgdGhhdA0KPj4+b25lIG1heSBj aG9vc2UgdG8gYWxzbyBzdG9wIHJlY2VpdmluZyBkYXRhIGluIGNhc2UgY29uc2VudCBleHBpcmVz Lg0KPj4NCj4+IENvbnNlbnQgY2hlY2sgb25seSBkZWFscyB3aXRoIHdoZXRoZXIgdG8gc2VuZCBt ZWRpYSBvciBub3QuIElmIENvbnNlbnQNCj4+ZmFpbHMgaXQgaXMgdXAgdGhlIGFwcGxpY2F0aW9u IHRvDQo+PiBkZWNpZGUgb24gd2hhdCBvdGhlciBhY3Rpb25zIGl0IG5lZWQgdG8gdGFrZSAobGlr ZSBzdG9wcGluZyByZWNlaXZpbmcNCj4+bWVkaWEgZS50LmMpDQo+DQo+QWdhaW4sIEkgdGhpbmsg YWxsIHRoZXNlICJhcHBsaWNhdGlvbiBkZWNpc2lvbnMiIHNob3VsZCBiZSBzdGF0ZWQgaW4gdGhl DQo+ZHJhZnQgOikNCj4NCj5BbHNvLCBpZiBJQ0UgcmVzdGFydCBpcyByZXF1aXJlZCBpbiBvcmRl ciB0byBzdGFydCBzZW5kaW5nIG1lZGlhIGFnYWluLA0KPml0IHNlZW1zIGEgbGl0dGxlIHN0cmFu Z2UgdGhhdCBvbmUgd291bGQgc3RpbGwgY29udGludWUgdG8gcmVjZWl2ZSBtZWRpYS4NCj5Pcj8N Cg0KSSBkb26hr3QgdGhpbmsgd2UgY2FuIG1hbmRhdGUgYXBwbGljYXRpb25zIHRvIHN0b3AgcmVj ZWl2aW5nIG1lZGlhIGFzIHdlbGwNCmlmIGNvbnNlbnQgZmFpbHMuIENvbnNlbnQgaXMgZm9yIG9u bHkgc2VuZGluZyBkYXRhLg0KDQo+DQo+DQo+Pj5RNToNCj4+Pi0tLS0tDQo+Pj4NCj4+PkFzc3Vt aW5nIEkgc2VuZCBSVFAgYW5kIFJUQ1Agb24gc2VwYXJhdGUgNS10dXBsZXMsIGFuZCBjb25zZW50 IGV4cGlyZXMNCj4+Pm9uIG9uZSBvZiB0aGUgNS10dXBsZXMuIEkgYXNzdW1lIHRoYXQgd2lsbCBp bXBhY3QgYm90aCA1LXR1cGxlcywgYW5kIGluDQo+Pj50aGF0IGNhc2UgSSB0aGluayBpdCB3b3Vs ZCBiZSBnb29kIHRvIGNsYXJpZnkuDQo+Pg0KPj4gQWdhaW4gdGhpcyBpcyBhcHBsaWNhdGlvbiBz cGVjaWZpYyBiZWhhdmlvdXIuIElmIGNvbnNlbnQgZmFpbHMgZm9yIG9uZQ0KPj41LXR1cGxlLCB0 aGUgYXBwbGljYXRpb24gY2FuIGNob29zZQ0KPj4gdG8gc3RvcCBkYXRhIG9uIHJlbGF0ZWQgNS10 dXBsZXMgYXMgd2VsbC4gRG9uJ3Qgc2VlIGEgbmVlZCB0byBoYXZlIHN1Y2gNCj4+YSB0ZXh0IGlu IHRoaXMgZHJhZnQuIFdlIHdpbGwgaGF2ZSB0bw0KPj4gZG9jdW1lbnQgc2V2ZXJhbCBzdWNoIGFw cGxpY2F0aW9uIGJlaGF2aW91cnMgIGlmIHdlIHN0YXJ0IHRvIGRvLg0KPg0KPlNlZSBhYm92ZSBy ZWdhcmRpbmcgYXBwbGljYXRpb24gZGVjaXNpb25zLg0KDQpTbyBJIGNhbiBhZGQgdGhlIGJlbG93 IGxpbmU6DQoNCiJJZiBjb25zZW50IGZhaWxzIGZvciBvbmUgNS10dXBsZSwgdGhlIGFwcGxpY2F0 aW9uIGNhbiBjaG9vc2UNCnRvIHN0b3AgZGF0YSBvbiByZWxhdGVkIDUtdHVwbGVzIGFzIHdlbGwg b3IgY29udGludWWhsS4NCg0KUmVnYXJkcywNClJhbQ0KDQoNCj4NCj5SZWdhcmRzLA0KPg0KPkNo cmlzdGVyDQo+DQoNCg== From nobody Wed Nov 19 23:19:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62ED1A009E for ; Wed, 19 Nov 2014 23:19:23 -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 dvUKA5Ixq1ga for ; Wed, 19 Nov 2014 23:19:21 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82F91A0099 for ; Wed, 19 Nov 2014 23:19:21 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id gq1so1762391obb.40 for ; Wed, 19 Nov 2014 23:19:21 -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=2fxtnqFpH2LYEWz1er6qCExvQvZTp3N/bAhvEkLUSjw=; b=HobaEP0+j0ovSTxEW1wz9OWOs66z/EyYh8iMjZvvHj1TOp8BXM4HMVYtoO8bufxCmD 2SRd0Y/WeU0Evxy1QHC9+1uEzWE/6XXA64sN1jY94/G+rut8XCmwJsv/aaDFNB6VeTSg Avh6gayY4ub1MyR/hGgwSV+KZ2mpFqPTXbgya2txBpqb7A//OixAg6prfGt63ExZdgSg G7l8M8V7Xf3THxBi5/aL+0g5ZqfirD1hNOEuTTUKlsxasiF7Npgb6Lr2XOSyx0OGHyvY tTjAUn3NPA7JOEA9e8VmjruJoac7+NMTuRR2+qzirrb4z8Ir9ujIOmil9tHjkVyLgD0W S5fg== MIME-Version: 1.0 X-Received: by 10.182.102.37 with SMTP id fl5mr40631003obb.24.1416467961017; Wed, 19 Nov 2014 23:19:21 -0800 (PST) Received: by 10.202.115.4 with HTTP; Wed, 19 Nov 2014 23:19:20 -0800 (PST) Received: by 10.202.115.4 with HTTP; Wed, 19 Nov 2014 23:19:20 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> Date: Wed, 19 Nov 2014 23:19:20 -0800 Message-ID: From: Martin Thomson To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=089e0149d172a6fa95050845253f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vX3vCFDRj4U9gjJHCRgaqQ1E9p4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 07:19:24 -0000 --089e0149d172a6fa95050845253f Content-Type: text/plain; charset=UTF-8 It is really hard following these threads, but it looks like this is being over-thought. "This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. What applications choose to do with this information is not described in this document." Add that to the introduction perhaps. We run the risk of expanding scope otherwise. As for the question of re-acquisition of consent, I think that we should keep it simple. For this: "After consent is lost for any reason, the same ICE credentials MUST NOT be used on the affected 5-tuple again. That means that a new session, or an ICE restart at least, is needed to obtain consent to send." Better to keep the rule simple, and we don't want to leave an option open for a packet-drop-based attack here. And one more thing ... On Nov 19, 2014 6:41 PM, "Ram Mohan R (rmohanr)" wrote: > >>> > >>>There IS text saying: > >>> > >>> "An endpoint that is not sending any application data does not need to > >>> maintain consent. However, the endpoint needs to ensure its NAT or > >>> firewall mappings persist which can be done using keepalive or other > >>> techniques (see Section 10 of [RFC5245] and see [RFC6263])." > >>> > >>>However, that seems to be more related to cases where I don't intend to > >>>send application data to begin with. > >>> > >>>So, perhaps the text above can be modified, to clarify that keepalives > >>>etc will still be sent if consent expires. I think that we should consider akeep alive as application data, and subject to to rules of consent. The text should note that firewall and NAT bindings could be lost, instead. --089e0149d172a6fa95050845253f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It is really hard following these threads, but it looks like= this is being over-thought.

"This document defines what it takes to obtain, maintai= n, and lose consent to send. Consent to send applies to a single 5-tuple. W= hat applications choose to do with this information is not described in thi= s document."

Add that to the introduction perhaps. We run the risk of exp= anding scope otherwise.

As for the question of re-acquisition of consent, I think th= at we should keep it simple. For this:

"After consent is lost for any reason, the same ICE cre= dentials MUST NOT be used on the affected 5-tuple again. That means that a = new session, or an ICE restart at least, is needed to obtain consent to sen= d."

Better to keep the rule simple, and we don't want to lea= ve an option open for a packet-drop-based attack here.

And one more thing ...

On Nov 19, 2014 6:41 PM, "Ram Mohan R (rmohanr)" &= lt;rmohanr@cisco.com> wrote: > >>>
> >>>There IS text saying:
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0"An endpoint that is not sending = any application data does not need to
> >>>=C2=A0 =C2=A0 =C2=A0maintain consent.=C2=A0 However, the e= ndpoint needs to ensure its NAT or
> >>>=C2=A0 =C2=A0 =C2=A0firewall mappings persist which can be= done using keepalive or other
> >>>=C2=A0 =C2=A0 =C2=A0techniques (see Section 10 of [RFC5245= ] and see [RFC6263])."
> >>>
> >>>However, that seems to be more related to cases where I do= n't intend to
> >>>send application data to begin with.
> >>>
> >>>So, perhaps the text above can be modified, to clarify tha= t keepalives
> >>>etc will still be sent if consent expires.

I think that we should consider akeep alive as application d= ata, and subject to to rules of consent.

The text should note that firewall and NAT bindings could be= lost, instead.

--089e0149d172a6fa95050845253f-- From nobody Thu Nov 20 08:29:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5E11A1B29 for ; Thu, 20 Nov 2014 08:29:11 -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, 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 RmEl6q828JgI for ; Thu, 20 Nov 2014 08:29:03 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E741A1AE3 for ; Thu, 20 Nov 2014 08:29:00 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-1a-546e16ca1af2 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DD.98.04081.AC61E645; Thu, 20 Nov 2014 17:28:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Thu, 20 Nov 2014 17:28:58 +0100 From: Christer Holmberg To: Martin Thomson , "Ram Mohan R (rmohanr)" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIwMelQGAAS/qitAASiGsAAAFh1AAABTZMDA= Date: Thu, 20 Nov 2014 16:28:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52C623@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje4psbwQgws3zC2unfnHaLG8awej xdp/7ewOzB5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mr5272csuCZYsWXtJvYG xjmCXYycHBICJhL3l19hgbDFJC7cW8/WxcjFISRwhFGi6csEFghnCaNE3+MO1i5GDg42AQuJ 7n/aIA0iAjESl6fvZwSxmQXUJe4sPscOYgsL5Eu0Hp3EDlFTIHG64QwjhO0n8b/xJpjNIqAq 0bb/B5jNK+ArsenabUaIXYuYJM69gUhwCgRKHNxzmAnEZgS67vupNUwQy8Qlbj2ZzwRxtYDE kj3nmSFsUYmXj/+xQthKEotuf2YCuZlZQFNi/S59iFZFiSndD9kh9gpKnJz5hGUCo9gsJFNn IXTMQtIxC0nHAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBEXVwy2+DHYwvnzseYhTg YFTi4TWIzA0RYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M Em3qV6crVP75axIkvbTNgvNZ4d3WiZom5pcfXu478j0y2T5P+5hwpkGa9Ar+es59bySX/T6y boZQ8qNHWzmnHrIrT7z69MvxN5OmTfj4wnyNzi6Hq1NvPf++Pynnz493Cxdb3Myp3i5ziudD 0hre/p0y5+fXlX1KXhK6l98ysJ2Fj9+lrubxFiWW4oxEQy3mouJEAD3ap1CJAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Sv2vjSSMihoxdyCIGu3hcCjDrP8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 16:29:11 -0000 SGkgTWFydGluLA0KDQo+SXQgaXMgcmVhbGx5IGhhcmQgZm9sbG93aW5nIHRoZXNlIHRocmVhZHMs IGJ1dCBpdCBsb29rcyBsaWtlIHRoaXMgaXMgYmVpbmcgb3Zlci10aG91Z2h0Lg0KPg0KPiJUaGlz IGRvY3VtZW50IGRlZmluZXMgd2hhdCBpdCB0YWtlcyB0byBvYnRhaW4sIG1haW50YWluLCBhbmQg bG9zZSBjb25zZW50IHRvIHNlbmQuIENvbnNlbnQgDQo+dG8gc2VuZCBhcHBsaWVzIHRvIGEgc2lu Z2xlIDUtdHVwbGUuIFdoYXQgYXBwbGljYXRpb25zIGNob29zZSB0byBkbyB3aXRoIHRoaXMgaW5m b3JtYXRpb24gaXMgbm90IA0KPmRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LiINCj4NCj5BZGQg dGhhdCB0byB0aGUgaW50cm9kdWN0aW9uIHBlcmhhcHMuIFdlIHJ1biB0aGUgcmlzayBvZiBleHBh bmRpbmcgc2NvcGUgb3RoZXJ3aXNlLg0KDQpJIGFncmVlIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byBz cGVjaWZ5IGFwcGxpY2F0aW9uIGJlaGF2aW91ci4gQnV0LCBJIHRoaW5rIHdlIGRvIG5lZWQgdG8g YmUgY2xlYXIgcmVnYXJkaW5nIHRoZSBpbXBhY3RzIG9uIHRoZSB0cmFuc3BvcnQvSUNFIGxheWVy LCB3aGVuL2lmL2hvdyBpdCBjYW4gYmUgbGF0ZXIgcmUtdXNlZCBldGMuDQoNCj5BcyBmb3IgdGhl IHF1ZXN0aW9uIG9mIHJlLWFjcXVpc2l0aW9uIG9mIGNvbnNlbnQsIEkgdGhpbmsgdGhhdCB3ZSBz aG91bGQga2VlcCBpdCBzaW1wbGUuIEZvciB0aGlzOg0KPg0KPiJBZnRlciBjb25zZW50IGlzIGxv c3QgZm9yIGFueSByZWFzb24sIHRoZSBzYW1lIElDRSBjcmVkZW50aWFscyBNVVNUIE5PVCBiZSB1 c2VkIG9uIHRoZSBhZmZlY3RlZCA1LXR1cGxlIGFnYWluLiANCj5UaGF0IG1lYW5zIHRoYXQgYSBu ZXcgc2Vzc2lvbiwgb3IgYW4gSUNFIHJlc3RhcnQgYXQgbGVhc3QsIGlzIG5lZWRlZCB0byBvYnRh aW4gY29uc2VudCB0byBzZW5kLiINCg0KTXkgcXVlc3Rpb24gaXMgaG93L2lmIHRoZSBjb25zZW50 IGxvc3QgaW1wYWN0cyAibm9ybWFsIiBJQ0UgKFNUVU4ga2VlcC1hbGl2ZXMgZXRjKSwgdHJhbnNw b3J0IGxheWVyIGhlYXJ0YmVhdHMgZXRjLg0KDQpBbHNvLCBhcyB0aGUgZW50aXR5IG1heSBzdGls bCByZWNlaXZlIG1lZGlhIG9uIHRoZSA1LXR1cGxlLCB0aGF0IGFsc28gbWVhbnMgaXQgc3RpbGwg aGF2ZSB0byByZXNwb25kIHRvIGluY29taW5nIFNUVU4gcmVxdWVzdHMgZXRjLg0KDQpJIHRoaW5r IHRoYXQgc2hvdWxkIGJlIGNsZWFyIGluIHRoZSBkcmFmdC4gDQoNCj5JIHRoaW5rIHRoYXQgd2Ug c2hvdWxkIGNvbnNpZGVyIGEga2VlcCBhbGl2ZSBhcyBhcHBsaWNhdGlvbiBkYXRhLCBhbmQgc3Vi amVjdCB0byBydWxlcyBvZiBjb25zZW50Lg0KPlRoZSB0ZXh0IHNob3VsZCBub3RlIHRoYXQgZmly ZXdhbGwgYW5kIE5BVCBiaW5kaW5ncyBjb3VsZCBiZSBsb3N0LCBpbnN0ZWFkLg0KDQpJIGFtIG9r IHdpdGggc3VjaCBhcHByb2FjaCwgYXMgbG9uZyBhcyB3ZSBkb2N1bWVudCBpdCA6KQ0KDQpXaGF0 IGFib3V0IERUTFMgaGVhcnRiZWF0cywgYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgb24gdGhl IHRyYW5zcG9ydCBsYXllcj8gSSBBU1NVTUUgdGhlIGVudGl0eSB3aWxsIG1haW50YWluIHRob3Nl LCBhcyBpdCBzdGlsbCBtYXkgcmVjZWl2ZSBtZWRpYQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Thu Nov 20 08:47:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E371A1AD3 for ; Thu, 20 Nov 2014 08:47:34 -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, 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 gSbO6dIldmjD for ; Thu, 20 Nov 2014 08:47:32 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005F01A07BC for ; Thu, 20 Nov 2014 08:47:31 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-af-546e1b228c97 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5D.83.24955.22B1E645; Thu, 20 Nov 2014 17:47:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Thu, 20 Nov 2014 17:47:29 +0100 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIwMelQGAAS/qitAASiGsAAAa/iqg Date: Thu, 20 Nov 2014 16:47:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52C653@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja6SdF6IwZ/vAhbLu3YwWqz9187u wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGWcapQvuCteMe3pIfYGxibhLkZODgkBE4k1 nffYIGwxiQv31gPZXBxCAkcYJRb1XGWHcJYwSnRsns/cxcjBwSZgIdH9TxukQUQgTGL6iQUs ILawQL5E69FJ7BDxAonTDWcYIWw3iY+LDoEtYBFQlbh45QVYDa+Ar8TRH/3MEPNvM0psvNjA BDKfU0Bf4vAJC5AaRqCDvp9awwRiMwuIS9x6Mp8J4lABiSV7zjND2KISLx//Y4WwlSQW3f4M Va8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcVJuelG xnqpRZnJxcX5eXp5qSWbGIFRcnDLb9UdjJffOB5iFOBgVOLhNYjMDRFiTSwrrsw9xCjNwaIk zrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwTfklxdCZmMK/dpNhZb7jEnfvx/hOF dXO6/UxmHGO60buqxz3WosE5SKvT9lYSz2y+DY8LcrfYCtQeObzjxPaic107vziEvDu33fCo +KTJu+xjl1+44LGPpa9626ouAZXmZaGGJXtSYyb7HznSZCUgv+XDTs+mp+fj/7HnOv0Xsfsw r2Kb10YlluKMREMt5qLiRABO7BV1cwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fFGy0M6uQintUzUfXtM7qXWkIvQ Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 16:47:35 -0000 Hi Ram, >>>>Q2: >>>>----- >>>> >>>>If consent expires, and I stop sending application data, will I still=20 >>>>send STUN keep-alives etc, to keep the candidate pair, NAT bindings=20 >>>>etc alive? >>>> >>>>There IS text saying:> >>>> >>>> "An endpoint that is not sending any application data does not need to >>>> maintain consent. However, the endpoint needs to ensure its NAT or >>>> firewall mappings persist which can be done using keepalive or othe= r >>>> techniques (see Section 10 of [RFC5245] and see [RFC6263])." >>>> >>>>However, that seems to be more related to cases where I don't intend=20 >>>>to send application data to begin with. >>>> >>>>So, perhaps the text above can be modified, to clarify that=20 >>>>keepalives etc will still be sent if consent expires. >>> >>> >>> Applications can continues to do what they were doing as part of=20 >>>STUN/ICE (like sending STUN binding indications for NAT/FW keepalives=20 >>>or whatever). If some application wants to act on Consent expiry and=20 >>>do some thing it can do so however such a thing is not in the scope of=20 >>>this draft. So IMO this is outside scope of this draft and is a=20 >>>application policy. >> >>Below (Q3) you say that ICE restart would be required after consent=20 >>expiration, so I guess that means that one should NOT send keep-alives=20 >>etc. >> >> >>>>Q3: >>>>----- >>>> >>>>Section 4.1. says: >>>> >>>> "If the endpoint wants to send application data, it needs to first=20 >>>> obtain consent if its consent has expired." >>>> >>>>If my consent has expired, is the a time period before I can try to=20 >>>>obtain consent again? Can I just continue sending STUN binding=20 >>>>requests even if my consent expires, and wait to obtain consent again? >>> >>> After consent fails, browser notifies the java script and there=20 >>> should be no mechanism available for java script to again tell the=20 >>> browser to start all over again (consider a malicious java script);=20 >>> IMO consent can be only be re-started with ICE-restart. >> >> First, Consent can be used by other devices than browsers :) > > Sure. Agree > >>Second, IF ICE-restart is required, I think the draft should state so. >> >>Third: IF ICE-restart is required, then I don't think keep-alives etc=20 >>would be needed once consent expires (see Q2 above). > > I take back that. It should not be ICE-restart I guess, since as per the = explanation in=20 > http://tools.ietf.org/html/rfc5245#section-9.1.1.1 for ICE-restart an end= point may=20 > continue to send media on previously selected 5-tuple which is not the ca= se here.=20 > In our case once Consent fails we just stop sending media on that 5-tuple= . > I guess brand new media session is required and the application has to do= offer/answer=20 > and do ICE again for that tuple. If we go by that no Keepalives are need= ed. We can add some text for that. See my reply to Martin's e-mail. Regards, Christer From nobody Thu Nov 20 17:33:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBFE1ACFF2 for ; Thu, 20 Nov 2014 17:33:56 -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 Qd98Ot-cLgzn for ; Thu, 20 Nov 2014 17:33:55 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36721ACFE8 for ; Thu, 20 Nov 2014 17:33:54 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id a141so2964626oig.4 for ; Thu, 20 Nov 2014 17:33:54 -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=YPtFIS73aeCiMoCIC5Hk+rmTderit/qSimCVoXSH/DI=; b=zl8s2xtwPXx0ApukBvAXLE1Ih3lGzp3lRknXscXWXeN5n2z/4cDGA8dXYlAExnBEaJ +MTQ7pnUDEV4bwEEQNSODO52mIh/7tTHV57C5UKnhmC80nIXSZLt4WD6YEDb8CWCETUR 6C64w8I78aV33qY801lsAbuoVETyZOt60PJngljMMmA4Qk6JEnpspYTc8P2M+D06/Ygq hlwBfg+pfzgbmKoLUpvoDnG9vxjoiCZc7xh9M5utxNfh6Mfj00yZWYFQ9AbodsCOq9Lu FB8DAnHUkUE7cIUWcOABQd5z+XTJD9J7zt2301J4rRt6xSKee2saGO8B/k3vGqvaKADJ Id3g== MIME-Version: 1.0 X-Received: by 10.182.104.40 with SMTP id gb8mr137103obb.61.1416533634316; Thu, 20 Nov 2014 17:33:54 -0800 (PST) Received: by 10.202.115.4 with HTTP; Thu, 20 Nov 2014 17:33:54 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52C623@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52C623@ESESSMB209.ericsson.se> Date: Thu, 20 Nov 2014 15:33:54 -1000 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/awJydduvhu5Pi8pRfVTKfUwV_eI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 01:33:57 -0000 On 20 November 2014 06:28, Christer Holmberg wrote: > I agree that we don't need to specify application behaviour. But, I think we do need to be clear regarding the impacts on the transport/ICE layer, when/if/how it can be later re-used etc. How is my response unclear exactly? IF NOT connectivity check, then NO DON'T SEND. > My question is how/if the consent lost impacts "normal" ICE (STUN keep-alives etc), transport layer heartbeats etc. I don't understand this concern. You can't use the credentials (see above), and you can't send anything else. That's a terminal condition. > Also, as the entity may still receive media on the 5-tuple, that also means it still have to respond to incoming STUN requests etc. This is one of those "application layer" things. If you want to cease your own consent in response to losing consent, that's your choice. We already say that connectivity check responses (connectivity checks as a whole, actually) aren't subject to consent. Though there is a real mistake in the draft here: OLD: An endpoint MUST NOT send paced STUN connectivity checks toward any transport address unless the receiving endpoint consents to receive data. That is, no application data (e.g., RTP or DTLS) can be sent NEW: An endpoint MUST NOT send data other than paced STUN connectivity checks or responses toward any transport address unless the receiving endpoint consents to receive data. That is, no application data (e.g., RTP or DTLS) can be sent I'll generate a PR if my co-authors don't get to it. I don't know how that happened. > What about DTLS heartbeats, and other information sent on the transport layer? I ASSUME the entity will maintain those, as it still may receive media That is unquestionably application-layer data. The upshot here is that you will probably break RTP because you can't generate an RR. You can't generate SCTP acknowledgements either. Fact is, virtually all protocols are bidirectional and will break if one party can't send. From nobody Thu Nov 20 18:03:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838B51A8A62 for ; Thu, 20 Nov 2014 18:03:33 -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 pk4T5YNUiAYO for ; Thu, 20 Nov 2014 18:03:22 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC3B1A86E4 for ; Thu, 20 Nov 2014 18:03:20 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id a141so2991867oig.4 for ; Thu, 20 Nov 2014 18:03:19 -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=zqbowbaoNEsahM486llOJ/d2tJJfwXfUL9efbzbI/KI=; b=HO+kh0Xq4cCes2RT1uhRdOzvNvoXRyuehxIJpf2YJcBvSJhZMrJ+9Pk3OXClTPDprS s+HGjtPSQQB7hOgvjNlLJC+xq093Glzd8/ujmpBgDER6pQlYdu21dycWi6vlMgQ4iUnU Ta7NqUHEx0T0EQg4U8eUfrAe4Mldo4+P6VZ2pQzLId884AayDd1MOmbA7ycMhTwdD4+i ePGjLm6jrTM3BZ4eC29V2o5J8MBSpUjwEYwi+9FB2OHEEoEw2ZZ0nEMteiE1vt0xNqKZ oZHuLiTg7g8JRNjyHkNP2VgUZX9/4E3/4R1OUA753Mnq1cNGpCagGk1yEeInBYnIepa2 nItA== MIME-Version: 1.0 X-Received: by 10.60.161.76 with SMTP id xq12mr194875oeb.59.1416535399549; Thu, 20 Nov 2014 18:03:19 -0800 (PST) Received: by 10.202.115.4 with HTTP; Thu, 20 Nov 2014 18:03:19 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52C623@ESESSMB209.ericsson.se> Date: Thu, 20 Nov 2014 16:03:19 -1000 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MYHFVydrcu9QRu2bkVgrWmIpduk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 02:03:33 -0000 Please see https://github.com/Draft-Mafia/IETF-drafts/pull/8 On 20 November 2014 15:33, Martin Thomson wrote: > On 20 November 2014 06:28, Christer Holmberg > wrote: >> I agree that we don't need to specify application behaviour. But, I think we do need to be clear regarding the impacts on the transport/ICE layer, when/if/how it can be later re-used etc. > > How is my response unclear exactly? IF NOT connectivity check, then > NO DON'T SEND. > >> My question is how/if the consent lost impacts "normal" ICE (STUN keep-alives etc), transport layer heartbeats etc. > > I don't understand this concern. You can't use the credentials (see > above), and you can't send anything else. That's a terminal > condition. > >> Also, as the entity may still receive media on the 5-tuple, that also means it still have to respond to incoming STUN requests etc. > > This is one of those "application layer" things. If you want to cease > your own consent in response to losing consent, that's your choice. > We already say that connectivity check responses (connectivity checks > as a whole, actually) aren't subject to consent. > > Though there is a real mistake in the draft here: > > OLD: > An endpoint MUST NOT send paced STUN connectivity checks toward any > transport address unless the receiving endpoint consents to receive > data. That is, no application data (e.g., RTP or DTLS) can be sent > NEW: > An endpoint MUST NOT send data other than paced STUN connectivity > checks or responses toward any > transport address unless the receiving endpoint consents to receive > data. That is, no application data (e.g., RTP or DTLS) can be sent > > I'll generate a PR if my co-authors don't get to it. I don't know how > that happened. > >> What about DTLS heartbeats, and other information sent on the transport layer? I ASSUME the entity will maintain those, as it still may receive media > > That is unquestionably application-layer data. > > The upshot here is that you will probably break RTP because you can't > generate an RR. You can't generate SCTP acknowledgements either. > Fact is, virtually all protocols are bidirectional and will break if > one party can't send. From nobody Thu Nov 20 18:15:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36D1A8A56 for ; Thu, 20 Nov 2014 18:15:17 -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, 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 xC5LNSWYu-dI for ; Thu, 20 Nov 2014 18:15:15 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D14B1A8750 for ; Thu, 20 Nov 2014 18:15:14 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-45-546ea030680a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.DE.04076.030AE645; Fri, 21 Nov 2014 03:15:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 03:15:07 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: Ac/yEUlFgzg9keX0RtqfGQOICUeeIwMelQGAAS/qitAASiGsAAAFh1AAABTZMDAAEWEBAAAC+cag Date: Fri, 21 Nov 2014 02:15:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52E22D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52C623@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvja7BgrwQg91T5SyunfnHaLG8awej xdp/7ewOzB5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mt5/esFU8EOg4uqknWwN jAcEuhg5OSQETCR2v33IDGGLSVy4t56ti5GLQ0jgCKPE5of7mCGcJYwSZ35dYO1i5OBgE7CQ 6P6nDdIgIqArsejsA3YQm1kgTGLd1l0sILawQL5E69FJ7BA1BRKnG84wQthREhNO/2ICsVkE VCW+PjgGFucV8JU48qCZEWLXWmaJZ23z2EASnAKBEgeezAWzGYGu+35qDRPEMnGJW0/mM0Fc LSCxZM95qA9EJV4+/scKYStJNC55AnYzs4CmxPpd+hCtihJTuh+yQ+wVlDg58wnLBEaxWUim zkLomIWkYxaSjgWMLKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAiPq4JbfVjsYDz53PMQo wMGoxMNrEJkbIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GBO+FWXMnfZ5TtnuXbPY52r9ktJieHuDu4bh2i4ezxCbRfVz+iqcNp05u1/PSEm9RNj5uaJv l22D+ttPhxP/Kv8pvGn/J3Ku+uJ1fy7Fq4i3Fxn/OraAacqBJ3Lzv9g+XBp/X+JiTEBPcMPu bp1k65IzX9+wSTVnL7tU8HzDZOWrzPdynmgFLFdiKc5INNRiLipOBABX6OkniQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Hzokx8Z8XozQav6AI8va18Cd-lQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 02:15:17 -0000 SGksDQoNCj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgY29uY2Vybi4gIFlvdSBjYW4ndCB1c2Ug dGhlIGNyZWRlbnRpYWxzIChzZWUgYWJvdmUpLCBhbmQgeW91IGNhbid0IHNlbmQgYW55dGhpbmcg ZWxzZS4gIFRoYXQncyBhIHRlcm1pbmFsIGNvbmRpdGlvbi4NCg0KU28sIHdlIG5lZWQgdG8gYWRk IHRleHQgZXhwbGljaXRseSBzYXlpbmcgdGhhdCB0aGUgY3JlZGVudGlhbHMgY2FuIG5vIGxvbmdl ciBiZSB1c2VkLCBvbmNlIGNvbnNlbnQgaGFzIGV4cGlyZWQuIFRoYXQgbWFrZXMgaXQgY2xlYXIg dGhhdCBvbmUgY2Fubm90IHNpbXBseSAid2FpdCBmb3IgYSB3aGlsZSIsIGFuZCB0aGVuIHN0YXJ0 IHNlbmRpbmcgbWVkaWEgYWdhaW4uLi4NCg0KPiBUaG91Z2ggdGhlcmUgaXMgYSByZWFsIG1pc3Rh a2UgaW4gdGhlIGRyYWZ0IGhlcmU6DQo+DQo+IE9MRDoNCj4gICBBbiBlbmRwb2ludCBNVVNUIE5P VCBzZW5kIHBhY2VkIFNUVU4gY29ubmVjdGl2aXR5IGNoZWNrcyB0b3dhcmQgYW55DQo+ICAgdHJh bnNwb3J0IGFkZHJlc3MgdW5sZXNzIHRoZSByZWNlaXZpbmcgZW5kcG9pbnQgY29uc2VudHMgdG8g cmVjZWl2ZQ0KPiAgIGRhdGEuICBUaGF0IGlzLCBubyBhcHBsaWNhdGlvbiBkYXRhIChlLmcuLCBS VFAgb3IgRFRMUykgY2FuIGJlIHNlbnQNCj4gTkVXOg0KPiAgIEFuIGVuZHBvaW50IE1VU1QgTk9U IHNlbmQgZGF0YSBvdGhlciB0aGFuIHBhY2VkIFNUVU4gY29ubmVjdGl2aXR5IGNoZWNrcyBvciBy ZXNwb25zZXMgdG93YXJkIGFueQ0KPiAgIHRyYW5zcG9ydCBhZGRyZXNzIHVubGVzcyB0aGUgcmVj ZWl2aW5nIGVuZHBvaW50IGNvbnNlbnRzIHRvIHJlY2VpdmUNCj4gICBkYXRhLiAgVGhhdCBpcywg bm8gYXBwbGljYXRpb24gZGF0YSAoZS5nLiwgUlRQIG9yIERUTFMpIGNhbiBiZSBzZW50DQoNCkxv b2tzIGdvb2QuDQoNCj4+IFdoYXQgYWJvdXQgRFRMUyBoZWFydGJlYXRzLCBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBvbiB0aGUgDQo+PiB0cmFuc3BvcnQgbGF5ZXI/IEkgQVNTVU1FIHRoZSBl bnRpdHkgd2lsbCBtYWludGFpbiB0aG9zZSwgYXMgaXQgc3RpbGwgDQo+PiBtYXkgcmVjZWl2ZSBt ZWRpYQ0KPg0KPiBUaGF0IGlzIHVucXVlc3Rpb25hYmx5IGFwcGxpY2F0aW9uLWxheWVyIGRhdGEu DQo+DQo+IFRoZSB1cHNob3QgaGVyZSBpcyB0aGF0IHlvdSB3aWxsIHByb2JhYmx5IGJyZWFrIFJU UCBiZWNhdXNlIHlvdSBjYW4ndCBnZW5lcmF0ZSBhbiBSUi4gIFlvdSBjYW4ndCBnZW5lcmF0ZSBT Q1RQIGFja25vd2xlZGdlbWVudHMgZWl0aGVyLg0KPiBGYWN0IGlzLCB2aXJ0dWFsbHkgYWxsIHBy b3RvY29scyBhcmUgYmlkaXJlY3Rpb25hbCBhbmQgd2lsbCBicmVhayBpZiBvbmUgcGFydHkgY2Fu J3Qgc2VuZC4NCg0KU28sIGFkZGluZyBhIGZldyB3b3JkcyBhYm91dCB0aGF0IHdvdWxkIGJlIHVz ZWZ1bCwgdG8gaW5mb3JtIHBlb3BsZS4gQmVjYXVzZSwgYXMgeW91IHNheSwgZXhwaXJlZCBjb25z ZW50IGZvciBzZW5kaW5nIG1lZGlhIHdpbGwgb2Z0ZW4gY2F1c2UgdHJvdWJsZSBhbHNvIGZvciBy ZWNlaXZlZCBtZWRpYS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= From nobody Thu Nov 20 21:28:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCB51AD0B2 for ; Thu, 20 Nov 2014 21:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 oBP4zdrj80cc for ; Thu, 20 Nov 2014 21:28:13 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F397D1A0052 for ; Thu, 20 Nov 2014 21:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2085; q=dns/txt; s=iport; t=1416547692; x=1417757292; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Lp0Tu5GP9NscsYzpdzWuxXiiQcLrnCIV1aR+ALeMFAI=; b=YCymUuO9PM7wisVFswbRIpQvA7ButjJIHJ9lF9rYHaZLBCzSdBFOadBD qsvhQV3ySIOn8sKCCLLKF3PPEDLeaOkZIB94O5BVcaM7kEvG4Pn9BF2KJ TtpxAxCp2G2zf7TllC69VvfLcOoETaaYKuWHdaee8Ogbi394ZlOPEL+xe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAC7NblStJA2J/2dsb2JhbABagw6BLgTTKwKBBBYBAQEBAX2EAgEBAQQ6SwQCAQgRAwECHwULIREdCAIEARKILAMSzVANhk8BAQEBAQEBAQIBAQEBAQEBARqOTYJCBoRFBZJXhTaEQIIUgTOOUoZ2gjaBRW2BSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,428,1413244800"; d="scan'208";a="98770727" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 21 Nov 2014 05:28:12 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sAL5SBTD032135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Nov 2014 05:28:12 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.185]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 23:28:11 -0600 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions Thread-Index: AQHQBUvwJjfjOKAbZ06T7Mg5VhaLYw== Date: Fri, 21 Nov 2014 05:28:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4CE861@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D525F52@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52C623@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52E22D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52E22D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.64.84] Content-Type: text/plain; charset="us-ascii" Content-ID: <30E151219456714F9E3F912158F71B37@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8YIkljDvOczjRkykExruU2fJT-I Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 05:28:15 -0000 -----Original Message----- From: Christer Holmberg Date: Friday, 21 November 2014 7:45 am To: Martin Thomson Cc: Cisco Employee , "rtcweb@ietf.org" Subject: RE: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions >Hi, > >> I don't understand this concern. You can't use the credentials (see >>above), and you can't send anything else. That's a terminal condition. > >So, we need to add text explicitly saying that the credentials can no >longer be used, once consent has expired. That makes it clear that one >cannot simply "wait for a while", and then start sending media again... > >> Though there is a real mistake in the draft here: >> >> OLD: >> An endpoint MUST NOT send paced STUN connectivity checks toward any >> transport address unless the receiving endpoint consents to receive >> data. That is, no application data (e.g., RTP or DTLS) can be sent >> NEW: >> An endpoint MUST NOT send data other than paced STUN connectivity >>checks or responses toward any >> transport address unless the receiving endpoint consents to receive >> data. That is, no application data (e.g., RTP or DTLS) can be sent > >Looks good. +1. Looks this text was broken in ver 08. Ver 07 has proper text. Ram > >>> What about DTLS heartbeats, and other information sent on the >>> transport layer? I ASSUME the entity will maintain those, as it still >>> may receive media >> >> That is unquestionably application-layer data. >> >> The upshot here is that you will probably break RTP because you can't >>generate an RR. You can't generate SCTP acknowledgements either. >> Fact is, virtually all protocols are bidirectional and will break if >>one party can't send. > >So, adding a few words about that would be useful, to inform people. >Because, as you say, expired consent for sending media will often cause >trouble also for received media. > >Regards, > >Christer > > From nobody Mon Nov 24 07:36:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE1C1A6FCF for ; Mon, 24 Nov 2014 07:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sctM79UkwN0h for ; Mon, 24 Nov 2014 07:36:39 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507591A6FB0 for ; Mon, 24 Nov 2014 07:36:39 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-7e-547350855503 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.7A.04076.58053745; Mon, 24 Nov 2014 16:36:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 16:36:36 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "rtcweb@ietf.org" Thread-Topic: JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Mon, 24 Nov 2014 15:36:36 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW5rQHGIwcVXwhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro+n3aqaCo8wVTz4WNjB+Z+pi5OSQEDCR+HRzIiOELSZx4d56 ti5GLg4hgSOMEvu//2KGcJYwStz/3w7WwSYQKLF13wI2EFtEQF3i8sML7CC2sICGxNbvT6Hi uhJbFm9ihrD1JG5+ucACYrMIqEr07NjNCmLzCvhKzJn7GizOCLT5+6k1YPOZBcQlbj2ZD3Wd gMSSPeeZIWxRiZeP/wH1cgDZShLTtqZBlOtJ3Jg6hQ3C1pZYtvA1M8R4QYmTM5+wTGAUnoVk 6iwkLbOQtMxC0rKAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmCAH9zy22oH48HnjocY BTgYlXh4C64XhQixJpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BsYin8npG8+dPWgw91wH95U/m17NX1LjPuuRb7yxvw2L9uriQwZdc85v41n2V/KHQKUg05dL 1V+m3ZtXeEyWx/sA2+PTfhl39H19mJdF6/lsX+MR18u82q+MqWTrlnXmUnkqfPLs/3xEDz2f khP7O/nMbWN9T9lMj+qUr9O732mUVJxc8kZu8kolluKMREMt5qLiRACMFa8zUQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pShO2ZQ8H04bTLWWanpK3Pe6zUQ Subject: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Nov 2014 15:36:41 -0000 Hi,=0A= =0A= I'm looking into the JSEP draft. One thing that seems strange is that in = =0A= every offer the role offered is "actpass", also for existing =0A= connections. As I read section 7.3 of =0A= https://www.rfc-editor.org/rfc/rfc4145.txt the established roles should =0A= be maintained in such situations.=0A= =0A= What is the reason for the always offering "actpass" also for =0A= established roles/connections?=0A= =0A= Stefan=0A= From nobody Mon Nov 24 12:18:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF431A6FF3 for ; Mon, 24 Nov 2014 12:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqkISmFG4OHv for ; Mon, 24 Nov 2014 12:18:46 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6971F1A6FE6 for ; Mon, 24 Nov 2014 12:18:46 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAOKIj7s034167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Nov 2014 14:18:45 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <547392A4.4080309@nostrum.com> Date: Mon, 24 Nov 2014 14:18:44 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------030708000505030801090809" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ftknNJtMx5JlBojdimQyA8Tqewc Subject: [rtcweb] draft-ietf-rtcweb-data-channel (Issue 5) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Nov 2014 20:18:48 -0000 This is a multi-part message in MIME format. --------------030708000505030801090809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I promised to propose a minor fix to the RFC 2119 use for the Issue 5 resolution discussed in Hawaii. The text on the slide was: > The message orientation of SCTP is used to preserve the message > boundaries of > user messages. Therefore, no more than one message MUST be put into an > SCTP > user message. If the deprecated PPID-based fragmentation and > reassembly is not > used, exactly one message MUST be put into an SCTP user message. I propose reformulating as: The message-orientation of SCTP is used to preserve the message boundaries of user messages. Therefore, senders MUST NOT put more than one application message into an SCTP message. Unless the deprecated PPID-based fragmentation and reassembly is used, the sender MUST include exactly one application message in each SCTP message. One of the things that flummoxed me a bit here in trying to rework the language is that "message" in the original formulation meant two different things: (1) an SCTP message (as in RFC4960) and (2) an application message (as in http://w3c.github.io/webrtc-pc/). I suggest that the document should include a terminology section that clearly lays out these two concepts with clearly-defined terms, citing these two specifications, and that the remainder of the document is rigorously updated to reflect that terminology (i.e. the term "message" should never appear by itself, only prefixed with an adjective to make it clear which of these two messages is meant). /a --------------030708000505030801090809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I promised to propose a minor fix to the RFC 2119 use for the Issue 5 resolution discussed in Hawaii. The text on the slide was:

The message orientation of SCTP is used to preserve the message boundaries of
user messages. Therefore, no more than one message MUST be put into an SCTP
user message. If the deprecated PPID-based fragmentation and reassembly is not
used, exactly one message MUST be put into an SCTP user message.

I propose reformulating as:

The message-orientation of SCTP is used to preserve the message boundaries of user messages.  Therefore, senders MUST NOT put more than one application message into an SCTP message.  Unless the deprecated PPID-based fragmentation and reassembly is used, the sender MUST include exactly one application message in each SCTP message.

One of the things that flummoxed me a bit here in trying to rework the language is that "message" in the original formulation meant two different things: (1) an SCTP message (as in RFC4960) and (2) an application message (as in http://w3c.github.io/webrtc-pc/). I suggest that the document should include a terminology section that clearly lays out these two concepts with clearly-defined terms, citing these two specifications, and that the remainder of the document is rigorously updated to reflect that terminology (i.e. the term "message" should never appear by itself, only prefixed with an adjective to make it clear which of these two messages is meant).

/a
--------------030708000505030801090809-- From nobody Mon Nov 24 14:19:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB151A7D80 for ; Mon, 24 Nov 2014 14:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.701 X-Spam-Level: *** X-Spam-Status: No, score=3.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oghq85yuCQu1 for ; Mon, 24 Nov 2014 14:19:45 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12681A0673 for ; Mon, 24 Nov 2014 14:19:44 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so9871174ier.32 for ; Mon, 24 Nov 2014 14:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MybhEGEr0lGuiOjgNcCC/I/J4gSOu71VzrLTFMMWu5E=; b=IbHfhI/PJS8WhsnrjaQe0Ke5S+uJvwt57nvILBolTPdM2MtQBM2W2fEcxvyKMA/Pdg 4ZcMdWXt4xEYoGkz7llGn3bYcIPkVnaQgTMkCwREyOKlMLYFQkdGZYw+m5wQwK2dxzHE fD2cqdS+Hr57HbM/R1c3Z9FHI6QShaBwdIWNB0AeovtOd6zCRHt0v0J7zwCn5XJKHmHL fPBZdKn4HIJeTx6sTxM4vEUW9QGYkmBmzrBKRzFnzwjYAvcYriKYRR6qYTf/jE8ZJYkB //j38VebEitk2h0pD8RgkAVHa3D6IM68v3xECLG2+BTAwPnYCuxksGX4oCq/d5FbBAiV zLtg== MIME-Version: 1.0 X-Received: by 10.107.170.98 with SMTP id t95mr20633618ioe.7.1416867583849; Mon, 24 Nov 2014 14:19:43 -0800 (PST) Received: by 10.43.3.4 with HTTP; Mon, 24 Nov 2014 14:19:43 -0800 (PST) Date: Mon, 24 Nov 2014 14:19:43 -0800 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/mixed; boundary=001a1142d9dc07b78c0508a231e2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/u-pf94KO-ep-hwpdYM8fnQd9GJQ Subject: [rtcweb] Draft Minutes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Nov 2014 22:19:50 -0000 --001a1142d9dc07b78c0508a231e2 Content-Type: multipart/alternative; boundary=001a1142d9dc07b7880508a231e0 --001a1142d9dc07b7880508a231e0 Content-Type: text/plain; charset=UTF-8 Attached are initial draft minutes of the RTCWEB sessions at IETF 91. We have included the raw notes received after the list of action items and presentations. Please review, thanks, Ted, Cullen, Sean --001a1142d9dc07b7880508a231e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Attached are initial draft minutes of the RTCWEB= sessions at IETF 91.=C2=A0 We have included the raw notes received after t= he list of action items and presentations.=C2=A0 Please review,

than= ks,

Ted, Cullen, Sean
--001a1142d9dc07b7880508a231e0-- --001a1142d9dc07b78c0508a231e2 Content-Type: text/plain; charset=UTF-8; name="RTCWEBMinutesIETF91.txt" Content-Disposition: attachment; filename="RTCWEBMinutesIETF91.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i2wedh9l0 77u/UlRDV0VCIElFVEY5MWRyYWZ0LWlldGYtcnRjd2ViLXZpZGVvIA0KQ2hhaXJzOiAgQ3VsbGVu IEplbm5pbmdzLCBUZWQgSGFyZGllLCBTZWFuIFR1cm5lcg0KTm90ZXM6ICBUaW0gVGVycmliZXJy eSwgS2VpdGggRHJhZ2UsIFN0ZXZlIERvbm92YW4sIEJyaWFuIFJvc2VuDQoNCg0KUmVjb3JkaW5n IGRheSAxOiBodHRwOi8vcmVjb3JkaW5ncy5jb25mLm1lZXRlY2hvLmNvbS9QbGF5b3V0L3dhdGNo LmpzcD9yZWNvcmRpbmc9SUVURjkxX1JUQ1dFQiZjaGFwdGVyPWNoYXB0ZXJfMA0KUmVjb3JkaW5n IGRheSAyOiANCmh0dHA6Ly9yZWNvcmRpbmdzLmNvbmYubWVldGVjaG8uY29tL1BsYXlvdXQvd2F0 Y2guanNwP3JlY29yZGluZz1JRVRGOTFfUlRDV0VCX0lJJmNoYXB0ZXI9Y2hhcHRlcl8wDQoNCg0K QWN0aW9uIGl0ZW1zOg0KDQoNCkNoYWlycyB0byBhc2sgZm9yIGNvbW1lbnRzIG9uIHRoZSBsaXN0 IGZvciB0aGUgR2F0ZXdheSBhbmQgUkVUVVJOICBkcmFmdCBiZWZvcmUgY29uc2lkZXJpbmcgZm9y IGFkb3B0aW9uLg0KDQoNCkNoYWlycyB0byBjb25maXJtIGFkb3B0aW9uIG9mIGRyYWZ0LXViZXJ0 aS1ydGN3ZWItZmVjIG9uIHRoZSBsaXN0Lg0KDQoNCkRhdGEgY2hhbm5lbCBkcmFmdCBhdXRob3Jz IHNob3VsZCB1cGRhdGUgdGhlIGRyYWZ0IGFuZCByZS1jaXJjdWxhdGUgLXJ0byBJRVNHLg0KDQoN CkpTRVAgZWRpdG9ycyBzaG91bGQgdXBkYXRlIHRoZSBkcmFmdCBhZnRlciBjb25maXJtYXRpb24g b2YgZGVjaXNpb25zIG9uIHRoZSBsaXN0Lg0KDQoNCkhhcmFsZCBzaG91bGQgdXBkYXRlIHRlcm1p bm9sb2d5IHRvIHJlZmxlY3QgbmV3IHRlcm0gZm9yIOKAnGRldmljZeKAnS4gDQoNCg0KU2VhbiAo YXMgQ2hhaXIpIHRvIGNvbmZpcm0gbWFuZGF0b3J5IHRvIGltcGxlbWVudCB2aWRlbyBjb2RlYyDi gJxzZW5zZSBvZiB0aGUgcm9vbeKAnSBvbiB0aGUgbGlzdC4NCg0KDQpBZGFtIFJvYWNoIHRvIHVw ZGF0ZSBkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlbyB3aXRoIHJlc29sdXRpb25zIG9mIG9wZW4gaXNz dWVzLg0KDQoNCk1hZ251cyBzaG91bGQgYmUgZGlzdHVyYmVkIG9uIHBhdGVybml0eSBsZWF2ZSB0 byBjb25maXJtIHRoZSB1c2Ugb2YgYj0uDQoNCg0KDQoNCkRheSAxDQpBZ2VuZGE6IEFkbWluaXN0 cml2aWENCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05 MS1ydGN3ZWItMS5wZGYNCkpTRVANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEv c2xpZGVzL3NsaWRlcy05MS1ydGN3ZWItNS5wZGYNCkRhdGEgQ2hhbm5lbCBpc3N1ZXMNCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05MS1ydGN3ZWItMC5w ZGYNClRlcm1pbm9sb2d5DQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL3NsaWRl cy9zbGlkZXMtOTEtcnRjd2ViLTIucGRmDQpHYXRld2F5DQpodHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzkxL3NsaWRlcy9zbGlkZXMtOTEtcnRjd2ViLTMucGRmDQpSZXR1cm4NCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05MS1ydGN3ZWItNC5w ZGYNCg0KDQpEYXkgMg0KQWRtaW4vY2hhaXIgc2xpZGVzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy85MS9zbGlkZXMvc2xpZGVzLTkxLXJ0Y3dlYi05LnBkZg0KDQoNCkRlcGVuZGVu Y3kgcmV2aWV3Og0KZHJhZnQtamVubmluZ3MtcnRjd2ViLWRlcHMtMDUNCg0KDQpGRUMgZGlzY3Vz c2lvbjoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05 MS1ydGN3ZWItNi5wZGYNCg0KDQpDb25zb2xpZGF0ZWQgY29kZWMgc2xpZGVzOg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MS9zbGlkZXMvc2xpZGVzLTkxLXJ0Y3dlYi03LnBkZg0K DQoNCg0KDQpUaGUgdGV4dCBmb2xsb3dpbmcgdGhpcyBpcyB0aGUgcmF3IG5vdGVzIHRoZSBjaGFp cnMgcmVjZWl2ZWQuICBUaGlzIGlzIG5vdCAxMDAlIGNvbXBsZXRlIGR1ZSB0byB0aGUgZGlmZmlj dWx0eSBvZiB0cmFuc2NyaWJpbmcgZXZlcnl0aGluZyBidXQgdGhlIHRoZSByZWNvcmRpbmdzIGFy ZSBhdmFpbGFibGUgZm9yIGNsYXJpZmljYXRpb25zLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCk5vdGVzIGZyb20gVGltIFRl cnJpYmVycnkNCg0KDQoNCg0KCT09PSBKU0VQID09PQ0KDQoNCi0gbT0gcHJvdG8gZmllbGQNCiAg KiBObyBvYmplY3Rpb25zIHRvIGJhc2ljIHByb3Bvc2FsOiBNVVNUIFtyZS1db2ZmZXIgY29ycmVj dCB0aGluZywgTVVTVCBhY2NlcHQgUlRQL1tTXUFWUFtGXSBvciAoVURQfFRDUCkvVExTL1JUUC9T QVZQW0ZdLCBhbnN3ZXIgTVVTVCBtYXRjaCBvZmZlcg0KICAqIFVzZSBVRFAgdW5sZXNzIHlvdSBr bm93IGZvciBjZXJ0YWluIHRoYXQgeW91J3JlIGRvaW5nIFRDUCAoZS5nLiwgaW4gYSByZS1vZmZl ciBhZnRlciBJQ0UgaGFzIGNvbXBsZXRlZCkNCiAgKiBJZiB3ZSdyZSB0YWxraW5nIGFib3V0IFND VFAvRFRMUyBhbmQgd2UncmUgbm90IHNheWluZyBhPWZpbmdlcnByaW50IGlzIHJlcXVpcmVkLCB0 aGUgSlNFUCBkcmFmdCBuZWVkcyB0byBiZSB1cGRhdGVkLg0KDQoNCi0gVGV4dCBhYm91dCBEVExT LVNSVFAgZXhpc3RzIGFsc28gaW4gdGhlIHJ0Y3dlYiBvdmVydmlldy4gV2Ugc2hvdWxkIGVpdGhl ciBzYXkgaXQgb25jZSwgb3IgYXQgbGVhc3QgbWFrZSBzdXJlIHRoZXkncmUgY29uc2lzdGVudC4N CiAganViZXJ0aTogV2Ugc2hvdWxkIHNheSB3ZSBoYXZlIHRvIHVzZSBEVExTLCBhbmQgaW4gdGhl IHNwZWNpYWwgY2FzZSBvZiBtZWRpYSBEVExTLVNSVFAuDQogIGZsdWZmeTogV2Ugc2hvdWxkIHNh eSB3ZSBoYXZlIHRvIHVzZSBUTFMsIGFuZCBJIGluY2x1ZGUgRFRMUyBpbiB0aGF0Lg0KDQoNCi0g QnVuZGxlL211eCBwb2xpY3kgKCM5MSkNCiAgKiBHbyB3aXRoIHR3byB2YXJpYWJsZXM6IFBldGVy J3MgIkkgY2FyZSBhIGxpdHRsZSBiaXQiIGlzIHRoZSBtb3N0IGNhcmUgd2UgY2FuIG11c3Rlci4N Cg0KDQotIFZhbHVlIG9mIHtsb2NhbCxyZW1vdGV9RGVzY3JpcHRpb24gd2hlbiBjbG9zZWQgKCM4 OCkNCiAgKiBUYWtlIHRoaXMgb3V0IG9mIHRoZSBzcGVjIGFuZCBsZXQgdGhlIFczQyBkZWFsIHdp dGggaXQuDQoNCg0KLSBhPXNzcmMgZm9yIGE9cmVjdm9ubHkgbS1saW5lcyAoIzc5KQ0KICAqIFRo aXMgaWRlYSB3aWxsIGdvIG9mZiBhbmQgZGllIGFuZCB3ZSdsbCBjb21lIHVwIHdpdGggc29tZSBv dGhlciB3YXkgb2YgZG9pbmcgdGhpcy4NCg0KDQotIERlYXRoIG9mIGEgb25lLXdheSBzdHJlYW0g KCM3NikNCiAgKiBXaGF0ZXZlciBpbnNhbmUgc3R1ZmYgaXMgaW4gdGhlIGRvY3VtZW50LCB0aGVy ZSdzIG5vIHdheSB0byBoYXZlIGNvbnRpbnVvdXMgY29uc2VudCBieSBtLWxpbmVzLg0KICAqIFN0 aWxsIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpbiBNTVVTSUMsIG5vIHZvbHVudGVlciBmb3VuZC4N Cg0KDQotIE11bHRpcGxlIHQ9bGluZXMgKCMyNykNCiAgKiBQcm9wb3NhbCBhY2NlcHRlZA0KICAq IGFiciB2b2x1bnRlZXJzIHRvIHJldmlldyBzcGVjcyBmb3Igb3RoZXIgcGxhY2VzIHdoZXJlIHdl IGFsbG93IG9uZSBvciBtb3JlIGRvb2RhZHMgd2hlbiB3ZSBzaG91bGQgcmVxdWlyZSBleGFjdGx5 IG9uZS4NCg0KDQotIENoYW5naW5nIGI9ICgjOSkNCiAgKiBObyBvbmUgYnV0IE1hZ251cyB1bmRl cnN0YW5kcyBiPQ0KICAqIElmIHRoZSBlZGl0b3JzIGNhbiBnZXQgdGhlIGRvY3VtZW50IGZpbmlz aGVkIGJlZm9yZSBNYWdudXMgcmV0dXJucyBmcm9tIHBhdGVybml0eSBsZWF2ZSwgZmx1ZmZ5IHdp bGwgYnV5IE1hZ251cyBlbm91Z2ggYm90dGxlcyBvZiBzY290Y2ggdGhhdCBoZSB3aWxsIGRvIHRo aXMgd2hpbGUgb24gcGF0ZXJuaXR5IGxlYXZlLg0KDQoNCj09PSBEYXRhIENoYW5uZWxzID09PQ0K DQoNCi0gRFRMUyAxLjAgdnMuIDEuMg0KICAqIENhbiByZWZlcmVuY2UgYm90aCA0MzQ2IHRvIDYz NDcgKGh1bSB0YWtlbiwgbm9uZSBvcHBvc2VkKQ0KICAqIEFuZHJlIHJhaXNlZCBhbiBvYmplY3Rp b24gdG8gTVVTVCAxLjAsIE1VU1QgMS4yDQogICogVGVkL1R1ZXhlbiBwcm9wb3NlIE1VU1QgMS4w LCBTSE9VTEQgZG8gdGhlIG1vc3QgcmVjZW50IHZlcnNpb24gYXMgdGhlIGFwcHJvcHJpYXRlIGNo b2ljZS4NCiAgICArIFdlIHdpbGwgbmVlZCB0byBhZGp1c3QgdGhlIGNyeXB0byBzdWl0ZXMgYXMg d2VsbC4NCg0KDQotIFVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzDQogICogZmx1ZmZ5J3Mgb3Bp bmlvbiBhcyBhIGNoYWlyIGlzIHRoYXQgd2Ugbm90IG1vdmUgdGV4dCBmcm9tIG9uZSBib2F0IHRv IGFub3RoZXIuDQogICogUGxhbiBCOiBQdXQgaXQgaW4gYW4gYXBwZW5kaXggYW5kIG1hcmsgaXQg aW5mb3JtYXRpb25hbC4NCg0KDQotIE5vcm1hdGl2ZSBsYW5ndWFnZSBjaGFuZ2VzDQogICogS2Vp dGg6IHRoZSBwYXNzaXZlIHZvaWNlIG1lYW5zIGl0J3Mgbm90IGNsZWFyIHdobyBoYXMgdG8gY29t cGx5IHdpdGggaXQuDQogICogYWJyIHRvIHNlbmQgY29tbWVudHMgYWJvdXQgYXdrd2FyZCB0ZXh0 IHRvIHRoZSBsaXN0Lg0KDQoNCj09PSBXZWJSVEMgVGVybWlub2xvZ3kgPT09DQoNCg0KLSBBIG1v YmlsZSBhcHAgdGhhdCBjb21waWxlcyBpbiBXZWJSVEMgc3VwcG9ydCB3b3VsZCBiZSBhIGRldmlj ZT8gWWVzLg0KDQoNCi0gTm9kZS5qcyB3b3VsZCBiZSBhIGJyb3dzZXI/IElmIGl0IGV4cG9zZXMg dGhlIEphdmFzY3JpcHQgQVBJLCB0aGVuIHllcy4NCi0gQSBicm93c2VyIHBsdWdpbiB0aGF0IHBy b3ZpZGVzIHJ0Y3dlYiBmdW5jdGlvbmFsaXR5IGluIGEgbm9uLVdlYlJUQyBjYXBhYmxlIGJyb3dz ZXI/IElmIGl0IHByb3ZpZGVzIHRoZSBydGN3ZWIgQVBJLCB0aGVuIHRoZSBjb21iaW5hdGlvbiBv ZiBwbHVnaW4rYnJvd3NlciBpcyBhIFVzZXIgQWdlbnQuDQotIEEgbGlicmFyeSB0aGF0IGltcGxl bWVudHMgV2ViUlRDOiB0aGUgbGlicmFyeSBieSBpdHNlbGYgZG9lc24ndCBkbyBhbnl0aGluZywg YnV0IG1pZ2h0IGJlIGEgRGV2aWNlIG9yIGEgVXNlciBBZ2VudCB3aGVuIGNvbWJpbmVkIHdpdGgg b3RoZXIgdGhpbmdzIChqdWJlcnRpIGRpc3NlbnRzIHRoYXQgdGhpbmdzIHRoYXQgYXJlIHByb2dy YW1tYWJsZSBzaG91bGQgYmUgVXNlciBBZ2VudHMpLg0KDQoNClBvbGwgZm9yIG5hbWVzIGluIHBs YWNlIG9mIGRldmljZTogIk5vbi1icm93c2VyIiBoYWQgbW9yZSBoYW5kcyB0aGFuICJOYXRpdmUg QXBwbGljYXRpb24iLg0KDQoNCkVLUjogV2UgaGF2ZSB0aGlzIHBob25lIHRoYXQgZG9lc24ndCBk byB2aWRlby4NCmp1YmVydGk6IENsZWFybHkgaWYgdGhlIGRldmljZSBkb2Vzbid0IHN1cHBvcnQg dmlkZW8sIHRoZW4gaXQgZG9lc24ndCBuZWVkIHRvIGRvIHZpZGVvLg0KDQoNCmh0YTogVGhlIGNh c2Ugb2Ygc29tZXRoaW5nIHRoYXQgaGFzIGFuIGV4cG9zZWQgQVBJLCBldmVuIGlmIGl0J3Mgbm90 IGEgSlMgQVBJLCBuZWVkcyB0byBiZSBtZW50aW9uZWQgc29tZXdoZXJlLg0KDQoNCj09PSBSRVRV Uk4gPT09DQoNCg0KbXQ6IFlvdSBoYXZlIHR3byBkaWZmZXJlbnQgImhvc3QiIGNhbmRpZGF0ZXMu IFlvdSB3YW50IHRvIHByaW9yaXRpemUgdGhlbSBhcHByb3ByaWF0ZWx5DQpmbHVmZnk6IFRoaXMg bXVzdCBndWFyYW50ZWUgdGhhdCBpZiB0aGUgSlMgaXMgdHJ5aW5nIHRvIHByZXNlcnZlIHByaXZh Y3ksIHRoZSBlbnRlcnByaXNlLXByb3ZpZGVkIGNvbmZpZ3VyYXRpb24gbXVzdCBub3Qgb3ZlcnJp ZGUgdGhhdCAoanViZXJ0aTogdGhhdCB3b3VsZG4ndCBoYXBwZW4gYmVjYXVzZSB5b3UnZCBzdGls bCBnbyB0aHJvdWdoIHRoZSBhcHBsaWNhdGlvbiBwcm94eSkuDQpmbHVmZnk6IEFzIGxvbmcgYXMg aXQncyBub3QgaGFpcnBpbm5pbmcsIEkgd291bGRuJ3Qgd2FudCB0byBoYXZlIHRvIGdvIHRocm91 Z2ggdGhlIGFwcGxpY2F0aW9uIHByb3h5IGlmIEkgZGlkbid0IGhhdmUgdG8gKGp1YmVydGk6IGFn cmVlZCkuDQoNCg0KT2YgdGhvc2Ugd2hvIGhhdmUgcmVhZCB0aGlzLCB3aG8gdGhpbmtzIHdlIHNo b3VsZCBhZG9wdCBpdCBhcyBhIFdHIGRyYWZ0PyAibGVzcyB0aGFuIGhhbGYiIC8gImEgdmVyeSBz bWFsbCBudW1iZXIiLg0KDQoNClRha2UgaXQgYmFjayB0byB0aGUgbGlzdCBmb3IgY29tbWVudHMu DQoNCg0KPT09IFdlYlJUQyBHYXRld2F5cyA9PT0NCg0KDQotIFRlZDogV2Ugd2FudCB0byBzZWUg YXQgbGVhc3Qgb25lIGNvbW1lbnQgb24gdGhlIGxpc3QgYmVmb3JlIHdlIGFzayBmb3IgV0cgYWRv cHRpb24uDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNClJhdyBub3RlcyBm cm9tIFN0ZXZlIERvbm92YW4gZm9yIERheSAyDQoNCg0KRkVDICAoc2VlIGRyYWZ0LXViZXJ0aS1y dGN3ZWItZmVjIGFuZCBkcmFmdC1zaW5naC1wYXlsb2FkLXJ0cC0xZDJkLXBhcml0eS1zY2hlbWXD ouKCrMKdKSAgKDIwIG1pbikgDQoNCiAgICBNYWluIGlzc3VlIGlzIHdlIG5lZWQgdG8gZGVjaWRl IHdoYXQsIGlmIGFueSwgRkVDIGlzIE1USSBmb3IgIFJUQ1dlYg0KDQotIEFkYXB0aW5nIGRyYWZ0 LXViZXJ0aS1ydGN3ZWItZmVjIGFzIGEgd29ya2luZyBncm91cCBpdGVtDQotIFdpbGwgY29uZmly bSBvbiB0aGUgbGlzdA0KDQoNCg0KLSBPcGVuIGlzc3VlIDEgLSBubyBvYmplY3Rpb25zDQotIE9w ZW4gaXNzdWUgMiAtIHNob3VsZCBiZSBzb2x2ZWQgc29tZXdoZXJlIGVsc2UsIG5vdCBhIHJ0Y1dF QiBzcGVjaWZpYyBpc3N1ZQ0KLSBPcGVuIGlzc3VlIDMgLSBNVVNUIHNlbmQgKGRlZmF1bHQgb2Yg cmlnaHQgc2lkZSB1cCksIFNIT1VMRCBiZSBhYmxlIHRvIHJlY2VpdmUsIE5lZWQgYSBoZWFkZXIg ZXh0ZW5zaW9uIGRlZmluaXRpb24sIG90aGVyIHRoaW5ncyBpbiA1LjIgDQpvZiBydGN3ZWIgdXNh Z2UgZG9jdW1lbnQgdGhhdCBzaG91bGQgYmUgTVVTVC4NCi0gT3BlbiBpc3N1ZSA0IC0gUmVxdWVz dCBmb3Igc29tZW9uZSB0byBzZW5kIGEgY2l0YXRpb24uDQotIE9wZW4gaXNzdWUgNSAtIFNob3Vs ZCB0YWtlIHRvIHRoZSBsaXN0IGJ1dCBhbnN3ZXIgbWF5IGJlIHllcywgQmVybmFyZCBhbmQgb3Ro ZXJzIHdpbGwgZ2VuZXJhdGUgbGlzdC4NCi0gT3BlbiBpc3N1ZSA2IC0gTVRJIChuZXh0IHRvcGlj KQ0KDQpNVEkgVmlkZW8gQ29kZWMgICh0aW1lIGRlcGVuZGluZykNCg0KTm92ZWwgcGxhbiAtIEFk YW0gUm9hY2gNCg0KLSBHZW5lcmFsIGZlZWRiYWNrIHRoYXQgbW9yZSBkZXRhaWwgaXMgbmVlZGVk IG9uIHdoYXQgd291bGQgdHJpZ2dlciByZW1vdmluZyBvbmUgb2YgdGhlIE1USXMuDQotIFRoZXJl IGlzIHByZWNlZGVuY2UgZm9yIHRoaXMgbWV0aG9kIHdpdGggY3J5cHRvIHN1aXRlcyBhbmQgZXhw aXJhdGlvbiBvZiBSU0EgcGF0ZW50cw0KLSBJcyB0cmlnZ2VyIGZvciB0aGUgd2hvbGUgY29kZWMg KGVuY29kZXIgYW5kIGRlY29kZXIpIGJlaW5nIHJveWFsdHkgZnJlZSBvciBvbmx5IHRoZSBlbmNv ZGVyPyAgQ3VycmVudGx5IHdob2xlIGNvZGVjDQoNCkpvbmF0aGFuIFJvc2VuYmVyZw0KDQotIExl dCdzIG1ha2UgcnRjd2ViIHN1Y2Nlc3NmdWwgdG9nZXRoZXIgLSBwbGVhc2UgcGxlYXNlIHBsZWFz ZQ0KDQpIYXJhbGQgQWx2ZXN0cmFuZA0KDQotICsxDQotIEdvb2dsZSBpbnRlbmRzIHRvIGltcGxl bWVudCB0aGUgc3RhbmRhcmQgDQoNCi0tLS0NCg0KIlRoZSBHcmVhdCBDb2RlYyBDb21wcm9taXNl Ig0KDQotIERpcmVjdGlvbiBmcm9tIGNoYWlyIC0gU3RhbmQgaWYgeW91IGFyZSBwYXJ0aWNpcGF0 aW5nIGluIHRoZSBkZWNpc2lvbiAtIEEgbG90IG9mIHBlb3BsZSBzdG9vZCAobW9zdCBvZiB0aGUg cm9vbSkNCg0KTmV3IHRlY2huaWNhbCBpc3N1ZXMgZGlzY3Vzc2lvbg0KDQotIFR5cGUgMyBkZWNs YXJhdGlvbnMgbWFkZSBhZ2FpbnN0IFZQOCBpbiBJU08gKE1pY3Jvc29mdCBhbmQgQXBwbGUgaW5k aWNhdGVkIHRoaXMgaXMgYSBibG9ja2luZyBpc3N1ZSBmb3IgaW1wbGVtZW50aW5nIFZQOCkNCi0g SC4yNjQgTVRJIGRvY3VtZW50IGhhcyBzb21lIG5ldyBpbmZvcm1hdGlvbg0KLSBHU01BIHJlcG9y dCAtIEhhcmFsZCBxdWVzdGlvbmVkIHNvbWUgb2YgdGhlIG51bWJlcnMgaW4gdGhlIHJlcG9ydA0K LSBBZGFtIHB1c2hlZCBiYWNrIHRoYXQgdGhlIG5ldyBpbmZvcm1hdGlvbiBkb2Vzbid0IHJlYWxs eSBpbXBhY3QgdGhlIHByb3Bvc2FsIGJlaW5nIG1hZGUNCi0gUXVlc3Rpb246IElmIHdlIGFjY2Vw dCB0aGlzIHByb3Bvc2FsIHRvZGF5IGNhbiB3ZSBjaGFuZ2UgaXQgdG8gYW5vdGhlciBwcm9wb3Nh bCB0aGF0IHdhcyByZWNlbnRseSBwdXQgb24gdGhlIGxpc3QgbGF0ZXIuICBBbnN3ZXIgeWVzLg0K LSBRdWVzdGlvbjogQ291bGQgdGhpcyBjaGFuZ2Ugd2l0aGluIDI0IG1vbnRocz8gQ3VsbGVuLCBw b3NzaWJsZSBidXQgY2FuJ3QgcHJlZGljdC4NCg0KLS0tLQ0KDQpUaGUgaHVtczoNCg0KV2hvIGRv ZXMgbm90IHdhbnQgdG8gdGFrZSB0aGUgc2Vuc2Ugb2YgdGhlIHJvb20gb24gd2hldGhlciB0byBh ZGQgdGhlIGNvbXByb21pc2UgdGV4dCBpbiB0aGUgZG9jIHRvZGF5PyBPbmUgaHVtIGZyb20gamFi YmVyIHJvb20uDQoNClRob3NlIGluIGZhdm9yIG9mIGFkZGluZyB0aGUgdGV4dCBpbnRvIHRoZSBk b2M/DQoNClRob3NlIG5vdCBpbiBmYXZvciBvZiBhZGRpbmcgdGhlIHRleHQgaW50byB0aGUgZG9j Pw0KDQpSb3VnaCBjb25zZW5zdXMgdG8gcHV0IHRoZSB0ZXh0IGluIHRoZSBkb2N1bWVudC4NCiAg ICAgICAgDQoNCkFsbCBvdGhlciBCdXNpbmVzcyAobWF0dGVycyByZXR1cm5pbmcgZnJvbSBzZXNz aW9uIDEsIElFU0cgcmVzb2x1dGlvbiwgZXRjLikNCg0KDQpSYXcgTm90ZXMgZnJvbSBLZWl0aCBE cmFnZSBmb3IgZGF5IDINCg0KDQpSVEMgV0VCIFNFU1NJT04gMiBOT1RFUw0KPT09PT09PT09PT09 PT09PT09PT09PT09PT0NCg0KDQpBZ2VuZGEgQmFzaGluZyArIFN0YXR1cyB1cGRhdGUgYWxsIGRy YWZ0cyAoNSBtaW4pIENoYWlycw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0KDQoNCkZFQyAgDQotLS0tLS0tLS0tLQ0KDQoN CmRyYWZ0LXViZXJ0aS1ydGN3ZWItZmVjDQpkcmFmdC1zaW5naC1wYXlsb2FkLXJ0cC0xZDJkLXBh cml0eS1zY2hlbWXigJ0pICAoMjAgbWluKQ0KDQoNClByZXNlbnRlcjogSnVzdGluIFVtYmVydGkN Cg0KDQpTbGlkZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3Ns aWRlcy05MS1ydGN3ZWItNi5wZGYNCg0KDQpNYWluIGlzc3VlIGlzIHdlIG5lZWQgdG8gZGVjaWRl IHdoYXQsIGlmIGFueSwgRkVDIGlzIE1USSBmb3IgIFJUQ1dlYg0KDQoNCkJlcm5hcmQgQWJvYmE6 IERyb3AgUkVEIG9uIGF1ZGlvDQoNCg0KTWFydGluIFRob21wc29uOiBJZiBoYXZlIGxlc3MsIHRo ZW4gZWFzaWVyIHRvIGFkZCBtb3JlIGxhdGVyIG9uLg0KDQoNCkRFQ0lTSU9OOiBXRyB3aWxsIHBy b2NlZWQgdG8gYWRvcHQgZHJhZnQtdWJlcnRpLXJ0Y3dlYi1mZWMgYXMgV0cgaXRlbSwgc3ViamVj dCB0byBjb25maXJtYXRpb24gb24gdGhlIGxpc3QuDQoNCg0KTVRJIFZpZGVvIENvZGVjDQotLS0t LS0tLS0tLS0tLS0NCg0KDQpkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlby0wMg0KDQoNClByZXNlbnRl cjogQWRhbSBSb2FjaCAgICAgICAgICAgICAgDQoNCg0KU2xpZGUgNQ0KDQoNCk1hcnRpbiBUaG9t cHNvbjogTm90IGEgcnRjd2ViIHNwZWNpZmljIGlzc3VlLg0KDQoNClNsaWRlIDY6DQoNCg0KSnVz dGluIFVtYmVydGk6IFdvdWxkIHByZWZlciB0byBiZSBzdHJvbmdlciwgYXMgaW4gTVVTVC4gU0hP VUxEIG9uIHJlY2VpdmluZy4NCg0KDQpKb25hdGhhbiBMZW5ub3g6IFJlYXNvbnMgZm9yIG5vdCBk b2luZywgbGlrZSBiZWluZyByaWdodCBzaWRlIHVwLiBTSE9VTEQgb24gcmVjZWl2aW5nIHNvdW5k cyB3ZWlyZC4NCg0KDQpKdXN0aW4gVW1iZXJ0aTogQWxsIG1vZGVybiBzdHVmZiBTSE9VTEQgdHJ5 IGFuZCBuZWdvdGlhdGUgaXQuDQoNCg0KSGFyYWxkOiBJZiBpbnRlbmRpbmcgdG8gdXNlIGEgaGVh ZGVyIGV4dGVuc2lvbiB0aGVuIGFkZCBhbiByZWZlcmVuY2UgdG8gZG9jdW1lbnQuDQoNCg0KTW8g WmFuYXR5OiBBbiBJQU5BIHJlZ2lzdGVyZWQgaGVhZGVyIHdpdGggcmVmZXJlbmNlIHRvIDNHUFAg ZG9jdW1lbnQuIENvZGVjIHNwZWNpZmljIG1lY2hhbmlzbSB3YXkgb2YgZG9pbmcgdGhpcy4NCg0K DQpIYXJhbGQ6IFdpbGwgc2VuZCBzb21lIHN1Z2dlc3Rpb25zIG9uIGRvaW5nIHRoaXMuDQoNCg0K UmFuZGFsbCBKZXN1cCBmcm9tIEphYmJlcjogTXVzdCBzZW5kIGlmIG5vdCBub24tcm90YXRlZCwg b3JpZW50YXRpb24gc2hvdWxkIHBlcnNpc3Qgd2l0aG91dCB0aGUgZXh0ZW5zaW9uLiAgUmV0cmFu c21pdCBvcmllbnRhdGlvbiBwZXJpb2RpY2FsbHkgdG8gZGVhbCB3aXRoIHBhY2tldCBsb3NzLg0K DQoNClN0ZWZhbiBXZW5nZXI6IElzIGhlYWRlciBleHRlbnNpb24gUkZDIGdlbmVyYWxseSByZXF1 aXJlZD8gQW5zd2VyIGlzIFllcy4NCg0KDQpQcmVzZW50ZXI6IEN1cnJlbnRseSBpbiBzdGF0ZSB3 aGVyZSBNVVNUIHVzZSBoZWFkZXIgZXh0ZW5zaW9ucy4NCg0KDQpKdXN0aW46IFNhbWUgYXMgcHJl dmlvdXMgY29tbWVudHMgdG8gYXBwbHkgdG8gbWl4ZXIgaGVhZGVyIGV4dGVuc2lvbi4NCg0KDQpT bGlkZSA4Og0KDQoNCkJlcm5hcmQgQWJvYmE6IFRoaW5rIHNob3VsZCB0YWtlIHRvIGxpc3QgYnV0 IHRoaW5rIHRoZSBhbnN3ZXIgaXMgeWVzLg0KDQoNClNsaWRlIDE0Ow0KDQoNClByZXNlbnRlciBz dGF0ZW1lbnQ6IFRoaXMgaXMgYSBzdGF0ZW1lbnQgb2YgaW50ZW50LiBJZiBxdWVzdGlvbiBpcyBp cnJlbGV2YW50IGF0IHRoZSB0aW1lLCB0aGVuIHdpbGwgbm90IGRvIHRoaXMuDQoNCg0KUHJlc2Vu dGVyIHN0YXRlbWVudDogQ2FuIGFsc28gcmVjb25zaWRlciBhdCBhbnkgb3RoZXIgdGltZS4NCg0K DQpBbmRyZXcgQWxsZW46IElzIGl0IGJvdGggZW5jb2RlciBhbmQgZGVjb2Rlcj8NCg0KDQpTdGVm YW4gV2VuZ2VyOiBJbiBnZW5lcmFsIHN0YW5kYXJkcyBkbyBub3QgZGVmaW5lIHRoZSBlbmNvZGVy IGFuZCB0aGVyZWZvcmUgSVBSIHN0YXRlbWVudHMgYXJlIG5vdCBtYWRlIG9uIHRoZSBlbmNvZGVy Lg0KDQoNCkplcmVteSBGdWxsZXI6IElzIHRoZXJlIGFueXRoaW5nIGhlcmUgdGhhdCBkZWNsYXJl cyBhIG1pbmltdW0gdGltZS4NCg0KDQpQcmVzZW50ZXIgQ2hhbmdlIGF0IFNsaWRlIDE1IHRvIEpv bmF0aGFuIFJvc2VuYmVyZy4NCg0KDQpQcmVzZW50ZXIgY2hhbmdlIGF0IFNsaWRlIDIwIHRvIEhh cmFsZCBBbHZlc3RyYW5kLg0KDQoNClNsaWRlOiAyNQ0KDQoNCkFuZHJldyBBbGxlbjogV2hhdCBp cyBiZWluZyBkb25lIGFib3V0IHRoZSB0eXBlIDMgZGVjbGFyYXRpb24gYW5kIHdpbGwgR29vZ2xl IGltcGxlbWVudCB0aGlzLg0KDQoNCkhhcmFsZDogQW0gd29ya2luZyBmcm9tIEFzc3VtcHRpb24g dGhhdCBWUDggaXMgcm95YWx0eSBmcmVlLiBXaGF0IHlvdSB0aGluayBpcyB1cCB0byB5b3UuDQoN Cg0KU2xpZGUgMjYNCg0KDQpTZWFuIFR1cm5lciBhc2tpbmcgcXVlc3Rpb25zIGZyb20gY2hhaXIu DQoNCg0KRG8geW91IHdhbnQgdG8gcGFydGljaXBhdGUgaW4gdGhpcy4NCg0KDQpNb3N0IHJvb20g aW5kaWNhdGVzIGFzc2VudC4NCg0KDQpBZGFtIFJvYWNoOiBEb2VzIHF1ZXN0aW9ucyBjYXB0dXJl LiBUaGlzIGlzIHByb2JhYmx5IG5vdCBsaXRlcmFsIHRleHQgZm9yIHRoZSBkb2N1bWVudC4NCg0K DQpBbmRyZXcgQWxsZW46IFZhcmlvdXMgaW5wdXQgbWF0ZXJpYWwgdGhhdCBkb2VzIG5vdCBzZWVt IHRvIGhhdmUgYmVlbiBkaXNjdXNzZWQuIEFsc28gcHJvY2VzcyBpc3N1ZSBpbiB0aGF0IG5ldyBw cm9wb3NhbCBpcyBvbiB0YWJsZSBhdCBzaG9ydCBub3RpY2UuDQoNCg0KQ2hhaXI6IElmIG5ldyB0 ZWNobmljYWwgaW5wdXQgdGhlbiBwbGVhc2UgY29tZSB0byBtaWMgYW5kIGRpc2N1c3MgdGhlbS4N Cg0KDQpCZXJuYXJkIEFib2JhOiBEcmF3cyBhdHRlbnRpb24gdG8gbGl0aWdhdGlvbiBkb2N1bWVu dCBhbmQgY2hhbmdlcyB0byBNVEkgZG9jdW1lbnQuIFBhcnRpY3VsYXIgaW50ZXJlc3QgaXMgdGhl IHR5cGUgMyBkZWNsYXJhdGlvbnMgaW4gSVNPLiBUaGVzZSBhcmUgdGhpbmdzIHRoYXQgcmVxdWly ZSB0aW1lLiBTaXR1YXRpb24gbWF5IGJlIGNsZWFyZXIgYXMgdGltZSBnb2VzIG9uIGJ1dCBiYXNl ZCBvbiB0aGluZ3MgdGhhdCBjYW5ub3QgYmUgY2xhcmlmaWVkIGhlcmUuIEguMjY0IGhhcyBhbHNv IHByb2xpZmVyYXRlZCBzaW5jZSBsYXN0IGRpc2N1c3Npb24uIEJvdGggaGFyZHdhcmUgYW5kIHNv ZnR3YXJlIGltcGxlbWVudGF0aW9ucy4gU2l0dWF0aW9ucyB3aGVyZSBILjI2NCBjb3ZlcmFnZSBk b2VzIG5vdCBleGlzdCBoYXMgc2hydW5rIGRyYW1hdGljYWxseSBzaW5jZSBsYXN0IGRpc2N1c3Np b24uIE1USSBpc3N1ZSBpZiBsZWZ0IGFsb25lIHdpbGwgYmUgc29sdmVkIGJ5IHRoZSBpbmR1c3Ry eSBhbmQgdGhlIElFVEYgZG9lcyBub3QgbmVlZCB0byBtYWtlIGEgZGVjaXNpb24uIFNvbWUgcHJv ZHVjdHMgY2Fubm90IGFmZm9yZCB0byBoYXZlIG11bHRpcGxlIGNvZGVjcyBiZWNhdXNlIG9mIHNw YWNlIGFuZCBlbmVyZ3kgY29uc3VtcHRpb24gaXNzdWVzIGFuZCB0aGVyZWZvcmUgd2lsbCBpZ25v cmUgSUVURiBkZWNpc2lvbi4gQXQgbW9tZW50IEguMjY0IGlzIHByZXR0eSBmYXIgYWhlYWQgYXQg dGhlIG1vbWVudCBvbiBlbmVyZ3kgY29uc3VtcHRpb24gaXNzdWVzLg0KDQoNCkNoYWlyIHN0YXRl bWVudDogQW55IGRlY2lzaW9uIHdpbGwgYmUgdGFrZW4gdG8gbGlzdCBhbmQgdGhlcmVmb3JlIGFu eW9uZSBub3QgaW4gdGhlIHJvb20gd2lsbCBnZXQgY2hhbmNlIHRvIGlucHV0IHRvIGRpc2N1c3Np b24uDQoNCg0KQW5kcmV3IEFsbGVuOiArMSB0byB3aGF0IEJlcm5hcmQgaXMgc2F5aW5nLiBNb2Jp bGUgaW5kdXN0cnkgd2lsbCBtYWtlIHRoZSBkZWNpc2lvbiBmb3IgdXMuIFRoaW5rcyB0aGF0IHdl IG9ubHkgaGF2ZSB0aGlzIGRpc2N1c3Npb24gYmVjYXVzZSBvbmUgYnJvd3NlciB2ZW5kb3IgaXMg aW5zaXN0aW5nIG9uIGhhdmluZyB0aGVpciBjb2RlYy4gSGlzIGNvbXBhbnkgaW1wbGVtZW50cyB0 aGVpciBvd24gYnJvd3NlciBiZWNhdXNlIFZQOCBzdGlsbCBoYXMgdG9vIG1hbnkgcmlza3Mgb2Yg bGl0aWdhdGlvbi4gSWYgbWFrZSBubyBkZWNpc2lvbiBILjI2NCBiZWNvbWVzIHRoZSBkZWZhdWx0 IE1USSBjb2RlYy4NCg0KDQpBZGFtIFJvYWNoOiBIYWxsbWFyayBvZiBhIGdvb2QgY29tcHJvbWlz ZSBpcyB0aGF0IG5vIG9uZSBpcyBoYXBweS4gQXMgcmVnYXJkcyBuZXcgaW5mb3JtYXRpb24gYWJv dXQgZXhpc3RpbmcgY29kZWNzLCBkbyBub3QgdGhpbmsgaXQgaXMgcmVsZXZhbnQgcmlnaHQgbm93 LiBEb2VzIG5vdCByZWFsbHkgY2hhbmdlIHRoaW5ncy4NCg0KDQpNYXJ5IEJhcm5lcyBmb3IgUmFu ZGFsbCBKZXN1cCB2aWEgSmFiYmVyOiBNb2JpbGUgZGV2aWNlcyBILjI2NCBpbXBsZW1lbnRhdGlv bnMgZnJlcXVlbnRseSAodXN1YWxseSBldmVuKSB3aWxsIG5vdCB3b3JrIGZvciBpbnRlcmFjdGl2 ZSB2aWRlbyBjb21tdW5pY2F0aW9uLiAgTWF5YmUgdGhleSdsbCBnZXQgdGhlcmUgcmVsaWFibHks IGJ1dCBldmVuIGRlY29kZSBoYXMgYmVlbiBhIGh1Z2UgcHJvYmxlbSBvbiBBbmRyb2lkIGFuZCBX aW5kb3dzIGZvciBNb3ppbGxhLiBhbmQgd2UgaGF2ZSBhIGh1Z2UgbnVtYmVyIG9mIGRlc2t0b3Ag cGxhdGZvcm1zIHRoYXQgd29uJ3Qgc3VwcG9ydCBpdCBpbiB0aGUgT1MgZm9yIHF1aXRlIHNvbWUg dGltZS4gIFNvbWV0aGluZyBsaWtlIDIwJSBvZiBNYWMgRmlyZWZveCB1c2VycyBhcmUgb24gMTAu Ni4uLi4gIGFuZCBsb3RzIHN0aWxsIGluIFhQICh5ZXMsIHJlYWxseSkNCg0KDQpUZWQgSGFyZGll IGZyb20gbWljOiBBbHNvIExTIGZyb20gVzNDIG9uIHdhbnRpbmcgcm95YWx0eSBmcmVlLiBBbHNv IFZQOCBpcyBkZXZlbG9waW5nIGF0IHNhbWUgdGltZSBhcyBILjI2NC4gQmVsaWV2ZXMgdGhpcyBj b21wcm9taXNlIGVudGlyZWx5IGluIHRoaXMgc3Bpcml0Lg0KDQoNCj8/PyAoTWljcm9zb2Z0KTog Q29kZWMgYXJndW1lbnQgaXMgdGVjaG5pY2FsIGRlY2lzaW9uIGJ5IGVhY2ggZGV2aWNlIGFuZCBi cm93c2VyIHZlbmRvci4NCg0KDQpKdXN0aW4gVWJlcnRpOiBEaXNhZ3JlZXMgd2l0aCBCZXJuYXJk 4oCZcyBjb21tZW50IHRoYXQgbW9iaWxlIGlzIHRoZSBmdXR1cmUuIFNhbXN1bmcsIFF1YWxjb21t IC4uLiBhcmUgc2hpcGluZyBWUDggZW5jb2RlIGFuZCBkZWNvZGUgaW4gdGhlaXIgaGFyZHdhcmUu DQoNCg0KTW8gWmFuYXR5OiBIYXJkd2FyZSBzdXBwb3J0IGlzIGNvbWluZy4gQmVlbiBkaWZmaWN1 bHQgZm9yIHJlYWwgdGltZSBzdXBwb3J0IGluIHBhc3QsIGJ1dCB0aGF0IGlzIG5vdyBkaXNhcHBl YXJpbmcuIE5vIG9uZSBoYXMgeWV0IG1lbnRpb25lZCB0aGUgZW5kIHVzZXJzLiBQcm9wb3NhbCBn dWFyYW50ZWVzIGludGVyb3BlcmFiaWxpdHkgZm9yIHRoZSBlbmQgdXNlcnMgc28gaXQgaXMgYSB3 aW4gZm9yIHRoZW0uDQoNCg0KQmVybmFyZCBBYm9iYTogQVBJcyBpbiBXaW5kb3dzIGFuZCBpT1Mg Ym90aCBnaXZlIGhhcmR3YXJlIHN1cHBvcnQgYW5kIHRoaXMgaXMgaW1wb3J0YW50IGZvciB0aGUg bW9iaWxlIGNvbW11bml0eS4gRXZlcnkgbmV3IG1vYmlsZSBhcHBsaWNhdGlvbiBpcyB1c2luZyB0 aGUgUlRDV0VCIHN0YWNrIGFuZCBjb21waWxpbmcgaXQgaW50byB0aGVpciBhcHBsaWNhdGlvbi4g R2VuZXJhbGx5IHVzaW5nIGFub3RoZXIgdmVyc2lvbiBvZiB0aGVpciBvd24gYXBwIGZvciBhbm90 aGVyIHVzYWdlLiBXZWJhcHBzIGFyZSB0aGUgcGxhY2Ugd2hlcmUgdGhpcyBkb2VzIG1hdHRlciBi dXQgW3RoZXNlIGFyZSBub3QgdGhlIG1ham9yIGlzc3VlXS4gQ292ZXJhZ2Ugb2YgSC4yNjQgaXMg bW9zdCB1bml2ZXJzYWwgbm93Lg0KDQoNCkFuZHJldyBBbGxlbjogUHJlc2VuY2Ugb2YgVlA4IG9u IG1hbnkgY2hpcHNldHMgaXMgZXZpZGVuY2UgdGhhdCB3ZSBkbyBub3QgbmVlZCB0byBtYWtlIGEg ZGVjaXNpb24gbm93Lg0KDQoNCkNoYWlyOiBEbyB5b3UgYWdyZWUgd2l0aCBXRyBwcmV2aW91cyBj b25zZW5zdXMgdG8gaGF2ZSBhbiBNVEkgY29kZWMuDQoNCg0KQW5kcmV3IEFsbGVuOiBQcmV2aW91 cyBkZWNpc2lvbiB3YXMgdG8gaGF2ZSBhIHNpbmdsZSBNVEkgY29kZWMuIFRoYXQgaXMgbm90IHdo YXQgaXMgb24gdGhlIHRhYmxlIHRvZGF5Lg0KDQoNCkVyaWMgUmVzY29ybGE6IExvbmcgc3RhbmRp bmcgY29uc2Vuc3VzIHRvIGhhdmUgYW4gTVRJIGNvZGVjLiBIYXZpbmcgdHdvIGluc3RlYWQgb2Yg b25lIGlzIHdlbGwgd2l0aGluIHRoZSByZW1pdCBvZiB0aGUgV0cgYW5kIGNvbnNpc3RlbnQgd2l0 aCB0aGF0LiBTdXJwcmlzZWQgdGhhdCB0aGVyZSBpcyBhIHNwYWNlIGlzc3VlIGZvciBwYWNraW5n IHR3byBjb2RlY3MgaW50byB0aGUgc2FtZSBwbGF0Zm9ybS4gQ29tcGFyZWQgdG8gYnJvd3NlciBz aXplIGlzIG5vdCBhIG1hdGVyaWFsIGlzc3VlLg0KDQoNCkdyZWcgTWFuc2VsbDogT3BlbiBzb3Vy Y2Ugd2FzIGFuIGluaXRpYWwgYWltLiBXb3JsZCBvZiBvcGVuIHNvdXJjZSBpcyBmYXIgd2lkZXIg dGhhbiB1c2VyIGFnZW50cyBhbmQgZGV2aWNlcy4gQ29tcGF0aWJpbGl0eSBpcyBhbHNvIGltcG9y dGFudC4gUHJvcG9zYWwgaXMgZ29vZCBmb3IgdmFzdCBtYWpvcml0eSBvZiBvcGVuIHNvdXJjZSBh cyB3ZWxsLg0KDQoNCkhhcmFsZCBBbHZlc3RyYW5kOiBUaGUgR1NNQSByZXBvcnQgd2FzIG1lbnRp b25lZC4gTWV0IGd1eSB3aG8gd3JvdGUgcmVwb3J0IGF0IFczQyBtZWV0aW5nLCBhbmQgYXNrZWQg cXVlc3Rpb25zIGFib3V0IHNvbWUgb2YgdGhlIHZhbHVlcyBpbmNsdWRlZC4gQ291bGQgbm90IGdl dCBhbiBhbnN3ZXIgdG8gdGhlIHF1ZXN0aW9ucy4NCg0KDQpKdXN0aW4gVWJlcnRpOiByZXNwb25k aW5nIHRvIEJlcm5hcmQuIFNhbXN1bmcgQ2hyb21lYm9vayBubyAxIHNlbGxpbmcgbGFwdG9wIHVz aW5nIFNhbXN1bmcgU1NDLiA/Pz8gdXNpbmcgUXVhbGNvbW0uIGV0Yy4gVlA4IHByZXZhbGVudCBh Y3Jvc3MgbW9iaWxlIGVjb3N5c3RlbS4NCg0KDQpBZGFtIFJvYWNoOiBSZXNwb25kaW5nIHRvIEJl cm5hcmQuIE1hbnkgdHJhZGUgc2hvd3MgcGVvcGxlIGdldCB1cCBhbmQgZGVzY3JpYmUgbGFjayBv ZiBNVEkgY29kZWMgYXMgYW4gaW1wb3J0YW50IGlzc3VlIHRoYXQgbmVlZHMgdG8gYmUgcmVzb2x2 ZWQuDQoNCg0KSm9uYXRoYW4gUm9zZW5iZXJnOiBXaWxsIHVubG9jayB0aGUgYWJpbGl0eSBmb3Ig YWxsIHRob3NlIGRpZmZlcmVudCBhcHBzIHRvIG5vdyBoYXZlIGEgd2ViYXBwIGFuZCBicmluZyBy ZWFsIHRpbWUgY29tbXVuaWNhdGlvbnMgdG8gdGhlIHdlYi4gTGFyZ2VzdCBidXJkZW4gaXMgb24g dGhlIGJyb3dzZXJzLg0KDQoNCkNodWNrID8/PzogV2FudCB0byBzZWUgcG9pbnQgMiBjaGFuZ2Vk IHRvIGJlIGlmIHJveWFsdGllcyBnbyB1cCBvciBkb3duLg0KDQoNCkN1bGxlbiBKZW5uaW5nczog V2FudHMgdG8gYWRkcmVzcyBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoZXJlIGhhcyBiZWVuIGVub3Vn aCB0aW1lIG9yIG5vdC4gU2l4IG1vbnRocyBhZ28gbWFkZSB2ZXJ5IGNsZWFyIGRpc2N1c3Npb24g d291bGQgYmUgcmV2aXNpdGVkIGhlcmUuDQoNCg0KTWFyeSBCYXJuZXMgY2hhbm5lbGxpbmcgUmFu ZGFsbCBKZXN1cDogVG8gbW8ncyBjb21tZW50LCBhbmQgQmVybmFyZDogSSBhZ3JlZSBIVyBzdXBw b3J0ICpjYW4qIGFuZCBkb2VzIHdvcmsuICBBbmQgSSBob3BlIHdlIGdldCB0byB3aGVyZSBhbGwg c2hpcHBpbmcgKGFuZCBtb3N0IGRlcGxveWVkKSBkZXZpY2VzIGhhdmUgcmVsaWFibGUgcmVhbHRp bWUgSFcgY29kZWMgc3VwcG9ydC4gIFRoYXQgaXNuJ3QgdG9kYXkuICBUaGF0IGlzbid0IG5leHQg eWVhci4gIG1heWJlIGluIHRoZSB5ZWFycyBhZnRlciB0aGF0LiAgQWxsIG9mIHRoYXQgc2FpZC4u LiBXaGlsZSBJIHBlcnNvbmFsbHkgcHJlZmVyIFZQOCBhcyBhIHNvbGUgY2hvaWNlLCBJIGNhbiBz dG9tYWNoIHRoZSBub3ZlbCBjb21wcm9taXNlLiAgVG8gQW5kcmV3J3MgY29tbWVudDogSSB0aGlu ayBkZWNvZGUgYm90aCwgZW5jb2RlIG9uZSBpcyBhcyBnb29kIGFzIGVuY29kZS9kZWNvZGUgYm90 aCwgSUYgYW5kIG9ubHkgaWYgeW91IGRlbWFuZCBhbGwgZGV2aWNlcyBkZWNvZGUgYm90aCwgd2hp Y2ggbWF5IHJlcXVpcmUgbW9yZSBmcm9tIGRldmljZXMgdGhhbiB0aGlzIHByb3Bvc2FsIGRvZXMu ICAgSSBkbyB3YW50IHRvIG1vdmUgZm9yd2FyZCBhbmQgZW5kIHRoaXMuICBXZSBkaWQgZGlzY3Vz cyB0aGF0IGlkZWEgYmVmb3JlLCBJIGV2ZW4gd2FzIHBvc2l0aXZlIGFib3V0IGl0LCBidXQgaXQg ZGlkbid0IGdldCBtdWNoIHN1cHBvcnQuDQoNCg0KTW9udHkgTW9udGdvbWVyeTogSGFzIGNsYXJp ZnlpbmcgcXVlc3Rpb24uIEFmdGVyIHRocmVlIHllYXJzIG5vdyBoYXZlIHByb3Bvc2FsIGZvciBj b21wcm9taXNlIGFuZCB0aGF0IGFub3RoZXIgbGFzdCBtaW51dGUgcHJvcG9zYWwgaXMgbm90IGJl aW5nIGRpc2N1c3NlZCB0b2RheS4gSXMgaXQgaW1wb3NzaWJsZSB0byBjb25zaWRlciBvdGhlciBw cm9wb3NhbHMgaW4gdGhlIGZ1dHVyZSBpZiBJRVRGIGNoYW5nZXMgaXRzIG1pbmRzLg0KDQoNCkty YXNpbWlyIEtvbGFyb3YgKEFwcGxlKTogQmVlbiBmb2xsb3dpbmcgZGlzY3Vzc2lvbi4gQXQgdGhp cyBwb2ludCB0ZWNobm9sb2d5IHRoYXQgaGFzIHR5cGUgMyBkZWNsYXJhdGlvbiAgd2lsbCBub3Qg YmUgc2hpcHBlZCBieSBBcHBsZS4NCg0KDQpCZXJuYXJkIEFib2JhOiBDbGFyaWZpZWQgdGhhdCB0 eXBlIDMgZGVjbGFyYXRpb24gaXMgYnkgTm9raWEgd2hpY2ggaXMgbm90IHRoZSBjb21wYW55IHRo YXQgTWljcm9zb2Z0IGFjcXVpcmVkLiBUaGlua3MgIk11c3QgaW1wbGVtZW50IGJvdGgiIGlzIHRv byBtdWNoIG9mIGEgYnVyZGVuLg0KDQoNClhhdmllciBNYXJqb3UgKE9yYW5nZSk6IEhhcHB5IHRo YXQgc29tZSBwZW9wbGUgd2lsbCBpbXBsZW1lbnQgYm90aCBjb2RlY3MuIE5vdCBoYXBweSB0aGF0 IG51bWJlciAzIGhhcyBkaXNhcHBlYXJlZCBmcm9tIHRoZSBsaXN0Lg0KDQoNCkFkYW0gUm9hY2g6 IE51bWJlciAzIGlzIHN0aWxsIGluIHRoZSBsaXN0LCBqdXN0IGNvbWJpbmVkIGluLg0KDQoNCk1v IFphbmF0eTogU3VycHJpc2VkIHRoYXQgTWljcm9zb2Z0IGRvZXMgbm90IGhhdmUgbGljZW5zZS4g VGhlcmUgd2lsbCBhbHdheXMgYmUgdmVuZG9ycyB3aG8gZG9lcyBub3QgY29tcGx5LiBJcyB0aGlz IGVub3VnaCBzdXBwb3J0IHRvIGVuc3VyZSB0aGlzIGlzIHVzZWZ1bC4gVGhlcmUgYXJlIHN0cm9u ZyByZWFzb25zIHRvIGhhdmUgMikgYXMgd2VsbCBhcyAxKS4NCg0KDQpBbmRyZXcgQWxsZW46IE5v dCBqdXN0IGEgZmV3IHNtYWxsIGNvbXBhbmllcywgTWljcm9zb2Z0IGFuZCBBcHBsZSBhcmUgYSBt YWpvciBwYXJ0IG9mIHRoZSBkZXNrdG9wIG1hcmtldCwgQ29tcGFuaWVzIGJlaW5nIGZvcmNlZCB0 byBpbXBsZW1lbnQgVlA4IGJlY2F1c2Ugb25lIGNvbXBhbnkgaXMgcmVmdXNpbmcgdG8gYWdyZWUg SC4yNjQgYXMgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBjb2RlYy4NCg0KDQpIYXJhbGQgQWx2ZXN0 cmFuZDogT25lIHBvaW50IGFib3V0IHR5cGUgMyBkZWNsYXJhdGlvbiBmcm9tIE5va2lhLiBTZXZl cmFsIG1vbnRocyBhZnRlciBOb2tpYSBjbGFpbWVkIHRvIGhhdmUgc3VibWl0dGVkIHN0aWxsIGhh cyBub3Qgc2hvd24gdXAgYXQgSVNPIE1QRUcuIERvZXMgbm90IG5hbWUgdGhlIHBhdGVudHMuDQoN Cg0KU3RlcGhhbiBXZW5nZXI6IElTTyBjdXJyZW50bHkgdW5kZXJnb2luZyB0ZWNobmljYWwgcmV2 YW1wIG9mIHRoZWlyIGRhdGFiYXNlIGFuZCB0aGF0IHByb2plY3QgaGl0IGNlcnRhaW4gcm9hZGJs b2Nrcy4gSVNPIHBvbGljeSBpcyB0aGF0IHBhdGVudCBudW1iZXJzIGFyZSBub3QgcmVxdWlyZWQu DQoNCg0KSGFyYWxkOiBOb2tpYSBmaWxlZCB0d28gb24gc2FtZSBkYXkuIE9uZSBtYWRlIGl0LCB0 aGUgb3RoZXIgZGlkIG5vdC4gTm9raWEgYmVoYXZpb3VyIGlzIGhpZ2hseSB1bnVzdWFsIGFuZCBw ZXJzb25hbGx5IG9iamVjdGlvbmFibGUgdG8gbWUuIE11c3QgY2xlYXJseSBzdGF0ZSB3aGF0IHdl IGhhdmUgc2VlbiBhbmQgbm90IHdoYXQgd2UgdGhpbmsgd2UgaGF2ZSBzZWVuLg0KDQoNCk1hcnkg QmFybmVzIGNoYW5uZWxsaW5nIFBldGVyIFN0LiBBbmRyZTogSSBjYW4ndCBhZ3JlZSB3aXRoIEpE UiB0aGF0IHdlYiBhcHBzIHdpbGwgcHJvbGlmZXJhdGUgb25jZSB3ZSBzb2x2ZSB0aGlzIGlzc3Vl IC0gdGhlIG1haW4gYmxvY2tlciBpcyB0aGF0IHdlIGRvbid0IGhhdmUgV2ViUlRDIHN1cHBvcnQg aW4gSUUgb3IgU2FmYXJpLCBhbmQgRmlyZWZveCBpcyBmYXIgZW5vdWdoIGJlaGluZCBpbiB0aGVp ciBpbXBsZW1lbnRhdGlvbiAobm8ga25vY2sgb24gdGhlIE1vemlsbGEgdGVhbSkgdGhhdCBpdCBp cyBkaWZmaWN1bHQgdG8gbWFrZSBpbnRlcm9wZXJhYmxlIGFwcGxpY2F0aW9ucyByaWdodCBub3cN Cg0KDQpNYXJ5IEJhcm5lcyBjaGFubmVsbGluZyBSYW5kYWxsIEplc3VwOiBBbmRyZXcncyBjb2xs ZWFndWUncyBwcm9wb3NhbCB3YXMgaW4gdGhlIGxpc3Qgb2Ygb3B0aW9ucyB3ZSBhbGwgc3VydmV5 ZWQgbWFueSBtb250aHMgYWdvLiAgSXQgZGlkIHBvb3JseS4NCg0KDQpEYW4gWW9yazogQmVlbiBn b2luZyBvbiBsb25nIHRpbWUgd2l0aCBkaXNjdXNzaW9uLiBBZ3JlZSB3aXRoIFBldGVyJ3MgcG9p bnQgdGhhdCBwZW9wbGUgYXJlIGdvaW5nIG91dCB0aGVyZSBhbmQgaW1wbGVtZW50aW5nLiBOZWVk IHRvIGhhdmUgdGhpcyBkZWNpZGVkLg0KDQoNCkp1c3RpbiBVYmVydGk6IFVuc3ltcGF0aGV0aWMg dG8gZGVzaXJlIHRvIGhhdmUgbW9yZSBkaXNjdXNzaW9uLg0KDQoNCktyYXNpbWlyIEtvbGFyb3Yg KEFwcGxlKTogSVNPIGRhdGFiYXNlIHZlcnkgc2xvdyB0byByZXNwb25kLg0KDQoNCkVyaWMgUmVz Y29ybGE6IFRvIGJlIGNsZWFyIHRoZXJlIGFyZSBubyBwcm90b2NvbCBwb2xpY3kgYW5kIGlmIGRv bid0IGRvIHRoaXMgdGhlbiBqdXN0IGJlY29tZSBvbmUgb2YgdGhlIG90aGVyIHRlcm1zLiBIYXZp bmcgYSB0ZXJyaWJsZSB0aW1lIHVuZGVyc3RhbmRpbmcgb3V0c2lkZSBicm93c2VyIG1hbnVmYWN0 dXJlcnMgYXMgd2hvIGlzIGJlaW5nIGluY29udmVuaWVuY2VkLg0KDQoNCkFuZHJldyBBbGxlbjog UmVmZXJyZWQgdG8gM0dQUCBJTVMgV2VicnRjIHdvcmssIGFuZCBoYXZlIHRvIG1ha2Ugc3RhdGVt ZW50cyBvZiBjb21wbGlhbmNlIHRvIHRoZXNlLiBNb2JpbGUgdmVuZG9ycyBjb3VsZCBiZSBmb3Jj ZWQgdG8gbWFrZSBhIHN0YXRlbWVudCBvZiBjb21wbGlhbmNlIGFuZCBpZiBjYW5ub3Qgc2hpcCBw cm9kdWN0IHRvIHNhbGVzIGNoYW5uZWwuIE1hdHRlcnMgdG8gc29tZSBjb21wYW5pZXMuDQoNCg0K TW9udHkgTW9udGdvbWVyeTogSGVscHMgdGhlIHZhc3QgbWFqb3JpdHkgb2Ygb3BlbiBzb3VyY2Ug ZXZlbiBpZiBpdCBsZWF2ZXMgdGhpbmdzIGRpZmZpY3VsdCBmb3Igc29tZSB3ZWIgYnJvd3NlcnMu DQoNCg0KSmVyZW15IEZ1bGxlcjogSWYgd29yZHMgb2YgMikgZG8gbm90IHRyaWdnZXIgaW4gbmV4 dCAyNCBtb250aHMgdGhlbiB3aWxsIGJlY29tZSBpcnJlbGV2YW50LiBJcyBhbnl0aGluZyBsaWtl bHkgdG8gaGFwcGVuIGluIHRoaXMgcmVzcGVjdC4NCg0KDQpDdWxsZW4gSmVubmluZ3M6IFRoaW5r cyB0aGVyZSBhcmUgdGhpbmdzIHRoYXQgcmVkdWNlIHVuY2VydGFpbnR5LiBHb29nbGUgY29uc2lk ZXJpbmcgaW52YWxpZGF0aW5nIElQUi4gVzNDIGFza2VkIE1QRUctTEEgYXNraW5nIHRvIG1ha2Ug SC4yNjQgcm95YWx0eSBmcmVlLg0KDQoNClRlZCBIYXJkaWU6IEltcG9ydGFudCBmb3IgdXMgdG8g bWFrZSBvdXIgYmVzdCBzaG90IGF0IG1ha2luZyB0aGlzIGFzIGJyb2FkIGFzIHBvc3NpYmxlLg0K DQoNCkJlcm5hcmQgQWJvYmE6IEtpbmQgb2YgbGlrZSB0aGUgc2xpZGUgYnV0IHRoaW5rcyB0aGF0 IElFVEYgcHJvcG9zYWwgaXMgYSBiaXQgb2YgYSBncmFuZCBnZXN0dXJlIHRoYXQgd2lsbCBub3Qg aGF2ZSBhbnkgaW1tZWRpYXRlIGVmZmVjdC4gV2lsbCBHb29nbGUgb2ZmZXIgaW5kZW1uaXR5IGZv ciBWUDggbGF3IHN1aXRzLg0KDQoNCkNoYWlyIChTZWFuIFR1cm5lcik6IFF1ZXN0aW9uOiBXaG8g ZG9lcyBub3Qgd2FudCB0byB0YWtlIGEgc2Vuc2Ugb2YgdGhlIHJvb20gb24gd2hldGhlciB0byBo YXZlIHRoZSBjb21wcm9taXNlIHRleHQgaW4gdGhlIGRvY3VtZW50IHRvZGF5Lg0KDQoNCk5vIGh1 bXMgaW4gcm9vbS4NCkluIEphYmJlciByb29tIG9uZSBodW1tZWQuDQoNCg0KQ2hhaXI6IExldHMg dGFrZSBhIHNlbnNlIG9mIHRoZSByb29tIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIGFkZCB0aGUgdGV4 dCB0byB0aGUgZG9jdW1lbnQuDQoNCg0KSHVtIG5vdyBpZiB5b3Ugd2FudCB0byBzaG92ZSB0aGUg dGV4dCBpbiB0aGUgZG9jdW1lbnQuDQoNCg0KTW9zdCBodW1zDQoNCg0KSHVtIG5vdyBpZiB5b3Ug ZG9uJ3Qgd2FudCB0byBzaG92ZSB0aGUgdGV4dCBpbiB0aGUgZG9jdW1lbnQuDQoNCg0KRmV3ZXIg aHVtcy4NCg0KDQpDaGFpciBkZWNsYXJlZCByb3VnaCBjb25zZW5zdXMgdG8gaGF2aW5nIHRleHQg aW4gdGhlIGRvY3VtZW50IC0gd2lsbCBiZSBjb25maXJtZWQgb24gdGhlIGxpc3QuDQoNCg0KQWxs IG90aGVyIEJ1c2luZXNzIChtYXR0ZXJzIHJldHVybmluZyBmcm9tIHNlc3Npb24gMSwgSUVTRyBy ZXNvbHV0aW9uLCBldGMuKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpDaGFpcnMgZGlkIG5v dCBkaXNjdXNzIGFueSBhZGRpdGlvbmFsIGJ1c2luZXNzIA0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCldlYlJUQyBUaHVyc2Rh eSBQTSBNaW51dGVzIGJ5IEJyaWFuIFJvc2VuDQoNCg0KRkVDIC0gSnVzdGluDQpCZXJuYXJkOiBE b2Mgb2theSwgUkVEIHJlY29tbWVuZGF0aW9uIHN1c3BlY3QNCkp1c3RpbjogZG9uJ3QgbWluZCBk cm9wcGluZw0KTWFydGluOiBMZXNzIGlzIGdvb2QNCg0KDQpDaGFpcnM6IEFueW9uZSBvYmplY3Qg dG8gYWRvcHRpbmcgdWJlcnRpLXJ0Y3dlYi1mZWM/DQo8Tm8gb2JqZWN0aW9ucz4NCkNoYWlyczog V2lsbCB0YWtlIHRvIGxpc3QgdG8gY29uZmlybQ0KDQoNCmRyYWZ0LWlldGYtcnRjd2ViLXZpZGVv IC0gQWRhbQ0KQWRhbTogPElzc3VlIDI+DQoyIGZvbGtzIHNhaWQgInNvbHZlIGVsc2V3aGVyZSIN Cg0KDQpPcmllbnRhdGlvbiBJbmRpY2F0aW9uDQpKdXN0aW46IFNIT1VMRCBpbnRlcnByZXQsIE1V U1Qgc2VuZA0KSm9uYXRoYW46IG5vdCBzZW5kaW5nIG1lYW5zIHJpZ2h0IHNpZGUgdXAsIHNvIE1V U1QgaW50ZXJwcmV0LCBNVVNUIGJlIHNlbnQgaWYgbm90IHJpZ2h0IHNpZGUgdXANCkp1c3Rpbjog U29tZW9uZSB3b27igJl0IGltcGxlbWVudC4gIA0KSGFyYWxkOiBBZGQgcmVmIHRvIGhlYWRlciBl eHRlbiBkb2MNCkFkYW06IElzIHRoZXJlIGFuIFJGQyB0byByZWZlcmVuY2U/DQpIYXJhbGQ6IElm IG5vdCBhbiBTQUkgbWVzc2FnZSwgbXVzdCANCj8/TW96OiBJQU5BIHJlZ2lzdHJ5IGZvciBpdA0K U3RlcGhlbjogSXMgaGVhZGVyIGV4dGVuc2lvbiBnZW5lcmFsbHkgcmVxdWlyZWQ/ICBJIHRoaW5r IHllcw0KSnVzdGluOiBtYWtlID8/IGEgTVVTVCBpcyBub3cgYSBTSE9VTEQNCkNoYWlyczogU2Vu ZCBtZXNzYWdlIHRvIGxpc3QNCg0KDQpILjI2NCBTRUkNCkRvIHdlIG5lZWQgbWFuZGF0b3J5IHN1 cHBvcnQNCkJlcm5hcmQ6IFRha2UgdG8gbGlzdCwgYnV0IEkgdGhpbmsgeWVzDQpBZGFtOiBOZWVk IGhlbHAgd2l0aCB0aGUgbGlzdA0KQmVybmFyZDogTWUgYW5kIHNvbWUgb3RoZXJzIHdpbGwgaGVs cA0KQWRhbTogYW5kIFN0ZXBoZW4NCg0KDQpNVEkgQ29kZWMgLSBBZGFtDQo8QWRhbSBwcmVzZW50 cyBoaXMgcHJvcG9zYWwgYW5kIGFza3MgZm9yIGNsYXJpZnlpbmcgcXVlc3Rpb25zPg0KS2VpdGg6 IEF0IHNvbWUgcG9pbnQsIHBhdGVudHMgZXhwaXJlLCB0aGVuIHdoYXQNCkFkYW06IEluIDIwMjYs IHNvbWVvbmUgZWxzZSdzIHByb2JsZW0NCkFuZHJldzogd2hhdCBpcyB0aGUgcHJvY2Vzcz8NCkFk YW06IHdvcmRpbmcgdG8gYmUgbmVnb3RpYXRlZA0KQW5kcmV3OiBOZWVkIHRvIGF2b2lkIGNvbWlu ZyBiYWNrDQo8Zm9yZ290IGhpcyBuYW1lLCBjaXNjbyBndXk+QWxzbyB3b3JyaWVkIGFib3V0IHdv cmRpbmcgb2YgbGljZW5zaW5nIHRlcm1zDQpTdGVwaGVuOiBEb2VzIGEgV0cgaGF2ZSB0aGUgYXV0 aG9yaXR5IHRvIGJpbmQgdGhlIElFVEYgdG8gYSBmdXR1cmUgZGVjaXNpb24NCkNoYWlyczogSGFz IGhhcHBlbmVkIGJlZm9yZSAoUlNBIHBhdGVudHMgZm9yIGV4YW1wbGUpLiAgUmVhbGx5IGEgcHJv bXB0IGZvciByZWNvbnNpZGVyYXRpb24gcmF0aGVyIHRoYW4gYW4gYWN0dWFsIGNvbW1pdG1lbnQg dG8gZG8gc29tZXRoaW5nDQpLZWl0aDogV2hlbiB3ZSBkaXNjdXNzZWQgYXVkaW8sIGhvdyB0byB1 c2UgY29kZWNzIGFuZCB3aGF0IHRoZSBNVEkgY29kZWMgd2FzIHdlcmUgaW4gc2VwYXJhdGUgZG9j cy4gTWF5IG5lZWQgc2FtZSBoZXJlLiAgQWxzbywgbm8gd2F5IG91dCBvZiB0aGlzIC0gaWYgZXZl cnlvbmUgaXMgaW1wbGVtZW50aW5nIEguMjY5LCBkb24ndCB3YW50IHRoZSBILjI2NCB2cyBWUDgg YXQgdGhhdCB0aW1lDQo/U2h1bj8obWljcm9zb2Z0KUhhcyB0aGlzIGJlZW4gY29tbXVuaWNhdGVk IHRvIElTTz8NCkNoYWlyczogTm8sIHRoaXMgaXMganVzdCBhIHRyaWdnZXIsIElTTyB3b3VsZCBu b3QgZGVjaWRlIGFueXRoaW5nDQo/U2h1bj86IElzIHRoZSBpbnRlbnRpb24gdG8gbWFrZSBhbiBN VEkgZGVjaXNpb24gYmVmb3JlIHN0YW5kYXJkaXphdGlvbg0KQ2hhaXJzOiBXZSdyZSB0YWxraW5n IGFib3V0IHNwZWNpZmljIFJGQ3MgYW5kIG90aGVyIGRvY3MsIG5vdCBpbmNsdWRpbmcgSVNPIHN0 YW5kYXJkaXphdGlvbg0KQW5kcmV3OiBJcyBpdCB0aGUgZGVjb2RlciBvciB0aGUgd2hvbGUgdGhp bmcgdGhhdCBoYXMgdG8gYmUgcm95YWx0eSBmcmVlPw0KQWRhbTogTXkgcG9zaXRpb24gaXMgbm8N ClN0ZXBoZW46IFJlbWluZCB5b3UgdGhhdCBpbiB2aWRlbyBjb2RlYyBzdGFuZGFyZGl6YXRpb24s IHRoZSBvbmx5IHRoaW5nIHN0YW5kYXJkaXplZCBvbiB0aGUgYml0c3RyZWFtIGFuZCB0aGUgZGVj b2Rlci4gIEVuY29kZXIgc3R1ZmYgaXMgZW5jdW1iZXJlZCBkaWZmZXJlbnRseQ0KSmVyZW15OiBB cyB0aGUgMm5kIGNvbmRpdGlvbiBpcyB0aW1lIHJlbGF0ZWQsIGRvIHdlIGhhdmUgYSBtaW5pbXVt IHRpbWUgaW4gbWluZD8NCkNoYWlyczogbm90aGluZyB0aGF0IGRlY2xhcmVzIG1pbmltdW0geWV0 DQpIYXJhbGQ6IExpY2Vuc2luZyB0ZXJtcyBmb3IgYXQgbGVhc3Qgb25lIG9mIHRoZW0gY292ZXIg Ym90aCBkZWNvZGVyIGFuZCBlbmNvZGVyLCBidXQgdXAgdHAgeW91IGFuZCB5b3VyIGxhd3llciBp ZiB0aGV5IGFyZSBzdWZmaWNpZW50DQo/QXBwbGUgZ3V5PzogSGF2ZSB5b3UgY29uc2lkZXJlZCBl bmNvZGUgYm90aCwgZGVjb2RlIG9uZT8NCkNoYWlyczogSGFzIGJlZW4gY29uc2lkZXJlZCwgbm90 IGFncmVlZCB0bw0KPz86IFRyaWdnZXJpbmcgY29uZGl0aW9uIHJlOmJyb3dzZXJzIGRvIHdlIHdh bnQgdG8gcHJlY2x1ZGUgc29tZXRoaW5nIG5ldyB0aGF0IGlzIHdvbmRlcmZ1bC4NCkFkYW06IEhh cyBiZWVuIGRpc2N1c3NlZC4gIEJ5IHJlcXVpcmluZyBicm93c2VycyB0byBhbHdheXMgZG8gYm90 aCwgd2UgaGF2ZSBpbnRlcm9wIHdpdGggYSB3aWRlIHZhcmlldHkgb2Ygc21hbGxlciBkZXZpY2Vz DQoNCg0KSm9uYXRoYW4NCjxhZHZvY2F0ZXMgZm9yIHRoZSBjb21wcm9taXNlLCBib3RoIGlzIG9r YXk+DQoNCg0KSGFyYWxkDQo8YWR2b2NhdGVzIGZvciB0aGUgY29tcHJvbWlzZSwgYm90aCBpcyBv a2F5Pg0KQW5kcmV3OiBBcmUgdGhlIGdvYWxzIGFjaGlldmFibGU/ICBJcyBpdCBldmVuIGRvYWJs ZSwgZ2l2ZW4gYSB0eXBlIDMgZGVjbGFyYXRpb24/ICBXaWxsIEdvb2dsZSBpbXBsZW1lbnQ/DQpI YXJhbGQ6IFllcywgd2Ugd2lsbCwgbm90IHN1cmUgd2hlbi4gIEdvb2dsZSBpcyB3b3JraW5nIGZy b20gYW4gYXNzdW1wdGlvbiB0aGF0IFZQOCBpcyByb3lhbHR5IGZyZWUgYnV0IG1heSB0YWtlIHRp bWUgYW5kIGxhd3llcnMgdG8gcHJvdmUgdGhhdA0KDQoNClNlYW4gVHVybmVyIChhcyBzb2xlIHJl bWFpbmluZyBjaGFpcikgIFBsZWFzZSBzdGFuZCBpZiB5b3Ugd2lsbCBwYXJ0aWNpcGF0ZSBpbiB0 aGUgcHJvY2Vzcw0KPG1vc3Qgb2YgdGhlIHBlb3BsZSBpbiB0aGUgcm9vbSBzdGFuZD4NCkNoYWly OiBBcmUgdGhlcmUgYW55IG5ldyB0ZWNobmljYWwgaXNzdWVzPw0KQWRhbSAoZnJvbSBmbG9vcik6 IE5vdCBsaXRlcmFsIHdvcmRzIG9uIHRoZSBOb3ZlbCBQbGFuIG9uIHRoZSBzY3JlZW4NCkNoYWly OiBJdCdzIHRoZSB0cmlnZ2VyIHRoYXQgbmVlZHMgdGhlIHdvcmRzbWl0aGluZw0KQW5kcmV3OiBT b21lIG1haWwgbGlzdCBkaXNjdXNzaW9uIGlzc3VlcywgYW5kIGxpYWlzb24gc3RhdGVtZW50IGZy b20gR1NNQSwgd2Ugb3VnaHQgdG8gY29uc2lkZXIgYW5kIGRpc2N1c3MuICBIYXZlIGEgcHJvY2Vz cyBxdWVzdGlvbiwgc29tZSBsaXN0IGRpc2N1c3Npb24gaW5kaWNhdGluZyBpdCB3b3VsZCBub3Qg dG8gYmUgZGVjaWRlZC4gIE5vdCB0aGUgd2F5IHRvIGRvIGl0Lg0KQmVybmFyZDogQXJlIHdlIG9w ZW5pbmcgdGhlIGRpc2N1c3Npb24gbm93Pw0KQ2hhaXI6IFllcw0KQmVybmFyZDogTGl0aWdhdGlv biBvbiBWUDgsIGFuZCBsaWNlbnNpbmcgSC4yNjQgc3R1ZmYuICBKdXN0IGJlY2F1c2Ugd2UgcHV0 IGl0IGluIGEgc3RhbmRhcmQgZG9lc24ndCBtZWFuIGl0IHdpbGwgYmUgaW1wbGVtZW50ZWQuICBU aGUgdHlwZSAzIGRlY2xhcmF0aW9uIGlzIHByb2JsZW1hdGljIGZvciBtYW55IGNvbXBhbmllcy4g IFJlcXVpcmVzIHRpbWUsIHNpdHVhdGlvbiBtYXkgYmVjb21lIGNsZWFyZXIgYXMgSVNPIHN0YW5k YXJkaXphdGlvbiBjb250aW51ZXMuICBILjI2NCBNVEkgZG9jIHNheXMgSC4yNjQgaW1wbGVtZW50 YXRpb24gaGFzIHByb2xpZmVyYXRlZC4gIFZlcnkgd2lkZSBILjI2NCBkZXBsb3ltZW50LiAgTW9i aWxlIGRldmljZXMgYXJlIGFsbCBILjI2NC4gIFNvLCBpbmR1c3RyeSB3aWxsIHNvbHZlIHRoaXMu ICBJRVRGIGRvZXNuJ3QgbmVlZCB0byBzb2x2ZSB0aGlzLiAgVG9vIG11Y2ggZGVhZCB3ZWlnaHQg b24gdGhpcyBjb21wcm9taXNlLiAgU21hbGwgZGV2aWNlcyB3aWxsIG9ubHkgaW1wbGVtZW50IG9u ZS4gIEF0IGxlYXN0IHNldmVyYWwgYnJvd3NlciB2ZW5kb3JzIHdpbGwgbm90IGNvbW1pdCB0byB0 aGlzIGluIGFueSBuZWFyIHRpbWUgZnJhbWUuICBUaGUgbGVnYWwgYW5kIGJ1c2luZXNzIGlzc3Vl cyB3aWxsIHN0aWxsIGRvbWluYXRlDQpDaGFpcjogRGVjaXNpb24gd2lsbCBiZSB0YWtlbiB0byB0 aGUgbGlzdA0KQW5kcmV3OiBCdXQgd2UncmUgZGlzY3Vzc2luZyB0aGlzIG5vdywgc21hbGxlciBn cm91cCB0aGFuIGxhc3QgdGltZS4gIExvdHMgb2YgKzEgdG8gQmVybmFyZC4gIE1vYmlsZSBkZXZp Y2VzIHdpbGwgZG8gSC4yNjQuICBPbmUgYnJvd3NlciB2ZW5kb3IgaW5zaXN0aW5nIG9uIFZQOCwg YW5kIHRoZSBvcGVuIHNvdXJjZSBmb2xrcywgYnV0IHRoZXkgY2FuJ3QgaW1wbGVtZW50IChSRiku ICBXZSBjYW4ndCBhZmZvcmQgdG8gaW1wbGVtZW50IFZQOCB3aXRoIHRoZSBjdXJyZW50IGxlZ2Fs IHNpdHVhdGlvbi4gIFdlIGRvbid0IG5lZWQgdG8gZGVjaWRlLCBILjI2NCB3aWxsIGJlIHRoZSBN VEkgY29kZWMuDQpBZGFtOiBUaGFuayBBbmRyZXcgYW5kIEJlcm5hcmQgdG8gbm90ZSB0aGUgaGFs bG1hcmsgb2YgYSBnb29kIGNvbXByb21pc2UgaXMgbm8gb25lIGlzIGhhcHB5LiAgRG9uJ3QgdGhp bmsgdGhlIEguMjY0IE1USSBkb2MgZG9lc24ndCBjaGFuZ2UgdGhlIHNpdHVhdGlvbi4NClJhbmRh bCBKZXNzdXA6IE1vYmlsZSBILjI2NCBpcyBwcm9ibGVtYXRpYy4gIA0KVGVkOiBMaWFzb24gc3Rh dGVtZW50IGZyb20gR1NNQSBpcyBuaWNlLCBidXQgd2UgYWxzbyBoYXZlIGEgbGlhc29uIGZyb20g VzNDIHRoYXQgaGFkIGEgZGlmZmVyZW50IHZpZXcuICBMb3RzIG9mIGNoaXBzZXRzIGRvaW5nIGJv dGguIEFsd2F5cyBleHBlY3RlZCBtdWx0aXBsZSBjb2RlY3MsIGJ1dCBuZWVkIE1USSB0byBhdm9p ZCBuZWdvdGlhdGlvbiBmYWlsdXJlLiAgTmVlZCB0byBtYWtlIGRlY2lzaW9uLg0KPz9TaHVuOiBC dXNpbmVzcyBhbmQgdGVjaG5pY2FsIGRlY2lzaW9uIGJ5IHZlbmRvcnMuICBUd28gY29kZWNzIGNv bXByb21pc2VzIHVzLg0KSnVzdGluOiBCZXJuYXJkIHNheXMgbW9iaWxlIGlzIHRoZSBmdXR1cmUs IHdlIGFncmVlLCBhbGwgU09DcyBhcmUgc2hpcHBpbmcgd2l0aCBib3RoIGNvZGVjcy4gIFJpc2s6 IEdvb2dsZSwgQW1hem9uLCBRdWFsY29tbSwgU2Ftc3VuZyBhcmUgc2hpcHBpbmcsIGFuZCB0aGV5 IHRoaW5rIGl0cyBva2F5DQpNb2U6IEhhcmR3YXJlIHN1cHBvcnQgaXMgY2hhbmdpbmcsIHZlcnkg cG9zc2libGUgdG8gZ2V0IGFwcHMgdG8gZ2V0IGdyZWF0IHBlcmZvcm1hbmNlIG9uIG1vYmlsZS4g IE5vIG9uZSB0YWxraW5nIGFib3V0IGVuZCB1c2Vycy4gIFRoaXMgaXMgbm90IGEgY29tcHJvbWlz ZSBmb3IgdGhlbSwgaXQncyBhIGJpZyB3aW4uDQpCZXJuYXJkOiAgV2UgbW9zdGx5IGRlcGxveSBp biBtb2JpbGUgYXBwcywgYmVpbmcgZGVwbG95ZWQsIGNob29zaW5nIGEgY29kZWMuICBIYXJkd2Fy ZSB3aWxsIGhlbHAgdGhlbSwgYnV0IHRoZXkgYXJlIGJlaW5nIGNvbXBhdGlibGUgd2l0aCB0aGVp ciBzZXJ2ZXJzLCBldGMuICBXZWIgYXBwcyBhcmUgdGhlIHBsYWNlIHdoZXJlIHRoaXMgZG9lcyBt YXR0ZXIuICBXaG8gaXMgaGF2aW5nIHRvIGltcGxlbWVudCB3aGF0PyAgV2hhdCBpcyB0aGUgbWlz c2luZyBwb3J0aW9uPyBDb3ZlcmFnZSBvZiBILjI2NCBpcyB1bml2ZXJzYWwuDQpBbmRyZXc6IHRo ZSBmYWN0IHRoYXQgaGFyZHdhcmUgaXMgYXZhaWxhYmxlIG1lYW5zIHdlIGRvbid0IG5lZWQgdG8g ZGVjaWRlDQpDaGFpcjogV29ya2luZyBncm91cCBjb25zZW5zdXMgaXMgdG8gYWdyZWUgb24gYW4g TVRJDQpBbmRyZXc6IENvbnNlbnN1cyB3YXMgdG8gYWdyZWUgb24gYSBzaW5nbGUgTVRJLiAgVmVy eSByZWNlbnQgcHJvcG9zYWwuICBEaWZmZXJlbnQgcHJvcG9zYWwgb24gdGhlIGxpc3QuICBTaG91 bGQgY29uc2lkZXIgb3RoZXJzLiAgQ29sbGVndWUgc3VnZ2VzdGVkIG9ubHkgZGVjb2RlciBpcyBN VEkgYm90aC4gIFR3byB3ZWVrcyBhZ28gaXQgbG9va2VkIGxpa2UgdGhlcmUgd2FzIGdvaW5nIHRv IGJlIG5vIGRpc2N1c3Npb24gaGVyZS4gIFRoaXMgcHJvcG9zYWwgaGFzIG9ueSBiZWVuIGRpc2N1 c3NlZCBmb3Igb25lIHdlZWsuDQpFS1I6IExvbmcgc3RhbmRpbmcgY29uc2Vuc3VzIGZvciBNVEkg Y29kZWMuICBIYXZpbmcgdHdvIGlzIG5vdCBhcyBnb29kIGFzIG9uZSwgYnV0IGhhdmluZyBhbiBN VEkgZGVjaXNpb24gaXMgZ29vZC4gIFRoaXMgaXMgdGhlIGZpcnN0IHByb3Bvc2FsIHRoYXQgaGFz IGEgY2hhbmNlIHRvIHJlc29sdmUgdGhpcy4gIElmIHlvdSBoYXZlIGEgcHJvcG9zYWwgdGhhdCBo YXMgYSBjaGFuY2Ugb2YgYmVpbmcgYWNjZXB0ZWQsIHdlIGNhbiBkaXNjdXNzLiAgRG9uJ3Qgd2Fu dCB0byB3b3JyeSBhYm91dCBwZW9wbGUgd2hvIGRlY2lkZWQgbm90IHRvIGNvbWUuICBIYXZpbmcg Ym90aCBpbiB0aGUgcGxhdGZvcm0gaXMgbm90IGhhcmQuICBWUDggaXMgNTBLLiAgVGhpcyBtYWtl cyBhIHN1YnN0YW50aWFsIGltcGFjdCBvbiBpbnRlcm9wZXJhYmlsaXR5Lg0KQ3JhaWdNOiBPcGVu IHNvdXJjZSB3YXMgYW4gYXJndW1lbnQuICBUaGlzIGlzIGEgY29tcHJvbWlzZSwgYnV0IHRoZSB3 b3JsZCBvZiBvcGVuIHNvdXJjZSBpcyBmYXIgd2lkZXIuICBDb21wYXRpYmlsaXR5IGlzIGltcG9y dGFudC4gIFByb3Bvc2FsIGlzIHVnbHksIGJ1dCBpdCdzIGdvb2QgZm9yIG1vc3Qgb3BlbiBzb3Vy Y2UgZm9sa3MNCkhhcmFsZDogR1NNQSByZXBvcnQgaGFzIHNvbWUgcXVlc3Rpb25hYmxlIG51bWJl cnMuICBEb2Mgc2F5cyB0cmFuc2NvZGUgYXQgZ2F0ZXdheXMgaXMgcGFpbmZ1bC4gIFllcyBpdCBp cy4gIA0KSnVzdGluOiBUbyBtYWtlIGFuIEFuZHJvaWQgZGV2aWNlLCBWUDggc3VwcG9ydCBpcyBy ZXF1aXJlZC4gIEdyZWF0IHN0b3J5IGZvciBWUDggb24gbW9ibGUuDQpBZGFtOiBRdWVzdGlvbiBC ZXJuYXJkIG9uIHdoZXRoZXIgdGhpcyBkZWNpc2lvbiBpcyBhbiBpc3N1ZS4gIFRoaW5rIHRoYXQg dGhlcmUgYXJlIG1hbnkgZm9sa3MgaGVzaXRhdGluZyBiZWNhdXNlIG9mIHRoaXMgaXNzdWUuDQpK b25hdGhhbjogTm8gb25lIHJlYWxseSBrbm93cyB3aGF0IHRoZSBhcHAgZ3V5cyBoYXZlLiAgQnV0 IHdoYXQgdGhleSBhbGwgbmVlZCBpcyBhIHdlYiBicm93c2VyIGFwcC4gIFdlIHdpbGwgdGhlbiB1 bmxvY2sgdGhlc2UgYXBwcyB0byBoYXZlIGEgd2ViIGFwcC4gIExhcmdlc3QgYnVyZGVuIGlzIG9u IHRoZSBicm93c2VyLCBmb3Igc3VyZS4gIFRoZSBUeXBlIDMgaXNzdWUgaXMgYSBiaWcgb25lLCBh c2sgTVMgdG8gaGVscCB3aXRoIHRoYXQgVHlwZSAzIGRlY2xhcmF0aW9uLg0KPz86IExpa2UgdG8g c2VlIHRoZSB3b3JkaW5nIHRhbGsgYWJvdXQgcm95YWx0aWVzIGdvIHVwIG9yIGRvd24uDQpDdWxs ZW46IDMgeWVhciBkaXNjdXNzaW9uLiAgSXQgaGFzIGJlZW4gY2xlYXIgd2Ugd291bGQgZGlzY3Vz cyBhdCB0aGlzIG1lYW5pbmcuICAiQm90aCIgcHJvcG9zYWxzIGhhdmUgYmVlbiBkaXNjdXNzZWQg YW5kIGdvdHRlbiB3aWRlIHN1cHBvcnQgYmVmb3JlLg0KPz86IEhhcmR3YXJlIGRvZXMgd29yaywg YnV0IGl0cyBub3QgdG9kYXkuDQpNb250eTogQ291bGQgd2UgcmV2aXNpdCBhbm90aGVyIHByb3Bv c2FsIHRvbW9ycm93Pw0KQ2hhaXI6IEFsd2F5cyBwb3NzaWJsZQ0KPz9BcHBsZT8/OiBDYW4ndCBz dXBwb3J0IGEgZGVjaXNpb24gd2l0aCBhIHR5cGUgMyBkZWNsYXJhdGlvbg0KQmVybmFyZDogTm9r aWEgaXMgbm90IHJlbGF0ZWQgdG8gTVMsIHRoZXkgbWFkZSB0aGUgVHlwZSAzIGRlY2xhcmF0aW9u LiAgDQo/PzogTnVtYmVyIDMgKFdlYlJUQyBjb21wYXRpYmxlIGVuZHBvaW50cyBjYW4gaW1wbGVt ZW50IGFueSkgbmVlZHMgdG8gYmUgb24gdGhlIHF1ZXN0aW9uDQpNb2U6IFVuZGVyc3RhbmQgc29t ZSB2ZW5kb3JzIHdvbid0IGJlIGFibGUgdG8gY29tcGx5LiAgVGhpcyBzdGlsbCBnb29kIGZvciBl bm91Z2ggb2YgdGhlIFdlYlJUQyBjb21tdW5pdHkuICBHb29kIHRlY2huaWNhbCByZWFzb25zIHRv IGhhdmUgbW9yZSB0aGFuIG9uZS4NCkFuZHJldzogTVMgY2FuJ3QgcmVtb3ZlIHRoZSBUMyBkZWNs YXJhdGlvbiBldmVuIGlmIHRoZXkgaGF2ZSBhIGxpY2Vuc2UuICBXZSdyZSBiZWluZyBmb3JjZWQg Ynkgb25lIHZlbmRvciB0byBpbmNsdWRlIFZQOC4gIElmIG9wZW4gc291cmNlIGZvbGtzIGNhbiBs aXZlIHdpdGggdGhpcywgdGhleSBjYW4gbGl2ZSB3aXRoIEguMjY0Lg0KSGFyYWxkOiBUeXBlIDMg ZGVjbGFyYXRpb24gaGFzIG5vdCB0dXJuZWQgdXAuICBObyBwYXRlbnQgbWVudGlvbmVkDQpTdGVw aGVuOiBJU08gaGFzIGEgdGVjaG5pY2FsIHJldmFtcCBvZiB0aGVpciBkYXRhYmFzZSBhbmQgdGhh dCBoYXMgaGVsZCB1cCB0aGUgbm90aWNlLiAgSVNPIGRvZXMgbm90IHJlcXVpcmUgcGF0ZW50cw0K SGFyYWxkOiBOb2tpYSBmaWxlZCB0d28sIG9uZSBtYWRlIGl0IG9uZSBkaWRuJ3QuICBPdGhlciBk ZWNsYXJhdGlvbnMgZmlsZWQgYWZ0ZXIgaGF2ZSBjb21lIG91dC4NClBldGVyOiBNYWluIGJsb2Nr ZXIgaXMgYnJvd3NlcnMNCkRhblk6IFdlIGhhdmUgZGlzY3Vzc2VkIHRoaXMgZXZlcnkgd2hpY2gg d2F5LiAgTmVlZCB0byBkZWNpZGUuICBDb21wcm9taXNlIGlzIGEgdHJ1ZSBjb21wcm9taXNlLg0K SnVzdGluOiBVbnN5bXBhdGhldGljIHRvIHBvc3Rwb25pbmcgZGlzY3Vzc2lvbi4gIA0KS2FzaW1l cjogVHdvIGRhdGFiYXNlcyBJU08gKyBJRUMsIElFQyBoYXMgdGhlIGRlY2xhcmF0aW9uDQpFS1I6 IFRoZXJlIGFyZSBubyBwcm90b2NvbCBwb2xpY2UuICBJZiB5b3UgaGF2ZSBhIHN0YW5kYWxvbmUg Y2xvc2VkIGFwcCwgY2hvaWNlIG9mIGNvZGVjIGlzIGRvbid0IGNhcmUNCkFuZHJldzogUkZDcywg d2hvIGNhcmVzIGFib3V0IHRoZW0/ICAzR1BQIGNhcmVzLiAgVmVuZG9ycyB3b3VsZG4ndCBiZSBh YmxlIHRvIGNvbXBseS4gIFRoaXMgcHJvcG9zYWwgaXMgbGVzcyB0aGFuIGEgd2VlayBvbGQuICBT aG91bGQgaGF2ZSBtb3JlIHRpbWUuDQpDcmFpZ006IEluIG5vIHdheSBpcyB0aGlzIGF0dHJhY3Rp dmUgdG8gb3BlbiBzb3VyY2UsIGl0J3MgYSBjb21wcm9taXNlLiAgDQpKZXJlbXk6IFRoaXMgaXMg YWxsIHRpbWUgc2Vuc2l0aXZlLiAgSWYgaXRzIDItMyB5ZWFycywgd2Ugd29uJ3QgY2FyZS4NCkN1 bGxlbjogVGhlcmUgYXJlIHRoaW5ncyB0aGF0IGNvdWxkIHJlZHVjZSB1bmNlcnRhaW50eSBmb3Ig Ym90aCBjb2RlY3MgcmVsYXRpdmVseSBzb29uLiAgDQpUZWQ6IFRoaXMgaXMgYSBjb21wcm9taXNl IHRvIGdldCBpbnRlcm9wZXJhYmlsaXR5LiAgSW1wb3J0YW50IHRvIHRoZSB1c2VyIHRvIG1ha2Ug aW50ZXJvcGVyYWJpbGl0eSBhcyBicm9hZCBhcyBwb3NzaWJsZQ0KQmVybmFyZDogVGhpcyBpcyBh IGdyYW5kIGdlc3R1cmUsIGJ1dCB3b24ndCByZWFsbHkgY2hhbmdlIGFueXRoaW5nLiAgVG8gSnVz dGluLCB3aWxsIEdvb2dsZSBvZmZlciBpbmRlbW5pZmljYXRpb24uICANCg0KDQpDaGFpciAtIDUg bWludXRlIGJyZWFrDQpXaG8gZG9lcyBub3Qgd2FudCB0byB0YWtlIGEgc2Vuc2Ugb2YgdGhlIHJv b20gdG8gYWRkIHRoZSBjb21wcm9taXNlIHRleHQgdG8gdGhlIGRvYyB0b2RheQ0KQW5kcmV3OiBJ cyB0aGlzIGEgcXVlc3Rpb24gb2Ygc3VwcG9ydCBmb3IgdGhlIHByb3Bvc2FsPw0KQ2hhaXI6IE5v DQpLZWl0aDogSXMgdGhpcyBkbyB5b3Ugd2FudCB0byBkZWNpZGUgdG9kYXk/DQpDaGFpcjogWWVz DQpBbmRyZXc6IERvbid0IHdhbnQgdG8gZGVjaWRlIHRvZGF5DQpNYXJ0aW46IExhcmdlIHJvb20u ICBXb24ndCBnZXQgbGV2ZWxzIHJpZ2h0IHVubGVzcyB5b3UgYXNrIHR3byBzaWRlZCBxdWVzdGlv bnMNCg0KDQpDaGFpcjoNCldobyBkb2VzIG5vdCB3YW50IHRvIHRha2UgYSBzZW5zZSBvZiB0aGUg cm9vbSB0byBhZGQgdGhlIGNvbXByb21pc2UgdGV4dCB0byB0aGUgZG9jIHRvZGF5Pw0KPE5vIG9u ZSBpbiB0aGUgcm9vbSwgb25lIG9uIHRoZSBqYWJiZXI+DQoNCg0KQ2hhaXI6DQpUaGUgbmV4dCBx dWVzdGlvbiBpczogVGhvc2UgaW4gZmF2b3Igb2YgYWRkaW5nIHRoZSB0ZXh0IGluIHRoZSBkb2Mg dG9kYXkgaHVtbSBub3cNCkFuZHJldzogRG9uJ3Qgd2FudCB0byBkZWNpZGUgdG9kYXkNCkFEOiBO b3QgYSBmaW5hbCBkZWNpc2lvbiwgd2lsbCB0YWtlIHRvIHRoZSBsaXN0LiAgU3VnZ2VzdCBzdHJp a2luZyAidG9kYXkiDQpFS1I6IElmIHdlIGh1bW0gZm9yIHRoaXMsIHdlIGNvbmZpcm0gb24gdGhl IGxpc3QsIGFuZCB0aGVuIHdlIGNoYW5nZSB0aGUgZG9jLCByaWdodD8NCg0KDQpDaGFpcjogSHVt bSBub3cgaWYgeW91IHdhbnQgdG8gc2hvdmUgdGhlIHRleHQgaW4gdGhlIGRvY3VtZW50DQo8aHVt bXMgZW5zdWVkPg0K --001a1142d9dc07b78c0508a231e2-- From nobody Mon Nov 24 17:11:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627151A6F57 for ; Mon, 24 Nov 2014 17:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.112 X-Spam-Level: X-Spam-Status: No, score=0.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hde7FM416OFF for ; Mon, 24 Nov 2014 17:11:43 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30521A1BF0 for ; Mon, 24 Nov 2014 17:11:42 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so4560713vcb.8 for ; Mon, 24 Nov 2014 17:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mtZ4RjqwRbBd5mLgdk0Wmv4qB3eJIwiGGy/7wFRcv1g=; b=BE/IHBhVtLm3Q06glaKSKIeBOgykiCg6jU4qAWZ+erjZZ5KtPCn7SHbPRRmJZqJCy4 lbIpXLDswrlKW8wNMcJdaKVW4qmfCbNPEJYpWlOl/jQvqX0vnR6C1qBQSwOJbw09PNT8 GbAD3y0EuQMvy9B3hgo0NKeotJluWZHKQLf5DuryRWEFtMLgpc//kImnk4VkGbzdDZB4 EfDJlPw+VJObzwup7qEydvRkAHOqs23zaA2m6Y9k4wNV7lGzNLBZwftnoxoc9VvwNFd9 S6Pa331S9WBzwGwYfvmOwY37asF0CF1nAVc6rs1kaIkUN97T6j3vNoICVj+UVzYPeq/M S7bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mtZ4RjqwRbBd5mLgdk0Wmv4qB3eJIwiGGy/7wFRcv1g=; b=XNJ99OXfvvcJ9iKZIjAarbPySfTpPrOA/v5qa+5JX8Cxz3xaB0gOzxEJX9bvf599kL Uw8aOKekbz6EQyNbrKVdbHWzPOFInGy3ou2+LyYChdyrI8TYdK+Ks1J6I62VCXruvDTi 6prkhUq1dO7EYHBX9LBhgi57REXXG5oDmE05Qm2uOkk6EqcCgJU+OUspNOhsiD4cWFBs JsB2/Yl0OVt7Uvq6yNNXMY8pPhuWGqCDvnOnwZdqqgB6HepEBknyGKH511E5elwhLuMf tAZOrkqTRfgh9gqrg4rEvwmfOYwlgTBqsYj+mPM9NzxzfxcPas8dBcfl9CyioIqqzuFI 7UDQ== X-Gm-Message-State: ALoCoQm9jmxWv0QSfR/pXFc7kVfVrfvXAm2eec4C+3c48RjpqjE9pl+B+lFD5PJCOVGqnb6qSGFu X-Received: by 10.53.10.65 with SMTP id dy1mr11361126vdd.51.1416877901762; Mon, 24 Nov 2014 17:11:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 24 Nov 2014 17:11:21 -0800 (PST) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> From: Justin Uberti Date: Mon, 24 Nov 2014 17:11:21 -0800 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=001a113659d0066fe50508a498db Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1A09Uz8AkQ2CEo5Eq_NlDGD0jck Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Nov 2014 01:11:44 -0000 --001a113659d0066fe50508a498db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Quoth RFC5763, Section 5: o The endpoint MUST use the setup attribute defined in [RFC4145 ]. The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer. The answerer MUST use either a setup attribute value of setup:active or setup:passive. Note that if the answerer uses setup:passive, then the DTLS handshake will not begin until the answerer is received, which adds additional latency. setup:active allows the answer and the DTLS handshake to occur in parallel. Thus, setup:active is RECOMMENDED. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). However I concur that the existing roles should be maintained, e.g. the answerer must choose active or passive appropriately. Chrome will fail upon an attempted role change. On Mon, Nov 24, 2014 at 7:36 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > Hi, > > I'm looking into the JSEP draft. One thing that seems strange is that in > every offer the role offered is "actpass", also for existing > connections. As I read section 7.3 of > https://www.rfc-editor.org/rfc/rfc4145.txt the established roles should > be maintained in such situations. > > What is the reason for the always offering "actpass" also for > established roles/connections? > > Stefan > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113659d0066fe50508a498db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Quoth RFC5763, Section 5:

   o  The endpoint MUST use the setup attribute defined in [RFC4145].
      The endpoint that is the offerer MUST use the setup attribute
      value of setup:actpass and be prepared to receive a client_hello
      before it receives the answer.  The answerer MUST use either a
      setup attribute value of setup:active or setup:passive.  Note that
      if the answerer uses setup:passive, then the DTLS handshake will
      not begin until the answerer is received, which adds additional
      latency. setup:active allows the answer and the DTLS handshake to
      occur in parallel.  Thus, setup:active is RECOMMENDED.  Whichever
      party is active MUST initiate a DTLS handshake by sending a
ClientHello over each flow (host/port quartet).

However I concur that the existing roles sh= ould be maintained, e.g. the answerer must choose active or passive appropr= iately. Chrome will fail upon an attempted role change.

On Mon, Nov 24, 2014 at 7= :36 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@erics= son.com> wrote:
Hi,

I'm looking into the JSEP draft. One thing that seems strange is that i= n
every offer the role offered is "actpass", also for existing
connections. As I read section 7.3 of
ht= tps://www.rfc-editor.org/rfc/rfc4145.txt the established roles should be maintained in such situations.

What is the reason for the always offering "actpass" also for
established roles/connections?

Stefan

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

--001a113659d0066fe50508a498db-- From nobody Mon Nov 24 23:08:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56C81A0013 for ; Mon, 24 Nov 2014 23:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmnW_1z2puhT for ; Mon, 24 Nov 2014 23:08:33 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B301A0010 for ; Mon, 24 Nov 2014 23:08:32 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-91-54742aee7e05 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7F.F2.04231.EEA24745; Tue, 25 Nov 2014 08:08:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 08:08:30 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Tue, 25 Nov 2014 07:08:30 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje57rZIQg/l3WC22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlvL5zjr1gv2jF4fP5DYy/BLoYOTkkBEwkbt5b xQphi0lcuLeerYuRi0NI4AijxP7lm9ghnCWMEhc2djCBVLEJBEps3beADcQWEVCTeDhrF1g3 s4C6xJ3F59hBbGEBU4lJF5cxQdSYSSw8OYERwtaTuPnlAksXIwcHi4CqxOxDyiAmr4CvROuC MohVUxglTnzZBdbKCHTQ91NrmCDGi0vcejKfCeJQAYkle84zQ9iiEi8f/4N6QEmicckTqHP0 JG5MncIGYWtLLFv4GqyeV0BQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSs l1qUmVxcnJ+nl5dasokRGCEHt/zW3cG4+rXjIUYBDkYlHt4NH4pDhFgTy4orcw8xSnOwKInz Ljo3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY1bN03NaLbeKjFfyh9S/MrnGdjAwSJJ3 dULAC/nMBIXMjgUH9rFe8mDOq+MzWpP8P2WhgexNoyk/HJqnzY+6q6fpxT11v/C8/z8faC46 MMn8zVG3tBYf4dCONHXBc5W/HSS23OwK3G62If5rdeWeyIBFd+fc8SpaGcc/4ez5b7afbZhz uvldlViKMxINtZiLihMBmBh5w3ECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xsMA1ZQjIHJkRxINX2lcldyrIWc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Nov 2014 07:08:36 -0000 On 25/11/14 02:11, Justin Uberti wrote:=0A= > Quoth RFC5763, Section 5:=0A= >=0A= > o The endpoint MUST use the setup attribute defined in [RFC4145 ].=0A= > The endpoint that is the offerer MUST use the setup attribute=0A= > value of setup:actpass and be prepared to receive a client_hello= =0A= > before it receives the answer. The answerer MUST use either a=0A= > setup attribute value of setup:active or setup:passive. Note that= =0A= > if the answerer uses setup:passive, then the DTLS handshake will= =0A= > not begin until the answerer is received, which adds additional=0A= > latency. setup:active allows the answer and the DTLS handshake to= =0A= > occur in parallel. Thus, setup:active is RECOMMENDED. Whichever= =0A= > party is active MUST initiate a DTLS handshake by sending a=0A= >=0A= > ClientHello over each flow (host/port quartet).=0A= =0A= The section quoted seem to refer to the initial offer/answer, later in =0A= that document (section 6.6, with heading "Session Modification") there =0A= is wording that (to me at least) hints at keeping the established roles =0A= in subsequent offers.=0A= =0A= A different question is the value of initially offering actpass when ICE = =0A= is mandatory to use. ICE connectivity checks will happen before the DTLS = =0A= handshake, so perhaps initially offering passive would make sense. =0A= (actpass is a MUST according to 5763, OTOH 5763 is only an informal ref =0A= to JSEP.)=0A= =0A= >=0A= >=0A= > However I concur that the existing roles should be maintained, e.g. the= =0A= > answerer must choose active or passive appropriately.=0A= =0A= Agreed.=0A= =0A= > Chrome will fail=0A= > upon an attempted role change.=0A= >=0A= > On Mon, Nov 24, 2014 at 7:36 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > Hi,=0A= >=0A= > I'm looking into the JSEP draft. One thing that seems strange is that= in=0A= > every offer the role offered is "actpass", also for existing=0A= > connections. As I read section 7.3 of=0A= > https://www.rfc-editor.org/rfc/rfc4145.txt the established roles shou= ld=0A= > be maintained in such situations.=0A= >=0A= > What is the reason for the always offering "actpass" also for=0A= > established roles/connections?=0A= >=0A= > Stefan=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= =0A= From nobody Tue Nov 25 08:28:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF461ACD9A for ; Tue, 25 Nov 2014 08:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWsjufu6JqNM for ; Tue, 25 Nov 2014 08:28:31 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4701ACDA1 for ; Tue, 25 Nov 2014 08:28:26 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 1270917F36211; Tue, 25 Nov 2014 16:28:20 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sAPGSMev030742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 11:28:22 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 11:28:22 -0500 From: "Makaraju, Maridi Raju (Raju)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAAz2pYg Date: Tue, 25 Nov 2014 16:28:22 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JJy9rAEVd96Og6tqypjrCHSPGic Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Nov 2014 16:28:33 -0000 > > o The endpoint MUST use the setup attribute defined in [RFC4145 > ]. > > The endpoint that is the offerer MUST use the setup attribute > > value of setup:actpass and be prepared to receive a client_hello > > before it receives the answer. The answerer MUST use either a > > setup attribute value of setup:active or setup:passive. Note th= at > > if the answerer uses setup:passive, then the DTLS handshake will > > not begin until the answerer is received, which adds additional > > latency. setup:active allows the answer and the DTLS handshake t= o > > occur in parallel. Thus, setup:active is RECOMMENDED. Whicheve= r > > party is active MUST initiate a DTLS handshake by sending a > > > > ClientHello over each flow (host/port quartet). >=20 > The section quoted seem to refer to the initial offer/answer, later in > that document (section 6.6, with heading "Session Modification") there > is wording that (to me at least) hints at keeping the established roles > in subsequent offers. >=20 > A different question is the value of initially offering actpass when ICE > is mandatory to use. ICE connectivity checks will happen before the DTLS > handshake, so perhaps initially offering passive would make sense. > (actpass is a MUST according to 5763, OTOH 5763 is only an informal ref > to JSEP.) Limiting it to "passive" would force the peer and/or intermediaries to supp= ort DTLS client functionality as well. IMHO, this may limit the success rat= e. If a peer or middlebox does not support DTLS client functionality then i= t can always return "passive", which may involve bit more delay in DTLS set= up. But it is not that bad as the SDP offerer must wait for SDP answer (a= =3Dfingerprint is needed) before the DTLS can be setup successfully anyway. BR Raju From nobody Tue Nov 25 09:38:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234501A6FFF for ; Tue, 25 Nov 2014 09:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8y6SmtfCVFk for ; Tue, 25 Nov 2014 09:38:36 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABD81A0368 for ; Tue, 25 Nov 2014 09:38:35 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-a8-5474be990274 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.65.04081.99EB4745; Tue, 25 Nov 2014 18:38:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 18:38:33 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Makaraju, Maridi Raju (Raju)" , "Justin Uberti" Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Tue, 25 Nov 2014 17:38:32 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7MfSUhBg9PGVhsnSpk0bDxCqvF 2n/t7A7MHq3P9rJ6LNhU6rFkyU+mAOYoLpuU1JzMstQifbsEroxfR2sK9gpVfL/wi7mBcQ5/ FyMnh4SAicSyxyfYIGwxiQv31gPZXBxCAkcYJf5f+soI4SxhlHh8ZgJYFZtAoMTWfQvAbBGB XIl5fSvBbGYBdYk7i8+xg9jCAqYSky4uY4KoMZNYeHICI4StJ3HzywUWEJtFQFXi24OrzCA2 r4CvRNuvbVDLVjNJHJr/EayZEeik76fWMEEsEJe49WQ+E8SpAhJL9pxnhrBFJV4+/scKYStJ rNh+iRGiXk/ixtQpUMdpSyxb+BpqmaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLU4 KTfdyEgvtSgzubg4P08vL7VkEyMwcg5u+W2wg/Hlc8dDjAIcjEo8vBs+FIcIsSaWFVfmHmKU 5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGtZqyc5V2HHv/WqtYwXan5alX nK7WQrdFX4o/fsk6p/jQiYMnZ+ovsZVlnDj9x3ob35tLy2JKq+cmHm9qZvRb/t2uUWrb+baS nRMvrZhQHDPfJiSuLHnunZnSaaI5e5YK7L7xYat4zZ0lUybaelWvk1jYt+XvM6aEEKk/qjaK L8+cMXqn9fA2txJLcUaioRZzUXEiAOONGVR9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LmkqKs0g5QJv8fscZYKu9XMVdCw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Nov 2014 17:38:38 -0000 On 25/11/14 17:28, Makaraju, Maridi Raju (Raju) wrote:=0A= >>> o The endpoint MUST use the setup attribute defined in [RFC4145=0A= >> ].=0A= >>> The endpoint that is the offerer MUST use the setup attribute=0A= >>> value of setup:actpass and be prepared to receive a client_hello=0A= >>> before it receives the answer. The answerer MUST use either a=0A= >>> setup attribute value of setup:active or setup:passive. Note=0A= >>> that if the answerer uses setup:passive, then the DTLS handshake=0A= >>> will not begin until the answerer is received, which adds=0A= >>> additional latency. setup:active allows the answer and the DTLS=0A= >>> handshake to occur in parallel. Thus, setup:active is=0A= >>> RECOMMENDED. Whichever party is active MUST initiate a DTLS=0A= >>> handshake by sending a=0A= >>>=0A= >>> ClientHello over each flow (host/port quartet).=0A= >>=0A= >> The section quoted seem to refer to the initial offer/answer, later=0A= >> in that document (section 6.6, with heading "Session Modification")=0A= >> there is wording that (to me at least) hints at keeping the=0A= >> established roles in subsequent offers.=0A= >>=0A= >> A different question is the value of initially offering actpass=0A= >> when ICE is mandatory to use. ICE connectivity checks will happen=0A= >> before the DTLS handshake, so perhaps initially offering passive=0A= >> would make sense. (actpass is a MUST according to 5763, OTOH 5763=0A= >> is only an informal ref to JSEP.)=0A= >=0A= > Limiting it to "passive" would force the peer and/or=0A= > intermediaries to support DTLS client functionality as well. IMHO,=0A= > this may limit the success rate. If a peer or middlebox does not=0A= > support DTLS client functionality then it can always return=0A= > "passive", which may involve bit more delay in DTLS setup. But it is=0A= > not that bad as the SDP offerer must wait for SDP answer=0A= > (a=3Dfingerprint is needed) before the DTLS can be setup successfully=0A= > anyway. =0A= =0A= Thanks Raju, seems this was a bad proposal - forget you heard it!=0A= =0A= Do you have an opinion on my main "topic": that subsequent offers should = =0A= offer the already negotiated role, rather than always "actpass"?=0A= =0A= Br,=0A= Stefan=0A= =0A= >=0A= > BR Raju=0A= >=0A= =0A= From nobody Tue Nov 25 10:31:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F02F1A8766 for ; Tue, 25 Nov 2014 10:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFOOhdnkF9jM for ; Tue, 25 Nov 2014 10:30:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACB01A8786 for ; Tue, 25 Nov 2014 10:30:07 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 4969456E03ED4; Tue, 25 Nov 2014 18:30:01 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sAPIU3aS000711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 13:30:03 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 13:30:03 -0500 From: "Makaraju, Maridi Raju (Raju)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAA2/86w Date: Tue, 25 Nov 2014 18:30:02 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pweTq1Ul-kliw5-sOrc0CjNEMMk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Nov 2014 18:30:48 -0000 >=20 > Do you have an opinion on my main "topic": that subsequent offers should > offer the already negotiated role, rather than always "actpass"? [Raju] For non DTLS-SRTP associations, I think the key attribute here is a=3Dconne= ction. If a subsequent offer has an explicit "a=3Dconnection:existing" then= per the reference[1] a=3Dsetup (and other params) are ignored. Per [2] bel= ow, the default value for a=3Dconnection is "new" in offer and answer. So, = if an explicit "a=3Dconnection:new" is present or "a=3Dconnection" is absen= t then, per [3], the existing association is closed and a new association = will be opened using new a=3Dsetup rules. Btw, I think section 7.3 of RFC 4145 is just an example showing previously = negotiated setup values are used. But section 5.1 is normative and clearly = says these attributes must be ignored for a=3Dconnection:existing. Reference [4] and [5] are for DTLS-SRTP which does not allow a=3Dconnection= attribute and indicates new offer/answer compatibility with old as the cri= teria to reuse or close/open new one. It also notes that if a=3Dsetup chang= es then a new association is established. This latter part also have to con= sider the a=3Dsetup defaults, which may be different from previously negoti= ated values, if absent in new offer/answer. [1] https://tools.ietf.org/html/rfc4145#section-5.1 =20 "If the connection value resulting from an offer/answer exchange is 'existing', the end-points continue using the existing connection. Consequently, the port numbers, IP addresses, and 'setup' attributes negotiated in the offer/answer exchange are ignored because there is no need to establish a new connection." [2] https://tools.ietf.org/html/rfc4145#section-5.1 =20 "The default value of the connection attribute in both offers and answers is 'new'. " [3] https://tools.ietf.org/html/rfc4145#section-5.2=20 "If the connection value for an 'm' line resulting from an offer/ answer exchange is 'new', the endpoints SHOULD establish a new TCP connection as indicated by the 'setup' attribute. If a previous TCP connection is still up, the endpoints SHOULD close it as soon as the offer/answer exchange is completed. It is up to the application to ensure proper data synchronization between the two TCP connections." [4] DTLS SRTP RFC https://tools.ietf.org/html/rfc5763#section-5 " The endpoint MUST NOT use the connection attribute defined in [RFC4145]." [5] https://tools.ietf.org/html/rfc5763#section-6.6 "The peers can reuse the existing associations if they are compatible (i.e., they have the same key fingerprints and transport parameters), or establish a new one following the same rules are for initial exchanges, tearing down the existing association as soon as the offer/answer exchange is completed. Note that if the active/passive status of the endpoints changes, a new connection MUST be established." BR Raju From nobody Tue Nov 25 15:29:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535501A8029; Tue, 25 Nov 2014 15:29:07 -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 f1aIyzXgHjF7; Tue, 25 Nov 2014 15:29:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 232B41A8707; Tue, 25 Nov 2014 15:29:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141125232901.1106.34782.idtracker@ietfa.amsl.com> Date: Tue, 25 Nov 2014 15:29:01 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0DFebktYcXDrJw1vURJJ820NBvw Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-video-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 23:29:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Video Processing and Codec Requirements Author : Adam Roach Filename : draft-ietf-rtcweb-video-03.txt Pages : 8 Date : 2014-11-25 Abstract: This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, as well as video codecs and their parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-video-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 25 15:34:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B171A87B2 for ; Tue, 25 Nov 2014 15:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87dP60NVXzer for ; Tue, 25 Nov 2014 15:33:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376401A86FA for ; Tue, 25 Nov 2014 15:33:57 -0800 (PST) Received: from Orochi.local ([38.100.151.157]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAPNXqA1090147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 17:33:53 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [38.100.151.157] claimed to be Orochi.local Message-ID: <547511DB.5050100@nostrum.com> Date: Tue, 25 Nov 2014 17:33:47 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3-IKK4aC0CXsoIwv5qiVu_kyxmA Cc: Harald Alvestrand Subject: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 25 Nov 2014 23:33:59 -0000 I've updated the draft-ietf-rtcweb-video based on the minutes from Hawaii. Now that we have a clear path to success, I'd like to get the document finalized and published as quickly as possible. This means I need your feedback on the remaining open issues (1, 4, and 5, below). If you are CCed on this mail, it's because you took an action item in Hawaii, and I'm waiting to hear back from you. New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt ____ Action item for Harald Alvestrand from the minutes: > Mo Zanaty: An IANA registered header with reference to 3GPP document. > Codec specific mechanism way of doing this. > Harald: Will send some suggestions on doing this. Action item for Bernard Aboba and Stephan Wenger: collect list of H.264 SEI messages we want to call out as MUST and/or SHOULD. ____ Open Issue 1: If you don't want sRGB to be the default color space, say something now. Open Issue 2 (closed): Took "screen source video metadata" issue out of the document, as this is an RTP issue, not a codec issue. Open Issue 3 (closed): New text in "stream orientation" section calling out various MUST/SHOULD/MAY levels, based on what I took away from the mic in Hawaii. If you care about this, double-check that these are what you expect them to be. Open Issue 4: In Toronto, it was suggested that we don't need to specify support for "bilinear" and "none" filter styles, since they're already required. I'm happy to remove the statement if someone can point me to where this is otherwise mandated. If no one comes forward with a citation, I'm going to close this open issue as harmless. Open Issue 5: Waiting on feedback from Bernard and Stefan, as detailed above. Open Issue 6 (closed): Please see the text in section 5 of the new document, which tracks the text from the Novel Proposal email pretty closely. /a From nobody Tue Nov 25 21:17:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA841A87D7 for ; Tue, 25 Nov 2014 21:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WZGZ9B4OH-Hk for ; Tue, 25 Nov 2014 21:17:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::752]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7223E1A88BC for ; Tue, 25 Nov 2014 21:17:19 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1274.namprd07.prod.outlook.com (25.160.149.17) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 05:16:56 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 05:16:56 +0000 From: Stephan Wenger To: Adam Roach , "rtcweb@ietf.org" Thread-Topic: Finishing up the Video Codec document Thread-Index: AQHQCQhLH8Rvof4WtkWeNp84Mnvyvpxx2CWA Date: Wed, 26 Nov 2014 05:16:55 +0000 Message-ID: References: <547511DB.5050100@nostrum.com> In-Reply-To: <547511DB.5050100@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1274; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(24454002)(479174003)(2501002)(97736003)(101416001)(31966008)(2656002)(87936001)(36756003)(86362001)(120916001)(92726001)(561944003)(92566001)(99286002)(15202345003)(107886001)(107046002)(106356001)(106116001)(46102003)(19580405001)(105586002)(19580395003)(76176999)(50986999)(40100003)(122556002)(54356999)(64706001)(66066001)(20776003)(77156002)(77096003)(62966003)(4396001)(15975445006)(95666004)(21056001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3D304705F8E5604BAD5FE10DD753C77E@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8UCIfJ4jDjml5xDiZ5iA55zZpIQ Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Nov 2014 05:17:22 -0000 Hi, below a few generic comments (not directly related to my action item). Stephan 1. Section 3: sRGB is fine. 2. Section 3: Add something like dynamic frame rate / frame interval based on user locale, available bandwidth, and so on. For example, in low light conditions, it almost never makes sense to run a full 30 fps camera when your transport has only bandwidth for 15 fps. 3. Section 3: Possibly missing: mention that the video scan pattern for both VP8 and H.264 is YCrCb 4:2:0. 4. Section 3: Possibly missing: the screen content section should mention that the scan format of video (YCrCb 4:2:0) is known to be suboptimal for the representation of screen content as produced by systems at the time of publication, which generally use at least 24 bits per sample RGB. Perhaps a forward looking statement: =B3In the future, it may become advisable to use video codecs optimized for screen content (scan pattern, color space, signal characteristics) for the representation of this type of content.=B2 5. Section 5 second and third paragraphs: Mention Constrained Baseline Profile here. Otherwise, section 5 seems fine to me. (I know that constrained baseline is mentioned as a MUST later, but H.264 in isolation is insufficient even in this overview part of the document). 6. Section 6, 3rd para, 1st and 2nd line, nit: "are MUST=B2 5. Section 6.2, profile_level_id, suggest to change the receiving side to a MUST. The decoder interprets the value anyway as presented in-band. What=B9s the point that a receiver accepts a bitstream (without checking profile_level_id), and the croaks because the decoder cannot handle the bitstream complexity as communicated in-band? 6. Section 6.2, max_mbps..., nit: par ameters (1st and second line) Normative reference to H.264: depending on the timing, it may be better to reference H.264v9. That version is currently in =B3pre-published=B2 state = and not freely downloadable, but should be generally available rather sooner than later (and almost certainly before we are through with this draft). 7. Section 6.2, sprop_parameter_sets: For avoidance of doubt, I would rephrase that as =B3this parameter MUST NOT be present=B2. It is possible = to have that parameter and later change parameter sets in-band, and that is a condition I think you want to avoid. (btw. my heart is bleeding. Some of you know why. The rest: keep guessing :-) 8. Section 6.2, Possibly missing: for H.264, should we specify a pixel aspect ratio? VP8 uses square pixels, right? Perhaps follow that lead? 9. Section 7: point to the payload formats also. H.264 allows for active content in SEI messages... and the payload formats contain the necessary caveats. On 11/25/14, 15:33, "Adam Roach" wrote: >I've updated the draft-ietf-rtcweb-video based on the minutes from >Hawaii. Now that we have a clear path to success, I'd like to get the >document finalized and published as quickly as possible. This means I >need your feedback on the remaining open issues (1, 4, and 5, below). If >you are CCed on this mail, it's because you took an action item in >Hawaii, and I'm waiting to hear back from you. > >New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ >Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-video-03.txt >____ > >Action item for Harald Alvestrand from the minutes: >> Mo Zanaty: An IANA registered header with reference to 3GPP document. >> Codec specific mechanism way of doing this. >> Harald: Will send some suggestions on doing this. > >Action item for Bernard Aboba and Stephan Wenger: collect list of H.264 >SEI messages we want to call out as MUST and/or SHOULD. >____ > >Open Issue 1: If you don't want sRGB to be the default color space, say >something now. > >Open Issue 2 (closed): Took "screen source video metadata" issue out of >the document, as this is an RTP issue, not a codec issue. > >Open Issue 3 (closed): New text in "stream orientation" section calling >out various MUST/SHOULD/MAY levels, based on what I took away from the >mic in Hawaii. If you care about this, double-check that these are what >you expect them to be. > >Open Issue 4: In Toronto, it was suggested that we don't need to specify >support for "bilinear" and "none" filter styles, since they're already >required. I'm happy to remove the statement if someone can point me to >where this is otherwise mandated. If no one comes forward with a >citation, I'm going to close this open issue as harmless. > >Open Issue 5: Waiting on feedback from Bernard and Stefan, as detailed >above. > >Open Issue 6 (closed): Please see the text in section 5 of the new >document, which tracks the text from the Novel Proposal email pretty >closely. > >/a From nobody Tue Nov 25 21:25:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAD71A8A3B for ; Tue, 25 Nov 2014 21:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcmjmEqcDfjP for ; Tue, 25 Nov 2014 21:25:45 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34D51A8A28 for ; Tue, 25 Nov 2014 21:25:39 -0800 (PST) Received: from [192.168.0.26] (c-76-100-22-52.hsd1.va.comcast.net [76.100.22.52]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D9881F240D for ; Tue, 25 Nov 2014 21:25:38 -0800 (PST) Message-ID: <54756452.90105@mozilla.com> Date: Tue, 25 Nov 2014 21:25:38 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7f4WKqo3MAvVdWNRHbi4DrQ08bA Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Nov 2014 05:25:47 -0000 Stephan Wenger wrote: > 3. Section 3: Possibly missing: mention that the video scan pattern for > both VP8 and H.264 is YCrCb 4:2:0. You mean Y'CbCr, no? From nobody Tue Nov 25 21:27:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA22E1A8A23 for ; Tue, 25 Nov 2014 21:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C0bp-IoPimNt for ; Tue, 25 Nov 2014 21:27:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::755]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814541A89F9 for ; Tue, 25 Nov 2014 21:27:47 -0800 (PST) Received: from CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) by CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 05:27:24 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 05:27:22 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 05:27:22 +0000 From: Stephan Wenger To: Adam Roach , Bernard Aboba , "rtcweb@ietf.org" Thread-Topic: Finishing up the Video Codec document Thread-Index: AQHQCQhLH8Rvof4WtkWeNp84MnvyvpxxzOkAgAAOKAA= Date: Wed, 26 Nov 2014 05:27:22 +0000 Message-ID: References: <547511DB.5050100@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1275; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(189002)(479174003)(24454002)(199003)(31966008)(76176999)(50986999)(54356999)(15202345003)(105586002)(106116001)(40100003)(122556002)(21056001)(107046002)(107886001)(77096003)(77156002)(62966003)(15975445006)(86362001)(97736003)(2501002)(92726001)(92566001)(20776003)(64706001)(66066001)(19580405001)(19580395003)(561944003)(2656002)(87936001)(101416001)(120916001)(46102003)(106356001)(99286002)(95666004)(36756003)(4396001)(21314002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1275; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1273; X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_d7PODLwX94q28bpOpTN7Lw-k6M Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Nov 2014 05:27:50 -0000 SGksDQoNCkkgbWVhbnQgdG8gY29weSB0aGUgbWFpbGluZyBsaXN0IG9uIHR3byBlbWFpbHMgcmVn YXJkaW5nIG15IChhbmQNCkJlcm5hcmTigJlzKSBhY3Rpb24gaXRlbXMuICBJIG1pcy1zcGVsbGVk IHJ0Y3dlYi4gIFNvIGhlcmUgdGhlIGNvbnRlbnQNCmludGVncmF0ZWQgaW50byBhIHNpbmdsZSBl bWFpbC4gIChCZXJuYXJkIGFuZCBBZGFtOiB0aGVyZeKAmXMgbm90aGluZyBuZXcNCmhlcmVpbi4p DQoNCkhpLA0KU28gaGVyZSBteSBwcm9wb3NhbCwgd2l0aCByZXNwZWN0IHRvIEguMjY0IGJhc2Vs aW5lOg0KDQpNVVNUOg0KRmlsbGVyIHBheWxvYWQuICBZb3Ugc2VlIHRoaXMgb2NjYXNpb25hbGx5 IGZyb20gbW9zdGx5IGVhcmx5IGdlbmVyYXRpb24pDQplbmNvZGVyIGNoaXBzLiAgSXTCuXMgYmFz aWNhbGx5IGEgd2F5IHRvIHdhc3RlIGJpdHMgc28gdG8gZnVsZmlsbCBidWZmZXINCmNvbnN0cmFp bnRzLiAgSW1wbGVtZW50YXRpb24gY29tcGxleGl0eSBpcyB6ZXJvOiB0aHJvdyBhd2F5IGJpdHMu DQoNCkZ1bGwgZnJhbWUgZnJlZXplOiB1c2VkIGluIHZpZGVvIHN3aXRjaGluZyBNQ1VzLCB0byBl bnN1cmUgYSBzdGFibGUNCmRlY29kZWQgZGlzcGxheWVkIHBpY3R1cmUgd2hpbGUgc3dpdGNoaW5n IGNoYW5uZWxzIGluIHByb2JhYmx5IGENCm1lZGlhLXVuYXdhcmUgd2F5LiAgQ29tbW9ubHkgdXNl ZCBpbiBILjMyeCBsZWdhY3kgZW52aXJvbm1lbnRzIGFuZCBhbHNvIGluDQpzb21lIFNJUCBNQ1Vz Lg0KDQoNClNIT1VMRDoNCnZhY2F0DQoNCk1BWToNClVzZXIgZGF0YSBULjM1IHJlZ2lzdGVyZWQs IGFuZCB1c2VyIGRhdGEgdW5yZWdpc3RlcmVkDQpFc3BlY2lhbGx5IHRoZSBsYXR0ZXIgeW91IHNl ZSBvY2Nhc2lvbmFsbHkgZm9yIHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMuDQpJdMK5cyBhIGdvb2Qg aWRlYSB0byBhZHZpc2UgaW1wbGVtZW50ZXJzIHRoYXQgYSBiaXRzdHJlYW0gbWF5IGNvbnRhaW4g dGhhdA0Ka2luZCBvZiBzdHVmZiwgZXZlbiBpZiB0aGV5IGRvbsK5dCBhY3Qgb24gaXQuDQoNCkRp c3BsYXkgb3JpZW50YXRpb24gU0VJLCBhcyBpdCBpcyByZWZlcmVuY2VkIGluIHNlY3Rpb24gNC4N Cg0KDQoNCg0KV2l0aCByZXNwZWN0IHRvIGZyZWV6ZSByZXF1ZXN0LCBiZWxvdyBhIHNsaWdodGx5 IGVkaXRlZCB2ZXJzaW9uIG9mIGFuDQplbWFpbCB0aGF0IEkgc2VudCB0byBBZGFtIHdoZW4gaGUg d2FzIHByZXBhcmluZyB0aGUgcHJlIElFVEYtOTEgZHJhZnQuDQoNClN0ZXBoYW4NCg0KRnJlZXpl LXJlcXVlc3QgYW5kIGZyZWV6ZS1yZWxlYXNlIGlzIHNvbWV0aGluZyB1c2VkIGluIHRoZSB2aWRl byBjb25mDQppbmR1c3RyeSBmb3IgYWdlcy4NCkNvbnNpZGVyIGEgZm91ci13YXkgY29uZmVyZW5j ZSB3aXRoIGVuZHBvaW50cyBBLCBCLCAgQywgYW5kIEQsIGFuZCBhDQp2aWRlby1zd2l0Y2hpbmcg TUNVLiAgQSwgQiwgQyBhcmUgYWxsIHNlbmRpbmcgcGljdHVyZXMgdG8gdGhlIE1DVS4gIEZvcg0K cmVjZWl2aW5nIGVuZHBvaW50IEEsIHRoZSBNQ1Ugc2VsZWN0cyBlaXRoZXIgYml0c3RyZWFtIHNl bnQgYnkgQiBvciBieQ0KZW5kcG9pbnQgQyBmb3IgZm9yd2FyZGluZyB0byBBLiAgVGhlIHNlbGVj dGlvbiBjYW4gYmUgYmFzZWQgb24gdm9pY2UNCmFjdGl2YXRpb24sIGNvbmYgY29udHJvbCwgbWFu dWFsIHJlcXVlc3QsIHdoYXRldmVyLiAgV2hlbiBzd2l0Y2hpbmcgZnJvbQ0KQsK5cyB2aWRlbyB0 byBDwrlzIHZpZGVvLCB0aGUgZm9sbG93aW5nIGhhcHBlbnM6DQoNCjEuIEluLWJhbmQgc2lnbmFs aW5nIMKzZnJlZXplIHBpY3R1cmUgcmVxdWVzdMKyIGluc2VydGVkIGJ5IHRoZSBNQ1UgaW50byB0 aGUNCmJpdHN0cmVhbSBmb3J3YXJkZWQgdG8gQS4gIFRoaXMgZnJlZXplcyB0aGUgZGlzcGxheSAo dGhvdWdoIG5vdA0KbmVjZXNzYXJpbHkgdGhlIGRlY29kaW5nKSBvZiB0aGUgYml0c3RyZWFtLg0K Mi4gTUNVIHNlbmRzIGZ1bGwgaW50cmEgcmVxdWVzdCB0byBlbmRwb2ludCBBLCB1c2luZyBhIHNp Z25hbGluZyBwcm90b2NvbC4NCk1lYW53aGlsZSwgaXQgY29udGludWVzIHRvIGZvcndhcmQgYWxs IHRoZSBiaXRzdHJlYW1zIGFzIHVzdWFsLiAgU2VydmljZQ0KdG8gZW5kcG9pbnRzIEIsIEMsIGFu ZCBEIGNvbnRpbnVlIHVuaW50ZXJydXB0ZWQuDQozLiBJbiBzb21lIHN5c3RlbXMgc3VwcG9ydGlu ZyBkaXJ0eSByZWZyZXNoIHBvaW50cywgdGhlIE1DVSBzdGFydHMNCmZvcndhcmRpbmcgYml0c3Ry ZWFtIEMgdG8gQSwgcmVzdWx0aW5nIGluIGdhcmJhZ2UgKHVudGlsIHRoZSBkaXJ0eSByZWZyZXNo DQpoYXMgY2xlYW5lZCB1cCB0aGUgcGljdHVyZS4gIFRoZSBnYXJiYWdlIGlzIGx1Y2tpbHkgbm90 IGRpc3BsYXllZCwgdGhhbmtzDQp0byB0aGUgZnJlZXplIHJlcXVlc3QuICBJbiBvdGhlciBzeXN0 ZW1zLCB0aGUgTUNVIHdhaXRzIGZvciBhbiBpbnRyYQ0KcGljdHVyZSBmcm9tIEEuDQo0LiBBcyBz b29uIGFzIHRoZSBNQ1Uga25vd3MgdGhhdCB0aGUgcGljdHVyZSBidWZmZXIgaW4gcmVjZWl2aW5n IGVuZHBvaW50DQpBIGhhcyBiZWVuIGNsZWFuZWQgdXAgKHRob3VnaCBpbnRyYSwgb3IgZGlydHkg cmVmcmVzaCksIGl0DQpzZW5kc+KAuS10eXBpY2FsbHkgdmlhIGEgc2lnbmFsaW5nIHByb3RvY29s IGxpa2UgSC4yNDUtLWEgZnJlZXplLXJlbGVhc2UuDQpBdCB0aGF0IHBvaW50LCBlbmRwb2ludCBB IHN0YXJ0cyBkaXNwbGF5aW5nIGFnYWluLg0KDQpUaGUgZnJlZXplIHJlcXVlc3QgaXMgaW4gdGhl IEgueHh4IHNlcmllcyBzdGFuZGFyZHMgYW4gU0VJIG1lc3NhZ2UuICBJbg0KSC4yNjEsIGl0IGlz IGEgYml0IGluIHRoZSB0aGUgcGljdHVyZSBoZWFkZXIuICBUaGUgcmVhc29uIGlzIHRoYXQgdGhl DQpmcmVlemUgcmVxdWVzdCBoYXMgdG8gYmUgZGVhbHQgd2l0aCBzeW5jaHJvbm91c2x5IHdpdGgg dGhlIGJpdHN0cmVhbSAob24gYQ0KcGVyIHBpY3R1cmUgZ3JhbnVsYXJpdHkpIHNvIHRvIGF2b2lk IGRpc3BsYXlpbmcgZ2FyYmFnZS4gIFRoZQ0KZnJlZXplLXJlbGVhc2UsIE9UT0gsIGNhbiBiZSBp biB0aGUgc2lnbmFsaW5nLCBiZWNhdXNlIGl0IGRvZXMgbm90IG1hdHRlcg0Kb3Zlcmx5IG11Y2gg d2hlbiB0aGUgcGljdHVyZSBpcyByZWxlYXNlZC0tZmFzdGVyIGlzIGJldHRlciBmcm9tIGFuIHVz ZXINCmV4cGVyaWVuY2Ugdmlld3BvaW50LCBidXQgdGhlIGZyZWV6ZSBvbmx5IGFmZmVjdHMgdGhl IG9uZSBkZWNvZGluZw0KZW5kcG9pbnQgdGhhdCBoYXMgZGVjaWRlZCBpdCB3YW50cyB0byBzZWUg c29tZXRoaW5nIGVsc2UsIHNvIGxldCB0aGlzIG9uZQ0Kc3VmZmVyIHRoZSBjb25zZXF1ZW5jZXMg KHJlc3VsdGluZyBmcm9tIGRlbGF5IGluIHRoZSBzaWduYWxpbmcpLg0KDQpUaGlzIGlzIHdoeSBw cmV0dHkgbXVjaCBhbGwgcHJvZmlsaW5nIHNwZWNzIGluIHRoZSB2aWRlbyBjb25mZXJlbmNpbmcN CmluZHVzdHJ5IHJlcXVpcmUgZnJlZXplIHJlcXVlc3QgdG8gYmUgc3VwcG9ydGVkIGluIHRoZSB2 aWRlbyBiaXRzdHJlYW0sDQphbmQgaXQgaXMgYWxzbyB3aHkgaXQgaXMgYXZhaWxhYmxlIGluIElU VSBhbmQgTVBFRyBzcGVjcyBzaW5jZQ0Kc3RhbmRhcmRpemVkIHZpZGVvIGNvbXByZXNzaW9uIHdh cyBkZXZlbG9wZWQuDQoNCk9uZSBjb3VsZCBhcmd1ZSB0aGF0IHB1cmUgdmlkZW8gc3dpdGNoaW5n IE1DVXMgYXJlIGEgdGhpbmcgb2YgdGhlIHBhc3QsDQphbmQgSSB3b3VsZCBtb3N0bHkgY29uY3Vy LiAgSG93ZXZlciwgaW4gdGhlIGNvbnRleHQgb2YgbGFyZ2UgdmlkZW8NCmNvbmZlcmVuY2VzIChk b3plbnMgb3IgaHVuZHJlZHMgb2YgcGFydGljaXBhbnRzKSwgYW5kIGFsc28gb24gc3lzdGVtcyB3 aXRoDQpsaW1pdGVkIHNjcmVlbiByZWFsLWVzdGF0ZSwgdmlkZW8gc3dpdGNoaW5nIGNvbnRpbnVl cyB0byBiZSByZXF1aXJlZC4NCldpdGggcmVzcGVjdCB0byBzdGF0ZS1vZi10aGUtYXJ0IHRlY2hu b2xvZ2llcywgdGhlIGFkdmVudCBvZiBzZWxlY3RpdmUNCmZvcndhcmRpbmcgdW5pdHMgYW5kIGxh eWVyZWQgY29kaW5nIGFsc28gcmVxdWlyZXMgZnJlZXplIHJlcXVlc3RzIChpbiB0aGUNCmVuaGFu Y2VtZW50IGxheWVyKSBmb3Igc2ltaWxhciByZWFzb25zIGFzIGRlc2NyaWJlZCBhYm92ZS4NCg0K DQo+DQo+DQo+T24gMTEvMjUvMTQsIDE1OjMzLCAiQWRhbSBSb2FjaCIgPGFkYW1Abm9zdHJ1bS5j b20+IHdyb3RlOg0KPg0KPj5JJ3ZlIHVwZGF0ZWQgdGhlIGRyYWZ0LWlldGYtcnRjd2ViLXZpZGVv IGJhc2VkIG9uIHRoZSBtaW51dGVzIGZyb20NCj4+SGF3YWlpLiBOb3cgdGhhdCB3ZSBoYXZlIGEg Y2xlYXIgcGF0aCB0byBzdWNjZXNzLCBJJ2QgbGlrZSB0byBnZXQgdGhlDQo+PmRvY3VtZW50IGZp bmFsaXplZCBhbmQgcHVibGlzaGVkIGFzIHF1aWNrbHkgYXMgcG9zc2libGUuIFRoaXMgbWVhbnMg SQ0KPj5uZWVkIHlvdXIgZmVlZGJhY2sgb24gdGhlIHJlbWFpbmluZyBvcGVuIGlzc3VlcyAoMSwg NCwgYW5kIDUsIGJlbG93KS4gSWYNCj4+eW91IGFyZSBDQ2VkIG9uIHRoaXMgbWFpbCwgaXQncyBi ZWNhdXNlIHlvdSB0b29rIGFuIGFjdGlvbiBpdGVtIGluDQo+Pkhhd2FpaSwgYW5kIEknbSB3YWl0 aW5nIHRvIGhlYXIgYmFjayBmcm9tIHlvdS4NCj4+DQo+Pk5ldyB2ZXJzaW9uOiBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXZpZGVvLw0KPj5EaWZmOiBo dHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ0Y3dlYi12aWRl by0wMy50eHQNCj4+X19fXw0KPj4NCj4+QWN0aW9uIGl0ZW0gZm9yIEhhcmFsZCBBbHZlc3RyYW5k IGZyb20gdGhlIG1pbnV0ZXM6DQo+Pj4gTW8gWmFuYXR5OiBBbiBJQU5BIHJlZ2lzdGVyZWQgaGVh ZGVyIHdpdGggcmVmZXJlbmNlIHRvIDNHUFAgZG9jdW1lbnQuDQo+Pj4gQ29kZWMgc3BlY2lmaWMg bWVjaGFuaXNtIHdheSBvZiBkb2luZyB0aGlzLg0KPj4+IEhhcmFsZDogV2lsbCBzZW5kIHNvbWUg c3VnZ2VzdGlvbnMgb24gZG9pbmcgdGhpcy4NCj4+DQo+PkFjdGlvbiBpdGVtIGZvciBCZXJuYXJk IEFib2JhIGFuZCBTdGVwaGFuIFdlbmdlcjogY29sbGVjdCBsaXN0IG9mIEguMjY0DQo+PlNFSSBt ZXNzYWdlcyB3ZSB3YW50IHRvIGNhbGwgb3V0IGFzIE1VU1QgYW5kL29yIFNIT1VMRC4NCj4+X19f Xw0KPj4NCj4+T3BlbiBJc3N1ZSAxOiBJZiB5b3UgZG9uJ3Qgd2FudCBzUkdCIHRvIGJlIHRoZSBk ZWZhdWx0IGNvbG9yIHNwYWNlLCBzYXkNCj4+c29tZXRoaW5nIG5vdy4NCj4+DQo+Pk9wZW4gSXNz dWUgMiAoY2xvc2VkKTogVG9vayAic2NyZWVuIHNvdXJjZSB2aWRlbyBtZXRhZGF0YSIgaXNzdWUg b3V0IG9mDQo+PnRoZSBkb2N1bWVudCwgYXMgdGhpcyBpcyBhbiBSVFAgaXNzdWUsIG5vdCBhIGNv ZGVjIGlzc3VlLg0KPj4NCj4+T3BlbiBJc3N1ZSAzIChjbG9zZWQpOiBOZXcgdGV4dCBpbiAic3Ry ZWFtIG9yaWVudGF0aW9uIiBzZWN0aW9uIGNhbGxpbmcNCj4+b3V0IHZhcmlvdXMgTVVTVC9TSE9V TEQvTUFZIGxldmVscywgYmFzZWQgb24gd2hhdCBJIHRvb2sgYXdheSBmcm9tIHRoZQ0KPj5taWMg aW4gSGF3YWlpLiBJZiB5b3UgY2FyZSBhYm91dCB0aGlzLCBkb3VibGUtY2hlY2sgdGhhdCB0aGVz ZSBhcmUgd2hhdA0KPj55b3UgZXhwZWN0IHRoZW0gdG8gYmUuDQo+Pg0KPj5PcGVuIElzc3VlIDQ6 IEluIFRvcm9udG8sIGl0IHdhcyBzdWdnZXN0ZWQgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIHNwZWNp ZnkNCj4+c3VwcG9ydCBmb3IgImJpbGluZWFyIiBhbmQgIm5vbmUiIGZpbHRlciBzdHlsZXMsIHNp bmNlIHRoZXkncmUgYWxyZWFkeQ0KPj5yZXF1aXJlZC4gSSdtIGhhcHB5IHRvIHJlbW92ZSB0aGUg c3RhdGVtZW50IGlmIHNvbWVvbmUgY2FuIHBvaW50IG1lIHRvDQo+PndoZXJlIHRoaXMgaXMgb3Ro ZXJ3aXNlIG1hbmRhdGVkLiBJZiBubyBvbmUgY29tZXMgZm9yd2FyZCB3aXRoIGENCj4+Y2l0YXRp b24sIEknbSBnb2luZyB0byBjbG9zZSB0aGlzIG9wZW4gaXNzdWUgYXMgaGFybWxlc3MuDQo+Pg0K Pj5PcGVuIElzc3VlIDU6IFdhaXRpbmcgb24gZmVlZGJhY2sgZnJvbSBCZXJuYXJkIGFuZCBTdGVm YW4sIGFzIGRldGFpbGVkDQo+PmFib3ZlLg0KPj4NCj4+T3BlbiBJc3N1ZSA2IChjbG9zZWQpOiBQ bGVhc2Ugc2VlIHRoZSB0ZXh0IGluIHNlY3Rpb24gNSBvZiB0aGUgbmV3DQo+PmRvY3VtZW50LCB3 aGljaCB0cmFja3MgdGhlIHRleHQgZnJvbSB0aGUgTm92ZWwgUHJvcG9zYWwgZW1haWwgcHJldHR5 DQo+PmNsb3NlbHkuDQo+Pg0KPj4vYQ0KPg0KDQo= From nobody Tue Nov 25 21:32:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238361A88A6 for ; Tue, 25 Nov 2014 21:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoN7hrJPAg2X for ; Tue, 25 Nov 2014 21:32:42 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0D11A8750 for ; Tue, 25 Nov 2014 21:32:41 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 05:32:17 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 05:32:17 +0000 From: Stephan Wenger To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document Thread-Index: AQHQCQhLH8Rvof4WtkWeNp84Mnvyvpxx2CWAgACInQD//3uugA== Date: Wed, 26 Nov 2014 05:32:16 +0000 Message-ID: References: <547511DB.5050100@nostrum.com> <54756452.90105@mozilla.com> In-Reply-To: <54756452.90105@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1273; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1273; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(199003)(51704005)(52604005)(479174003)(101416001)(120916001)(31966008)(50986999)(76176999)(122556002)(77096003)(77156002)(54356999)(62966003)(21056001)(20776003)(64706001)(36756003)(66066001)(92566001)(92726001)(86362001)(19580405001)(19580395003)(40100003)(46102003)(107046002)(107886001)(2501002)(97736003)(2656002)(87936001)(4396001)(15975445006)(95666004)(105586002)(99286002)(106356001)(106116001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1273; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <81F66D2A9B335D49B92BF139AE72DCD5@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IvW_Pv4FaDp5HiyAcE_J44oSF9w Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Nov 2014 05:32:43 -0000 Indeed. Thanks for spotting this. Stephan (We could add a whole lot more about transfer characteristics, but perhaps this doc is not really concerned with those details.) On 11/25/14, 21:25, "Timothy B. Terriberry" wrote: >Stephan Wenger wrote: >> 3. Section 3: Possibly missing: mention that the video scan pattern for >> both VP8 and H.264 is YCrCb 4:2:0. > >You mean Y'CbCr, no? > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Nov 26 00:18:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC30A1A0045 for ; Wed, 26 Nov 2014 00:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIWQ3aFrhU6w for ; Wed, 26 Nov 2014 00:18:24 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35371A0030 for ; Wed, 26 Nov 2014 00:18:23 -0800 (PST) Received: from [192.168.1.200] (p548190F0.dip0.t-ipconnect.de [84.129.144.240]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A678C1C1622BD; Wed, 26 Nov 2014 09:18:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <547392A4.4080309@nostrum.com> Date: Wed, 26 Nov 2014 09:18:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547392A4.4080309@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uiCqLEXqru9vyjb9ha0tYQy_xhs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel (Issue 5) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Nov 2014 08:18:26 -0000 On 24 Nov 2014, at 21:18, Adam Roach wrote: > I promised to propose a minor fix to the RFC 2119 use for the Issue 5 = resolution discussed in Hawaii. The text on the slide was: >=20 >> The message orientation of SCTP is used to preserve the message = boundaries of >> user messages. Therefore, no more than one message MUST be put into = an SCTP >> user message. If the deprecated PPID-based fragmentation and = reassembly is not >> used, exactly one message MUST be put into an SCTP user message. >=20 > I propose reformulating as: >=20 > The message-orientation of SCTP is used to preserve the message = boundaries of user messages. Therefore, senders MUST NOT put more than = one application message into an SCTP message. Unless the deprecated = PPID-based fragmentation and reassembly is used, the sender MUST include = exactly one application message in each SCTP message. I don't know what an SCTP message is. Most likely I would guess that it = is an SCTP packet. Using that interpretation, your suggested text forbids bundling of data chunks = and sending user messages larger than the MTU minus headers. That is why I used "user message", the entity which is transported by = SCTP to the peer with preservation of message boundaries. This is also used in RFC 4960. So what about: The message-orientation of SCTP is used to preserve the message = boundaries of user messages. Therefore, senders MUST NOT put more than = one application message into an SCTP user message. Unless the = deprecated PPID-based fragmentation and reassembly is used, the sender = MUST include exactly one application message in each SCTP user message. OK? >=20 > One of the things that flummoxed me a bit here in trying to rework the = language is that "message" in the original formulation meant two = different things: (1) an SCTP message (as in RFC4960) and (2) an = application message (as in http://w3c.github.io/webrtc-pc/). I suggest = that the document should include a terminology section that clearly lays=20= It was intended to be an user message. Fix in the above suggested text. Best regards Michael > out these two concepts with clearly-defined terms, citing these two = specifications, and that the remainder of the document is rigorously = updated to reflect that terminology (i.e. the term "message" should = never appear by itself, only prefixed with an adjective to make it clear = which of these two messages is meant). >=20 > /a > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Nov 26 01:16:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895101A7004 for ; Wed, 26 Nov 2014 01:16:03 -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 qM7bStkGeYbD for ; Wed, 26 Nov 2014 01:16:00 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D39F1A0056 for ; Wed, 26 Nov 2014 01:16:00 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so11757924wiv.11 for ; Wed, 26 Nov 2014 01:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=h+LY0MJ8vxVBArI+86CQLOktE09avacjwBQ0DH3IzCk=; b=iH2O/PPyUvmnt35kIYLZY0OjO/8ZFfgHV0kyVmqYSMGfoGh5tkrGchEsLAGcHNRchG g2LKpMk4506Qtw0JLc8qhZyDr1V0Sn4RjbmBxC1ZkxnkzDxPRzWl1zsZNcFh9BqCXq3v PkRpDT6HL4OT0Gvd+j1yPwm/tVYYCiIefB4216CdZNzWeDR59g2VeX7ewi2oYN1DtbPS rKHfF+BFzZuimel7hrq3DoBUcHy+4tXK9s/BnX4Rbb0CdIrQmfHxFFm5JvvqBR4IJmhV u5Z7xGKEDVgcrVt/pT+hJQ8jaEqKqhvoZKe98MahOs9LyWqo9t/stlnHsLPPLndFQl4R TwQw== X-Received: by 10.180.73.7 with SMTP id h7mr39616074wiv.83.1416993359150; Wed, 26 Nov 2014 01:15:59 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id wa10sm5512378wjc.8.2014.11.26.01.15.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Nov 2014 01:15:58 -0800 (PST) Message-ID: <54759A4C.6020806@gmail.com> Date: Wed, 26 Nov 2014 10:15:56 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adam Roach , "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> In-Reply-To: <547511DB.5050100@nostrum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JQc8ii6zTsYPcyBT5gzs0WcnP7E Cc: Harald Alvestrand Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 09:16:03 -0000 IMO, mandatory codec revisiting has to be done for all webrtc entities. Why not doing it for web browsers when one codec is proved to be royalty free? Are the specs going to force any browser flavour to pay many forever? Btw, from the minutes sent on the mailing list, I understood that the decision is to be confirmed on the list (which is the norm for IETF anyhow). Unless I missed some messages, I haven't seen any discussion here following the last IETF meeting, exposing the conclusion of the meeting and asking to have a decision on that. Daniel On 26/11/14 00:33, Adam Roach wrote: > I've updated the draft-ietf-rtcweb-video based on the minutes from > Hawaii. Now that we have a clear path to success, I'd like to get the > document finalized and published as quickly as possible. This means I > need your feedback on the remaining open issues (1, 4, and 5, below). > If you are CCed on this mail, it's because you took an action item in > Hawaii, and I'm waiting to hear back from you. > > New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ > Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt > ____ > > Action item for Harald Alvestrand from the minutes: >> Mo Zanaty: An IANA registered header with reference to 3GPP document. >> Codec specific mechanism way of doing this. >> Harald: Will send some suggestions on doing this. > > Action item for Bernard Aboba and Stephan Wenger: collect list of > H.264 SEI messages we want to call out as MUST and/or SHOULD. > ____ > > Open Issue 1: If you don't want sRGB to be the default color space, > say something now. > > Open Issue 2 (closed): Took "screen source video metadata" issue out > of the document, as this is an RTP issue, not a codec issue. > > Open Issue 3 (closed): New text in "stream orientation" section > calling out various MUST/SHOULD/MAY levels, based on what I took away > from the mic in Hawaii. If you care about this, double-check that > these are what you expect them to be. > > Open Issue 4: In Toronto, it was suggested that we don't need to > specify support for "bilinear" and "none" filter styles, since they're > already required. I'm happy to remove the statement if someone can > point me to where this is otherwise mandated. If no one comes forward > with a citation, I'm going to close this open issue as harmless. > > Open Issue 5: Waiting on feedback from Bernard and Stefan, as detailed > above. > > Open Issue 6 (closed): Please see the text in section 5 of the new > document, which tracks the text from the Novel Proposal email pretty > closely. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Wed Nov 26 06:26:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0858F1A012D for ; Wed, 26 Nov 2014 06:26:01 -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 6ltvRM_s1Tue for ; Wed, 26 Nov 2014 06:25:58 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C2B1A007B for ; Wed, 26 Nov 2014 06:25:58 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so2553000lbv.28 for ; Wed, 26 Nov 2014 06:25:56 -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=LJyDZ/zP2cecCrZMrMnSEMjI9Z32+SK3prO/LaZSi5s=; b=EPtK+gcb9k4BEW81oQckx+xpRsNSjeS/cf4qeW3V0GqmaIZJ9e2fARtvsJjsvx6ufk MIsAtu/h/AtLOthtA6O7C/T9a682ShDRT/i5XCaqjYz8svXWwmrzfMyH1o+e5xj1KpiC g8trONrAAv2XCrKmp/wKAMrlr9v82EicHrteZOjAELs1qbrmKYm6SSIS1IxesdXu6MNQ NbiTSQOAPZlIUHMtej5aHGoGm3icUc8Y4nhr+rwXZhFZKnSgtofd898qEQi7lOxN0wB+ sJD91rvxcPsZfjPOScTzZ+VOuHtAwjw4seBDmexLr9b7XpMQ8cIQJD5aZauwKVD9elnk D4pA== MIME-Version: 1.0 X-Received: by 10.152.9.7 with SMTP id v7mr34325932laa.40.1417011956651; Wed, 26 Nov 2014 06:25:56 -0800 (PST) Received: by 10.25.205.201 with HTTP; Wed, 26 Nov 2014 06:25:56 -0800 (PST) In-Reply-To: <54759A4C.6020806@gmail.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> Date: Wed, 26 Nov 2014 15:25:56 +0100 Message-ID: From: Victor Pascual Avila To: Daniel-Constantin Mierla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uVacYBbbf1BQP1PGpsQJB_Iy2gs Cc: "rtcweb@ietf.org" , Harald Alvestrand Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Nov 2014 14:26:01 -0000 On Wed, Nov 26, 2014 at 10:15 AM, Daniel-Constantin Mierla wrote: > IMO, mandatory codec revisiting has to be done for all webrtc entities. > Why not doing it for web browsers when one codec is proved to be royalty > free? Are the specs going to force any browser flavour to pay many foreve= r? Agree > Btw, from the minutes sent on the mailing list, I understood that the > decision is to be confirmed on the list (which is the norm for IETF > anyhow). Unless I missed some messages, I haven't seen any discussion > here following the last IETF meeting, exposing the conclusion of the > meeting and asking to have a decision on that. Agree -Victor > On 26/11/14 00:33, Adam Roach wrote: >> I've updated the draft-ietf-rtcweb-video based on the minutes from >> Hawaii. Now that we have a clear path to success, I'd like to get the >> document finalized and published as quickly as possible. This means I >> need your feedback on the remaining open issues (1, 4, and 5, below). >> If you are CCed on this mail, it's because you took an action item in >> Hawaii, and I'm waiting to hear back from you. >> >> New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ >> Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-video-03.t= xt >> ____ >> >> Action item for Harald Alvestrand from the minutes: >>> Mo Zanaty: An IANA registered header with reference to 3GPP document. >>> Codec specific mechanism way of doing this. >>> Harald: Will send some suggestions on doing this. >> >> Action item for Bernard Aboba and Stephan Wenger: collect list of >> H.264 SEI messages we want to call out as MUST and/or SHOULD. >> ____ >> >> Open Issue 1: If you don't want sRGB to be the default color space, >> say something now. >> >> Open Issue 2 (closed): Took "screen source video metadata" issue out >> of the document, as this is an RTP issue, not a codec issue. >> >> Open Issue 3 (closed): New text in "stream orientation" section >> calling out various MUST/SHOULD/MAY levels, based on what I took away >> from the mic in Hawaii. If you care about this, double-check that >> these are what you expect them to be. >> >> Open Issue 4: In Toronto, it was suggested that we don't need to >> specify support for "bilinear" and "none" filter styles, since they're >> already required. I'm happy to remove the statement if someone can >> point me to where this is otherwise mandated. If no one comes forward >> with a citation, I'm going to close this open issue as harmless. >> >> Open Issue 5: Waiting on feedback from Bernard and Stefan, as detailed >> above. >> >> Open Issue 6 (closed): Please see the text in section 5 of the new >> document, which tracks the text from the Novel Proposal email pretty >> closely. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Victor Pascual =C3=81vila From nobody Wed Nov 26 08:32:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B191A0195; Wed, 26 Nov 2014 08:32:16 -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 KN06Uzvt2q83; Wed, 26 Nov 2014 08:32:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AAE1A00FC; Wed, 26 Nov 2014 08:32:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141126163215.6289.51533.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 08:32:15 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bn6DZKWwjmmdqqIZ9YeOOrtNUvc Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-21.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 16:32:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-21.txt Pages : 45 Date : 2014-11-26 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 26 08:47:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37FD1A014C for ; Wed, 26 Nov 2014 08:47:39 -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 y8HT3di9EoA7 for ; Wed, 26 Nov 2014 08:47:38 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CA91A0149 for ; Wed, 26 Nov 2014 08:47:38 -0800 (PST) Received: from [130.209.247.112] (port=49325 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xtfke-0004Lc-6S for rtcweb@ietf.org; Wed, 26 Nov 2014 16:47:36 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <20141126163215.6289.51533.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 16:47:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141126163215.6289.51533.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YFrztcyNEvmPVhvBc3GBPC6qiaM Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-21.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 16:47:40 -0000 The changes in this version are as follows: - In Section 4.3, clarify reference to draft-ietf-rtcweb-audio and add = reference draft-ietf-rtcweb-video for mandatory to implement codec and = payload formats. Clarify that other codecs and payload formats MAY be = implemented, and that all payload formats MUST be signalled before use. - In Section 5.2.5, note that the CVO header extension MUST be = implemented as described in Section 4 of draft-ietf-rtcweb-video. - In Section 4.1, note that the RTCP SDES MID item MUST be implemented = if the SDP bundle extension is used. In Section 5.2.4, note that the RTP = MID header extension MUST be implemented if the SDP bundle extension is = used. - In Sections 5.2.1, 5.2.2, and 5.2.3, clarify that the header extension = needs to be negotiated before it can be used. - In Section 5.2.2, clarify that the RFC 6464 client-to-mixer audio = level header extension MUST be implemented, based on discussion in = IETF91. - Update Section 6.2 on FEC to refer to draft-uberti-rtcweb-fec. Colin On 26 Nov 2014, at 16:32, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Authors : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-21.txt > Pages : 45 > Date : 2014-11-26 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-21 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-21 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ From nobody Wed Nov 26 09:09:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7CD1A0149 for ; Wed, 26 Nov 2014 09:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ctp6j64oIkB for ; Wed, 26 Nov 2014 09:09:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAE51A0173 for ; Wed, 26 Nov 2014 09:09:11 -0800 (PST) Received: from Orochi.local ([38.100.151.157]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAQH95Xv002558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2014 11:09:06 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [38.100.151.157] claimed to be Orochi.local Message-ID: <5476092D.4010406@nostrum.com> Date: Wed, 26 Nov 2014 11:09:01 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: miconda@gmail.com, "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> In-Reply-To: <54759A4C.6020806@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aoi4U5dPxxFeyBi708WZNL8B4fw Cc: Harald Alvestrand Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 26 Nov 2014 17:09:16 -0000 On 11/26/14 03:15, Daniel-Constantin Mierla wrote: > IMO, mandatory codec revisiting has to be done for all webrtc entities. > Why not doing it for web browsers when one codec is proved to be royalty > free? The rationale here is browser accommodation for very constrained "WebRTC compatible" devices, which will most typically be concerned with browser interoperation. The example that's been tossed around in this space is the "WebRTC doorbell" -- when someone rings the bell, you navigate to its interface using WebRTC, and stream an image from a small, embedded camera. In these kinds of very-low-cost devices, you're going to likely see hardware video encoding (e.g. do a web search for NVS2200), which will likely be one codec or another, but not both. The goal is continued browser support for such devices in perpetuity. > Btw, from the minutes sent on the mailing list, I understood that the > decision is to be confirmed on the list (which is the norm for IETF > anyhow). Unless I missed some messages, I haven't seen any discussion > here following the last IETF meeting, exposing the conclusion of the > meeting and asking to have a decision on that. Sure. I'll leave it to the chairs to cross their t's and dot their i's how they see fit, but it's pretty clear which direction the wind is blowing. Frankly, if I were chair [1], I would consider the on-list conversation from November 9th through November 15th (67 messages in total) to be sufficient ratification for the proposal, and the in-person discussion simply a final punctuation mark on this long-languishing chapter. If the on-list and in-person conversations had been pointed different directions from each other, I'd definitely be holding off trying to get the draft language nailed down. But they weren't, so I'm not. /a _____ [1] I'm not second-guessing what the chairs are doing here, mind you -- I'm just pointing out that they appear to be choosing their actions out of an abundance of caution rather than absolute necessity. From nobody Thu Nov 27 02:37:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D0F1A88C7 for ; Thu, 27 Nov 2014 02:37:49 -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 8NJDh740uVxm for ; Thu, 27 Nov 2014 02:37:47 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF231A888E for ; Thu, 27 Nov 2014 02:37:46 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so7847501wiw.10 for ; Thu, 27 Nov 2014 02:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Sukoy4Lc5KmO6VHTeB8NwW5OK7D1+RDUmBKv7oxmJ6U=; b=eb24gyZdmv85RYQQRv09TCN6cXmurDvuCXjhNueibZ2xd6bm5b/xUmbC0Z4xJXcvoi qee7JiSNQMUOwN77KWpr642ryR9H+a9vrtRcaTyP+hF/xjmtbpO+vw1AXmG7lpVLbaT7 eXnDoOyth7YhWVem9OZtua4xPD1VQH+a+9XqufsmJ6QRdxPastUgcH+SMYLjAG5gflnq BSBHg4z0UvJT7JgWFxRiX7uT4fk8095gUimayMdUedjogf3uOSdQYjGDmNtW3DavLqMN wM4AnRy6cgTteAKf7H51a2HJ06eOaJhC7Y4tn+j8lda4Howonqh4x8zsD6MjI/oeQAoa dOfQ== X-Received: by 10.180.90.144 with SMTP id bw16mr51020410wib.50.1417084665660; Thu, 27 Nov 2014 02:37:45 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ud1sm10122979wjc.7.2014.11.27.02.37.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 02:37:44 -0800 (PST) Message-ID: <5476FEF6.6000807@gmail.com> Date: Thu, 27 Nov 2014 11:37:42 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adam Roach , "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> In-Reply-To: <5476092D.4010406@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Y91MDkbOy9H8o-PVeNk0Kh7x1fM Cc: Harald Alvestrand Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 10:37:49 -0000 On 26/11/14 18:09, Adam Roach wrote: > On 11/26/14 03:15, Daniel-Constantin Mierla wrote: >> IMO, mandatory codec revisiting has to be done for all webrtc entities. >> Why not doing it for web browsers when one codec is proved to be royalty >> free? > > The rationale here is browser accommodation for very constrained > "WebRTC compatible" devices, which will most typically be concerned > with browser interoperation. The example that's been tossed around in > this space is the "WebRTC doorbell" -- when someone rings the bell, > you navigate to its interface using WebRTC, and stream an image from a > small, embedded camera. In these kinds of very-low-cost devices, > you're going to likely see hardware video encoding (e.g. do a web > search for NVS2200), which will likely be one codec or another, but > not both. > > The goal is continued browser support for such devices in perpetuity. That is the decision of a business entity to go for a technology that can add extra costs to the user of the product. I couldn't find that as a guiding rule for IETF versus the rule of preferring technologies with no IPR. Similar decisions were taken by ITU/GSMA and cell phone manufacturers with AMR or other things, which haven't impacted any decision on WebRTC specs (as it should be). > >> Btw, from the minutes sent on the mailing list, I understood that the >> decision is to be confirmed on the list (which is the norm for IETF >> anyhow). Unless I missed some messages, I haven't seen any discussion >> here following the last IETF meeting, exposing the conclusion of the >> meeting and asking to have a decision on that. > > Sure. I'll leave it to the chairs to cross their t's and dot their i's > how they see fit, but it's pretty clear which direction the wind is > blowing. Frankly, if I were chair [1], I would consider the on-list > conversation from November 9th through November 15th (67 messages in > total) to be sufficient ratification for the proposal, and the > in-person discussion simply a final punctuation mark on this > long-languishing chapter. > > If the on-list and in-person conversations had been pointed different > directions from each other, I'd definitely be holding off trying to > get the draft language nailed down. But they weren't, so I'm not. I didn't get the impression that was any clear conclusion on anything, including if this is the right proposal (e.g., there were voices arguing about inability to tailor open source browsers for particular needs, including form those that as some point welcomed the proposal) as well as what and how should be mandatory for what so ever form (terminology) of webrtc endpoints. Besides the well known group of interests jumping on stage with the 'yes', there were real concerns put on table that seems to be ignored. Moreover, your proposal with considering a past discussions for something that was not made clear as a decision making process to a sensitive subject, looks like changing the rules of the game after the match. Then, using the in-person meeting of a bunch of people in a far-end corner of the world (for most of the population) to end this subject, again, without a prior notification, definitely is not a transparent process, but more an obscure decision system, which I though it is not how IETF aims to work. Daniel > > /a > > _____ > [1] I'm not second-guessing what the chairs are doing here, mind you > -- I'm just pointing out that they appear to be choosing their actions > out of an abundance of caution rather than absolute necessity. -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Fri Nov 28 05:03:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3F81A1AD3 for ; Fri, 28 Nov 2014 05:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKDFiqgj6zHk for ; Fri, 28 Nov 2014 05:03:38 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF8F1A1AFB for ; Fri, 28 Nov 2014 05:03:37 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-e7-547872a6da25 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.44.29772.6A278745; Fri, 28 Nov 2014 14:03:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:03:34 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: IETF#91: Notes from 1st RTCWEB session Thread-Index: AdALC6+4hyPFqCLJRbuI4SCmIfNy1A== Date: Fri, 28 Nov 2014 13:03:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53EF61@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje7yoooQg877PBZzdj1gslj7r53d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MqYs7eBseDGbcaKS5c3sjcw/j3I2MXIySEh YCJx9Mk3NghbTOLCvfVgtpDAEUaJi4dTuxi5gOwljBL3O9cBJTg42AQsJLr/aYPUiAioS1x+ eIEdxGYWcJTY3beDCcQWFtCX2LpvIyNIuQjQ/O45PhDlehLfDzSBlbAIqEpc/LkI7AReAV+J y+tesoLYjEAnfD+1hglipLjErSfzmSBOE5BYsuc8M4QtKvHy8T9WCFtJ4seGSywgq5gF8iXu LE2HGCkocXLmE5YJjMKzkEyahVA1C0kVRImOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopR tDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMHYObvltsIPx5XPHQ4wCHIxKPLwFshUhQqyJZcWV uYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcbum6Hzf1NK9Mkvu3pSX iklwVmTztv2x6VBMg/CD8+UdCiYf38+8elnEa0sOX3j5Qqt5iq8dC468256S9Gz+p67Uk7vy jqxPM99Y/vXGzpRXHVY1n576Xz3wV91122KxCZXWogGLa2ak//+iddvS1u9O5Mmvc7er5i09 ZRo4/Su74S8rNuM5/5RYijMSDbWYi4oTAej2LDl+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RUoK1s8Rg2vEFcabE9MZqja4XQ0 Cc: "rtcweb-chairs@tools.ietf.org" Subject: [rtcweb] IETF#91: Notes from 1st RTCWEB session X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:03:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the 1st RTCWEB session. Regards, Christer ---------------- Topic:JSEP Draft: draft-ietf-rtcweb-jsep-08 Presenter: Eric Rescola Presentation of the updates in the latest version of the draft. m- line considerations: Indicated that the SDP fingerprint attribute will be used to indicate that = DTLS-SRTP is used. It was commented that the fingerprint attribute is currently optional in th= e SCTP-SDP draft. Indicated that it sounds like an error in the SCTP-SDP dr= aft. BUNDLE clarification: It was commented that a JavaScript application cannot request a browser to = not offer BUNDLE, in case it is known that the remote peer does not support= BUNDLE. Indicated that BUNDLE works with such peers, as BUNDLE will be dis= abled if not supported by the peer. BUNDLE/MUX policy (#91): Question whether we need to be able to explicitly specify usage of rtcp-mux= . Why can't the max-bundle option implicitly include usage of rtcp-mux? Ind= icated that it has previously been stated that one may want to do max BUNDL= E, but not use rtcp-mux. OUTCOME: ??? Value of {local/remote} description when closed (#88). OUTCOME: This belongs to the W3C spec. No need to say anything in the JSEP = draft. a=3Dssrc for a=3Drecvonly m=3D lines (#79): OUTCOME: The suggested proposal was not accepted. Some more thinking about = this is needed. Death of a one-way stream (#76) Indicated that we need a way to indicate, for a given m- line, "I am never = going to send media associated with this m- line again" and "I never want t= o receive media associated with this m- line again". Indicated that it has previously been agreed to bring the issue to MMUSIC, = but that has not yet happened. A volunteer is needed. OUTCOME: This issue needs to be brought to MMUSIC, but unclear who will bri= ng it. Signaling synchronization (#31): OUTCOME: If LS is not indicated, streams are synchronized if they share the= same CNAME value. Changing b=3D (#9): It was indicated that Magnus was supposed to produce text, and that a new v= olunteer is needed. However, it was unclear what the issue is. OUTCOME: Agreed to wait until Magnus comes back, as the issue will most lik= ely delay the JSEP draft. Topic:WebRTC Data Channels Draft: draft-ietf-rtcweb-data-channel Presenter: Salvatore Loreto Provided status update based on the IESG review. There are no DISCUSSes, bu= t some COMMENTs. Indicated that we need to decide whether to use DTLS 1.0 or DTLS 1.2. Indicated that DTLS 1.2 is not widely available at this stage. OUTCOME: - MUST support 1.0, SHOULD support latest version. - No objection to having a reference to RFC 6347. - We need to adjust the crypto suites (Cullen) Topic: WebRTC Terminology Draft: draft-ietf-rtcweb-overview Presenter: Harald Alvestrand The discussion focused on the split between a WebRTC browser and a WebRTC d= evice. It was indicated that "device" terminology is confusing. It was suggested to talk about "native applications" instead of "devices". It was suggested to simply talk about "non-browsers" instead of "devices". It was asked whether a browser plug-in, providing WebRTC JavaScript API fun= ctionality to a non-WebRTC browser, is considered a "browser" or a "device"= . The combination of the browser and the plug-in is considered a "browser". It was asked whether a non-JavaScript library, very similar to the WebRTC J= avaScript API, providing similar functionality, the WebRTC API to a non-Web= RTC browser, is considered a "browser" or a "device". OUTCOME: It was agreed to talk about "browsers" and "non-browsers", and the= next version of the draft will incorporate that terminology. Topic: Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy = in WebRTC Draft: draft-schwartz-rtcweb-return Presenter: Justin Uberti It was realized that very few people had read the draft. Half of the participants thought the draft should be adopted as a WG draft. OUTCOME: Further discussions on the list are needed, before a decision to a= dopt the draft can be made. Topic: WebRTC Gateways Draft: draft-alvestrand-rtcweb-gateways Presenter: Harald Alvestrand Indicated that gateways are not part of the core WebRTC architecture, but t= hey are never the less important in order to be able to achieve interoperab= ility between WebRTC devices and legacy devices and systems. Described how gateway are different from WebRTC browsers, related to securi= ty considerations, support of features (e.g. ICE), specific codecs etc. Indicated that it was previously agreed to add a section about gateway to t= he common overview document, rather than having a separate document. Indica= ted the minutes from the previous meeting indicate that having a separate d= ocument for gateway was the preferred way forward. OUTCOME: Further discussions on the list are needed, before a decision to a= dopt the draft can be made. --_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below are my notes from the 1st RTCWEB session.=

 

Regards,

 

Christer

 

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

 

 

Topic:JSEP

Draft: draft-ietf-rtcweb-jsep-08

Presenter: Eric Rescola

 

Presentation of the updates in the latest version of the draft.

 

 

m- line considerations:

 

Indicated that the SDP fingerprint attribute will be used to indicate th= at DTLS-SRTP is used.

 

It was commented that the fingerprint attribute is currently optional in= the SCTP-SDP draft. Indicated that it sounds like an error in the SCTP-SDP= draft.

 

 

BUNDLE clarification:

 

It was commented that a JavaScript application cannot request a browser = to not offer BUNDLE, in case it is known that the remote peer does not supp= ort BUNDLE. Indicated that BUNDLE works with such peers, as BUNDLE will be disabled if not supported by the peer.=

 

 

BUNDLE/MUX policy (#91):

 

Question whether we need to be able to explicitly specify usage of rtcp-= mux. Why can’t the max-bundle option implicitly include usage of rtcp= -mux? Indicated that it has previously been stated that one may want to do max BUNDLE, but not use rtcp-mux.

 

OUTCOME: ???

 

 

Value of {local/remote} description when closed (#88).

 

OUTCOME: This belongs to the W3C spec. No need to say anything in the JSEP draft.=

 

 

a=3Dssrc for a=3Drecvonly m=3D lines (#79):

 

OUTCOME: The suggested proposal was not accepted. Some more thinking about this i= s needed.

 

 

Death of a one-way stream (#76)

 

Indicated that we need a way to indicate, for a given m- line, “I = am never going to send media associated with this m- line again” and = “I never want to receive media associated with this m- line again”.

 

Indicated that it has previously been agreed to bring the issue to MMUSI= C, but that has not yet happened. A volunteer is needed.<= /p>

 

OUTCOME: This issue needs to be brought to MMUSIC, but unclear who will bring it.=

 

 

Signaling synchronization (#31):

 

OUTCOME: If LS is not indicated, streams are synchronized if they share the same = CNAME value.

 

 

Changing b=3D (#9):

 <= /u>

It was indicated that Magnus was supposed to produce text, and that a ne= w volunteer is needed. However, it was unclear what the issue is.

 

OUTCOME: Agreed to wait until Magnus comes back, as the issue will most likely de= lay the JSEP draft.

 

 

 

Topic:WebRTC Data Channels

Draft: draft-ietf-rtcweb-data-channel

Presenter: Salvatore Loreto

 

 

Provided status update based on the IESG review. There are no DISCUSSes,= but some COMMENTs.

 

Indicated that we need to decide whether to use DTLS 1.0 or DTLS 1.2.

 

Indicated that DTLS 1.2 is not widely available at this stage.

 

OUTCOME:

 

- MUST support 1.0, SHOULD support latest version.

- No objection to having a reference to RFC 6347.

- We need to adjust the crypto suites (Cullen)

 

 

 

Topic: WebRTC Terminology

Draft: draft-ietf-rtcweb-overview

Presenter: Harald Alvestrand

 

The discussion focused on the split between a WebRTC browser and a WebRT= C device. It was indicated that “device” terminology is confusi= ng.

 

It was suggested to talk about “native applications” instead= of “devices”.

 

It was suggested to simply talk about “non-browsers” instead= of “devices”.

 

It was asked whether a browser plug-in, providing WebRTC JavaScript API = functionality to a non-WebRTC browser, is considered a “browser”= ; or a “device”. The combination of the browser and the plug-in is considered a “browser”.

 

It was asked whether a non-JavaScript library, very similar to the WebRT= C JavaScript API, providing similar functionality, the WebRTC API to a non-= WebRTC browser, is considered a “browser” or a “device”.

 

OUTCOME: It was agreed to talk about “browsers” and “non-browse= rs”, and the next version of the draft will incorporate that terminol= ogy.

 

 

 

Topic: Recursively Encapsulated TURN (RETURN) for Co= nnectivity and Privacy in WebRTC

Draft: draft-schwartz-rtcweb-return

Presenter: Justin Uberti

 

It was realized that very few people had read the draft.

 

Half of the participants thought the draft should be adopted as a WG dra= ft.

 

OUTCOME: Further discussions on the list are needed, before a decision to adopt t= he draft can be made.

 

 

 

Topic: WebRTC Gateways

Draft: draft-alvestrand-rtcweb-gateways

Presenter: Harald Alvestrand

 

Indicated that gateways are not part of the core WebRTC architecture, bu= t they are never the less important in order to be able to achieve interope= rability between WebRTC devices and legacy devices and systems.

 

Described how gateway are different from WebRTC browsers, related to sec= urity considerations, support of features (e.g. ICE), specific codecs etc.<= o:p>

 

Indicated that it was previously agreed to add a section about gateway t= o the common overview document, rather than having a separate document. Ind= icated the minutes from the previous meeting indicate that having a separate document for gateway was the preferred way forward.=

 

OUTCOME: Further discussions on the list are needed, before a decision to adopt t= he draft can be made.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D53EF61ESESSMB209erics_-- From nobody Fri Nov 28 05:19:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C1A1A1B5E; Fri, 28 Nov 2014 05:19:04 -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 xZTBOZSu3j8n; Fri, 28 Nov 2014 05:19:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 979EB1A1A66; Fri, 28 Nov 2014 05:19:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141128131903.18180.87191.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 05:19:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZNEGFn1Ij4bWTE-ewBgE4aXmIYw Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:19:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-13.txt Pages : 22 Date : 2014-11-28 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 28 05:35:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCF21A1A73 for ; Fri, 28 Nov 2014 05:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHitdT5Xu4Js for ; Fri, 28 Nov 2014 05:35:29 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id AEBE11A1A6C for ; Fri, 28 Nov 2014 05:35:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 778B77C0951 for ; Fri, 28 Nov 2014 14:35:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dol50MlX3Kro for ; Fri, 28 Nov 2014 14:35:26 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:30cd:102:b31:8dfd] (unknown [IPv6:2001:470:de0a:27:30cd:102:b31:8dfd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 446987C05A3 for ; Fri, 28 Nov 2014 14:35:26 +0100 (CET) Message-ID: <54787A1D.2050204@alvestrand.no> Date: Fri, 28 Nov 2014 14:35:25 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LJ3MyoT-lN3wtnzlv1QrqqQ0Uxk Subject: [rtcweb] Overview updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:35:33 -0000 I've emitted the -13 version of the overview. Important changes: - Devices are now "non-browsers" - Since it makes no sense to talk about "a browser is a non-browser", I've used the word "endpoint" for the thing that one can place requirements on that apply to both browsers and non-browsers. - Some words about non-browsers with APIs were added. And more importantly: - -video is now referenced for video codecs. There is now a github repo for -overview, in case anyone wants to look behind the curtain: https://github.com/alvestrand/rtcweb-overview Enjoy! From nobody Fri Nov 28 05:44:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E551A1B0A for ; Fri, 28 Nov 2014 05:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ5yoOluP_BC for ; Fri, 28 Nov 2014 05:44:34 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5B51A1B65 for ; Fri, 28 Nov 2014 05:44:34 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-5d-54787c40439c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FD.1B.29772.04C78745; Fri, 28 Nov 2014 14:44:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:44:31 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Makaraju, Maridi Raju (Raju)" , "Justin Uberti" Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Fri, 28 Nov 2014 13:44:30 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvja5DTUWIwZQ5shZbpwpZNGy8wmqx 9l87uwOzR+uzvaweCzaVeixZ8pMpgDmKyyYlNSezLLVI3y6BK2P3oU6Wgh0yFRO/dzA3MN4U 72Lk5JAQMJHY9+cyC4QtJnHh3nq2LkYuDiGBI4wShxsbWSGcJYwSU7p3gFWxCQRKbN23gA3E FhHIlZjXtxLMZhZQl7iz+Bw7iC0sYCox6eIyJogaM4mFJycwQth6Eje/XACaw8HBIqAq8WQS K0iYV8BXYsrMnVCLDzFL/JgyHWwOI9BF30+tYYKYLy5x68l8JohLBSSW7DnPDGGLSrx8/I8V ZKaEgJLEtK1pEOV6EjemToE6TVti2cLXzBC7BCVOznzCMoFRdBaSqbOQtMxC0jILScsCRpZV jKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFxc3DLb4MdjC+fOx5iFOBgVOLhLZCtCBFiTSwr rsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwymdse77dhLL+mqbsy dMOTp8vufGazWnshRvoKxzv7gL3JG67euJ/2Mei4ebxTyY+qSj37OcnqboVPfoRXyirbbLg7 MVfs1rcHV1a5ZTiFO7+dp2ucpLZ/0gVxR/evJ2e9nCj9W2byurpIEc3eXRYdqRfCOl0Djimz nl21/KlFgNsrpuoHXwuVWIozEg21mIuKEwEdsXebfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sfFKY9-TSbucAvcTM5pv8C-Cnmg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:44:36 -0000 Thanks for a good overview!=0A= =0A= On 25/11/14 19:30, Makaraju, Maridi Raju (Raju) wrote:=0A= >>=0A= >> Do you have an opinion on my main "topic": that subsequent offers=0A= >> should offer the already negotiated role, rather than always=0A= >> "actpass"?=0A= > [Raju] For non DTLS-SRTP associations, I think the key attribute here=0A= > is a=3Dconnection. If a subsequent offer has an explicit=0A= > "a=3Dconnection:existing" then per the reference[1] a=3Dsetup (and other= =0A= > params) are ignored. Per [2] below, the default value for=0A= > a=3Dconnection is "new" in offer and answer. So, if an explicit=0A= > "a=3Dconnection:new" is present or "a=3Dconnection" is absent then, per= =0A= > [3], the existing association is closed and a new association will=0A= > be opened using new a=3Dsetup rules. Btw, I think section 7.3 of RFC=0A= > 4145 is just an example showing previously negotiated setup values=0A= > are used. But section 5.1 is normative and clearly says these=0A= > attributes must be ignored for a=3Dconnection:existing.=0A= >=0A= > Reference [4] and [5] are for DTLS-SRTP which does not allow=0A= > a=3Dconnection attribute and indicates new offer/answer compatibility=0A= > with old as the criteria to reuse or close/open new one. It also=0A= > notes that if a=3Dsetup changes then a new association is established.=0A= > This latter part also have to consider the a=3Dsetup defaults, which=0A= > may be different from previously negotiated values, if absent in new=0A= > offer/answer.=0A= =0A= In this context we're dealing only with DTLS-SRTP I guess.=0A= =0A= I read [5] as that subsequent offers should offer the negotiated role =0A= for existing connections (and not actpass), but I'm not sure. What is =0A= your interpretation?=0A= =0A= >=0A= > [1] https://tools.ietf.org/html/rfc4145#section-5.1=0A= >=0A= > "If the connection value resulting from an offer/answer exchange is=0A= > 'existing', the end-points continue using the existing connection.=0A= > Consequently, the port numbers, IP addresses, and 'setup' attributes=0A= > negotiated in the offer/answer exchange are ignored because there is=0A= > no need to establish a new connection."=0A= >=0A= > [2] https://tools.ietf.org/html/rfc4145#section-5.1 "The default=0A= > value of the connection attribute in both offers and answers is=0A= > 'new'. "=0A= >=0A= > [3] https://tools.ietf.org/html/rfc4145#section-5.2=0A= >=0A= > "If the connection value for an 'm' line resulting from an offer/=0A= > answer exchange is 'new', the endpoints SHOULD establish a new TCP=0A= > connection as indicated by the 'setup' attribute. If a previous TCP=0A= > connection is still up, the endpoints SHOULD close it as soon as the=0A= > offer/answer exchange is completed. It is up to the application to=0A= > ensure proper data synchronization between the two TCP connections."=0A= >=0A= > [4] DTLS SRTP RFC https://tools.ietf.org/html/rfc5763#section-5 " The=0A= > endpoint MUST NOT use the connection attribute defined in=0A= > [RFC4145]."=0A= >=0A= > [5] https://tools.ietf.org/html/rfc5763#section-6.6 "The peers can=0A= > reuse the existing associations if they are compatible (i.e., they=0A= > have the same key fingerprints and transport parameters), or=0A= > establish a new one following the same rules are for initial=0A= > exchanges, tearing down the existing association as soon as the=0A= > offer/answer exchange is completed. Note that if the active/passive=0A= > status of the endpoints changes, a new connection MUST be=0A= > established."=0A= >=0A= > BR Raju=0A= >=0A= =0A= From nobody Fri Nov 28 06:09:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FE91A1B42 for ; Fri, 28 Nov 2014 06:09:31 -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, 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 xzTMotdVa-Jk for ; Fri, 28 Nov 2014 06:09:25 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810BB1A1A98 for ; Fri, 28 Nov 2014 06:09:24 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-09-547882125cb2 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.5C.04076.21288745; Fri, 28 Nov 2014 15:09:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 15:09:22 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-08.txt Thread-Index: AQHQCxRx1iae8tO9U0eS4jtCB30HDpx2E0ZQ Date: Fri, 28 Nov 2014 14:09:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53F58D@ESESSMB209.ericsson.se> References: <20141128140523.13879.56557.idtracker@ietfa.amsl.com> In-Reply-To: <20141128140523.13879.56557.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja5QU0WIwYtL+hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+XKtcwFSwQrLu9pZG5gvMbbxcjJISFgIrF9cQ8jhC0mceHe erYuRi4OIYEjjBJPN19lhnCWMEpc/nABKMPBwSZgIdH9TxukQURAXeLywwvsILawgLPEletb mSDiLhIbHk5ngbCNJNo+b2EDsVkEVCW2HvoPFucV8JWYf/wVK4gtJOAocf3RdjCbU8BJYm37 crA5jEAHfT+1BsxmFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSfzYcIkFol5HYsHuT2wQ trbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPRSizKTi4vz 8/TyUks2MQJj4uCW31Y7GA8+dzzEKMDBqMTDWyBbESLEmlhWXJl7iFGag0VJnHfhuXnBQgLp iSWp2ampBalF8UWlOanFhxiZODilGhjtAl5eP2NuE8phcyHpg/uhuZMjbv9Im/NgzXKTDba7 OEv+ByUys3CsmLqioIObofXO9LBLd5UDjk7tLORn3f1YUdxv2y3TX981Tlnsl59w9ErmkuNb bB74NSx22hOWXyzFbLVEsEpV645u6nf5B7kdfQ1nAhP+PFIWWZWb+Pv1i2NsU58vr+9QYinO SDTUYi4qTgQAWLLsW2oCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1Ww66OBXzbPEI_SlCbU83Duxqsk Subject: [rtcweb] FW: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:09:34 -0000 FYI, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 28. marraskuuta 2014 16:05 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based= Media Transport in the Session Description Protocol (SDP) Authors : Christer Holmberg Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-08.txt Pages : 16 Date : 2014-11-28 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Nov 28 06:34:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189031A1B6C for ; Fri, 28 Nov 2014 06:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHOxbBXAmI3K for ; Fri, 28 Nov 2014 06:34:44 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED6F1A1A69 for ; Fri, 28 Nov 2014 06:34:44 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so18708726wiv.17 for ; Fri, 28 Nov 2014 06:34:43 -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=VhQwaZHWriJ41Hwa/ogCxbIvfsOnJ1+gLC/+rplKu+4=; b=V7EdsAxpF5pVCSnplV8U8OAlS1FHHF37Mawno9OzZdkUzPqhkFa7HOPByuim1bZSXx lNpOdgTGnRHN/ZHgwWIlpp4bwGFnuo6F+Ily3/jisEa0e0ZIcfj4vTZKoY7dTip6y6hJ pKm0VOBMtPrKVbIqYVZ5/eAI/dR3PFQLYOL8x+mtafGR5Eod3P9FnCrPa+3Rlvwe1rIC Wjh3ttpjyAeiqbVQ1j3repheYAv+88wzCAQAAN0wigL8xxpmfh7YVjGcqwdIxzx7Y7OV 5J0T7xM1dFzCNxG9CYno9PgTRVzplQj/4mWU9oUmukHiIB7HQN72Jc5qC0Y0m1T2DlEN yq1A== X-Gm-Message-State: ALoCoQnly75jjn1IfdvuF+iC6OwB3wprDO+RXRstICqzfb+PQVgHHMa7ZQSwB6df/o9Va3LRC4ps X-Received: by 10.194.235.193 with SMTP id uo1mr68324427wjc.105.1417185282968; Fri, 28 Nov 2014 06:34:42 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com. [74.125.82.52]) by mx.google.com with ESMTPSA id vy7sm15250412wjc.27.2014.11.28.06.34.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Nov 2014 06:34:41 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id a1so8999393wgh.25 for ; Fri, 28 Nov 2014 06:34:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr71205490wjb.71.1417185281286; Fri, 28 Nov 2014 06:34:41 -0800 (PST) Received: by 10.216.186.74 with HTTP; Fri, 28 Nov 2014 06:34:41 -0800 (PST) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> Date: Fri, 28 Nov 2014 09:34:41 -0500 Message-ID: From: Roman Shpount To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=047d7bd910c245a8e80508ec29bb Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G4nPjmf9nXVcgcWMjjzC4FVtfLM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:34:46 -0000 --047d7bd910c245a8e80508ec29bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 28, 2014 at 8:44 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > In this context we're dealing only with DTLS-SRTP I guess. > > I read [5] as that subsequent offers should offer the negotiated role > for existing connections (and not actpass), but I'm not sure. What is > your interpretation? > > I actually have a more generic question: In what circumstances would new DTLS connection handshake be initiated if transport parameters and fingerprint did not change? I assume new negotiation is required if subsequent offer contains active or passive role that does not match the current connection state. What about actpass? Is getting an actpass in the subsequent offer should mean that the roles did not change and existing connection should continue to be re-used or does it mean new negotiation should be started? Should DTLS-SRTP endpoints be able to handle new DTLS handshake at any time, without any associated signaling exchange? I do not think any of the current browser implementations support that, even though such support would be required for DTLS-SRTP rekey. If DTLS handshake handling at any time is required, then end-points should only be forced to do a new handshake by signaling if their roles change. If one of the end-points turns out to be overzealous and starts an unexpected handshake, it would be handled no differently then DTLS rekey, as long as roles stayed the same. There is also a consideration, that the newly generated offer is intended to be send to a completely new end-point and not to the existing connection. This would most likely be known in advance for webrtc end points, since they will need to collect a new set of ICE candidates, but this can affect SIP end-points. Since we would probably want to avoid extra handshakes, and that we want to accommodate both offers intended for the existing and the new destinations, we can state that in the subsequent offers, the end point should include the actpass setup attribute. In the answer, if DTLS connection is already setup, the end point should respond with the currently negotiated role. If an end-point receives an offer with the non actpass setup attribute, it should only initiate a new DTLS handshake if the specified attribute does not match the currently negotiated setup state. _____________ Roman Shpount --047d7bd910c245a8e80508ec29bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 28, 2014 at 8:44 AM, Stefan H=C3=A5kansson LK <= ;stef= an.lk.hakansson@ericsson.com> wrote:
In t= his context we're dealing only with DTLS-SRTP I guess.

I read [5] as that subsequent offers should offer the negotiated role
for existing connections (and not actpass), but I'm not sure. What is your interpretation?


I actually have a more generic questio= n: In what circumstances would new DTLS connection handshake be initiated i= f transport parameters and fingerprint did not change?=C2=A0

=
I assume new negotiation is required if subsequent offer contain= s active or passive role that does not match the current connection state. = What about actpass? Is getting an actpass in the subsequent offer should me= an that the roles did not change and existing connection should continue to= be re-used or does it mean new negotiation should be started?
Should DTLS-SRTP endpoints be able to handle new DTLS handshak= e at any time, without any associated signaling exchange? I do not think an= y of the current browser implementations support that, even though such sup= port would be required for DTLS-SRTP rekey. If DTLS handshake handling at a= ny time is required, then end-points should only be forced to do a new hand= shake by signaling if their roles change. If one of the end-points turns ou= t to be overzealous and starts an unexpected handshake, it would be handled= no differently then DTLS rekey, as long as roles stayed the same.

There is also a consideration, that the newly generated of= fer is intended to be send to a completely new end-point and not to the exi= sting connection. This would most likely be known in advance for webrtc end= points, since they will need to collect a new set of ICE candidates, but t= his can affect SIP end-points.

Since we would prob= ably want to avoid extra handshakes, and that we want to accommodate both o= ffers intended for the existing and the new destinations, we can state that= in the subsequent offers, the end point should include the actpass setup a= ttribute. In the answer, if DTLS connection is already setup, the end point= should respond with the currently negotiated role. If an end-point receive= s an offer with the non actpass setup attribute, it should only initiate a = new DTLS handshake if the specified attribute does not match the currently = negotiated setup state.
__________= ___
Roman Shpount
=C2=A0
--047d7bd910c245a8e80508ec29bb-- From nobody Fri Nov 28 06:59:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E431A1A68 for ; Fri, 28 Nov 2014 06:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFeQDwLX8hbj for ; Fri, 28 Nov 2014 06:59:13 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82891A000B for ; Fri, 28 Nov 2014 06:59:12 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E46B58BD68D19; Fri, 28 Nov 2014 14:59:06 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sASEx3OS032349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 09:59:08 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 09:59:05 -0500 From: "Makaraju, Maridi Raju (Raju)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JADFbzPw Date: Fri, 28 Nov 2014 14:59:04 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HGMq7qEpdSoDISVMPKUqcP0W71w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:59:15 -0000 > Thanks for a good overview! >=20 > On 25/11/14 19:30, Makaraju, Maridi Raju (Raju) wrote: > >> > >> Do you have an opinion on my main "topic": that subsequent offers > >> should offer the already negotiated role, rather than always > >> "actpass"? > > [Raju] For non DTLS-SRTP associations, I think the key attribute here > > is a=3Dconnection. If a subsequent offer has an explicit > > "a=3Dconnection:existing" then per the reference[1] a=3Dsetup (and othe= r > > params) are ignored. Per [2] below, the default value for > > a=3Dconnection is "new" in offer and answer. So, if an explicit > > "a=3Dconnection:new" is present or "a=3Dconnection" is absent then, per > > [3], the existing association is closed and a new association will > > be opened using new a=3Dsetup rules. Btw, I think section 7.3 of RFC > > 4145 is just an example showing previously negotiated setup values > > are used. But section 5.1 is normative and clearly says these > > attributes must be ignored for a=3Dconnection:existing. > > > > Reference [4] and [5] are for DTLS-SRTP which does not allow > > a=3Dconnection attribute and indicates new offer/answer compatibility > > with old as the criteria to reuse or close/open new one. It also > > notes that if a=3Dsetup changes then a new association is established. > > This latter part also have to consider the a=3Dsetup defaults, which > > may be different from previously negotiated values, if absent in new > > offer/answer. >=20 > In this context we're dealing only with DTLS-SRTP I guess. >=20 > I read [5] as that subsequent offers should offer the negotiated role > for existing connections (and not actpass), but I'm not sure. What is > your interpretation? IMO, the text does not say subsequent offer must send previously=20 negotiated role. In fact there are issues in sending previously=20 negotiated role. The browser or the client is not aware if the sub-sequent offer could result in an SDP answer which now have a new destination address (e.g. a new middle box for conf), only the service logic=20 in the communications server determines this. To facilitate this, IMO, sending actpass is the right approach. If it turns out to be SDP answer has not changed the destination, fingerprint, and role (i.e. compatible to previous answer) then previous association will continue to be used. This is per [6]. The above explanation is for DTLS-SRTP without use of ICE. When ICE is used, if the destination is to be changed then=20 per [6] ICE must be restarted. So, restarting ICE must also set role as actpass instead of previously negotiated role. When ICE is completed, the SDP answer to a subsequent offer=20 can't change the Destination (m/c=3D lines) to a new=20 candidate (it should be the selected candidate) unless ICE=20 is restarted. Please note that ICE restart can't be initiated in an SDP answer. Unfortunately [7] did not talk about these interactions with ICE. In conclusion, even for WebRTC use case of DTLS-SRTP, IMHO, it is better if actpass is offered again for all cases independent of ICE restart. The peer will simply respond to the previously negotiated role which will keep the existing association. [6] https://tools.ietf.org/html/rfc5245#section-9.1.1.1=20 [7] https://tools.ietf.org/html/rfc5763#section-6.7.1 >=20 > > > > [1] https://tools.ietf.org/html/rfc4145#section-5.1 > > > > "If the connection value resulting from an offer/answer exchange is > > 'existing', the end-points continue using the existing connection. > > Consequently, the port numbers, IP addresses, and 'setup' attributes > > negotiated in the offer/answer exchange are ignored because there is > > no need to establish a new connection." > > > > [2] https://tools.ietf.org/html/rfc4145#section-5.1 "The default > > value of the connection attribute in both offers and answers is > > 'new'. " > > > > [3] https://tools.ietf.org/html/rfc4145#section-5.2 > > > > "If the connection value for an 'm' line resulting from an offer/ > > answer exchange is 'new', the endpoints SHOULD establish a new TCP > > connection as indicated by the 'setup' attribute. If a previous TCP > > connection is still up, the endpoints SHOULD close it as soon as the > > offer/answer exchange is completed. It is up to the application to > > ensure proper data synchronization between the two TCP connections." > > > > [4] DTLS SRTP RFC https://tools.ietf.org/html/rfc5763#section-5 " The > > endpoint MUST NOT use the connection attribute defined in > > [RFC4145]." > > > > [5] https://tools.ietf.org/html/rfc5763#section-6.6 "The peers can > > reuse the existing associations if they are compatible (i.e., they > > have the same key fingerprints and transport parameters), or > > establish a new one following the same rules are for initial > > exchanges, tearing down the existing association as soon as the > > offer/answer exchange is completed. Note that if the active/passive > > status of the endpoints changes, a new connection MUST be > > established." > > > > BR Raju > > From nobody Fri Nov 28 07:00:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103BE1A1A68 for ; Fri, 28 Nov 2014 07:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F-hteIwCgFE for ; Fri, 28 Nov 2014 07:00:33 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1C91A000B for ; Fri, 28 Nov 2014 07:00:32 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-6f-54788e0f14c0 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.86.24955.F0E88745; Fri, 28 Nov 2014 16:00:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 16:00:30 +0100 From: Christer Holmberg To: Roman Shpount , =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JADE6FaAAAJOeiA= Date: Fri, 28 Nov 2014 15:00:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvjS5/X0WIwcF1/BYzLkxltlj7r53d gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZexte89SsEet4u2pI2wNjHtUuxg5OSQETCRW nDjEBGGLSVy4t56ti5GLQ0jgCKPEsgMrWCGcJYwSm4+2AzkcHGwCFhLd/7RBGkQESiQWt1xg AbGZBdQl7iw+xw5iCwuYSryfe4QZosZMYuHJCYwQtpXEnZ5fbCA2i4CqxMy7XWA2r4CvxKvN V6F2nWWR+HjlDzvILk6BQIk3O8RAahiBjvt+ag0TxC5xiVtP5kMdLSCxZM95ZghbVOLl43+s ELaSxI8Nl1hAxjALaEqs36UP0aooMaX7ITvEWkGJkzOfsExgFJuFZOoshI5ZSDpmIelYwMiy ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwcg5u+a26g/HyG8dDjAIcjEo8vAWyFSFCrIll xZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR7PSJv68WnvavkFqw 5Ob9zaqR05daSSYkidTKeqywf8Dz9eQ/juOpp++6Hj+yPsW/6/n/tc+ffOJgfDtj2sK/fyr4 T93sEK+KKpp8dp7zTMfaE34BO+KNPfpzqznrig7MzV4usuLj56JpArO6W2w2G8+Q0nGbfdrs 4hfePXLiB6XW1jmoGk24rsRSnJFoqMVcVJwIAIwcZ+Z9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5c9mYygzxpFuFEUSRQhwHHFzkig Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 15:00:36 -0000 SGksDQoNCllvdSBtYXkgd2FudCB0byB0YWtlIGEgbG9vayBhdCB0aGUgbmV3IHZlcnNpb24gb2Yg dGhlIFNDVFAtU0RQIGRyYWZ0LCB3aGVyZSBJIGhhdmUgYWRkZWQgcHJvY2VkdXJlcyAoYW5kIHNv bWUgb3BlbiBpc3N1ZXMpIHJlZ2FyZGluZyB0aGUgdXNhZ2Ugb2YgYT1zZXR1cCBhbmQgYT1jb25u ZWN0aW9uLg0KDQo+SW4gdGhpcyBjb250ZXh0IHdlJ3JlIGRlYWxpbmcgb25seSB3aXRoIERUTFMt U1JUUCBJIGd1ZXNzLg0KPg0KPkkgcmVhZCBbNV0gYXMgdGhhdCBzdWJzZXF1ZW50IG9mZmVycyBz aG91bGQgb2ZmZXIgdGhlIG5lZ290aWF0ZWQgcm9sZQ0KPmZvciBleGlzdGluZyBjb25uZWN0aW9u cyAoYW5kIG5vdCBhY3RwYXNzKSwgYnV0IEknbSBub3Qgc3VyZS4gV2hhdCBpcw0KPnlvdXIgaW50 ZXJwcmV0YXRpb24/DQo+DQo+IEkgYWN0dWFsbHkgaGF2ZSBhIG1vcmUgZ2VuZXJpYyBxdWVzdGlv bjogSW4gd2hhdCBjaXJjdW1zdGFuY2VzIHdvdWxkIG5ldyBEVExTIGNvbm5lY3Rpb24gaGFuZHNo YWtlIGJlIGluaXRpYXRlZCBpZiB0cmFuc3BvcnQgcGFyYW1ldGVycyBhbmQgZmluZ2VycHJpbnQg ZGlkIG5vdCBjaGFuZ2U/wqANCj4NCj4gSSBhc3N1bWUgbmV3IG5lZ290aWF0aW9uIGlzIHJlcXVp cmVkIGlmIHN1YnNlcXVlbnQgb2ZmZXIgY29udGFpbnMgYWN0aXZlIG9yIHBhc3NpdmUgcm9sZSB0 aGF0IGRvZXMgbm90IG1hdGNoIHRoZSBjdXJyZW50IGNvbm5lY3Rpb24gc3RhdGUuIA0KPg0KPiBX aGF0IGFib3V0IGFjdHBhc3M/IElzIGdldHRpbmcgYW4gYWN0cGFzcyBpbiB0aGUgc3Vic2VxdWVu dCBvZmZlciBzaG91bGQgbWVhbiB0aGF0IHRoZSByb2xlcyBkaWQgbm90IGNoYW5nZSBhbmQgZXhp c3RpbmcgY29ubmVjdGlvbiBzaG91bGQgY29udGludWUgdG8gYmUgcmUtdXNlZCBvciBkb2VzIGl0 IG1lYW4gbmV3IG5lZ290aWF0aW9uIHNob3VsZCBiZSBzdGFydGVkPw0KPg0KPiBTaG91bGQgRFRM Uy1TUlRQIGVuZHBvaW50cyBiZSBhYmxlIHRvIGhhbmRsZSBuZXcgRFRMUyBoYW5kc2hha2UgYXQg YW55IHRpbWUsIHdpdGhvdXQgYW55IGFzc29jaWF0ZWQgc2lnbmFsaW5nIGV4Y2hhbmdlPyBJIGRv IG5vdCB0aGluayBhbnkgb2YgdGhlIA0KPiBjdXJyZW50IGJyb3dzZXIgaW1wbGVtZW50YXRpb25z IHN1cHBvcnQgdGhhdCwgZXZlbiB0aG91Z2ggc3VjaCBzdXBwb3J0IHdvdWxkIGJlIHJlcXVpcmVk IGZvciBEVExTLVNSVFAgcmVrZXkuIElmIERUTFMgaGFuZHNoYWtlIA0KPiBoYW5kbGluZyBhdCBh bnkgdGltZSBpcyByZXF1aXJlZCwgdGhlbiBlbmQtcG9pbnRzIHNob3VsZCBvbmx5IGJlIGZvcmNl ZCB0byBkbyBhIG5ldyBoYW5kc2hha2UgYnkgc2lnbmFsaW5nIGlmIHRoZWlyIHJvbGVzIGNoYW5n ZS4gSWYgb25lIG9mIHRoZSBlbmQtcG9pbnRzIA0KPiB0dXJucyBvdXQgdG8gYmUgb3ZlcnplYWxv dXMgYW5kIHN0YXJ0cyBhbiB1bmV4cGVjdGVkIGhhbmRzaGFrZSwgaXQgd291bGQgYmUgaGFuZGxl ZCBubyBkaWZmZXJlbnRseSB0aGVuIERUTFMgcmVrZXksIGFzIGxvbmcgYXMgcm9sZXMgc3RheWVk IHRoZSBzYW1lLg0KPg0KPiBUaGVyZSBpcyBhbHNvIGEgY29uc2lkZXJhdGlvbiwgdGhhdCB0aGUg bmV3bHkgZ2VuZXJhdGVkIG9mZmVyIGlzIGludGVuZGVkIHRvIGJlIHNlbmQgdG8gYSBjb21wbGV0 ZWx5IG5ldyBlbmQtcG9pbnQgYW5kIG5vdCB0byB0aGUgZXhpc3RpbmcgY29ubmVjdGlvbi4gVGhp cyB3b3VsZCANCj4gbW9zdCBsaWtlbHkgYmUga25vd24gaW4gYWR2YW5jZSBmb3Igd2VicnRjIGVu ZCBwb2ludHMsIHNpbmNlIHRoZXkgd2lsbCBuZWVkIHRvIGNvbGxlY3QgYSBuZXcgc2V0IG9mIElD RSBjYW5kaWRhdGVzLCBidXQgdGhpcyBjYW4gYWZmZWN0IFNJUCBlbmQtcG9pbnRzLg0KPg0KPiBT aW5jZSB3ZSB3b3VsZCBwcm9iYWJseSB3YW50IHRvIGF2b2lkIGV4dHJhIGhhbmRzaGFrZXMsIGFu ZCB0aGF0IHdlIHdhbnQgdG8gYWNjb21tb2RhdGUgYm90aCBvZmZlcnMgaW50ZW5kZWQgZm9yIHRo ZSBleGlzdGluZyBhbmQgdGhlIG5ldyBkZXN0aW5hdGlvbnMsIHdlIGNhbiANCj4gc3RhdGUgdGhh dCBpbiB0aGUgc3Vic2VxdWVudCBvZmZlcnMsIHRoZSBlbmQgcG9pbnQgc2hvdWxkIGluY2x1ZGUg dGhlIGFjdHBhc3Mgc2V0dXAgYXR0cmlidXRlLiBJbiB0aGUgYW5zd2VyLCBpZiBEVExTIGNvbm5l Y3Rpb24gaXMgYWxyZWFkeSBzZXR1cCwgdGhlIGVuZCBwb2ludCBzaG91bGQgDQo+IHJlc3BvbmQg d2l0aCB0aGUgY3VycmVudGx5IG5lZ290aWF0ZWQgcm9sZS4gSWYgYW4gZW5kLXBvaW50IHJlY2Vp dmVzIGFuIG9mZmVyIHdpdGggdGhlIG5vbiBhY3RwYXNzIHNldHVwIGF0dHJpYnV0ZSwgaXQgc2hv dWxkIG9ubHkgaW5pdGlhdGUgYSBuZXcgRFRMUyBoYW5kc2hha2UgaWYgdGhlIA0KPiBzcGVjaWZp ZWQgYXR0cmlidXRlIGRvZXMgbm90IG1hdGNoIHRoZSBjdXJyZW50bHkgbmVnb3RpYXRlZCBzZXR1 cCBzdGF0ZS4NCg0KUkZDIDczNDUgKFVEUFRMLURUTFMpIHNheXMgdGhlIGZvbGxvd2luZzoNCg0K CSJPbmNlIGFuIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBoYXMgYmVlbiBjb21wbGV0ZWQsIGVpdGhl ciBlbmRwb2ludCBNQVkNCiAgIAlzZW5kIGEgbmV3IG9mZmVyIGluIG9yZGVyIHRvIG1vZGlmeSB0 aGUgc2Vzc2lvbi4gIFRoZSBlbmRwb2ludHMgY2FuDQogICAJcmV1c2UgdGhlIGV4aXN0aW5nIERU TFMgYXNzb2NpYXRpb24gaWYgdGhlIGtleSBmaW5nZXJwcmludCB2YWx1ZXMgYW5kDQogICAJdHJh bnNwb3J0IHBhcmFtZXRlcnMgaW5kaWNhdGVkIGJ5IGVhY2ggZW5kcG9pbnQgYXJlIHVuY2hhbmdl ZC4NCiAgIAlPdGhlcndpc2UsIGZvbGxvd2luZyB0aGUgcnVsZXMgZm9yIHRoZSBpbml0aWFsIG9m ZmVyL2Fuc3dlciBleGNoYW5nZSwNCiAgIAl0aGUgZW5kcG9pbnRzIGNhbiBuZWdvdGlhdGUgYW5k IGNyZWF0ZSBhIG5ldyBEVExTIGFzc29jaWF0aW9uIGFuZCwNCiAgIAlvbmNlIGNyZWF0ZWQsIGRl bGV0ZSB0aGUgcHJldmlvdXMgRFRMUyBhc3NvY2lhdGlvbiwgZm9sbG93aW5nIHRoZQ0KICAgCXNh bWUgcnVsZXMgZm9yIHRoZSBpbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZS4gIEVhY2ggZW5k cG9pbnQNCiAgIAluZWVkcyB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGRhdGEgb24gYm90aCB0 aGUgbmV3IGFuZCBvbGQgRFRMUw0KICAgCWFzc29jaWF0aW9ucyBhcyBsb25nIGFzIGJvdGggYXJl IGFsaXZlLiINCg0KU28sIEkgZ3Vlc3MgdGhhdCBjYW4gYmUgcmVhZCBpbiBhIHdheSB0aGF0IHRo ZSBzZXR1cCBhdHRyaWJ1dGUgYXMgc3VjaCBkb2VzIG5vdCBpbXBhY3QgcHJldmlvdXNseSBuZWdv dGlhdGVkIFRMUyByb2xlcyAtIHVubGVzcyB0aGUga2V5IGZpbmdlcnByaW50IHZhbHVlcyBhbmQv b3IgdHJhbnNwb3J0IHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkLg0KDQpUaGUgU0NUUC1TRFAgZHJh ZnQgY3VycmVudGx5IHNheXMgdGhhdCBhIHN1YnNlcXVlbnQgb2ZmZXIgbXVzdCBub3QgY2hhbmdl IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgcm9sZXMuIEJ1dCwgSSBndWVzcyB3ZSBjb3VsZCBz YXkgc29tZXRoaW5nIHNpbWlsYXIgYXMgaW4gUkZDIDczNDUuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQo= From nobody Fri Nov 28 07:37:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E87A1A0077 for ; Fri, 28 Nov 2014 07:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWx44htj4IbA for ; Fri, 28 Nov 2014 07:36:56 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4E31A0052 for ; Fri, 28 Nov 2014 07:36:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6D6097C0B28 for ; Fri, 28 Nov 2014 16:36:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uw7uNiyJvJ9p for ; Fri, 28 Nov 2014 16:36:54 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:50b5:9650:e9f9:ed09] (unknown [IPv6:2001:470:de0a:27:50b5:9650:e9f9:ed09]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6336A7C0B00 for ; Fri, 28 Nov 2014 16:36:54 +0100 (CET) Message-ID: <54789695.2010406@alvestrand.no> Date: Fri, 28 Nov 2014 07:36:53 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qFWE8hdXC7L72ZYIii-msPk-ZCo Subject: [rtcweb] VP8 "profile" text - proposed replacement X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 15:36:59 -0000 The current text in draft-ietf-rtcweb-video-03 text about VP8 that I commented on in Hawaii, and my proposed replacement: ** OLD ** For the VP8 codec, defined in [RFC6386], endpoints MUST support the payload formats defined in [I-D.ietf-payload-vp8]. In addition they MUST support the 'bilinear' and 'none' reconstruction filters. ** NEW ** For the VP8 codec, defined in [RFC6386], endpoints MUST support the payload formats defined in [I-D.ietf-payload-vp8]. All VP8 decoders have to support all features of the VP8 bitstream as defined in [RFC6386], including all 4 defined values (0-3) of the "version" number defined in section 9.1 of that document. ** END CHANGE ** RFC 6386 isn't very clear about the fact that all features must be implemented by all decoders, but that has been the reality since VP8 was first released. So the new sentence should be equivalent to saying nothing, but it is OK to be super-clear about this. I believe this is already clarified in the MPEG version of the VP8 specification too. --=20 Surveillance is pervasive. Go Dark. From nobody Fri Nov 28 15:23:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898D1A1B87 for ; Fri, 28 Nov 2014 15:23:02 -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 4pp7nktMLz0a for ; Fri, 28 Nov 2014 15:23:00 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857C71A1B86 for ; Fri, 28 Nov 2014 15:22:59 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so9887431wgh.12 for ; Fri, 28 Nov 2014 15:22:58 -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=wfitLjPDLWtPS6m0UopX/LCE0ueBX4NZdVq91QpKzjY=; b=P8zOJwu+OfeHKqI1APBzvLeushQRPhrW6HF/yB7+QQ2xBF00ohrIQMaFDQWigyuYMO RxrRK/ISL97GkM6zEswM1yZsgiltvs2lCEQkrZnk8CwuLVlkQQrg1qs/X5UVnft5WJgn gWXT/4S1txFcwRI6QlgSJk326iCXGz02/MKvCRYXRXa7WHaxNdptof0LI8QAzQj64aVR 8n2wOb/suCBYO4SpXQmSqOWCu0tXKZevJO64k3yDbiC9toWM2YoZZBV1o53D0pClbJl3 ZD6LfaRu7+Eg7y8tu/h8fQeEg5B5anIQwxdIus1xs/GXcJLPBoBcV4zw6Ikzzq/5Bx7i 5InA== X-Gm-Message-State: ALoCoQmvbNBoyWhlkOwbM35myFTBR7ukQrehGXiUwnk7YRU0PrTu3Bg0U4LMR9d4ozLr2jDrtuVs X-Received: by 10.180.198.52 with SMTP id iz20mr37873040wic.60.1417216978160; Fri, 28 Nov 2014 15:22:58 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com. [74.125.82.48]) by mx.google.com with ESMTPSA id k5sm9544859wjn.1.2014.11.28.15.22.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Nov 2014 15:22:57 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so9827586wgg.7 for ; Fri, 28 Nov 2014 15:22:56 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr75511571wjb.78.1417216976817; Fri, 28 Nov 2014 15:22:56 -0800 (PST) Received: by 10.216.186.74 with HTTP; Fri, 28 Nov 2014 15:22:56 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> Date: Fri, 28 Nov 2014 18:22:56 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0102fc527918ec0508f38af5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9faEKXh-FRgQQMY1r7bKgH5i9rc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 23:23:02 -0000 --089e0102fc527918ec0508f38af5 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 28, 2014 at 10:00 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > RFC 7345 (UDPTL-DTLS) says the following: > > "Once an offer/answer exchange has been completed, either endpoint > MAY > send a new offer in order to modify the session. The endpoints can > reuse the existing DTLS association if the key fingerprint values > and > transport parameters indicated by each endpoint are unchanged. > Otherwise, following the rules for the initial offer/answer > exchange, > the endpoints can negotiate and create a new DTLS association and, > once created, delete the previous DTLS association, following the > same rules for the initial offer/answer exchange. Each endpoint > needs to be prepared to receive data on both the new and old DTLS > associations as long as both are alive." > > So, I guess that can be read in a way that the setup attribute as such > does not impact previously negotiated TLS roles - unless the key > fingerprint values and/or transport parameters are modified. > > The SCTP-SDP draft currently says that a subsequent offer must not change > the previously negotiated roles. But, I guess we could say something > similar as in RFC 7345. > I have struggled with this language quite a bit from the implementation perspective. I think we need to explicitly state that endpoints MUST reuse the existing association if the key fingerprint values and transport parameters indicated by each endpoint are unchanged. The way this language reads to me is that endpoints can reuse the existing association if they want to, but they can create a new one if they don't. Also, when this new association is created, it is unclear if old setup roles MUST be preserved or if they MUST be selected based on the current offer/answer exchange. It seems the current specification language is not strong or clear enough on this topic. Another implementation issue, unless I am greatly mistaken, is that the web browsers will not currently handle creating a new DTLS association unless they expect it to be created. I believe this to be a very critical issue with DTLS implementations which will not only affect DTLS association setup, but will also break re-key. I think, we should state that webrtc end-point should expect new DTLS association with exiting setup roles and key fingerprint to be created at any time. _____________ Roman Shpount --089e0102fc527918ec0508f38af5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 28, 2014 at 10:00 AM, Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:
RFC 7345 (UDPTL-DTLS) says the= following:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Once an offer/answer exchange has been co= mpleted, either endpoint MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 send a new offer in order to modify the session= .=C2=A0 The endpoints can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reuse the existing DTLS association if the key = fingerprint values and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transport parameters indicated by each endpoint= are unchanged.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Otherwise, following the rules for the initial = offer/answer exchange,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the endpoints can negotiate and create a new DT= LS association and,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 once created, delete the previous DTLS associat= ion, following the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 same rules for the initial offer/answer exchang= e.=C2=A0 Each endpoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 needs to be prepared to receive data on both th= e new and old DTLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 associations as long as both are alive."
So, I guess that can be read in a way that the setup attribute as such does= not impact previously negotiated TLS roles - unless the key fingerprint va= lues and/or transport parameters are modified.

The SCTP-SDP draft currently says that a subsequent offer must not change t= he previously negotiated roles. But, I guess we could say something similar= as in RFC 7345.

I have struggled with = this language quite a bit from the implementation perspective. I think we n= eed to explicitly state that endpoints MUST reuse the existing association = if the key fingerprint values and transport parameters indicated by each en= dpoint are unchanged. The way this language reads to me is that endpoints c= an reuse the existing association if they want to, but they can create a ne= w one if they don't. Also, when this new association is created, it is = unclear if old setup roles MUST be preserved or if they MUST be selected ba= sed on the current offer/answer exchange. It seems the current specificatio= n language is not strong or clear enough on this topic.

Another implementation issue, unless I am greatly mistaken, is that t= he web browsers will not currently handle creating a new DTLS association u= nless they expect it to be created. I believe this to be a very critical is= sue with DTLS implementations which will not only affect DTLS association s= etup, but will also break re-key. I think, we should state that webrtc end-= point should expect new DTLS association with exiting setup roles and key f= ingerprint to be created at any time.=C2=A0
_____________
Roman Shpount
=C2=A0
--089e0102fc527918ec0508f38af5-- From nobody Fri Nov 28 21:01:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6956E1A002C for ; Fri, 28 Nov 2014 21:01:25 -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, 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 ZpBxezprmxBy for ; Fri, 28 Nov 2014 21:01:23 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5892F1A002B for ; Fri, 28 Nov 2014 21:01:23 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-12-547953202960 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.2B.04231.02359745; Sat, 29 Nov 2014 06:01:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Sat, 29 Nov 2014 06:01:20 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JADE6FaAAAJOeiAAECRyAAANRj6g Date: Sat, 29 Nov 2014 05:01:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvja5icGWIwb2PfBYzLkxltlj7r53d gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZfyY9pip4IJ0xcOZCQ2MX6S6GDk5JARMJCZ1 LmKHsMUkLtxbzwZiCwkcYZSYeriui5ELyF7CKPFk2WbmLkYODjYBC4nuf9ogNSICqhJ/v09m ArGZBcokbpw+xQhiCwuYSryfe4QZosZMYuHJCYwQtpvEh/UPWUHGsAD1blodABLmFfCVePRs JyvE2husEru3cILYnAKBEs/2HgJrZQQ67fupNVCrxCVuPZnPBHGygMSSPeeZIWxRiZeP/7FC 2EoSaw9vZwFZxSygKbF+lz5Eq6LElO6H7BBrBSVOznzCMoFRbBaSqbMQOmYh6ZiFpGMBI8sq RtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMCYObjlt+4OxtWvHQ8xCnAwKvHwFshWhAixJpYV V+YeYpTmYFES5110bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZWCfF7tsYaGYYHPvxR 9oubHFF044xK94OpCw8lHu7+8ubGso2LWIt6ReSyyya6q5w/oeFctHmirNnmrSbu/WFhHtW2 XwN2OMVsbr10mG9R9fXJLzdJCYlazYno4d1s9H5K8Y62SRenzrla6HQqwTfKdGrJUu+ZnG9/ PNq2+c3ZDbmvHNwDJY4osRRnJBpqMRcVJwIAVed6ZXoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xp5yBRu_GP2vuBjvB8fOjv7c3dk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 29 Nov 2014 05:01:25 -0000 SGksDQoNCj4+UkZDIDczNDUgKFVEUFRMLURUTFMpIHNheXMgdGhlIGZvbGxvd2luZzoNCj4+DQo+ PsKgIMKgIMKgIMKgICJPbmNlIGFuIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBoYXMgYmVlbiBjb21w bGV0ZWQsIGVpdGhlciBlbmRwb2ludCBNQVkNCj4+wqAgwqAgwqAgwqAgc2VuZCBhIG5ldyBvZmZl ciBpbiBvcmRlciB0byBtb2RpZnkgdGhlIHNlc3Npb24uwqAgVGhlIGVuZHBvaW50cyBjYW4NCj4+ wqAgwqAgwqAgwqAgcmV1c2UgdGhlIGV4aXN0aW5nIERUTFMgYXNzb2NpYXRpb24gaWYgdGhlIGtl eSBmaW5nZXJwcmludCB2YWx1ZXMgYW5kDQo+PsKgIMKgIMKgIMKgIHRyYW5zcG9ydCBwYXJhbWV0 ZXJzIGluZGljYXRlZCBieSBlYWNoIGVuZHBvaW50IGFyZSB1bmNoYW5nZWQuDQo+PsKgIMKgIMKg IMKgIE90aGVyd2lzZSwgZm9sbG93aW5nIHRoZSBydWxlcyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIv YW5zd2VyIGV4Y2hhbmdlLA0KPj7CoCDCoCDCoCDCoCB0aGUgZW5kcG9pbnRzIGNhbiBuZWdvdGlh dGUgYW5kIGNyZWF0ZSBhIG5ldyBEVExTIGFzc29jaWF0aW9uIGFuZCwNCj4+wqAgwqAgwqAgwqAg b25jZSBjcmVhdGVkLCBkZWxldGUgdGhlIHByZXZpb3VzIERUTFMgYXNzb2NpYXRpb24sIGZvbGxv d2luZyB0aGUNCj4+wqAgwqAgwqAgwqAgc2FtZSBydWxlcyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIv YW5zd2VyIGV4Y2hhbmdlLsKgIEVhY2ggZW5kcG9pbnQNCj4+wqAgwqAgwqAgwqAgbmVlZHMgdG8g YmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBkYXRhIG9uIGJvdGggdGhlIG5ldyBhbmQgb2xkIERUTFMN Cj4+wqAgwqAgwqAgwqAgYXNzb2NpYXRpb25zIGFzIGxvbmcgYXMgYm90aCBhcmUgYWxpdmUuIg0K Pj4NCj4+IFNvLCBJIGd1ZXNzIHRoYXQgY2FuIGJlIHJlYWQgaW4gYSB3YXkgdGhhdCB0aGUgc2V0 dXAgYXR0cmlidXRlIGFzIHN1Y2ggZG9lcyBub3QgaW1wYWN0IHByZXZpb3VzbHkgDQo+PiBuZWdv dGlhdGVkIFRMUyByb2xlcyAtIHVubGVzcyB0aGUga2V5IGZpbmdlcnByaW50IHZhbHVlcyBhbmQv b3IgdHJhbnNwb3J0IHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkLg0KPj4NCj4+IFRoZSBTQ1RQLVNE UCBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGF0IGEgc3Vic2VxdWVudCBvZmZlciBtdXN0IG5vdCBj aGFuZ2UgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlcy4gQnV0LCBJIGd1ZXNzIA0KPj4g d2UgY291bGQgc2F5IHNvbWV0aGluZyBzaW1pbGFyIGFzIGluIFJGQyA3MzQ1Lg0KPg0KPiBJIGhh dmUgc3RydWdnbGVkIHdpdGggdGhpcyBsYW5ndWFnZSBxdWl0ZSBhIGJpdCBmcm9tIHRoZSBpbXBs ZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZS4gSSB0aGluayB3ZSBuZWVkIHRvIGV4cGxpY2l0bHkgc3Rh dGUgDQo+IHRoYXQgZW5kcG9pbnRzIE1VU1QgcmV1c2UgdGhlIGV4aXN0aW5nIGFzc29jaWF0aW9u IGlmIHRoZSBrZXkgZmluZ2VycHJpbnQgdmFsdWVzIGFuZCB0cmFuc3BvcnQgcGFyYW1ldGVycyBp bmRpY2F0ZWQgDQo+IGJ5IGVhY2ggZW5kcG9pbnQgYXJlIHVuY2hhbmdlZC4NCg0KV2UgY291bGQg dGFrZSBzdWNoIGdlbmVyYWwgYXBwcm9hY2guDQoNCkhvd2V2ZXIsIGZvciDigJhTQ1RQL0RUTFPi gJkgKERUTFMgb3ZlciBTQ1RQKSwgSSBhc3N1bWUgdGhhdCB0aGUgRFRMUyBjb25uZWN0aW9uIHdp bGwgYWxzbyBiZSByZS1lc3RhYmxpc2hlZCBpZiB0aGUgdW5kZXJseWluZyBTQ1RQIGFzc29jaWF0 aW9uIGlzIHJlLWVzdGFibGlzaGVkIC0gZXZlbiBpZiBubyB0cmFuc3BvcnQgcGFyYW1ldGVycyBl dGMgYXJlIGNoYW5nZWQuDQoNCkFsc28sIFJGQyA2MDgzIHNheXM6DQoNCiAgICAgICAgICAgICAg ICDigJxFYWNoIERUTFMgY29ubmVjdGlvbiBNVVNUIGJlIGVzdGFibGlzaGVkIGFuZCB0ZXJtaW5h dGVkIHdpdGhpbiB0aGUgc2FtZSBTQ1RQIGFzc29jaWF0aW9uLuKAnQ0KDQoNCj4gVGhlIHdheSB0 aGlzIGxhbmd1YWdlIHJlYWRzIHRvIG1lIGlzIHRoYXQgZW5kcG9pbnRzIGNhbiByZXVzZSB0aGUg ZXhpc3RpbmcgYXNzb2NpYXRpb24gaWYgdGhleSB3YW50IHRvLCBidXQgdGhleSBjYW4gY3JlYXRl IGEgbmV3IG9uZSBpZiB0aGV5IGRvbid0LiBBbHNvLCB3aGVuIHRoaXMgbmV3IA0KPiBhc3NvY2lh dGlvbiBpcyBjcmVhdGVkLCBpdCBpcyB1bmNsZWFyIGlmIG9sZCBzZXR1cCByb2xlcyBNVVNUIGJl IHByZXNlcnZlZCBvciBpZiB0aGV5IE1VU1QgYmUgc2VsZWN0ZWQgYmFzZWQgb24gdGhlIGN1cnJl bnQgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLiBJdCBzZWVtcyB0aGUgY3VycmVudCANCj4gc3BlY2lm aWNhdGlvbiBsYW5ndWFnZSBpcyBub3Qgc3Ryb25nIG9yIGNsZWFyIGVub3VnaCBvbiB0aGlzIHRv cGljLg0KDQpJbiBteSBvcGluaW9uLCBJRiBhIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8g YmUgZXN0YWJsaXNoZWQgKGZvciB3aGF0ZXZlciByZWFzb25zKSwgdGhlIGN1cnJlbnQgcm9sZXMg c2hvdWxkIGJlIHVzZWQuDQoNCkJUVywgSSB0aGluayB0aGlzIHdob2xlIGRpc2N1c3Npb24gYmVs b25ncyB0byBNTVVTSUMsIGFzIGl0IGlzIE9mZmVyL0Fuc3dlciByZWxhdGVkIDopDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQo= From nobody Sun Nov 30 05:51:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF71A0173 for ; Sun, 30 Nov 2014 05:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpjTCrWCDTHa for ; Sun, 30 Nov 2014 05:50:59 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94641A0161 for ; Sun, 30 Nov 2014 05:50:59 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id B2D1CA8AAE774; Sun, 30 Nov 2014 13:50:55 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sAUDotwc009391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 08:50:55 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 08:50:55 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Roman Shpount Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JADRev2AAADmq4AAEYxBAAAL0YgAADmeW3A= Date: Sun, 30 Nov 2014 13:50:54 +0000 Deferred-Delivery: Sun, 30 Nov 2014 13:50:00 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9TSRpbWCMGuhGPaKmKCPcTBlfQI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 13:51:01 -0000 PiBIaSwNCj4gDQo+ID4+UkZDIDczNDUgKFVEUFRMLURUTFMpIHNheXMgdGhlIGZvbGxvd2luZzoN Cj4gPj4NCj4gPj7CoCDCoCDCoCDCoCAiT25jZSBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgaGFz IGJlZW4gY29tcGxldGVkLCBlaXRoZXIgZW5kcG9pbnQNCj4gTUFZDQo+ID4+wqAgwqAgwqAgwqAg c2VuZCBhIG5ldyBvZmZlciBpbiBvcmRlciB0byBtb2RpZnkgdGhlIHNlc3Npb24uwqAgVGhlIGVu ZHBvaW50cw0KPiBjYW4NCj4gPj7CoCDCoCDCoCDCoCByZXVzZSB0aGUgZXhpc3RpbmcgRFRMUyBh c3NvY2lhdGlvbiBpZiB0aGUga2V5IGZpbmdlcnByaW50IHZhbHVlcw0KPiBhbmQNCj4gPj7CoCDC oCDCoCDCoCB0cmFuc3BvcnQgcGFyYW1ldGVycyBpbmRpY2F0ZWQgYnkgZWFjaCBlbmRwb2ludCBh cmUgdW5jaGFuZ2VkLg0KPiA+PsKgIMKgIMKgIMKgIE90aGVyd2lzZSwgZm9sbG93aW5nIHRoZSBy dWxlcyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIvYW5zd2VyDQo+IGV4Y2hhbmdlLA0KPiA+PsKgIMKg IMKgIMKgIHRoZSBlbmRwb2ludHMgY2FuIG5lZ290aWF0ZSBhbmQgY3JlYXRlIGEgbmV3IERUTFMg YXNzb2NpYXRpb24gYW5kLA0KPiA+PsKgIMKgIMKgIMKgIG9uY2UgY3JlYXRlZCwgZGVsZXRlIHRo ZSBwcmV2aW91cyBEVExTIGFzc29jaWF0aW9uLCBmb2xsb3dpbmcgdGhlDQo+ID4+wqAgwqAgwqAg wqAgc2FtZSBydWxlcyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLsKgIEVh Y2ggZW5kcG9pbnQNCj4gPj7CoCDCoCDCoCDCoCBuZWVkcyB0byBiZSBwcmVwYXJlZCB0byByZWNl aXZlIGRhdGEgb24gYm90aCB0aGUgbmV3IGFuZCBvbGQgRFRMUw0KPiA+PsKgIMKgIMKgIMKgIGFz c29jaWF0aW9ucyBhcyBsb25nIGFzIGJvdGggYXJlIGFsaXZlLiINCj4gPj4NCj4gPj4gU28sIEkg Z3Vlc3MgdGhhdCBjYW4gYmUgcmVhZCBpbiBhIHdheSB0aGF0IHRoZSBzZXR1cCBhdHRyaWJ1dGUg YXMgc3VjaA0KPiBkb2VzIG5vdCBpbXBhY3QgcHJldmlvdXNseQ0KPiA+PiBuZWdvdGlhdGVkIFRM UyByb2xlcyAtIHVubGVzcyB0aGUga2V5IGZpbmdlcnByaW50IHZhbHVlcyBhbmQvb3IgdHJhbnNw b3J0DQo+IHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkLg0KPiA+Pg0KPiA+PiBUaGUgU0NUUC1TRFAg ZHJhZnQgY3VycmVudGx5IHNheXMgdGhhdCBhIHN1YnNlcXVlbnQgb2ZmZXIgbXVzdCBub3QgY2hh bmdlDQo+IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgcm9sZXMuIEJ1dCwgSSBndWVzcw0KPiA+ PiB3ZSBjb3VsZCBzYXkgc29tZXRoaW5nIHNpbWlsYXIgYXMgaW4gUkZDIDczNDUuDQo+ID4NCj4g PiBJIGhhdmUgc3RydWdnbGVkIHdpdGggdGhpcyBsYW5ndWFnZSBxdWl0ZSBhIGJpdCBmcm9tIHRo ZSBpbXBsZW1lbnRhdGlvbg0KPiBwZXJzcGVjdGl2ZS4gSSB0aGluayB3ZSBuZWVkIHRvIGV4cGxp Y2l0bHkgc3RhdGUNCj4gPiB0aGF0IGVuZHBvaW50cyBNVVNUIHJldXNlIHRoZSBleGlzdGluZyBh c3NvY2lhdGlvbiBpZiB0aGUga2V5IGZpbmdlcnByaW50DQo+IHZhbHVlcyBhbmQgdHJhbnNwb3J0 IHBhcmFtZXRlcnMgaW5kaWNhdGVkDQo+ID4gYnkgZWFjaCBlbmRwb2ludCBhcmUgdW5jaGFuZ2Vk Lg0KPiANCj4gV2UgY291bGQgdGFrZSBzdWNoIGdlbmVyYWwgYXBwcm9hY2guDQo+IA0KPiBIb3dl dmVyLCBmb3Ig4oCYU0NUUC9EVExT4oCZIChEVExTIG92ZXIgU0NUUCksIEkgYXNzdW1lIHRoYXQg dGhlIERUTFMgY29ubmVjdGlvbg0KPiB3aWxsIGFsc28gYmUgcmUtZXN0YWJsaXNoZWQgaWYgdGhl IHVuZGVybHlpbmcgU0NUUCBhc3NvY2lhdGlvbiBpcyByZS0NCj4gZXN0YWJsaXNoZWQgLSBldmVu IGlmIG5vIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGV0YyBhcmUgY2hhbmdlZC4NCj4gDQo+IEFsc28s IFJGQyA2MDgzIHNheXM6DQo+IA0KPiAgICAgICAgICAgICAgICAg4oCcRWFjaCBEVExTIGNvbm5l Y3Rpb24gTVVTVCBiZSBlc3RhYmxpc2hlZCBhbmQgdGVybWluYXRlZA0KPiB3aXRoaW4gdGhlIHNh bWUgU0NUUCBhc3NvY2lhdGlvbi7igJ0NCj4gDQo+IA0KPiA+IFRoZSB3YXkgdGhpcyBsYW5ndWFn ZSByZWFkcyB0byBtZSBpcyB0aGF0IGVuZHBvaW50cyBjYW4gcmV1c2UgdGhlIGV4aXN0aW5nDQo+ IGFzc29jaWF0aW9uIGlmIHRoZXkgd2FudCB0bywgYnV0IHRoZXkgY2FuIGNyZWF0ZSBhIG5ldyBv bmUgaWYgdGhleSBkb24ndC4NCj4gQWxzbywgd2hlbiB0aGlzIG5ldw0KPiA+IGFzc29jaWF0aW9u IGlzIGNyZWF0ZWQsIGl0IGlzIHVuY2xlYXIgaWYgb2xkIHNldHVwIHJvbGVzIE1VU1QgYmUgcHJl c2VydmVkDQo+IG9yIGlmIHRoZXkgTVVTVCBiZSBzZWxlY3RlZCBiYXNlZCBvbiB0aGUgY3VycmVu dCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuIEl0DQo+IHNlZW1zIHRoZSBjdXJyZW50DQo+ID4gc3Bl Y2lmaWNhdGlvbiBsYW5ndWFnZSBpcyBub3Qgc3Ryb25nIG9yIGNsZWFyIGVub3VnaCBvbiB0aGlz IHRvcGljLg0KPiANCj4gSW4gbXkgb3BpbmlvbiwgSUYgYSBuZXcgRFRMUyBjb25uZWN0aW9uIG5l ZWRzIHRvIGJlIGVzdGFibGlzaGVkIChmb3INCj4gd2hhdGV2ZXIgcmVhc29ucyksIHRoZSBjdXJy ZW50IHJvbGVzIHNob3VsZCBiZSB1c2VkLg0KDQo8UmFqdT4NCldoZW4gSUNFIGlzIE5PVCB1c2Vk LCBob3cgZG9lcyB0aGUgb2ZmZXJlciBrbm93IHRoYXQgdGhlIGFuc3dlcmVyIGRvZXMgbm90IGNo YW5nZSB0aGUgZmluZ2VycHJpbnQgYW5kL29yIHRyYW5zcG9ydCBwYXJhbWV0ZXJzPyBJIGd1ZXNz IGl0IGRvZXMgbm90IGtub3cuIFNvLCBvZmZlcmVyIGhhcyB0byBiZSBwcmVwYXJlZCBmb3IgbmV3 IERUTFMgYXNzb2NpYXRpb24gYnkgb2ZmZXJpbmcgYWN0cGFzcy4NCldoZW4gSUNFIGlzIHVzZWQs IHRoZSBhbnN3ZXJlciBjYW4ndCBjaGFuZ2UgdHJhbnNwb3J0IHBhcmFtZXRlciB1bmxlc3Mgb2Zm ZXJlciBkb2VzIElDRSByZXN0YXJ0ICh3aGljaCBjaGFuZ2VzIG9mZmVyZXIgdHJhbnNwb3J0IHBh cmFtZXRlcnMpOyBSZWYgWzFdIGlzIHZlcnkgY2xlYXIgb24gdGhpcyBpbmRpY2F0aW5nICJEVExT IGhhbmRzaGFrZSBwcm9jZWR1cmUgaXMgcmVwZWF0ZWQiLiBIb3dldmVyLCBldmVuIHdoZW4gSUNF IGlzIHVzZWQsIEkgZG8gbm90IGZpbmQgYW55IHJlc3RyaWN0aW9uIGFib3V0IGFuc3dlcmVyIG5v dCBjaGFuZ2luZyBmaW5nZXJwcmludC4gU28sIGV2ZW4gd2l0aG91dCBJQ0UgcmVzdGFydCBhbnN3 ZXJlciBjYW4gdHJpZ2dlciBhIERUTFMgcmVuZWdvdGlhdGlvbiBieSBjaGFuZ2luZyBpdHMgZmlu Z2VycHJpbnQuDQoNClRvIGNvbmNsdWRlIGFsbCB0aGlzLCBJTU8gd2hldGhlciBJQ0UgaXMgdXNl ZCBvciBub3QsIHNlbmRpbmcgYWN0cGFzcyBmb3IgYWxsIG5ldyBvZmZlcnMgbWF5IGJlIGNvdmVy IGFsbCBwb3NzaWJsZSBzY2VuYXJpb3MuDQoNClsxXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MzQ1I3BhZ2UtOA0KICAgSW4gdGhlIGNhc2Ugb2YgYW4gSUNFIHJlc3RhcnQsIHRoZSBE VExTDQogICBoYW5kc2hha2UgcHJvY2VkdXJlIGlzIHJlcGVhdGVkLCBhbmQgYSBuZXcgRFRMUyBh c3NvY2lhdGlvbiBpcw0KICAgY3JlYXRlZC4gIE9uY2UgdGhlIERUTFMgaGFuZHNoYWtlIGlzIGNv bXBsZXRlZCBhbmQgdGhlIG5ldyBEVExTDQogICBhc3NvY2lhdGlvbiBoYXMgYmVlbiBjcmVhdGVk LCB0aGUgcHJldmlvdXMgRFRMUyBhc3NvY2lhdGlvbiBpcw0KICAgZGVsZXRlZC4NCg0KPC9SYWp1 Pg0KDQpCUg0KUmFqdQ0K From nobody Sun Nov 30 06:21:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03BD1A01F6 for ; Sun, 30 Nov 2014 06:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-3xvm4SnoeS for ; Sun, 30 Nov 2014 06:21:00 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D551A0108 for ; Sun, 30 Nov 2014 06:20:59 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-0a-547b27c9a152 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8C.48.04231.9C72B745; Sun, 30 Nov 2014 15:20:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 15:20:57 +0100 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: "Makaraju, Maridi Raju (Raju)" , Christer Holmberg , Roman Shpount Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Sun, 30 Nov 2014 14:20:56 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje5J9eoQgz8/NS0aNl5htZhxYSqz xdp/7ewOzB6tz/ayeixZ8pPJ49aUggDmKC6blNSczLLUIn27BK6MffvusBTMUqhom/ORvYFx n1QXIweHhICJxJ+zhl2MnECmmMSFe+vZuhi5OIQEjjBKdC34yAzhLGGUuPLsCztIA5tAsETT XzeQuIjAAkaJdysXsoN0MwuoS9xZfA7MFhYwlZh0cRkTiC0iYCax8OQERghbT+LmlwssIDaL gKrEyZU9YHFeAV+JWd+esUMse88m0d10B6yIEeik76fWMEEsEJe49WQ+E8SpAhJL9pxnhrBF JV4+/scKYStJNC55wgpRbyDx/tx8ZghbW2LZwtfMEMsEJU7OfMIygVF0FpKxs5C0zELSMgtJ ywJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgbFzcMtv3R2Mq187HmIU4GBU4uHd8KMq RIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MC5Qir6uK1Dp zrYm9JTK7+Y6NtEj8//85g/aIPXly7+khdXMH3In5XGcvRjn47jitdTtnueaapOXHfGseGFc uKI54+yEuXXHV/Da+R5xzjAIfzoviOPnrR1HPXrm6tX1eu/lKOc6ePLym5Sq9UWTaq9nnT57 1vXiXv8dKX85d77QD1I+1LD18jQlluKMREMt5qLiRAD1j3eEfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y3TUxLbLonIbjgwh65ZqP5p7ygo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 14:21:02 -0000 On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote:=0A= >> Hi,=0A= >>=0A= >>>> RFC 7345 (UDPTL-DTLS) says the following:=0A= >>>>=0A= >>>> "Once an offer/answer exchange has been completed, either=0A= >>>> endpoint=0A= >> MAY=0A= >>>> send a new offer in order to modify the session. The=0A= >>>> endpoints=0A= >> can=0A= >>>> reuse the existing DTLS association if the key fingerprint=0A= >>>> values=0A= >> and=0A= >>>> transport parameters indicated by each endpoint are unchanged.=0A= >>>> Otherwise, following the rules for the initial offer/answer=0A= >> exchange,=0A= >>>> the endpoints can negotiate and create a new DTLS association=0A= >>>> and, once created, delete the previous DTLS association,=0A= >>>> following the same rules for the initial offer/answer exchange.=0A= >>>> Each endpoint needs to be prepared to receive data on both the=0A= >>>> new and old DTLS associations as long as both are alive."=0A= >>>>=0A= >>>> So, I guess that can be read in a way that the setup attribute=0A= >>>> as such=0A= >> does not impact previously=0A= >>>> negotiated TLS roles - unless the key fingerprint values and/or=0A= >>>> transport=0A= >> parameters are modified.=0A= >>>>=0A= >>>> The SCTP-SDP draft currently says that a subsequent offer must=0A= >>>> not change=0A= >> the previously negotiated roles. But, I guess=0A= >>>> we could say something similar as in RFC 7345.=0A= >>>=0A= >>> I have struggled with this language quite a bit from the=0A= >>> implementation=0A= >> perspective. I think we need to explicitly state=0A= >>> that endpoints MUST reuse the existing association if the key=0A= >>> fingerprint=0A= >> values and transport parameters indicated=0A= >>> by each endpoint are unchanged.=0A= >>=0A= >> We could take such general approach.=0A= >>=0A= >> However, for =91SCTP/DTLS=92 (DTLS over SCTP), I assume that the DTLS=0A= >> connection will also be re-established if the underlying SCTP=0A= >> association is re- established - even if no transport parameters=0A= >> etc are changed.=0A= >>=0A= >> Also, RFC 6083 says:=0A= >>=0A= >> =93Each DTLS connection MUST be established and terminated within the=0A= >> same SCTP association.=94=0A= >>=0A= >>=0A= >>> The way this language reads to me is that endpoints can reuse the=0A= >>> existing=0A= >> association if they want to, but they can create a new one if they=0A= >> don't. Also, when this new=0A= >>> association is created, it is unclear if old setup roles MUST be=0A= >>> preserved=0A= >> or if they MUST be selected based on the current offer/answer=0A= >> exchange. It seems the current=0A= >>> specification language is not strong or clear enough on this=0A= >>> topic.=0A= >>=0A= >> In my opinion, IF a new DTLS connection needs to be established=0A= >> (for whatever reasons), the current roles should be used.=0A= >=0A= > When ICE is NOT used, how does the offerer know that the=0A= > answerer does not change the fingerprint and/or transport parameters?=0A= > I guess it does not know. So, offerer has to be prepared for new DTLS=0A= > association by offering actpass. When ICE is used, the answerer can't=0A= > change transport parameter unless offerer does ICE restart (which=0A= > changes offerer transport parameters); Ref [1] is very clear on this=0A= > indicating "DTLS handshake procedure is repeated". However, even when=0A= > ICE is used, I do not find any restriction about answerer not=0A= > changing fingerprint. So, even without ICE restart answerer can=0A= > trigger a DTLS renegotiation by changing its fingerprint.=0A= >=0A= > To conclude all this, IMO whether ICE is used or not, sending actpass=0A= > for all new offers may be cover all possible scenarios.=0A= =0A= That is also my conclusion based on the discussion so far.=0A= =0A= I also think the JSEP draft as far as detailed out is correct, but info =0A= about how the implementation should behave for Subsequent answers is =0A= missing. Text saying that the role must be maintained (unless there is =0A= an ICE restart) should be put in there.=0A= From nobody Sun Nov 30 07:06:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6BA1A0368 for ; Sun, 30 Nov 2014 07:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTti7vXMwdbe for ; Sun, 30 Nov 2014 07:06:25 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6881A0362 for ; Sun, 30 Nov 2014 07:06:24 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id E998E3C5FA49B; Sun, 30 Nov 2014 15:06:20 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sAUF6KNH030818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 10:06:20 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 10:06:20 -0500 From: "Makaraju, Maridi Raju (Raju)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Christer Holmberg , Roman Shpount Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAEro8vQ Date: Sun, 30 Nov 2014 15:06:20 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vA7F_LVlBiDXxlaXgUo4oNjxKwg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 15:06:28 -0000 > On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote: > >> Hi, > >> > >>>> RFC 7345 (UDPTL-DTLS) says the following: > >>>> > >>>> "Once an offer/answer exchange has been completed, either > >>>> endpoint > >> MAY > >>>> send a new offer in order to modify the session. The > >>>> endpoints > >> can > >>>> reuse the existing DTLS association if the key fingerprint > >>>> values > >> and > >>>> transport parameters indicated by each endpoint are unchanged. > >>>> Otherwise, following the rules for the initial offer/answer > >> exchange, > >>>> the endpoints can negotiate and create a new DTLS association > >>>> and, once created, delete the previous DTLS association, > >>>> following the same rules for the initial offer/answer exchange. > >>>> Each endpoint needs to be prepared to receive data on both the > >>>> new and old DTLS associations as long as both are alive." > >>>> > >>>> So, I guess that can be read in a way that the setup attribute > >>>> as such > >> does not impact previously > >>>> negotiated TLS roles - unless the key fingerprint values and/or > >>>> transport > >> parameters are modified. > >>>> > >>>> The SCTP-SDP draft currently says that a subsequent offer must > >>>> not change > >> the previously negotiated roles. But, I guess > >>>> we could say something similar as in RFC 7345. > >>> > >>> I have struggled with this language quite a bit from the > >>> implementation > >> perspective. I think we need to explicitly state > >>> that endpoints MUST reuse the existing association if the key > >>> fingerprint > >> values and transport parameters indicated > >>> by each endpoint are unchanged. > >> > >> We could take such general approach. > >> > >> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the DTLS > >> connection will also be re-established if the underlying SCTP > >> association is re- established - even if no transport parameters > >> etc are changed. > >> > >> Also, RFC 6083 says: > >> > >> "Each DTLS connection MUST be established and terminated within the > >> same SCTP association." > >> > >> > >>> The way this language reads to me is that endpoints can reuse the > >>> existing > >> association if they want to, but they can create a new one if they > >> don't. Also, when this new > >>> association is created, it is unclear if old setup roles MUST be > >>> preserved > >> or if they MUST be selected based on the current offer/answer > >> exchange. It seems the current > >>> specification language is not strong or clear enough on this > >>> topic. > >> > >> In my opinion, IF a new DTLS connection needs to be established > >> (for whatever reasons), the current roles should be used. > > > > When ICE is NOT used, how does the offerer know that the > > answerer does not change the fingerprint and/or transport parameters? > > I guess it does not know. So, offerer has to be prepared for new DTLS > > association by offering actpass. When ICE is used, the answerer can't > > change transport parameter unless offerer does ICE restart (which > > changes offerer transport parameters); Ref [1] is very clear on this > > indicating "DTLS handshake procedure is repeated". However, even when > > ICE is used, I do not find any restriction about answerer not > > changing fingerprint. So, even without ICE restart answerer can > > trigger a DTLS renegotiation by changing its fingerprint. > > > > To conclude all this, IMO whether ICE is used or not, sending actpass > > for all new offers may be cover all possible scenarios. >=20 > That is also my conclusion based on the discussion so far. >=20 > I also think the JSEP draft as far as detailed out is correct, but info > about how the implementation should behave for Subsequent answers is > missing. Text saying that the role must be maintained (unless there is > an ICE restart) should be put in there. Hi Stefan, Looks like, there is some misunderstanding here. My conclusion is to includ= e actpass, but not the previously negotiated role, in all subsequent offers,= =20 not just during ICE-restarts. This is to handle the scenario of answerer changing fingerprint, which is allowed (i.e. not explicitly disallowed), in a more natural way by renegotiating the roles. Entity which wants to change finger= print may also want to renegotiate the role even when transport parameters are no= t changed. Also, when ICE is not used answerer can change transport parameters which n= eeds=20 renegotiation of roles. So, to have uniform rules for ICE (restart or not) and no ICE it is better = to send the role in subsequent offer as if it is an initial offer (i.e. actpas= s). BR Raju From nobody Sun Nov 30 07:26:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECC71A0367 for ; Sun, 30 Nov 2014 07:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM1LY00x_C1V for ; Sun, 30 Nov 2014 07:26:49 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0B31A0362 for ; Sun, 30 Nov 2014 07:26:47 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-da-547b3736481c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.CB.04231.6373B745; Sun, 30 Nov 2014 16:26:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 16:26:45 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Makaraju, Maridi Raju (Raju)" , Christer Holmberg , Roman Shpount Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Sun, 30 Nov 2014 15:26:45 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja6ZeXWIwc2tohYNG6+wWsy4MJXZ Yu2/dnYHZo/WZ3tZPZYs+cnkcWtKQQBzFJdNSmpOZllqkb5dAldGz+4LbAVfdCrO7DzD3MD4 WqWLkZNDQsBE4u+uHWwQtpjEhXvrgWwuDiGBI4wSUzpmskM4Sxgljs28BlbFJhAosXXfArAq EYEFjBLvVi5kB0kwC6hL3Fl8DswWFjCVmHRxGROILSJgJrHw5ARGCFtP4uaXCywgNouAqsT8 rtVgQ3kFfCV2//7JCLGtjUPi1b4LYM2MQDd9P7WGCWKBuMStJ/OZIG4VkFiy5zwzhC0q8fLx P1YIW0micckTVoh6PYkbU6ewQdjaEssWvmaGWCYocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCy rGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjJ+DW37r7mBc/drxEKMAB6MSD++GH1UhQqyJ ZcWVuYcYpTlYlMR5F52bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUdGQreWHwuHT1qvy rcIVBWfavDwsGXf2TuxB9xX1Wpd35tS4h95bFHJw8YLtmYyF5/9GrH/p41/bcTnyW+HRax/k A1aIBO2WKNyzPu7xlI3GxVO+5027fNF+V2PYxHh3z5vHnglxPV/ZKBP4+tGpun0309evrQjt El/ibXS1+MM07Sc/+Bcr71NiKc5INNRiLipOBADG/6W0gAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/34TPqVKS0Z3wKQQlbVXXWep00mA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 15:26:51 -0000 On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote:=0A= >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote:=0A= >>>> Hi,=0A= >>>>=0A= >>>>>> RFC 7345 (UDPTL-DTLS) says the following:=0A= >>>>>>=0A= >>>>>> "Once an offer/answer exchange has been completed, either=0A= >>>>>> endpoint=0A= >>>> MAY=0A= >>>>>> send a new offer in order to modify the session. The=0A= >>>>>> endpoints=0A= >>>> can=0A= >>>>>> reuse the existing DTLS association if the key fingerprint=0A= >>>>>> values=0A= >>>> and=0A= >>>>>> transport parameters indicated by each endpoint are unchanged.=0A= >>>>>> Otherwise, following the rules for the initial offer/answer=0A= >>>> exchange,=0A= >>>>>> the endpoints can negotiate and create a new DTLS association=0A= >>>>>> and, once created, delete the previous DTLS association,=0A= >>>>>> following the same rules for the initial offer/answer exchange.=0A= >>>>>> Each endpoint needs to be prepared to receive data on both the=0A= >>>>>> new and old DTLS associations as long as both are alive."=0A= >>>>>>=0A= >>>>>> So, I guess that can be read in a way that the setup attribute=0A= >>>>>> as such=0A= >>>> does not impact previously=0A= >>>>>> negotiated TLS roles - unless the key fingerprint values and/or=0A= >>>>>> transport=0A= >>>> parameters are modified.=0A= >>>>>>=0A= >>>>>> The SCTP-SDP draft currently says that a subsequent offer must=0A= >>>>>> not change=0A= >>>> the previously negotiated roles. But, I guess=0A= >>>>>> we could say something similar as in RFC 7345.=0A= >>>>>=0A= >>>>> I have struggled with this language quite a bit from the=0A= >>>>> implementation=0A= >>>> perspective. I think we need to explicitly state=0A= >>>>> that endpoints MUST reuse the existing association if the key=0A= >>>>> fingerprint=0A= >>>> values and transport parameters indicated=0A= >>>>> by each endpoint are unchanged.=0A= >>>>=0A= >>>> We could take such general approach.=0A= >>>>=0A= >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the DTLS=0A= >>>> connection will also be re-established if the underlying SCTP=0A= >>>> association is re- established - even if no transport parameters=0A= >>>> etc are changed.=0A= >>>>=0A= >>>> Also, RFC 6083 says:=0A= >>>>=0A= >>>> "Each DTLS connection MUST be established and terminated within the=0A= >>>> same SCTP association."=0A= >>>>=0A= >>>>=0A= >>>>> The way this language reads to me is that endpoints can reuse the=0A= >>>>> existing=0A= >>>> association if they want to, but they can create a new one if they=0A= >>>> don't. Also, when this new=0A= >>>>> association is created, it is unclear if old setup roles MUST be=0A= >>>>> preserved=0A= >>>> or if they MUST be selected based on the current offer/answer=0A= >>>> exchange. It seems the current=0A= >>>>> specification language is not strong or clear enough on this=0A= >>>>> topic.=0A= >>>>=0A= >>>> In my opinion, IF a new DTLS connection needs to be established=0A= >>>> (for whatever reasons), the current roles should be used.=0A= >>>=0A= >>> When ICE is NOT used, how does the offerer know that the=0A= >>> answerer does not change the fingerprint and/or transport parameters?= =0A= >>> I guess it does not know. So, offerer has to be prepared for new DTLS= =0A= >>> association by offering actpass. When ICE is used, the answerer can't= =0A= >>> change transport parameter unless offerer does ICE restart (which=0A= >>> changes offerer transport parameters); Ref [1] is very clear on this=0A= >>> indicating "DTLS handshake procedure is repeated". However, even when= =0A= >>> ICE is used, I do not find any restriction about answerer not=0A= >>> changing fingerprint. So, even without ICE restart answerer can=0A= >>> trigger a DTLS renegotiation by changing its fingerprint.=0A= >>>=0A= >>> To conclude all this, IMO whether ICE is used or not, sending actpass= =0A= >>> for all new offers may be cover all possible scenarios.=0A= >>=0A= >> That is also my conclusion based on the discussion so far.=0A= >>=0A= >> I also think the JSEP draft as far as detailed out is correct, but info= =0A= >> about how the implementation should behave for Subsequent answers is=0A= >> missing. Text saying that the role must be maintained (unless there is= =0A= >> an ICE restart) should be put in there.=0A= >=0A= > =0A= > Hi Stefan,=0A= > Looks like, there is some misunderstanding here.=0A= =0A= Probably my fault in that case :)=0A= =0A= > My conclusion is to include=0A= > actpass, but not the previously negotiated role, in all subsequent offers= ,=0A= > not just during ICE-restarts.=0A= =0A= I think that is what the JSEP draft says - and my conclusion is that it =0A= _is_ correct.=0A= =0A= My point was that the _answer_ should (when it is a subsequent answer) =0A= should say the same role as in previous answers (unless there is an ICE =0A= restart).=0A= =0A= > This is to handle the scenario of answerer changing fingerprint, which=0A= > is allowed (i.e. not explicitly disallowed), in a more=0A= > natural way by renegotiating the roles. Entity which wants to change fing= erprint=0A= > may also want to renegotiate the role even when transport parameters are = not changed.=0A= >=0A= > Also, when ICE is not used answerer can change transport parameters which= needs=0A= > renegotiation of roles.=0A= >=0A= > So, to have uniform rules for ICE (restart or not) and no ICE it is bette= r to=0A= > send the role in subsequent offer as if it is an initial offer (i.e. actp= ass).=0A= =0A= That is also my understanding (and what the JSEP draft says).=0A= =0A= > =0A= >=0A= > BR=0A= > Raju=0A= >=0A= >=0A= =0A= From nobody Sun Nov 30 07:29:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563D31A0367 for ; Sun, 30 Nov 2014 07:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEfFNlc2LgA5 for ; Sun, 30 Nov 2014 07:29:09 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37C11A0362 for ; Sun, 30 Nov 2014 07:29:08 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-db-547b37c2ae6d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.00.29772.2C73B745; Sun, 30 Nov 2014 16:29:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 16:29:06 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , "Makaraju, Maridi Raju (Raju)" , "Roman Shpount" Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAEtdFdA Date: Sun, 30 Nov 2014 15:29:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D55BDBE@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje4h8+oQg5aL6hYNG6+wWsy4MJXZ Yu2/dnYHZo/WZ3tZPZYs+cnkcWtKQQBzFJdNSmpOZllqkb5dAlfG82N3GAu6dCt+d3xja2Dc o9LFyMkhIWAisenWBmYIW0ziwr31bCC2kMARRokzJ8y6GLmA7CWMEj//PWXvYuTgYBOwkOj+ pw0SFxHYySjxYccxFpAGZgF1iTuLz7GD2MICphLv5x4BGyoiYCax8OQERgjbSKK1ayoTiM0i oCrx6NlJsBpeAV+JhXNAekGWneKQWPLkC9hQTgE/iTN7r4FdxAh03fdTa5gglolL3Hoynwni agGJJXvOQ30gKvHy8T9WCFtJYsX2S4wQ9XoSN6ZOYYOwtSWWLXwNtVhQ4uTMJywTGMVmIRk7 C0nLLCQts5C0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGFMHt/w22MH48rnjIUYB DkYlHt4NP6pChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o/hct6aUXS9OXEmo+HF517TVt3OO12v2cLAqeVvXzWo9rvhObLaGjLiYhIVAd76Z4sljc4Im bf38lrmwY4lPr6BaVYgSR9WX/XujXhZ/k3q7+U7E7X/7DPb/dmphWcZgYXt/xQzfzVXVZefU uwNlHXrvPWY1eKfetiHv9pWvT28JWealX3gnocRSnJFoqMVcVJwIAM1CKNCKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WC1YfmLFWKL2Tlb87nuzob0qxL0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 15:29:11 -0000 Hi, If some clarification regarding this is needed, I don't think it should be = in the JSEP draft. If it's related to SDP Offer/Answer in general, it should be in an MMUSIC s= pec, referenced by JSEP. Regards, Christer -----Original Message----- From: Stefan H=E5kansson LK=20 Sent: 30 November 2014 17:27 To: Makaraju, Maridi Raju (Raju); Christer Holmberg; Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Why always offer actpass? On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote: >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote: >>>> Hi, >>>> >>>>>> RFC 7345 (UDPTL-DTLS) says the following: >>>>>> >>>>>> "Once an offer/answer exchange has been completed, either=20 >>>>>> endpoint >>>> MAY >>>>>> send a new offer in order to modify the session. The endpoints >>>> can >>>>>> reuse the existing DTLS association if the key fingerprint values >>>> and >>>>>> transport parameters indicated by each endpoint are unchanged. >>>>>> Otherwise, following the rules for the initial offer/answer >>>> exchange, >>>>>> the endpoints can negotiate and create a new DTLS association=20 >>>>>> and, once created, delete the previous DTLS association,=20 >>>>>> following the same rules for the initial offer/answer exchange. >>>>>> Each endpoint needs to be prepared to receive data on both the=20 >>>>>> new and old DTLS associations as long as both are alive." >>>>>> >>>>>> So, I guess that can be read in a way that the setup attribute as=20 >>>>>> such >>>> does not impact previously >>>>>> negotiated TLS roles - unless the key fingerprint values and/or=20 >>>>>> transport >>>> parameters are modified. >>>>>> >>>>>> The SCTP-SDP draft currently says that a subsequent offer must=20 >>>>>> not change >>>> the previously negotiated roles. But, I guess >>>>>> we could say something similar as in RFC 7345. >>>>> >>>>> I have struggled with this language quite a bit from the=20 >>>>> implementation >>>> perspective. I think we need to explicitly state >>>>> that endpoints MUST reuse the existing association if the key=20 >>>>> fingerprint >>>> values and transport parameters indicated >>>>> by each endpoint are unchanged. >>>> >>>> We could take such general approach. >>>> >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the DTLS=20 >>>> connection will also be re-established if the underlying SCTP=20 >>>> association is re- established - even if no transport parameters=20 >>>> etc are changed. >>>> >>>> Also, RFC 6083 says: >>>> >>>> "Each DTLS connection MUST be established and terminated within the=20 >>>> same SCTP association." >>>> >>>> >>>>> The way this language reads to me is that endpoints can reuse the=20 >>>>> existing >>>> association if they want to, but they can create a new one if they=20 >>>> don't. Also, when this new >>>>> association is created, it is unclear if old setup roles MUST be=20 >>>>> preserved >>>> or if they MUST be selected based on the current offer/answer=20 >>>> exchange. It seems the current >>>>> specification language is not strong or clear enough on this=20 >>>>> topic. >>>> >>>> In my opinion, IF a new DTLS connection needs to be established=20 >>>> (for whatever reasons), the current roles should be used. >>> >>> When ICE is NOT used, how does the offerer know that the=20 >>> answerer does not change the fingerprint and/or transport parameters? >>> I guess it does not know. So, offerer has to be prepared for new=20 >>> DTLS association by offering actpass. When ICE is used, the answerer=20 >>> can't change transport parameter unless offerer does ICE restart=20 >>> (which changes offerer transport parameters); Ref [1] is very clear=20 >>> on this indicating "DTLS handshake procedure is repeated". However,=20 >>> even when ICE is used, I do not find any restriction about answerer=20 >>> not changing fingerprint. So, even without ICE restart answerer can=20 >>> trigger a DTLS renegotiation by changing its fingerprint. >>> >>> To conclude all this, IMO whether ICE is used or not, sending=20 >>> actpass for all new offers may be cover all possible scenarios. >> >> That is also my conclusion based on the discussion so far. >> >> I also think the JSEP draft as far as detailed out is correct, but=20 >> info about how the implementation should behave for Subsequent=20 >> answers is missing. Text saying that the role must be maintained=20 >> (unless there is an ICE restart) should be put in there. > > > Hi Stefan, > Looks like, there is some misunderstanding here. Probably my fault in that case :) > My conclusion is to include > actpass, but not the previously negotiated role, in all subsequent=20 > offers, not just during ICE-restarts. I think that is what the JSEP draft says - and my conclusion is that it _is= _ correct. My point was that the _answer_ should (when it is a subsequent answer) shou= ld say the same role as in previous answers (unless there is an ICE restart= ). > This is to handle the scenario of answerer changing fingerprint, which=20 > is allowed (i.e. not explicitly disallowed), in a more natural way by=20 > renegotiating the roles. Entity which wants to change fingerprint may=20 > also want to renegotiate the role even when transport parameters are not = changed. > > Also, when ICE is not used answerer can change transport parameters=20 > which needs renegotiation of roles. > > So, to have uniform rules for ICE (restart or not) and no ICE it is=20 > better to send the role in subsequent offer as if it is an initial offer = (i.e. actpass). That is also my understanding (and what the JSEP draft says). > > > BR > Raju > > From nobody Sun Nov 30 09:18:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFB91A1A36 for ; Sun, 30 Nov 2014 09:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XpvdjRng7tJ for ; Sun, 30 Nov 2014 09:18:09 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61401A1A2D for ; Sun, 30 Nov 2014 09:18:08 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id A8059BE125A14; Sun, 30 Nov 2014 17:18:02 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id sAUHI103013513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 12:18:03 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 12:18:02 -0500 From: "Makaraju, Maridi Raju (Raju)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Christer Holmberg , Roman Shpount Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAExDhxg Date: Sun, 30 Nov 2014 17:18:02 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4k9uXw82-WC0J6o6eRxcKLbV0mU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 17:18:11 -0000 > >>> When ICE is NOT used, how does the offerer know that the > >>> answerer does not change the fingerprint and/or transport parameters? > >>> I guess it does not know. So, offerer has to be prepared for new DTLS > >>> association by offering actpass. When ICE is used, the answerer can't > >>> change transport parameter unless offerer does ICE restart (which > >>> changes offerer transport parameters); Ref [1] is very clear on this > >>> indicating "DTLS handshake procedure is repeated". However, even when > >>> ICE is used, I do not find any restriction about answerer not > >>> changing fingerprint. So, even without ICE restart answerer can > >>> trigger a DTLS renegotiation by changing its fingerprint. > >>> > >>> To conclude all this, IMO whether ICE is used or not, sending actpass > >>> for all new offers may be cover all possible scenarios. > >> > >> That is also my conclusion based on the discussion so far. > >> > >> I also think the JSEP draft as far as detailed out is correct, but inf= o > >> about how the implementation should behave for Subsequent answers is > >> missing. Text saying that the role must be maintained (unless there is > >> an ICE restart) should be put in there. > > > > > > Hi Stefan, > > Looks like, there is some misunderstanding here. >=20 > Probably my fault in that case :) >=20 > > My conclusion is to include > > actpass, but not the previously negotiated role, in all subsequent offe= rs, > > not just during ICE-restarts. >=20 > I think that is what the JSEP draft says - and my conclusion is that it > _is_ correct. >=20 > My point was that the _answer_ should (when it is a subsequent answer) > should say the same role as in previous answers (unless there is an ICE > restart). Hi Stefan, Sorry, it was my misunderstanding in not reading your text correctly. I did not pay attention to "_answer_" part. I agree with you that subsequent answers SHOULD (not MUST) keep=20 previously negotiated role (except for ICE restarts). However, as Christer pointed out such clarification belong to SCTP=20 SDP draft though. BR Raju From nobody Sun Nov 30 11:44:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF221A1A7B for ; Sun, 30 Nov 2014 11:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDHIFK0FSsXj for ; Sun, 30 Nov 2014 11:44:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC55B1A1A7A for ; Sun, 30 Nov 2014 11:44:07 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id B09838A0A3629 for ; Sun, 30 Nov 2014 19:44:00 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id sAUJi1n5031050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 30 Nov 2014 14:44:03 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 14:44:01 -0500 From: "Makaraju, Maridi Raju (Raju)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt Thread-Index: AQHQCw3w2ia/yona0k6xAQgNHvOCYJx5bwHQ Date: Sun, 30 Nov 2014 19:44:01 +0000 Message-ID: References: <20141128131903.18180.87191.idtracker@ietfa.amsl.com> In-Reply-To: <20141128131903.18180.87191.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6yoRcta8CIwXfNatBQ6OEGblkak Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 19:44:09 -0000 >A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is >s= omething that conforms to both the protocol specification and the >Javascript API defined above. Thanks for adding updates to the terminology, which now captures most of it. I have a comment on the above text in 2.2. This seem to focus more on WebRTC **browser**. But, there are hybrid environments, such as Apache Cordova, which are not browsers but can conform to protocol specification and Javascript API just like a=20 browser (as most of the times they share same source code as a browser). An= droid KitKat provided WebView component, that supports WebRTC APIs+Javascri= pt, is one example which is close to native than hybrid environment. To inc= lude these use cases, I suggest changing the above text to: "A WebRTC User Agent or WebRTC UA is something that conforms to both the pr= otocol specification and the Javascript API defined above. WebRTC browser i= s one such WebRTC UA. However, other non-browser implementations may confor= m to WebRTC UA as well." BR Raju > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, November 28, 2014 7:19 AM > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. >=20 > Title : Overview: Real Time Protocols for Browser-based > Applications > Author : Harald T. Alvestrand > Filename : draft-ietf-rtcweb-overview-13.txt > Pages : 22 > Date : 2014-11-28 >=20 > Abstract: > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". >=20 > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. >=20 > This document is an Applicability Statement - it does not itself > specify any protocol, but specifies which other specifications WebRTC > compliant implementations are supposed to follow. >=20 > This document is a work item of the RTCWEB working group. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-13 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-overview-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Nov 30 16:14:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68C1A1ACC for ; Sun, 30 Nov 2014 16:14:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlbNKFKOawzr for ; Sun, 30 Nov 2014 16:14:02 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF5E1A1AB4 for ; Sun, 30 Nov 2014 16:14:02 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-86-547bb2c7fcfc Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.D6.04076.7C2BB745; Mon, 1 Dec 2014 01:13:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 01:13:59 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt Thread-Index: AQHQCw33rKA6xe5U90+II1GYD2bsSpx5hRuAgABcMLs= Date: Mon, 1 Dec 2014 00:13:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D55D88D@ESESSMB209.ericsson.se> References: <20141128131903.18180.87191.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D55D88DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje7xTdUhBnPWGFk0bLzCarH2Xzu7 A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYtGILS8HCyIpTL76yNjB2+HQxcnJICJhI XO3/xQhhi0lcuLeerYuRi0NI4AijxNsrf5ggnMWMEtO+7wKq4uBgE7CQ6P6nDdIgIpAjsfBW AyuILSzgLNF++RUzRNxFovHAfCjbSqL91EYmEJtFQEXiwp/bYHFeAV+Js/f+s0DMn8Qo8bv1 MtgVnAKxErfbV4PZjEAXfT+1BqyZWUBcounLSlaISwUkluw5zwxhi0q8fPyPFaImX2LF3Sls EAsEJU7OfMIygVF4FpL2WUjKZiEpg4gbSHx5fxvK1pZYtvA1M4StL9H9/jQTsvgCRvZVjKLF qcXFuelGRnqpRZnJxcX5eXp5qSWbGIERdHDLb6sdjAefOx5iFOBgVOLhLVhYHSLEmlhWXJl7 iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhTNzretfKo196+tniV153u hJzH/PlnX2YfNOXW2ijSz3B5/8xAG7N1ngd+HL55tFdE1ntLnajotY1iwWcWReZa6J12fvWi smpyiSXvpx3nhXNuqW4q2bbNs+SA4EuuixfUL4Xs4Uvkuubyy9Y1+KBTce3f6J27b8XPFHiw RvHBIq6NN29HW25RYinOSDTUYi4qTgQAUOiS04ECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jyOjalaFeqT8x7caO0YtHy0kEzw Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 00:14:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D55D88DESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, My understanding from Honolulu was that we were NOT going to talk about "We= bRTC User Agents" - we were going to talk about "WebRTC browsers" and "WebR= TC non-browsers". Regards, Christer Sent from my Windows Phone ________________________________ From: Makaraju, Maridi Raju (Raju) Sent: =FD30/=FD11/=FD2014 21:44 To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt >A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is >s= omething that conforms to both the protocol specification and the >Javascript API defined above. Thanks for adding updates to the terminology, which now captures most of it. I have a comment on the above text in 2.2. This seem to focus more on WebRTC **browser**. But, there are hybrid environments, such as Apache Cordova, which are not browsers but can conform to protocol specification and Javascript API just like a browser (as most of the times they share same source code as a browser). An= droid KitKat provided WebView component, that supports WebRTC APIs+Javascri= pt, is one example which is close to native than hybrid environment. To inc= lude these use cases, I suggest changing the above text to: "A WebRTC User Agent or WebRTC UA is something that conforms to both the pr= otocol specification and the Javascript API defined above. WebRTC browser i= s one such WebRTC UA. However, other non-browser implementations may confor= m to WebRTC UA as well." BR Raju > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, November 28, 2014 7:19 AM > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : Overview: Real Time Protocols for Browser-based > Applications > Author : Harald T. Alvestrand > Filename : draft-ietf-rtcweb-overview-13.txt > Pages : 22 > Date : 2014-11-28 > > Abstract: > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This document is an Applicability Statement - it does not itself > specify any protocol, but specifies which other specifications WebRTC > compliant implementations are supposed to follow. > > This document is a work item of the RTCWEB working group. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-overview-13 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1D55D88DESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

My understanding from Honolulu was that we were NOT going to talk about &qu= ot;WebRTC User Agents" - we were going to talk about "WebRTC brow= sers" and "WebRTC non-browsers".

Regards,

Christer

Sent from my Windows Phone
From: Makaraju, Maridi Raju (Raju)=
Sent: =FD30= /=FD11/=FD2014 21:44
To: rtcweb@ietf.org
Subject: Re: [= rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt


>A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is = ;     >something that conforms to both the protocol = specification and the
>Javascript API defined above.

Thanks for adding updates to the terminology, which now captures most
of it.
I have a comment on the above text in 2.2.

This seem to focus more on WebRTC **browser**. But, there are hybrid
environments, such as Apache Cordova, which are not browsers but can
conform to protocol specification and Javascript API just like a
browser (as most of the times they share same source code as a browser). An= droid KitKat provided WebView component, that supports WebRTC APIs+Java= script, is one example which is close to native than hybrid environment. To= include these use cases, I suggest changing the above text to:

"A WebRTC User Agent or WebRTC UA is something that conforms to both t= he protocol specification and the Javascript API defined above. WebRTC brow= ser is one such WebRTC UA. However, other non-browser implementations may c= onform to WebRTC UA as well."

BR
Raju

> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, November 28, 2014 7:19 AM
> To: i-d-announce@ietf.org
> Cc: rtcweb@ietf.org
> Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Real-Time Communication in WEB-= browsers
> Working Group of the IETF.
>
>         Title   = ;        : Overview: Real Time Protocols= for Browser-based
> Applications
>         Author  &nbs= p;       : Harald T. Alvestrand
>        Filename   &n= bsp;    : draft-ietf-rtcweb-overview-13.txt
>        Pages    = ;       : 22
>        Date    =         : 2014-11-28
>
> Abstract:
>    This document gives an overview and context of a pro= tocol suite
>    intended for use with real-time applications that ca= n be deployed in
>    browsers - "real time communication on the Web&= quot;.
>
>    It intends to serve as a starting and coordination p= oint to make sure
>    all the parts that are needed to achieve this goal a= re findable, and
>    that the parts that belong in the Internet protocol = suite are fully
>    specified and on the right publication track.
>
>    This document is an Applicability Statement - it doe= s not itself
>    specify any protocol, but specifies which other spec= ifications WebRTC
>    compliant implementations are supposed to follow. >
>    This document is a work item of the RTCWEB working g= roup.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/
>
> There's also a htmlized version available at:
> h= ttp://tools.ietf.org/html/draft-ietf-rtcweb-overview-13
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-overview-13=
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/int= ernet-drafts/
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_7594FB04B1934943A5C02806D1A2204B1D55D88DESESSMB209erics_--