From junluan.xia@intel.com Tue Oct 1 01:08:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCF821F9C53 for ; Tue, 1 Oct 2013 01:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.378 X-Spam-Level: X-Spam-Status: No, score=-8.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq+kLUME3r3f for ; Tue, 1 Oct 2013 01:08:35 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 551C221F9C52 for ; Tue, 1 Oct 2013 01:08:32 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 01 Oct 2013 01:08:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,1012,1371106800"; d="scan'208,217";a="368122834" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by azsmga001.ch.intel.com with ESMTP; 01 Oct 2013 01:08:31 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 1 Oct 2013 01:08:30 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 1 Oct 2013 01:08:30 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.4]) by SHSMSX101.ccr.corp.intel.com ([10.239.4.153]) with mapi id 14.03.0123.003; Tue, 1 Oct 2013 16:08:29 +0800 From: "Xia, Junluan" To: "rtcweb@ietf.org" Thread-Topic: unsubscribe Thread-Index: Ac6+fWk6tf/BTQLkTwmqV6Yj13cv2Q== Date: Tue, 1 Oct 2013 08:08:29 +0000 Message-ID: <7841A4E0A9C8784C9D8B07DF5E48F0A811602434@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: multipart/alternative; boundary="_000_7841A4E0A9C8784C9D8B07DF5E48F0A811602434SHSMSX104ccrcor_" MIME-Version: 1.0 Subject: [rtcweb] unsubscribe X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 08:08:40 -0000 --_000_7841A4E0A9C8784C9D8B07DF5E48F0A811602434SHSMSX104ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable regards, Andrew --_000_7841A4E0A9C8784C9D8B07DF5E48F0A811602434SHSMSX104ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

regards,

Andrew

 

--_000_7841A4E0A9C8784C9D8B07DF5E48F0A811602434SHSMSX104ccrcor_-- From magnus.westerlund@ericsson.com Tue Oct 1 04:49:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FA321F93E1 for ; Tue, 1 Oct 2013 04:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q98Atuh5HaVG for ; Tue, 1 Oct 2013 04:49:47 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC921F9F9D for ; Tue, 1 Oct 2013 04:49:46 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-a0-524ab6d92d5e Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 14.96.03802.9D6BA425; Tue, 1 Oct 2013 13:49:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.146) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Tue, 1 Oct 2013 13:49:45 +0200 Message-ID: <524AB730.7040809@ericsson.com> Date: Tue, 1 Oct 2013 13:51:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Stahl References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> In-Reply-To: <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre7NbV5BBi8OKFhsvjmJ0eJdz1o2 i7X/2tkdmD2WLPnJ5PFp63wWjy+XP7MFMEdx2aSk5mSWpRbp2yVwZbybdpaxYKJAxcQNC5ka GP/zdDFyckgImEicWryRHcIWk7hwbz1bFyMXh5DAYUaJJfOmM0I4yxglbi65xAhSxSugLTHz RRMTiM0ioCJx58oGMJtNwELi5o9GNhBbVCBYon37VzaIekGJkzOfsIDYIgLqEtPOnwKLMwuE Sfw5tAMsLgxkN387AbXsNJPEm93HWEESnAIOEudWLoM6T1Ji26Jj7BDNehJTrrYwQtjyEtvf zmEGsYWAjmto6mCdwCg0C8nuWUhaZiFpWcDIvIqRPTcxMye93GgTIzCED275rbqD8c45kUOM 0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgNO+W3/TK9JP7EY/lvy/6m7YI a7ifjC5ZsPTxJqez/RJZa//rqaQ1yNe7uc7nMFP/nWL08ULhl4hfS5Zw7P/rwR9QcVhoFVeY UHqe5Yyzgs58k1OctW+rTSmZm2oXHS3YOmPK7MdyFo7zbrWIxD8W/XyKYUJr6e/rOllvf/FI rVj6WEoodt4yJZbijERDLeai4kQADPE47y8CAAA= Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 11:49:52 -0000 Hi Karl, I just want to provide a comment on your below suggestion. On 2013-09-21 23:44, Karl Stahl wrote: > Yet another thing related to > draft-ietf-rtcweb-use-cases-and-requirements-11: > It is about payload type, PT=, in SDP and RTP, so I am copying MMUSIC > > Network service providers have expressed an interest to know whether packets > carry audio or video, to be able to handle them differently in the network > (e.g. quality wise). PT is visible outside the encrypted payload in RTP, > however if dynamic payload types PT:96-127 are used, you cannot know what > the payload is without knowledge of the SDP (which we for WebRTC must assume > the network provider has no knowledge of). > > In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I see > no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC. > > So, can we have payload types assigned to codecs that will be recommended > for WebRTC (PT:35-71 are unassigned)? And this is because over 10 years ago we (IETF) stopped assigning static payload types, actually forbid future static assignments. All payload types are assumed to be dynamically assigned in RTCWEB. The reason is that we have more codecs and codec configurations than there is PT space. > Or can we at least split dynamic payload types PT:96-127 into groups for > audio and video codecs? That assumes that one understand how many of each there is going to be. You also have the supplemental payload types, like RTP Retransmission that has a one to one binding with another payload type in the RTP session. So how should one do this split without being significantly restricted in how you use the payload type space. I personally see that the 96-127 space will be insufficient in quite many cases due to the combination of supporting a number of audio and video codes combined with retransmission and FEC. I don't really dare doing a split, as I would have to live with it for the foreseeable future, and it would inevitable be wrong. Cheers Magnus From saverio.vardaro@gmail.com Tue Oct 1 09:02:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B015121E8085 for ; Tue, 1 Oct 2013 09:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-Ht3HOWZJDs for ; Tue, 1 Oct 2013 09:02:32 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 66B7321E81B9 for ; Tue, 1 Oct 2013 09:01:31 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id i1so4956664oag.20 for ; Tue, 01 Oct 2013 09:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GufkPGTeqWxpAIGjCFKvA5YpvUDnrATm12YijMGeajw=; b=uTNEy3wSpYcZx+vsxPTn57PrHjKZk+oAJIvYbT2U/DeQ51yYcRQL44v7TMYF+tAUrM +0ILaEDOVtcnPItGfyeN7IhjSGg/26dkWbOq/fLIzAAVZZ+BbC3KL66EGEcZ/6GfLMob BNj5zVmXkXhn7JN/sfYGit9gKHWCzf0CKq+kCpW6QEHbEQ0YBu4sPP7oNu6mVOElreQe 30RmpTjDA9z30NIzJgijYUZEru8MRUUH1vOwZMNnmicHh3r9uQFhzfPJYf8EoyVd5Jth X+aySYzrhHY8leqYLYAk/RD6LaMOKV+7cMl2HwWjdjBCpz4FKP6SxAZPFvkLzq6zEcDJ pVBg== MIME-Version: 1.0 X-Received: by 10.60.116.230 with SMTP id jz6mr27415780oeb.21.1380643284294; Tue, 01 Oct 2013 09:01:24 -0700 (PDT) Received: by 10.60.27.198 with HTTP; Tue, 1 Oct 2013 09:01:24 -0700 (PDT) In-Reply-To: <5245c4af.8908420a.33f6.ffff8025SMTPIN_ADDED_BROKEN@mx.google.com> References: <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> <52445257.8581700a.36b0.fffff687SMTPIN_ADDED_BROKEN@mx.google.com> <5245c4af.8908420a.33f6.ffff8025SMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 1 Oct 2013 18:01:24 +0200 Message-ID: From: Saverio Vardaro To: Karl Stahl Content-Type: multipart/alternative; boundary=089e0115e84a85a8b804e7b01010 Cc: fluffy@cisco.com, rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:02:48 -0000 --089e0115e84a85a8b804e7b01010 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Sep 27, 2013 at 7:47 PM, Karl Stahl wrote: > > Does your mobile provider currently do reverse dns for your mobile's > real ip address?**** > > >CB**** > > Good question and the answer is good: Yes**** > > We just checked both major 3G mobile operators TeleaSonera and Tele2 in > Sweden.**** > > E.g. just surfing to http://whatismyipaddress.com **** > > (which tells me it is TeliaSonera, Wireless Broadband)**** > > Then clicking the =93Additional IP Details=94 button, I get the PTR recor= d:*** > * > > host-95-199-196-65.mobileonline.telia.com**** > > Tele2 gave: m83-186-15-99.cust.tele2.se**** > > ** ** > > So, obviously mobile providers have ways of provisioning these kind of > things in DNS.**** > > ** ** > > How does it look in other places of the world?**** > > ** > [SV] This is NOT the case for Vodafone Italy > ** > > /Karl**** > > ** ** > > ** ** > > *Fr=E5n:* cb.list6 [mailto:cb.list6@gmail.com] > *Skickat:* den 27 september 2013 01:06 > *Till:* Karl Stahl > *Kopia:* fluffy@cisco.com; rtcweb@ietf.org; > draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; > Markus.Isomaki@nokia.com > *=C4mne:* Re: SV: [rtcweb] TURN server address via DHCP, WGLC of > draft-ietf-rtcweb-use-cases-and-requirements-11**** > > ** ** > > > On Sep 26, 2013 8:27 AM, "Karl Stahl" wrote: > > > > Here comes the suggestion I got from my developer that would allow a > network > > provider to offer his TURN server for the WebRTC browser to use. This > would > > require NO new DHCP-options or similar, and NO OS changes (I do realize > > those should be avoided if possible...). > > > > The idea is still, that whoever is responsible for giving a device an I= P > > address (the network provider or a LAN administrator) can also announce= a > > TURN server for the WebRTC browser to use. > > > > The suggestion is to use RFC6763 (DNS-Based Service Discovery, see > chapter > > 11) where the network provider (the owner of the IP address) has set up= a > > DNS PTR record for the TURN server in the in-addr.arpa domain. > > > > If the device got IP 173.164.252.149, then make a query for the PTR > record > > for: > > _turn._udp.149.252.164.173.in-addr.arpa. > > Then the SRV record would return the actual address to the TURN server > (and > > you may find several for load balancing and failover I guess) > > > > If the device is on a LAN, the IP 173.164.252.149 to query would be the > WAN > > IP you get via STUN in the ICE process. But if the LAN administrator > > provides a local TURN server, then he also should have blocked STUN in > the > > firewall, and the browser should query the device's local host address > (as > > in the ICE procedure) and the local LAN DNS server should answer the > query > > to give the local TURN server address on the LAN. > > > > Shouldn't this work to allow network provider to offer his TURN server > > "automatically and generally"? > > > > And wouldn't this work nicely for mobile devices, whenever the device i= s > on > > a "WebRTC-ready access" (actually good for everything using ICE), wheth= er > > fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network > > provider hopefully offers a prioritized pipe there as one usage of this > > mechanism). > >**** > > Does your mobile provider currently do reverse dns for your mobile's real > ip address?**** > > CB**** > > > Not to slow down every call setup by doing this in the ICE process, I > guess > > this could be done when starting the browser and when the device gets a > new > > IP address, to have the TURN server address ready for later use. > > > > /Karl > > > > > > -----Ursprungligt meddelande----- > > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r > > Markus.Isomaki@nokia.com > > Skickat: den 26 september 2013 14:06 > > Till: fluffy@cisco.com; cb.list6@gmail.com > > Kopia: rtcweb@ietf.org > > =C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of > > draft-ietf-rtcweb-use-cases-and-requirements-11 > > > > Hi, > > > > Cullen Jennings wrote: > > > > > > I will note that browsers have many ways to learn about HTTP proxies > > > from the network and it seems to me that using some of theses same > > > technique might also be a good way to learn about TURN servers. > > > > > > > I agree. I assume that in enterprises it would be the same people > managing > > both of these. > > > > Is there something the IETF can or should do about this, or do we just > > assume it will happen? A new DHCP option is something the IETF could > easily > > do, but I also doubt how usable that would be. > > > > Markus > > _______________________________________________ > > 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 > > --089e0115e84a85a8b804e7b01010 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Fri, Sep 27, 2013 at 7:47 PM, Karl Stahl <<= a href=3D"mailto:karl.stahl@intertex.se" target=3D"_blank">karl.stahl@inter= tex.se> wrote:

> Does your mobile provider currently do reverse dns= for your mobile's real ip address?

>CB

Good question and the answer = is good: Yes

We just checked= both major 3G mobile operators TeleaSonera and Tele2 in Sweden.<= /u>

E.g. just surfi= ng =A0to http://= whatismyipaddress.com

(which tells me= it is TeliaSonera, Wireless Broadband)

Then clicking the =93Additional IP Det= ails=94 button, I get the PTR record:

host-95-199-196-65.mobileonline.te= lia.com

Tele2 gave: m83-186-15-99= .cust.tele2.se

=A0

So= , obviously mobile providers have ways of provisioning these kind of things= in DNS.

=A0

Ho= w does it look in other places of the world?

=A0

[SV] This is NOT the case for Vod= afone Italy
=A0

/Karl=

= =A0

=A0

Fr=E5n: cb.lis= t6 [mailto:cb.list6= @gmail.com]
Skickat: den 27 september 2013 01:06
Till: Karl Stahl
<= b>Kopia: fluffy@c= isco.com; rtcweb@i= etf.org; draft-ietf-rtcweb-use-cases-and-requirem= ents@tools.ietf.org; Markus.Isomaki@nokia.com
=C4mne: Re: SV: [rtcweb] TURN server address via DHCP, WGLC of draft= -ietf-rtcweb-use-cases-and-requirements-11

=A0


On = Sep 26, 2013 8:27 AM, "Karl Stahl" <karl.stahl@intertex.se> wrote:
>
> Here comes the suggestion I got from my developer that would a= llow a network
> provider to offer his TURN server for the WebRTC bro= wser to use. This would
> require NO new DHCP-options or similar, and= NO OS changes (I do realize
> those should be avoided if possible...).
>
> The idea is s= till, that whoever is responsible for giving a device an IP
> address= (the network provider or a LAN administrator) can also announce a
> = TURN server for the WebRTC browser to use.
>
> The suggestion is to use RFC6763 (DNS-Based Service Discovery,= see chapter
> 11) where the network provider (the owner of the IP ad= dress) has set up a
> DNS PTR record for the TURN server in the in-ad= dr.arpa domain.
>
> If the device got IP 173.164.252.149, then make a query for th= e PTR record
> for:
> _turn._udp.149.252.164.173.in-addr.arpa.<= br>> Then the SRV record would return the actual address to the TURN ser= ver (and
> you may find several for load balancing and failover I guess)
><= br>> If the device is on a LAN, the IP 173.164.252.149 to query would be= the WAN
> IP you get via STUN in the ICE process. But if the LAN adm= inistrator
> provides a local TURN server, then he also should have blocked STUN in= the
> firewall, and the browser should query the device's local = host address (as
> in the ICE procedure) and the local LAN DNS server= should answer the query
> to give the local TURN server address on the LAN.
>
> Shou= ldn't this work to allow network provider to offer his TURN server
&= gt; "automatically and generally"?
>
> And wouldn'= ;t this work nicely for mobile devices, whenever the device is on
> a "WebRTC-ready access" (actually good for everything using = ICE), whether
> fixed, WiFi or 3G/4G OTT, you get also a TURN server = (and the network
> provider hopefully offers a prioritized pipe there= as one usage of this
> mechanism).
>

Does your mobile provider curr= ently do reverse dns for your mobile's real ip address?

CB

> Not to slow down every call setup by doing= this in the ICE process, I guess
> this could be done when starting the browser and when the device gets = a new
> IP address, to have the TURN server address ready for later u= se.
>
> /Karl
>
>
> -----Ursprungligt meddela= nde-----
> Fr=E5n: r= tcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r
> Markus.Isomaki@nokia.com=
> Skickat: den 26 september 2013 14:06
> Till: fluffy@cisco.com; cb.list6@gmail.com
> Kopia:= rtcweb@ietf.org > =C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of
> dra= ft-ietf-rtcweb-use-cases-and-requirements-11
>
> Hi,
>> Cullen Jennings wrote:
> >
> > I will note that bro= wsers have many ways to learn about HTTP proxies
> > from the network and it seems to me that using some of theses sam= e
> > technique might also be a good way to learn about TURN serve= rs.
> >
>
> I agree. I assume that in enterprises it w= ould be the same people managing
> both of these.
>
> Is there something the IETF can or shou= ld do about this, or do we just
> assume it will happen? A new DHCP o= ption is something the IETF could easily
> do, but I also doubt how u= sable that would be.
>
> Markus
> _______________________________________________=
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/rtcweb
>


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


--089e0115e84a85a8b804e7b01010-- From martin.thomson@gmail.com Tue Oct 1 14:51:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B0821E81FF for ; Tue, 1 Oct 2013 14:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6B6JNtGppdZ for ; Tue, 1 Oct 2013 14:51:42 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D7DA621E808C for ; Tue, 1 Oct 2013 14:51:41 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cb5so6349563wib.10 for ; Tue, 01 Oct 2013 14:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FfPkMp1j0i4E3FJOZTvkxr7HFoK3+yw7Behv7RLbxaA=; b=wxyDBIh+1DK9j1rKlaVSuV03tVkN/Y/HC4MjpkBzlsPLJPTK73vU1eM0ZOCfu9W7sf s9SoD0IfhxpdCOAxXdo6BARTvjTkua4M9CM/MaGSIZgf6Ek/T8cfNaIZXTlX1dqU4Igq Bm7OY+j7hFG5Tz/0X6c5yhJKfb1coiOOY6eyHuI0RgDsZGfUIrCzuqc6tfi5E34rZiy2 BAbJMMeJyjtVwy6qqg+F81XF1ICpXjCima0X04L/utMOd1ywXGK7Dp3vG86PX1TYkq+e V88DMyPAKhFpbGtM6980XTRYZQgPU99h4W2NVUlHyfVewodj8aSYA5XDGu9+/Qa3oJGW Tf/A== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr20568080wic.64.1380664299913; Tue, 01 Oct 2013 14:51:39 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Tue, 1 Oct 2013 14:51:39 -0700 (PDT) In-Reply-To: <52427F74.9030805@alvestrand.no> References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com> <52427F74.9030805@alvestrand.no> Date: Tue, 1 Oct 2013 14:51:39 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] additional ICE info X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 21:51:55 -0000 On 24 September 2013 23:15, Harald Alvestrand wrote: > > The existence of that (public) document explains some strange features > of some earlier Microsoft proposals that I was never able to get an > explanation for. > > This approach (which seems to have many of the properties of RSVP) seems > to offer a solution to some problems that people have been solving by > snooping SIP (which is impossible if SIP isn't used, and very hard when > all the SIP channels are encrypted). Is there a chance that we could get > public-stable specification of the required pieces, so that other > companies can dare to depend on it? http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00 I've had interest in this from other people. It is currently framed as a mitigation for an attack, but it turns out that the TURN allocation sizing is probably the most interesting part, since the consent mechanism provides a fairly effective mitigation mechanism. Especially if we define a new STUN error code that can be used to provide immediate consent termination. It's less generic than the malice draft, which I find compelling, though I know generality is appealing to some people. From partha@parthasarathi.co.in Wed Oct 2 10:42:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E044321F90E5 for ; Wed, 2 Oct 2013 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w+jR2VBjO30 for ; Wed, 2 Oct 2013 10:42:14 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.156]) by ietfa.amsl.com (Postfix) with ESMTP id B5D4021F94FA for ; Wed, 2 Oct 2013 10:40:38 -0700 (PDT) Received: from userPC (unknown [122.179.13.94]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 1E8A314D854B; Wed, 2 Oct 2013 17:40:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1380735635; bh=tueojLqV0cRc+LGc1b4E8q1dhy3ifNrSrS59xxbNXOs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=iHoSO5rYuhNzg5EDH/eP5Xyorn+aJRg4SJ3zZIpurjua94F0nmSflGZFcY0MJz8YL ozgrEsL7+tI0VoixIMAlVkCDpcog6F3/2WXR7rDFKjK06pKxh5bCX+/oWJQFyvbJaH hEbV3GMtZnkpdggVO9rADa9f/+TuckKScfHi5ufw= From: "Parthasarathi R" To: Date: Wed, 2 Oct 2013 23:10:25 +0530 Message-ID: <006401cebf96$7db7a4f0$7926eed0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6/lnkAhKE72RhfQdaR3bEfZ6NwEg== Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.524C5A93.0176, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154 Cc: rtcweb@ietf.org Subject: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:42:25 -0000 Hi Harald, Could you please let me know the specification which indicates SRTP/AVPF/TCP profile in Sec 2.2 of draft-ietf-rtcweb-transports-01. Thanks Partha From harald@alvestrand.no Wed Oct 2 13:24:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5B21F9CA4 for ; Wed, 2 Oct 2013 13:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZa1onnEAm4O for ; Wed, 2 Oct 2013 13:24:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F105B21F9A43 for ; Wed, 2 Oct 2013 13:19:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76BB639E1BB; Wed, 2 Oct 2013 22:19:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvdkv1R1+6yx; Wed, 2 Oct 2013 22:19:39 +0200 (CEST) Received: from [172.19.6.255] (unknown [216.239.45.95]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1393E39E070; Wed, 2 Oct 2013 22:19:38 +0200 (CEST) Message-ID: <524C7FD8.1050801@alvestrand.no> Date: Wed, 02 Oct 2013 22:19:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Parthasarathi R References: <006401cebf96$7db7a4f0$7926eed0$@co.in> In-Reply-To: <006401cebf96$7db7a4f0$7926eed0$@co.in> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------020503090409030900020304" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:24:28 -0000 This is a multi-part message in MIME format. --------------020503090409030900020304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/02/2013 07:40 PM, Parthasarathi R wrote: > Hi Harald, > > Could you please let me know the specification which indicates SRTP/AVPF/TCP > profile in Sec 2.2 of draft-ietf-rtcweb-transports-01. > > Thanks > Partha > That's a good question! http://tools.ietf.org/html/rfc4571 defines TCP/RTP/AVP, but there doesn't seem to be a corresponding defintion for SRTP/AVPF over TCP. Neither is the RFC 4571 profile registered at IANA - I think both that and the DTLS forms should have been at http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-7 - but this registry seems so short, I wonder if I'm missing something. -- Surveillance is pervasive. Go Dark. --------------020503090409030900020304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/02/2013 07:40 PM, Parthasarathi R wrote:
Hi Harald,

Could you please let me know the specification which indicates SRTP/AVPF/TCP
profile in Sec 2.2 of draft-ietf-rtcweb-transports-01. 

Thanks
Partha
That's a good question!

http://tools.ietf.org/html/rfc4571 defines TCP/RTP/AVP, but there doesn't seem to be a corresponding defintion for SRTP/AVPF over TCP.

Neither is the RFC 4571 profile registered at IANA - I think both that and the DTLS forms should have been at http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-7 - but this registry seems so short, I wonder if I'm missing something.

-- 
Surveillance is pervasive. Go Dark.
--------------020503090409030900020304-- From mandyam@quicinc.com Wed Oct 2 13:32:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3768B21F8793 for ; Wed, 2 Oct 2013 13:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paekQY-Vq--3 for ; Wed, 2 Oct 2013 13:32:12 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id B53AC21F8E21 for ; Wed, 2 Oct 2013 13:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1380745917; x=1412281917; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6kLlxF4r10V7WbsEbM0jSI5Gv5EyDSchVDdwrg9Rpa0=; b=ZxRjs8QvErwnRLv+PgUZi4ZR4GItNEZMpcH8BCOCcDOkM3dK9o170BIP lgJ0rS+XUXLPIWqQJmriQscRsdkjZSHFp++Lv85alAykirNXaK3jDZ7tZ MrnKiqpGg4mic2wobhy3PY64OA1WKTVUGK8zFqLCJiMV1TBrlZE0cIhJZ k=; X-IronPort-AV: E=McAfee;i="5400,1158,7215"; a="77814380" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 02 Oct 2013 13:31:57 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7215"; a="521035518" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Oct 2013 13:31:57 -0700 Received: from NASANEXD01H.na.qualcomm.com ([169.254.8.8]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.03.0158.001; Wed, 2 Oct 2013 13:31:56 -0700 From: "Mandyam, Giridhar" To: Harald Alvestrand , Parthasarathi R Thread-Topic: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 Thread-Index: Ac6/lnkAhKE72RhfQdaR3bEfZ6NwEgAUOoEAAA5cARA= Date: Wed, 2 Oct 2013 20:31:57 +0000 Message-ID: References: <006401cebf96$7db7a4f0$7926eed0$@co.in> <524C7FD8.1050801@alvestrand.no> In-Reply-To: <524C7FD8.1050801@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: multipart/alternative; boundary="_000_CAC8DBE4E9704C41BCB290C2F3CC921A165B77DAnasanexd01hnaqu_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:32:22 -0000 --_000_CAC8DBE4E9704C41BCB290C2F3CC921A165B77DAnasanexd01hnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does RFC 6544 work (http://tools.ietf.org/html/rfc6544) for a normative ref= erence on SRTP/AVP over TCP? -Giri From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Wednesday, October 02, 2013 1:20 PM To: Parthasarathi R Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 On 10/02/2013 07:40 PM, Parthasarathi R wrote: Hi Harald, Could you please let me know the specification which indicates SRTP/AVPF/TC= P profile in Sec 2.2 of draft-ietf-rtcweb-transports-01. Thanks Partha That's a good question! http://tools.ietf.org/html/rfc4571 defines TCP/RTP/AVP, but there doesn't s= eem to be a corresponding defintion for SRTP/AVPF over TCP. Neither is the RFC 4571 profile registered at IANA - I think both that and = the DTLS forms should have been at http://www.iana.org/assignments/rtp-para= meters/rtp-parameters.xhtml#rtp-parameters-7 - but this registry seems so s= hort, I wonder if I'm missing something. -- Surveillance is pervasive. Go Dark. --_000_CAC8DBE4E9704C41BCB290C2F3CC921A165B77DAnasanexd01hnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does RFC 6544 work (http://tools.ietf.org/html/rfc654= 4) for a normative reference on SRTP/AVP over TCP?

-Giri

 <= /p>

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ie= tf.org] On Behalf Of Harald Alvestrand
Sent: Wednesday, October 02, 2013 1:20 PM
To: Parthasarathi R
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-= 01

 

On 10/02/2013 07:40 PM, Parthasarathi R wrote:<= /o:p>

Hi Harald,
 
Could you please let me know the specification which indicates SRTP/AV=
PF/TCP
profile in Sec 2.2 of draft-ietf-rtcweb-transports-01. 

 


Thanks


Partha


 

That's a good question!

http://tools.ietf.org/html/r= fc4571 defines TCP/RTP/AVP, but there doesn't seem to be a correspondin= g defintion for SRTP/AVPF over TCP.

Neither is the RFC 4571 profile registered at IANA - I think both that and = the DTLS forms should have been at http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-par= ameters-7 - but this registry seems so short, I wonder if I'm missing s= omething.


-- 
Surveillance is pervasive. Go Dark.
--_000_CAC8DBE4E9704C41BCB290C2F3CC921A165B77DAnasanexd01hnaqu_-- From karl.stahl@intertex.se Wed Oct 2 15:50:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33EE21F9A61 for ; Wed, 2 Oct 2013 15:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60tAemuOCujJ for ; Wed, 2 Oct 2013 15:50:31 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04021F9DC7 for ; Wed, 2 Oct 2013 15:50:02 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310030049588596; Thu, 03 Oct 2013 00:49:58 +0200 From: "Karl Stahl" To: "'Magnus Westerlund'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> In-Reply-To: <524AB730.7040809@ericsson.com> Date: Thu, 3 Oct 2013 00:50:01 +0200 Message-ID: <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6+nFH8CL2Yst2HTRSvKXyZPyqIGgBIBUtA Content-Language: sv Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 22:50:41 -0000 Hej Magnus, Hmm, if we (IETF) allowed ourselves to each decennium allocate payload = types for the 3-4 most common/important codecs, the unassigned pool (PT:35-71) would last 100 years! I think our own Opus, H.264, and maybe some mobile = and the Skype codec (SILK) could be honored AND of course the mandatory = video codec that will be selected for WebRTC (VPx or H.26y). The need for assigning new payload types may have been small - dynamic payload types works equally well - EXCEPT for the quality routing = reason. (RSVP quality type of networks could at least know maximum bandwidth. = DPI guesswork could/should be avoided.) So with WebRTC, expecting to finally bring us beyond POTS quality on a massive scale - we (IETF) may reconsider... If that really is impossible, is there anything stopping _the RTCWEB = RFC_ to recommend (MUST or SHOULD) specific _dynamic_ payload types to be used = for e.g. Opus:PT=3D111, H.264:PT=3D112, VP9:PT=3D113 etc.? That may be good = enough, and surely others, like SIP-client, would follow this usage (or add it = to their recommendations). /Karl -----Ursprungligt meddelande----- Fr=E5n: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Skickat: den 1 oktober 2013 13:51 Till: Karl Stahl Kopia: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org =C4mne: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Hi Karl, I just want to provide a comment on your below suggestion. On 2013-09-21 23:44, Karl Stahl wrote: > Yet another thing related to > draft-ietf-rtcweb-use-cases-and-requirements-11: > It is about payload type, PT=3D, in SDP and RTP, so I am copying = MMUSIC >=20 > Network service providers have expressed an interest to know whether=20 > packets carry audio or video, to be able to handle them differently in = > the network (e.g. quality wise). PT is visible outside the encrypted=20 > payload in RTP, however if dynamic payload types PT:96-127 are used,=20 > you cannot know what the payload is without knowledge of the SDP=20 > (which we for WebRTC must assume the network provider has no knowledge of). >=20 > In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I = > see no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC. >=20 > So, can we have payload types assigned to codecs that will be=20 > recommended for WebRTC are unassigned)? And this is because over 10 years ago we (IETF) stopped assigning static payload types, actually forbid future static assignments. All payload = types are assumed to be dynamically assigned in RTCWEB. The reason is that we = have more codecs and codec configurations than there is PT space. > Or can we at least split dynamic payload types PT:96-127 into groups=20 > for audio and video codecs? That assumes that one understand how many of each there is going to be. You also have the supplemental payload types, like RTP Retransmission = that has a one to one binding with another payload type in the RTP session. = So how should one do this split without being significantly restricted in = how you use the payload type space. I personally see that the 96-127 space = will be insufficient in quite many cases due to the combination of supporting = a number of audio and video codes combined with retransmission and FEC. I don't really dare doing a split, as I would have to live with it for = the foreseeable future, and it would inevitable be wrong. Cheers Magnus From magnus.westerlund@ericsson.com Wed Oct 2 22:23:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3021E804E for ; Wed, 2 Oct 2013 22:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llmowkw-ClFl for ; Wed, 2 Oct 2013 22:23:30 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0B92C21F9DC9 for ; Wed, 2 Oct 2013 22:22:56 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-e4-524cff193fc0 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D7.A4.25272.91FFC425; Thu, 3 Oct 2013 07:22:33 +0200 (CEST) Received: from ESESSMB309.ericsson.se ([169.254.9.202]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 07:22:32 +0200 From: Magnus Westerlund To: Harald Alvestrand Thread-Topic: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 Thread-Index: Ac6/lnkAhKE72RhfQdaR3bEfZ6NwEgABXocAABcnJbc= Date: Thu, 3 Oct 2013 05:22:32 +0000 Message-ID: References: <006401cebf96$7db7a4f0$7926eed0$@co.in>, <524C7FD8.1050801@alvestrand.no> In-Reply-To: <524C7FD8.1050801@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_ro3xdjcv7wkbl37rttggv2qu1380777749933emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvra7ef58gg4Uf+SyO9XWxWUz+1Mdq sfZfO7sDs8eVCVdYPZYs+cnk8WH+F/YA5igum5TUnMyy1CJ9uwSujCM/XzIXXJSt+LRhPVMD 42bJLkZODgkBE4k1Z84wQdhiEhfurWfrYuTiEBI4yijx6+1bRghnMaPEsYUbmEGq2AQsJG7+ aGQDsUUEdCQe7m8A62YWCJe4tfoBI4gtLOAm8f7ffagad4l/TTsYIWwrif3bXrCD2CwCKhK7 NhwFi/MC1f94swHMFhIIkViwaAGYzSmgK7HvzDOwekYBWYn73++xQOwSl/g89wHU1QISS/ac Z4awRSVePv7HClGTI3Ho93QmiPmCEidnPmGZwCgyC0n7LCRls5CUQcT1JG5MncIGYWtLLFv4 mhnC1pWY8e8QC7L4Akb2VYwcxanFSbnpRgabGIExdXDLb4sdjJf/2hxilOZgURLn/fjWOUhI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY85ucVOLtd8ElvoJy+l2HP38Prv9bkp0csa/5BT/ SP0ZnysOPjbR2V/yzvDKkY0ND85t0In6vsH86Iw5Sqe4awOTdyhxHXo6ZZmo56uDp5Itpxkl rY+r/bjgq3J9/RSpPRnxMTm3Z2+Ri9rQbx54TF6QhevZi+510p+N56+8evnc/nj5xZXZz5RY ijMSDbWYi4oTARXrru93AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 05:23:41 -0000 --_000_ro3xdjcv7wkbl37rttggv2qu1380777749933emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald, Yes you are missing something. The registry you pointed at are the one for = RTP profiles. The one containing the combinations with transport are SDP sp= ecific. http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-par= ameters-2 Cheers Magnus Sent from Moxier Mail (http://www.moxier.com) ----- Ursprungligt meddelande ----- Fr=E5n: Harald Alvestrand Till: Parthasarathi R Kopia: "rtcweb@ietf.org" Skickat: 02-10-2013 10:24 em =C4mne: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 On 10/02/2013 07:40 PM, Parthasarathi R wrote: Hi Harald, Could you please let me know the specification which indicates SRTP/AVPF/TC= P profile in Sec 2.2 of draft-ietf-rtcweb-transports-01. Thanks Partha That's a good question! http://tools.ietf.org/html/rfc4571 defines TCP/RTP/AVP, but there doesn't s= eem to be a corresponding defintion for SRTP/AVPF over TCP. Neither is the RFC 4571 profile registered at IANA - I think both that and = the DTLS forms should have been at http://www.iana.org/assignments/rtp-para= meters/rtp-parameters.xhtml#rtp-parameters-7 - but this registry seems so s= hort, I wonder if I'm missing something. -- Surveillance is pervasive. Go Dark. --_000_ro3xdjcv7wkbl37rttggv2qu1380777749933emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Harald, =0A=
=0A=
Yes you are missing something. The registry you pointed at are the one for =
RTP profiles. The one containing the combinations with transport are SDP sp=
ecific. =0A=
=0A=
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-par=
ameters-2=0A=
=0A=
Cheers =0A=
=0A=
Magnus=0A=
=0A=
Sent from Moxier Mail=0A=
(http://www.moxier.com)=0A=
=0A=
=0A=
----- Ursprungligt meddelande -----=0A=
Fr=E5n: Harald Alvestrand <harald@alvestrand.no>=0A=
Till: Parthasarathi R <partha@parthasarathi.co.in>=0A=
Kopia: "rtcweb@ietf.org" <rtcweb@ietf.org>=0A=
Skickat: 02-10-2013 10:24 em=0A=
=C4mne: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01=0A=
=0A=
=0A=
On 10/02/2013 07:40 PM, Parthasarathi R wrot= e:
Hi Harald,

Could you please let me know the specification which indicates SRTP/AVPF/TC=
P
profile in Sec 2.2 of draft-ietf-rtcweb-transports-01.=20

Thanks
Partha
That's a good question!

http://tools.ietf.org/html/r= fc4571 defines TCP/RTP/AVP, but there doesn't seem to be a correspondin= g defintion for SRTP/AVPF over TCP.

Neither is the RFC 4571 profile registered at IANA - I think both that and = the DTLS forms should have been at http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-par= ameters-7 - but this registry seems so short, I wonder if I'm missing s= omething.

--=20
Surveillance is pervasive. Go Dark.
--_000_ro3xdjcv7wkbl37rttggv2qu1380777749933emailandroidcom_-- From christer.holmberg@ericsson.com Thu Oct 3 07:16:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196C21F9360 for ; Thu, 3 Oct 2013 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83sSxjZnSSaG for ; Thu, 3 Oct 2013 07:16:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9215221F8B4E for ; Thu, 3 Oct 2013 07:10:48 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-43-524d7ae6107c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F5.4C.16099.6EA7D425; Thu, 3 Oct 2013 16:10:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 16:10:46 +0200 From: Christer Holmberg To: Justin Uberti , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] No a=ice-lite in JSEP-04 Thread-Index: Ac698bCDm/FvoM3PQXG8Sb8kVVaquv//37SAgAB0oAD/+7OiAA== Date: Thu, 3 Oct 2013 14:10:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> 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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B37B8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvre7zKt8gg5OXuC2m77Ox2DpVyGLt v3Z2B2aPcw3v2T0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxrsD+5gL9kVWbP+n2sDYEt7F yMkhIWAisetZKxOELSZx4d56NhBbSOAwo0TvWWUIezGjxO/j6l2MHBxsAhYS3f+0QUwRgSSJ totgU5gF1CXuLD7HDmILC+hJ/H31B8wWEdCXWLfxIBuE7STx/elJFhCbRUBF4uylThaQMbwC vhJzN+l1MXIBLbrNKPHg0kNmkBpOgUCJ92f/gfUyAl32/dQaJohd4hK3nsyHulhAYsme88wQ tqjEy8f/WCFsRYmPr/YxQtTnS+x92AVm8woISpyc+YRlAqPoLCSjZiEpm4WkbBbQecwCmhLr d+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FSN7bmJmTnq54SZGYFwd3PJbdwfjqXMihxilOViU xHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCod/7Y4TPCRfvlNJYlvdbdoyG/8Jtz iqKiz97qrNAnK4oKH6g+bn10f9/FGcL/flmayN3jrdoe4sVo/pLty90pqm8u2GitkJTIis79 bj/5+cT/129lr864nbdkZ5zEC50fMT3XX61PljvwU4Or1mD+bv6ZZtvZUz8L9Z2WU/dt+b+i XkZ44RZFJZbijERDLeai4kQAhYmzLnkCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:16:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B37B8ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkp1c3QgdG8gYmUgY2xlYXIsIHdpdGgg4oCcV2ViUlRDIGVuZHBvaW504oCdIEkgZ3Vl c3MgeW91IGRvIG5vdCBpbmNsdWRlIGdhdGV3YXlzPw0KDQpNYXliZSB3ZSBzaG91bGQgdGFsayBh Ym91dCDigJxKU0VQIGVuZHBvaW50c+KAnSwgb3Igc29tZXRoaW5nLi4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDEuIGxv a2FrdXV0YSAyMDEzIDE6MzANClRvOiBJw7Fha2kgQmF6IENhc3RpbGxvDQpDYzogcnRjd2ViQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gTm8gYT1pY2UtbGl0ZSBpbiBKU0VQLTA0DQoN Clllcy4gSW4gdGhlIG9mZmVycyBhbmQgYW5zd2VycyB0aGF0IFdlYlJUQyBlbmRwb2ludHMgY3Jl YXRlLCBhPWljZS1saXRlIGlzIHByb2hpYml0ZWQsIHNpbmNlIFdlYlJUQyBlbmRwb2ludHMgbXVz dCBzdXBwb3J0ICJGdWxsIiBJQ0UuDQoNClRoZSByZW1vdGUgZW5kcG9pbnQgbWF5IG9mIGNvdXJz ZSBzdXBwb3J0IG9ubHkgSUNFIExpdGUsIGFuZCBXZWJSVEMgaW1wbGVtZW50YXRpb25zIG11c3Qg d29yayBwcm9wZXJseSB3aXRoIHN1Y2ggZW5kcG9pbnRzLg0KDQpUaGlzIGlzbid0IG5vcm1hdGl2 ZWx5IGluZGljYXRlZCBhbnl3aGVyZSB0aGF0IEkgY291bGQgZmluZCwgc28gSSBwbGFuIHRvIGFk ZCBzcGVjaWZpY3Mgb24gdGhpcyB0byB0aGUgbmV4dCB2ZXJzaW9uIG9mIEpTRVAuDQoNCg0KDQpP biBNb24sIFNlcCAzMCwgMjAxMyBhdCA4OjMyIEFNLCBJw7Fha2kgQmF6IENhc3RpbGxvIDxpYmNA YWxpYXgubmV0PG1haWx0bzppYmNAYWxpYXgubmV0Pj4gd3JvdGU6DQoyMDEzLzkvMzAgUmF1c2No ZW5iYWNoLCBVd2UgKE5TTiAtIERFL011bmljaCkgPHV3ZS5yYXVzY2hlbmJhY2hAbnNuLmNvbTxt YWlsdG86dXdlLnJhdXNjaGVuYmFjaEBuc24uY29tPj46DQo+IEpTRVAtMDQgcHJvaGliaXRzIHRo ZSB1c2Ugb2YgYT1pY2UtbGl0ZS4gSXQgaXMgc3RhdGVkIHRoYXQgaXQgaXMgaW5jb21wYXRpYmxl IHdpdGggSS1ELmlldGYtcnRjd2ViLXJ0cC11c2FnZS4NCj4gQ2FuIHlvdSBwb2ludCBvdXQgd2hp Y2ggc3BlY2lmaWMgYXNwZWN0IG9mIHRoaXMgZHJhZnQgSUNFIExpdGUgaXMgaW5jb21wYXRpYmxl IHdpdGg/DQo+DQo+IEluIGRlcGxveW1lbnRzIHdoZXJlIG9uZSBlbmRwb2ludCBpcyBhIGJyb3dz ZXIgYW5kIGFub3RoZXIgb25lIGlzIGEgZ2F0ZXdheSBjb25uZWN0ZWQgdG8gdGhlIHB1YmxpYyBJ bnRlcm5ldCwgaXQgbWFrZXMgc2Vuc2UgdG8gYWxsb3cgSUNFIGxpdGUuDQpXaXRob3V0IHJlYWRp bmcgSlNFUC0wNCBJIGV4cGVjdCB0aGF0IGl0IGlzIG5vdCBhbGxvd2VkIGZvciBhIHdlYg0KYnJv d3NlciB0byBpbmRpY2F0ZSAiYT1pY2UtbGl0ZSIsIGJ1dCBhIHNlcnZlciBjYW4gZG8gdGhhdC4g QW55aG93LA0KQUZBSVIgdGhlIHVzYWdlIG9mIElDRSBsaXRlIGlzIGZ1bGx5IHRyYW5zcGFyZW50 IGZvciB0aGUgbm9uIElDRSBsaXRlDQplbmRwb2ludC4NCg0KDQotLQ0KScOxYWtpIEJheiBDYXN0 aWxsbw0KPGliY0BhbGlheC5uZXQ8bWFpbHRvOmliY0BhbGlheC5uZXQ+Pg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_7594FB04B1934943A5C02806D1A2204B1C4B37B8ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SnVzdCB0byBiZSBjbGVhciwgd2l0aCDigJxXZWJSVEMgZW5kcG9pbnTigJ0gSSBndWVz cyB5b3UgZG8gbm90IGluY2x1ZGUgZ2F0ZXdheXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSB3ZSBzaG91bGQg dGFsayBhYm91dCDigJxKU0VQIGVuZHBvaW50c+KAnSwgb3Igc29tZXRoaW5nLi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxi PlNlbnQ6PC9iPiAxLiBsb2tha3V1dGEgMjAxMyAxOjMwPGJyPg0KPGI+VG86PC9iPiBJw7Fha2kg QmF6IENhc3RpbGxvPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtydGN3ZWJdIE5vIGE9aWNlLWxpdGUgaW4gSlNFUC0wNDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gSW4gdGhlIG9mZmVycyBhbmQgYW5zd2Vy cyB0aGF0IFdlYlJUQyBlbmRwb2ludHMgY3JlYXRlLCBhPWljZS1saXRlIGlzIHByb2hpYml0ZWQs IHNpbmNlIFdlYlJUQyBlbmRwb2ludHMgbXVzdCBzdXBwb3J0ICZxdW90O0Z1bGwmcXVvdDsgSUNF LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHJlbW90ZSBlbmRwb2ludCBtYXkgb2YgY291cnNlIHN1cHBvcnQgb25seSBJQ0UgTGl0ZSwgYW5k IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgbXVzdCB3b3JrIHByb3Blcmx5IHdpdGggc3VjaCBlbmRw b2ludHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoaXMgaXNuJ3Qgbm9ybWF0aXZlbHkgaW5kaWNhdGVkIGFueXdoZXJlIHRoYXQgSSBjb3Vs ZCBmaW5kLCBzbyBJIHBsYW4gdG8gYWRkIHNwZWNpZmljcyBvbiB0aGlzIHRvIHRoZSBuZXh0IHZl cnNpb24gb2YgSlNFUC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgU2VwIDMwLCAyMDEz IGF0IDg6MzIgQU0sIEnDsWFraSBCYXogQ2FzdGlsbG8gJmx0OzxhIGhyZWY9Im1haWx0bzppYmNA YWxpYXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aWJjQGFsaWF4Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxMy85LzMwIFJhdXNjaGVuYmFj aCwgVXdlIChOU04gLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJtYWlsdG86dXdlLnJhdXNjaGVu YmFjaEBuc24uY29tIiB0YXJnZXQ9Il9ibGFuayI+dXdlLnJhdXNjaGVuYmFjaEBuc24uY29tPC9h PiZndDs6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IEpTRVAtMDQgcHJvaGliaXRzIHRoZSB1c2Ugb2Yg YT1pY2UtbGl0ZS4gSXQgaXMgc3RhdGVkIHRoYXQgaXQgaXMgaW5jb21wYXRpYmxlIHdpdGggSS1E LmlldGYtcnRjd2ViLXJ0cC11c2FnZS48YnI+DQomZ3Q7IENhbiB5b3UgcG9pbnQgb3V0IHdoaWNo IHNwZWNpZmljIGFzcGVjdCBvZiB0aGlzIGRyYWZ0IElDRSBMaXRlIGlzIGluY29tcGF0aWJsZSB3 aXRoPzxicj4NCiZndDs8YnI+DQomZ3Q7IEluIGRlcGxveW1lbnRzIHdoZXJlIG9uZSBlbmRwb2lu dCBpcyBhIGJyb3dzZXIgYW5kIGFub3RoZXIgb25lIGlzIGEgZ2F0ZXdheSBjb25uZWN0ZWQgdG8g dGhlIHB1YmxpYyBJbnRlcm5ldCwgaXQgbWFrZXMgc2Vuc2UgdG8gYWxsb3cgSUNFIGxpdGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGhvdXQgcmVhZGlu ZyBKU0VQLTA0IEkgZXhwZWN0IHRoYXQgaXQgaXMgbm90IGFsbG93ZWQgZm9yIGEgd2ViPGJyPg0K YnJvd3NlciB0byBpbmRpY2F0ZSAmcXVvdDthPWljZS1saXRlJnF1b3Q7LCBidXQgYSBzZXJ2ZXIg Y2FuIGRvIHRoYXQuIEFueWhvdyw8YnI+DQpBRkFJUiB0aGUgdXNhZ2Ugb2YgSUNFIGxpdGUgaXMg ZnVsbHkgdHJhbnNwYXJlbnQgZm9yIHRoZSBub24gSUNFIGxpdGU8YnI+DQplbmRwb2ludC48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KLS08YnI+DQpJw7Fha2kg QmF6IENhc3RpbGxvPGJyPg0KJmx0OzxhIGhyZWY9Im1haWx0bzppYmNAYWxpYXgubmV0IiB0YXJn ZXQ9Il9ibGFuayI+aWJjQGFsaWF4Lm5ldDwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1C4B37B8ESESSMB209erics_-- From ekr@rtfm.com Thu Oct 3 07:26:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CF021F96ED for ; Thu, 3 Oct 2013 07:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHG0L2jBe0YP for ; Thu, 3 Oct 2013 07:26:10 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 663B421F9901 for ; Thu, 3 Oct 2013 07:19:14 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so40510wid.15 for ; Thu, 03 Oct 2013 07:19:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jxYy4G4l7Ia2Gouq7PAYFjn0oUPl2xXtoR9vWM1eslM=; b=Wf2/vR57/fs4ySsbLJklNT4uRShNbZyAoMAzeL57lYUUq0AHoMwaKiL2P00nKUOlnz GgUWGGTT6TIuJIcftpvPJW41m7pwpXp+fy8DXfPw+MkrIg1L53R5iM5v0JL+kOs1VdfR KAbPKbVvwPAXo/waCiNxla6VV4kTUXo+2NdjZ8JiithEPwu7s9tla3UoL6FDChFRkIFK 13TXKVvsMAoIS46/VN8g2a13RdolOzcrgUTdxC+YRzmT4FT/mrt45L1vzjn/1ZHiiv+m mlgsXsAOBLIahaJeVOsVOELo/E4zzmn7NRTkjwtdjR0bWFcTwA63ajZyOddQEKEgQ7hW dS+w== X-Gm-Message-State: ALoCoQkeU2evXvtVVucdqPxNptpR3qtKH1oNpaK/LqHcXKWi5yJAWgvO8PpKfXdnenF8dD1mUndr X-Received: by 10.194.77.41 with SMTP id p9mr1725440wjw.66.1380809953546; Thu, 03 Oct 2013 07:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Thu, 3 Oct 2013 07:18:33 -0700 (PDT) X-Originating-IP: [88.128.80.2] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Thu, 3 Oct 2013 16:18:33 +0200 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bfcfc6cc8ab6104e7d6de7a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:26:23 -0000 --047d7bfcfc6cc8ab6104e7d6de7a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Oct 3, 2013 at 4:10 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi,**** > > ** ** > > Just to be clear, with =93WebRTC endpoint=94 I guess you do not include > gateways?**** > > ** ** > > Maybe we should talk about =93JSEP endpoints=94, or something. > I assumed he meant "browser". -Ekr > Regards,**** > > ** ** > > Christer**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* 1. lokakuuta 2013 1:30 > *To:* I=F1aki Baz Castillo > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04**** > > ** ** > > Yes. In the offers and answers that WebRTC endpoints create, a=3Dice-lite= is > prohibited, since WebRTC endpoints must support "Full" ICE. **** > > ** ** > > The remote endpoint may of course support only ICE Lite, and WebRTC > implementations must work properly with such endpoints.**** > > ** ** > > This isn't normatively indicated anywhere that I could find, so I plan to > add specifics on this to the next version of JSEP.**** > > ** ** > > ** ** > > ** ** > > On Mon, Sep 30, 2013 at 8:32 AM, I=F1aki Baz Castillo wro= te: > **** > > 2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) := * > *** > > > JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it is > incompatible with I-D.ietf-rtcweb-rtp-usage. > > Can you point out which specific aspect of this draft ICE Lite is > incompatible with? > > > > In deployments where one endpoint is a browser and another one is a > gateway connected to the public Internet, it makes sense to allow ICE lit= e. > **** > > Without reading JSEP-04 I expect that it is not allowed for a web > browser to indicate "a=3Dice-lite", but a server can do that. Anyhow, > AFAIR the usage of ICE lite is fully transparent for the non ICE lite > endpoint. > > > -- > I=F1aki Baz Castillo > **** > > _______________________________________________ > 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 > > --047d7bfcfc6cc8ab6104e7d6de7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Thu, Oct 3, 2013 at 4:10 PM, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:

Hi,<= /p>

=A0<= /p>

Just to be clear, with = =93WebRTC endpoint=94 I guess you do not include gateways?

=A0<= /p>

Maybe we should talk abou= t =93JSEP endpoints=94, or something.


I assumed he meant "browser".

=
-Ekr

=A0
=

Regards,

=A0<= /p>

Christer

=A0<= /p>

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 1. lokakuuta 2013 1:30
To: I=F1aki Baz Castillo
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

=A0

Yes. In the offers and answers that WebRTC endpoints= create, a=3Dice-lite is prohibited, since WebRTC endpoints must support &q= uot;Full" ICE.=A0

=A0

The remote endpoint may of course support only ICE L= ite, and WebRTC implementations must work properly with such endpoints.<= /u>

=A0

This isn't normatively indicated anywhere that I= could find, so I plan to add specifics on this to the next version of JSEP= .

=A0

=A0

=A0

On Mon, Sep 30, 2013 at 8:32 AM, I=F1aki Baz Castill= o <ibc@aliax.net&= gt; wrote:

2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) <uwe.rauschenbac= h@nsn.com>:

> JSEP-04 prohibit= s the use of a=3Dice-lite. It is stated that it is incompatible with I-D.ie= tf-rtcweb-rtp-usage.
> Can you point out which specific aspect of this draft ICE Lite is inco= mpatible with?
>
> In deployments where one endpoint is a browser and another one is a ga= teway connected to the public Internet, it makes sense to allow ICE lite.

Without reading JSEP-04 I expect that it is not allo= wed for a web
browser to indicate "a=3Dice-lite", but a server can do that. Any= how,
AFAIR the usage of ICE lite is fully transparent for the non ICE lite
endpoint.


--
I=F1aki Baz Castillo
<ibc@aliax.net>= ;

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

=A0


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


--047d7bfcfc6cc8ab6104e7d6de7a-- From tim@phonefromhere.com Thu Oct 3 07:35:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E734821E804D for ; Thu, 3 Oct 2013 07:35:08 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZuzbOKROp8W for ; Thu, 3 Oct 2013 07:34:55 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 6349D11E80AD for ; Thu, 3 Oct 2013 07:26:40 -0700 (PDT) Received: (qmail 8424 invoked from network); 3 Oct 2013 14:26:37 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 3 Oct 2013 14:26:37 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9D79118A0C33; Thu, 3 Oct 2013 15:26:37 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6A25018A0AC1; Thu, 3 Oct 2013 15:26:37 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A2BCE5EB-7787-41B3-B70C-5A9255182F5D" From: Tim Panton In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> Date: Thu, 3 Oct 2013 15:26:35 +0100 Message-Id: <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:35:10 -0000 --Apple-Mail=_A2BCE5EB-7787-41B3-B70C-5A9255182F5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I'm starting to think that we need a less clumsy name for the webRTC = media wire protocol=20 ICE/STUN/TURN/SRTP/DTLS/RTCP/Opus/VP8/ etc... It looks likely to take on a life of it's own outside the browser. T. On 3 Oct 2013, at 15:10, Christer Holmberg wrote: > Hi, > =20 > Just to be clear, with =93WebRTC endpoint=94 I guess you do not = include gateways? > =20 > Maybe we should talk about =93JSEP endpoints=94, or something.. > =20 > Regards, > =20 > Christer > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Justin Uberti > Sent: 1. lokakuuta 2013 1:30 > To: I=F1aki Baz Castillo > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04 > =20 > Yes. In the offers and answers that WebRTC endpoints create, = a=3Dice-lite is prohibited, since WebRTC endpoints must support "Full" = ICE.=20 > =20 > The remote endpoint may of course support only ICE Lite, and WebRTC = implementations must work properly with such endpoints. > =20 > This isn't normatively indicated anywhere that I could find, so I plan = to add specifics on this to the next version of JSEP. > =20 > =20 > =20 >=20 > On Mon, Sep 30, 2013 at 8:32 AM, I=F1aki Baz Castillo = wrote: > 2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) = : > > JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it is = incompatible with I-D.ietf-rtcweb-rtp-usage. > > Can you point out which specific aspect of this draft ICE Lite is = incompatible with? > > > > In deployments where one endpoint is a browser and another one is a = gateway connected to the public Internet, it makes sense to allow ICE = lite. >=20 > Without reading JSEP-04 I expect that it is not allowed for a web > browser to indicate "a=3Dice-lite", but a server can do that. Anyhow, > AFAIR the usage of ICE lite is fully transparent for the non ICE lite > endpoint. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > 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=_A2BCE5EB-7787-41B3-B70C-5A9255182F5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I'm starting to think that we need a less clumsy = name for the webRTC media wire = protocol 
ICE/STUN/TURN/SRTP/DTLS/RTCP/Opus/VP8/ = etc...

It looks likely to take on a life of = it's own outside the = browser.

T.

On 3 Oct = 2013, at 15:10, Christer Holmberg wrote:

Just = to be clear, with =93WebRTC endpoint=94 I guess you do not include = gateways?
Maybe = we should talk about =93JSEP endpoints=94, or = something..
 rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.o= rg] On Behalf = Of Justin = Uberti
Sent: 1. lokakuuta 2013 = 1:30
To: I=F1a= ki Baz Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite = in JSEP-04
Yes. In the offers and = answers that WebRTC endpoints create, a=3Dice-lite is prohibited, since = WebRTC endpoints must support "Full" = ICE. 
The remote endpoint may = of course support only ICE Lite, and WebRTC implementations must work = properly with such endpoints.
 
This isn't normatively indicated anywhere that I could = find, so I plan to add specifics on this to the next version of = JSEP.
 

Without reading JSEP-04 I = expect that it is not allowed for a web
browser to indicate = "a=3Dice-lite", but a server can do that. Anyhow,
AFAIR the usage of = ICE lite is fully transparent for the non ICE lite
endpoint.


--
I=F1aki Baz = Castillo
<rtcweb@ietf.org
El 03/10/2013 16:26, "Tim Panton" escribi=C3=B3: > I'm starting to think that we need a less clumsy name for the webRTC medi= a > wire protocol > ICE/STUN/TURN/SRTP/DTLS/RTCP/Opus/VP8/ etc... > > It looks likely to take on a life of it's own outside the browser. > > T. > > On 3 Oct 2013, at 15:10, Christer Holmberg wrote: > > Hi,**** > ** ** > Just to be clear, with =E2=80=9CWebRTC endpoint=E2=80=9D I guess you do n= ot include > gateways?**** > ** ** > Maybe we should talk about =E2=80=9CJSEP endpoints=E2=80=9D, or something= ..**** > ** ** > Regards,**** > ** ** > Christer**** > ** ** > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* 1. lokakuuta 2013 1:30 > *To:* I=C3=B1aki Baz Castillo > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04**** > ** ** > Yes. In the offers and answers that WebRTC endpoints create, a=3Dice-lite= is > prohibited, since WebRTC endpoints must support "Full" ICE. **** > ** ** > The remote endpoint may of course support only ICE Lite, and WebRTC > implementations must work properly with such endpoints.**** > ** ** > This isn't normatively indicated anywhere that I could find, so I plan to > add specifics on this to the next version of JSEP.**** > ** ** > ** ** > > ** ** > On Mon, Sep 30, 2013 at 8:32 AM, I=C3=B1aki Baz Castillo = wrote: > **** > 2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) := * > *** > > > JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it is > incompatible with I-D.ietf-rtcweb-rtp-usage. > > Can you point out which specific aspect of this draft ICE Lite is > incompatible with? > > > > In deployments where one endpoint is a browser and another one is a > gateway connected to the public Internet, it makes sense to allow ICE lit= e. > **** > Without reading JSEP-04 I expect that it is not allowed for a web > browser to indicate "a=3Dice-lite", but a server can do that. Anyhow, > AFAIR the usage of ICE lite is fully transparent for the non ICE lite > endpoint. > > > -- > I=C3=B1aki Baz Castillo > **** > _______________________________________________ > 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 > > > --089e014938c801b41a04e7d70c8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If I implement my own WebRTC stack in a smartphone app, am I= disallowed to do ICE-lite in my side??

Let's focus. We can mandate constrains just into browser= s so IMHO "WebRTC browser" is the appropriate name here.

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

El 03/10/2013 16:26, "Tim Panton" <= tim@phonefromhere.com> escr= ibi=C3=B3:
I'm starting to think that we need = a less clumsy name for the webRTC media wire protocol=C2=A0
ICE/STUN/TU= RN/SRTP/DTLS/RTCP/Opus/VP8/ etc...

It looks likely= to take on a life of it's own outside the browser.

T.

On 3 Oct 2013, at 15:10, Chr= ister Holmberg wrote:

= Hi,
=C2=A0
Just to be clear, with =E2=80=9CWebRTC endpoint=E2=80=9D I guess you do = not include gateways?
=C2=A0
Maybe we should talk about =E2=80=9CJSEP endpoints=E2=80=9D, or somethin= g..
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0
From:= =C2=A0rtcweb-bounces@ietf.org=C2= =A0[mailto:rtcweb-bounces@ietf.org]=C2=A0On Behalf Of=C2= =A0Justin Uberti
Sent:=C2=A01. lokakuuta 2013 1:30
To:= =C2=A0I=C3=B1aki Baz Castillo
Cc:=C2=A0rtcweb@ietf.org
Subject:=C2=A0Re: [rtcweb] No a=3Dice-lite in JSEP-04
=C2=A0
Yes. In the offers and answers that WebRTC endpoi= nts create, a=3Dice-lite is prohibited, since WebRTC endpoints must support= "Full" ICE.=C2=A0
= =C2=A0
The remote endpoint may of course support only ICE Lite, and WebRTC impleme= ntations must work properly with such endpoints.
<= div>
=C2=A0
This isn't normatively indicated anywhe= re that I could find, so I plan to add specifics on this to the next versio= n of JSEP.
= =C2=A0
=C2=A0

=C2=A0

On Mon, Sep 30, 2013 at 8:32 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) <uwe.rauschenbach@nsn.com>:

> JSEP-04 prohibits the use of a=3Dice-lite. It is stated that it is inc= ompatible with I-D.ietf-rtcweb-rtp-usage.
> Can you point out which s= pecific aspect of this draft ICE Lite is incompatible with?
>
>= In deployments where one endpoint is a browser and another one is a gatewa= y connected to the public Internet, it makes sense to allow ICE lite.

Without reading JSEP-04 I expect that it is not allowed for a web
brows= er to indicate "a=3Dice-lite", but a server can do that. Anyhow,<= br> AFAIR the usage of ICE lite is fully transparent for the non ICE lite
en= dpoint.


--
I=C3=B1aki = Baz Castillo
<ibc@aliax.net><= /u>
_______________________________________________
rtcweb mailing list=
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb=
=C2=A0
__________________= _____________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/lis= tinfo/rtcweb

--089e014938c801b41a04e7d70c8c-- From fluffy@cisco.com Thu Oct 3 07:44:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3E921E804D for ; Thu, 3 Oct 2013 07:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6RRQvpkh5wR for ; Thu, 3 Oct 2013 07:44:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B902121F8EDF for ; Thu, 3 Oct 2013 07:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=326; q=dns/txt; s=iport; t=1380811018; x=1382020618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YdxhAZvjagF+vILgObaiLTx3vNei551axJWq8nmvo8w=; b=WaNSwqflkn6tZcTnm2pbP3g83Ihh6a45xE9UVGhIA51G0KucsKQZRTb+ Rra/6WacQ+ND1GtryUUj0f+vdXmvMIHexoTCexUMw0sjpz+zPadHQy8yv SOpaQy3ZmqygYDBbLjoQeIyabTfVxAbZVhm9YQ/yUuuna5Cwr8k05PUIT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAC6ATVKtJV2d/2dsb2JhbABZgweBCsE9gR4WdIIlAQEBAwFnEgULAgEIIhkLMiUCBA4FCId4Brxzjx4CMQeDH4EEA4kBoH+BZoE+gio X-IronPort-AV: E=Sophos;i="4.90,1026,1371081600"; d="scan'208";a="267640874" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 03 Oct 2013 14:36:56 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r93EauA4027223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 14:36:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 3 Oct 2013 09:36:56 -0500 From: "Cullen Jennings (fluffy)" To: Karl Stahl Thread-Topic: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: AQHOwEYC8R4lr9oytECeVQBiAelBJQ== Date: Thu, 3 Oct 2013 14:36:55 +0000 Message-ID: References: <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se> <07e501ceb71a$07f766d0$17e63470$@stahl@intertex.se> In-Reply-To: <07e501ceb71a$07f766d0$17e63470$@stahl@intertex.se> 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="iso-8859-1" Content-ID: <45834257CA83904AA12F493DF94A7C73@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:44:50 -0000 On Sep 21, 2013, at 4:29 PM, Karl Stahl wrote: > I've heard several carries expressing that they want to provide their own > TURN servers with their accesses. Any chance you could put me in touch with some of them. I'd love to get mor= e information on what is needed so we can solve this. From fluffy@cisco.com Thu Oct 3 08:04:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727111E811E for ; Thu, 3 Oct 2013 08:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khu-hUEuimGd for ; Thu, 3 Oct 2013 08:04:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6F21F9998 for ; Thu, 3 Oct 2013 07:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=286; q=dns/txt; s=iport; t=1380812027; x=1382021627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vHQLHeq4VmXj90NTrgYNDPtH46v08LK0pWEZS6TziWo=; b=au0qGD1l94mQXb9CyalUr+rOEZ3lo2Om07udvQqyiW0tzqekZGEpri9t m5AGQTUSzwaoQYxNQ8m7E+sfDIP/FF+ScEerDA3y0WpUGS/iPArlV7a7Z yr5n0OZiuO4T4zhWpOzwAdXM0xhZlclW96sTt7avm8lYgICkfjHy8dteR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAOaDTVKtJV2Y/2dsb2JhbABZgweBCsFBgR4WdIIlAQEBAwF5BQsCAQgiJDIlAgQOBQiHeAa9Bo8eAjEHgx+BBAOqAIMkgio X-IronPort-AV: E=Sophos;i="4.90,1026,1371081600"; d="scan'208";a="267645332" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 03 Oct 2013 14:53:46 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r93ErkRd007112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 14:53:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 3 Oct 2013 09:53:46 -0500 From: "Cullen Jennings (fluffy)" To: Tim Panton Thread-Topic: [rtcweb] No a=ice-lite in JSEP-04 Thread-Index: AQHOwEhcM1c8CWjw1k2+GKW3tRLAdA== Date: Thu, 3 Oct 2013 14:53:45 +0000 Message-ID: References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> In-Reply-To: <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.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="Windows-1252" Content-ID: <407A794B144E684F96D63AB281A4F753@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:04:45 -0000 On Oct 3, 2013, at 8:26 AM, Tim Panton wrote: > I'm starting to think that we need a less clumsy name for the webRTC medi= a wire protocol=20 > ICE/STUN/TURN/SRTP/DTLS/RTCP/Opus/VP8/ etc... >=20 RAI 2.0 seems to be the term that is getting used =85. From adam@nostrum.com Thu Oct 3 08:04:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80F11E8122 for ; Thu, 3 Oct 2013 08:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.904 X-Spam-Level: X-Spam-Status: No, score=-100.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8ZDOo0aVo2P for ; Thu, 3 Oct 2013 08:04:44 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D90A511E80AD for ; Thu, 3 Oct 2013 07:53:47 -0700 (PDT) Received: from [192.168.0.191] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r93ErhT3064327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Oct 2013 09:53:44 -0500 (CDT) (envelope-from adam@nostrum.com) References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> X-Mailer: iPhone Mail (10B350) From: Adam Roach Date: Thu, 3 Oct 2013 09:53:40 -0500 To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:04:53 -0000 On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo wrote: > If I implement my own WebRTC stack in a smartphone app, am I disallowed to= do ICE-lite in my side?? I would hope so, yes. The chance that your smartphone app would have any hop= e if working if it did ice lite are as close to zero as to make no differenc= e. The fact that implementors apparently don't see this as an obvious fact tell= s me that we need pretty strong language around this prohibition, and "brows= er" is clearly too narrow a scope.=20 /a= From ibc@aliax.net Thu Oct 3 08:20:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85CD21F8426 for ; Thu, 3 Oct 2013 08:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASBH-cUwtUJ0 for ; Thu, 3 Oct 2013 08:20:33 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0B52521F88BA for ; Thu, 3 Oct 2013 08:13:33 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id c3so1722460qcv.4 for ; Thu, 03 Oct 2013 08:13:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c8Ruh/TmWVd9ALy8Xz7UPYSpRlNRzexMNNDHl3IJncU=; b=iI0IW98OCnd1HfTSJk0K86cEQMZTZPpeeOOmhaqzPX+N4DgfytFKoksaNb/TKIcqhY FpfV+ZY7mcxOUTZmllLcpswgrEjbXhlD8RVK9kICTf0S+PQQTTrqMXSCmBHgGbtJQmjm CLi3BJilv4EgT1WPmm+5zKxCoBtoOuscmZZfxyT81hu/6LpcSACZV2kbzvvFi5sr02vV booSq2Qe0PdIiS/wpItnNrfRpsYJn4DhxRYt+kzysktllKRtf3N8EyWO0upo8altngfK eBFEAsORjvESfRVrDY9kP2eMtkxFH9oFb4WalOqkqgJPRsJ/yuDD+VjE3f3nMupM3eeE ohPw== X-Gm-Message-State: ALoCoQmD1OB4+PmXKEKUjsPjAlH6hXlkKx5oktU/tMsHAV0p/v4r5SLlwTlZYXV1fgVO3p2fxiLP MIME-Version: 1.0 X-Received: by 10.224.69.132 with SMTP id z4mr11019457qai.78.1380813213130; Thu, 03 Oct 2013 08:13:33 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Thu, 3 Oct 2013 08:13:32 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Thu, 3 Oct 2013 08:13:32 -0700 (PDT) In-Reply-To: <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> Date: Thu, 3 Oct 2013 17:13:32 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c2310e11f40e04e7d7a13c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:20:45 -0000 --001a11c2310e11f40e04e7d7a13c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -- I=C3=B1aki Baz Castillo El 03/10/2013 16:53, "Adam Roach" escribi=C3=B3: > > On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo wrote: > > > If I implement my own WebRTC stack in a smartphone app, am I disallowed to do ICE-lite in my side?? > > I would hope so, yes. The chance that your smartphone app would have any hope if working if it did ice lite are as close to zero as to make no difference. > > The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browser" is clearly too narrow a scope. Some vendor will implement ICE-lite in its PBX and then many users will put in into a LAN with port 5060 redirection in the router. And things won't work. The problem you describe will be present anyhow. Regards. --001a11c2310e11f40e04e7d7a13c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
El 03/10/2013 16:53, "Adam Roach" <adam@nostrum.com> escribi=C3=B3:
>
> On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>
> > If I implement my own WebRTC stack in a smartphone app, am I disa= llowed to do ICE-lite in my side??
>
> I would hope so, yes. The chance that your smartphone app would have a= ny hope if working if it did ice lite are as close to zero as to make no di= fference.
>
> The fact that implementors apparently don't see this as an obvious= fact tells me that we need pretty strong language around this prohibition,= and "browser" is clearly too narrow a scope.

Some vendor will implement ICE-lite in its PBX and then many= users will put in into a LAN with port 5060 redirection in the router. And= things won't work.
The problem you describe will be present anyhow.

Regards.

--001a11c2310e11f40e04e7d7a13c-- From harald@alvestrand.no Thu Oct 3 08:27:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA7821F8E85 for ; Thu, 3 Oct 2013 08:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3kPZS5bW2kj for ; Thu, 3 Oct 2013 08:27:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 18EFD21F8EEA for ; Thu, 3 Oct 2013 08:20:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A94E39E4AB; Thu, 3 Oct 2013 17:20:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE70AVUlf7vw; Thu, 3 Oct 2013 17:20:15 +0200 (CEST) Received: from [10.0.0.100] (unknown [205.164.11.246]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DB38739E27D; Thu, 3 Oct 2013 17:20:14 +0200 (CEST) Message-ID: <524D8B2C.7050606@alvestrand.no> Date: Thu, 03 Oct 2013 17:20:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Magnus Westerlund References: <006401cebf96$7db7a4f0$7926eed0$@co.in>, <524C7FD8.1050801@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------070606000408090102030006" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:27:51 -0000 This is a multi-part message in MIME format. --------------070606000408090102030006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/03/2013 07:22 AM, Magnus Westerlund wrote: > Harald, > > Yes you are missing something. The registry you pointed at are the one for RTP profiles. The one containing the combinations with transport are SDP specific. > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2 Thanks! For consistency's sake, shouldn't all the SDP parameters that contain "RTP" also be listed in the RTP registry? I'm thinking that -transport- may have to grow an IANA section that registers TCP/RTP/SAVPF, and it needs to decide whether to register it in one or both. (Of course, the TCP/ prefix is only used in some of the examples in the RFC defining RTP over TCP - as a matter of taste, I don't like having protocol in the profile name, so would be happy not doing so if the SDP experts say this is OK by the rules, but then I need to adjust the language to not use the word "profile" in this place.) --------------070606000408090102030006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/03/2013 07:22 AM, Magnus Westerlund wrote:
Harald, 

Yes you are missing something. The registry you pointed at are the one for RTP profiles. The one containing the combinations with transport are SDP specific. 

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2

Thanks!

For consistency's sake, shouldn't all the SDP parameters that contain "RTP" also be listed in the RTP registry?

I'm thinking that -transport- may have to grow an IANA section that registers TCP/RTP/SAVPF, and it needs to decide whether to register it in one or both.

(Of course, the TCP/ prefix is only used in some of the examples in the RFC defining RTP over TCP - as a matter of taste, I don't like having protocol in the profile name, so would be happy not doing so if the SDP experts say this is OK by the rules, but then I need to adjust the language to not use the word "profile" in this place.)



--------------070606000408090102030006-- From ted.ietf@gmail.com Thu Oct 3 08:45:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259E721E80A9 for ; Thu, 3 Oct 2013 08:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl08FiFQUXLc for ; Thu, 3 Oct 2013 08:45:19 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5B28521E80BF for ; Thu, 3 Oct 2013 08:36:01 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so5876240ieb.14 for ; Thu, 03 Oct 2013 08:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TaFjmdubpk+zD2tPa+o3XyyWuz4BYCcXjyWxyz4CGBY=; b=VX/X30H7f986Khj8MDG1DG2FYv5vWsQK+KxczAO8N+haxh6+TRjuN7adGDiKoYD7wM abi7XM2Z770qu2ts2UFoSJ8dFIm/Xxzk27/g2Tvz7dFkXuiV+Ukn11K2Y9DuSS31qL2D kP7h4hd72ZXLWXU+MeuNETS+PyXG75sMxGyYI7xKzU08rqkRXGz8fG4uwDhwAr+6i0uA eZcSx2dJHKa7LYxF0EezQByHWNnp/sJhHvvJNSfUDTfsJOz93JDUfQ8iIu1jl5MqHGqV p7UjIOffk1XqQliSF6I3DBzQgVK6g70+gt6UM1QKNe4mE9TDWWjXj/yEc4YnZ7w5bJfP 8mIA== MIME-Version: 1.0 X-Received: by 10.50.9.72 with SMTP id x8mr2641377iga.19.1380814557460; Thu, 03 Oct 2013 08:35:57 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Thu, 3 Oct 2013 08:35:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Oct 2013 08:35:57 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/mixed; boundary=001a11c2fdc432dc2004e7d7f121 Cc: Cullen Jennings Subject: [rtcweb] Fwd: [rmcat] time to get busy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:45:26 -0000 --001a11c2fdc432dc2004e7d7f121 Content-Type: multipart/alternative; boundary=001a11c2fdc432dc1b04e7d7f11f --001a11c2fdc432dc1b04e7d7f11f Content-Type: text/plain; charset=ISO-8859-1 Dear WG members, As you see below, the RMCAT working group is seeking reviewers for the requirements document and evaluations scenarios. Please review the document. thanks, Ted, Cullen, Magnus ---------- Forwarded message ---------- From: Eggert, Lars Date: Mon, Sep 9, 2013 at 4:56 AM Subject: [rmcat] time to get busy To: "rmcat@ietf.org WG" Hi folks, it's only six short weeks to the ID submission cutoff for Vancouver. I'd like us to complete some work before then; specifically: (1) Reviews for draft-ietf-rmcat-cc-requirements-00, so that we can last-call it in Vancouver. Any volunteers? (2) Have some rough consensus on at least one initial evaluation scenario. This includes a network topology, a traffic workload and a list of performance metrics for that scenario. On (2), is the design team still having calls? I have not seen any announcements on the list after Berlin. If not, we should probably restart the calls. Thanks, Lars --001a11c2fdc432dc1b04e7d7f11f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear WG members,

As you see below, the RM= CAT working group is seeking reviewers for the requirements document and ev= aluations scenarios.=A0 Please review the document.

thanks,
Ted, Cullen, Magnus

---------- Forwarded message ----------
From: Eggert, Lars <lars@netapp.com>
Date: Mon, Sep 9, 2013 at 4:56 AM
Subject: [rmcat] time to get busy
T= o: "rmcat@ietf.org WG" <= rmcat@ietf.org>


Hi folk= s,

it's only six short weeks to the ID submission cutoff for Vancouver. I&= #39;d like us to complete some work before then; specifically:

(1) Reviews for draft-ietf-rmcat-cc-requirements-00, so that we can last-ca= ll it in Vancouver. Any volunteers?

(2) Have some rough consensus on at least one initial evaluation scenario. = This includes a network topology, a traffic workload and a list of performa= nce metrics for that scenario.

On (2), is the design team still having calls? I have not seen any announce= ments on the list after Berlin. If not, we should probably restart the call= s.

Thanks,
Lars

--001a11c2fdc432dc1b04e7d7f11f-- --001a11c2fdc432dc2004e7d7f121 Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 X-Attachment-Id: f06bf28f216c88d8_0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cDov L2dwZ3Rvb2xzLm9yZw0KDQppUUNWQXdVQlVpMjNjOVpjbnBSdmVvMXhBUUorWUFRQWdaOGZQMllm OWJaQUlpZDNJMHYrUUoyVkFDRUMzaStLDQpPaUluTTBPY21IK2g5NHVSQ1hWaGt0bWhJcEFkLzZP dzZvT2ZHZExWZ1lkUmd5WFZjNDQ3bWlWVjZmeDJQU0NXDQppM1oxNDRua0ZPd0NTRy83ZmQ5aWNK QnN1VjVCZ2Z1a0Mwd2NqTnFZRVlHRzRMN3pDeXAvTXV5d1NuMWRyUmVNDQpQUFE2NlZmRnJ2cz0N Cj0xUUcwDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --001a11c2fdc432dc2004e7d7f121-- From karl.stahl@intertex.se Thu Oct 3 09:08:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23C421F89EB for ; Thu, 3 Oct 2013 09:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNlTxnTRq0BO for ; Thu, 3 Oct 2013 09:08:32 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id D24E021E80CD for ; Thu, 3 Oct 2013 08:58:23 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310031758195388; Thu, 03 Oct 2013 17:58:19 +0200 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" References: <079001ceb618$2f551ae0$8dff50a0$@stahl@intertex.se> <07e501ceb71a$07f766d0$17e63470$@stahl@intertex.se> In-Reply-To: Date: Thu, 3 Oct 2013 17:58:20 +0200 Message-ID: <021101cec051$61be79c0$253b6d40$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOwEYC8R4lr9oytECeVQBiAelBJZnjIbhg Content-Language: sv Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 16:08:45 -0000 Yes, I'll check with them and I return on your fluffy email. /Karl -----Ursprungligt meddelande----- Fr=E5n: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 Skickat: den 3 oktober 2013 16:37 Till: Karl Stahl Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 On Sep 21, 2013, at 4:29 PM, Karl Stahl wrote: > I've heard several carries expressing that they want to provide their=20 > own TURN servers with their accesses. Any chance you could put me in touch with some of them. I'd love to get = more information on what is needed so we can solve this. From matthew@matthew.at Thu Oct 3 09:11:58 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E969A11E80F6 for ; Thu, 3 Oct 2013 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7oMlvJplPk6 for ; Thu, 3 Oct 2013 09:11:52 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id B7FB621E80CF for ; Thu, 3 Oct 2013 09:01:56 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 7104F420739 for ; Thu, 3 Oct 2013 09:01:35 -0700 (PDT) Message-ID: <524D94E0.7020801@matthew.at> Date: Thu, 03 Oct 2013 09:01:36 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> In-Reply-To: <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 16:11:59 -0000 On 10/3/2013 7:53 AM, Adam Roach wrote: > On Oct 3, 2013, at 9:31, Iñaki Baz Castillo wrote: > >> If I implement my own WebRTC stack in a smartphone app, am I disallowed to do ICE-lite in my side?? > I would hope so, yes. The chance that your smartphone app would have any hope if working if it did ice lite are as close to zero as to make no difference. > > The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browser" is clearly too narrow a scope. > > The spec should say that: 1. The prohibition on sending media prior to completing a STUN connectivity test is a MUST 2. A full ICE implementation is a SHOULD If I'm building a system with clients at one end and gateways with public addresses at the other, a full ICE implementation isn't required anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consented *is* required. Matthew Kaufman From christer.holmberg@ericsson.com Thu Oct 3 09:46:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930B511E815A for ; Thu, 3 Oct 2013 09:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r410Mldxqc9f for ; Thu, 3 Oct 2013 09:45:55 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C8DC921E80A6 for ; Thu, 3 Oct 2013 09:31:01 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-c3-524d9bc4388a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CB.B4.03802.4CB9D425; Thu, 3 Oct 2013 18:31:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 18:31:00 +0200 From: Christer Holmberg To: Matthew Kaufman , "rtcweb@ietf.org" Thread-Topic: [rtcweb] No a=ice-lite in JSEP-04 Thread-Index: Ac698bCDm/FvoM3PQXG8Sb8kVVaquv//37SAgAB0oAD/+7OiAIAIfEKAgAABegCAAAYXAIAAEvsAgAApJSb///9iQw== Date: Thu, 3 Oct 2013 16:30:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com>, <524D94E0.7020801@matthew.at> In-Reply-To: <524D94E0.7020801@matthew.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B3AECESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre6R2b5BBlcfq1u0zT7CYrH2Xzu7 A5PHkiU/mTxOdXoFMEVx2aSk5mSWpRbp2yVwZXQ2XGYpaFCrePvzGXMD4yv5LkZODgkBE4nf a44yQdhiEhfurWfrYuTiEBI4zCix+MUPFghnMaPE42VHgKo4ONgELCS6/2mDmCICvhI/lquD 9AoL6En8ffWHHcQWEdCXWLfxIBuEnSWxYOI/sDiLgIpE0+bfYDYvUOuD+++YIMZ/YZZYvaQR LMEpoCXx7OtCRhCbEeig76fWgB3HLCAucevJfKhDBSSW7DnPDGGLSrx8/I8V5B4JAUWJ5f1y EOX5Eot6DrFC7BKUODnzCcsERpFZSCbNQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w5B 1VhLHF26jRlZzQJGjlWM7LmJmTnp5UabGIHxdHDLb9UdjHfOiRxilOZgURLn/fDWOUhIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QD44JLk1naW2z0dGRryj2VhDilIl0i/wdM2Fx5yWvP6492 AmW82swztG7l5U6w/JXnUJFkVqHA//HCtD963lETJ7mf9rd+WJ5qwt0pc+ffzqvBgVHamo9Y 91QJRJfebtBSscmLUTwTfnLL2/f+CdciT/9TKtJSbg/oyepNfXui7M+GW7+tf/xSYinOSDTU Yi4qTgQAwkvx3HUCAAA= Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 16:46:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B3AECESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Do we really need to say more than the ICE RFC already says? I think it exp= lains when ICE-lite is appropriate, and when it isn't. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthe= w Kaufman [matthew@matthew.at] Sent: Thursday, 03 October 2013 7:01 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04 On 10/3/2013 7:53 AM, Adam Roach wrote: > On Oct 3, 2013, at 9:31, I=F1aki Baz Castillo wrote: > >> If I implement my own WebRTC stack in a smartphone app, am I disallowed = to do ICE-lite in my side?? > I would hope so, yes. The chance that your smartphone app would have any = hope if working if it did ice lite are as close to zero as to make no diffe= rence. > > The fact that implementors apparently don't see this as an obvious fact t= ells me that we need pretty strong language around this prohibition, and "b= rowser" is clearly too narrow a scope. > > The spec should say that: 1. The prohibition on sending media prior to completing a STUN connectivity test is a MUST 2. A full ICE implementation is a SHOULD If I'm building a system with clients at one end and gateways with public addresses at the other, a full ICE implementation isn't required anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consented *is* required. Matthew Kaufman _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C4B3AECESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <574412FBD40D734682B23C07AD40AB91@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

Do we really need to say more than the ICE RFC already says? I think it = explains when ICE-lite is appropriate, and when it isn't.

 

Regards,

 

Christer

 

 

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behal= f of Matthew Kaufman [matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, I=F1aki Baz Castillo <ibc@aliax.net> wr= ote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disal= lowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have a= ny hope if working if it did ice lite are as close to zero as to make no di= fference.
>
> The fact that implementors apparently don't see this as an obvious fac= t tells me that we need pretty strong language around this prohibition, and= "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consented *is* required.

Matthew Kaufman
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--_000_7594FB04B1934943A5C02806D1A2204B1C4B3AECESESSMB209erics_-- From ibc@aliax.net Thu Oct 3 10:06:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E9F21E8103 for ; Thu, 3 Oct 2013 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4Oxxd5G-u23 for ; Thu, 3 Oct 2013 10:06:12 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id C20C021F8FF5 for ; Thu, 3 Oct 2013 09:48:20 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id q4so1821165qcx.26 for ; Thu, 03 Oct 2013 09:48:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TzDCwr5px9vw9+wOFWhaTWI/n1mFYEaT1nmrkVTAMac=; b=fFIjd5SWEnO+uc3xmENYyoUA53m616w77fmGVnMk0Z9ejVowiaLT2axVQFE3Jzrl+8 bw30Ak6kSObcqlKhl7O3LnwEr83OHINCnfxUjFDnkMlqoEaEiQsyPqvrub3pgsTTTCz4 wQpVd7Ug8DrsY4scvSLe/lIZFhp54bN+wyoi1uVo5tbEPb479CpEmphSyJmLN4Yp5RRL zdiY++NM36DY27kyvUCIrYiYuJUzveoyR1HkRgE9QD+PsSRBT3iOe3Io+O0hIm4o40y4 f1ONw96re3E7WAwwRrbJYFTsUjiI3Q6Vr9S7XIn7FVMPt9yQ6b1RsY6hfm/LKAmmhpdh 5dtw== X-Gm-Message-State: ALoCoQnNWau/cbrV2LVSpuQmjYUKpQJs98jWBnOL4wwnt+vwKWvM6jTgX8TkRxSLn30FstMnfyP9 MIME-Version: 1.0 X-Received: by 10.224.69.132 with SMTP id z4mr11656647qai.78.1380818897948; Thu, 03 Oct 2013 09:48:17 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Thu, 3 Oct 2013 09:48:17 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Thu, 3 Oct 2013 09:48:17 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> <524D94E0.7020801@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> Date: Thu, 3 Oct 2013 18:48:17 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2310ee9655504e7d8f364 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:06:22 -0000 --001a11c2310ee9655504e7d8f364 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. This is not a HOWTO but a set of specs. -- I=C3=B1aki Baz Castillo El 03/10/2013 18:46, "Christer Holmberg" escribi=C3=B3: > Hi, > > > > Do we really need to say more than the ICE RFC already says? I think it > explains when ICE-lite is appropriate, and when it isn't. > > > > Regards, > > > > Christer > > > > > ------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Matthew Kaufman [matthew@matthew.at] > *Sent:* Thursday, 03 October 2013 7:01 PM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04 > > On 10/3/2013 7:53 AM, Adam Roach wrote: > > On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo wrote: > > > >> If I implement my own WebRTC stack in a smartphone app, am I disallowe= d > to do ICE-lite in my side?? > > I would hope so, yes. The chance that your smartphone app would have an= y > hope if working if it did ice lite are as close to zero as to make no > difference. > > > > The fact that implementors apparently don't see this as an obvious fact > tells me that we need pretty strong language around this prohibition, and > "browser" is clearly too narrow a scope. > > > > > > The spec should say that: > 1. The prohibition on sending media prior to completing a STUN > connectivity test is a MUST > 2. A full ICE implementation is a SHOULD > > If I'm building a system with clients at one end and gateways with > public addresses at the other, a full ICE implementation isn't required > anywhere in order to make calls through those gateways. But keeping the > browser from being able to spew media at something that hasn't consented > *is* required. > > Matthew Kaufman > _______________________________________________ > 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 > > --001a11c2310ee9655504e7d8f364 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Agreed. This is not a HOWTO but a set of specs.

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

El 03/10/2013 18:46, "Christer Holmberg&quo= t; <christer.holmberg@= ericsson.com> escribi=C3=B3:

Hi,

=C2=A0

Do we really need to say more than the ICE RFC already says? I think it = explains when ICE-lite is appropriate, and when it isn't.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb-bounces@ietf.org [rtcweb-bounces@i= etf.org] on behalf of Matthew Kaufman [matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf= .org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disal= lowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have a= ny hope if working if it did ice lite are as close to zero as to make no di= fference.
>
> The fact that implementors apparently don't see this as an obvious= fact tells me that we need pretty strong language around this prohibition,= and "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required=
anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consente= d
*is* required.

Matthew Kaufman
_______________________________________________
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

--001a11c2310ee9655504e7d8f364-- From christer.holmberg@ericsson.com Thu Oct 3 10:08:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847DB21E811B for ; Thu, 3 Oct 2013 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.176 X-Spam-Level: X-Spam-Status: No, score=-4.176 tagged_above=-999 required=5 tests=[AWL=-1.578, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdR58JGAjVRy for ; Thu, 3 Oct 2013 10:08:19 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 47B6321F8934 for ; Thu, 3 Oct 2013 09:48:59 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-3b-524d9ffaea69 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 57.90.25272.AFF9D425; Thu, 3 Oct 2013 18:48:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 18:48:58 +0200 From: Christer Holmberg To: Matthew Kaufman , "rtcweb@ietf.org" Thread-Topic: [rtcweb] No a=ice-lite in JSEP-04 Thread-Index: Ac698bCDm/FvoM3PQXG8Sb8kVVaquv//37SAgAB0oAD/+7OiAIAIfEKAgAABegCAAAYXAIAAEvsAgAAINACAACYZFP///4TN Date: Thu, 3 Oct 2013 16:48:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com>, <524D94E0.7020801@matthew.at>, <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B3C06ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre6v+b5BBs9bZCzaZh9hsVj7r53d gcljyZKfTB6nOr0CmKK4bFJSczLLUov07RK4Mm4sO8pc8N2g4kjbf7YGxm7NLkZODgkBE4n5 +26wQthiEhfurWfrYuTiEBI4yiixbONzVghnMaPEkeO7gBwODjYBC4nuf9ogpoiAr8SP5eog vcICehJ/X/1hB7FFBPQl1m08yAZh50ksOLcHzGYRUJGY8qkVbBcvUGvzhn1MEON3ski8erOC ESTBKeAnse7SHCYQmxHooO+n1oDZzALiEreezGeCOFRAYsme88wQtqjEy8f/wE6TEFCUWN4v B1GeL3Fo1UFGiF2CEidnPmGZwCgyC8mkWUjKZiEpg4jrSdyYOoUNwtaWWLbwNTOErSsx498h qBpriQnnbzMiq1nAyLGKkaM4tTgpN93IYBMjMKIObvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmk J5akZqemFqQWxReV5qQWH2Jk4uCUamA8LnPpvmb6tWcrpix2YNy6em+SaN6LnGzFgB+Te2Lr IzmFlx7beyqDRWdVWZnd8kf/93OtPfyrueRo59Z75TfCMm4LWcncn/7XXPxwbcrHpNcXz57x 23j72nnbGU4ypSr/Jcs/ZEzRy3HR4t33fhGfFefTEyGsxjx1WZp8NyXnsNftnlVn38mlxFKc kWioxVxUnAgAJrmGdXYCAAA= Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:08:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B3C06ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What I think we DO need to say (eventhough someone may think it's obvious) = , in the continous consent spec, is that ICE-lite entities do not send cc S= TUN requests. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Thursday, 03 October 2013 7:30 PM To: Matthew Kaufman; rtcweb@ietf.org Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04 Hi, Do we really need to say more than the ICE RFC already says? I think it exp= lains when ICE-lite is appropriate, and when it isn't. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthe= w Kaufman [matthew@matthew.at] Sent: Thursday, 03 October 2013 7:01 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04 On 10/3/2013 7:53 AM, Adam Roach wrote: > On Oct 3, 2013, at 9:31, I=F1aki Baz Castillo wrote: > >> If I implement my own WebRTC stack in a smartphone app, am I disallowed = to do ICE-lite in my side?? > I would hope so, yes. The chance that your smartphone app would have any = hope if working if it did ice lite are as close to zero as to make no diffe= rence. > > The fact that implementors apparently don't see this as an obvious fact t= ells me that we need pretty strong language around this prohibition, and "b= rowser" is clearly too narrow a scope. > > The spec should say that: 1. The prohibition on sending media prior to completing a STUN connectivity test is a MUST 2. A full ICE implementation is a SHOULD If I'm building a system with clients at one end and gateways with public addresses at the other, a full ICE implementation isn't required anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consented *is* required. Matthew Kaufman _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C4B3C06ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

What I think we DO need to say (eventhough someone may think it's obviou= s) , in the continous consent spec, is that ICE-lite entities do = not send cc STUN requests.

 

Regards,

 

Christer

 

From: rtcweb-bounces@ietf.org [rtcweb-bou= nces@ietf.org] on behalf of Christer Holmberg [christer.holmberg@ericsson.c= om]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

Hi,

 

Do we really need to say more than the ICE RFC already says? I think it = explains when ICE-lite is appropriate, and when it isn't.

 

Regards,

 

Christer

 

 

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behal= f of Matthew Kaufman [matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, I=F1aki Baz Castillo <ibc@aliax.net> wr= ote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disal= lowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have a= ny hope if working if it did ice lite are as close to zero as to make no di= fference.
>
> The fact that implementors apparently don't see this as an obvious fac= t tells me that we need pretty strong language around this prohibition, and= "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consented *is* required.

Matthew Kaufman
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--_000_7594FB04B1934943A5C02806D1A2204B1C4B3C06ESESSMB209erics_-- From partha@parthasarathi.co.in Thu Oct 3 10:29:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1BB21F85BB for ; Thu, 3 Oct 2013 10:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DNEyKJzEHzz for ; Thu, 3 Oct 2013 10:28:51 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.157]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C321E8128 for ; Thu, 3 Oct 2013 10:09:25 -0700 (PDT) Received: from userPC (unknown [122.179.90.35]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 26A2886903C; Thu, 3 Oct 2013 17:09:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1380820165; bh=2cOJjaQPitpVlncaWsNsxwdEUor39MZqxgLLQfU848I=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=GqPLQHSkmHFzsKjEenC2iMjP/k36B+VVsMB++xldyMg5/l67fXf6YoQwknoHq2Tpo T/O7ZWm8OzxI6xrE2PN1+eYXYBH1EgMhO8S36ZXezf3KDmZ9QOWdyeTjDn7ULXRSJG UwAhfudFEJ7xFp9CvWc9KYzoaMLF8bgl/s/4zzVU= From: "Parthasarathi R" To: "'Harald Alvestrand'" , "'Magnus Westerlund'" References: <006401cebf96$7db7a4f0$7926eed0$@co.in>, <524C7FD8.1050801@alvestrand.no> <524D8B2C.7050606@alvestrand.no> In-Reply-To: <524D8B2C.7050606@alvestrand.no> Date: Thu, 3 Oct 2013 22:39:13 +0530 Message-ID: <005c01cec05b$4c998710$e5cc9530$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01CEC089.6651C310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7ATBJ0mqOuLxeeT3S3xu/d6dbirgACN1QA Content-Language: en-us X-CTCH-RefID: str=0001.0A020201.524DA4C5.0005, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:29:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005D_01CEC089.6651C310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Harald/Magnus, Thanks for the clarification. Please clarify whether TCP/RTP/SAVPF will be registered in IANA as separate MMUSIC specification or any another simple mechanism exists to add IANA registry. I'm interested in seeing the usage of DTLS key exchange for SRTP within TCP/RTP/SAVPF profile. Even though DTLS is designed for connectionless protocol, I assume that it works with TCP (connection oriented) protocol as well. The optimized version of TCP/RTP/SAVPF shall use TLS as a SRTP key exchange mechanism. Please correct me in case I'm missing something. Thanks Partha From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Thursday, October 03, 2013 8:50 PM To: Magnus Westerlund Cc: Parthasarathi R; rtcweb@ietf.org Subject: Re: SV: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 On 10/03/2013 07:22 AM, Magnus Westerlund wrote: Harald, Yes you are missing something. The registry you pointed at are the one for RTP profiles. The one containing the combinations with transport are SDP specific. http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-para meters-2 Thanks! For consistency's sake, shouldn't all the SDP parameters that contain "RTP" also be listed in the RTP registry? I'm thinking that -transport- may have to grow an IANA section that registers TCP/RTP/SAVPF, and it needs to decide whether to register it in one or both. (Of course, the TCP/ prefix is only used in some of the examples in the RFC defining RTP over TCP - as a matter of taste, I don't like having protocol in the profile name, so would be happy not doing so if the SDP experts say this is OK by the rules, but then I need to adjust the language to not use the word "profile" in this place.) ------=_NextPart_000_005D_01CEC089.6651C310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harald/Magnus,

 

Thanks for the clarification.  Please clarify = whether TCP/RTP/SAVPF will be registered in IANA as separate MMUSIC specification or any = another simple mechanism exists to add IANA registry.

 

I’m interested in seeing the usage of DTLS key = exchange for SRTP within TCP/RTP/SAVPF profile. Even though DTLS is designed for connectionless protocol, I assume that it works with TCP (connection = oriented) protocol as well. The optimized version of TCP/RTP/SAVPF shall use TLS = as a SRTP key exchange mechanism. Please correct me in case I’m missing = something.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, October 03, 2013 8:50 PM
To: Magnus Westerlund
Cc: Parthasarathi R; rtcweb@ietf.org
Subject: Re: SV: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01

 

On 10/03/2013 07:22 AM, Magnus Westerlund = wrote:

Harald, =

 
Yes you are missing =
something. The registry you pointed at are the one for RTP profiles. The =
one containing the combinations with transport are SDP specific. =

 
http://www.iana.org/assignments/sdp-parameters/sdp-p=
arameters.xhtml#sdp-parameters-2
=


Thanks!

For consistency's sake, shouldn't all the SDP parameters that contain "RTP" also be listed in the RTP registry?

I'm thinking that -transport- may have to grow an IANA section that = registers TCP/RTP/SAVPF, and it needs to decide whether to register it in one or = both.

(Of course, the TCP/ prefix is only used in some of the examples in the = RFC defining RTP over TCP - as a matter of taste, I don't like having = protocol in the profile name, so would be happy not doing so if the SDP experts say = this is OK by the rules, but then I need to adjust the language to not use the = word "profile" in this place.)


------=_NextPart_000_005D_01CEC089.6651C310-- From adam@nostrum.com Thu Oct 3 10:48:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6A921F8F32 for ; Thu, 3 Oct 2013 10:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkrk+t6oEVpT for ; Thu, 3 Oct 2013 10:48:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8550821F88BA for ; Thu, 3 Oct 2013 10:32:42 -0700 (PDT) Received: from Orochi.local (host-192-112-2-219.dfwairport.com [192.112.2.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r93HWTP1081921 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Oct 2013 12:32:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <524DAA28.7040108@nostrum.com> Date: Thu, 03 Oct 2013 12:32:24 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Christer Holmberg References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> <524D94E0.7020801@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030205060109060204090909" Received-SPF: pass (shaman.nostrum.com: 192.112.2.219 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:48:59 -0000 This is a multi-part message in MIME format. --------------030205060109060204090909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I would assert that what we have is demonstrably insufficient, inasmuch as you, Iñaki, demonstrated just a few messages ago that you don't understand the present guidance. No one who does would ever even imagine putting ICE lite into a smartphone application. Perhaps a reiteration in the RTCWEB documents would be appropriate. /a On 10/3/13 11:48, Iñaki Baz Castillo wrote: > > Agreed. This is not a HOWTO but a set of specs. > > -- > Iñaki Baz Castillo > > > > El 03/10/2013 18:46, "Christer Holmberg" > > escribió: > > Hi, > > Do we really need to say more than the ICE RFC already says? I > think it explains when ICE-lite is appropriate, and when it isn't. > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* rtcweb-bounces@ietf.org > [rtcweb-bounces@ietf.org ] on > behalf of Matthew Kaufman [matthew@matthew.at > ] > *Sent:* Thursday, 03 October 2013 7:01 PM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=ice-lite in JSEP-04 > > On 10/3/2013 7:53 AM, Adam Roach wrote: > > On Oct 3, 2013, at 9:31, Iñaki Baz Castillo > wrote: > > > >> If I implement my own WebRTC stack in a smartphone app, am I > disallowed to do ICE-lite in my side?? > > I would hope so, yes. The chance that your smartphone app would > have any hope if working if it did ice lite are as close to zero > as to make no difference. > > > > The fact that implementors apparently don't see this as an > obvious fact tells me that we need pretty strong language around > this prohibition, and "browser" is clearly too narrow a scope. > > > > > > The spec should say that: > 1. The prohibition on sending media prior to completing a STUN > connectivity test is a MUST > 2. A full ICE implementation is a SHOULD > > If I'm building a system with clients at one end and gateways with > public addresses at the other, a full ICE implementation isn't > required > anywhere in order to make calls through those gateways. But > keeping the > browser from being able to spew media at something that hasn't > consented > *is* required. > > Matthew Kaufman > _______________________________________________ > 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 --------------030205060109060204090909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I would assert that what we have is demonstrably insufficient, inasmuch as you, Iñaki, demonstrated just a few messages ago that you don't understand the present guidance. No one who does would ever even imagine putting ICE lite into a smartphone application.

Perhaps a reiteration in the RTCWEB documents would be appropriate.

/a

On 10/3/13 11:48, Iñaki Baz Castillo wrote:

Agreed. This is not a HOWTO but a set of specs.

--
Iñaki Baz Castillo
<ibc@aliax.net>

El 03/10/2013 18:46, "Christer Holmberg" <christer.holmberg@ericsson.com> escribió:

Hi,

 

Do we really need to say more than the ICE RFC already says? I think it explains when ICE-lite is appropriate, and when it isn't.

 

Regards,

 

Christer

 

 

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthew Kaufman [matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disallowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have any hope if working if it did ice lite are as close to zero as to make no difference.
>
> The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required
anywhere in order to make calls through those gateways. But keeping the
browser from being able to spew media at something that hasn't consented
*is* required.

Matthew Kaufman
_______________________________________________
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

--------------030205060109060204090909-- From harald@alvestrand.no Thu Oct 3 10:58:40 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1183721F8546 for ; Thu, 3 Oct 2013 10:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g32zQroOe90i for ; Thu, 3 Oct 2013 10:58:28 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F128711E8133 for ; Thu, 3 Oct 2013 10:43:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B07739E27D for ; Thu, 3 Oct 2013 19:43:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY42oCuEa1+O for ; Thu, 3 Oct 2013 19:43:35 +0200 (CEST) Received: from [172.19.6.255] (unknown [216.239.45.95]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9478E39E222 for ; Thu, 3 Oct 2013 19:43:34 +0200 (CEST) Message-ID: <524DACC4.8060901@alvestrand.no> Date: Thu, 03 Oct 2013 19:43:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com>, <524D94E0.7020801@matthew.at>, <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------010000050403030206050709" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:58:40 -0000 This is a multi-part message in MIME format. --------------010000050403030206050709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 10/03/2013 06:48 PM, Christer Holmberg wrote: > > What I think we DO need to say (eventhough someone may think it's > obvious) , in the continous consent spec, is that ICE-lite entities do > not send cc STUN requests. > Hm. If correct: What are the consequences of that? It seems to me that the entity sending cc STUN requests is the one asking for permission (although I may have misremembered something). So this means that if there are no cc STUN requests coming from the ice-lite end, the ice-lite end is neither requesting permission to contine to send, nor is it going to stop sending when the WebRTC end tries to revoke permission. With the security guarantees we've been trying to work in here, where it's safe to execute Javascript because there's a limit to how much damage you can do with it.... I reach this conclusion: Entities that implement the WebRTC API, and allow others' Javascript to access that API (for brevity's sake, let's call them "browsers", even though W3C tends to call them "UAs") MUST NOT implement ice-lite. No matter whether they have a public IP address or not; if they implement ice-lite, they can't offer the security guarantees we want. Entities that don't offer an API that allows third parties to start connections from it (for brevity, "non-browsers") have to be taken over in other ways in order to perform an attack anyway, in which case all the WebRTC guarantees are shot - so there's no harm in allowing them to implement ice-lite. > > > Regards, > > > > Christer > > > > ------------------------------------------------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Christer Holmberg [christer.holmberg@ericsson.com] > *Sent:* Thursday, 03 October 2013 7:30 PM > *To:* Matthew Kaufman; rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=ice-lite in JSEP-04 > > Hi, > > > > Do we really need to say more than the ICE RFC already says? I think > it explains when ICE-lite is appropriate, and when it isn't. > > > > Regards, > > > > Christer > > > > > > ------------------------------------------------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Matthew Kaufman [matthew@matthew.at] > *Sent:* Thursday, 03 October 2013 7:01 PM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=ice-lite in JSEP-04 > > On 10/3/2013 7:53 AM, Adam Roach wrote: > > On Oct 3, 2013, at 9:31, Iñaki Baz Castillo wrote: > > > >> If I implement my own WebRTC stack in a smartphone app, am I > disallowed to do ICE-lite in my side?? > > I would hope so, yes. The chance that your smartphone app would have > any hope if working if it did ice lite are as close to zero as to make > no difference. > > > > The fact that implementors apparently don't see this as an obvious > fact tells me that we need pretty strong language around this > prohibition, and "browser" is clearly too narrow a scope. > > > > > > The spec should say that: > 1. The prohibition on sending media prior to completing a STUN > connectivity test is a MUST > 2. A full ICE implementation is a SHOULD > > If I'm building a system with clients at one end and gateways with > public addresses at the other, a full ICE implementation isn't required > anywhere in order to make calls through those gateways. But keeping the > browser from being able to spew media at something that hasn't consented > *is* required. > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------010000050403030206050709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/03/2013 06:48 PM, Christer Holmberg wrote:

What I think we DO need to say (eventhough someone may think it's obvious) , in the continous consent spec, is that ICE-lite entities do not send cc STUN requests.


Hm. If correct: What are the consequences of that?

It seems to me that the entity sending cc STUN requests is the one asking for permission (although I may have misremembered something). So this means that if there are no cc STUN requests coming from the ice-lite end, the ice-lite end is neither requesting permission to contine to send, nor is it going to stop sending when the WebRTC end tries to revoke permission.

With the security guarantees we've been trying to work in here, where it's safe to execute Javascript because there's a limit to how much damage you can do with it.... I reach this conclusion:

Entities that implement the WebRTC API, and allow others' Javascript to access that API (for brevity's sake, let's call them "browsers", even though W3C tends to call them "UAs") MUST NOT implement ice-lite. No matter whether they have a public IP address or not; if they implement ice-lite, they can't offer the security guarantees we want.

Entities that don't offer an API that allows third parties to start connections from it (for brevity, "non-browsers") have to be taken over in other ways in order to perform an attack anyway, in which case all the WebRTC guarantees are shot - so there's no harm in allowing them to implement ice-lite.


 

Regards,

 

Christer

 

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Christer Holmberg [christer.holmberg@ericsson.com]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; rtcweb@ietf.org
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

Hi,

 

Do we really need to say more than the ICE RFC already says? I think it explains when ICE-lite is appropriate, and when it isn't.

 

Regards,

 

Christer

 

 

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthew Kaufman [matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disallowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have any hope if working if it did ice lite are as close to zero as to make no difference.
>
> The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required
anywhere in order to make calls through those gateways. But keeping the
browser from being able to spew media at something that hasn't consented
*is* required.

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


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



-- 
Surveillance is pervasive. Go Dark.
--------------010000050403030206050709-- From christer.holmberg@ericsson.com Thu Oct 3 11:44:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB2621E809C for ; Thu, 3 Oct 2013 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWZNIfEQ9xFA for ; Thu, 3 Oct 2013 11:44:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BF67B21F8F32 for ; Thu, 3 Oct 2013 11:35:18 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-02-524db8e5cfed Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 34.AD.03802.5E8BD425; Thu, 3 Oct 2013 20:35:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 20:35:16 +0200 From: Christer Holmberg To: Karl Stahl , Magnus Westerlund Thread-Topic: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: AQHOvpxUWC3SPyNT0EKIc+6nFGZBBpnh5LSAgAFsUHaAAABltQ== Date: Thu, 3 Oct 2013 18:35:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B3CFA@ESESSMB209.ericsson.se> References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com>, <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> In-Reply-To: <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B3CFAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvre7THb5BBkufKFhsvjmJ0eJdz1o2 i7X/2tkdmD2WLPnJ5PFp63wWjy+XP7MFMEdx2aSk5mSWpRbp2yVwZbzc8pel4JhfxfTebYwN jPsduxg5OSQETCTurf/KCGGLSVy4t56ti5GLQ0jgMKPE0dUvWCGcxYwSG26fYu5i5OBgE7CQ 6P6nDWKKCMRKnDtgCFLCLLCCUaLp/VwWkEHCAhESrxbtBrNFBCIlTh89xAphO0lcfrSSGcRm EVCRaJu+BizOK+Ar8erlPKjFq5klJj4+BtbMKeAg8fn1WXYQmxHouu+n1jCB2MwC4hK3nsxn grhaQGLJnvPMELaoxMvH/1ghbEWJq9OXQ9XnS9x7+YIFYpmgxMmZT1gmMIrOQjJqFpKyWUjK IOJ6EjemTmGDsLUlli18zQxh60rM+HcIqsZaYua5bhZkNQsYOVYxsucmZuaklxttYgRG4MEt v1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjK795rlxSyzO 123iNnCf9+sEY9X1HNYG9owF9WudvxWI7Dv0OiAzMTn4u3p/5QIT3612hWv8HYza/73YcTr9 mOiXnc5K39I+XlI/nv6JW2nysrjUwvzLwnE8gSIdf+0Z+b5OeWJuu+7fh52HOhvW1xx76X2/ Werw8bLEZ40/3Hvfnfg9932tlhJLcUaioRZzUXEiAGp7RPuOAgAA Cc: "rtcweb@ietf.org" , "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" Subject: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 18:44:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B3CFAESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I believe this discussion is outside the scope of the WGLC of draft-ietf-rt= cweb-use-cases-and-requirements, so I would suggest changing the subject. Thanks! Regards, Christer ________________________________ From: Karl Stahl [karl.stahl@intertex.se] Sent: Thursday, 03 October 2013 1:50 AM To: Magnus Westerlund Cc: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.iet= f.org Subject: SV: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requ= irements-11 Hej Magnus, Hmm, if we (IETF) allowed ourselves to each decennium allocate payload type= s for the 3-4 most common/important codecs, the unassigned pool (PT:35-71) would last 100 years! I think our own Opus, H.264, and maybe some mobile an= d the Skype codec (SILK) could be honored AND of course the mandatory video codec that will be selected for WebRTC (VPx or H.26y). The need for assigning new payload types may have been small - dynamic payload types works equally well - EXCEPT for the quality routing reason. (RSVP quality type of networks could at least know maximum bandwidth. DPI guesswork could/should be avoided.) So with WebRTC, expecting to finally bring us beyond POTS quality on a massive scale - we (IETF) may reconsider... If that really is impossible, is there anything stopping _the RTCWEB RFC_ t= o recommend (MUST or SHOULD) specific _dynamic_ payload types to be used for e.g. Opus:PT=3D111, H.264:PT=3D112, VP9:PT=3D113 etc.? That may be good eno= ugh, and surely others, like SIP-client, would follow this usage (or add it to their recommendations). /Karl -----Ursprungligt meddelande----- Fr=E5n: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Skickat: den 1 oktober 2013 13:51 Till: Karl Stahl Kopia: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org =C4mne: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Hi Karl, I just want to provide a comment on your below suggestion. On 2013-09-21 23:44, Karl Stahl wrote: > Yet another thing related to > draft-ietf-rtcweb-use-cases-and-requirements-11: > It is about payload type, PT=3D, in SDP and RTP, so I am copying MMUSIC > > Network service providers have expressed an interest to know whether > packets carry audio or video, to be able to handle them differently in > the network (e.g. quality wise). PT is visible outside the encrypted > payload in RTP, however if dynamic payload types PT:96-127 are used, > you cannot know what the payload is without knowledge of the SDP > (which we for WebRTC must assume the network provider has no knowledge of). > > In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I > see no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC. > > So, can we have payload types assigned to codecs that will be > recommended for WebRTC are unassigned)? And this is because over 10 years ago we (IETF) stopped assigning static payload types, actually forbid future static assignments. All payload types are assumed to be dynamically assigned in RTCWEB. The reason is that we hav= e more codecs and codec configurations than there is PT space. > Or can we at least split dynamic payload types PT:96-127 into groups > for audio and video codecs? That assumes that one understand how many of each there is going to be. You also have the supplemental payload types, like RTP Retransmission that has a one to one binding with another payload type in the RTP session. So how should one do this split without being significantly restricted in how you use the payload type space. I personally see that the 96-127 space will be insufficient in quite many cases due to the combination of supporting a number of audio and video codes combined with retransmission and FEC. I don't really dare doing a split, as I would have to live with it for the foreseeable future, and it would inevitable be wrong. Cheers Magnus --_000_7594FB04B1934943A5C02806D1A2204B1C4B3CFAESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

I believe this discussion is outside the scope of the WGLC of draft-ietf= -rtcweb-use-cases-and-requirements, so I would suggest changing the su= bject.

 

Thanks!

 

Regards,

 

Christer

 

 

From: Karl Stahl [karl.stahl@intertex.se]
Sent: Thursday, 03 October 2013 1:50 AM
To: Magnus Westerlund
Cc: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@to= ols.ietf.org
Subject: SV: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-a= nd-requirements-11

Hej Magnus,

Hmm, if we (IETF) allowed ourselves to each decennium allocate payload type= s
for the 3-4 most common/important codecs, the unassigned pool (PT:35-71) would last 100 years! I think our own Opus, H.264, and maybe some mobile an= d
the Skype codec (SILK) could be honored AND of course the mandatory video codec that will be selected for WebRTC (VPx or H.26y).

The need for assigning new payload types may have been small - dynamic
payload types works equally well - EXCEPT for the quality routing reason. (RSVP quality type of networks could at least know maximum bandwidth. DPI guesswork could/should be avoided.) So with WebRTC, expecting to finally bring us beyond POTS quality on a massive scale - we (IETF) may
reconsider...

If that really is impossible, is there anything stopping _the RTCWEB RFC_ t= o
recommend (MUST or SHOULD) specific _dynamic_ payload types to be used for<= br> e.g. Opus:PT=3D111, H.264:PT=3D112, VP9:PT=3D113 etc.? That may be good eno= ugh,
and surely others, like SIP-client, would follow this usage (or add it to their recommendations).

/Karl

-----Ursprungligt meddelande-----
Fr=E5n: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Skickat: den 1 oktober 2013 13:51
Till: Karl Stahl
Kopia: rtcweb@ietf.org;
draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
=C4mne: Re: [rtcweb] [mmusic] WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi Karl,

I just want to provide a comment on your below suggestion.

On 2013-09-21 23:44, Karl Stahl wrote:
> Yet another thing related to
> draft-ietf-rtcweb-use-cases-and-requirements-11:
> It is about payload type, PT=3D, in SDP and RTP, so I am copying MMUSI= C
>
> Network service providers have expressed an interest to know whether <= br> > packets carry audio or video, to be able to handle them differently in=
> the network (e.g. quality wise). PT is visible outside the encrypted <= br> > payload in RTP, however if dynamic payload types PT:96-127 are used, <= br> > you cannot know what the payload is without knowledge of the SDP
> (which we for WebRTC must assume the network provider has no knowledge=
of).
>
> In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I > see no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC. >
> So, can we have payload types assigned to codecs that will be
> recommended for WebRTC are unassigned)?

And this is because over 10 years ago we (IETF) stopped assigning static payload types, actually forbid future static assignments. All payload types=
are assumed to be dynamically assigned in RTCWEB. The reason is that we hav= e
more codecs and codec configurations than there is PT space.


> Or can we at least split dynamic payload types PT:96-127 into groups <= br> > for audio and video codecs?

That assumes that one understand how many of each there is going to be.
You also have the supplemental payload types, like RTP Retransmission that<= br> has a one to one binding with another payload type in the RTP session. So how should one do this split without being significantly restricted in how<= br> you use the payload type space. I personally see that the 96-127 space will=
be insufficient in quite many cases due to the combination of supporting a<= br> number of audio and video codes combined with retransmission and FEC.

I don't really dare doing a split, as I would have to live with it for the<= br> foreseeable future, and it would inevitable be wrong.

Cheers

Magnus

--_000_7594FB04B1934943A5C02806D1A2204B1C4B3CFAESESSMB209erics_-- From juberti@google.com Thu Oct 3 11:59:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2946C21F898A for ; Thu, 3 Oct 2013 11:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cM-ITiIznaa for ; Thu, 3 Oct 2013 11:59:48 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFAA21F9228 for ; Thu, 3 Oct 2013 11:49:38 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lc6so1298622vcb.1 for ; Thu, 03 Oct 2013 11:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FXPGpnXR1qR3btzpEEmv9NW+IgxtiuwKrOHhodEHQEI=; b=HeuNKG5HSZ65buRajb9QHUh2/XlYc9IVtiw8RHY6Ae/9qakXLcCIbn71HUT8dE491o 7ici7BzyVPH4elTzBFIqqIKsDWPMRVYwvgB+zBWoAwWHVn87PyOCTCPZOUyX7KahFASk AO2qD4XAeFEqt9hI3553JVW64VOrg4wo1ybxiF5+dDZM/MFzrbd/oa6errRg2dnrooHZ bokQLptFtF1iemCHkGIobDbsM0y1ORVJuA4SSv+eapiXqyf9qtBtQGNCMs+pQiawDQJf QrI6R4fWjbcZrQu8aRzVITdHTKJ1itInCyXYyCJC8AAtz8XBs+YESUZs4dgq/iP0lxJ6 Jc7g== 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=FXPGpnXR1qR3btzpEEmv9NW+IgxtiuwKrOHhodEHQEI=; b=hX6iTQg+yuIRj8nOIjqq8mbEJyw4XiFcvM1J0jztayXQFnHgQGV3YswfYZGNOCPBEy or6JGRX7LMQiYg6+LxTOeS2BtbpPQpkSDtzaERhlXxmwheEOvrvNtx5BPqQtbMGdC/Gr DBxOGm6WyCW2Erh5kEBr0UCosCrkOBZA3zQzV7g7bLxsgkGkYI2fuWIE6AELKvCkslE6 tOcrD8qSk0pkyZ8JTFFkzxYttmZw+EmC11Y2gVRfUmFsfl0caeUDZJg3/G/phV+CFjdt +dvUKtHgLc7aG/H7B46tpuXresYS6GK02RpSsyTgnKbLqpe3UfTaYzBnyRFkKYYpTeMF i+gg== X-Gm-Message-State: ALoCoQnS8FSWRGQknLmF0A43GYP6n9VU053aG1+dh1+CWTAV7uFaewNTjW2QEoDUHubJbRPi4gtpRByaAg2O4SoyAxLIyflwHWbYiYhAvj+1uUe0nekTlWcZ1AKp2sYGL4kPkN9g4JHHw2L6cxqWeZYQWFW0tt54tA3zpf93yOToRzkoWgzhvtUiYHjJBrkbTTNCqTE/+Py8 X-Received: by 10.59.11.69 with SMTP id eg5mr8649177ved.17.1380826177421; Thu, 03 Oct 2013 11:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Thu, 3 Oct 2013 11:49:16 -0700 (PDT) In-Reply-To: <524DACC4.8060901@alvestrand.no> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> <524D94E0.7020801@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> <524DACC4.8060901@alvestrand.no> From: Justin Uberti Date: Thu, 3 Oct 2013 11:49:16 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7bf0dc6ccd61da04e7daa5db Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 18:59:55 -0000 --047d7bf0dc6ccd61da04e7daa5db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree with Harald, although I don't like the terms "browser"/"non-browser", since many folks (us included) are making native versions of the WebRTC APIs available, which should conform to the same rules as their web brethren. WebRTC implementations (basically, anything exposing a WebRTC API) MUST support full ICE, and MUST not support ICE Lite. WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite. On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestrand wr= ote: > On 10/03/2013 06:48 PM, Christer Holmberg wrote: > > What I think we DO need to say (eventhough someone may think it's > obvious) , in the continous consent spec, is that ICE-lite entities do no= t > send cc STUN requests. > > > Hm. If correct: What are the consequences of that? > > It seems to me that the entity sending cc STUN requests is the one asking > for permission (although I may have misremembered something). So this mea= ns > that if there are no cc STUN requests coming from the ice-lite end, the > ice-lite end is neither requesting permission to contine to send, nor is = it > going to stop sending when the WebRTC end tries to revoke permission. > > With the security guarantees we've been trying to work in here, where it'= s > safe to execute Javascript because there's a limit to how much damage you > can do with it.... I reach this conclusion: > > Entities that implement the WebRTC API, and allow others' Javascript to > access that API (for brevity's sake, let's call them "browsers", even > though W3C tends to call them "UAs") MUST NOT implement ice-lite. No matt= er > whether they have a public IP address or not; if they implement ice-lite, > they can't offer the security guarantees we want. > > Entities that don't offer an API that allows third parties to start > connections from it (for brevity, "non-browsers") have to be taken over i= n > other ways in order to perform an attack anyway, in which case all the > WebRTC guarantees are shot - so there's no harm in allowing them to > implement ice-lite. > > > > > > Regards, > > > > Christer > > > ------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Christer Holmberg [christer.holmberg@ericsson.com] > *Sent:* Thursday, 03 October 2013 7:30 PM > *To:* Matthew Kaufman; rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04 > > Hi, > > > > Do we really need to say more than the ICE RFC already says? I think it > explains when ICE-lite is appropriate, and when it isn't. > > > > Regards, > > > > Christer > > > > > ------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Matthew Kaufman [matthew@matthew.at] > *Sent:* Thursday, 03 October 2013 7:01 PM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04 > > On 10/3/2013 7:53 AM, Adam Roach wrote: > > On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo wrote: > > > >> If I implement my own WebRTC stack in a smartphone app, am I disallowe= d > to do ICE-lite in my side?? > > I would hope so, yes. The chance that your smartphone app would have an= y > hope if working if it did ice lite are as close to zero as to make no > difference. > > > > The fact that implementors apparently don't see this as an obvious fact > tells me that we need pretty strong language around this prohibition, and > "browser" is clearly too narrow a scope. > > > > > > The spec should say that: > 1. The prohibition on sending media prior to completing a STUN > connectivity test is a MUST > 2. A full ICE implementation is a SHOULD > > If I'm building a system with clients at one end and gateways with > public addresses at the other, a full ICE implementation isn't required > anywhere in order to make calls through those gateways. But keeping the > browser from being able to spew media at something that hasn't consented > *is* required. > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > 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 > > --047d7bf0dc6ccd61da04e7daa5db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with Harald, although I don't like the terms &qu= ot;browser"/"non-browser", since many folks (us included) ar= e making native versions of the WebRTC APIs available, which should conform= to the same rules as their web brethren.

WebRTC implementations (basically, anything exposing a WebRT= C API) MUST support full ICE, and MUST not support ICE Lite.
WebR= TC-compatible endpoints (e.g. gateways) MAY support ICE Lite.




On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 10/03/2013 06:48 PM, Christer Holmberg wrote:
=20 =20 =20 =20

What I think we DO need to say (eventhough someone may think it's obvious)=C2=A0,=C2=A0in the continous consent spec, is t= hat ICE-lite entities do not send=C2=A0cc=C2=A0STUN requests.


Hm. If correct: What are the consequences of that?

It seems to me that the entity sending cc STUN requests is the one asking for permission (although I may have misremembered something). So this means that if there are no cc STUN requests coming from the ice-lite end, the ice-lite end is neither requesting permission to contine to send, nor is it going to stop sending when the WebRTC end tries to revoke permission.

With the security guarantees we've been trying to work in here, where it's safe to execute Javascript because there's a limit t= o how much damage you can do with it.... I reach this conclusion:

Entities that implement the WebRTC API, and allow others' Javascrip= t to access that API (for brevity's sake, let's call them "b= rowsers", even though W3C tends to call them "UAs") MUST NOT implement ice-lite. No matter whether they have a public IP address or not; if they implement ice-lite, they can't offer the security guarantees w= e want.

Entities that don't offer an API that allows third parties to start connections from it (for brevity, "non-browsers") have to be = taken over in other ways in order to perform an attack anyway, in which case all the WebRTC guarantees are shot - so there's no harm in allowing them to implement ice-lite.



=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: rt= cweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Christer Holmberg [christer.holmberg@ericsson.com]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

Hi,

=C2=A0

Do we really need to say more than the ICE RFC already says? I think it explains when ICE-lite is appropriate, and when it isn't.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthew Kaufman [matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04
On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo <ib= c@aliax.net> wrote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disallowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have any hope if working if it did ice lite are as close to zero as to make no difference.
>
> The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browse= r" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required
anywhere in order to make calls through those gateways. But keeping the
browser from being able to spew media at something that hasn't consented
*is* required.

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


_______________________________________________
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


--047d7bf0dc6ccd61da04e7daa5db-- From harald@alvestrand.no Thu Oct 3 12:05:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F410321F9BA4 for ; Thu, 3 Oct 2013 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Stf5V0lW84Bh for ; Thu, 3 Oct 2013 12:04:51 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 651D221E805F for ; Thu, 3 Oct 2013 11:54:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0916A39E27D; Thu, 3 Oct 2013 20:54:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmMtdeWNMqCO; Thu, 3 Oct 2013 20:54:57 +0200 (CEST) Received: from [172.19.6.255] (unknown [216.239.45.95]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7813A39E222; Thu, 3 Oct 2013 20:54:56 +0200 (CEST) Message-ID: <524DBD7E.2030702@alvestrand.no> Date: Thu, 03 Oct 2013 20:54:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Magnus Westerlund References: <006401cebf96$7db7a4f0$7926eed0$@co.in>, <524C7FD8.1050801@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:05:03 -0000 I've modified my copy of the transport draft as follows: ICE TCP candidates, either using TURN [RFC6062] or not [RFC6544] MAY be supported; this may allow applications to achieve peer-to-peer communication across UDP-blocking firewalls. NOTE IN DRAFT: The profile used is RTP/SAVPF. RFC 4571 registers the profile "TCP/RTP/AVP", but there's no registration for "TCP/RTP/ SAVPF", which corresponds to the RTP/SAVPF profile recommended elsewhere in the RTCWEB specifications. RFC 6544 shows examples both with and without the TCP/ prefix. Should we suggest that in general, the prefix should not be used? If the prefix should be used, TCP/ RTP/SAVPF needs to be registered. I must admit that I don't follow the logic behind RTP profile names in SDP these days; they seem to vaccilate between transport protocol and no transport protocol. I think I prefer "no transport protocol", keeping the profile name constant across different transports, but this is probably a subject that either rtp-usage or jsep needs to tackle explicitly. Harald From juberti@google.com Thu Oct 3 12:10:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ECB21F893E for ; Thu, 3 Oct 2013 12:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec-9AHMDDDZW for ; Thu, 3 Oct 2013 12:09:56 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55621F8BFD for ; Thu, 3 Oct 2013 11:59:41 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so1759409vbf.24 for ; Thu, 03 Oct 2013 11:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VgyHIR1hZU+3SXKQ8cfclHEj5je4TMBwBy3/JZURhVM=; b=JAq9Y6KDWLHVOl5H+/jLNKJ9XJ4R8Da7yVK9/K0/LyccF0s2kPaO+UDU8x8JYToRGP /uyCi/U3/azeE+ZR5xTvJS3j4ytHep9stwMxUI6uyPBHPyIQklQebP05rYP3x5A6lZuD t0eVE4HsU0zLe4mHiLLPGG41TwipRvmAanhMro3AYH/ehl4YTuxALDvERuMbIlzHfZWa sCZArDf1TJV8LNwV/nZa7cTV7IejZwTy0wK+DOlv4Ch2G0vrV81l9YGHfEqJklrMtgJ5 5IDf7BWFAIc21NJz8ECzRa2fQ0C1GBzm9NTDN1GI9Hd+4MTFXOaIP7k4XSEsaN0MEt8q +iFg== 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=VgyHIR1hZU+3SXKQ8cfclHEj5je4TMBwBy3/JZURhVM=; b=WlFb03U8A7h9ARnWCTDPq+yweN+Py/v4/pRyZcd0+wWJWxs+gLO907z3PhkmCqMS7J Je/vp16YNAhBlF7hFKE2MezcCkKtcMwiEQs141OulIpYR4FPNA4Dyg9odzl2tD3l39MR lxHHF1HYVmnWb6bwz0N8SEsup8n9jBOr+Jkwg5AydHOCYtbKGQuO9h1hfJQ9KDjoyOJZ BpV7LeYTdmBm+PsJrbVHH/YGtPfDrn9vipOwCVPzgf1VVFiqycldk+fGKpz8TkI3gnLs 8UiWx2aHFO4aktBNSNGpHZuCnCsz8ukxilwhtvRN0XDvFNgRdDdDT78b8fwArMXDsaK0 7bGQ== X-Gm-Message-State: ALoCoQneOw1qo92tN2ETG5H7z8EhnGDTr2rQkuI0hnSGazEVlwvbWxhO89QKByFTgqdnPOWgIOIkSy8L6TnEBTCykS/xyYq5mJejd02lwgmr+D1+lgJrXTEeAayLJjI0eompF7Q1Z048qAsgcN0a8z+1RzRB3HwU4QR8F8Lpl5mlCimggStQYSjmAwTPDfTxPHGgeEM34Q1e X-Received: by 10.220.10.194 with SMTP id q2mr8622404vcq.2.1380826780775; Thu, 03 Oct 2013 11:59:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Thu, 3 Oct 2013 11:59:20 -0700 (PDT) In-Reply-To: <524a139b.e37e700a.694f.ffffae7bSMTPIN_ADDED_BROKEN@mx.google.com> References: <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> <5244104D.4010401@alvestrand.no> <524a139b.e37e700a.694f.ffffae7bSMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Thu, 3 Oct 2013 11:59:20 -0700 Message-ID: To: Karl Stahl Content-Type: multipart/alternative; boundary=001a11c3b944c3ce7704e7dac968 Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, "Cullen Jennings \(fluffy\)" Subject: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:10:04 -0000 --001a11c3b944c3ce7704e7dac968 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable WPAD already supports DNS-based discovery (in addition to DHCP). If you have host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it will try to get a PAC file from wpad.mobileonline.telia.com. Since for all practical purposes, TURN is a "UDP proxy", I think it should be handled similar to other proxy autoconfig mechanisms. On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl wrote: > I happily withdraw my suggestion to use DHCP to find a network provider > offered TURN server in favor of the DNS-Based Service Discovery method > (inserted last below). The major problem with the DHCP usage was that you > then also have to do something similar for: RA - Router Advertisement - i= n > IPv6, addition to the IPCP protocol for PPPoE and something for the mobil= e > OTT channel =E2=80=93 wherever DHCP is NOT the method to give you an IP a= ddress.** > ** > > ** ** > > Further:**** > > > On Thu, Sep 27, 2013 Justin Uberti wrote:**** > > > Agree. I still think that extending PAC files to include TURN > information is the right way to go.**** > > > PAC files can already be discovered via DHCP or DNS, there is no need t= o > reinvent this wheel.**** > > ** ** > > >>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote:**** > > >>I think we need to give some advise to the browsers vendors on what the= y > should implement to find turn servers**** > > ** ** > > I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file > can be picked up through a URL based on the device name. Similar could wo= rk > for finding a TURN server on a LAN, but what about the case with a networ= k > provider offered TURN server? The network provider hands out an IP addres= s > and wants to announce a related TURN server address: =E2=80=93 Is there a= =E2=80=9CPAC-way=E2=80=9D > to announce it to a device on a LAN (behind a NAT/firewall)? The device > must find such configuration file based on its public IP address (that he > can find using STUN as in the suggestion below).**** > > ** ** > > But generally, finding a TURN-server is a network-thing, ICE (or even TUR= N > not using ICE), not a Web-thing, so for that reason the DNS-Based Service > Discovery method is at a better level. Such method could also be used by > SIP clients (even a Skype client could implement it to benefit from a > real-time path with better quality, if the network provider offers such > path through his TURN server).**** > > ** ** > > The DNS-Based Service Discovery method should be easy to implement in a > WebRTC browser (doing complex ICE things anyway). The question is rather > how easy it is for the network provider to provision. Do they all do > reverse DNS like with found with mobile operators TeliaSonera and Tele2 i= n > Sweden? Then it should not be too difficult.**** > > ** ** > > Or is there yet another better method to announce a TURN server address > with the IP address offered?**** > > ** ** > > /Karl**** > > ** ** > > ** ** > > *Fr=C3=A5n:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *F= =C3=B6r *Bernard > Aboba > *Skickat:* den 29 september 2013 02:41 > *Till:* Harald Alvestrand > *Kopia:* rtcweb@ietf.org > > *=C3=84mne:* Re: [rtcweb] TURN server address via DHCP, WGLC of > draft-ietf-rtcweb-use-cases-and-requirements-11**** > > ** ** > > On Sep 26, 2013 8:46 PM, "Harald Alvestrand" wrote= : > > "So far, neither the POSIX standard nor any OS vendor has offered a > generic facility to access information made available in DHCP packets."**= * > * > > ** ** > > [BA] The Windows DHCP client API does provide this: **** > > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.8= 5).aspx > **** > > ** ** > > In particular, the SendParams argument to the DhcpRequestParams > function can be used to request a particular parameter (e.g. TURN server > address), which will then be returned in the RecdParams variable. **** > > ** ** > > Nevertheless, I still think that using DHCP to configure the TURN server > address in a browser isn't a good idea. For one thing, since DHCP is > effectively unsecured, this mechanism could be used by a rogue DHCP serve= r > to force traffic to a rogue turnserver. Great for surveillance!**** > > ** ** > > ** ** > > On Sep 27, 2013 1:27 AM, "Karl Stahl" wrote:**** > > Here comes the suggestion I got from my developer that would allow a > network > provider to offer his TURN server for the WebRTC browser to use. This wou= ld > require NO new DHCP-options or similar, and NO OS changes (I do realize > those should be avoided if possible...). > > The idea is still, that whoever is responsible for giving a device an IP > address (the network provider or a LAN administrator) can also announce a > TURN server for the WebRTC browser to use. > > The suggestion is to use RFC6763 (DNS-Based Service Discovery, see chapte= r > 11) where the network provider (the owner of the IP address) has set up a > DNS PTR record for the TURN server in the in-addr.arpa domain. > > If the device got IP 173.164.252.149, then make a query for the PTR recor= d > for: > _turn._udp.149.252.164.173.in-addr.arpa. > Then the SRV record would return the actual address to the TURN server (a= nd > you may find several for load balancing and failover I guess) > > If the device is on a LAN, the IP 173.164.252.149 to query would be the W= AN > IP you get via STUN in the ICE process. But if the LAN administrator > provides a local TURN server, then he also should have blocked STUN in th= e > firewall, and the browser should query the device's local host address (a= s > in the ICE procedure) and the local LAN DNS server should answer the quer= y > to give the local TURN server address on the LAN. > > Shouldn't this work to allow network provider to offer his TURN server > "automatically and generally"? > > And wouldn't this work nicely for mobile devices, whenever the device is = on > a "WebRTC-ready access" (actually good for everything using ICE), whether > fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network > provider hopefully offers a prioritized pipe there as one usage of this > mechanism). > > Not to slow down every call setup by doing this in the ICE process, I gue= ss > this could be done when starting the browser and when the device gets a n= ew > IP address, to have the TURN server address ready for later use. > > /Karl**** > > --001a11c3b944c3ce7704e7dac968 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
WPAD already supports DNS-based discovery (in addition to = DHCP). If you have=C2=A0host-95-199-196-65.mobileonline.telia.com=C2=A0as your endpoint= hostname, it will try to get a PAC file from wpad.mobileonline.telia.com.

Since for all practical purposes, TURN is a "UDP proxy&= quot;, I think it should be handled similar to other proxy autoconfig mecha= nisms.


On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl <karl.stahl@intertex.se= > wrote:

I happily withdraw my suggestion to use DHCP to find a network = provider offered TURN server in favor of the DNS-Based Service Discovery me= thod (inserted last below). The major problem with the DHCP usage was that = you then also have to do something similar for: RA - Router Advertisement -= in IPv6, addition to the IPCP protocol for PPPoE and something for the mob= ile OTT channel =E2=80=93 wherever DHCP is NOT the method to give you an IP= address.

=C2=A0

Further:

> On Thu, Sep 27, 20= 13 Justin Uberti wrote:

> Agree. I still think that extending = PAC files to include TURN information is the right way to go.=

> PAC files can already be discovered = via DHCP or DNS, there is no need to reinvent this wheel.

=C2=A0

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen J= ennings (fluffy) <fluffy@cisco.com> w= rote:

>>I think= we need to give some advise to the browsers vendors on what they should im= plement to find turn servers

=C2=A0

I Googled a bit on PAC and WPAD and saw that = a HTTP proxy config JS file can be picked up through a URL based on the dev= ice name. Similar could work for finding a TURN server on a LAN, but what a= bout the case with a network provider offered TURN server? The network prov= ider hands out an IP address and wants to announce a related TURN server ad= dress: =E2=80=93 Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a d= evice on a LAN (behind a NAT/firewall)? The device must find such configura= tion file based on its public IP address (that he can find using STUN as in= the suggestion below).

=C2=A0

But generally, finding a TURN-server is a network= -thing, ICE (or even TURN not using ICE), not a Web-thing, so for that reas= on the DNS-Based Service Discovery method is at a better level. Such method= could also be used by SIP clients (even a Skype client could implement it = to benefit from a real-time path with better quality, if the network provid= er offers such path through his TURN server).

=C2=A0

The DNS-Based Service Discovery method should be = easy to implement in a WebRTC browser (doing complex ICE things anyway). Th= e question is rather how easy it is for the network provider to provision. = Do they all do reverse DNS like with found with mobile operators TeliaSoner= a and Tele2 in Sweden? Then it should not be too difficult.

=C2=A0

Or is there yet another better method to announce= a TURN server address with the IP address offered?

=C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n: rtc= web-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Bernard Abo= ba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestra= nd
Kopia: rt= cweb@ietf.org


=C3=84mne: Re: [rt= cweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and= -requirements-11

=C2=A0

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <<= a href=3D"mailto:harald@alvestrand.no" target=3D"_blank">harald@alvestrand.= no> wrote:


"So far, neither the POSIX standard nor any= OS vendor has offered a generic facility to access information made availa= ble in DHCP packets."

=C2=A0

[BA] T= he Windows DHCP client API does provide this:=C2=A0

http://msdn.microsof= t.com/en-us/library/windows/desktop/aa363351(v=3Dvs.85).aspx<= /u>

=C2=A0

In par= ticular, the SendParams argument to the DhcpRequestParams function=C2=A0can= be used to request a particular parameter (e.g. TURN server address), whic= h will then be returned in the RecdParams variable. =C2=A0

=C2=A0

Nevert= heless, I still think that using DHCP to configure the TURN server address = in a browser isn't a good idea. =C2=A0For one thing, since DHCP is effe= ctively unsecured, this mechanism could be used by a rogue DHCP server to f= orce traffic to a rogue turnserver. =C2=A0 Great for surveillance!

=C2=A0

=C2=A0

On Sep 27, 2013 1:27 AM, "Karl Stahl" <karl.s= tahl@intertex.se> wrote:

Here comes the suggestion I got from my developer that would= allow a network
provider to offer his TURN server for the WebRTC browse= r to use. This would
require NO new DHCP-options or similar, and NO OS changes (I do realize
= those should be avoided if possible...).

The idea is still, that who= ever is responsible for giving a device an IP
address (the network provi= der or a LAN administrator) can also announce a
TURN server for the WebRTC browser to use.

The suggestion is to use = RFC6763 (DNS-Based Service Discovery, see chapter
11) where the network = provider (the owner of the IP address) has set up a
DNS PTR record for t= he TURN server in the in-addr.arpa domain.

If the device got IP 173.164.252.149, then make a query for the PTR rec= ord
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the SRV rec= ord would return the actual address to the TURN server (and
you may find= several for load balancing and failover I guess)

If the device is on a LAN, the IP 173.164.252.149 to query would be the= WAN
IP you get via STUN in the ICE process. But if the LAN administrato= r
provides a local TURN server, then he also should have blocked STUN in= the
firewall, and the browser should query the device's local host address = (as
in the ICE procedure) and the local LAN DNS server should answer the= query
to give the local TURN server address on the LAN.

Shouldn&= #39;t this work to allow network provider to offer his TURN server
"automatically and generally"?

And wouldn't this work = nicely for mobile devices, whenever the device is on
a "WebRTC-read= y access" (actually good for everything using ICE), whether
fixed, = WiFi or 3G/4G OTT, you get also a TURN server (and the network
provider hopefully offers a prioritized pipe there as one usage of this
= mechanism).

Not to slow down every cal= l setup by doing this in the ICE process, I guess
this could be done whe= n starting the browser and when the device gets a new
IP address, to have the TURN server address ready for later use.

/Karl Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:15:22 -0000 --047d7b5d9e6308d2ce04e7dad77d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 3, 2013 at 10:09 AM, Parthasarathi R wrote: > Hi Harald/Magnus,**** > > ** ** > > Thanks for the clarification. Please clarify whether TCP/RTP/SAVPF will > be registered in IANA as separate MMUSIC specification or any another > simple mechanism exists to add IANA registry. **** > > ** ** > > I=E2=80=99m interested in seeing the usage of DTLS key exchange for SRTP = within > TCP/RTP/SAVPF profile. Even though DTLS is designed for connectionless > protocol, I assume that it works with TCP (connection oriented) protocol = as > well. The optimized version of TCP/RTP/SAVPF shall use TLS as a SRTP key > exchange mechanism. Please correct me in case I=E2=80=99m missing somethi= ng. > Yes, this should work. It will use the RTP-over-TCP framing for the DTLS records (i.e. 16-bit-length prefix). I don't think if it makes sense to support TLS instead of DTLS in this case since there are no guarantees that the TCP transport will be lossless (i.e. if the TCP buffers fill, endpoints may choose to start dropping packets instead of continuing to buffer). > **** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Thursday, October 03, 2013 8:50 PM > *To:* Magnus Westerlund > *Cc:* Parthasarathi R; rtcweb@ietf.org > *Subject:* Re: SV: [rtcweb] SRTP/AVPF/TCP in > draft-ietf-rtcweb-transports-01**** > > ** ** > > On 10/03/2013 07:22 AM, Magnus Westerlund wrote:**** > > Harald, **** > > ** ** > > Yes you are missing something. The registry you pointed at are the one fo= r RTP profiles. The one containing the combinations with transport are SDP = specific. **** > > ** ** > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-p= arameters-2**** > > > Thanks! > > For consistency's sake, shouldn't all the SDP parameters that contain > "RTP" also be listed in the RTP registry? > > I'm thinking that -transport- may have to grow an IANA section that > registers TCP/RTP/SAVPF, and it needs to decide whether to register it in > one or both. > > (Of course, the TCP/ prefix is only used in some of the examples in the > RFC defining RTP over TCP - as a matter of taste, I don't like having > protocol in the profile name, so would be happy not doing so if the SDP > experts say this is OK by the rules, but then I need to adjust the langua= ge > to not use the word "profile" in this place.) > > > **** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b5d9e6308d2ce04e7dad77d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --047d7b5d9e6308d2ce04e7dad77d-- From christer.holmberg@ericsson.com Thu Oct 3 12:22:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD8221F9AB4 for ; Thu, 3 Oct 2013 12:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.043 X-Spam-Level: X-Spam-Status: No, score=-4.043 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id earZeVVHhYWM for ; Thu, 3 Oct 2013 12:22:07 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C6A4A21F9D12 for ; Thu, 3 Oct 2013 12:08:28 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-ad-524dc0ab6e65 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 84.3A.25272.BA0CD425; Thu, 3 Oct 2013 21:08:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 21:08:27 +0200 From: Christer Holmberg To: Justin Uberti , Harald Alvestrand Thread-Topic: [rtcweb] No a=ice-lite in JSEP-04 Thread-Index: Ac698bCDm/FvoM3PQXG8Sb8kVVaquv//37SAgAB0oAD/+7OiAIAIfEKAgAABegCAAAYXAIAAEvsAgAAINACAACYZFP///4TN///uqgAAAku8AAAEq8cm///+dQQ= Date: Thu, 3 Oct 2013 19:08:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B4051@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> <524D94E0.7020801@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> <524DACC4.8060901@alvestrand.no>, 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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B4051ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvre6aA75BBlO2sVsc6+tis9g6Vchi 7b92dgdmjysTrrB6LNhU6rFkyU+mAOYoLpuU1JzMstQifbsErozby6YwFewvqjjz7zhjA+P1 hC5GTg4JAROJVRt6mCBsMYkL99azdTFycQgJHGWU+LDyIQuEs5hRYte2x0BVHBxsAhYS3f+0 QRpEBIIkvv+5xQJiMwuoS9xZfI4dxBYW0JP4++oPO0SNvsS6jQfBhooIdDFKLNo0hw0kwSKg IrFv8WqwIl4BX4mPm66wQix7xiqxfdImsKmcAoESXVs/gjUwAp33/dQaJoht4hK3nsyHOltA Ysme88wQtqjEy8f/WCFsRYmr05dD1edLrHx7ghFimaDEyZlPWCYwis5CMmoWkrJZSMog4noS N6ZOYYOwtSWWLXzNDGHrSsz4dwiqxlqi42MTC7KaBYwcqxg5ilOLk3LTjQw2MQIj8OCW3xY7 GC//tTnEKM3BoiTO+/Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRqdrloXLrFLj+R6U W0iV5RXsYlu6QebqnQWZm769Wfd7SZ1xz+myQrVuT17Pmdc1w8olbpx5lPW8QeEsk5qPktyX lEvtqQ+Ulxoe1sncFaYbJH28bKt6SMkCq4NT4n9zzEnc8XlVMxPj1qRX377/nf3YxvnAj5ys K10y9qkL839ML06PfHtcQ4mlOCPRUIu5qDgRACwbESeOAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:22:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B4051ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Why does the exposure of a WebRTC API determine whether the application mus= t support full ICE or not? Shouldn't it depend on whether the application c= ode is considered "trusted" or not. For example, assume I would implement a gateway using node.js and WebRTP AP= I. The gateway platform isn't downloading the JavaScript code from a webser= ver - it is "manually" installed, which means it can be reviewed before it = is executed. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Justin= Uberti [juberti@google.com] Sent: Thursday, 03 October 2013 9:49 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04 Agree with Harald, although I don't like the terms "browser"/"non-browser",= since many folks (us included) are making native versions of the WebRTC AP= Is available, which should conform to the same rules as their web brethren. WebRTC implementations (basically, anything exposing a WebRTC API) MUST sup= port full ICE, and MUST not support ICE Lite. WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite. On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestrand > wrote: On 10/03/2013 06:48 PM, Christer Holmberg wrote: What I think we DO need to say (eventhough someone may think it's obvious) = , in the continous consent spec, is that ICE-lite entities do not send cc S= TUN requests. Hm. If correct: What are the consequences of that? It seems to me that the entity sending cc STUN requests is the one asking f= or permission (although I may have misremembered something). So this means = that if there are no cc STUN requests coming from the ice-lite end, the ice= -lite end is neither requesting permission to contine to send, nor is it go= ing to stop sending when the WebRTC end tries to revoke permission. With the security guarantees we've been trying to work in here, where it's = safe to execute Javascript because there's a limit to how much damage you c= an do with it.... I reach this conclusion: Entities that implement the WebRTC API, and allow others' Javascript to acc= ess that API (for brevity's sake, let's call them "browsers", even though W= 3C tends to call them "UAs") MUST NOT implement ice-lite. No matter whether= they have a public IP address or not; if they implement ice-lite, they can= 't offer the security guarantees we want. Entities that don't offer an API that allows third parties to start connect= ions from it (for brevity, "non-browsers") have to be taken over in other w= ays in order to perform an attack anyway, in which case all the WebRTC guar= antees are shot - so there's no harm in allowing them to implement ice-lite= . Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] on behalf of Christer Holmberg= [christer.holmberg@ericsson.com] Sent: Thursday, 03 October 2013 7:30 PM To: Matthew Kaufman; rtcweb@ietf.org Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04 Hi, Do we really need to say more than the ICE RFC already says? I think it exp= lains when ICE-lite is appropriate, and when it isn't. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounc= es@ietf.org] on behalf of Matthew Kaufman [= matthew@matthew.at] Sent: Thursday, 03 October 2013 7:01 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04 On 10/3/2013 7:53 AM, Adam Roach wrote: > On Oct 3, 2013, at 9:31, I=F1aki Baz Castillo wrote: > >> If I implement my own WebRTC stack in a smartphone app, am I disallowed = to do ICE-lite in my side?? > I would hope so, yes. The chance that your smartphone app would have any = hope if working if it did ice lite are as close to zero as to make no diffe= rence. > > The fact that implementors apparently don't see this as an obvious fact t= ells me that we need pretty strong language around this prohibition, and "b= rowser" is clearly too narrow a scope. > > The spec should say that: 1. The prohibition on sending media prior to completing a STUN connectivity test is a MUST 2. A full ICE implementation is a SHOULD If I'm building a system with clients at one end and gateways with public addresses at the other, a full ICE implementation isn't required anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consented *is* required. Matthew Kaufman _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C4B4051ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

Why does the exposure of a WebRTC API determine whether the application = must support full ICE or not? Shouldn't it depend on whether the applicatio= n code is considered "trusted" or not.

 

For example, assume I would implement a gateway using node.js and WebRTP= API. The gateway platform isn't downloading the JavaScript code from a web= server - it is "manually" installed, which means it can be r= eviewed before it is executed.

 

Regards,

 

Christer

 

 

From: rtcweb-bounces@ietf.org [rtcweb-bou= nces@ietf.org] on behalf of Justin Uberti [juberti@google.com]
Sent: Thursday, 03 October 2013 9:49 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

Agree with Harald, although I don't like the terms "b= rowser"/"non-browser", since many folks (us included) are ma= king native versions of the WebRTC APIs available, which should conform to = the same rules as their web brethren.

WebRTC implementations (basically, anything exposing a WebRTC API) MUS= T support full ICE, and MUST not support ICE Lite.
WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite.




On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestra= nd <harald@alvest= rand.no> wrote:
On 10/03/2013 06:48 PM, Christer Holmberg wrote:

What I think we DO need to say (eventhough someone may think it's obviou= s) , in the continous consent spec, is that ICE-lite entities do = not send cc STUN requests.


Hm. If correct: What are the consequences of that?

It seems to me that the entity sending cc STUN requests is the one asking f= or permission (although I may have misremembered something). So this means = that if there are no cc STUN requests coming from the ice-lite end, the ice= -lite end is neither requesting permission to contine to send, nor is it going to stop sending when the We= bRTC end tries to revoke permission.

With the security guarantees we've been trying to work in here, where it's = safe to execute Javascript because there's a limit to how much damage you c= an do with it.... I reach this conclusion:

Entities that implement the WebRTC API, and allow others' Javascript to acc= ess that API (for brevity's sake, let's call them "browsers", eve= n though W3C tends to call them "UAs") MUST NOT implement ice-lit= e. No matter whether they have a public IP address or not; if they implement ice-lite, they can't offer the security guarantees = we want.

Entities that don't offer an API that allows third parties to start connect= ions from it (for brevity, "non-browsers") have to be taken over = in other ways in order to perform an attack anyway, in which case all the W= ebRTC guarantees are shot - so there's no harm in allowing them to implement ice-lite.



 

Regards,

 

Christer

 

F= rom: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Christer Holmberg = [christ= er.holmberg@ericsson.com]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

Hi,

 

Do we really need to say more than the ICE RFC already says? I think it = explains when ICE-lite is appropriate, and when it isn't.

 

Regards,

 

Christer

 

 

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthew Kaufman [<= a href=3D"mailto:matthew@matthew.at" target=3D"_blank">matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf= .org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disal= lowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have a= ny hope if working if it did ice lite are as close to zero as to make no di= fference.
>
> The fact that implementors apparently don't see this as an obvious fac= t tells me that we need pretty strong language around this prohibition, and= "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consented *is* required.

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


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



-- =0A=
Surveillance is pervasive. Go Dark.=0A=

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


--_000_7594FB04B1934943A5C02806D1A2204B1C4B4051ESESSMB209erics_-- From martin.thomson@gmail.com Thu Oct 3 13:19:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E01221F92B2 for ; Thu, 3 Oct 2013 13:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwj1-wTCtXcT for ; Thu, 3 Oct 2013 13:19:24 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8121E8107 for ; Thu, 3 Oct 2013 13:04:33 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm2so581413wib.10 for ; Thu, 03 Oct 2013 13:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zp3VcRD7+2RHSw+F0JWnsKlN3j2eMuBiPMt+/8pZLXw=; b=K29OCCriI1MD0HWdjLLHbEwOgaxzIqkEq2hi6my6xWueY2bFqYdcpHowDJ3unbmeem T+jdUhHyHEKbzaj1Hbcz86k2UW7oGYyUk6cO3sGK+n0ceom1AEqzMwrT6w6BHh33Tq4J bMjEuz06ZS+bw4z+Q44fhPX6aDIoug/8gBt/0Di7ikAVk1wr+JiGd+UAh22kuYtkqJo7 B9gmmLfobbzCe7FB6yLAkxKNK0M6AUpNYr8uUwGgkHKBbN09RY8d8F51Sn0aMx34y2TH n35EO3gFcKHhlM4p3HTAH1U2wVbdpC8bMe4zS86wYIPJHc6DAZhL178YqLT6tyttQE3z XBtw== MIME-Version: 1.0 X-Received: by 10.194.94.137 with SMTP id dc9mr9175965wjb.38.1380830672820; Thu, 03 Oct 2013 13:04:32 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Thu, 3 Oct 2013 13:04:32 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B4051@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> <524D94E0.7020801@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> <524DACC4.8060901@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C4B4051@ESESSMB209.ericsson.se> Date: Thu, 3 Oct 2013 13:04:32 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:19:30 -0000 On 3 October 2013 12:08, Christer Holmberg wrote: > For example, assume I would implement a gateway using node.js and WebRTP > API. The gateway platform isn't downloading the JavaScript code from a > webserver - it is "manually" installed, which means it can be reviewed > before it is executed. In that case, given that node.js has a UDP API, there isn't a security reason for preventing you from sending RTP. You'd only need ICE-lite to be compatible. That said, if you want to use the WebRTC API, wouldn't you want the same code (on both sides of the API)? But that's not really the WebRTC API as specified, because the specification has to assume the browser security model. From juberti@google.com Thu Oct 3 14:03:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1B21F9433 for ; Thu, 3 Oct 2013 14:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgikDE5TAEI3 for ; Thu, 3 Oct 2013 14:03:02 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AE5A521F8C3E for ; Thu, 3 Oct 2013 13:50:12 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hz10so1285861vcb.26 for ; Thu, 03 Oct 2013 13:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ryDzjzbNaCuHMhtYCDIDbvUH1u6yNuwI8W4s4ilR+oc=; b=RSLefkGbMM4IQOZIPQxkGZe+Fj8CgwseWX9pDtU4t0lqMxV2qoz+36FzZPA236xXU/ I2J2Vrs6UKMuSkWMJxRFPH18DNAk7fFcsEbOZvC9dmRgfZBVYGO68SPWZsRKu1hx87U7 zuw9wn9WdbKWlx+GodqQt4OtqV5wa8vXg7UJBa3jATio1OLlANbFT9mb/1hrTTVt+MEa ZXhDdluLHWErDvZyr57aZivwmFDVcrzMhuS/+lhhOmABWsb92K0L0ea1BOoShNG1xNjo iA5EYFUZzH8CepUABiTnPSQ6cvKlJTxVZ6YX8gCEHn/ejQL5J1t/FMGWF96ypSbD2Lug leHg== 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=ryDzjzbNaCuHMhtYCDIDbvUH1u6yNuwI8W4s4ilR+oc=; b=PmmsgFiTgV9L0degDJKUbIpVfH/GUkP9jp/d5GHm7KD+Tyc0iTSWazk2ut/yi9hNDF cc3qhH9/UFUjsRmecDI69UnTLhNJBf4GujpaubxQtw/GVzow42B7heNEYFOexJ+IVwro huxpcXN5g7d8FN6pC7zX20Puo/4wYQo45F7AOrF7R7vfY4tgqth3uQY/l7jbt7lsA57j OvIjyLAP4oHS2gs/bwRbPGRzh+MpyCAupeKhHDfsIPUkKwP5a8tXI5T4+ZUDiEAkd9nf nYM8qzC9UWW5Ek/FOy/gKbob7W92Fnsmr95Km3FbE+ljgNwmWWVfPi8He7qKuBNDNnsk P0CQ== X-Gm-Message-State: ALoCoQnFc05HNYsqXpnQVYBVDKuywVHn4UYhJfy0hfCpgaGBiyxSm1VoLptpC5j4N/FSDIsjXmfOIFxoBYqSA6o8X7ZXb/lJppQsRHlrlke8Vvy75w3OWNEtUlv70M9NMr7HLDWi33kgVaD2YiHAJsJnA5yx1+G3PcHrfK5uPl/DRQuYva226AwgWk028vp7BPkGYt7eE3NM X-Received: by 10.58.77.65 with SMTP id q1mr9039934vew.8.1380833412049; Thu, 03 Oct 2013 13:50:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Thu, 3 Oct 2013 13:49:51 -0700 (PDT) In-Reply-To: References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> <524D94E0.7020801@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> <524DACC4.8060901@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C4B4051@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 3 Oct 2013 13:49:51 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=e89a8f6474ed05126604e7dc55a0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 21:03:09 -0000 --e89a8f6474ed05126604e7dc55a0 Content-Type: text/plain; charset=UTF-8 Agree with Martin. Also, the implications of DTLS (for example) are substantially larger than requiring full ICE. Given that full ICE is already strongly recommended by 5245, is there any non-academic reason to not mandate it for WebRTC implementations? On Thu, Oct 3, 2013 at 1:04 PM, Martin Thomson wrote: > On 3 October 2013 12:08, Christer Holmberg > wrote: > > For example, assume I would implement a gateway using node.js and WebRTP > > API. The gateway platform isn't downloading the JavaScript code from a > > webserver - it is "manually" installed, which means it can be reviewed > > before it is executed. > > In that case, given that node.js has a UDP API, there isn't a security > reason for preventing you from sending RTP. You'd only need ICE-lite > to be compatible. That said, if you want to use the WebRTC API, > wouldn't you want the same code (on both sides of the API)? > > But that's not really the WebRTC API as specified, because the > specification has to assume the browser security model. > --e89a8f6474ed05126604e7dc55a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with Martin.

Also, the impl= ications of DTLS (for example) are substantially larger than requiring full= ICE. Given that full ICE is already strongly recommended by 5245, is there= any non-academic reason to not mandate it for WebRTC implementations?


On Thu, Oct 3= , 2013 at 1:04 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 3 October 2013 12:08, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> For example, assume I would implement a gateway using node.js and WebR= TP
> API. The gateway platform isn't downloading the JavaScript code fr= om a
> webserver - it is "manually" installed, which means it can b= e reviewed
> before it is executed.

In that case, given that node.js has a UDP API, there isn't a sec= urity
reason for preventing you from sending RTP. =C2=A0You'd only need ICE-l= ite
to be compatible. =C2=A0That said, if you want to use the WebRTC API,
wouldn't you want the same code (on both sides of the API)?

But that's not really the WebRTC API as specified, because the
specification has to assume the browser security model.

--e89a8f6474ed05126604e7dc55a0-- From ibc@aliax.net Thu Oct 3 14:13:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D438521E80AD for ; Thu, 3 Oct 2013 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbwfOgP8JEm4 for ; Thu, 3 Oct 2013 14:12:53 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85021E80E0 for ; Thu, 3 Oct 2013 14:01:30 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 6so2226315qea.4 for ; Thu, 03 Oct 2013 14:01:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+PyAUVDdWoBwN1NnW5qV21o+NUaY/jIHlEFFCfOlgkA=; b=kX3xOYpSgqDPGCWLFqkwpOw2xMYM0PdY0Ca/UAy5hfxXx+92T2Ny4O3mJIMx09UPB7 /pVD1XdrS6Dvs2Q/UBUJbE1EopJ6PrHWafe0rTYe9VPngZKdJ1byV4X4NTauEBm0E2ea LMAwfxbUnDtC24UumxSc6VZ8AIu8CWFKQi1bdSJlBG7PvpUlsHu/U+IWME9ry+xN9x8A le/T/KqE78WhwFOKNCpMYZZXmnlLX87E8HoKlt+ma6fh5ZHpakVAaQP0h9sFYhy1H9gb r05I7QNl3fzJCYgnpx3gq9z2ebWwljOnbG4lF8TCET6GLkU9OhucnOxZJfA3UgysfLGG hFmA== X-Gm-Message-State: ALoCoQlCoNrkDBNzlBRTJ+5v+4G/D4Y6HaWfvJ+4oqr0AtLO9DJp7k85foosOsldaKK3c5S8v67o MIME-Version: 1.0 X-Received: by 10.49.94.172 with SMTP id dd12mr12740516qeb.4.1380834089277; Thu, 03 Oct 2013 14:01:29 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Thu, 3 Oct 2013 14:01:29 -0700 (PDT) Received: by 10.49.16.71 with HTTP; Thu, 3 Oct 2013 14:01:29 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B4051@ESESSMB209.ericsson.se> References: <56C2F665D49E0341B9DF5938005ACDF811144C@DEMUMBX005.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C4B37B8@ESESSMB209.ericsson.se> <2F515906-BEC6-4ACA-BF2B-172E6ADBDAF1@phonefromhere.com> <54B5DF36-6BEE-4FA4-ACA1-D4912F9A49AB@nostrum.com> <524D94E0.7020801@matthew.at> <7594FB04B1934943A5C02806D1A2204B1C4B3AEC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4B3C06@ESESSMB209.ericsson.se> <524DACC4.8060901@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C4B4051@ESESSMB209.ericsson.se> Date: Thu, 3 Oct 2013 23:01:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b6d8b4c63235b04e7dc7dd1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] No a=ice-lite in JSEP-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 21:13:04 -0000 --047d7b6d8b4c63235b04e7dc7dd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AFAIR JSEP is not about WebRTC API and belongs to RTCWEB IETF WG. Anyhow the only reason for disallowing ICE-lite in some endpoints is the fact that it would fail in NAT cases. OK, mandate no ICE-lite for browsers and let implementors of other WebRTC devices to decide whether they want to implement it or not (IMHO). -- I=C3=B1aki Baz Castillo El 03/10/2013 21:22, "Christer Holmberg" escribi=C3=B3: > Hi, > > > > Why does the exposure of a WebRTC API determine whether the application > must support full ICE or not? Shouldn't it depend on whether the > application code is considered "trusted" or not. > > > > For example, assume I would implement a gateway using node.js and WebRTP > API. The gateway platform isn't downloading the JavaScript code from a > webserver - it is "manually" installed, which means it can be reviewed > before it is executed. > > > > Regards, > > > > Christer > > > > > ------------------------------ > *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Justin Uberti [juberti@google.com] > *Sent:* Thursday, 03 October 2013 9:49 PM > *To:* Harald Alvestrand > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04 > > Agree with Harald, although I don't like the terms > "browser"/"non-browser", since many folks (us included) are making native > versions of the WebRTC APIs available, which should conform to the same > rules as their web brethren. > > WebRTC implementations (basically, anything exposing a WebRTC API) MUST > support full ICE, and MUST not support ICE Lite. > WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite. > > > > > On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestrand = wrote: > >> On 10/03/2013 06:48 PM, Christer Holmberg wrote: >> >> What I think we DO need to say (eventhough someone may think it's >> obvious) , in the continous consent spec, is that ICE-lite entities do n= ot >> send cc STUN requests. >> >> >> Hm. If correct: What are the consequences of that? >> >> It seems to me that the entity sending cc STUN requests is the one askin= g >> for permission (although I may have misremembered something). So this me= ans >> that if there are no cc STUN requests coming from the ice-lite end, the >> ice-lite end is neither requesting permission to contine to send, nor is= it >> going to stop sending when the WebRTC end tries to revoke permission. >> >> With the security guarantees we've been trying to work in here, where >> it's safe to execute Javascript because there's a limit to how much dama= ge >> you can do with it.... I reach this conclusion: >> >> Entities that implement the WebRTC API, and allow others' Javascript to >> access that API (for brevity's sake, let's call them "browsers", even >> though W3C tends to call them "UAs") MUST NOT implement ice-lite. No mat= ter >> whether they have a public IP address or not; if they implement ice-lite= , >> they can't offer the security guarantees we want. >> >> Entities that don't offer an API that allows third parties to start >> connections from it (for brevity, "non-browsers") have to be taken over = in >> other ways in order to perform an attack anyway, in which case all the >> WebRTC guarantees are shot - so there's no harm in allowing them to >> implement ice-lite. >> >> >> >> >> >> Regards, >> >> >> >> Christer >> >> >> ------------------------------ >> *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of >> Christer Holmberg [christer.holmberg@ericsson.com] >> *Sent:* Thursday, 03 October 2013 7:30 PM >> *To:* Matthew Kaufman; rtcweb@ietf.org >> *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04 >> >> Hi, >> >> >> >> Do we really need to say more than the ICE RFC already says? I think it >> explains when ICE-lite is appropriate, and when it isn't. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> ------------------------------ >> *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of >> Matthew Kaufman [matthew@matthew.at] >> *Sent:* Thursday, 03 October 2013 7:01 PM >> *To:* rtcweb@ietf.org >> *Subject:* Re: [rtcweb] No a=3Dice-lite in JSEP-04 >> >> On 10/3/2013 7:53 AM, Adam Roach wrote: >> > On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo wrote: >> > >> >> If I implement my own WebRTC stack in a smartphone app, am I >> disallowed to do ICE-lite in my side?? >> > I would hope so, yes. The chance that your smartphone app would have >> any hope if working if it did ice lite are as close to zero as to make n= o >> difference. >> > >> > The fact that implementors apparently don't see this as an obvious fac= t >> tells me that we need pretty strong language around this prohibition, an= d >> "browser" is clearly too narrow a scope. >> > >> > >> >> The spec should say that: >> 1. The prohibition on sending media prior to completing a STUN >> connectivity test is a MUST >> 2. A full ICE implementation is a SHOULD >> >> If I'm building a system with clients at one end and gateways with >> public addresses at the other, a full ICE implementation isn't required >> anywhere in order to make calls through those gateways. But keeping the >> browser from being able to spew media at something that hasn't consented >> *is* required. >> >> Matthew Kaufman >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> 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 >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b6d8b4c63235b04e7dc7dd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

AFAIR JSEP is not about WebRTC API and belongs to RTCWEB IET= F WG.
Anyhow the only reason for disallowing ICE-lite in some endpoints is the fa= ct that it would fail in NAT cases. OK, mandate no ICE-lite for browsers an= d let implementors of other WebRTC devices to decide whether they want to i= mplement it or not (IMHO).

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

El 03/10/2013 21:22, "Christer Holmberg&quo= t; <christer.holmberg@= ericsson.com> escribi=C3=B3:

Hi,

=C2=A0

Why does the exposure of a WebRTC API determine whether the application = must support full ICE or not? Shouldn't it depend on whether the applic= ation code is considered "trusted" or not.

=C2=A0

For example, assume I would implement a gateway using node.js and WebRTP= API. The gateway platform isn't downloading the JavaScript code from a= webserver - it is=C2=A0"manually" installed, which means it can = be reviewed before it is executed.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

Fro= m: rtcweb-= bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Justin Uberti [juberti@google.com]
Sent: Thursday, 03 October 2013 9:49 PM
To: Harald Alvestrand
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

Agree with Harald, although I don't like the terms &qu= ot;browser"/"non-browser", since many folks (us included) ar= e making native versions of the WebRTC APIs available, which should conform= to the same rules as their web brethren.

WebRTC implementations (basically, anything exposing a WebRTC API) MUS= T support full ICE, and MUST not support ICE Lite.
WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite.




On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestra= nd <harald@alvest= rand.no> wrote:
On 10/03/2013 06:48 PM, Christer Holmberg wrote:

What I think we DO need to say (eventhough someone may think it's ob= vious)=C2=A0,=C2=A0in the continous consent spec, is that ICE-lite entities= do not send=C2=A0cc=C2=A0STUN requests.


Hm. If correct: What are the consequences of that?

It seems to me that the entity sending cc STUN requests is the one asking f= or permission (although I may have misremembered something). So this means = that if there are no cc STUN requests coming from the ice-lite end, the ice= -lite end is neither requesting permission to contine to send, nor is it going to stop sending when the We= bRTC end tries to revoke permission.

With the security guarantees we've been trying to work in here, where i= t's safe to execute Javascript because there's a limit to how much = damage you can do with it.... I reach this conclusion:

Entities that implement the WebRTC API, and allow others' Javascript to= access that API (for brevity's sake, let's call them "browser= s", even though W3C tends to call them "UAs") MUST NOT imple= ment ice-lite. No matter whether they have a public IP address or not; if they implement ice-lite, they can't offer the security guarant= ees we want.

Entities that don't offer an API that allows third parties to start con= nections from it (for brevity, "non-browsers") have to be taken o= ver in other ways in order to perform an attack anyway, in which case all t= he WebRTC guarantees are shot - so there's no harm in allowing them to implement ice-lite.



=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

Fro= m: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Christer Holmberg = [christ= er.holmberg@ericsson.com]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; rtcweb@ietf.org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

Hi,

=C2=A0

Do we really need to say more than the ICE RFC already says? I think it = explains when ICE-lite is appropriate, and when it isn't.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Matthew Kaufman [<= a href=3D"mailto:matthew@matthew.at" target=3D"_blank">matthew@matthew.at]
Sent: Thursday, 03 October 2013 7:01 PM
To: rtcweb@ietf= .org
Subject: Re: [rtcweb] No a=3Dice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>
>> If I implement my own WebRTC stack in a smartphone app, am I disal= lowed to do ICE-lite in my side??
> I would hope so, yes. The chance that your smartphone app would have a= ny hope if working if it did ice lite are as close to zero as to make no di= fference.
>
> The fact that implementors apparently don't see this as an obvious= fact tells me that we need pretty strong language around this prohibition,= and "browser" is clearly too narrow a scope.
>
>

The spec should say that:
1. The prohibition on sending media prior to completing a STUN
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with
public addresses at the other, a full ICE implementation isn't required=
anywhere in order to make calls through those gateways. But keeping the browser from being able to spew media at something that hasn't consente= d
*is* required.

Matthew Kaufman
_______________________________________________
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
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

--047d7b6d8b4c63235b04e7dc7dd1-- From cb.list6@gmail.com Thu Oct 3 17:09:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150AB21E8098 for ; Thu, 3 Oct 2013 17:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1NVLNiwrREk for ; Thu, 3 Oct 2013 17:08:49 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 02C6521E809C for ; Thu, 3 Oct 2013 17:08:48 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so3764300wes.28 for ; Thu, 03 Oct 2013 17:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F4JohcF2b1qJbmbYhk88kc1jv7W6icTJYznUPoUhz9Q=; b=qmqSZKXb73JzN5Bj4DVH7uOVZ6QcImJ0ngO9n8lxKtlu0pGVpZ4CWp8H6YcIJ2yxGq Lt1mn0OxNIU1XlLNP98mMfH5fp94rdSa3abufuoxSdf8AoQ4XqOaRtvDfYmoJIPBw1EM tIvWXOHG/34qYQkOx7d5nv9KULKd++vCCMXIvDjT7cAq/EXCU5HQPg2xjKhcAau7950P sdx9vOv4Su2fKxIDgcfXBta7lT7r283FXuF5pxqPHWJsc1MujW6NN5oN7MBOuKgqJoS6 5DDCwjsg+qyevI22o/Z1+sXDqm+oE4eFq61Qu8qLnoMxWeRpzFDKMb4lBMjO/y73rVsL fh8g== MIME-Version: 1.0 X-Received: by 10.180.13.13 with SMTP id d13mr4931082wic.34.1380845327129; Thu, 03 Oct 2013 17:08:47 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Thu, 3 Oct 2013 17:08:46 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Thu, 3 Oct 2013 17:08:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Oct 2013 17:08:46 -0700 Message-ID: From: "cb.list6" To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a11c2a46236a10e04e7df1bc7 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 00:09:00 -0000 --001a11c2a46236a10e04e7df1bc7 Content-Type: text/plain; charset=ISO-8859-1 On Oct 3, 2013 7:44 AM, "Cullen Jennings (fluffy)" wrote: > > > On Sep 21, 2013, at 4:29 PM, Karl Stahl wrote: > > > I've heard several carries expressing that they want to provide their own > > TURN servers with their accesses. > > Any chance you could put me in touch with some of them. I'd love to get more information on what is needed so we can solve this. > +1. I am especially interested in the case of providing my ipv6-only access customers with dual-stack TURN capabilities CB T-Mobile US > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --001a11c2a46236a10e04e7df1bc7 Content-Type: text/html; charset=ISO-8859-1


On Oct 3, 2013 7:44 AM, "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote:
>
>
> On Sep 21, 2013, at 4:29 PM, Karl Stahl <karl.stahl@intertex.se> wrote:
>
> > I've heard several carries expressing that they want to provide their own
> > TURN servers with their accesses.
>
> Any chance you could put me in touch with some of them. I'd love to get more information on what is needed so we can solve this.
>

+1. I am especially interested in the case of providing my ipv6-only access customers with dual-stack TURN capabilities

CB
T-Mobile US

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

--001a11c2a46236a10e04e7df1bc7-- From magnus.westerlund@ericsson.com Mon Oct 7 01:20:39 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC70621E8192 for ; Mon, 7 Oct 2013 01:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3cdB2nPTj1T for ; Mon, 7 Oct 2013 01:20:31 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 153F521E8196 for ; Mon, 7 Oct 2013 01:20:25 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-b7-52526ec75732 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 93.FE.25272.7CE62525; Mon, 7 Oct 2013 10:20:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 10:20:23 +0200 Message-ID: <52526EF6.40303@ericsson.com> Date: Mon, 7 Oct 2013 10:21:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Parthasarathi R References: <006401cebf96$7db7a4f0$7926eed0$@co.in>, <524C7FD8.1050801@alvestrand.no> <524D8B2C.7050606@alvestrand.no> <005c01cec05b$4c998710$e5cc9530$@co.in> In-Reply-To: <005c01cec05b$4c998710$e5cc9530$@co.in> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre6JvKAgg+N3WCyO9XWxWUz+1Mdq sfZfO7sDs8eVCVdYPZYs+cnk8WH+F/YA5igum5TUnMyy1CJ9uwSujBVnigpO8VUsmbmbsYHx FXcXIyeHhICJxI2vS1ggbDGJC/fWs3UxcnEICRxllLi18zsrhLOMUaJ/30c2kCpeAU2J241v GEFsFgEViUsfF4LZbAIWEjd/NILViAoES7Rv/wpVLyhxcuYTsA0iAgYSv7c9ZAWxmQUcJZo+ /GYGsYUFvCSm/PzBDrHsBqPE1V07mUASnEDnnZt8mRHiPEmJbYuOsUM0G0gcWTQHapC8RPPW 2WCDhAS0JRqaOlgnMArNQrJ7FpKWWUhaFjAyr2LkKE4tTspNNzLYxAgM4YNbflvsYLz81+YQ ozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGBu2G62t33l3Jmdg0zxO++7M 9o0qn68V5T3UTT6pGvhhSYfOw7s7li+aIX5mZvT9b3IvYxh7Fv7T2aFR9OLJPJ1XwctysrtM 3yU5Ppx8/e+dLzpCPX+mSaUFFt1M3nJH+vVJ91+7brzWlW67P63omPjaiMQtnybmugqv+BDG WfBhxiTl7CeRIe+VWIozEg21mIuKEwEuMUfKLwIAAA== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 08:20:39 -0000 On 2013-10-03 19:09, Parthasarathi R wrote: > Hi Harald/Magnus, > > > > Thanks for the clarification. Please clarify whether TCP/RTP/SAVPF will > be registered in IANA as separate MMUSIC specification or any another > simple mechanism exists to add IANA registry. I think we might need a MMUSIC or AVTCORE SDP field proto cleanup document. It is not only TCP/RTP/SAVPF that is missing, also AVPF and SAVP is missing. But, before diving into this. Are there really consensus that we will use IP/TCP/RFC4571 framing/RTP(SAVPF) rather than using TURN over TCP to get a stack saying IP/TCP/TURN/RTP(SAVPF)? Their SDP identification are quite different. The later uses m= lines indicating RTP/SAVPF with the TURN part in the ICE candidates. > > > I’m interested in seeing the usage of DTLS key exchange for SRTP within > TCP/RTP/SAVPF profile. Even though DTLS is designed for connectionless > protocol, I assume that it works with TCP (connection oriented) protocol > as well. The optimized version of TCP/RTP/SAVPF shall use TLS as a SRTP > key exchange mechanism. Please correct me in case I’m missing something. In that case you definitely need an MMUSIC document. This as we need to figure out if using TLS to represent DTLS was a misstake as I think you need to separate DTLS and TLS when sent over TCP for the different purposes in that case. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Oct 7 01:37:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BDA21E819A for ; Mon, 7 Oct 2013 01:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.88 X-Spam-Level: X-Spam-Status: No, score=-104.88 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QODZoLEMaUaf for ; Mon, 7 Oct 2013 01:37:15 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 775D521E819E for ; Mon, 7 Oct 2013 01:37:14 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-d9-525272b9fcd4 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9D.3B.03802.9B272525; Mon, 7 Oct 2013 10:37:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 10:37:12 +0200 Message-ID: <525272E8.5050300@ericsson.com> Date: Mon, 7 Oct 2013 10:38:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Stahl References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> In-Reply-To: <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre7OoqAggwmvJS0235zEaPGuZy2b xdp/7ewOzB5Llvxk8vi0dT6Lx5fLn9kCmKO4bFJSczLLUov07RK4MvoPX2MuOChVMWvReaYG xk2iXYycHBICJhJ9pw+zQNhiEhfurWfrYuTiEBI4zChxdOY9JghnGaPEuqUHmEGqeAW0Jf4/ OsAKYrMIqEj8WXEdrJtNwELi5o9GNhBbVCBYon37VzaIekGJkzOfgNWICKhLTDt/CizOLBAm 8efQDrC4sEC1xP8/j5ghls1nluh9uoIdJMEp4CDx+fVZdojzJCW2LTrGDtGsJzHlagsjhC0v 0bx1NthxQkDHNTR1sE5gFJqFZPcsJC2zkLQsYGRexciem5iZk15utIkRGMIHt/xW3cF455zI IUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOvHp7C3+enoCp3xGxT9xb u2SV3jAePlufcWcve+x5lsBnS6f7aLVd/s387mqgCOe2LMbLt0o/fao4+3b+Qs2wF5cUenL8 rpVosgntW6qb8uPBumuGGimfA5dJ/3rpJmBtvnFnxr2/s7iyBQtuBPbs9GFbM3NK59GFpu5b 77JwL5fxrmyZZaumxFKckWioxVxUnAgAk7KaLS8CAAA= Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 08:37:25 -0000 Hi Karl, On 2013-10-03 00:50, Karl Stahl wrote: > Hej Magnus, > > Hmm, if we (IETF) allowed ourselves to each decennium allocate payload types > for the 3-4 most common/important codecs, the unassigned pool (PT:35-71) > would last 100 years! I think our own Opus, H.264, and maybe some mobile and > the Skype codec (SILK) could be honored AND of course the mandatory video > codec that will be selected for WebRTC (VPx or H.26y). Yes, but we already today have at least 126 media type names registered that has RTP Payload formats. Out of these a significant number do requires additional parameters, like H.264, AMR, i.e. one media type may not represent one interoperability point but many. Thus static assignment of codec plus parameters are totally out of the question. We also have various different usages and none includes all the available media types, if they would, we already now would have run out of RTP payload types. > > The need for assigning new payload types may have been small - dynamic > payload types works equally well - EXCEPT for the quality routing reason. > (RSVP quality type of networks could at least know maximum bandwidth. DPI > guesswork could/should be avoided.) So with WebRTC, expecting to finally > bring us beyond POTS quality on a massive scale - we (IETF) may > reconsider... IETF already have define an IP field for quality based routing and forwarding: The DiffServ Code Point field. If you argument is that it is difficult to agree on mapping between media types and quality to static value being used everywhere, the same applies to RTP level. You will not be able to make legacy abide any static assignments. So you will see voice in the video class etc and vice versa. > > If that really is impossible, is there anything stopping _the RTCWEB RFC_ to > recommend (MUST or SHOULD) specific _dynamic_ payload types to be used for > e.g. Opus:PT=111, H.264:PT=112, VP9:PT=113 etc.? That may be good enough, > and surely others, like SIP-client, would follow this usage (or add it to > their recommendations). What would you gain if you can't rely on the PT value being used for the defined usage. In general you will see other IP/UDP/RTP flows with PT=111 that will be H.264, or MPEG-2 or what ever. Also, are you really interested in knowing that it is VP9 vs H.264, isn't the questions this is video of this priority that is important? I think you need to more carefully consider what are the goals you try to achieve them. What layer do you want to achieve them at. Who are going to react to you information and how can one trust it across administrative boundaries. Also what scope for this information are you trying to achieve, full end to end, only first two hops? This is a difficult issue with no good solutions. A restricted problem may be possible to solve, a larger one may not be realistic. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Mon Oct 7 01:46:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60C521E819F for ; Mon, 7 Oct 2013 01:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDC1D8d6UPFG for ; Mon, 7 Oct 2013 01:46:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E386321F9E8B for ; Mon, 7 Oct 2013 01:46:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8591D39E4C6; Mon, 7 Oct 2013 10:46:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-wHVeJo7tsi; Mon, 7 Oct 2013 10:46:05 +0200 (CEST) Received: from [10.59.3.34] (unknown [212.91.240.155]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3750639E418; Mon, 7 Oct 2013 10:46:05 +0200 (CEST) Message-ID: <525274CC.7030907@alvestrand.no> Date: Mon, 07 Oct 2013 10:46:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Magnus Westerlund , Parthasarathi R References: <006401cebf96$7db7a4f0$7926eed0$@co.in>, <524C7FD8.1050801@alvestrand.no> <524D8B2C.7050606@alvestrand.no> <005c01cec05b$4c998710$e5cc9530$@co.in> <52526EF6.40303@ericsson.com> In-Reply-To: <52526EF6.40303@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 08:46:17 -0000 On 10/07/2013 10:21 AM, Magnus Westerlund wrote: > On 2013-10-03 19:09, Parthasarathi R wrote: >> Hi Harald/Magnus, >> >> >> >> Thanks for the clarification. Please clarify whether TCP/RTP/SAVPF will >> be registered in IANA as separate MMUSIC specification or any another >> simple mechanism exists to add IANA registry. > I think we might need a MMUSIC or AVTCORE SDP field proto cleanup > document. It is not only TCP/RTP/SAVPF that is missing, also AVPF and > SAVP is missing. > > But, before diving into this. Are there really consensus that we will > use IP/TCP/RFC4571 framing/RTP(SAVPF) rather than using TURN over TCP to > get a stack saying IP/TCP/TURN/RTP(SAVPF)? I have seen this thread suggesting two stacks: - TURN over TCP to a TURN server, UDP to final destination - RFC 4571 framing (I think) over TCP, all the way to the final destination The latter would be done using ICE TCP candidates according to RFC 63something. I haven't yet seen one suggesting using the TURN framing all the way to the final destination; I'm not sure I've seen a way of signalling that either. I think I've seen rough consensus that we should (SHOULD) support the former. Ihaven't seen anything stronger than a MAY support the latter, so for Transport, the only concern is that if we reference it, we reference it correctly. > > Their SDP identification are quite different. The later uses m= lines > indicating RTP/SAVPF with the TURN part in the ICE candidates. > >> >> >> I’m interested in seeing the usage of DTLS key exchange for SRTP within >> TCP/RTP/SAVPF profile. Even though DTLS is designed for connectionless >> protocol, I assume that it works with TCP (connection oriented) protocol >> as well. The optimized version of TCP/RTP/SAVPF shall use TLS as a SRTP >> key exchange mechanism. Please correct me in case I’m missing something. > In that case you definitely need an MMUSIC document. This as we need to > figure out if using TLS to represent DTLS was a misstake as I think you > need to separate DTLS and TLS when sent over TCP for the different > purposes in that case. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > -- Surveillance is pervasive. Go Dark. From karl.stahl@intertex.se Mon Oct 7 05:21:19 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354E021E81C1 for ; Mon, 7 Oct 2013 05:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVQ2XM+XA56z for ; Mon, 7 Oct 2013 05:21:13 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id E6E8E21E8190 for ; Mon, 7 Oct 2013 05:21:10 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310071421064219; Mon, 07 Oct 2013 14:21:06 +0200 From: "Karl Stahl" To: "'Saverio Vardaro'" References: <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> <52445257.8581700a.36b0.fffff687SMTPIN_ADDED_BROKEN@mx.google.com> <5245c4af.8908420a.33f6.ffff8025SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Mon, 7 Oct 2013 14:21:08 +0200 Message-ID: <044101cec357$b3b556a0$1b2003e0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0442_01CEC368.773E26A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6+v3pJAKiiLD3XSiO7/NAQdY11QAElaE9w Content-Language: sv Cc: fluffy@cisco.com, rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:21:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0442_01CEC368.773E26A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We checked some more mobile service providers in US and Japan (Softbank) = and they all did reverse DNS for the real IP address at the OTT channel. =20 US: Charter Communications, Broadband: Hostname: 66-189-44-147.dhcp.oxfr.ma.charter.com=20 US: Verizon Wireless, Wireless Broadband: Hostname: 179.sub-174-252-35.myvzw.com Japan (Softbank): ASAHI Net,Inc.: Hostname: k185241.ppp.asahi-net.or.jp Sweden (Tele2/Comviq): Hostname: m90-130-225-160.cust.tele2.se Sweden: Telia Sonera AB, Wireless Broadband: Hostname: host-95-199-20-150.mobileonline.telia.com Sweden: Tele2 SWlPnet, Tele2 Mobil, wireless Broadband: Hostname: m5-243-149-119.cust.tele2.se Sweden: Telenor Sverige AB, Wireless Broadband: Hostname: c-5eeaaa41-74736162.cust.telenor.se =20 /Karl =20 Fr=E5n: Saverio Vardaro [mailto:saverio.vardaro@gmail.com]=20 Skickat: den 1 oktober 2013 18:01 Till: Karl Stahl Kopia: cb.list6; fluffy@cisco.com; rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org =C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 =20 =20 On Fri, Sep 27, 2013 at 7:47 PM, Karl Stahl = wrote: > Does your mobile provider currently do reverse dns for your mobile's = real ip address? >CB Good question and the answer is good: Yes We just checked both major 3G mobile operators TeleaSonera and Tele2 in Sweden. E.g. just surfing to http://whatismyipaddress.com=20 (which tells me it is TeliaSonera, Wireless Broadband) Then clicking the =93Additional IP Details=94 button, I get the PTR = record: host-95-199-196-65.mobileonline.telia.com Tele2 gave: m83-186-15-99.cust.tele2.se =20 So, obviously mobile providers have ways of provisioning these kind of things in DNS. =20 How does it look in other places of the world? =20 [SV] This is NOT the case for Vodafone Italy =20 /Karl =20 =20 Fr=E5n: cb.list6 [mailto:cb.list6@gmail.com]=20 Skickat: den 27 september 2013 01:06 Till: Karl Stahl Kopia: fluffy@cisco.com; rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; Markus.Isomaki@nokia.com =C4mne: Re: SV: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On Sep 26, 2013 8:27 AM, "Karl Stahl" wrote: > > Here comes the suggestion I got from my developer that would allow a network > provider to offer his TURN server for the WebRTC browser to use. This would > require NO new DHCP-options or similar, and NO OS changes (I do = realize > those should be avoided if possible...). > > The idea is still, that whoever is responsible for giving a device an = IP > address (the network provider or a LAN administrator) can also = announce a > TURN server for the WebRTC browser to use. > > The suggestion is to use RFC6763 (DNS-Based Service Discovery, see = chapter > 11) where the network provider (the owner of the IP address) has set = up a > DNS PTR record for the TURN server in the in-addr.arpa domain. > > If the device got IP 173.164.252.149, then make a query for the PTR = record > for: > _turn._udp.149.252.164.173.in-addr.arpa. > Then the SRV record would return the actual address to the TURN server (and > you may find several for load balancing and failover I guess) > > If the device is on a LAN, the IP 173.164.252.149 to query would be = the WAN > IP you get via STUN in the ICE process. But if the LAN administrator > provides a local TURN server, then he also should have blocked STUN in = the > firewall, and the browser should query the device's local host address = (as > in the ICE procedure) and the local LAN DNS server should answer the = query > to give the local TURN server address on the LAN. > > Shouldn't this work to allow network provider to offer his TURN server > "automatically and generally"? > > And wouldn't this work nicely for mobile devices, whenever the device = is on > a "WebRTC-ready access" (actually good for everything using ICE), = whether > fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network > provider hopefully offers a prioritized pipe there as one usage of = this > mechanism). > Does your mobile provider currently do reverse dns for your mobile's = real ip address? CB > Not to slow down every call setup by doing this in the ICE process, I guess > this could be done when starting the browser and when the device gets = a new > IP address, to have the TURN server address ready for later use. > > /Karl > > > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r > Markus.Isomaki@nokia.com > Skickat: den 26 september 2013 14:06 > Till: fluffy@cisco.com; cb.list6@gmail.com > Kopia: rtcweb@ietf.org > =C4mne: Re: [rtcweb] TURN server address via DHCP, WGLC of > draft-ietf-rtcweb-use-cases-and-requirements-11 > > Hi, > > Cullen Jennings wrote: > > > > I will note that browsers have many ways to learn about HTTP proxies > > from the network and it seems to me that using some of theses same > > technique might also be a good way to learn about TURN servers. > > > > I agree. I assume that in enterprises it would be the same people = managing > both of these. > > Is there something the IETF can or should do about this, or do we just > assume it will happen? A new DHCP option is something the IETF could easily > do, but I also doubt how usable that would be. > > Markus > _______________________________________________ > 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 ------=_NextPart_000_0442_01CEC368.773E26A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable



On Thu, Oct 3, 2013 at 10:09 AM, Parthasarathi R = <partha@= parthasarathi.co.in> wrote:

Hi Harald/Magnus,<= u>

=C2=A0

Thanks for the clarificat= ion. =C2=A0Please clarify whether TCP/RTP/SAVPF will be registered in IANA as separate MMUSIC specification or any another simple mechanism exists to add IANA registry.

=C2=A0

I=E2=80=99m interested in= seeing the usage of DTLS key exchange for SRTP within TCP/RTP/SAVPF profile. Even though DTLS is designed for connectionless protocol, I assume that it works with TCP (connection orient= ed) protocol as well. The optimized version of TCP/RTP/SAVPF shall use TLS as a= SRTP key exchange mechanism. Please correct me in case I=E2=80=99m missing somet= hing.


Yes, this shou= ld work. It will use the RTP-over-TCP framing for the DTLS records (i.e. 16= -bit-length prefix). I don't think if it makes sense to support TLS ins= tead of DTLS in this case since there are no guarantees that the TCP transp= ort will be lossless (i.e. if the TCP buffers fill, endpoints may choose to= start dropping packets instead of continuing to buffer).
=C2=A0

=C2=A0

Thanks

Partha

=C2=A0

From: Harald Alvestrand [mailto:harald@al= vestrand.no]
Sent: Thursday, October 03, 2013 8:50 PM
To: Magnus Westerlund
Cc: Parthasarathi R; rtcweb@ietf.org
Subject: Re: SV: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01

=C2=A0

On 10/03/2013 07:22 AM, Magnus Westerlund wrote:<= /u>

Harald, 
=C2=A0
=
Yes you are missing something. The registry you pointed at are the one for =
RTP profiles. The one containing the combinations with transport are SDP sp=
ecific. 
=
=C2=A0
ht=
tp://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-param=
eters-2


Thanks!

For consistency's sake, shouldn't all the SDP parameters that conta= in "RTP" also be listed in the RTP registry?

I'm thinking that -transport- may have to grow an IANA section that reg= isters TCP/RTP/SAVPF, and it needs to decide whether to register it in one or both= .

(Of course, the TCP/ prefix is only used in some of the examples in the RFC defining RTP over TCP - as a matter of taste, I don't like having proto= col in the profile name, so would be happy not doing so if the SDP experts say thi= s is OK by the rules, but then I need to adjust the language to not use the word "profile" in this place.)



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


We= checked some more mobile service providers in US and Japan (Softbank) = and they all did reverse DNS for the real IP address at the OTT = channel.

 

US= : Charter Communications, Broadband: Hostname: = 66-189-44-147.dhcp.oxfr.ma.charter.com

US= : Verizon Wireless, Wireless Broadband: Hostname: = 179.sub-174-252-35.myvzw.com

Ja= pan (Softbank): ASAHI Net,Inc.: Hostname: = k185241.ppp.asahi-net.or.jp

Sw= eden (Tele2/Comviq): Ho= stname: m9= 0-130-225-160.cust.tele2.se

Sw= eden: Telia Sonera AB, Wireless Broadband: Hostname: = host-95-199-20-150.mobileonline.telia.com

Sw= eden: Tele2 SWlPnet, Tele2 Mobil, wireless Broadband: Hostname: = m5-243-149-119.cust.tele2.se

Sw= eden: Telenor Sverige AB, Wireless Broadband: Hostname: = c-5eeaaa41-74736162.cust.telenor.se

 

/K= arl

 

Fr=E5n: Saverio = Vardaro [mailto:saverio.vardaro@gmail.com]
Skickat: den 1 = oktober 2013 18:01
Till: Karl Stahl
Kopia: cb.list6; = fluffy@cisco.com; rtcweb@ietf.org; = draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
=C4mne:= Re: [rtcweb] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

 

 

On Fri, Sep 27, 2013 at 7:47 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

&g= t; Does your mobile provider currently do = reverse dns for your mobile's real ip = address?

>CB

Go= od question and the answer is good: Yes

We= just checked both major 3G mobile operators TeleaSonera and Tele2 in = Sweden.

E.= g. just surfing  to http://whatismyipaddress.com =

(w= hich tells me it is TeliaSonera, Wireless = Broadband)

Th= en clicking the “Additional IP Details” button, I get the = PTR record:

host-95-199-196-65.mobileonline.telia.com

Te= le2 gave: m83-186-15-99.cust.tele2.se

&n= bsp;

So= , obviously mobile providers have ways of provisioning these kind of = things in DNS.

&n= bsp;

Ho= w does it look in other places of the world?

&n= bsp;

[SV] = This is NOT the case for Vodafone Italy

 

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: cb.list6 = [mailto:cb.list6@gmail.com]
Skickat: den 27 = september 2013 01:06
Till: Karl Stahl
Kopia: fluffy@cisco.com; = rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf= .org; Markus.Isomaki@nokia.com
=C4mne: Re: SV: = [rtcweb] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 <= /o:p>


On Sep 26, 2013 8:27 AM, "Karl Stahl" <karl.stahl@intertex.se> wrote:
>
> = Here comes the suggestion I got from my developer that would allow a = network
> provider to offer his TURN server for the WebRTC browser = to use. This would
> require NO new DHCP-options or similar, and = NO OS changes (I do realize
> those should be avoided if = possible...).
>
> The idea is still, that whoever is = responsible for giving a device an IP
> address (the network = provider or a LAN administrator) can also announce a
> TURN server = for the WebRTC browser to use.
>
> The suggestion is to use = RFC6763 (DNS-Based Service Discovery, see chapter
> 11) where the = network provider (the owner of the IP address) has set up a
> DNS = PTR record for the TURN server in the in-addr.arpa = domain.
>
> If the device got IP 173.164.252.149, then make = a query for the PTR record
> for:
> = _turn._udp.149.252.164.173.in-addr.arpa.
> Then the SRV record = would return the actual address to the TURN server (and
> you may = find several for load balancing and failover I guess)
>
> If = the device is on a LAN, the IP 173.164.252.149 to query would be the = WAN
> IP you get via STUN in the ICE process. But if the LAN = administrator
> provides a local TURN server, then he also should = have blocked STUN in the
> firewall, and the browser should query = the device's local host address (as
> in the ICE procedure) and = the local LAN DNS server should answer the query
> to give the = local TURN server address on the LAN.
>
> Shouldn't this = work to allow network provider to offer his TURN server
> = "automatically and generally"?
>
> And wouldn't = this work nicely for mobile devices, whenever the device is on
> a = "WebRTC-ready access" (actually good for everything using = ICE), whether
> fixed, WiFi or 3G/4G OTT, you get also a TURN = server (and the network
> provider hopefully offers a prioritized = pipe there as one usage of this
> = mechanism).
>

Does your mobile provider currently = do reverse dns for your mobile's real ip = address?

CB

> Not to slow down = every call setup by doing this in the ICE process, I guess
> this = could be done when starting the browser and when the device gets a = new
> IP address, to have the TURN server address ready for later = use.
>
> /Karl
>
>
> -----Ursprungligt = meddelande-----
> Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r
> Markus.Isomaki@nokia.com
> Skickat: den 26 = september 2013 14:06
> Till: fluffy@cisco.com; cb.list6@gmail.com
> Kopia: rtcweb@ietf.org
> =C4mne: Re: [rtcweb] TURN = server address via DHCP, WGLC of
> = draft-ietf-rtcweb-use-cases-and-requirements-11
>
> = Hi,
>
> Cullen Jennings wrote:
> >
> > I = will note that browsers have many ways to learn about HTTP = proxies
> > from the network and it seems to me that using some = of theses same
> > technique might also be a good way to learn = about TURN servers.
> >
>
> I agree. I assume that = in enterprises it would be the same people managing
> both of = these.
>
> Is there something the IETF can or should do = about this, or do we just
> assume it will happen? A new DHCP = option is something the IETF could easily
> do, but I also doubt = how usable that would be.
>
> Markus
> = _______________________________________________
> 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

 

------=_NextPart_000_0442_01CEC368.773E26A0-- From karl.stahl@intertex.se Mon Oct 7 06:21:55 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5884421E8184 for ; Mon, 7 Oct 2013 06:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZrDqfrKDbBD for ; Mon, 7 Oct 2013 06:21:45 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id D138C21E8191 for ; Mon, 7 Oct 2013 06:21:41 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310071521384518; Mon, 07 Oct 2013 15:21:38 +0200 From: "Karl Stahl" To: "'Justin Uberti'" References: <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> <5244104D.4010401@alvestrand.no> <524a139b.e37e700a.694f.ffffae7bSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Mon, 7 Oct 2013 15:21:39 +0200 Message-ID: <044601cec360$28254150$786fc3f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0447_01CEC370.EBAE1150" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7Aaree2/D2RNFzRkaQmpnzrYvIdAC6kz7Q Content-Language: sv Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, "'Cullen Jennings \(fluffy\)'" Subject: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:21:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0447_01CEC370.EBAE1150 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable So the WPAD-way of getting a network provider=E2=80=99s TURN server = address for the real (white, global) IP address he has handed out to a = user, the browser would: - Use STUN to find the global IP address (done anyway in ICE) - Do a reverse DNS lookup (instead of the DNS-Based Service Discovery = that is not yet deployed) - Make a URL based on the hostname from the reverse DNS lookup, e.g. = from 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com - And there find a list (in JS) of TURN server addresses for the network = provider=E2=80=99s IP addresses Or would an alternative be to add your own IP address to the URL and = get only your specific TURN server address? =20 Doing it at this Web level, I think we also should consider clients = using ICE/TURN, but not having the luxury of a JS engine: Would e.g. a = SIP client be able to parse a =E2=80=9CJS table=E2=80=9D to find his = TURN server address easily? Also, are there long time-outs to be = considered when there is no h ttp://turned.myvzw.com to be found? =20 This method may be easier for a network provider to deploy (I = don=E2=80=99t know, but for local use on a LAN I guess it is). On the = other hand, the DNS-Based Service Discovery method is quick and easy for = a WebRTC browser, so that may be tried as well. =20 Independent of how we find the network provided TURN server, one = advantage with it is the authentication: The network provider simply = sets up the TURN for usage from the IP addresses he has handed out. =20 /Karl =20 Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 3 oktober 2013 20:59 Till: Karl Stahl Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); = draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; = rtcweb@ietf.org =C3=84mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 WPAD already supports DNS-based discovery (in addition to DHCP). If you = have = host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it = will try to get a PAC file from wpad.mobileonline.telia.com. =20 Since for all practical purposes, TURN is a "UDP proxy", I think it = should be handled similar to other proxy autoconfig mechanisms. =20 On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl = wrote: I happily withdraw my suggestion to use DHCP to find a network provider = offered TURN server in favor of the DNS-Based Service Discovery method = (inserted last below). The major problem with the DHCP usage was that = you then also have to do something similar for: RA - Router = Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and = something for the mobile OTT channel =E2=80=93 wherever DHCP is NOT the = method to give you an IP address. =20 Further: > On Thu, Sep 27, 2013 Justin Uberti wrote: > Agree. I still think that extending PAC files to include TURN = information is the right way to go. > PAC files can already be discovered via DHCP or DNS, there is no need = to reinvent this wheel. =20 >>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < = fluffy@cisco.com> wrote: >>I think we need to give some advise to the browsers vendors on what = they should implement to find turn servers =20 I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file = can be picked up through a URL based on the device name. Similar could = work for finding a TURN server on a LAN, but what about the case with a = network provider offered TURN server? The network provider hands out an = IP address and wants to announce a related TURN server address: = =E2=80=93 Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a = device on a LAN (behind a NAT/firewall)? The device must find such = configuration file based on its public IP address (that he can find = using STUN as in the suggestion below). =20 But generally, finding a TURN-server is a network-thing, ICE (or even = TURN not using ICE), not a Web-thing, so for that reason the DNS-Based = Service Discovery method is at a better level. Such method could also be = used by SIP clients (even a Skype client could implement it to benefit = from a real-time path with better quality, if the network provider = offers such path through his TURN server). =20 The DNS-Based Service Discovery method should be easy to implement in a = WebRTC browser (doing complex ICE things anyway). The question is rather = how easy it is for the network provider to provision. Do they all do = reverse DNS like with found with mobile operators TeliaSonera and Tele2 = in Sweden? Then it should not be too difficult. =20 Or is there yet another better method to announce a TURN server address = with the IP address offered? =20 /Karl =20 =20 Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] = F=C3=B6r Bernard Aboba Skickat: den 29 september 2013 02:41 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C3=84mne: Re: [rtcweb] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On Sep 26, 2013 8:46 PM, "Harald Alvestrand" = wrote: "So far, neither the POSIX standard nor any OS vendor has offered a = generic facility to access information made available in DHCP packets." =20 [BA] The Windows DHCP client API does provide this:=20 http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.8= 5).aspx =20 In particular, the SendParams argument to the DhcpRequestParams function = can be used to request a particular parameter (e.g. TURN server = address), which will then be returned in the RecdParams variable. =20 =20 Nevertheless, I still think that using DHCP to configure the TURN server = address in a browser isn't a good idea. For one thing, since DHCP is = effectively unsecured, this mechanism could be used by a rogue DHCP = server to force traffic to a rogue turnserver. Great for surveillance! =20 =20 On Sep 27, 2013 1:27 AM, "Karl Stahl" < = karl.stahl@intertex.se> wrote: Here comes the suggestion I got from my developer that would allow a = network provider to offer his TURN server for the WebRTC browser to use. This = would require NO new DHCP-options or similar, and NO OS changes (I do realize those should be avoided if possible...). The idea is still, that whoever is responsible for giving a device an IP address (the network provider or a LAN administrator) can also announce = a TURN server for the WebRTC browser to use. The suggestion is to use RFC6763 (DNS-Based Service Discovery, see = chapter 11) where the network provider (the owner of the IP address) has set up = a DNS PTR record for the TURN server in the in-addr.arpa domain. If the device got IP 173.164.252.149, then make a query for the PTR = record for: _turn._udp.149.252.164.173.in-addr.arpa. Then the SRV record would return the actual address to the TURN server = (and you may find several for load balancing and failover I guess) If the device is on a LAN, the IP 173.164.252.149 to query would be the = WAN IP you get via STUN in the ICE process. But if the LAN administrator provides a local TURN server, then he also should have blocked STUN in = the firewall, and the browser should query the device's local host address = (as in the ICE procedure) and the local LAN DNS server should answer the = query to give the local TURN server address on the LAN. Shouldn't this work to allow network provider to offer his TURN server "automatically and generally"? And wouldn't this work nicely for mobile devices, whenever the device is = on a "WebRTC-ready access" (actually good for everything using ICE), = whether fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network provider hopefully offers a prioritized pipe there as one usage of this mechanism). Not to slow down every call setup by doing this in the ICE process, I = guess this could be done when starting the browser and when the device gets a = new IP address, to have the TURN server address ready for later use. /Karl =20 ------=_NextPart_000_0447_01CEC370.EBAE1150 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

So= the WPAD-way of getting a network provider=E2=80=99s TURN server = address for the real (white, global) IP address he has handed out to a = user, the browser would:

- = Use STUN to find the global IP address (done anyway in = ICE)

- = Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that = is not yet deployed)

- = Make a URL based on the hostname from the reverse DNS lookup, e.g. from = 17= 9.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com

- = And there find a list (in JS) of TURN server addresses for the network = provider=E2=80=99s IP addresses

= =C2=A0Or would an alternative be to add your own IP address to the URL = and get only your specific TURN server address?

 

Do= ing it at this Web level, I think we also should consider clients using = ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP = client be able to parse a =E2=80=9CJS table=E2=80=9D to find his TURN = server address easily? Also, are there long time-outs to be considered = when there is no h = ttp://turned.myvzw.com to be found?

 

Th= is method may be easier for a network provider to deploy (I = don=E2=80=99t know, but for local use on a LAN I guess it is). On the = other hand, the DNS-Based Service Discovery method is quick and easy for = a WebRTC browser, so that may be tried as well.

 

In= dependent of how we find the network provided TURN server, one advantage = with it is the authentication: The network provider simply sets up the = TURN for usage from the IP addresses he has handed = out.

 

/K= arl

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com]
Skickat: den 3 oktober = 2013 20:59
Till: Karl Stahl
Kopia: Bernard Aboba; = Harald Alvestrand; Cullen Jennings (fluffy); = draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; = rtcweb@ietf.org
=C3=84mne: Re: [rtcweb] [mmusic] TURN server = address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

WPAD already supports DNS-based discovery (in addition = to DHCP). If you have host-95-199-1= 96-65.mobileonline.telia.com as your endpoint hostname, = it will try to get a PAC file from wpad.mobileonline.telia.com.

 

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

I happily = withdraw my suggestion to use DHCP to find a network provider offered = TURN server in favor of the DNS-Based Service Discovery method (inserted = last below). The major problem with the DHCP usage was that you then = also have to do something similar for: RA - Router Advertisement - in = IPv6, addition to the IPCP protocol for PPPoE and something for the = mobile OTT channel =E2=80=93 wherever DHCP is NOT the method to give you = an IP address.

 

=

Further:

> On Thu, = Sep 27, 2013 Justin Uberti wrote:

> Agree. I = still think that extending PAC files to include TURN information is the = right way to go.

> PAC files = can already be discovered via DHCP or DNS, there is no need to reinvent = this wheel.

 

=

>>On = Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> = wrote:

>>I = think we need to give some advise to the browsers vendors on what they = should implement to find turn servers

 

=

I Googled a = bit on PAC and WPAD and saw that a HTTP proxy config JS file can be = picked up through a URL based on the device name. Similar could work for = finding a TURN server on a LAN, but what about the case with a network = provider offered TURN server? The network provider hands out an IP = address and wants to announce a related TURN server address: =E2=80=93 = Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a device on a LAN = (behind a NAT/firewall)? The device must find such configuration file = based on its public IP address (that he can find using STUN as in the = suggestion below).

 

=

But generally, = finding a TURN-server is a network-thing, ICE (or even TURN not using = ICE), not a Web-thing, so for that reason the DNS-Based Service = Discovery method is at a better level. Such method could also be used by = SIP clients (even a Skype client could implement it to benefit from a = real-time path with better quality, if the network provider offers such = path through his TURN server).

 

=

The DNS-Based = Service Discovery method should be easy to implement in a WebRTC browser = (doing complex ICE things anyway). The question is rather how easy it is = for the network provider to provision. Do they all do reverse DNS like = with found with mobile operators TeliaSonera and Tele2 in Sweden? Then = it should not be too difficult.

 

=

Or is there = yet another better method to announce a TURN server address with the IP = address offered?

 

=

/Karl

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&n= bsp;

&n= bsp;

Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Bernard = Aboba
Skickat: den 29 september 2013 02:41
Till: = Harald Alvestrand
Kopia: rtcweb@ietf.org


=C3=84mne: Re: [rtcweb] TURN server address = via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 <= /o:p>

On Sep 26, 2013 8:46 PM, = "Harald Alvestrand" <harald@alvestrand.no> = wrote:


"So = far, neither the POSIX standard nor any OS vendor has offered a generic = facility to access information made available in DHCP = packets."

 

=

[BA] The Windows DHCP = client API does provide this: 

http://msdn.microsoft.com/en-us/library/windows/desktop= /aa363351(v=3Dvs.85).aspx

 

=

In particular, the = SendParams argument to the DhcpRequestParams function can be used = to request a particular parameter (e.g. TURN server address), which will = then be returned in the RecdParams variable. =  

 

=

Nevertheless, I still think = that using DHCP to configure the TURN server address in a browser isn't = a good idea.  For one thing, since DHCP is effectively unsecured, = this mechanism could be used by a rogue DHCP server to force traffic to = a rogue turnserver.   Great for = surveillance!

&n= bsp;

&n= bsp;

On Sep 27, 2013 1:27 AM, "Karl Stahl" = <karl.stahl@intertex.se> = wrote:

Here comes the suggestion I got from my = developer that would allow a network
provider to offer his TURN = server for the WebRTC browser to use. This would
require NO new = DHCP-options or similar, and NO OS changes (I do realize
those should = be avoided if possible...).

The idea is still, that whoever is = responsible for giving a device an IP
address (the network provider = or a LAN administrator) can also announce a
TURN server for the = WebRTC browser to use.

The suggestion is to use RFC6763 = (DNS-Based Service Discovery, see chapter
11) where the network = provider (the owner of the IP address) has set up a
DNS PTR record = for the TURN server in the in-addr.arpa domain.

If the device got = IP 173.164.252.149, then make a query for the PTR = record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the = SRV record would return the actual address to the TURN server = (and
you may find several for load balancing and failover I = guess)

If the device is on a LAN, the IP 173.164.252.149 to query = would be the WAN
IP you get via STUN in the ICE process. But if the = LAN administrator
provides a local TURN server, then he also should = have blocked STUN in the
firewall, and the browser should query the = device's local host address (as
in the ICE procedure) and the local = LAN DNS server should answer the query
to give the local TURN server = address on the LAN.

Shouldn't this work to allow network provider = to offer his TURN server
"automatically and = generally"?

And wouldn't this work nicely for mobile = devices, whenever the device is on
a "WebRTC-ready access" = (actually good for everything using ICE), whether
fixed, WiFi or = 3G/4G OTT, you get also a TURN server (and the network
provider = hopefully offers a prioritized pipe there as one usage of = this
mechanism).

Not to slow down every call setup by = doing this in the ICE process, I guess
this could be done when = starting the browser and when the device gets a new
IP address, to = have the TURN server address ready for later use.

/Karl

 

------=_NextPart_000_0447_01CEC370.EBAE1150-- From partha@parthasarathi.co.in Mon Oct 7 10:05:48 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4A321E81AF for ; Mon, 7 Oct 2013 10:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3VawHDmPGDL for ; Mon, 7 Oct 2013 10:05:44 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [70.87.28.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1B03821E81A6 for ; Mon, 7 Oct 2013 10:05:40 -0700 (PDT) Received: from userPC (unknown [122.179.88.43]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 84F9363970C; Mon, 7 Oct 2013 17:05:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1381165535; bh=a2zKf5NRF8+FyCL/Ma29E26HFVM371qQrYE0oTtMFFM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y6WqZ9Qf/3q9nWKpuNOz8PDIXKdBhBO2fMOeZOwTkec6lpfleRVS2QwomlG0pNk7N LCJTsMVmmPn06morHby4ayrIDcjv++kGrdxmwGAeQ6egf4Zv+JkD4ao4QmjYhc11UW pWqCjvzLwYU9tJHJXWU4GOH9Z0kxy8fyXghnvhRw= From: "Parthasarathi R" To: "'Harald Alvestrand'" , "'Magnus Westerlund'" References: <006401cebf96$7db7a4f0$7926eed0$@co.in>, <524C7FD8.1050801@alvestrand.no> <524D8B2C.7050606@alvestrand.no> <005c01cec05b$4c998710$e5cc9530$@co.in> <52526EF6.40303@ericsson.com> <525274CC.7030907@alvestrand.no> In-Reply-To: <525274CC.7030907@alvestrand.no> Date: Mon, 7 Oct 2013 22:35:29 +0530 Message-ID: <00c801cec37f$7017bd70$50473850$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7DOa3+5h31DiflQ3WLbXbOUiOaEgAPs7Jg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.5252E9DF.0058, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb-transports-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:05:48 -0000 Hi Harald/Magnus, I agree with you that we need to reference the correct transport in draft-ietf-rtcweb-transports. I noticed that RTP over TCP (http://www.ietf.org/mail-archive/web/pntaw/current/msg00041.html) discussion is going on in ptnaw mailing alias. As there is a possibility = of two different stack for RTCWeb and it is an open item, let us discuss = and conclude in ptnaw mailing alias before updating in RTCWeb transport. =20 Also I agree with Magnus that it is better to discuss in MMUSIC for SDP field proto cleanup for TCP/RTP/SAVPF, TCP/RTP/SAVP, TCP/RTP/AVPF. I'll start the mail thread in Mmusic after seeing the interest in ptnaw = mailing alias. Thanks Partha > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Monday, October 07, 2013 2:16 PM > To: Magnus Westerlund; Parthasarathi R > Cc: rtcweb@ietf.org > Subject: Re: SV: [rtcweb] SRTP/AVPF/TCP in draft-ietf-rtcweb- > transports-01 >=20 > On 10/07/2013 10:21 AM, Magnus Westerlund wrote: > > On 2013-10-03 19:09, Parthasarathi R wrote: > >> Hi Harald/Magnus, > >> > >> > >> > >> Thanks for the clarification. Please clarify whether TCP/RTP/SAVPF > will > >> be registered in IANA as separate MMUSIC specification or any > another > >> simple mechanism exists to add IANA registry. > > I think we might need a MMUSIC or AVTCORE SDP field proto cleanup > > document. It is not only TCP/RTP/SAVPF that is missing, also AVPF = and > > SAVP is missing. > > > > But, before diving into this. Are there really consensus that we = will > > use IP/TCP/RFC4571 framing/RTP(SAVPF) rather than using TURN over = TCP > to > > get a stack saying IP/TCP/TURN/RTP(SAVPF)? >=20 > I have seen this thread suggesting two stacks: >=20 > - TURN over TCP to a TURN server, UDP to final destination > - RFC 4571 framing (I think) over TCP, all the way to the final > destination >=20 > The latter would be done using ICE TCP candidates according to RFC > 63something. I haven't yet seen one suggesting using the TURN framing > all the way to the final destination; I'm not sure I've seen a way of > signalling that either. >=20 > I think I've seen rough consensus that we should (SHOULD) support the > former. Ihaven't seen anything stronger than a MAY support the latter, > so for Transport, the only concern is that if we reference it, we > reference it correctly. >=20 >=20 > > > > Their SDP identification are quite different. The later uses m=3D = lines > > indicating RTP/SAVPF with the TURN part in the ICE candidates. > > > >> > >> > >> I=92m interested in seeing the usage of DTLS key exchange for SRTP > within > >> TCP/RTP/SAVPF profile. Even though DTLS is designed for > connectionless > >> protocol, I assume that it works with TCP (connection oriented) > protocol > >> as well. The optimized version of TCP/RTP/SAVPF shall use TLS as a > SRTP > >> key exchange mechanism. Please correct me in case I=92m missing > something. > > In that case you definitely need an MMUSIC document. This as we need > to > > figure out if using TLS to represent DTLS was a misstake as I think > you > > need to separate DTLS and TLS when sent over TCP for the different > > purposes in that case. > > > > Cheers > > > > Magnus Westerlund > > > > = --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > = --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = --------------------------------------------------------------------- > - > > >=20 >=20 > -- > Surveillance is pervasive. Go Dark. From karl.stahl@intertex.se Mon Oct 7 13:16:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1B521E81A1 for ; Mon, 7 Oct 2013 13:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_20=-0.74, GB_I_INVITATION=-2, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWktJ1qpFtac for ; Mon, 7 Oct 2013 13:16:18 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3821E81BB for ; Mon, 7 Oct 2013 13:16:10 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310072216030270; Mon, 07 Oct 2013 22:16:03 +0200 From: "Karl Stahl" To: "'Dan Wing'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com> In-Reply-To: <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com> Date: Mon, 7 Oct 2013 22:16:04 +0200 Message-ID: <04c901cec39a$0d34b120$279e1360$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac64hjS54N7NaLXjT8+x9ebvqsoFnwK6TyzQ Content-Language: sv Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:16:24 -0000 Quality (below)... and it's NOT all about bandwidth Dan Wing wrote:=20 > Unfortunately the industry doesn't yet seem to agree there is even a problem. Well, that depends on which part of "the industry" we seem to be in: There seems to be more concern about quality for 3.5 kHz POTS pre = AM-radio quality voice, than for HiFi and HD video WebRTC with telepresence capability... I think forward carriers are concerned. And when putting the media over our data crowded Internet accesses (that = is the way it is/has to be with WebRTC, Skype etc.) there is certainly competition for the bandwidth. TCP type of traffic is always (intermittently) filling the pipe at the most narrow point, packets are = lost (that is the way TCP flows share the bandwidth and make the Internet = work), but both TCP and UDP packets carrying media are lost. Level 3 (or lower) = QoS mechanisms diffserve, RSVP, prioritization and traffic shaping at = congestion points (most often the CPE/Firewall/access router) helps/works - if = used! - Carriers deploying POTSoIP with voice ending up in RJ11 ports on a CPE (often part of a triple play service, delivering also data and IP-TV) = always have some sort of level 3 or below QoS, giving them loss-less voice = media transport. E.g. my ADSL+2 CPE classifies RJ11 voice, puts it on = prioritized level 2 ATM (57 byte packets!) until the DSLAM headend puts it together = to prioritized VLAN Ethernet frames and some switch puts it onto an MPLS = link, that in this case actually carries IP-packets with routable addresses. = This call may go to a 100 Mbps triple play Ethernet service where the voice = comes over a VLAN tagged Ethernet, not competing with data that is on another = VLAN (but often broken by some TDM peering point if more carriers are involved...). - Today, with higher access speeds, there is a carrier trend to use = IP-level diffserve QoS in the access (instead of level 2-2.5 separate networks), = and cable networks use RSVP for media that are shared on their Internet = pipes. That is sufficient and gives loss-less, low delay media transport. QoS mechanisms at data crowded Internet accesses are required, even for decent POTS voice. I have a good 2 Mbps upstream ADSL2+ Annex M access. Using VoIP on my LAN without any QoS mechanism - 100 kbps voice is not = even possible for the remote end to understand, when two kids are surfing and file sharing resulting in some 2000 open TCP flows on the same access. Adding prioritization and traffic shaping in the ADSL modem/firewall (built-in E-SBC which SIP proxy keeps track of SIP media and classifies = it), the voice get as perfect as when I had the pipe to myself for my call = only. When SIP Trunking PBXs (i.e. connecting them to ITSPs IP telephony = access, as we do with our Ingate and Intertex E-SBCs), there is often a separate non-Internet pipe (maybe over MPLS) or an Internet access only used for = the SIP Trunk. But when we share an Internet pipe with TCP flow intensive = data, we certainly apply QoS (prioritization and traffic shaping (staying = below the access bandwidth by holding back data traffic). That is a must for decent sound quality - even when you have plenty of bandwidth. Now with WebRTC, there is no signaling protocol to help us see what is = going on, diffserve bits cannot be set in common OS (and maybe never when = muxing different flows over a single UDP port), signaling and media is = encrypted and ICE is used for traversing NAT/firewalls without them having a clue = what is going on (which was the purpose with ICE...). How can we then = classify the real-time traffic and apply any level 3 QoS methods that can do = miracles in this harsh environment? That is why I brought up the idea of enforcing TURN at the access and classifying or routing UDP flows opened by ICE. Even if favoring UDP over TCP, using tolerant codecs, FEC, and other endpoint smart trix helps a lot, there is a limit to what can be = achieved if you have packet loss and delay. Those are the things handled with level = 3 (and below) QoS. WebRTC requires better transport than POTS voice, and bandwidth is not everything. The network must be given a chance to prioritize the traffic that needs it. (Just to clarify: I don't want us to use separate networks - Let's stay = on our Internet accesses!) =20 /Karl PS: Just browsed your links briefly and noted "(PCP [RFC6887]). ...surprising ...does not require the network operate a NAT..." The same goes for TURN also, doesn't it? -----Ursprungligt meddelande----- Fr=E5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 23 september 2013 19:57 Till: Karl Stahl Kopia: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org =C4mne: Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 On Sep 21, 2013, at 2:44 PM, Karl Stahl wrote: > Yet another thing related to > draft-ietf-rtcweb-use-cases-and-requirements-11: > It is about payload type, PT=3D, in SDP and RTP, so I am copying = MMUSIC >=20 > Network service providers have expressed an interest to know whether=20 > packets carry audio or video, to be able to handle them differently in = > the network (e.g. quality wise). PT is visible outside the encrypted=20 > payload in RTP, however if dynamic payload types PT:96-127 are used,=20 > you cannot know what the payload is without knowledge of the SDP=20 > (which we for WebRTC must assume the network provider has no knowledge of). >=20 > In http://www.ietf.org/assignments/rtp-parameters/rtp-parameters.xml I = > see no PTs defined for Opus, VP8, H.264 etc. considered for WebRTC. >=20 > So, can we have payload types assigned to codecs that will be=20 > recommended for WebRTC (PT:35-71 are unassigned)? > Or can we at least split dynamic payload types PT:96-127 into groups=20 > for audio and video codecs? >=20 >=20 > I relation to that simple request, one may wonder how the network=20 > anyway can know what is carried in an UPD packet (the RTP header is no = > reserved field - it could be the payload of something else). >=20 > Quality related requirements F38, A23 and A26 in the use case draft,=20 > nowadays only seem to relate to the browsers, not assuming that=20 > diffserve bits or similar are conveyed to the network. That is=20 > realistic, since most operating systems don't allow quality markings (diffserve, TOS) of packets. > However, 3.2.1. Simple Video Communication Service, mentions "The web = > service monitors the quality of the service (focus on quality of audio = > and > video) the end-users experience.". I don't understand how "The *web=20 > service* monitors" based on the listed requirements. Should it be "The = > *browsers* monitors"? >=20 > What are then the possibilities for a network to classify traffic for=20 > quality or other purposes? I agree there is a problem here, and have been trying to convince others there is a problem that needs to be solved. So far, there appears to be scant agreement there is a problem. See thread on TSVWG starting at http://www.ietf.org/mail-archive/web/tsvwg/current/msg12182.html. The solution I am pitching is an extension to PCP, draft-wing-pcp-flowdata. Another solution is MALICE which adds information to the ICE = connectivity checks (bandwidth, drop preference, etc.) which can be DPI'd by network devices. But before getting deep on solutions, we first we need some consensus = that some flows need different handling than other flows, and then = acquiescence that existing techniques do not solve the problem (RSVP, NSIS, = Diffserv). Unfortunately the industry doesn't yet seem to agree there is even a problem. -d >=20 > 3G/4G networks have DPIs (Deep Packet Inspection) - such box may guess = > what encrypted RTP traffic is... or may not... >=20 > Real time communication protocols using ICE as a pre-protocol to=20 > establish media paths give a possibility though. If the network=20 > provider offers a TURN server at his access, and enforces the TURN=20 > server to be used (by eating STUN packets), then the RTP flows set up=20 > through the TURN server could classify and mark packets. Then it is=20 > useful to know whether it is an audio or video packet by looking at = the payload type. >=20 > A LAN firewall, can also include a TURN-server, that in addition to=20 > classifying and marking packets for the transport network (if honored=20 > - which rarely is the case on the Internet today), it can also=20 > prioritize and traffic shape so the RTP traffic at least is=20 > undisturbed through a data crowded Internet access. >=20 > A more difficult request comes from networks using bandwidth=20 > reservation > (RSVP) for quality, like mobile and cable networks. Such networks=20 > would benefit from knowing the bandwidth used, but that is not fixed=20 > for advanced codecs like the ones considered for WebRTC. One way would = > be to reserve maximum bandwidth, and possibly repeat the reservation=20 > if less is actually used. >=20 > /Karl >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = > Karl Stahl > Skickat: den 21 september 2013 02:16 > Till: rtcweb@ietf.org; > draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org > =C4mne: [rtcweb] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 >=20 > While reading the draft-ietf-rtcweb-use-cases-and-requirements-11,=20 > here are a few "telephony related" WebRTC things I think should be=20 > clarified in the use cases. >=20 >=20 > 3.2.1. Simple Video Communication Service 3.2.1.1. Description ... =20 > The invited user might accept or reject the session.=20 > [Suggest adding] The invited user might accept only audio, rejecting=20 > video (even if a camera is enabled). A user may also select to=20 > initiate an audio session, without video. >=20 > And in API requirements: > ---------------------------------------------------------------- > A1 The Web API must provide means for the application to ask = the > browser for permission to use cameras and microphones, individually as = > input devices. (One must be able to answer with voice only - declining video.) > ---------------------------------------------------------------- > Same under > 6.2. Browser Considerations > ... > The browser is expected to provide mechanisms for users to revise and=20 > even completely revoke consent to use device resources such as camera=20 > and microphone. [Suggest adding] Specifically, a user must be given=20 > the opportunity to only accept audio in a video call invitation. >=20 >=20 >=20 > 3.2.12. Multiparty video communication 3.2.12.1. Description ... > [Suggest adding] It is essential that automatic adjustments of=20 > microphone volume is disabled, or microphones not spoken into are=20 > muted. (This is a serious problem with most soft clients (SIP clients) = > of today, plaguing conferences with ever increasing noise from silent=20 > participants.) >=20 > And in API requirements: > ---------------------------------------------------------------- > A15 The Web API must provide means for the web application to = adjust > the level in audio streams. > ---------------------------------------------------------------- > Axx The Web API must provide means to disable any automatic = volume > adjustment in the sent audio streams. (To avoid disturbing noise in=20 > conferences - making many softclients unusable). > ---------------------------------------------------------------- >=20 >=20 >=20 > 3.2.6. Simple Video Communication Service, access change 3.2.6.1. > Description ... > the user has to start a trip during the session. The communication=20 > device automatically changes to use WiFi when the Ethernet cable is=20 > removed and then moves to cellular access to the Internet when moving=20 > out of WiFi coverage. The session continues even though the access = method changes. >=20 > [Question] Is this some sort of roaming without network support=20 > (please clarify)? Getting a new access will also give the client a new = > IP address, won't it? How could then the session continue? The=20 > browsers will have no signaling connection and cannot renegotiate a = media connection, can they? >=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 juberti@google.com Mon Oct 7 23:17:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E821E8145 for ; Mon, 7 Oct 2013 23:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdkoMx7FCDt8 for ; Mon, 7 Oct 2013 23:17:26 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2F99921E813F for ; Mon, 7 Oct 2013 23:17:26 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so4318359veb.3 for ; Mon, 07 Oct 2013 23:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=we+vOkLAXpxUEQw6tKyfonM3AerdiretkXBcU5c70ZI=; b=Dz7peiQQsLZr0BX6hD1PMm9tyQcTZsq5l7N22J7KmafaTAyphYyALJfUKJy4+B1ls8 9lPmsLRa6sPwmjJny8rWU8083yTAnBED6GZ6bB1fJQJWNw8KlJi3lzd7Bkmov+5PKU2V yXcGB6467iEHGzLAuNjQEVh6IYWJO8tT9erlJv/VLJq39ouKwvsGUTFj7SRe/TWx4fcM ealaZTqPJeDLupROs9T84bzT1ek96RDdDJWMaDZT9auSWz86iaOs9BXUNSzwozzLGvgk +TWwjN107GXBRfHOshSWhPsuH0ijF254J+sK1mSlYJ2KWnr9f95M6qpmQr7IxLazRblx jzNw== 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=we+vOkLAXpxUEQw6tKyfonM3AerdiretkXBcU5c70ZI=; b=hLxZ6FTXU+XEjbP+U2Pyp9QbudJt5BTZD1qMD7+Fl4UYA9JkvmwwYEKUUJXqGDmhYc P0pf4UQAL2grqNuB1HMRG9Q9kZrqpRYR02HDQyg8HXGTuzQdbvToO5EqAEy9Yp6szOwO SARIw0W/K9OskGf9TjY2dxC8JnzR13wik8gwY4eYoKVbkftzF2RWy3HrrgMLyGlMo6+j paT/dbbc1X8KMCmm2+lpkuiKqIqd+1krzaq3JyHLR/Quue/mpIcp2JWoVmJSVXEzw1Xn fvcd8aWkZiBTftg071JQFBCfZaHU2A5r5D3k6vEyYMHBtxs6m4CneEJgU4IN+pvLukfT tN5g== X-Gm-Message-State: ALoCoQky7mmZyCVhO/nOq+s8UfYEx7yZIJMGLZEPgiveWD+p8uv73YESkGqH9RSxjMs/rWEjJLvBI7Vgt/IbeWEDEA5FYwtegI0oOMqR/kGK7sxUJHPLU10L/GDSJXVJ4B7ZEMkPhfiZ9+TFuVn09o4MuT862xYTYEpeiWEU9BotNZeugsnKdvpYL5hHz9MODeJ7U5/zh3ZL X-Received: by 10.58.245.169 with SMTP id xp9mr7709vec.60.1381213045449; Mon, 07 Oct 2013 23:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Mon, 7 Oct 2013 23:17:04 -0700 (PDT) In-Reply-To: <5252b565.2913980a.7a03.ffff8dd3SMTPIN_ADDED_BROKEN@mx.google.com> References: <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> <5244104D.4010401@alvestrand.no> <524a139b.e37e700a.694f.ffffae7bSMTPIN_ADDED_BROKEN@mx.google.com> <5252b565.2913980a.7a03.ffff8dd3SMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Mon, 7 Oct 2013 23:17:04 -0700 Message-ID: To: Karl Stahl Content-Type: multipart/alternative; boundary=047d7b873d66ef115b04e834b812 Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, "Cullen Jennings \(fluffy\)" Subject: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 06:17:28 -0000 --047d7b873d66ef115b04e834b812 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl wrote: > So the WPAD-way of getting a network provider=E2=80=99s TURN server addre= ss for > the real (white, global) IP address he has handed out to a user, the > browser would:**** > > - Use STUN to find the global IP address (done anyway in ICE) > How does this get bootstrapped? That is, how is the STUN server found? > **** > > - Do a reverse DNS lookup (instead of the DNS-Based Service Discovery tha= t > is not yet deployed)**** > > - Make a URL based on the hostname from the reverse DNS lookup, e.g. from > 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com > I was hoping we could do something simpler, such as using the ISP's configured domain search list, to determine the domain. > **** > > - And there find a list (in JS) of TURN server addresses for the network > provider=E2=80=99s IP addresses**** > > Or would an alternative be to add your own IP address to the URL and get > only your specific TURN server address?**** > > ** ** > > Doing it at this Web level, I think we also should consider clients using > ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP clie= nt > be able to parse a =E2=80=9CJS table=E2=80=9D to find his TURN server add= ress easily? Also, > are there long time-outs to be considered when there is no h ttp:// > turned.myvzw.com to be found? > **** > > ** ** > > This method may be easier for a network provider to deploy (I don=E2=80= =99t know, > but for local use on a LAN I guess it is). On the other hand, the DNS-Bas= ed > Service Discovery method is quick and easy for a WebRTC browser, so that > may be tried as well.**** > > ** ** > > Independent of how we find the network provided TURN server, one advantag= e > with it is the authentication: The network provider simply sets up the TU= RN > for usage from the IP addresses he has handed out.**** > > ** ** > > /Karl**** > > ** ** > > *Fr=C3=A5n:* Justin Uberti [mailto:juberti@google.com] > *Skickat:* den 3 oktober 2013 20:59 > *Till:* Karl Stahl > *Kopia:* Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); > draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; > rtcweb@ietf.org > *=C3=84mne:* Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of > draft-ietf-rtcweb-use-cases-and-requirements-11**** > > ** ** > > WPAD already supports DNS-based discovery (in addition to DHCP). If you > have host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, > it will try to get a PAC file from wpad.mobileonline.telia.com.**** > > ** ** > > Since for all practical purposes, TURN is a "UDP proxy", I think it shoul= d > be handled similar to other proxy autoconfig mechanisms.**** > > ** ** > > On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl > wrote:**** > > I happily withdraw my suggestion to use DHCP to find a network provider > offered TURN server in favor of the DNS-Based Service Discovery method > (inserted last below). The major problem with the DHCP usage was that you > then also have to do something similar for: RA - Router Advertisement - i= n > IPv6, addition to the IPCP protocol for PPPoE and something for the mobil= e > OTT channel =E2=80=93 wherever DHCP is NOT the method to give you an IP a= ddress.** > ** > > **** > > Further:**** > > > On Thu, Sep 27, 2013 Justin Uberti wrote:**** > > > Agree. I still think that extending PAC files to include TURN > information is the right way to go.**** > > > PAC files can already be discovered via DHCP or DNS, there is no need t= o > reinvent this wheel.**** > > **** > > >>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote:**** > > >>I think we need to give some advise to the browsers vendors on what the= y > should implement to find turn servers**** > > **** > > I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file > can be picked up through a URL based on the device name. Similar could wo= rk > for finding a TURN server on a LAN, but what about the case with a networ= k > provider offered TURN server? The network provider hands out an IP addres= s > and wants to announce a related TURN server address: =E2=80=93 Is there a= =E2=80=9CPAC-way=E2=80=9D > to announce it to a device on a LAN (behind a NAT/firewall)? The device > must find such configuration file based on its public IP address (that he > can find using STUN as in the suggestion below).**** > > **** > > But generally, finding a TURN-server is a network-thing, ICE (or even TUR= N > not using ICE), not a Web-thing, so for that reason the DNS-Based Service > Discovery method is at a better level. Such method could also be used by > SIP clients (even a Skype client could implement it to benefit from a > real-time path with better quality, if the network provider offers such > path through his TURN server).**** > > **** > > The DNS-Based Service Discovery method should be easy to implement in a > WebRTC browser (doing complex ICE things anyway). The question is rather > how easy it is for the network provider to provision. Do they all do > reverse DNS like with found with mobile operators TeliaSonera and Tele2 i= n > Sweden? Then it should not be too difficult.**** > > **** > > Or is there yet another better method to announce a TURN server address > with the IP address offered?**** > > **** > > /Karl**** > > **** > > **** > > *Fr=C3=A5n:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *F= =C3=B6r *Bernard > Aboba > *Skickat:* den 29 september 2013 02:41 > *Till:* Harald Alvestrand > *Kopia:* rtcweb@ietf.org**** > > > *=C3=84mne:* Re: [rtcweb] TURN server address via DHCP, WGLC of > draft-ietf-rtcweb-use-cases-and-requirements-11**** > > **** > > On Sep 26, 2013 8:46 PM, "Harald Alvestrand" wrote= : > **** > > > "So far, neither the POSIX standard nor any OS vendor has offered a > generic facility to access information made available in DHCP packets."**= * > * > > **** > > [BA] The Windows DHCP client API does provide this: **** > > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.8= 5).aspx > **** > > **** > > In particular, the SendParams argument to the DhcpRequestParams > function can be used to request a particular parameter (e.g. TURN server > address), which will then be returned in the RecdParams variable. **** > > **** > > Nevertheless, I still think that using DHCP to configure the TURN server > address in a browser isn't a good idea. For one thing, since DHCP is > effectively unsecured, this mechanism could be used by a rogue DHCP serve= r > to force traffic to a rogue turnserver. Great for surveillance!**** > > **** > > **** > > On Sep 27, 2013 1:27 AM, "Karl Stahl" wrote:**** > > Here comes the suggestion I got from my developer that would allow a > network > provider to offer his TURN server for the WebRTC browser to use. This wou= ld > require NO new DHCP-options or similar, and NO OS changes (I do realize > those should be avoided if possible...). > > The idea is still, that whoever is responsible for giving a device an IP > address (the network provider or a LAN administrator) can also announce a > TURN server for the WebRTC browser to use. > > The suggestion is to use RFC6763 (DNS-Based Service Discovery, see chapte= r > 11) where the network provider (the owner of the IP address) has set up a > DNS PTR record for the TURN server in the in-addr.arpa domain. > > If the device got IP 173.164.252.149, then make a query for the PTR recor= d > for: > _turn._udp.149.252.164.173.in-addr.arpa. > Then the SRV record would return the actual address to the TURN server (a= nd > you may find several for load balancing and failover I guess) > > If the device is on a LAN, the IP 173.164.252.149 to query would be the W= AN > IP you get via STUN in the ICE process. But if the LAN administrator > provides a local TURN server, then he also should have blocked STUN in th= e > firewall, and the browser should query the device's local host address (a= s > in the ICE procedure) and the local LAN DNS server should answer the quer= y > to give the local TURN server address on the LAN. > > Shouldn't this work to allow network provider to offer his TURN server > "automatically and generally"? > > And wouldn't this work nicely for mobile devices, whenever the device is = on > a "WebRTC-ready access" (actually good for everything using ICE), whether > fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network > provider hopefully offers a prioritized pipe there as one usage of this > mechanism).**** > > Not to slow down every call setup by doing this in the ICE process, I gue= ss > this could be done when starting the browser and when the device gets a n= ew > IP address, to have the TURN server address ready for later use.**** > > /Karl**** > > ** ** > --047d7b873d66ef115b04e834b812 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl <karl.stahl@intert= ex.se> wrote:

So the= WPAD-way of getting a network provider=E2=80=99s TURN server address for t= he real (white, global) IP address he has handed out to a user, the browser= would:

- Use STUN to f= ind the global IP address (done anyway in ICE)


How does this get bootstrapped? That is, how is the STU= N server found?
=C2=A0

=

= - Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that = is not yet deployed)

- Make a URL ba= sed on the hostname from the reverse DNS lookup, e.g. from 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com<= /p>


I was hoping we could do somet= hing simpler, such as using the ISP's configured domain search list, to= determine the domain.
=C2=A0

- And there find a list (in JS) of TUR= N server addresses for the network provider=E2=80=99s IP addresses

=C2=A0Or would= an alternative be to add your own IP address to the URL and get only your = specific TURN server address?

=C2=A0

Doing it at this Web level, I think we also should consider clients using = ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP client= be able to parse a =E2=80=9CJS table=E2=80=9D to find his TURN server addr= ess easily? Also, are there long time-outs to be considered when there is n= o h ttp://turned.myvzw.com to be found?

=C2=A0

This method may be easier for a network provider to deploy (I don=E2=80=99= t know, but for local use on a LAN I guess it is). On the other hand, the D= NS-Based Service Discovery method is quick and easy for a WebRTC browser, s= o that may be tried as well.

=C2=A0

Independent of how we find the network provided TURN server, one advantage= with it is the authentication: The network provider simply sets up the TUR= N for usage from the IP addresses he has handed out.

=C2=A0

/Karl

=C2=A0

Fr=C3=A5n: Jus= tin Uberti [mailto:= juberti@google.com]
Skickat: den 3 oktober 2013 20:59
Till: Karl Stahl
K= opia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.or= g; rtcweb@ietf.org=
=C3=84mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11

=

=C2=A0

WPAD already supports DNS-based discovery (in addition to DHCP). If you hav= e=C2=A0host-95-199-196-65.mobileonline.telia.com= =C2=A0as your endpoint hostname, it will try to get a PAC file from wpad.mobileonline= .telia.com.

=C2=A0

Since for all practical purposes, TURN is a "UDP proxy"= ;, I think it should be handled similar to other proxy autoconfig mechanism= s.

<= /u>=C2=A0

On Mon, Sep 30, 2013 at 5:1= 3 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

I happily withdraw my suggestio= n to use DHCP to find a network provider offered TURN server in favor of th= e DNS-Based Service Discovery method (inserted last below). The major probl= em with the DHCP usage was that you then also have to do something similar = for: RA - Router Advertisement - in IPv6, addition to the IPCP protocol for= PPPoE and something for the mobile OTT channel =E2=80=93 wherever DHCP is = NOT the method to give you an IP address.

=C2=A0

Further:

> On Thu, Sep 27, 2013 Justin Ube= rti wrote:

> A= gree. I still think that extending PAC files to include TURN information is= the right way to go.

> PAC files can already be discovered = via DHCP or DNS, there is no need to reinvent this wheel.<= /u>

=C2=A0

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen J= ennings (fluffy) <fluffy@cisco.com> w= rote:

>>I think we need to giv= e some advise to the browsers vendors on what they should implement to find= turn servers

=C2=A0

I Googled a bit on PAC and WPAD and saw that = a HTTP proxy config JS file can be picked up through a URL based on the dev= ice name. Similar could work for finding a TURN server on a LAN, but what a= bout the case with a network provider offered TURN server? The network prov= ider hands out an IP address and wants to announce a related TURN server ad= dress: =E2=80=93 Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a d= evice on a LAN (behind a NAT/firewall)? The device must find such configura= tion file based on its public IP address (that he can find using STUN as in= the suggestion below).

=C2=A0

But generally, finding a TURN-server is a network= -thing, ICE (or even TURN not using ICE), not a Web-thing, so for that reas= on the DNS-Based Service Discovery method is at a better level. Such method= could also be used by SIP clients (even a Skype client could implement it = to benefit from a real-time path with better quality, if the network provid= er offers such path through his TURN server).

=C2=A0

The DNS-Based Service Discovery method should be = easy to implement in a WebRTC browser (doing complex ICE things anyway). Th= e question is rather how easy it is for the network provider to provision. = Do they all do reverse DNS like with found with mobile operators TeliaSoner= a and Tele2 in Sweden? Then it should not be too difficult.

=C2=A0

Or is there yet another better method to announce= a TURN server address with the IP address offered?

=C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n: rtc= web-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Bernard Abo= ba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestra= nd
Kopia: rt= cweb@ietf.org


<= b>=C3=84mne: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-i= etf-rtcweb-use-cases-and-requirements-11

=C2=A0

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" <harald@alvestrand.n= o> wrote:


"So far, neither the POSIX standa= rd nor any OS vendor has offered a generic facility to access information m= ade available in DHCP packets."

=C2=A0

[BA] T= he Windows DHCP client API does provide this:=C2=A0

http://msdn.microsof= t.com/en-us/library/windows/desktop/aa363351(v=3Dvs.85).aspx<= /u>

=C2=A0

In par= ticular, the SendParams argument to the DhcpRequestParams function=C2=A0can= be used to request a particular parameter (e.g. TURN server address), whic= h will then be returned in the RecdParams variable. =C2=A0=

=C2=A0

Nevert= heless, I still think that using DHCP to configure the TURN server address = in a browser isn't a good idea. =C2=A0For one thing, since DHCP is effe= ctively unsecured, this mechanism could be used by a rogue DHCP server to f= orce traffic to a rogue turnserver. =C2=A0 Great for surveillance!

=C2=A0

=C2=A0

On Sep 27= , 2013 1:27 AM, "Karl Stahl" <karl.stahl@intertex= .se> wrote:

Here comes the suggestion I got from my developer that would allow a netwo= rk
provider to offer his TURN server for the WebRTC browser to use. This= would
require NO new DHCP-options or similar, and NO OS changes (I do realize
= those should be avoided if possible...).

The idea is still, that who= ever is responsible for giving a device an IP
address (the network provi= der or a LAN administrator) can also announce a
TURN server for the WebRTC browser to use.

The suggestion is to use = RFC6763 (DNS-Based Service Discovery, see chapter
11) where the network = provider (the owner of the IP address) has set up a
DNS PTR record for t= he TURN server in the in-addr.arpa domain.

If the device got IP 173.164.252.149, then make a query for the PTR rec= ord
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the SRV rec= ord would return the actual address to the TURN server (and
you may find= several for load balancing and failover I guess)

If the device is on a LAN, the IP 173.164.252.149 to query would be the= WAN
IP you get via STUN in the ICE process. But if the LAN administrato= r
provides a local TURN server, then he also should have blocked STUN in= the
firewall, and the browser should query the device's local host address = (as
in the ICE procedure) and the local LAN DNS server should answer the= query
to give the local TURN server address on the LAN.

Shouldn&= #39;t this work to allow network provider to offer his TURN server
"automatically and generally"?

And wouldn't this work = nicely for mobile devices, whenever the device is on
a "WebRTC-read= y access" (actually good for everything using ICE), whether
fixed, = WiFi or 3G/4G OTT, you get also a TURN server (and the network
provider hopefully offers a prioritized pipe there as one usage of this
= mechanism).

Not to slow down every call setup by doing this i= n the ICE process, I guess
this could be done when starting the browser and when the device gets a new=
IP address, to have the TURN server address ready for later use.=

/Karl

=C2=A0


--047d7b873d66ef115b04e834b812-- From karl.stahl@intertex.se Tue Oct 8 00:17:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D36021E815C for ; Tue, 8 Oct 2013 00:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmkZWsi4nQDB for ; Tue, 8 Oct 2013 00:17:05 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F421E814C for ; Tue, 8 Oct 2013 00:17:02 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310080916593032; Tue, 08 Oct 2013 09:16:59 +0200 From: "Karl Stahl" To: "'Magnus Westerlund'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> In-Reply-To: <525272E8.5050300@ericsson.com> Date: Tue, 8 Oct 2013 09:17:00 +0200 Message-ID: <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7DOGuIq7IwaT1cT3GNHbfKzjL84wAgq+9Q Content-Language: sv Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 07:17:11 -0000 Hej Magnus, > Also, are you really interested in knowing that it is VP9 vs H.264, = isn't the questions this is video of this priority that is important? > I think you need to more carefully consider what are the goals you try = to achieve them. Actually, my concern is to get an idea of the maximum bandwidth that = could be required for a WebRTC (ICE) setup media flow. Both voice and video = should be prioritized over data (their individual priority is of less = importance as long as there is sufficient bandwidth for both). With diffserv you don=92t need to know the bandwidth requirement, but = with RSVP reservation (like in cable and mobile networks) you need to know = how much to reserve. Voice is like 100's kbit/s, video VP8 or H.264 is like = 3,5 mbps.=20 To add to the complication of codec variants, the video codecs in = question for WebRTC have variable bandwidth, and when there is a poor connection = we see Chrome reducing the video window size to reduce the bandwidth = used...=20 I think the payload type field at best can reflect a maximum bandwidth = to initially reserve bandwidth for, and thereafter make new reservations if = the bandwidth changes during the call. So could we change RTP to show = maximum bandwidth instead of payload type in that field outside the encrypted payload :) ... Or maybe that is not a joke? > IETF already have define an IP field for quality based routing and forwarding: The DiffServ Code Point field. Sure, but current OS stop those bits to be set by the WebRTC browser. = And when multiplexing everything over one UDP port, I doubt we will ever see diffserv bits coming from the application. Further, diffserv bits does = not give us the bandwidth required for RSVP networks. In cable networks today, they look into the SIP/SDP signaling to see the bandwidth to reserve (usually only G.711 I believe). That cannot be done with no signaling WebRTC and all encrypted. On another track, I = suggested enforcing TURN to be used (by eating the initial STUN packet). That = could capture the ICE initiated media flow, but there is still a need to = estimate the bandwidth requirement for RSVP type of networks. /Karl -----Ursprungligt meddelande----- Fr=E5n: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Skickat: den 7 oktober 2013 10:38 Till: Karl Stahl Kopia: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org =C4mne: Payload Types assignments was Re: SV: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Hi Karl, On 2013-10-03 00:50, Karl Stahl wrote: > Hej Magnus, >=20 > Hmm, if we (IETF) allowed ourselves to each decennium allocate payload = > types for the 3-4 most common/important codecs, the unassigned pool=20 > (PT:35-71) would last 100 years! I think our own Opus, H.264, and=20 > maybe some mobile and the Skype codec (SILK) could be honored AND of=20 > course the mandatory video codec that will be selected for WebRTC (VPx = or H.26y). Yes, but we already today have at least 126 media type names registered = that has RTP Payload formats. Out of these a significant number do requires additional parameters, like H.264, AMR, i.e. one media type may not represent one interoperability point but many. Thus static assignment of codec plus parameters are totally out of the question. We also have various different usages and none includes all = the available media types, if they would, we already now would have run out = of RTP payload types. >=20 > The need for assigning new payload types may have been small - dynamic = > payload types works equally well - EXCEPT for the quality routing = reason. > (RSVP quality type of networks could at least know maximum bandwidth.=20 > DPI guesswork could/should be avoided.) So with WebRTC, expecting to=20 > finally bring us beyond POTS quality on a massive scale - we (IETF)=20 > may reconsider... IETF already have define an IP field for quality based routing and forwarding: The DiffServ Code Point field. If you argument is that it is difficult to agree on mapping between media types and quality to static value being used everywhere, the same applies to RTP level. You will not = be able to make legacy abide any static assignments. So you will see voice = in the video class etc and vice versa. >=20 > If that really is impossible, is there anything stopping _the RTCWEB=20 > RFC_ to recommend (MUST or SHOULD) specific _dynamic_ payload types to = > be used for e.g. Opus:PT=3D111, H.264:PT=3D112, VP9:PT=3D113 etc.? = That may=20 > be good enough, and surely others, like SIP-client, would follow this=20 > usage (or add it to their recommendations). What would you gain if you can't rely on the PT value being used for the defined usage. In general you will see other IP/UDP/RTP flows with PT=3D111 that will be H.264, or MPEG-2 or what ever. Also, are you really interested in knowing that it is VP9 vs H.264, = isn't the questions this is video of this priority that is important? I think you need to more carefully consider what are the goals you try = to achieve them. What layer do you want to achieve them at. Who are going = to react to you information and how can one trust it across administrative boundaries. Also what scope for this information are you trying to = achieve, full end to end, only first two hops? This is a difficult issue with no good solutions. A restricted problem = may be possible to solve, a larger one may not be realistic. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Tue Oct 8 04:01:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BFF11E81AB for ; Tue, 8 Oct 2013 04:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdJJCV7mvlHq for ; Tue, 8 Oct 2013 04:01:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 11D6D11E81AF for ; Tue, 8 Oct 2013 04:01:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8F0A39E13F for ; Tue, 8 Oct 2013 13:01:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgfrCo+jWXf3 for ; Tue, 8 Oct 2013 13:01:00 +0200 (CEST) Received: from [10.59.4.97] (unknown [212.91.240.155]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BD50939E0E1 for ; Tue, 8 Oct 2013 13:01:00 +0200 (CEST) Message-ID: <5253E5EB.8030608@alvestrand.no> Date: Tue, 08 Oct 2013 13:00:59 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> In-Reply-To: <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:01:10 -0000 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, > >> Also, are you really interested in knowing that it is VP9 vs H.264, isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you try to > achieve them. > > Actually, my concern is to get an idea of the maximum bandwidth that could > be required for a WebRTC (ICE) setup media flow. Both voice and video should > be prioritized over data (their individual priority is of less importance as > long as there is sufficient bandwidth for both). You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement and event information (data) is MORE time sensitive than the voice data. > > With diffserv you don’t need to know the bandwidth requirement, but with > RSVP reservation (like in cable and mobile networks) you need to know how > much to reserve. Voice is like 100's kbit/s, video VP8 or H.264 is like 3,5 > mbps. Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely different from a high-movement scene. > > To add to the complication of codec variants, the video codecs in question > for WebRTC have variable bandwidth, and when there is a poor connection we > see Chrome reducing the video window size to reduce the bandwidth used... > > I think the payload type field at best can reflect a maximum bandwidth to > initially reserve bandwidth for, and thereafter make new reservations if the > bandwidth changes during the call. So could we change RTP to show maximum > bandwidth instead of payload type in that field outside the encrypted > payload :) ... Or maybe that is not a joke? I think these ruminations only lead to one conclusion: You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. If you need to know the bandwidth or the priority up front, the application has to tell you. Anything else is pure heuristics. From ted.ietf@gmail.com Tue Oct 8 08:42:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A659F21E81C6 for ; Tue, 8 Oct 2013 08:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY+huvy8qpET for ; Tue, 8 Oct 2013 08:42:12 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3916A21E818D for ; Tue, 8 Oct 2013 08:42:12 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so20451635ieb.9 for ; Tue, 08 Oct 2013 08:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fwbMHMHNL3cNT1FVFOGjeKmWUQzHeoyHCJvoc9x8umk=; b=1EHmLhIbMvSJ8UKvOmlmGvKHeBdT+pyH6KPalgd1971AJo7p8BwgwHgXrcY8agwOUM pv+RS7vrLfsHek9dzTjcl/68jFNQ9lNIFyDTBBiwvY+JSVeUEF/Pb66YHDhk6MlgxLEv LG6cc0c5APwgcWlrg1uN0HuvGD/ICn89jOfRRZZmQA0ESbvWGiXjIVU0Kg+XH3BncQEM vodpujulO+6yhI2JupiSYDRzmi+cNHmQOjVSiX0mfX8VGSr2CXjr5uOT1zka4h0GlZ0I VcFI01YEps35FWSyNQlkjk28zgiNDXrr/034gx439PP0t3KF4NorbOrHnmxHGeXqOJxk NL3w== MIME-Version: 1.0 X-Received: by 10.50.119.70 with SMTP id ks6mr1850265igb.22.1381246931606; Tue, 08 Oct 2013 08:42:11 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Tue, 8 Oct 2013 08:42:11 -0700 (PDT) Date: Tue, 8 Oct 2013 08:42:11 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0111d9b8b4aa5204e83c9cc0 Subject: [rtcweb] Updated drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 15:42:12 -0000 --089e0111d9b8b4aa5204e83c9cc0 Content-Type: text/plain; charset=ISO-8859-1 There have been updated drafts for both H.264 ( http://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/) and VP8 (http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/). There were no other submissions for consideration. As noted before, now is the time for folks to dig into these drafts, raising issues and checking the work. Please kick that off as soon as possible. thanks, Ted Hardie --089e0111d9b8b4aa5204e83c9cc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There have been updated drafts for both H.264 (ht= tp://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/)=A0 an= d VP8 (http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/).=A0 = There were no other submissions for consideration.=A0 As noted before, now = is the time for folks to dig into these drafts, raising issues and checking= the work.=A0 Please kick that off as soon as possible.

thanks,

Ted Hardie



--089e0111d9b8b4aa5204e83c9cc0-- From BeckW@telekom.de Thu Oct 10 08:03:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5355621E812F for ; Thu, 10 Oct 2013 08:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlndXjMh0koL for ; Thu, 10 Oct 2013 08:03:01 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC2221E812D for ; Thu, 10 Oct 2013 08:02:49 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 10 Oct 2013 17:02:20 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.164]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 10 Oct 2013 17:02:20 +0200 From: To: , Date: Thu, 10 Oct 2013 17:02:19 +0200 Thread-Topic: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: Ac7EFbG2DmgtDqolRyWywR/JKvL2ZgBsFMBg Message-ID: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> In-Reply-To: <5253E5EB.8030608@alvestrand.no> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:03:06 -0000 The basic question seems to be: how can the web server or JS client learn a= bout local policy enforcement elements in the user's network and access the= m to allocate bandwidth, setup priorisation etc? The ALTO WG had a very similar problem and proposed DHCP after DNS experts = dismissed a discovery mechanism based on reverse DNS lookups. The classical solution: avoid the problem by having a webrtc server in your= local network which does policy enforcement/QoS priorisation etc, and inte= rconnects to some other webrtc server with a standardized protocol like SIP= or XMPP. Popular in RTCWEB, less popular elsewhere.. The DHCP way: let the browser learn about the policy enforcement elements t= hrough DHCP, it may communicate them to the server. This has some problems.= There are no widely adopted DHCP APIs, and the policy enforcement elements= may be unwilling to let some random web server access them. DNS magic: derive the address of your local policy enforcement element by m= anipulating the result of a reverse DNS lookup of the global IP address.=20 Manual configuration: Solves only the problem of missing DHCP APIs and intr= oduces the usability nightmare we know too well from SIP clients.=20 3rd party auth: the user authenticates with a local idP, which not only car= ries the user's name but also the local policy enforcement urls as attribut= es. A web server can use the 3rd party auth token to access the local netwo= rk elements. Haven't thought this through yet.=20 Wolfgang Beck -----Urspr=FCngliche Nachricht----- Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag vo= n Harald Alvestrand Gesendet: Dienstag, 8. Oktober 2013 13:01 An: rtcweb@ietf.org Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC o= f draft-ietf-rtcweb-use-cases-and-requirements-11 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, > >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. > > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of=20 > less importance as long as there is sufficient bandwidth for both). You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement and = event information (data) is MORE time sensitive than the voice data. > > With diffserv you don't need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth variation= of screencast (semi-static with sudden, large changes) is completely diffe= rent from that of a talking head, which is again completely different from = a high-movement scene. > > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the ban= dwidth used... > > I think the payload type field at best can reflect a maximum bandwidth=20 > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a joke? I think these ruminations only lead to one conclusion: You can't tell what the needed bandwidth is up front without asking the app= lication. You can't tell what the right priority ranking is without asking the applic= ation. If you need to know the bandwidth or the priority up front, the application= has to tell you. Anything else is pure heuristics. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Thu Oct 10 08:50:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A04311E8199 for ; Thu, 10 Oct 2013 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-jE7WFyDDh9 for ; Thu, 10 Oct 2013 08:50:28 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 18ABD21E805D for ; Thu, 10 Oct 2013 08:50:25 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6FC2722E2C9; Thu, 10 Oct 2013 11:50:06 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Oct 2013 09:50:04 -0600 Message-Id: <055EA81A-C60B-4FA3-B080-F41CDB6E573F@iii.ca> To: "rtcweb@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [rtcweb] Draft RTCWeb Agenda for IETF 88 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:50:37 -0000 Draft Agenda Version #1 - Oct 10 Monday 14:50 to 17:20 Chair / Agenda bash (10 min) JSEP (50 min) Data channel document (40 min) Security Documents (20 min) - deal with any WGLC issues RTP Usages (30 min) - mapping to API considerations - simulcast - any need for priority mappings - other open issues (If requirement / uses cases needs time, will try to add) Thursday 13:00 to 15:00 Frame discussions and process and agenda: 10 min (chairs) VP8 presentation with clarify questions - 25 min (???) H.264 presentation with clarify questions - 25 min (???) Microphone discussions of pro/cons - 40 min (all) Call the question - 10 min ( chairs ) Wrap up and next steps - 10 min (chairs) Celebrate on our successful decision reach. From christer.holmberg@ericsson.com Thu Oct 10 09:08:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E93E11E8186 for ; Thu, 10 Oct 2013 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEnV7AXzbgvc for ; Thu, 10 Oct 2013 09:08:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC2B11E8199 for ; Thu, 10 Oct 2013 09:07:54 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-a2-5256d0d967b7 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A9.AB.03802.AD0D6525; Thu, 10 Oct 2013 18:07:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 10 Oct 2013 18:07:53 +0200 From: Christer Holmberg To: Cullen Jennings , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Draft RTCWeb Agenda for IETF 88 Thread-Index: AQHOxdB/opv/bigLk02r0coWdNltWJnuGeVg Date: Thu, 10 Oct 2013 16:07:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BA766@ESESSMB209.ericsson.se> References: <055EA81A-C60B-4FA3-B080-F41CDB6E573F@iii.ca> In-Reply-To: <055EA81A-C60B-4FA3-B080-F41CDB6E573F@iii.ca> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre6tC2FBBsc7BCw+rP/BaLH2Xzu7 A5PHkiU/mTwun//IGMAUxWWTkpqTWZZapG+XwJUxZ/dspoI1XBWPbv1maWBcytHFyMEhIWAi 0XA1qouRE8gUk7hwbz1bFyMXh5DAYUaJeQt/MkI4Sxglzv1/ygTSwCZgIdH9TxukQUTAQ+LQ z0/sIDazgK9E37vnTCC2sICpxL5jB5kgaswkNjd/YIGwjSS6G84yg9gsAqoSt27fYAOxeYF6 b2x+AVYvJGAp8XB6E5jNKWAlcXNROyuIzQh03PdTa5ggdolLfDh4nRniaAGJJXvOQ9miEi8f /2OFsJUk1h7ezgJRrydxY+oUNghbW2LZwtfMEHsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJG llWM7LmJmTnp5UabGIERcnDLb9UdjHfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY83Wd6tmRJgdET4bcHp/FsPHo9wZbn283ooLW+d7Pf5syDDv2bldvmVrNusX X+9MuNhfuKubMa55/5r7W6bWrig+XLRs8sJJtjy/97/8PNvkEP+8Q+dZRJduKVme4F5dsqPi vjqLyrnbZ9TbZnXGi7FXpuwLX2aaKMBhuGZL6Z8L1aX/n2rblSuxFGckGmoxFxUnAgBvnR/P XgIAAA== Subject: Re: [rtcweb] Draft RTCWeb Agenda for IETF 88 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:08:07 -0000 Hi Cullen, We do not intend to request agenda time for the requirements/use-cases. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P= uolesta Cullen Jennings L=E4hetetty: 10. lokakuuta 2013 18:50 Vastaanottaja: rtcweb@ietf.org Aihe: [rtcweb] Draft RTCWeb Agenda for IETF 88 Draft Agenda Version #1 - Oct 10=20 Monday 14:50 to 17:20=20 Chair / Agenda bash (10 min) JSEP (50 min) Data channel document (40 min)=20 Security Documents (20 min) - deal with any WGLC issues=20 RTP Usages (30 min)=20 - mapping to API considerations - simulcast - any need for priority mappings=20 - other open issues (If requirement / uses cases needs time, will try to add)=20 Thursday 13:00 to 15:00 =20 Frame discussions and process and agenda: 10 min (chairs) VP8 presentation with clarify questions - 25 min (???) H.264 presentation with clarify questions - 25 min (???) Microphone discussions of pro/cons - 40 min (all) Call the question - 10 min ( chairs )=20 Wrap up and next steps - 10 min (chairs) Celebrate on our successful decision reach.=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Thu Oct 10 09:30:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1C21E8117 for ; Thu, 10 Oct 2013 09:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7dGAZJMk3j1 for ; Thu, 10 Oct 2013 09:30:53 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C5E0F21E8090 for ; Thu, 10 Oct 2013 09:30:53 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id x13so5735925ief.17 for ; Thu, 10 Oct 2013 09:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1aQiclDb7yKo3n5WxJD4uZL1hDIMZVfrBNC7+wUSsDo=; b=l9z5KEvfnIiej3/0QLqOlnF0sOcHfC+1cH1MmGCaJ3zhPBeTwFQchf99PUqaDt+Y6B aOIO5jlHzcyAsFNNuhYvthjTofxo7mRhT+k+Kmz7Ycrk0njxB3LytPmgaTo4DvZUoCwr //kGTSjzEwmL6US4FVLDS2kePs7rgDeiZy/TXtFPv2qNIqxgQpLw6FBL7vwgmh/c4Jha VcHWKcyH+kL7S9kCoPasB55ctUyCtV7VSFfjfRobz5BGsDohYccAUdXqoGElr0TlMXZN 9s3zuI+emhX9ptL9iwFZxJXpT18/HdkshEXY+NDUL40VgU+STiWFE7wgQKR3LnQXtkoa 0Wyg== MIME-Version: 1.0 X-Received: by 10.50.9.72 with SMTP id x8mr7205239iga.19.1381422653124; Thu, 10 Oct 2013 09:30:53 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Thu, 10 Oct 2013 09:30:53 -0700 (PDT) In-Reply-To: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> Date: Thu, 10 Oct 2013 09:30:53 -0700 Message-ID: From: Ted Hardie To: BeckW@telekom.de Content-Type: multipart/alternative; boundary=001a11c2fdc4863c1704e865861c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 16:30:55 -0000 --001a11c2fdc4863c1704e865861c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 10, 2013 at 8:02 AM, wrote: > The basic question seems to be: how can the web server or JS client learn > about local policy enforcement elements in the user's network and access > them to allocate bandwidth, setup priorisation etc? > > So, I'm a little confused about why that is the basic question. If the prioritization is done by something like a diffserv code point, it seems like the question is how the flow signals its classification, rather than to whom it signals that . I would presume that the networks which honor such markings would be constructed such that some conversant network element is on path. What it is and where it is kind of aren't the JS app or browser's issue. What am I missing? Ted > The ALTO WG had a very similar problem and proposed DHCP after DNS expert= s > dismissed a discovery mechanism based on reverse DNS lookups. > > The classical solution: avoid the problem by having a webrtc server in > your local network which does policy enforcement/QoS priorisation etc, an= d > interconnects to some other webrtc server with a standardized protocol li= ke > SIP or XMPP. Popular in RTCWEB, less popular elsewhere.. > > The DHCP way: let the browser learn about the policy enforcement elements > through DHCP, it may communicate them to the server. This has some > problems. There are no widely adopted DHCP APIs, and the policy enforceme= nt > elements may be unwilling to let some random web server access them. > > DNS magic: derive the address of your local policy enforcement element by > manipulating the result of a reverse DNS lookup of the global IP address. > > Manual configuration: Solves only the problem of missing DHCP APIs and > introduces the usability nightmare we know too well from SIP clients. > > 3rd party auth: the user authenticates with a local idP, which not only > carries the user's name but also the local policy enforcement urls as > attributes. A web server can use the 3rd party auth token to access the > local network elements. Haven't thought this through yet. > > > Wolfgang Beck > > -----Urspr=FCngliche Nachricht----- > Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag > von Harald Alvestrand > Gesendet: Dienstag, 8. Oktober 2013 13:01 > An: rtcweb@ietf.org > Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC > of draft-ietf-rtcweb-use-cases-and-requirements-11 > > On 10/08/2013 09:17 AM, Karl Stahl wrote: > > Hej Magnus, > > > >> Also, are you really interested in knowing that it is VP9 vs H.264, > >> isn't > > the questions this is video of this priority that is important? > >> I think you need to more carefully consider what are the goals you > >> try to > > achieve them. > > > > Actually, my concern is to get an idea of the maximum bandwidth that > > could be required for a WebRTC (ICE) setup media flow. Both voice and > > video should be prioritized over data (their individual priority is of > > less importance as long as there is sufficient bandwidth for both). > > You don't know that without knowing what the application is for. > In, for instance, a shooter game with voice backchannels, the movement an= d > event information (data) is MORE time sensitive than the voice data. > > > > > With diffserv you don't need to know the bandwidth requirement, but > > with RSVP reservation (like in cable and mobile networks) you need to > > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > > H.264 is like 3,5 mbps. > > Again, without knowing the application, you don't know that. > The application could decide to use QCIF or HD, and the bandwidth > variation of screencast (semi-static with sudden, large changes) is > completely different from that of a talking head, which is again complete= ly > different from a high-movement scene. > > > > > To add to the complication of codec variants, the video codecs in > > question for WebRTC have variable bandwidth, and when there is a poor > > connection we see Chrome reducing the video window size to reduce the > bandwidth used... > > > > I think the payload type field at best can reflect a maximum bandwidth > > to initially reserve bandwidth for, and thereafter make new > > reservations if the bandwidth changes during the call. So could we > > change RTP to show maximum bandwidth instead of payload type in that > > field outside the encrypted payload :) ... Or maybe that is not a joke? > > I think these ruminations only lead to one conclusion: > > You can't tell what the needed bandwidth is up front without asking the > application. > You can't tell what the right priority ranking is without asking the > application. > > If you need to know the bandwidth or the priority up front, the > application has to tell you. Anything else is pure heuristics. > > _______________________________________________ > 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 > --001a11c2fdc4863c1704e865861c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 10, 2013 at 8:02 AM, <BeckW@telekom.de>= ; wrote:
The basic question seems to be: how can the web server or JS client learn a= bout local policy enforcement elements in the user's network and access= them to allocate bandwidth, setup priorisation etc?


So, I'm a little confused about wh= y that is the basic question.=A0 If the prioritization is done by something= like a diffserv code point, it seems like the question is how the flow sig= nals its classification, rather than to whom it signals that .=A0 I would p= resume that the networks which honor such markings would be constructed suc= h that some conversant network element is on path.=A0 What it is and where = it is kind of aren't the JS app or browser's issue.

What am I missing?

Ted

=A0
The ALTO WG had a very similar problem and proposed DHCP after DNS experts = dismissed a discovery mechanism based on reverse DNS lookups.

The classical solution: avoid the problem by having a webrtc server in your= local network which does policy enforcement/QoS priorisation etc, and inte= rconnects to some other webrtc server with a standardized protocol like SIP= or XMPP. Popular in RTCWEB, less popular elsewhere..

The DHCP way: let the browser learn about the policy enforcement elements t= hrough DHCP, it may communicate them to the server. This has some problems.= There are no widely adopted DHCP APIs, and the policy enforcement elements= may be unwilling to let some random web server access them.

DNS magic: derive the address of your local policy enforcement element by m= anipulating the result of a reverse DNS lookup of the global IP address.
Manual configuration: Solves only the problem of missing DHCP APIs and intr= oduces the usability nightmare we know too well from SIP clients.

3rd party auth: the user authenticates with a local idP, which not only car= ries the user's name but also the local policy enforcement urls as attr= ibutes. A web server can use the 3rd party auth token to access the local n= etwork elements. Haven't thought this through yet.


Wolfgang Beck

-----Urspr=FCngliche Nachricht-----
Von: rtcweb-bounces@ietf.org= [mailto:rtcweb-bounces@ietf.org= ] Im Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 13:01
An: rtcweb@ietf.org
Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC o= f draft-ietf-rtcweb-use-cases-and-requirements-11

On 10/08/2013 09:17 AM, Karl Stahl wrote:
> Hej Magnus,
>
>> Also, are you really interested in knowing that it is VP9 vs H.264= ,
>> isn't
> the questions this is video of this priority that is important?
>> I think you need to more carefully consider what are the goals you=
>> try to
> achieve them.
>
> Actually, my concern is to get an idea of the maximum bandwidth that > could be required for a WebRTC (ICE) setup media flow. Both voice and<= br> > video should be prioritized over data (their individual priority is of=
> less importance as long as there is sufficient bandwidth for both).
You don't know that without knowing what the application is for.
In, for instance, a shooter game with voice backchannels, the movement and = event information (data) is MORE time sensitive than the voice data.

>
> With diffserv you don't need to know the bandwidth requirement, bu= t
> with RSVP reservation (like in cable and mobile networks) you need to<= br> > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=
> H.264 is like 3,5 mbps.

Again, without knowing the application, you don't know that.
The application could decide to use QCIF or HD, and the bandwidth variation= of screencast (semi-static with sudden, large changes) is completely diffe= rent from that of a talking head, which is again completely different from = a high-movement scene.

>
> To add to the complication of codec variants, the video codecs in
> question for WebRTC have variable bandwidth, and when there is a poor<= br> > connection we see Chrome reducing the video window size to reduce the = bandwidth used...
>
> I think the payload type field at best can reflect a maximum bandwidth=
> to initially reserve bandwidth for, and thereafter make new
> reservations if the bandwidth changes during the call. So could we
> change RTP to show maximum bandwidth instead of payload type in that > field outside the encrypted payload :) ... Or maybe that is not a joke= ?

I think these ruminations only lead to one conclusion:

You can't tell what the needed bandwidth is up front without asking the= application.
You can't tell what the right priority ranking is without asking the ap= plication.

If you need to know the bandwidth or the priority up front, the application= has to tell you. Anything else is pure heuristics.

_______________________________________________
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

--001a11c2fdc4863c1704e865861c-- From BeckW@telekom.de Fri Oct 11 02:20:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3441511E8142 for ; Fri, 11 Oct 2013 02:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbjHk9WhNA55 for ; Fri, 11 Oct 2013 02:20:28 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id AC9AC21E80E4 for ; Fri, 11 Oct 2013 02:20:17 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 11 Oct 2013 11:20:15 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.164]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 11 Oct 2013 11:20:15 +0200 From: To: Date: Fri, 11 Oct 2013 11:20:13 +0200 Thread-Topic: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: Ac7F1gS7mx21ZNPsRQSeFG1FqZLXDwAieFIw Message-ID: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 09:20:33 -0000 Ted wrote: > So, I'm a little confused about why that is the basic question. If the p= rioritization is done by something like a diffserv code=20 > point, it seems like the question is how the flow signals its classificat= ion, rather than to whom it signals that . I would=20 > presume that the networks which honor such markings would be constructed = such that some conversant network element is on path. =20 > What it is and where it is kind of aren't the JS app or browser's issue. > What am I missing? Here are some examples that were mentioned on the list or elsewhere: - My company doesn't allow tunnels to the TURN server of some outside WebRT= C service. How can I tell the WebRTC service to use my company's TURN serve= r? - My ISP uses DSCP code point x for low delay. How can I tell my WebRTC ser= vice to use this code point for the flows that require low delay (as Harald= correctly pointed out, only the service self knows about the requirements = of a flow)? - My ISP requires admission control to protect its low delay class from pac= ket loss. How can a WebRTC service contact the resource admission control s= ervice (ok, this a bit speculative)? In all those cases, the WebRTC service needs information about the user's i= nfrastructure, be it the company intranet or the ISP. We currently don't ha= ve a good way to get such information.=20 Wolfgang Beck =A0 -----Urspr=FCngliche Nachricht----- Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag vo= n Harald Alvestrand Gesendet: Dienstag, 8. Oktober 2013 13:01 An: rtcweb@ietf.org Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC o= f draft-ietf-rtcweb-use-cases-and-requirements-11 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, > >> Also, are you really interested in knowing that it is VP9 vs H.264, >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you >> try to > achieve them. > > Actually, my concern is to get an idea of the maximum bandwidth that > could be required for a WebRTC (ICE) setup media flow. Both voice and > video should be prioritized over data (their individual priority is of > less importance as long as there is sufficient bandwidth for both). You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement and = event information (data) is MORE time sensitive than the voice data. > > With diffserv you don't need to know the bandwidth requirement, but > with RSVP reservation (like in cable and mobile networks) you need to > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > H.264 is like 3,5 mbps. Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth variation= of screencast (semi-static with sudden, large changes) is completely diffe= rent from that of a talking head, which is again completely different from = a high-movement scene. > > To add to the complication of codec variants, the video codecs in > question for WebRTC have variable bandwidth, and when there is a poor > connection we see Chrome reducing the video window size to reduce the ban= dwidth used... > > I think the payload type field at best can reflect a maximum bandwidth > to initially reserve bandwidth for, and thereafter make new > reservations if the bandwidth changes during the call. So could we > change RTP to show maximum bandwidth instead of payload type in that > field outside the encrypted payload :) ... Or maybe that is not a joke? I think these ruminations only lead to one conclusion: You can't tell what the needed bandwidth is up front without asking the app= lication. You can't tell what the right priority ranking is without asking the applic= ation. If you need to know the bandwidth or the priority up front, the application= has to tell you. Anything else is pure heuristics. _______________________________________________ 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 harald@alvestrand.no Fri Oct 11 04:05:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470F921E81C2 for ; Fri, 11 Oct 2013 04:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWPamAlxOnfy for ; Fri, 11 Oct 2013 04:05:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFBC21E813A for ; Fri, 11 Oct 2013 04:05:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5848E39EA0A; Fri, 11 Oct 2013 13:05:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4VcEpLsl1ml; Fri, 11 Oct 2013 13:05:27 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5DF1339E04C; Fri, 11 Oct 2013 13:05:27 +0200 (CEST) Message-ID: <5257DB76.7000200@alvestrand.no> Date: Fri, 11 Oct 2013 13:05:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: BeckW@telekom.de, ted.ietf@gmail.com References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 11:05:41 -0000 On 10/11/2013 11:20 AM, BeckW@telekom.de wrote: > Ted wrote: >> So, I'm a little confused about why that is the basic question. If the prioritization is done by something like a diffserv code >> point, it seems like the question is how the flow signals its classification, rather than to whom it signals that . I would >> presume that the networks which honor such markings would be constructed such that some conversant network element is on path. >> What it is and where it is kind of aren't the JS app or browser's issue. >> What am I missing? > Here are some examples that were mentioned on the list or elsewhere: > - My company doesn't allow tunnels to the TURN server of some outside WebRTC service. How can I tell the WebRTC service to use my company's TURN server? > - My ISP uses DSCP code point x for low delay. How can I tell my WebRTC service to use this code point for the flows that require low delay (as Harald correctly pointed out, only the service self knows about the requirements of a flow)? > - My ISP requires admission control to protect its low delay class from packet loss. How can a WebRTC service contact the resource admission control service (ok, this a bit speculative)? > > In all those cases, the WebRTC service needs information about the user's infrastructure, be it the company intranet or the ISP. We currently don't have a good way to get such information. This topic may have solutions that aren't being pursued in the RTCWEB WG. In particular: http://www.w3.org/TR/2013/WD-discovery-api-20130924/ describes a proposal for how to find objects on the local net (currently: announced via upnp and zeroconf), and http://www.w3.org/TR/netinfo-api/ describes a proposal for getting some information about how you're connected to the network. Getting that information may be out of scope for WEBRTC or RTCWEB. Putting that information to use once we have it may be in scope. From martin.thomson@gmail.com Fri Oct 11 04:32:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6CF21E80F3 for ; Fri, 11 Oct 2013 04:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL5Hh2Qidgel for ; Fri, 11 Oct 2013 04:32:00 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3259D21E80EB for ; Fri, 11 Oct 2013 04:32:00 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hn3so900406wib.17 for ; Fri, 11 Oct 2013 04:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VSPN0XNFNVfiqzA3IOlDwC+4R1o2wLlC1ipwCq2+UPs=; b=nFtYh5bpp4g6PaMOx2Nttwte5o3IS2lRUq4Zd3uAkRi9EkxZ/XTj9EOpr0+m1YjAAd +ygrn1Lf0/q21OUuqJ5BJO5HsqRiAwK5ftdy/CBUH/2ccsfjhz5ZmlRvRi3/N6uKvlH9 h5i9RSILR9ryB/4tktcu7YR7InwyqawjpE5CD9QVP86Fs1vYlkCj4EEKpV7Wen2eq+hh ewPzX4NIfeQrG+Rale4pUe7b8tn50e4XIF7ixdaZ2khLbHTtpp/6IDfnkSj4obvOACMS zC1bRbBtUv3tlHb1JznmBKaU2Z/u/sgkj/5Yh7fnR/SQynCSuNRmlXNrOGDmypa7HQf+ fitA== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr2822454wic.64.1381491119264; Fri, 11 Oct 2013 04:31:59 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Fri, 11 Oct 2013 04:31:59 -0700 (PDT) In-Reply-To: <5257DB76.7000200@alvestrand.no> References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> <5257DB76.7000200@alvestrand.no> Date: Fri, 11 Oct 2013 04:31:59 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 11:32:01 -0000 On 11 October 2013 04:05, Harald Alvestrand wrote: > This topic may have solutions that aren't being pursued in the RTCWEB WG. > > In particular: > > http://www.w3.org/TR/2013/WD-discovery-api-20130924/ > > describes a proposal for how to find objects on the local net (currently: > announced via upnp and zeroconf), and > > http://www.w3.org/TR/netinfo-api/ > > describes a proposal for getting some information about how you're connected > to the network. Those solutions may not be appropriate for use in web browsers, in much the same way that the "raw sockets" API is not. > Getting that information may be out of scope for WEBRTC or RTCWEB. > Putting that information to use once we have it may be in scope. I find it more appropriate to say first that the problem is in scope, then to look for solutions that you don't have to build yourself. It seems that if you want to be able to do priority marking, then a way of discovering what markings do what is entirely in scope. This is, of course, another case where the delineation of responsibilities is required. The W3C group you chair might decide to use the discovery API, but there may be a need to assess the discovery mechanisms here. Other items on the list - a reasonable set of questions - seemed like even larger problems. If we're talking about a generic way to advertise packet prioritization capabilities in a network, plus ways to manage access to those features, that's a non-trivial enterprise. From harald@alvestrand.no Fri Oct 11 05:19:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F6D21E81B2 for ; Fri, 11 Oct 2013 05:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+fPwEKwAtVb for ; Fri, 11 Oct 2013 05:19:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CF7F221E81AF for ; Fri, 11 Oct 2013 05:19:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3DA9839EA1B; Fri, 11 Oct 2013 14:19:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbqXcRT0GniH; Fri, 11 Oct 2013 14:19:24 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7846139E04C; Fri, 11 Oct 2013 14:19:24 +0200 (CEST) Message-ID: <5257ECCA.9040301@alvestrand.no> Date: Fri, 11 Oct 2013 14:19:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Martin Thomson References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> <5257DB76.7000200@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:19:41 -0000 On 10/11/2013 01:31 PM, Martin Thomson wrote: > On 11 October 2013 04:05, Harald Alvestrand wrote: >> This topic may have solutions that aren't being pursued in the RTCWEB WG. >> >> In particular: >> >> http://www.w3.org/TR/2013/WD-discovery-api-20130924/ >> >> describes a proposal for how to find objects on the local net (currently: >> announced via upnp and zeroconf), and >> >> http://www.w3.org/TR/netinfo-api/ >> >> describes a proposal for getting some information about how you're connected >> to the network. > Those solutions may not be appropriate for use in web browsers, in > much the same way that the "raw sockets" API is not. That's the reason why I selected those particular ones - they are proposals being made for use in browsers. They might be successful or unsuccessful, but the browsers are their target. > >> Getting that information may be out of scope for WEBRTC or RTCWEB. >> Putting that information to use once we have it may be in scope. > I find it more appropriate to say first that the problem is in scope, > then to look for solutions that you don't have to build yourself. It > seems that if you want to be able to do priority marking, then a way > of discovering what markings do what is entirely in scope. > > This is, of course, another case where the delineation of > responsibilities is required. The W3C group you chair might decide to > use the discovery API, but there may be a need to assess the discovery > mechanisms here. > > Other items on the list - a reasonable set of questions - seemed like > even larger problems. If we're talking about a generic way to > advertise packet prioritization capabilities in a network, plus ways > to manage access to those features, that's a non-trivial enterprise. Yup. Those proposals above don't address those problems. But if they are able to do what they are designed to do, following their lead may be more doable than striking out in a completely new direction. (The netinfo API seems a bit moribund, btw. If anyone knows why, it would be nice if they could post an update here.) From BeckW@telekom.de Fri Oct 11 05:26:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773FC21E81B8 for ; Fri, 11 Oct 2013 05:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QZhR-DWUhHh for ; Fri, 11 Oct 2013 05:26:28 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 81E8821F9BA4 for ; Fri, 11 Oct 2013 05:26:07 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 11 Oct 2013 14:26:00 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.164]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 11 Oct 2013 14:26:00 +0200 From: To: , Date: Fri, 11 Oct 2013 14:25:59 +0200 Thread-Topic: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: Ac7GdXO+vIfJrUSwTd6g9Tb1tL7aVwABUo/A Message-ID: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> <5257DB76.7000200@alvestrand.no> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:26:33 -0000 TWFydGluIFRob21zb24gd3JvdGU6DQo+IE9uIDExIE9jdG9iZXIgMjAxMyAwNDowNSwgSGFyYWxk IEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPiB3cm90ZToNCj4+IC4uIGh0dHA6Ly93 d3cudzMub3JnL1RSLzIwMTMvV0QtZGlzY292ZXJ5LWFwaS0yMDEzMDkyNC8gLi4NCj4+DQo+PiBk ZXNjcmliZXMgYSBwcm9wb3NhbCBmb3IgaG93IHRvIGZpbmQgb2JqZWN0cyBvbiB0aGUgbG9jYWwg bmV0IChjdXJyZW50bHk6DQo+PiBhbm5vdW5jZWQgdmlhIHVwbnAgYW5kIHplcm9jb25mKSwgYW5k DQo+Pg0KPj4gaHR0cDovL3d3dy53My5vcmcvVFIvbmV0aW5mby1hcGkvDQo+Pg0KPj4gZGVzY3Jp YmVzIGEgcHJvcG9zYWwgZm9yIGdldHRpbmcgc29tZSBpbmZvcm1hdGlvbiBhYm91dCBob3cgeW91 J3JlIA0KPj4gY29ubmVjdGVkIHRvIHRoZSBuZXR3b3JrLg0KPg0KPiBUaG9zZSBzb2x1dGlvbnMg bWF5IG5vdCBiZSBhcHByb3ByaWF0ZSBmb3IgdXNlIGluIHdlYiBicm93c2VycywgaW4gbXVjaCB0 aGUgc2FtZSB3YXkgdGhhdCB0aGUgInJhdyBzb2NrZXRzIiBBUEkgaXMgbm90Lg0KTmV0aW5mby1h cGkgaXMgaW1wbGVtZW50ZWQgaW4gRmlyZWZveCAod2l0aCBhIG1veiBwcmVmaXgpLiBJdCBjb3Vs ZCBiZSBleHRlbmRlZCB0byBtYXRjaCB0aGUgdXNlIGNhc2VzIEkgZGVzY3JpYmVkLg0KDQpXRC1k aXNjb3ZlcnktYXBpIGlzIHdvbmRlcmZ1bGx5IGZsZXhpYmxlLCBidXQgcHJvYmFibHkgdG9vIHNj YXJ5IGZvciB0aGUgdXNlcjoNCiJleGFtcGxlLmNvbSB3YW50cyB0byBzY2FuIHlvdSBuZXR3b3Jr IGZvciBhbGwgVFZzLCBwcmludGVycywgcm91dGVycywgVFVSTi1TZXJ2ZXJzOiBEZW55L0FsbG93 PyINCkkgZ3Vlc3MgdGhhdCdzIHRoZSByZWFzb24gd2h5IG5vIGJyb3dzZXIgc3VwcG9ydHMgaXQu DQoNCg0KDQpXb2xmZ2FuZw0K From martin.thomson@gmail.com Fri Oct 11 05:35:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2EA11E813D for ; Fri, 11 Oct 2013 05:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AehVX7urbbeC for ; Fri, 11 Oct 2013 05:35:50 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1521E80FB for ; Fri, 11 Oct 2013 05:35:47 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so369019wgh.22 for ; Fri, 11 Oct 2013 05:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o3vV6maOKJfLtOM1hhaf7bVbed2qZKw8JhcGkO698G0=; b=it14Ah9vSC2MiHlZIB0YkaiIMYRxIbVsrG7pTdpt1xpK8xbK63F/+C9WjL2ob7CGN8 zyrSqTxVzPBF0gnoUJJV/h+9W3+ib1zGr9jmU37nftbf8N+aYk6b+wt8mCCeyRMtxe5Z Q4vg5s9vVVNGkSv/nIFce7MdLhQjvb/LmV1gkT+vLvOmLSZmFV1TPk0n0LpLjAsbV/Xe YVhWjapXzbII2k6H/gyE7hFH2f3pECu3LCrY72scV0IkHgqSRIQwEDOzFXO5CVArFLRJ 2tLjWDd+VNxnVU7bklmV5HPZ/SESpfWh0GoW4oZWNFUJ3behE2k5VXlRjeMsa7KkUvSo cARw== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr3117917wij.30.1381494946195; Fri, 11 Oct 2013 05:35:46 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Fri, 11 Oct 2013 05:35:46 -0700 (PDT) In-Reply-To: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> <5257DB76.7000200@alvestrand.no> Date: Fri, 11 Oct 2013 05:35:46 -0700 Message-ID: From: Martin Thomson To: BeckW@telekom.de Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:35:51 -0000 On 11 October 2013 05:25, wrote: > Netinfo-api is implemented in Firefox (with a moz prefix). It could be extended to match the use cases I described. That doesn't sound like a great idea, but it's there all right. That said, the capabilities are significantly less than what I remember from when I last reviewed the specification: >>> navigator.mozConnection.bandwidth Infinity >>> navigator.mozConnection.metered false Not exactly earth-shattering. > WD-discovery-api is wonderfully flexible, but probably too scary for the user: Oh hooray, another API with a requirement to ask a user for permission without any real consideration given to how to ask properly. You are right, Section 4.1 is a frightful mess. From ted.ietf@gmail.com Fri Oct 11 10:56:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D254821E8133 for ; Fri, 11 Oct 2013 10:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K80pJifl6E1M for ; Fri, 11 Oct 2013 10:56:27 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7060921F91AB for ; Fri, 11 Oct 2013 10:56:19 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id x13so9013964ief.31 for ; Fri, 11 Oct 2013 10:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eoc95P9CBXh6kKpzmftpfwUqwvYkAepI1fIHzbyiJ2A=; b=LwNcZuT41KE1pX7FTm6jsmWcKUEWEVzigxRepfYE5Zwi49/rleSti07wLh4Z4Zc1E7 pVJGAglPhN9AOhIc4mPln5fVzPdpqY88AxpEnXKrnuhQKrt5nuW4fm8rERYxQ1Ek+Dxs oYMUYAzQEvBR43UPR3T1Xk+K39t4wmouf9/jfCo5GuMfeZnn7GVntxyatYjkL1a1nbbZ OBO+dqnrSrZHe/n85tg2yS6/xQM6pK67SkfgcdV9n+sRW5c3YQtOCwzqZu1PAAV8tA4R fBQ8STZf/oLSRfZdMhcWwhrTSrBPPaPx03LBg8VLDsfuWfhg3HiIL1AH6INa/RAZS8AW yzFA== MIME-Version: 1.0 X-Received: by 10.43.178.135 with SMTP id ow7mr11757015icc.43.1381514177199; Fri, 11 Oct 2013 10:56:17 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 11 Oct 2013 10:56:17 -0700 (PDT) In-Reply-To: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> Date: Fri, 11 Oct 2013 10:56:17 -0700 Message-ID: From: Ted Hardie To: BeckW@telekom.de Content-Type: multipart/alternative; boundary=001a11c30becc8caa104e87ad57b Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 17:56:46 -0000 --001a11c30becc8caa104e87ad57b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 11, 2013 at 2:20 AM, wrote: > Ted wrote: > > So, I'm a little confused about why that is the basic question. If the > prioritization is done by something like a diffserv code > > point, it seems like the question is how the flow signals its > classification, rather than to whom it signals that . I would > > presume that the networks which honor such markings would be constructe= d > such that some conversant network element is on path. > > What it is and where it is kind of aren't the JS app or browser's issue= . > > > What am I missing? > > Here are some examples that were mentioned on the list or elsewhere: > - My company doesn't allow tunnels to the TURN server of some outside > WebRTC service. How can I tell the WebRTC service to use my company's TUR= N > server? > I see. I was taking your original statement "The basic question seems to be: how can the web server or JS client learn about local policy enforcement elements in the user's network and access them to allocate bandwidth, setup priorisation etc?" a bit too literally--I thought you were focused purely on prioritization and resource allocation. If part of what you mean is "how do I discover a service on the local network when I require it", then the answer is going to be dependent on the service, not on the condition that causes you to require it. That it is, for TURN you look to RFC 5766 and RFC 5928 and their successors, not to RTCWEB. - My ISP uses DSCP code point x for low delay. How can I tell my WebRTC > service to use this code point for the flows that require low delay (as > Harald correctly pointed out, only the service self knows about the > requirements of a flow)? > So, I'm not sure there are many places where DSCP markings from external parties are trusted at AS borders in any case, but the theory is that we say what DSCP marking should be used and the ISP recognizes it as WebRTC traffic from that code point. In the case where the ISP does trust external markings but doesn't use a standard one, you have a bit of problem in any case--the marking on the packet from the peer may be valid in the origin network, so recommending it be changed to the one in the destination may result in sub-optimal processing in the origin. At that point, you need one of the two peer networks to adjust the markings at the border. This is, again, not really a problem for RTCWEB to solve. > - My ISP requires admission control to protect its low delay class from > packet loss. How can a WebRTC service contact the resource admission > control service (ok, this a bit speculative)? > > Yeah, I tend to agree that this is speculative. > In all those cases, the WebRTC service needs information about the user's > infrastructure, be it the company intranet or the ISP. We currently don't > have a good way to get such information. > > For the services like TURN, I believe the answer is "use what ever is defined for that service, rather than inventing a new one for WebRTC". For the marking, I think the answer has to be "define a standard marking", since you likely can't find the specific markings and then implement translations for all the networks a flow might traverse. Just my opinion as a contributor, mind, not a chair or company statement. regards, Ted > > Wolfgang Beck > > > -----Urspr=FCngliche Nachricht----- > Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag > von Harald Alvestrand > Gesendet: Dienstag, 8. Oktober 2013 13:01 > An: rtcweb@ietf.org > Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC > of draft-ietf-rtcweb-use-cases-and-requirements-11 > > On 10/08/2013 09:17 AM, Karl Stahl wrote: > > Hej Magnus, > > > >> Also, are you really interested in knowing that it is VP9 vs H.264, > >> isn't > > the questions this is video of this priority that is important? > >> I think you need to more carefully consider what are the goals you > >> try to > > achieve them. > > > > Actually, my concern is to get an idea of the maximum bandwidth that > > could be required for a WebRTC (ICE) setup media flow. Both voice and > > video should be prioritized over data (their individual priority is of > > less importance as long as there is sufficient bandwidth for both). > > You don't know that without knowing what the application is for. > In, for instance, a shooter game with voice backchannels, the movement an= d > event information (data) is MORE time sensitive than the voice data. > > > > > With diffserv you don't need to know the bandwidth requirement, but > > with RSVP reservation (like in cable and mobile networks) you need to > > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > > H.264 is like 3,5 mbps. > > Again, without knowing the application, you don't know that. > The application could decide to use QCIF or HD, and the bandwidth > variation of screencast (semi-static with sudden, large changes) is > completely different from that of a talking head, which is again complete= ly > different from a high-movement scene. > > > > > To add to the complication of codec variants, the video codecs in > > question for WebRTC have variable bandwidth, and when there is a poor > > connection we see Chrome reducing the video window size to reduce the > bandwidth used... > > > > I think the payload type field at best can reflect a maximum bandwidth > > to initially reserve bandwidth for, and thereafter make new > > reservations if the bandwidth changes during the call. So could we > > change RTP to show maximum bandwidth instead of payload type in that > > field outside the encrypted payload :) ... Or maybe that is not a joke? > > I think these ruminations only lead to one conclusion: > > You can't tell what the needed bandwidth is up front without asking the > application. > You can't tell what the right priority ranking is without asking the > application. > > If you need to know the bandwidth or the priority up front, the > application has to tell you. Anything else is pure heuristics. > > _______________________________________________ > 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 > > --001a11c30becc8caa104e87ad57b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2013 at 2:20 AM, <BeckW@telekom.de>= ; wrote:
Ted wrote:
> So, I'm a little confused about why that is the basic question. = =A0If the prioritization is done by something like a diffserv code
> point, it seems like the question is how the flow signals its classifi= cation, rather than to whom it signals that . =A0I would
> presume that the networks which honor such markings would be construct= ed such that some conversant network element is on path.
> What it is and where it is kind of aren't the JS app or browser= 9;s issue.

> What am I missing?

Here are some examples that were mentioned on the list or elsewhere:<= br> - My company doesn't allow tunnels to the TURN server of some outside W= ebRTC service. How can I tell the WebRTC service to use my company's TU= RN server?

I see.=A0 I was taking your = original statement "The basic question seems to be: how can the web se= rver or JS client=20 learn about local policy enforcement elements in the user's network and= =20 access them to allocate bandwidth, setup priorisation etc?" a bit too = literally--I thought you were focused purely on prioritization and resource= allocation.=A0 If part of what you mean is "how do I discover a servi= ce on the local network when I require it", then the answer is going t= o be dependent on the service, not on the condition that causes you to requ= ire it.=A0 That it is, for TURN you look to RFC 5766 and RFC 5928 and their= successors, not to RTCWEB.=A0

- My ISP uses DSCP code point x for low delay. How can I tell my WebRTC ser= vice to use this code point for the flows that require low delay (as Harald= correctly pointed out, only the service self knows about the requirements = of a flow)?

So, I'm not sure there are many places= where DSCP markings from external parties are trusted at AS borders in any= case, but the theory is that we say what DSCP marking should be used and t= he ISP recognizes it as WebRTC traffic from that code point.=A0 In the case= where the ISP does trust external markings but doesn't use a standard = one, you have a bit of problem in any case--the marking on the packet from = the peer may be valid in the origin network, so recommending it be changed = to the one in the destination may result in sub-optimal processing in the o= rigin.=A0 At that point, you need one of the two peer networks to adjust th= e markings at the border.=A0 This is, again, not really a problem for RTCWE= B to solve.
=A0
- My ISP requires admission control to protect its low delay class from pac= ket loss. How can a WebRTC service contact the resource admission control s= ervice (ok, this a bit speculative)?

Yeah, I tend to agree that this is speculative.
=A0
In all those cases, the WebRTC service needs information about the user'= ;s infrastructure, be it the company intranet or the ISP. We currently don&= #39;t have a good way to get such information.


For the services like TURN, I believe the answer is "use w= hat ever is defined for that service, rather than inventing a new one for W= ebRTC".=A0 For the marking, I think the answer has to be "define = a standard marking", since you likely can't find the specific mark= ings and then implement translations for all the networks a flow might trav= erse.

Just my opinion as a contributor, mind, not a chair or compa= ny statement.

regards,

Ted

=A0

Wolfgang Beck
=A0

-----Urspr=FCngliche Nachricht-----
Von: rtcweb-bounces@ietf.org= [mailto:rtcweb-bounces@ietf.org= ] Im Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 13:01
An: rtcweb@ietf.org
Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC o= f draft-ietf-rtcweb-use-cases-and-requirements-11

On 10/08/2013 09:17 AM, Karl Stahl wrote:
> Hej Magnus,
>
>> Also, are you really interested in knowing that it is VP9 vs H.264= ,
>> isn't
> the questions this is video of this priority that is important?
>> I think you need to more carefully consider what are the goals you=
>> try to
> achieve them.
>
> Actually, my concern is to get an idea of the maximum bandwidth that > could be required for a WebRTC (ICE) setup media flow. Both voice and<= br> > video should be prioritized over data (their individual priority is of=
> less importance as long as there is sufficient bandwidth for both).
You don't know that without knowing what the application is for.
In, for instance, a shooter game with voice backchannels, the movement and = event information (data) is MORE time sensitive than the voice data.

>
> With diffserv you don't need to know the bandwidth requirement, bu= t
> with RSVP reservation (like in cable and mobile networks) you need to<= br> > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=
> H.264 is like 3,5 mbps.

Again, without knowing the application, you don't know that.
The application could decide to use QCIF or HD, and the bandwidth variation= of screencast (semi-static with sudden, large changes) is completely diffe= rent from that of a talking head, which is again completely different from = a high-movement scene.

>
> To add to the complication of codec variants, the video codecs in
> question for WebRTC have variable bandwidth, and when there is a poor<= br> > connection we see Chrome reducing the video window size to reduce the = bandwidth used...
>
> I think the payload type field at best can reflect a maximum bandwidth=
> to initially reserve bandwidth for, and thereafter make new
> reservations if the bandwidth changes during the call. So could we
> change RTP to show maximum bandwidth instead of payload type in that > field outside the encrypted payload :) ... Or maybe that is not a joke= ?

I think these ruminations only lead to one conclusion:

You can't tell what the needed bandwidth is up front without asking the= application.
You can't tell what the right priority ranking is without asking the ap= plication.

If you need to know the bandwidth or the priority up front, the application= has to tell you. Anything else is pure heuristics.

_______________________________________________
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


--001a11c30becc8caa104e87ad57b-- From Richard.Lee.FTC@FMR.COM Fri Oct 11 11:26:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B256921E809B for ; Fri, 11 Oct 2013 11:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bea7DwIZusvf for ; Fri, 11 Oct 2013 11:25:42 -0700 (PDT) Received: from msginmsm07vapp.fmr.com (ltm-fwus209m-210m.fidelity.com [155.199.204.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B921E808A for ; Fri, 11 Oct 2013 11:25:41 -0700 (PDT) Received: from msgrtphc01win.DMN1.FMR.COM (MSGRTPHC01WIN.dmn1.fmr.com [10.93.142.12]) by msginmsm07vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id r9BIPXrW016367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 11 Oct 2013 18:25:35 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm07vapp.fmr.com r9BIPXrW016367 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1381515935; bh=wUYn+wYM/gyHoCiGyTnJysQXus7SInusQF07P5idOVw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=PHJ6x3IaLC0nQTxyi9CHz6xw6ZDuuQEZD2CPZJmdKZJvYrL35mndYs3tlLjL0+Y9m NhaVYP6NcCpEBr5JmTk1B79Z2ClZskP8ClJnUKVdoSy1FAYbowhqF6fAjTRanZrT13 sfSqkirj1slEibNPuu0QNwDRqKH4GeNwkW8qHT2Y= Received: from MSGRTPCCRE2WIN.DMN1.FMR.COM ([10.95.11.31]) by msgrtphc01win.DMN1.FMR.COM ([10.93.142.12]) with mapi; Fri, 11 Oct 2013 14:25:34 -0400 From: "Lee, Richard FTC" To: "rtcweb@ietf.org" Date: Fri, 11 Oct 2013 14:25:33 -0400 Thread-Topic: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: Ac7Gq1VOykSgMZqUTRqvXhIF7obhAwAAbyWA Message-ID: <3B4DBB0890AD6642BEAB7B3470FC18F90117A1A1D789@MSGRTPCCRE2WIN.DMN1.FMR.COM> References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3B4DBB0890AD6642BEAB7B3470FC18F90117A1A1D789MSGRTPCCRE2_" MIME-Version: 1.0 Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 18:26:07 -0000 --_000_3B4DBB0890AD6642BEAB7B3470FC18F90117A1A1D789MSGRTPCCRE2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think peer to peer communications are fine and will work akin to the Skyp= e (Best Effort delivery) model Session quality will suffer periodically. While annoying, part of the price= to pay for a free service The expectation of providing network guarantees for timely service delivery= does require active intervention (ToS or DSCP) with associated cost Negotiation of codecs and bandwidth assignments are typically done by the e= ndpoints in a peer to peer endpoints for a given session. Due to the bandwidth options associated with video, it is expected that con= trols will be implemented at enterprise borders to enforce session constrai= nts In part to allow as many sessions as possible. Enterprise support of webRTC will probably evolve as SIP has done. There will be a service/proxy exposed to allow communications inside the co= rporate network In many organizations protocols that bypass standard firewalls (STUN, TURN,= ICE ...) are blocked. Regards Rich From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: Friday, October 11, 2013 1:56 PM To: BeckW@telekom.de Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC o= f draft-ietf-rtcweb-use-cases-and-requirements-11 On Fri, Oct 11, 2013 at 2:20 AM, = > wrote: Ted wrote: > So, I'm a little confused about why that is the basic question. If the p= rioritization is done by something like a diffserv code > point, it seems like the question is how the flow signals its classificat= ion, rather than to whom it signals that . I would > presume that the networks which honor such markings would be constructed = such that some conversant network element is on path. > What it is and where it is kind of aren't the JS app or browser's issue. > What am I missing? Here are some examples that were mentioned on the list or elsewhere: - My company doesn't allow tunnels to the TURN server of some outside WebRT= C service. How can I tell the WebRTC service to use my company's TURN serve= r? I see. I was taking your original statement "The basic question seems to b= e: how can the web server or JS client learn about local policy enforcement= elements in the user's network and access them to allocate bandwidth, setu= p priorisation etc?" a bit too literally--I thought you were focused purely= on prioritization and resource allocation. If part of what you mean is "h= ow do I discover a service on the local network when I require it", then th= e answer is going to be dependent on the service, not on the condition that= causes you to require it. That it is, for TURN you look to RFC 5766 and R= FC 5928 and their successors, not to RTCWEB. - My ISP uses DSCP code point x for low delay. How can I tell my WebRTC ser= vice to use this code point for the flows that require low delay (as Harald= correctly pointed out, only the service self knows about the requirements = of a flow)? So, I'm not sure there are many places where DSCP markings from external pa= rties are trusted at AS borders in any case, but the theory is that we say = what DSCP marking should be used and the ISP recognizes it as WebRTC traffi= c from that code point. In the case where the ISP does trust external mark= ings but doesn't use a standard one, you have a bit of problem in any case-= -the marking on the packet from the peer may be valid in the origin network= , so recommending it be changed to the one in the destination may result in= sub-optimal processing in the origin. At that point, you need one of the = two peer networks to adjust the markings at the border. This is, again, no= t really a problem for RTCWEB to solve. - My ISP requires admission control to protect its low delay class from pac= ket loss. How can a WebRTC service contact the resource admission control s= ervice (ok, this a bit speculative)? Yeah, I tend to agree that this is speculative. In all those cases, the WebRTC service needs information about the user's i= nfrastructure, be it the company intranet or the ISP. We currently don't ha= ve a good way to get such information. For the services like TURN, I believe the answer is "use what ever is defin= ed for that service, rather than inventing a new one for WebRTC". For the = marking, I think the answer has to be "define a standard marking", since yo= u likely can't find the specific markings and then implement translations f= or all the networks a flow might traverse. Just my opinion as a contributor, mind, not a chair or company statement. regards, Ted Wolfgang Beck -----Urspr=FCngliche Nachricht----- Von: rtcweb-bounces@ietf.org [mailto:rtcweb= -bounces@ietf.org] Im Auftrag von Harald Al= vestrand Gesendet: Dienstag, 8. Oktober 2013 13:01 An: rtcweb@ietf.org Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC o= f draft-ietf-rtcweb-use-cases-and-requirements-11 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, > >> Also, are you really interested in knowing that it is VP9 vs H.264, >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you >> try to > achieve them. > > Actually, my concern is to get an idea of the maximum bandwidth that > could be required for a WebRTC (ICE) setup media flow. Both voice and > video should be prioritized over data (their individual priority is of > less importance as long as there is sufficient bandwidth for both). You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement and = event information (data) is MORE time sensitive than the voice data. > > With diffserv you don't need to know the bandwidth requirement, but > with RSVP reservation (like in cable and mobile networks) you need to > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > H.264 is like 3,5 mbps. Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth variation= of screencast (semi-static with sudden, large changes) is completely diffe= rent from that of a talking head, which is again completely different from = a high-movement scene. > > To add to the complication of codec variants, the video codecs in > question for WebRTC have variable bandwidth, and when there is a poor > connection we see Chrome reducing the video window size to reduce the ban= dwidth used... > > I think the payload type field at best can reflect a maximum bandwidth > to initially reserve bandwidth for, and thereafter make new > reservations if the bandwidth changes during the call. So could we > change RTP to show maximum bandwidth instead of payload type in that > field outside the encrypted payload :) ... Or maybe that is not a joke? I think these ruminations only lead to one conclusion: You can't tell what the needed bandwidth is up front without asking the app= lication. You can't tell what the right priority ranking is without asking the applic= ation. If you need to know the bandwidth or the priority up front, the application= has to tell you. Anything else is pure heuristics. _______________________________________________ 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_3B4DBB0890AD6642BEAB7B3470FC18F90117A1A1D789MSGRTPCCRE2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think p= eer to peer communications are fine and will work akin to the Skype (Best E= ffort delivery) model

Sess= ion quality will suffer periodically. While annoying, part of the price to = pay for a free service

The= expectation of providing network guarantees for timely service delivery do= es require active intervention (ToS or DSCP) with associated cost

Negotiation of codecs and bandwidth= assignments are typically done by the endpoints in a peer to peer endpoint= s for a given session.

Due= to the bandwidth options associated with video, it is expected that contro= ls will be implemented at enterprise borders to enforce session constraints=

In part to allow as many = sessions as possible.

 

Enterprise support of w= ebRTC will probably evolve as SIP has done.

There will be a service/proxy exposed to allow communic= ations inside the corporate network

In many organizations protocols that bypass standard firewalls (S= TUN, TURN, ICE …) are blocked.

 

Regards =

Rich

 

 

&nbs= p;

From:<= /b> rtcw= eb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Te= d Hardie
Sent: Friday, October 11, 2013 1:56 PM
To: Bec= kW@telekom.de
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb]= Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-u= se-cases-and-requirements-11

 

On Fri, Oct 11, 2013 at 2:20 AM, <BeckW@telekom.de> wrote:<= /o:p>

Ted wrote:
> So, I'm a little conf= used about why that is the basic question.  If the prioritization is d= one by something like a diffserv code
> point, it seems like the ques= tion is how the flow signals its classification, rather than to whom it sig= nals that .  I would
> presume that the networks which honor suc= h markings would be constructed such that some conversant network element i= s on path.
> What it is and where it is kind of aren't the JS app or = browser's issue.

> What am I missing?

Here are some examples that were m= entioned on the list or elsewhere:
- My company doesn't allow tunnels to= the TURN server of some outside WebRTC service. How can I tell the WebRTC = service to use my company's TURN server?

 

I see.  I was takin= g your original statement "The basic question seems to be: how can the= web server or JS client learn about local policy enforcement elements in t= he user's network and access them to allocate bandwidth, setup priorisation= etc?" a bit too literally--I thought you were focused purely on prior= itization and resource allocation.  If part of what you mean is "= how do I discover a service on the local network when I require it", t= hen the answer is going to be dependent on the service, not on the conditio= n that causes you to require it.  That it is, for TURN you look to RFC= 5766 and RFC 5928 and their successors, not to RTCWEB. 

 

- My ISP uses DSCP code point x for= low delay. How can I tell my WebRTC service to use this code point for the= flows that require low delay (as Harald correctly pointed out, only the se= rvice self knows about the requirements of a flow)?

 <= /p>

So, I'm not s= ure there are many places where DSCP markings from external parties are tru= sted at AS borders in any case, but the theory is that we say what DSCP mar= king should be used and the ISP recognizes it as WebRTC traffic from that c= ode point.  In the case where the ISP does trust external markings but= doesn't use a standard one, you have a bit of problem in any case--the mar= king on the packet from the peer may be valid in the origin network, so rec= ommending it be changed to the one in the destination may result in sub-opt= imal processing in the origin.  At that point, you need one of the two= peer networks to adjust the markings at the border.  This is, again, = not really a problem for RTCWEB to solve.

 

- My ISP requires admission control to protect its low delay class from = packet loss. How can a WebRTC service contact the resource admission contro= l service (ok, this a bit speculative)?

Yeah, I tend to agree that thi= s is speculative.

 

In all = those cases, the WebRTC service needs information about the user's infrastr= ucture, be it the company intranet or the ISP. We currently don't have a go= od way to get such information.

 

=

 

For the services like TURN, I believe the ans= wer is "use what ever is defined for that service, rather than inventi= ng a new one for WebRTC".  For the marking, I think the answer ha= s to be "define a standard marking", since you likely can't find = the specific markings and then implement translations for all the networks = a flow might traverse.

Just my opinion as a contributor, mind, not a chair or company stat= ement.

regards,

Ted


 

=
Wolfgang Beck
 

-----Urspr=FCngliche Nachricht-----
V= on: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org<= /a>] Im Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 201= 3 13:01
An: rtcweb@ietf.org
Be= treff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

On 10/08/2013 09:17 = AM, Karl Stahl wrote:
> Hej Magnus,
>
>> Also, are you= really interested in knowing that it is VP9 vs H.264,
>> isn't> the questions this is video of this priority that is important?
&g= t;> I think you need to more carefully consider what are the goals you>> try to
> achieve them.
>
> Actually, my concer= n is to get an idea of the maximum bandwidth that
> could be required= for a WebRTC (ICE) setup media flow. Both voice and
> video should b= e prioritized over data (their individual priority is of
> less impor= tance as long as there is sufficient bandwidth for both).

You don't = know that without knowing what the application is for.
In, for instance,= a shooter game with voice backchannels, the movement and event information= (data) is MORE time sensitive than the voice data.

>
> Wit= h diffserv you don't need to know the bandwidth requirement, but
> wi= th RSVP reservation (like in cable and mobile networks) you need to
>= know how much to reserve. Voice is like 100's kbit/s, video VP8 or
>= H.264 is like 3,5 mbps.

Again, without knowing the application, you= don't know that.
The application could decide to use QCIF or HD, and th= e bandwidth variation of screencast (semi-static with sudden, large changes= ) is completely different from that of a talking head, which is again compl= etely different from a high-movement scene.

>
> To add to t= he complication of codec variants, the video codecs in
> question for= WebRTC have variable bandwidth, and when there is a poor
> connectio= n we see Chrome reducing the video window size to reduce the bandwidth used= ...
>
> I think the payload type field at best can reflect a ma= ximum bandwidth
> to initially reserve bandwidth for, and thereafter = make new
> reservations if the bandwidth changes during the call. So = could we
> change RTP to show maximum bandwidth instead of payload ty= pe in that
> field outside the encrypted payload :) ... Or maybe that= is not a joke?

I think these ruminations only lead to one conclusio= n:

You can't tell what the needed bandwidth is up front without aski= ng the application.
You can't tell what the right priority ranking is wi= thout asking the application.

If you need to know the bandwidth or t= he priority up front, the application has to tell you. Anything else is pur= e heuristics.

_______________________________________________
rtc= web mailing list
rtcweb@ietf.org<= br>https://www.ietf.org/mailman/listinfo/rtcweb
____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/= rtcweb

 

= = --_000_3B4DBB0890AD6642BEAB7B3470FC18F90117A1A1D789MSGRTPCCRE2_-- From ted.ietf@gmail.com Fri Oct 11 15:43:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5165B21E8094 for ; Fri, 11 Oct 2013 15:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izGB9eDJHt3v for ; Fri, 11 Oct 2013 15:43:55 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 48B4621E8095 for ; Fri, 11 Oct 2013 15:43:51 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id x13so9677241ief.31 for ; Fri, 11 Oct 2013 15:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KkqVl0b4JR5v+Njkn2hIbHULF38BH8vJUeIwYMF1lHc=; b=cI/ETPqXBjmG7zbWddiWkniK0t1h/zzACna72wKqbrJ+vk7vNZEoD17QtQjKNHC2uj FsGfSQR68A4KDgdwp3XAcpCk8ohgs8GD5IfdmLqDqIfl0L+9E4D7TNZDX9h3hSACjBqc CMDM5V+IW21j/45+ozyMSGIEuYOSUF/cRZ04rWWH7c7CdUribbjs74y6SDC1I/0q5/Ju NeGX9Mavjlgp+AJLqEwoK8V4pLmunqTIyYIFtWmD/B5icx1QdNgQecBLe17Qhg+oP8pj Kqwz0wpclu2cbYnW7aei7FX4BsWSlCqMHeWkYdNroSDncaK8fK/9v1i6E12M3oyR+8c8 rgNQ== MIME-Version: 1.0 X-Received: by 10.42.215.80 with SMTP id hd16mr12950487icb.17.1381531421111; Fri, 11 Oct 2013 15:43:41 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 11 Oct 2013 15:43:41 -0700 (PDT) In-Reply-To: <52579E47.6020706@ericsson.com> References: <20131008184514.32189.48777.idtracker@ietfa.amsl.com> <52579E47.6020706@ericsson.com> Date: Fri, 11 Oct 2013 15:43:41 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=20cf301d3cec9a317b04e87ed9b3 Subject: [rtcweb] Fwd: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 22:43:56 -0000 --20cf301d3cec9a317b04e87ed9b3 Content-Type: text/plain; charset=ISO-8859-1 Gonzalo has asked that this get redistributed; please do consider making and/or accepting nominations for IETF leadership positions. Ted ---------- Forwarded message ---------- From: Gonzalo Camarillo Date: Thu, Oct 10, 2013 at 11:44 PM Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV To: rai@ietf.org Folks, we need more volunteers (see email below). If you are thinking of running but still have some doubts about it, feel free to talk with me (or with any of the former RAI ADs) and we will be happy to clarify everything for you. Cheers, Gonzalo -------- Original Message -------- Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Tue, 8 Oct 2013 11:45:14 -0700 From: NomCom Chair Reply-To: To: IETF Announcement List CC: UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai --20cf301d3cec9a317b04e87ed9b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gonzalo has asked that this get redistributed; please= do consider making and/or accepting nominations for IETF leadership positi= ons.

Ted

---------= - Forwarded message ----------
From: Gonzalo Camarillo <Gonzalo.Camarillo@er= icsson.com>
Date: Thu, Oct 10, 2013 at 11:44 PM
Subject= : [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI= , TSV
To: rai@ietf.org


Folks,

we need more volunteers (see email below). If you are thinking of
running but still have some doubts about it, feel free to talk with me
(or with any of the former RAI ADs) and we will be happy to clarify
everything for you.

Cheers,

Gonzalo


-------- Original Message --------
Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TS= V
Date: Tue, 8 Oct 2013 11:45:14 -0700
From: NomCom Chair <nomcom-chai= r@ietf.org>
Reply-To: <nomcom-chair-20= 13@ietf.org>
To: IETF Announcement List <ie= tf-announce@ietf.org>
CC: <ietf@ietf.org>

UPDATE: nominations are too sparse in several = of the IESG areas: =A0APP, OAM,
RAI, and TSV. =A0If you know one or more of those areas, exercise your soci= al
network and submit nominations. =A0We'll be very grateful!

Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and
consider
nominating her or him. Or several folks! Deadline for nominations is
October 18.
Nominate soon to give your nominee(s) plenty time to fill in the
questionnaire.

If you're nominated, even if you support the present incumbent, being reviewed
by Nomcom is great IETF experience. =A0The questionnaire offers a chance to=
think about IETF and about your area. =A0Whether or not your candidacy
progresses
this time, you'll have gained some valuable insights, and you'll ha= ve
contributed
greatly. This process only works because many IETFers take part; please
join in.

Lots more, including which positions are open, how to make a nomination
(including nomination of yourself), and how to send us your feedback on
the desired expertise, follows.

IETFers, let's hear from you! =A0Make nominations, accept nominations!<= br>
If you have any questions about the process, feel free to get in touch
with me.

Best regards,

Allison for the Nomcom

Allison Mankin
Nomcom Chair 2013-14

----- The Info You Need for Nominating -----

The 2013-14 Nominating Committee (Nomcom) is seeking nominations
from now until October 18, 2013. The open positions being considered
by this year's Nomcom can be found later in this section, and also on this year's Nomcom website:

htt= ps://datatracker.ietf.org/nomcom/2013/

Information about the desired expertise for positions is here:
=A0 =A0 =A0 =A0 =A0 https://datatracker.ietf.org/nomcom/2013/expertis= e

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2013 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2013/nominate/

Note that nominations made using the web tool require an ietf.org
datatracker account. You can create a datatracker ietf.org account
if you don't have one already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom13 at ietf.org.
If you nominate by email, please include the word "Nominate" in t= he Subject
and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you
are making the nomination. If you use email, please use a separate email fo= r
each person you nominate, and for each position (if you are nominating one<= br> person for multiple positions).

Self-nomination is welcome! =A0No need to be shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing<= br> Nominees" described in RFC 5680. =A0As stated in RFC 5680: "The l= ist of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists. =A0In all other ways, the
confidentiality requirements of RFC 3777/BCP10 remain in effect. =A0All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the
Nomcom on or before October 18, 2013. =A0Please submit your nominations
as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013.

The list of people and posts whose terms end with the March 2014 IETF
meeting,
and thus the positions for which we are accepting nominations:

IAOC
Chris Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF. =A0Also, please give serious consideration to accepting nominatio= ns
you receive.

The summaries of the desired expertise for the positions, developed by the<= br> respective bodies, are found at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In addition to nominations, the Nomcom seeks community input on
the positions themselves. =A0We need and welcome the community's
views and input on the jobs within each organization. If you
have ideas on the positions' responsibilities (more, less,
different), please let us know. =A0You can send us email about this to
nomcom13 at ietf.org, and= we will use this feedback actively.

Thank you for your help in nominating a great pool of strong and interestin= g
nominees!



_______________________________________________
RAI mailing list
RAI@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/rai

--20cf301d3cec9a317b04e87ed9b3-- From dwing@cisco.com Fri Oct 11 17:35:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A490721E8120 for ; Fri, 11 Oct 2013 17:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NboSBFGw7286 for ; Fri, 11 Oct 2013 17:35:18 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29921E8103 for ; Fri, 11 Oct 2013 17:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15496; q=dns/txt; s=iport; t=1381538117; x=1382747717; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=+6fOCp/EmC0bEfWLO/TBZCrm5Lja1T9DgtiHWkGhUww=; b=blfLwnO1e9A3u1xaGzknmrOCmxA5KJhnD3KT2FLogQ6TIJAK3upQtXGu ShH0hZnSAYwfBg7iRactPS3xxjL/qNmZDiOJUEqHqF1zKOZLddl9cujOC pxGiXDn1Q5AR1QsJOpIEgKh6UX29Gt9VswNo+sytsdVMLZnfPlQY1F1eM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFABeYWFKrRDoG/2dsb2JhbABagwc4wWRLgR4WdIIlAQEBAwEBAQFkBAMLBQsLGCMEByEGHxEGExuHWQMJBQ2yKw2JZwSMYIJpBAeDH4EEA4k8jGCBaYxMhTaBZoFeHA X-IronPort-AV: E=Sophos;i="4.93,479,1378857600"; d="scan'208,217";a="91959017" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 12 Oct 2013 00:35:16 +0000 Received: from sjc-vpn6-1359.cisco.com (sjc-vpn6-1359.cisco.com [10.21.125.79]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9C0ZCIX008542; Sat, 12 Oct 2013 00:35:13 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_EBB5264B-BAA8-4565-9F86-855A42024F86" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Fri, 11 Oct 2013 17:35:12 -0700 Message-Id: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> To: Ted Hardie X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 00:35:22 -0000 --Apple-Mail=_EBB5264B-BAA8-4565-9F86-855A42024F86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 10, 2013, at 9:30 AM, Ted Hardie wrote: > On Thu, Oct 10, 2013 at 8:02 AM, wrote: > The basic question seems to be: how can the web server or JS client = learn about local policy enforcement elements in the user's network and = access them to allocate bandwidth, setup priorisation etc? >=20 >=20 > So, I'm a little confused about why that is the basic question. If = the prioritization is done by something like a diffserv code point, it = seems like the question is how the flow signals its classification, = rather than to whom it signals that . I would presume that the networks = which honor such markings would be constructed such that some conversant = network element is on path. What it is and where it is kind of aren't = the JS app or browser's issue. >=20 > What am I missing? * Several operating systems do not allow non-privileged applications to = set DSCP bits at all; Windows, for example. Yes, I know everyone is = supposed to use any other OS, but Linux has also only allowed certain = DSCP values to be set. * When joining a network, the DSCP values for the network cannot be = learned or discovered -- we lack a protocol to do that. The RFCs that = define DSCP values are not standards (they are informational) and many a = network choose their own values. =20 * Setting the correct DSCP value affects only outgoing traffic but has = no influence on the incoming traffic. As you stated in a later post, = incoming DSCP isn't trusted anyway. "Reflexive DSCP Policy" was = attempted years ago to allow the network to assume a host's DSCP = settings could be applied to the other direction, but it was rejected I = believe during IETF review but I couldn't find record why it was = actually disposed (document was draft-ietf-ieprep-reflexive-dscp). -d >=20 > Ted >=20 > =20 > The ALTO WG had a very similar problem and proposed DHCP after DNS = experts dismissed a discovery mechanism based on reverse DNS lookups. >=20 > The classical solution: avoid the problem by having a webrtc server in = your local network which does policy enforcement/QoS priorisation etc, = and interconnects to some other webrtc server with a standardized = protocol like SIP or XMPP. Popular in RTCWEB, less popular elsewhere.. >=20 > The DHCP way: let the browser learn about the policy enforcement = elements through DHCP, it may communicate them to the server. This has = some problems. There are no widely adopted DHCP APIs, and the policy = enforcement elements may be unwilling to let some random web server = access them. >=20 > DNS magic: derive the address of your local policy enforcement element = by manipulating the result of a reverse DNS lookup of the global IP = address. >=20 > Manual configuration: Solves only the problem of missing DHCP APIs and = introduces the usability nightmare we know too well from SIP clients. >=20 > 3rd party auth: the user authenticates with a local idP, which not = only carries the user's name but also the local policy enforcement urls = as attributes. A web server can use the 3rd party auth token to access = the local network elements. Haven't thought this through yet. >=20 >=20 > Wolfgang Beck >=20 > -----Urspr=FCngliche Nachricht----- > Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im = Auftrag von Harald Alvestrand > Gesendet: Dienstag, 8. Oktober 2013 13:01 > An: rtcweb@ietf.org > Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 >=20 > On 10/08/2013 09:17 AM, Karl Stahl wrote: > > Hej Magnus, > > > >> Also, are you really interested in knowing that it is VP9 vs H.264, > >> isn't > > the questions this is video of this priority that is important? > >> I think you need to more carefully consider what are the goals you > >> try to > > achieve them. > > > > Actually, my concern is to get an idea of the maximum bandwidth that > > could be required for a WebRTC (ICE) setup media flow. Both voice = and > > video should be prioritized over data (their individual priority is = of > > less importance as long as there is sufficient bandwidth for both). >=20 > You don't know that without knowing what the application is for. > In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. >=20 > > > > With diffserv you don't need to know the bandwidth requirement, but > > with RSVP reservation (like in cable and mobile networks) you need = to > > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > > H.264 is like 3,5 mbps. >=20 > Again, without knowing the application, you don't know that. > The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is = completely different from that of a talking head, which is again = completely different from a high-movement scene. >=20 > > > > To add to the complication of codec variants, the video codecs in > > question for WebRTC have variable bandwidth, and when there is a = poor > > connection we see Chrome reducing the video window size to reduce = the bandwidth used... > > > > I think the payload type field at best can reflect a maximum = bandwidth > > to initially reserve bandwidth for, and thereafter make new > > reservations if the bandwidth changes during the call. So could we > > change RTP to show maximum bandwidth instead of payload type in that > > field outside the encrypted payload :) ... Or maybe that is not a = joke? >=20 > I think these ruminations only lead to one conclusion: >=20 > You can't tell what the needed bandwidth is up front without asking = the application. > You can't tell what the right priority ranking is without asking the = application. >=20 > If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. >=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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_EBB5264B-BAA8-4565-9F86-855A42024F86 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ted.ietf@gmail.com> = wrote:
On Thu, Oct 10, 2013 at 8:02 AM, = <BeckW@telekom.de> wrote:
The basic question seems to be: how can the web server or JS client = learn about local policy enforcement elements in the user's network and = access them to allocate bandwidth, setup priorisation etc?


So, I'm a little confused about why = that is the basic question.  If the prioritization is done by = something like a diffserv code point, it seems like the question is how = the flow signals its classification, rather than to whom it signals that = .  I would presume that the networks which honor such markings = would be constructed such that some conversant network element is on = path.  What it is and where it is kind of aren't the JS app or = browser's issue.

What am I = missing?

* = Several operating systems do not allow non-privileged applications to = set DSCP bits at all; Windows, for example.  Yes, I know everyone = is supposed to use any other OS, but Linux has also only allowed certain = DSCP values to be set.
* When joining a network, the DSCP = values for the network cannot be learned or discovered -- we lack a = protocol to do that.  The RFCs that define DSCP values are not = standards (they are informational) and many a network choose their own = values.  
* Setting the correct DSCP value affects only = outgoing traffic but has no influence on the incoming traffic.  As = you stated in a later post, incoming DSCP isn't trusted anyway. =  "Reflexive DSCP Policy" was attempted years ago to allow the = network to assume a host's DSCP settings could be applied to the other = direction, but it was rejected I believe during IETF review but I = couldn't find record why it was actually disposed (document = was draft-ietf-ieprep-reflexive-dscp).

-d



Ted

 
The ALTO WG had a very similar problem and proposed DHCP after DNS = experts dismissed a discovery mechanism based on reverse DNS = lookups.

The classical solution: avoid the problem by having a webrtc server in = your local network which does policy enforcement/QoS priorisation etc, = and interconnects to some other webrtc server with a standardized = protocol like SIP or XMPP. Popular in RTCWEB, less popular = elsewhere..

The DHCP way: let the browser learn about the policy enforcement = elements through DHCP, it may communicate them to the server. This has = some problems. There are no widely adopted DHCP APIs, and the policy = enforcement elements may be unwilling to let some random web server = access them.

DNS magic: derive the address of your local policy enforcement element = by manipulating the result of a reverse DNS lookup of the global IP = address.

Manual configuration: Solves only the problem of missing DHCP APIs and = introduces the usability nightmare we know too well from SIP = clients.

3rd party auth: the user authenticates with a local idP, which not only = carries the user's name but also the local policy enforcement urls as = attributes. A web server can use the 3rd party auth token to access the = local network elements. Haven't thought this through yet.


Wolfgang Beck

-----Urspr=FCngliche Nachricht-----
Von: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] Im = Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 13:01
An: rtcweb@ietf.org
Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On 10/08/2013 09:17 AM, Karl Stahl wrote:
> Hej Magnus,
>
>> Also, are you really interested in knowing that it is VP9 vs = H.264,
>> isn't
> the questions this is video of this priority that is important?
>> I think you need to more carefully consider what are the goals = you
>> try to
> achieve them.
>
> Actually, my concern is to get an idea of the maximum bandwidth = that
> could be required for a WebRTC (ICE) setup media flow. Both voice = and
> video should be prioritized over data (their individual priority is = of
> less importance as long as there is sufficient bandwidth for = both).

You don't know that without knowing what the application is for.
In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice = data.

>
> With diffserv you don't need to know the bandwidth requirement, = but
> with RSVP reservation (like in cable and mobile networks) you need = to
> know how much to reserve. Voice is like 100's kbit/s, video VP8 = or
> H.264 is like 3,5 mbps.

Again, without knowing the application, you don't know that.
The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is = completely different from that of a talking head, which is again = completely different from a high-movement scene.

>
> To add to the complication of codec variants, the video codecs = in
> question for WebRTC have variable bandwidth, and when there is a = poor
> connection we see Chrome reducing the video window size to reduce = the bandwidth used...
>
> I think the payload type field at best can reflect a maximum = bandwidth
> to initially reserve bandwidth for, and thereafter make new
> reservations if the bandwidth changes during the call. So could = we
> change RTP to show maximum bandwidth instead of payload type in = that
> field outside the encrypted payload :) ... Or maybe that is not a = joke?

I think these ruminations only lead to one conclusion:

You can't tell what the needed bandwidth is up front without asking the = application.
You can't tell what the right priority ranking is without asking the = application.

If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics.

_______________________________________________
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.or= g/mailman/listinfo/rtcweb

= --Apple-Mail=_EBB5264B-BAA8-4565-9F86-855A42024F86-- From richard.ejzak@alcatel-lucent.com Sun Oct 13 16:00:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D4D11E812F; Sun, 13 Oct 2013 16:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzogSgXQi7S1; Sun, 13 Oct 2013 16:00:16 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D2B4611E80EE; Sun, 13 Oct 2013 16:00:13 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9DN0Bsc028960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Oct 2013 18:00:11 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9DN0AHG030789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Oct 2013 19:00:10 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Sun, 13 Oct 2013 19:00:10 -0400 From: "Ejzak, Richard P (Richard)" To: DISPATCH , "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [dispatch] [MMUSIC] [rtcweb] FW: New Version Notification for draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt Thread-Index: AQHOyGf3HKB+ufbKaUuqcHLlUeseLg== Date: Sun, 13 Oct 2013 23:00:09 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86A163@US70UWXCHMBA04.zam.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [rtcweb] [dispatch] [MMUSIC] FW: New Version Notification for draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 23:00:22 -0000 UGxlYXNlIG5vdGUgdGhlIHN1Ym1pc3Npb24gb2YgZHJhZnQtZWp6YWstZGlzcGF0Y2gtd2VicnRj LWRhdGEtY2hhbm5lbC1zZHBuZWcuICBJdCBkZXNjcmliZXMgRGF0YUNoYW5uZWwgZXh0ZXJuYWwg bmVnb3RpYXRpb24gcHJvY2VkdXJlcyBiYXNlZCBvbiBTRFAgdG8gc2V0IHVwIERhdGFDaGFubmVs IHRyYW5zcG9ydCBmb3Igd2VsbC1rbm93biBzdWItcHJvdG9jb2xzIGxpa2UgTVNSUCwgQkZDUCwg VDE0MCwgVDM4LCBhbmQgcG9zc2libHkgdGhlIENMVUUgY29udHJvbCBwcm90b2NvbC4gIEl0IG1h a2VzIG5vIGFkZGl0aW9uYWwgZGVtYW5kcyBvbiB0aGUgRGF0YUNoYW5uZWwgZGVzaWduLCBhbHRo b3VnaCB0aGUgZG9jdW1lbnQgcmFpc2VzIG9uZSBzbWFsbCBpc3N1ZSBhbmQgc3VnZ2VzdHMgc29t ZSBjbGFyaWZpY2F0aW9ucyBpbiBleGlzdGluZyBEYXRhQ2hhbm5lbCBkb2N1bWVudHMuIFBsZWFz ZSBleHBlY3Qgb25lIG1vcmUgZG9jdW1lbnQgc29vbiB0aGF0IGRlc2NyaWJlcyB0aGUgYXBwbGlj YXRpb24gb2YgdGhlIGRyYWZ0IHRvIG5lZ290aWF0aW9uIG9mIERhdGFDaGFubmVsIHRyYW5zcG9y dCBmb3IgTVNSUC4NCg0KUmljaGFyZCBFanphaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgT2N0b2JlciAxMywgMjAxMyA1OjQ1IFBNDQpUbzog RWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCk7IE1BUkNPTiwgSkVST01FIChKRVJPTUUpDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWVqemFrLWRpc3BhdGNoLXdl YnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1lanphay1kaXNwYXRjaC13ZWJydGMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmljaGFyZCBFanphayBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZWp6YWstZGlz cGF0Y2gtd2VicnRjLWRhdGEtY2hhbm5lbC1zZHBuZWcNClJldmlzaW9uOgkgMDANClRpdGxlOgkJ IFNEUC1iYXNlZCBXZWJSVEMgZGF0YSBjaGFubmVsIG5lZ290aWF0aW9uDQpDcmVhdGlvbiBkYXRl OgkgMjAxMy0xMC0xNA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDE0DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnDQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVqemFrLWRpc3BhdGNoLXdl YnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgUmVhbC1U aW1lIENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzIChSVENXZWIpIHdvcmtpbmcgZ3JvdXAg aXMNCiAgIGNoYXJnZWQgdG8gcHJvdmlkZSBwcm90b2NvbHMgdG8gc3VwcG9ydCBkaXJlY3QgaW50 ZXJhY3RpdmUgcmljaA0KICAgY29tbXVuaWNhdGlvbiB1c2luZyBhdWRpbywgdmlkZW8sIGFuZCBk YXRhIGJldHdlZW4gdHdvIHBlZXJzJyB3ZWItDQogICBicm93c2Vycy4gIEZvciB0aGUgc3VwcG9y dCBvZiBkYXRhIGNvbW11bmljYXRpb24sIHRoZSBSVENXZWIgd29ya2luZw0KICAgZ3JvdXAgaGFz IGluIHBhcnRpY3VsYXIgZGVmaW5lZCB0aGUgY29uY2VwdCBvZiBiaS1kaXJlY3Rpb25hbCBkYXRh DQogICBjaGFubmVscyBvdmVyIFNDVFAsIHdoZXJlIGVhY2ggZGF0YSBjaGFubmVsIG1pZ2h0IGJl IHVzZWQgdG8NCiAgIHRyYW5zcG9ydCBvdGhlciBwcm90b2NvbHMsIGNhbGxlZCBzdWItcHJvdG9j b2xzLiAgRGF0YSBjaGFubmVsIHNldHVwDQogICBjYW4gYmUgZG9uZSB1c2luZyBlaXRoZXIgdGhl IGluLWJhbmQgV2ViUlRDIERhdGEgQ2hhbm5lbCBwcm90b2NvbCBvcg0KICAgc29tZSBleHRlcm5h bCAoaW4tYmFuZCBvciBvdXQtb2YtYmFuZCkgbmVnb3RpYXRpb24uICBUaGlzIGRvY3VtZW50DQog ICBzcGVjaWZpZXMgaG93IHRoZSBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGNhbiBiZSB1c2Vk IHRvIGFjaGlldmUNCiAgIHN1Y2ggYW4gZXh0ZXJuYWwgbmVnb3RpYXRpb24uDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From internet-drafts@ietf.org Mon Oct 14 02:33:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0E21E8169; Mon, 14 Oct 2013 02:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu5IGRO7Zkuz; Mon, 14 Oct 2013 02:33:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A0A21E816A; Mon, 14 Oct 2013 02:29:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014092909.21176.66104.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 02:29:09 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-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, 14 Oct 2013 09:33:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-12.txt Pages : 28 Date : 2013-10-14 Abstract: This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from use-cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requiremen= ts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and-requirem= ents-12 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 christer.holmberg@ericsson.com Mon Oct 14 02:40:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EFA21E817C for ; Mon, 14 Oct 2013 02:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRVEpAQeEDK0 for ; Mon, 14 Oct 2013 02:40:27 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B608021E818B for ; Mon, 14 Oct 2013 02:36:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-8d-525bbb00b9a4 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 98.79.16099.00BBB525; Mon, 14 Oct 2013 11:36:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 11:36:00 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented Thread-Index: Ac7IvINFDjps6xe1Q0+JPDy99cM+7A== Date: Mon, 14 Oct 2013 09:35:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvrS7j7uggg7kvuC06JrNZrP3Xzm7R ONfOgdljyu+NrB47Z91l91iy5CdTAHMUl01Kak5mWWqRvl0CV8amE68ZCxb3MFZ0LX/D1MB4 PaeLkZNDQsBEYs/pFUwQtpjEhXvr2UBsIYHDjBIbt1p2MXIB2UsYJc6fvsPaxcjBwSZgIdH9 TxukRkRAXeLywwvsIDXMAqsZJX4/n8QKkhAWyJRofbiZHaIoT+LFvK/MELaexPQZR1lAbBYB VYnnj1eDLeYV8JW4fOkEWD0j0BHfT60BizMLiEvcejIf6jgBiSV7zjND2KISLx//A7tHQkBR Ynm/HES5jsSC3Z/YIGxtiWULXzNDjBeUODnzCcsERpFZSKbOQtIyC0nLLCQtCxhZVjGy5yZm 5qSXG25iBMbAwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MTqzs9cEBzUznYp6qbM+o8t625M0Plf0VjKF3MqL+fdcJsLM2v73nn/Bk/9T1L14HCDVZ st79tzaN0c6raffFl/wLL+2LOyS8drvEfse1AsG5C65banJLXGm14JFVE384i8/g+iNzlbrv Fe+39U7w+PhSa7PrwotVfqdUOO/kJV/r/S1wKXOuEktxRqKhFnNRcSIApSRqjE8CAAA= Cc: "Cullen Jennings \(fluffy@cisco.com\)" Subject: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 09:40:38 -0000 Hi, I have submitted a new version (-12) of the use-case-requirements draft. Th= e draft implements the changes due to the WGLC comments. Below is an e-mail which describes the changes (indicated by the "V-12" pre= fix), based on the comments that Magnus gave (also taking into consideratio= n the comments given by Bernard A and Andrew H). NOTE: Based on the comments, some text has been removed (as indicated below= ), so I ask people to take a look at the draft. Regards, Christer ----------------------------------------- > 1. First of all I like to bring up a document structure problem. When rev= iewing this it is difficult to follow what requirements that are added for = the=20 > different use cases. I would propose that each Use Case or general sectio= n that describe something that causes new requirements that hasn't=20 > been listed yet in the document to define the Requirement there. Somethin= g like this: > > 3.2.2.1. Description > > This use-case is almost identical to the Simple Video Communication > Service use-case (Section 3.2.1). The difference is that one of the > users is behind a NAT that blocks UDP traffic. > > 3.2.2.2. Derived Requirements > > F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28 > > A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 > > New Requirement: > > F29 The browser must be able to send streams and > data to a peer in the presence of NATs that > block UDP traffic. > > This makes the incremental use cases much more understandable in how they= add requirements. > > This I think will also affect Section 3.1 which will need to include the = requirement definitions created by these general considerations. > > However, I do suggest that you leave the collection of all requirements i= n place for easy reference. V-12: I now define the requirements retrieved from the "Simple Video Commun= ication Service" use-case as common. Then, for each additional use-case, I = only list the additional requirement(s) retrieved from that use-case. ---------------------------------------------------------------- > 2. Section 1: > > The document focuses on requirements related to real-time media > streams and data exchange. Requirements related to privacy, > signalling between the browser and web server etc. are currently not > considered. > > I think this needs to be rewritten. The draft actually do consider a numb= er of high level security and privacy concerns. V-12: Paragraph removed, as suggested by Bernard A. ---------------------------------------------------------------- > 3. Section 2: > > If you have no definitions, do remove the section, rather then leaving it= TBD. V-12: Section removed. ---------------------------------------------------------------- > 4. Section 3.1 > > o Clients can be on wideband (10s of Mbits/sec) > > o Clients can be on narrowband (10s to 100s of Kbits/sec) > > Due to the usage of the terms wideband and narrowband I think you need to= be more explicit about what is actually referred to here. My assumption is= network throughput capability. And in these cases maybe expressing this ex= plicitly is a better choice. V-12: The bullets above are removed, and replaced with a bullet saying: "Cl= ients can be connected to networks with different throughput capabilities". ---------------------------------------------------------------- > 5. Section 3.1: > > o Clients can be on networks with any type (as described in RFC4787) = of NAT. > > I think "any type" is unclear here, as there are no types defined in that= RFC unless you are trying to express the difference between basic NAT and = NAPT, which I don't believe you are. I think you should use something like = this: > > o Clients can be on networks with a NAT using any type of Mapping and= Filtering behaviors (as described in RFC4787). V-12: The bullet above is modified as suggested. ---------------------------------------------------------------- > 6. Section 3.2.1.1: > > It is essential that the communication cannot be wiretapped [RFC2804]. > > This sentence returns a number of times in this document. I think it is a= general security requirement that applies to probably all of the use cases= . If there is one use case that don't need to enable protection against thi= s, then please be explicit about that. > > My Suggestion is to move this into the general considerations section. V-12: The sentence is removed from sections 3.2.11, 3.2.11.1, 3.2.12.1, 3.2= .13.1, 3.3.1.1 and 3.3.3.1. No new requirement is needed, as it is already = covered by requirement F20. ---------------------------------------------------------------- > 7. Section 3.2.1.1: > > In addition, it is required that browsers enable the media and data > security keys to be cryptographically bound to the user identity. > > I think this sentence is actually subtly wrong in a couple of ways. > First of all it talks about "the identity", where I think it should be ta= lking about "a identity". This can both the human users identity, but also = a role identity, like Police Officer. > > Secondly, binding it to the security keys without putting requirements o= n the keying and key-exchange mechanism to prevent man in the middles empti= es this=20 > requirement. I would recommend that you reformulate this to a high level = requirement without going into mechanism. For example: > > In addition, it is required that browsers enables binding an identity of = the user's choice to his end of the secured communication and that=20 > such mechanism prevent man in the middle attacks. V-12: The sentence is removed, as it is covered by requirement F36. ---------------------------------------------------------------- > 8. Section 3.2.1.1 > > One user has an unreliable Internet connection. It sometimes loses > packets, and sometimes goes down completely. > > I guess the requirement here is to handle this in a graceful way from med= ia transport and rendering perspective. The packet loss is also unclear as = I don't know if=20 > the intention is to capture spurious packet losses due to the link media,= or congestion losses. I think some expansion of this is needed. V-12: Sentence removed. Covered by requirement F5. ---------------------------------------------------------------- > 9. Section 3.2.1.1: > > One user is located behind a Network Address Translator (NAT). > > What is the point being stressed here that isn't covered by the general c= onsideration in 3.1 that says: > > o Clients can be on networks with any type (as described in RFC4787) o= f NAT. V-12: The sentence is removed. ---------------------------------------------------------------- > Section 3.2.2.2: > > 3.2.2.2. Derived Requirements > > F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F29 > > A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12 > > > How come this list of Derived Requirements are shorter than for the paren= t use case which has the following list: > > 3.2.1.2. Derived Requirements > > F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39 > > A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26 > > > If each use case is listing all the requirement then it needs to be consi= stently done and actually list all that applies. If there are requirements = from the parent that doesn't apply that may even be worth explicitly mentio= ning. > > This comments applies to all use cases as there appears to be general inc= onsistencies. V-12: As indicated earlier, I now define the requirements retrieved from th= e "Simple Video Communication Service" use-case as common. Then, for each a= dditional use-case, I only list the additional requirement(s) retrieved fro= m that use-case. ---------------------------------------------------------------- > 10. Section 3.2.3.1: > > > 3.2.3.1. Description > > This use-case is almost identical to the Simple Video Communication > Service use-case (Section 3.2.1). The difference is that one of the > users is behind a FW that only allows http traffic. > > If a firewall only allows HTTP traffic, then can we really assume that th= e firewall administrator per default will accept WebRTC Media and Data traf= fic? > > I am far from certain of this, and think on a requirement level needs to = express a situation where the firewall administrator allows WebRTC across i= ts FW, or at least can easily configure a rule to block it. Thus resulting = in that any solution for this needs to be easily identifiable and possible = to block. > > See also PNTAW@ietf.org mailing list. V-12: The sentence starting with "The difference..." is replaced by "The di= fference is that one of the users is behind a FW that only allows traffic v= ia a HTTP Proxy.", as suggested by Andrew H. Requirement F37 is modified to: "The browser must be able to send streams and data to a peer in the presence of FWs that onl= y allows traffic via a HTTP Proxy." ---------------------------------------------------------------- >11. Section 3.2.8.1: > > But in addition to this, one of the users can share what is being > displayed on her/his screen with a peer. The user can choose to > share the entire screen, part of the screen (part selected by the > user) or what a selected applicaton displays with the peer. > > Does this needs mentioning of additional high level security requirements= ? = =20 V-12: No change was done based on this comment. ---------------------------------------------------------------- > 12. Section 3.2.10.1: > > The service providers are interconnected by some means, but exchange > no more information about the users than what can be carried using > SIP. > > NOTE: More profiling of what this means may be needed. > > The Note, can it be removed, or do we need additional text in this docume= nt? V-12: Note removed. ---------------------------------------------------------------- > 13. Section 3.2.10.1: > > The same issues with connectivity apply. > > I don't understand this comment. What is it intended to refer to? V-12: Section removed. As indicated by Bernard A, the note indicates that t= he purpose of the section is unclear. Requirements not affected. ---------------------------------------------------------------- > 14. Section 3.2.11.1: > > Before the game starts, and during game breaks, the talent scout and > the manager have a 1-1 audiovisual communication session. Only the > rear facing camera of the mobile phone is used. On the display of > the mobile phone, the video of the club manager is shown with a > picture-in-picture thumbnail of the rear facing camera (self-view). > On the display of the desktop, the video of the talent scout is shown > with a picture-in-picture thumbnail of the desktop camera (self- > view). > > I get a bit confused with what is the front and rear of my smart phone. > I would consider the display side the front side, and the rear the other = big side of my block shaped mobile phone. I suggest using other terms. V-12: Text is modified to: "Before the game starts, and during game breaks, the talent scout and the manager have a 1-1 audiovisual communication session. On the mobile p= hone, only the camera facing the talent scout is used. On the user display of the mobile phone, the video of the club manager is shown with a picture-in-picture thumbnail of the rear facing camera (self-view). On the display of the desktop, the video of the talent scout is shown with a picture-in-picture thumbnail of the desktop camera (self-view)." ---------------------------------------------------------------- > 15. Section 3.2.14.1: > > Discussion: This use-case was briefly discussed at the Quebec webrtc > meeting and it got support. So far the only concrete requirement > (A17) derived is that the application must be able to ask the browser > to treat the audio signal as audio (in contrast to speech). However, > the use case should be further analysed to determine other > requirements (could be e.g. on delay mic->speaker, level control of > audio signals, etc.). > > I think this Discussion points needs to be dealt with before we can publi= sh this document. I would consider the question if this needs more analysis= a open issue. V-12: Section removed. Requirements not affected. ---------------------------------------------------------------- > 16. Section 3.3.2.1: > > Alice uses her web browser with a service that allows her to call > PSTN numbers. Alice calls 1-800-gofedex. Alice should be able to > hear the initial prompts from the fedex IVR and when the IVR says > press 1, there should be a way for Alice to navigate the IVR. > > Can you please expand IVR. V-12: Added "Interactive Voice Responder (IVR)" on first occurrence. ---------------------------------------------------------------- > 17. Section 3.3.3.1: > > The organization has an internal network set up with an aggressive > firewall handling access to the Internet. If users cannot physically > access the internal network, they can establish a Virtual Private > Network (VPN). > > I think the requirements or limitations the above paragraph try to expres= s is not clear. There is some missing assumptions of location of server rel= ated to clients that is not covered. Thus it is not clear what requirements= this results in. > > Can you please expand this to something that is understandable. V-12: Paragraph removed. ---------------------------------------------------------------- > 18. Section 3.3.3.1: > > This use-case adds requirements on support for fast stream > switches F7, on encryption of media and on ability to traverse very > restrictive FWs. > > Regarding the restricted FWs, my comment 10) applies to also this comment= . V-12: No change done in section 3.3.3.1. Covered by the change done based o= n comment 10). ---------------------------------------------------------------- > 19. Section 4.2: > > F14 The browser must be able to measure the level > > F15 The browser must be able to change the level > in audio streams. > > Can you please make explicit what type level you think should be measured= or changed, energy, "voice activity"? V-12: "level" replaced with "voice activity level". ---------------------------------------------------------------- > 20. Section 4.2 > > F19 Streams and data must be able to pass through limited middleboxe= s. > > What type of limitations are you considering in this requirement? V-12: Requirement removed. Can only think of firewall traversal, which are = covered by requirement F37. "F19 Streams and data must be able to pass thr= ough limited middleboxes." ---------------------------------------------------------------- > 21. Section 4.2 > > I note that F30, and F36 may be affected by earlier comments on the under= lying reason for these requirements and need additional text or clarificati= ons. V-12: No need for changes were identified. ---------------------------------------------------------------- > 22. Section 4.2: > F37 The browser must be able to send streams and > data to a peer in the presence of FWs that only > allows http(s) traffic. > > I think this requirement should have a caveat along the lines: when FW po= licy allows WebRTC traffic. V-12: Caveat added. "The browser must be able to send streams and data to a peer in the presence of FWs that onl= y allows traffic via a HTTP Proxy, when FW polic= y=20 allows WebRTC traffic." ---------------------------------------------------------------- > 23. Section 5: > > Change the TBD to a statement that there are no IANA actions in this docu= ment. V-12: Done. ---------------------------------------------------------------- > 24. Section 6.2: > > These security considerations are really security requirements on the bro= wser or the API. I don't know if would be better to move them to relevant u= se case sections, or leave them in place. V-12: No changes based on this comment. ---------------------------------------------------------------- > 25. Section 7: > > 13. Enable company coop without being able to decipher http:// > www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html > > What is "coop" in the above? V-12: I have no idea. Use-case removed. http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html ---------------------------------------------------------------- > 26. Please run a spell checker on the document prior to submitting the up= date. V-12: Done. ---------------------------------------------------------------- > 27. Ensure that the ID nits issues are not real issues: > > =3D=3D Line 667 has weird spacing: '...resence of NA...' > > =3D=3D Line 785 has weird spacing: '...of that strea...' V-12: Done. ---------------------------------------------------------------- Regards, Christer From christer.holmberg@ericsson.com Mon Oct 14 04:39:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2E21F9AA1 for ; Mon, 14 Oct 2013 04:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.768 X-Spam-Level: X-Spam-Status: No, score=-5.768 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6ZjTyqZ2ejJ for ; Mon, 14 Oct 2013 04:39:48 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7421F9C38 for ; Mon, 14 Oct 2013 04:39:44 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-05-525bd7ff439c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 62.5C.16099.FF7DB525; Mon, 14 Oct 2013 13:39:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 13:39:43 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05 Thread-Index: Ac7I0di3UBEoQZRvT4uPzavUAWT7pA== Date: Mon, 14 Oct 2013 11:39:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BDFB0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/mixed; boundary="_004_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3Vvf/9egggyWfBCx6Py5htFj7r53d gcljyZKfTB5H5+1nDWCK4rJJSc3JLEst0rdL4Mpo6uhiLlhtXPH14RuWBsYjul2MnBwSAiYS j49uZ4KwxSQu3FvP1sXIxSEkcJhRYs+3k+wQzhJGiR9vjrN0MXJwsAlYSHT/0wZpEBGIkJi2 Zwk7iC0sECZx+d4fFoh4uMSy2ROZIWw9iW8ru9lBWlkEVCUeT5UCCfMK+Eps3/SPEcRmBNr7 /dQasBuYBcQlbj2ZD3WPiMTDi6fZIGxRiZeP/7GCjJEQUJRY3i8HUZ4psWDJQTaIkYISJ2c+ YZnAKDQLyaRZSMpmISmDiOdLzJ9+mRHC1pFYsPsTG4StLbFs4WtmGPvMgcdMmOK6EkfOH2OH sBUl2rY3A/VyAdkrGCWezWxmhUhYSzzcM4UNpmhK90P2BYy8qxjZcxMzc9LLDTcxAiPz4Jbf ujsYT50TOcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGjI6sViPtd6cZ Y54U7TbftEYuzf1L+yHruQF8NjP+MckuKNyetOlA+r1jp1ekfX+368e14tlC+kotu6TitsXU yGy44xPRk17w+f+K0B1nvNjP+z0P6j8RqCyosGP/5SmtG8+0nZKaviE2SMkkw7Lt19kXE42l BP6FfTNpbqsp/LlQJLFDKWyGEktxRqKhFnNRcSIA4q/02poCAAA= Subject: [rtcweb] FW: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:39:53 -0000 --_004_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_ Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_" --_000_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, In order to avoid cross-posting, if you have any comments or questions on t= he BUNDLE draft, please present them on the MMUSIC list. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 14. lokakuuta 2013 14:37 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiati= on-05 Hi, I've submitted a new version of the BUNDLE draft. I have implemented the modified text for the Offerer and Answerer procedure= s, as presented on the list in September. The procedures now also mention the usage of the SDP 'bundle-only' attribut= e. However, the attribute definition itself has yet not been added to the d= raft, as we still haven't solved the issue regarding usage of port zero. In addition, there are some reference corrections, and the FQDN values in t= he examples are now according to RFC 2606. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

In order to avoid cros= s-posting, if you have any comments or questions on the BUNDLE draft, pleas= e present them on the MMUSIC list.

 

Regards,

 

Christer

 

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 14. lokakuuta 2013 14:37
To: mmusic@ietf.org
Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-ne= gotiation-05

 

Hi,

 

I’ve submitted a new version of the BUNDLE dra= ft.

 

I have implemented the modified text for the Offerer= and Answerer procedures, as presented on the list in September.=

 

The procedures now also mention the usage of the SDP= ‘bundle-only’ attribute. However, the attribute definition its= elf has yet not been added to the draft, as we still haven’t solved t= he issue regarding usage of port zero.

 

In addition, there are some reference corrections, a= nd the FQDN values in the examples are now according to RFC 2606.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_-- --_004_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Mon, 14 Oct 2013 11:37:43 GMT"; modification-date="Mon, 14 Oct 2013 11:37:43 GMT" Content-ID: <9FB25AF1D7B5E84383BD2B80D12A04C2@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7594FB04B1934943A5C02806D1A2204B1C4BDFB0ESESSMB209erics_-- From uwe.rauschenbach@nsn.com Mon Oct 14 05:53:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265EB11E817E for ; Mon, 14 Oct 2013 05:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChExZhHCaGZW for ; Mon, 14 Oct 2013 05:53:04 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C031621E8170 for ; Mon, 14 Oct 2013 05:52:45 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9ECqgCn024915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2013 14:52:42 +0200 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 r9ECqg2N003303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 14:52:42 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.164]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 14:52:41 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented Thread-Index: Ac7IvINFDjps6xe1Q0+JPDy99cM+7AAHt7EA Date: Mon, 14 Oct 2013 12:52:41 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF811F599@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] 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: 2240 X-purgate-ID: 151667::1381755162-00004A43-77A9DCE9/0-0/0-0 Subject: Re: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:53:09 -0000 Hi Christer, A nit: shouldn't the two requirements below mention "receive" as well? =A0 Kind regards, Uwe =20 > ---------------------------------------------------------------- >=20 >=20 > > 10. Section 3.2.3.1: > > > > > > 3.2.3.1. Description > > > > This use-case is almost identical to the Simple Video Communication > > Service use-case (Section 3.2.1). The difference is that one of the > > users is behind a FW that only allows http traffic. > > > > If a firewall only allows HTTP traffic, then can we really assume that > the firewall administrator per default will accept WebRTC Media and Data > traffic? > > > > I am far from certain of this, and think on a requirement level needs > to express a situation where the firewall administrator allows WebRTC > across its FW, or at least can easily configure a rule to block it. Thus > resulting in that any solution for this needs to be easily identifiable > and possible to block. > > > > See also PNTAW@ietf.org mailing list. >=20 > V-12: The sentence starting with "The difference..." is replaced by "The > difference is that one of the users is behind a FW that only allows > traffic via a HTTP Proxy.", as suggested by Andrew H. >=20 > Requirement F37 is modified to: >=20 > "The browser must be able to send streams and > data to a peer in the presence of FWs that only > allows traffic via a HTTP Proxy." [skipping ...] > ---------------------------------------------------------------- >=20 >=20 > > 22. Section 4.2: > > F37 The browser must be able to send streams and > > data to a peer in the presence of FWs that only > > allows http(s) traffic. > > > > I think this requirement should have a caveat along the lines: when FW > policy allows WebRTC traffic. >=20 > V-12: Caveat added. >=20 > "The browser must be able to send streams > and > data to a peer in the presence of FWs that > only > allows traffic via a HTTP Proxy, when FW > policy > allows WebRTC traffic." >=20 >=20 From christer.holmberg@ericsson.com Mon Oct 14 05:58:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D3C11E817E for ; Mon, 14 Oct 2013 05:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.968 X-Spam-Level: X-Spam-Status: No, score=-3.968 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZXOZ-0qdPbN for ; Mon, 14 Oct 2013 05:58:47 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E5CDD21E8093 for ; Mon, 14 Oct 2013 05:58:43 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-b4-525bea8203b0 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 66.C8.25272.28AEB525; Mon, 14 Oct 2013 14:58:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 14:58:42 +0200 From: Christer Holmberg To: "Rauschenbach, Uwe (NSN - DE/Munich)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented Thread-Index: Ac7IvINFDjps6xe1Q0+JPDy99cM+7AAHt7EAAABqxIA= Date: Mon, 14 Oct 2013 12:58:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BE09C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF811F599@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF811F599@DEMUMBX005.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrW7Tq+ggg59b1C3W/mtnt7h7eA6z A5PHkiU/mTx+rr/KHsAUxWWTkpqTWZZapG+XwJWxqekQa8EE0YrJ31vZGhjX83cxcnJICJhI fH39mxHCFpO4cG89WxcjF4eQwFFGiY0HJjFBOEsYJZqedjF3MXJwsAlYSHT/0wZpEBHIluh/ upAJxBYWKJNY2TyVCaRERKBc4vVbQ4gSK4lJk9tZQGwWAVWJbffuM4PYvAK+Eo9eXmGEGD+R UWJz+zt2kASngJ/E9P99YEWMQAd9P7UGbD6zgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WkL0S AooSy/vlIMr1JG5MncIGYWtLLFv4GmqvoMTJmU9YJjCKzkIydRaSlllIWmYhaVnAyLKKkaM4 tTgpN93IYBMjMBYObvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamB0+7HiRWj0acb1cyd/btVWsCwS1m2LbdQXFPp87HC017zDjsKiLrv/dvf3v3d/LCO0 Q7x3nsEVtUMH2XJreu5d5VzS/W9m3YROwQ1KfEXfbr5fHmXfvX7Ca5az5ZvP++25rSYof3T5 1sP1HbJVqy5o7G5v+nfmVdP1O4ZxllpRSttrN5cEfWdVYinOSDTUYi4qTgQAcVzxf1MCAAA= Subject: Re: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:58:53 -0000 Hi Uwe, I guess you are right. I'll fix that in the next version. Thanks! Regards, Christer -----Original Message----- From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:uwe.rauschenbach@nsn.com]= =20 Sent: 14. lokakuuta 2013 15:53 To: Christer Holmberg; rtcweb@ietf.org Subject: RE: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-re= quirements-12 - WGLC comments implemented Hi Christer, A nit: shouldn't the two requirements below mention "receive" as well? =A0 Kind regards, Uwe =20 > ---------------------------------------------------------------- >=20 >=20 > > 10. Section 3.2.3.1: > > > > > > 3.2.3.1. Description > > > > This use-case is almost identical to the Simple Video Communication > > Service use-case (Section 3.2.1). The difference is that one of the > > users is behind a FW that only allows http traffic. > > > > If a firewall only allows HTTP traffic, then can we really assume=20 > > that > the firewall administrator per default will accept WebRTC Media and=20 > Data traffic? > > > > I am far from certain of this, and think on a requirement level=20 > > needs > to express a situation where the firewall administrator allows WebRTC=20 > across its FW, or at least can easily configure a rule to block it.=20 > Thus resulting in that any solution for this needs to be easily=20 > identifiable and possible to block. > > > > See also PNTAW@ietf.org mailing list. >=20 > V-12: The sentence starting with "The difference..." is replaced by=20 > "The difference is that one of the users is behind a FW that only=20 > allows traffic via a HTTP Proxy.", as suggested by Andrew H. >=20 > Requirement F37 is modified to: >=20 > "The browser must be able to send streams and > data to a peer in the presence of FWs that only > allows traffic via a HTTP Proxy." [skipping ...] > ---------------------------------------------------------------- >=20 >=20 > > 22. Section 4.2: > > F37 The browser must be able to send streams and > > data to a peer in the presence of FWs that only > > allows http(s) traffic. > > > > I think this requirement should have a caveat along the lines: when=20 > > FW > policy allows WebRTC traffic. >=20 > V-12: Caveat added. >=20 > "The browser must be able to send streams=20 > and > data to a peer in the presence of FWs=20 > that only > allows traffic via a HTTP Proxy, when FW=20 > policy > allows WebRTC traffic." >=20 >=20 From harald@alvestrand.no Mon Oct 14 07:11:06 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E4821E8082 for ; Mon, 14 Oct 2013 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+NE0lvFJ2OZ for ; Mon, 14 Oct 2013 07:11:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFBE21E80C4 for ; Mon, 14 Oct 2013 07:10:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0AE2C39E371 for ; Mon, 14 Oct 2013 16:10:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZaSecimLdUI for ; Mon, 14 Oct 2013 16:10:56 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6200239E10F for ; Mon, 14 Oct 2013 16:10:56 +0200 (CEST) Message-ID: <525BFB6F.5080403@alvestrand.no> Date: Mon, 14 Oct 2013 16:10:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:11:06 -0000 I've read the H.264 Constrained Baseline proposal. It contains no information that hasn't been presented to the list long ago; all but the performance evaluations were presented in Florida. I've written the VP8 proposal. It contains new information, but only in the form of pointing out that VP8 is more widely deployed, closer to being an ISO standard, and working better than when we discussed this in Florida. It is also being universally deployed in existing WebRTC implementations (Mozilla and Chrome). We know that for most participants, the IPR issue is the only real issue. So far, I haven't seen any of the people who were saying "we want to ship products but can't possibly use H.264" saying that they have changed their minds. Yet the chairs are proposing the following 2-hour agenda: Frame discussions and process and agenda: 10 min (chairs) VP8 presentation with clarify questions - 25 min (???) H.264 presentation with clarify questions - 25 min (???) Microphone discussions of pro/cons - 40 min (all) Call the question - 10 min ( chairs ) Wrap up and next steps - 10 min (chairs) Celebrate on our successful decision reach. Don't we have ways in which we can make better use of 2 hours? From mary.ietf.barnes@gmail.com Mon Oct 14 07:22:54 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A42811E813A for ; Mon, 14 Oct 2013 07:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.611 X-Spam-Level: X-Spam-Status: No, score=-101.611 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYoZCsTbhwsm for ; Mon, 14 Oct 2013 07:22:54 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id B75DA11E8144 for ; Mon, 14 Oct 2013 07:22:51 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id d4so5115000qej.7 for ; Mon, 14 Oct 2013 07:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1T4ELfh/h8kILYTlf50sUbDFNld76T3am8UBSu1gZYM=; b=nYyZiHIMBgyc/GvqQ6VC4KVqSSPN6Nv3u6w+sQcnADEkJWJ0OR/7Z5Ah0SERXV+0Bg oTF2iRA0gcBME9ocvZPS4x/ILcOICOtbXeVl6VNFDdd8f0mJpZs4O0SnOgt4+GQOpaCa W40EBIdh/D1xVFSTI9Frfaz987Wir97R6M1k5CxuPBSFV+Q4ftk1PxJnd8tT93S5Yt77 k4yt71J72LNA2BM+pXCqYE7DRHYM5bST2LjI+QlV75yZSlvmrLyP8muTO8Fc9qxmcekG J+g6xfYakOJ5niYtGGEsOZ4MmTv0o6S0yTs7RYJSrphraZwtX/NThz+AfRPWonZcMr9+ k80w== MIME-Version: 1.0 X-Received: by 10.49.17.98 with SMTP id n2mr12273244qed.61.1381760570895; Mon, 14 Oct 2013 07:22:50 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Mon, 14 Oct 2013 07:22:50 -0700 (PDT) In-Reply-To: <525BFB6F.5080403@alvestrand.no> References: <525BFB6F.5080403@alvestrand.no> Date: Mon, 14 Oct 2013 09:22:50 -0500 Message-ID: From: Mary Barnes To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7bea3f30fe4f1b04e8b4334a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:22:54 -0000 --047d7bea3f30fe4f1b04e8b4334a Content-Type: text/plain; charset=ISO-8859-1 I totally agree with the sentiment that the WG can make much better use of the 2 hours. We previously spent 2+ hours on this topic with no conclusion. Is the new information on VP8 enough to change anyone's opinion? Why not ask the questions that were proposed for this topic *now* on the mailing list? Regards, Mary. On Mon, Oct 14, 2013 at 9:10 AM, Harald Alvestrand wrote: > I've read the H.264 Constrained Baseline proposal. > > It contains no information that hasn't been presented to the list long > ago; all but the performance evaluations were presented in Florida. > > I've written the VP8 proposal. > It contains new information, but only in the form of pointing out that VP8 > is more widely deployed, closer to being an ISO standard, and working > better than when we discussed this in Florida. It is also being universally > deployed in existing WebRTC implementations (Mozilla and Chrome). > > We know that for most participants, the IPR issue is the only real issue. > So far, I haven't seen any of the people who were saying "we want to ship > products but can't possibly use H.264" saying that they have changed their > minds. > > Yet the chairs are proposing the following 2-hour agenda: > > Frame discussions and process and agenda: 10 min (chairs) > > VP8 presentation with clarify questions - 25 min (???) > > H.264 presentation with clarify questions - 25 min (???) > > Microphone discussions of pro/cons - 40 min (all) > > Call the question - 10 min ( chairs ) > > Wrap up and next steps - 10 min (chairs) > > Celebrate on our successful decision reach. > > > Don't we have ways in which we can make better use of 2 hours? > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --047d7bea3f30fe4f1b04e8b4334a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I totally agree with the sentiment that the WG can make mu= ch better use of the 2 hours. =A0We previously spent 2+ hours on this topic= with no conclusion. =A0Is the new information on VP8 enough to change anyo= ne's opinion? =A0Why not ask the questions that were proposed for this = topic *now* on the mailing list?=A0

Regards,
Mary.=A0


On Mon, Oct 14, 2013 at 9:10 AM, H= arald Alvestrand <harald@alvestrand.no> wrote:
I've read the H.264 Constrained Baseline= proposal.

It contains no information that hasn't been presented to the list long = ago; all but the performance evaluations were presented in Florida.

I've written the VP8 proposal.
It contains new information, but only in the form of pointing out that VP8 = is more widely deployed, closer to being an ISO standard, and working bette= r than when we discussed this in Florida. It is also being universally depl= oyed in existing WebRTC implementations (Mozilla and Chrome).

We know that for most participants, the IPR issue is the only real issue. S= o far, I haven't seen any of the people who were saying "we want t= o ship products but can't possibly use H.264" saying that they hav= e changed their minds.

Yet the chairs are proposing the following 2-hour agenda:

Frame discussions and process and agenda: 10 min (chairs)

VP8 presentation with clarify questions - =A025 min (???)

H.264 presentation with clarify questions - 25 min (???)

Microphone discussions of pro/cons - 40 min (all)

Call the question - 10 min ( chairs )

Wrap up and next steps - 10 min (chairs)

Celebrate on our successful decision reach.


Don't we have ways in which we can make better use of 2 hours?

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

--047d7bea3f30fe4f1b04e8b4334a-- From bernard_aboba@hotmail.com Mon Oct 14 07:34:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3321F9B35 for ; Mon, 14 Oct 2013 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.927 X-Spam-Level: X-Spam-Status: No, score=-100.927 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktJU+DxJDqE2 for ; Mon, 14 Oct 2013 07:34:41 -0700 (PDT) Received: from blu0-omc1-s20.blu0.hotmail.com (blu0-omc1-s20.blu0.hotmail.com [65.55.116.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7AF11E8147 for ; Mon, 14 Oct 2013 07:34:40 -0700 (PDT) Received: from BLU406-EAS58 ([65.55.116.7]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 07:34:41 -0700 X-TMN: [9B/lS6GdjwvF8IH2YIHrN8ao7pXiceFl] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_74173035-84b4-4a67-b1f3-0c986d4534c0_" References: <525BFB6F.5080403@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Mon, 14 Oct 2013 07:34:36 -0700 To: Mary Barnes X-OriginalArrivalTime: 14 Oct 2013 14:34:41.0261 (UTC) FILETIME=[849569D0:01CEC8EA] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 14:34:45 -0000 --_74173035-84b4-4a67-b1f3-0c986d4534c0_ Content-Type: multipart/alternative; boundary="Apple-Mail-1F5386F2-DA62-4EB5-9C5C-3E0CFB64622C" Content-Transfer-Encoding: 7bit --Apple-Mail-1F5386F2-DA62-4EB5-9C5C-3E0CFB64622C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. Allocating two hours is a colossal waste of time.=20 > On Oct 14, 2013, at 7:22 AM, "Mary Barnes" wr= ote: >=20 > I totally agree with the sentiment that the WG can make much better use of= the 2 hours. We previously spent 2+ hours on this topic with no conclusion= . Is the new information on VP8 enough to change anyone's opinion? Why not= ask the questions that were proposed for this topic *now* on the mailing li= st?=20 >=20 > Regards, > Mary.=20 >=20 >=20 >> On Mon, Oct 14, 2013 at 9:10 AM, Harald Alvestrand = wrote: >> I've read the H.264 Constrained Baseline proposal. >>=20 >> It contains no information that hasn't been presented to the list long ag= o; all but the performance evaluations were presented in Florida. >>=20 >> I've written the VP8 proposal. >> It contains new information, but only in the form of pointing out that VP= 8 is more widely deployed, closer to being an ISO standard, and working bett= er than when we discussed this in Florida. It is also being universally depl= oyed in existing WebRTC implementations (Mozilla and Chrome). >>=20 >> We know that for most participants, the IPR issue is the only real issue.= So far, I haven't seen any of the people who were saying "we want to ship p= roducts but can't possibly use H.264" saying that they have changed their mi= nds. >>=20 >> Yet the chairs are proposing the following 2-hour agenda: >>=20 >> Frame discussions and process and agenda: 10 min (chairs) >>=20 >> VP8 presentation with clarify questions - 25 min (???) >>=20 >> H.264 presentation with clarify questions - 25 min (???) >>=20 >> Microphone discussions of pro/cons - 40 min (all) >>=20 >> Call the question - 10 min ( chairs ) >>=20 >> Wrap up and next steps - 10 min (chairs) >>=20 >> Celebrate on our successful decision reach. >>=20 >>=20 >> Don't we have ways in which we can make better use of 2 hours? >>=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-1F5386F2-DA62-4EB5-9C5C-3E0CFB64622C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
+1. Allocating two hours is a colossal waste of time. 

On Oct 14, 2013, at 7:22 AM, "Mary Barnes" <mary.ietf.barnes@gmail.com> wrote:

I totally agree with the sentiment that the WG can make much better use of the 2 hours.  We previously spent 2+ hours on this topic with no conclusion.  Is the new information on VP8 enough to change anyone's opinion?  Why not ask the questions that were proposed for this topic *now* on the mailing list? 

Regards,
Mary. 


On Mon, Oct 14, 2013 at 9:10 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
I've read the H.264 Constrained Baseline proposal.

It contains no information that hasn't been presented to the list long ago; all but the performance evaluations were presented in Florida.

I've written the VP8 proposal.
It contains new information, but only in the form of pointing out that VP8 is more widely deployed, closer to being an ISO standard, and working better than when we discussed this in Florida. It is also being universally deployed in existing WebRTC implementations (Mozilla and Chrome).

We know that for most participants, the IPR issue is the only real issue. So far, I haven't seen any of the people who were saying "we want to ship products but can't possibly use H.264" saying that they have changed their minds.

Yet the chairs are proposing the following 2-hour agenda:

Frame discussions and process and agenda: 10 min (chairs)

VP8 presentation with clarify questions -  25 min (???)

H.264 presentation with clarify questions - 25 min (???)

Microphone discussions of pro/cons - 40 min (all)

Call the question - 10 min ( chairs )

Wrap up and next steps - 10 min (chairs)

Celebrate on our successful decision reach.


Don't we have ways in which we can make better use of 2 hours?

_______________________________________________
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
--Apple-Mail-1F5386F2-DA62-4EB5-9C5C-3E0CFB64622C-- --_74173035-84b4-4a67-b1f3-0c986d4534c0_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_74173035-84b4-4a67-b1f3-0c986d4534c0_-- From BeckW@telekom.de Mon Oct 14 08:04:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3921F93DB for ; Mon, 14 Oct 2013 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2Rc4I4UoY3i for ; Mon, 14 Oct 2013 08:04:27 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0F57221E817F for ; Mon, 14 Oct 2013 08:04:23 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 14 Oct 2013 17:04:21 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([169.254.4.164]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 14 Oct 2013 17:04:21 +0200 From: To: Date: Mon, 14 Oct 2013 17:04:12 +0200 Thread-Topic: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 Thread-Index: Ac7GqxmGvnLxLT89Qi2FJDAib3hLpgCDmo1A Message-ID: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:04:32 -0000 WPAD has already been discussed on this list as a way to discover local TUR= N servers. If we extend WPAD for TURN servers, we may extend it for other l= ocal information. WPAD never became an RfC so it could not be referenced in a RTCWEB document= . The success of WPAD shows that there is a need for such a functionality. Is it time to revive the 12 year old draft? Wolfgang Beck From cowwoc@bbs.darktech.org Mon Oct 14 10:57:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9A911E8151 for ; Mon, 14 Oct 2013 10:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4uJutjJ4lNM for ; Mon, 14 Oct 2013 10:57:07 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id D62EF11E8156 for ; Mon, 14 Oct 2013 10:56:28 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id ar20so3761263iec.12 for ; Mon, 14 Oct 2013 10:56:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ew0Vdzs9D6IU8Zd9N9QkrFXH9ejRH9WNYK7PsXAnmAY=; b=Kfk5YvrbP+KlNaFuFvi3fVoGSru2fX46CNFydGKt49yWIaGrM1n4a8BG8P20XDwXvB /4hmxgVI6z6sAPeLMTA4NwcrqSdD3RI+usy5KgIStTZA1Ywgs9PLy0+qtERNrVLUDiUt lsjBPZNj8MiKGxIpJ9UO1Dw4J+1zeVnn9Wpbc5ONf3s++cyarjiuD3zcD3wZ2TijJau2 AIRDPMvEKF+0SLKLDkLEheQHVe7zW7RBt+43ZgDexN+abahSbk7rc117/tDjajx0ixim yK6KLdURFtHqZHDQodxzXC4u+MTwyJFCY3pBXUjJVDL2KxHsb+ffaqFzXS6xt4OT9hxw Qrsg== X-Gm-Message-State: ALoCoQmo3Z5a5S2vaySv0P2V1enh5CFlk1mQfYsV32nJCOkdfH2w1frplYn3Uo/ggJIIhqGwpE1r X-Received: by 10.50.73.74 with SMTP id j10mr14013864igv.50.1381773388024; Mon, 14 Oct 2013 10:56:28 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id p7sm21608766iga.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 10:56:27 -0700 (PDT) Message-ID: <525C3049.1000809@bbs.darktech.org> Date: Mon, 14 Oct 2013 13:56:25 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <525BFB6F.5080403@alvestrand.no> In-Reply-To: <525BFB6F.5080403@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 17:57:12 -0000 Harald, What's the alternative? Whether the discussion happens on the mailing list or a call it sounds to me like you've got people with entrenched views. I'll take this opportunity to remind you of another option: mandate a codec whose IPR has expired and have clients negotiate up from there. This compromise displeases everyone equally, but it allows us to proceed without any further delay. Gili On 14/10/2013 10:10 AM, Harald Alvestrand wrote: > I've read the H.264 Constrained Baseline proposal. > > It contains no information that hasn't been presented to the list long > ago; all but the performance evaluations were presented in Florida. > > I've written the VP8 proposal. > It contains new information, but only in the form of pointing out that > VP8 is more widely deployed, closer to being an ISO standard, and > working better than when we discussed this in Florida. It is also > being universally deployed in existing WebRTC implementations (Mozilla > and Chrome). > > We know that for most participants, the IPR issue is the only real > issue. So far, I haven't seen any of the people who were saying "we > want to ship products but can't possibly use H.264" saying that they > have changed their minds. > > Yet the chairs are proposing the following 2-hour agenda: > > Frame discussions and process and agenda: 10 min (chairs) > > VP8 presentation with clarify questions - 25 min (???) > > H.264 presentation with clarify questions - 25 min (???) > > Microphone discussions of pro/cons - 40 min (all) > > Call the question - 10 min ( chairs ) > > Wrap up and next steps - 10 min (chairs) > > Celebrate on our successful decision reach. > > > Don't we have ways in which we can make better use of 2 hours? > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From mary.ietf.barnes@gmail.com Mon Oct 14 11:26:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D55421E80B3 for ; Mon, 14 Oct 2013 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.58 X-Spam-Level: X-Spam-Status: No, score=-101.58 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag7Ys24RMWgS for ; Mon, 14 Oct 2013 11:26:46 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 80BA521E80E3 for ; Mon, 14 Oct 2013 11:26:46 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id a11so472903qen.8 for ; Mon, 14 Oct 2013 11:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/6HTdNGYGmAiFy6kl4eaxICuNew+KKk4padQpwN7Ilo=; b=MyVys/A1IHDcqji2NlQNLgoukM6Q5kIso4eFW1YrTIM2c1s4HSwJCrVJu/kKUghu2G DEM+MoWW5LzmUeymyX7t9y9AgtZKJUzPZ7SLY1TpYSBHooiQuWgzj+ZCbtCqQGNfi4Kv MZzg1UzjXZa2ehTf3Ddpb1S8Z9XC8fuC665Zz8kQxu+245j/xIvasinDF/b+hA9CfoFI 00wyMWSJ+vrv+98nU8WUTXhxsPCw7ZN/SaajX1ZbcLPtbqkrQDhfax2/zy5iCwZsysq5 pCdf+9kAUXif+EOiOjHV6zl14Ab9LZr8xeWWWYjshYUNc+bCVOStwBDgrIMc/Uwu7f+A tVFA== MIME-Version: 1.0 X-Received: by 10.49.25.1 with SMTP id y1mr40544620qef.22.1381775205881; Mon, 14 Oct 2013 11:26:45 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Mon, 14 Oct 2013 11:26:45 -0700 (PDT) In-Reply-To: <525C3049.1000809@bbs.darktech.org> References: <525BFB6F.5080403@alvestrand.no> <525C3049.1000809@bbs.darktech.org> Date: Mon, 14 Oct 2013 13:26:45 -0500 Message-ID: From: Mary Barnes To: cowwoc Content-Type: multipart/alternative; boundary=047d7b676e684e79b804e8b79c50 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 18:26:47 -0000 --047d7b676e684e79b804e8b79c50 Content-Type: text/plain; charset=ISO-8859-1 Gili, The concern is around 2 hours on the agenda at the upcoming f2f meeting: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09037.html We already spent around hours on this topic at a previous f2f IETF. Here's the multi-media recording for your enjoyment: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_III BTW, Meetecho is a great way for remote folks to follow the f2f IETF meetings. Regards, Mary. On Mon, Oct 14, 2013 at 12:56 PM, cowwoc wrote: > Harald, > > What's the alternative? Whether the discussion happens on the mailing > list or a call it sounds to me like you've got people with entrenched > views. I'll take this opportunity to remind you of another option: mandate > a codec whose IPR has expired and have clients negotiate up from there. > This compromise displeases everyone equally, but it allows us to proceed > without any further delay. > > Gili > > > On 14/10/2013 10:10 AM, Harald Alvestrand wrote: > >> I've read the H.264 Constrained Baseline proposal. >> >> It contains no information that hasn't been presented to the list long >> ago; all but the performance evaluations were presented in Florida. >> >> I've written the VP8 proposal. >> It contains new information, but only in the form of pointing out that >> VP8 is more widely deployed, closer to being an ISO standard, and working >> better than when we discussed this in Florida. It is also being universally >> deployed in existing WebRTC implementations (Mozilla and Chrome). >> >> We know that for most participants, the IPR issue is the only real issue. >> So far, I haven't seen any of the people who were saying "we want to ship >> products but can't possibly use H.264" saying that they have changed their >> minds. >> >> Yet the chairs are proposing the following 2-hour agenda: >> >> Frame discussions and process and agenda: 10 min (chairs) >> >> VP8 presentation with clarify questions - 25 min (???) >> >> H.264 presentation with clarify questions - 25 min (???) >> >> Microphone discussions of pro/cons - 40 min (all) >> >> Call the question - 10 min ( chairs ) >> >> Wrap up and next steps - 10 min (chairs) >> >> Celebrate on our successful decision reach. >> >> >> Don't we have ways in which we can make better use of 2 hours? >> >> ______________________________**_________________ >> 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 > --047d7b676e684e79b804e8b79c50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gili,

The concern is around 2 hou= rs on the agenda at the upcoming f2f meeting:

We already spent around hours on this topic= at a previous f2f IETF. =A0Here's the multi-media recording for your e= njoyment:=A0

BTW, Meetecho is a great way for remo= te folks to follow the f2f IETF meetings.=A0


Regards,
Mary.


On Mon, Oct 14, 2013 at 12:56 PM, cowwoc= <cowwoc@bbs.darktech.org> wrote:
Harald,

=A0 =A0 What's the alternative? Whether the discussion happens on the m= ailing list or a call it sounds to me like you've got people with entre= nched views. I'll take this opportunity to remind you of another option= : mandate a codec whose IPR has expired and have clients negotiate up from = there. This compromise displeases everyone equally, but it allows us to pro= ceed without any further delay.

Gili


On 14/10/2013 10:10 AM, Harald Alvestrand wrote:
I've read the H.264 Constrained Baseline proposal.

It contains no information that hasn't been presented to the list long = ago; all but the performance evaluations were presented in Florida.

I've written the VP8 proposal.
It contains new information, but only in the form of pointing out that VP8 = is more widely deployed, closer to being an ISO standard, and working bette= r than when we discussed this in Florida. It is also being universally depl= oyed in existing WebRTC implementations (Mozilla and Chrome).

We know that for most participants, the IPR issue is the only real issue. S= o far, I haven't seen any of the people who were saying "we want t= o ship products but can't possibly use H.264" saying that they hav= e changed their minds.

Yet the chairs are proposing the following 2-hour agenda:

Frame discussions and process and agenda: 10 min (chairs)

VP8 presentation with clarify questions - =A025 min (???)

H.264 presentation with clarify questions - 25 min (???)

Microphone discussions of pro/cons - 40 min (all)

Call the question - 10 min ( chairs )

Wrap up and next steps - 10 min (chairs)

Celebrate on our successful decision reach.


Don't we have ways in which we can make better use of 2 hours?

_______________________________________________
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

--047d7b676e684e79b804e8b79c50-- From partha@parthasarathi.co.in Mon Oct 14 12:15:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324F921F9FA4 for ; Mon, 14 Oct 2013 12:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y9mtH8yl4ZF for ; Mon, 14 Oct 2013 12:15:12 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.235]) by ietfa.amsl.com (Postfix) with ESMTP id B7DA811E8189 for ; Mon, 14 Oct 2013 12:15:07 -0700 (PDT) Received: from userPC (unknown [122.172.182.21]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 0AC94638178; Mon, 14 Oct 2013 19:15:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1381778107; bh=q9qxT/gCPk49WSM0xXOPmF2dA9wvDoUc8mWZF3QFQSQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mPUlFLJtjAJg0WwvW/OXF/ilaEQOMrNWAelxzmcFDozzEZuQQighH+KX1vAFy+lxz CHhw5wIqpvJMFgy7CmnsByzBmEY0iyCh87cra/cogyZG1iHc5q7+APcCy11sHU/n1v sonvuBRoJzghCzc7G2rA0hIU//eozxJG70qZH4GA= From: "Parthasarathi R" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> Date: Tue, 15 Oct 2013 00:45:01 +0530 Message-ID: <00d601cec911$b0fd4b60$12f7e220$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7IvINFDjps6xe1Q0+JPDy99cM+7AAUxh6w Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.525C42BB.005C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:15:18 -0000 Hi Christer & all, In PNTAW mailing list, there is a discussion on firewall blocking incoming TCP traffic when the firewall blocks UDP or allows only HTTP traffic. The related link is http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. Could you please clarify whether F29 & F37 requirement implicitly indicates that incoming TCP/HTTP traffic is blocked for browser when these requirements are met. If so, Please update the below requirement text with those details. Thanks Partha Note: ---------------------------------------------------------------- F29 The browser must be able to send streams and data to a peer in the presence of NATs that block UDP traffic. ---------------------------------------------------------------- F37 The browser must be able to send streams and data to a peer in the presence of FWs that only allows traffic via a HTTP Proxy, when FW policy allows WebRTC traffic. From cowwoc@bbs.darktech.org Mon Oct 14 12:25:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E374C11E818E for ; Mon, 14 Oct 2013 12:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gp2LUBt3l6w for ; Mon, 14 Oct 2013 12:25:29 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9A11E8185 for ; Mon, 14 Oct 2013 12:25:29 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id k4so1676490qaq.0 for ; Mon, 14 Oct 2013 12:25:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=mULLqbNJDfBDxCyztFY49jEho9dCgai9LiZ/v6XvML8=; b=LZMZ+uf0LophHT1P5lKFVdUsZ/Hn8rIvg35Q4QLvUu4KnNIBRAnrSBUDsD2rQR1Oln fvuwGZIDD5a2gdZhNZhO4XO0zCZPHV2zBu4zsvb4LpONaLyldcFV1o/hesLfzbwNl0cU PBe331oRilxcoCmWNiKv3+XhAv6C/tX0K5Qj4TjbZtjwylx5j47F/5f7NSx+jXcMLfMk NmwQeyfCmTa5smnb3pRAWVRHrO+/gpHydEUcdkTi0XWqJo4JEeBkPjxFh6qGyrvxlkde DWRD+c9zjwdiOtOVKbwPcpuEj9eN3zOoiZjFSj93PAh7P5jBfW20cj9hsmgdiFvI6t+y ANmA== X-Gm-Message-State: ALoCoQmnKW3ey6Bc9tXME2gcFe25X8s1OWJrAVNocN2qOrDbRZw1h6678AK8SQs6rmpvtep5wqwB X-Received: by 10.224.25.8 with SMTP id x8mr24363637qab.77.1381778727331; Mon, 14 Oct 2013 12:25:27 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id h9sm31558966qaq.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 12:25:26 -0700 (PDT) Message-ID: <525C4524.20909@bbs.darktech.org> Date: Mon, 14 Oct 2013 15:25:24 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mary Barnes References: <525BFB6F.5080403@alvestrand.no> <525C3049.1000809@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000900070400030504000009" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:25:34 -0000 This is a multi-part message in MIME format. --------------000900070400030504000009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Mary, I understand. So you're saying that the WG believes that this topic has been discussed to death and therefore would like to call it to a vote without (or with a shorter) discussion, is that correct? Gili On 14/10/2013 2:26 PM, Mary Barnes wrote: > Gili, > > The concern is around 2 hours on the agenda at the upcoming f2f meeting: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09037.html > > We already spent around hours on this topic at a previous f2f IETF. > Here's the multi-media recording for your enjoyment: > http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_III > > BTW, Meetecho is a great way for remote folks to follow the f2f IETF > meetings. > > > Regards, > Mary. > > > On Mon, Oct 14, 2013 at 12:56 PM, cowwoc > wrote: > > Harald, > > What's the alternative? Whether the discussion happens on the > mailing list or a call it sounds to me like you've got people with > entrenched views. I'll take this opportunity to remind you of > another option: mandate a codec whose IPR has expired and have > clients negotiate up from there. This compromise displeases > everyone equally, but it allows us to proceed without any further > delay. > > Gili > > > On 14/10/2013 10:10 AM, Harald Alvestrand wrote: > > I've read the H.264 Constrained Baseline proposal. > > It contains no information that hasn't been presented to the > list long ago; all but the performance evaluations were > presented in Florida. > > I've written the VP8 proposal. > It contains new information, but only in the form of pointing > out that VP8 is more widely deployed, closer to being an ISO > standard, and working better than when we discussed this in > Florida. It is also being universally deployed in existing > WebRTC implementations (Mozilla and Chrome). > > We know that for most participants, the IPR issue is the only > real issue. So far, I haven't seen any of the people who were > saying "we want to ship products but can't possibly use H.264" > saying that they have changed their minds. > > Yet the chairs are proposing the following 2-hour agenda: > > Frame discussions and process and agenda: 10 min (chairs) > > VP8 presentation with clarify questions - 25 min (???) > > H.264 presentation with clarify questions - 25 min (???) > > Microphone discussions of pro/cons - 40 min (all) > > Call the question - 10 min ( chairs ) > > Wrap up and next steps - 10 min (chairs) > > Celebrate on our successful decision reach. > > > Don't we have ways in which we can make better use of 2 hours? > > _______________________________________________ > 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 > > --------------000900070400030504000009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Mary,

    I understand. So you're saying that the WG believes that this topic has been discussed to death and therefore would like to call it to a vote without (or with a shorter) discussion, is that correct?

Gili

On 14/10/2013 2:26 PM, Mary Barnes wrote:
Gili,

The concern is around 2 hours on the agenda at the upcoming f2f meeting:

We already spent around hours on this topic at a previous f2f IETF.  Here's the multi-media recording for your enjoyment: 

BTW, Meetecho is a great way for remote folks to follow the f2f IETF meetings. 


Regards,
Mary.


On Mon, Oct 14, 2013 at 12:56 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Harald,

    What's the alternative? Whether the discussion happens on the mailing list or a call it sounds to me like you've got people with entrenched views. I'll take this opportunity to remind you of another option: mandate a codec whose IPR has expired and have clients negotiate up from there. This compromise displeases everyone equally, but it allows us to proceed without any further delay.

Gili


On 14/10/2013 10:10 AM, Harald Alvestrand wrote:
I've read the H.264 Constrained Baseline proposal.

It contains no information that hasn't been presented to the list long ago; all but the performance evaluations were presented in Florida.

I've written the VP8 proposal.
It contains new information, but only in the form of pointing out that VP8 is more widely deployed, closer to being an ISO standard, and working better than when we discussed this in Florida. It is also being universally deployed in existing WebRTC implementations (Mozilla and Chrome).

We know that for most participants, the IPR issue is the only real issue. So far, I haven't seen any of the people who were saying "we want to ship products but can't possibly use H.264" saying that they have changed their minds.

Yet the chairs are proposing the following 2-hour agenda:

Frame discussions and process and agenda: 10 min (chairs)

VP8 presentation with clarify questions -  25 min (???)

H.264 presentation with clarify questions - 25 min (???)

Microphone discussions of pro/cons - 40 min (all)

Call the question - 10 min ( chairs )

Wrap up and next steps - 10 min (chairs)

Celebrate on our successful decision reach.


Don't we have ways in which we can make better use of 2 hours?

_______________________________________________
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


--------------000900070400030504000009-- From bo.burman@ericsson.com Mon Oct 14 14:12:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09BA21E80A8 for ; Mon, 14 Oct 2013 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcLusoZLtzYZ for ; Mon, 14 Oct 2013 14:12:16 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC25421E80F8 for ; Mon, 14 Oct 2013 14:12:10 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-cd-525c5e2a2829 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3D.C7.03802.A2E5C525; Mon, 14 Oct 2013 23:12:10 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.148]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 23:12:10 +0200 From: Bo Burman To: "rtcweb@ietf.org" Thread-Topic: Comments on H.264 and VP8 performance comparisons Thread-Index: Ac7JIe76OhlqjGwCQFaenvACTkQ0Vw== Date: Mon, 14 Oct 2013 21:12:08 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvra5WXEyQQdM6fou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcaq9m7Fgql7FlnV/mBoYd6t2MXJySAiYSOyc9YIRwhaTuHBv PVsXIxeHkMBhRokvC6YzQjhLGCUOtl9kA6liE9CQmL/jLliHiIC6xOWHF9hBbGEBK4klkx5A xe0l1mzeyQZh60mc3/sSLM4ioCrxr20FC4jNK+ArsevrOiYQm1FAVuL+93tgcWYBcYlbT+Yz QVwkILFkz3lmCFtU4uXjf6xdjBxAtqLE8n45iHIdiQW7P7FB2NoSyxa+ZoYYLyhxcuYTlgmM wrOQTJ2FpGUWkpZZSFoWMLKsYmTPTczMSS832sQIDOODW36r7mC8c07kEKM0B4uSOO+Ht85B QgLpiSWp2ampBalF8UWlOanFhxiZODilGhgnHd/xVsZUTnHLsvA1D9epMmVtX/nwWTWbRlkt byzX9Fjuqqi7n03XrLC2zuY9e/ThD4NQtU/FyTMvL9F7cviKV2JFhF2F/tkDgXxuJi9Fdkrf C9S8eV3u4+dd3Zd7lBNDbs13P9V6asdLz7vRu3mkfH9H7zl8RugtywfJq6eDf+86rBvQLtGr xFKckWioxVxUnAgA+qovpzECAAA= Subject: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 21:12:22 -0000 Hi all, We would like to counter Google's suggestion that our test has only "demons= trated that it is possible to reduce VP8's performance" (updated draft on V= P8 http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/).=20 In fact, what we did in our test was mostly undoing some very peculiar x264= settings made by Google in their test from April 3. By instead using the x= 264 settings Google themselves proposed in their earlier test (from March 1= 2), and removing threading, the difference went down from 41% to 16%. (This= is without touching the VP8 parameters.) The last change we made was to remove the rate control from the comparison,= something that is standard practice in the world of video standardization.= This involved changing both the x264 and VP8 parameters. After that, the d= ifference went down to -1%. In summary, the following steps were taken in our comparison: 1) Downloading the latest software: 41% became 36% 2) Removing threading: 26% 3) Removing bit padding: 18% 4) Removing other differences between Google's March 12 and April 3rd tests= : 16% 5) Removing rate controller: -1% Contrary to Google's note on our test the purpose was not to "reduce the VP= 8 performance" but rather to present a technically correct codec comparison= . Below follows a detailed description of what we found: --- When we first saw Google's test which was posted on April 3rd, we were surp= rised to find that their results differed so much from our own. Whereas we = got a negligible difference between VP8 and H.264 constrained baseline, Goo= gle reported that H.264 constrained baseline needed 41% more bits than VP8 = for the same quality. This made us look deeper into Google's test to see ho= w this could be explained.=20 The first thing we did was to download the latest versions of all software = packages. By using the newest version of x264, the difference went down fro= m 41% to 36%. The second thing that caught our attention was that Google's x264 test used= auto threading. By omitting the parameter "--threads 1", the x264 encoder = defaults to "--threads auto", which means that a large number of threads wi= ll be used to compress the image (see for instance http://mewiki.project357= .com/wiki/X264_Settings). This will have the effect of decreasing the compr= ession time at the cost of quality. The VP8 codec, on the other hand, defau= lts to a single thread with no quality degradation. Even when we changed th= e x264 configuration to use the proper threading value ("--threads 1"), the= x264 codec was twice as fast as VP8, and the difference in bit rate went d= own from 36% to 26%.=20 At this time we proceeded to only test the first 10 seconds of each sequenc= e in order to get reasonable running times. This actually increased the dif= ference again to 29%. Our attention now turned to the "--nal-hrd cbr" parameter in Google's x264 = April 3rd parameter list. As described at http://mewiki.project357.com/wiki= /X264_Settings#nal-hrd, this setting will pack the bitstream with padding b= its in order to exactly reach a particular bit rate. This is useful in some= circumstances such as in Blu-ray or ISDN video telephony which has to be e= xactly, say, 64000 bits per second, but it is undesirable in a codec compar= ison since it will only add bits and not increase quality. The VP8 encoder = does not do such bit padding and was thus at an advantage. Removing the "--= nal-hrd cbr" parameter for x264 avoided the unnecessary bit padding and the= difference now went down from 29% to 18%. At this point in time we tried removing the remaining variables that differ= ed between the x264 parameter set of Google's first test (from March 12) an= d the x264 parameter set of Google's second test (from April 3rd), and this= resulted in a further decrease from 18% to 16%. Finally we removed the rate controller from the test and instead used fixed= QP. As we have argued previously, having a rate controller in the loop jus= t adds noise to the test and also risks measuring the performance of the ra= te controller rather than the codec. Using fixed QP (no rate control) is th= erefore established practice in the video codec community. As an example, t= he Motion Pictures Expert Group (MPEG) recommends using fixed QP for video = comparisons, see for instance (http://mpeg.chiariglione.org/standards/explo= ration/internet-video-coding/call-proposals-internet-video-coding-technolog= y). The reworked test without rate control (which we published on June 22) = then got the result of -1%. This means H.264 constrained baseline (in the x= 264 implementation) outperformed VP8. We also found H.264 constrained high,= again using the x264 implementation, to be 24% better than VP8. Google's comparison on April 3rd also included a speed test. In this, x264 = is set to use only one thread, the parameter "--threads 1" is set. This mea= ns that x264 cannot enjoy the faster speed of a parallel implementation. We= do not quite understand this choice of parameters from Google: When thread= ing should be avoided (in the case of measuring quality), it is used, where= as when it would be helpful (in the case of measuring speed), it is avoided= . In both cases this is unfavorable to x264. This does not seem entirely fa= ir. Note that the biggest differences in performance were not due the changes m= ade to the VP8 settings but to those of x264: The threading and the bit pad= ding alone accounted for 21 of the 41 percentage points. Thus, we do not th= ink that our test is about trying to "reduce the VP8 performance". Instead,= the major things have been avoiding what we believe are unfortunate parame= ter choices for x264 on behalf of Google, and to create a technically corre= ct test. Best Regards, Bo Burman From mary.ietf.barnes@gmail.com Mon Oct 14 14:31:53 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E321E812D for ; Mon, 14 Oct 2013 14:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHm3LjY5MuLW for ; Mon, 14 Oct 2013 14:31:52 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5376B21E8108 for ; Mon, 14 Oct 2013 14:31:50 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id n9so2337403qcw.15 for ; Mon, 14 Oct 2013 14:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=clyK4lMAXzarj3C3p26l1m1Pys2saMtyds7rFk0/nUA=; b=I7Rbn0urHHO79PqVjvo3n5j8S2nK2bG8/EEKYelSIdnoPcPzWBBhbXQNgH4XiwhQ4x TEE45ds3rPHjvGSEeCdTlQ9ab2VU5dOmXUgwi5ldNlznmIxi6RCXgIPm1uBezSu5UVy5 /iuZKzHm2/Eo1OGuDSMHNzx8qfoibS2KeTVZMAPz2F1HnBIlb7jnUTt++VEtaq5P3Wnf aMeBKdr8ZhMzPy3v5HQ0VsUZ7eyj4teTWmjzORdKjlTlf1fW8P8ffW/FrZmKlkmukBZG lb/jMdNfUx7BEy72bnzZeIukgNPpfxRzviTdJkZ/OBawrQ4A84qW9cVMdG01+v5JafEv znWQ== MIME-Version: 1.0 X-Received: by 10.224.54.209 with SMTP id r17mr25447785qag.16.1381786309670; Mon, 14 Oct 2013 14:31:49 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Mon, 14 Oct 2013 14:31:49 -0700 (PDT) In-Reply-To: <525C4524.20909@bbs.darktech.org> References: <525BFB6F.5080403@alvestrand.no> <525C3049.1000809@bbs.darktech.org> <525C4524.20909@bbs.darktech.org> Date: Mon, 14 Oct 2013 16:31:49 -0500 Message-ID: From: Mary Barnes To: cowwoc Content-Type: multipart/alternative; boundary=089e015375322511d304e8ba324a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 21:31:53 -0000 --089e015375322511d304e8ba324a Content-Type: text/plain; charset=ISO-8859-1 Basically, yes. On Mon, Oct 14, 2013 at 2:25 PM, cowwoc wrote: > Hi Mary, > > I understand. So you're saying that the WG believes that this topic > has been discussed to death and therefore would like to call it to a vote > without (or with a shorter) discussion, is that correct? > > Gili > > > On 14/10/2013 2:26 PM, Mary Barnes wrote: > > Gili, > > The concern is around 2 hours on the agenda at the upcoming f2f meeting: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09037.html > > We already spent around hours on this topic at a previous f2f IETF. > Here's the multi-media recording for your enjoyment: > http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_III > > BTW, Meetecho is a great way for remote folks to follow the f2f IETF > meetings. > > > Regards, > Mary. > > > On Mon, Oct 14, 2013 at 12:56 PM, cowwoc wrote: > >> Harald, >> >> What's the alternative? Whether the discussion happens on the mailing >> list or a call it sounds to me like you've got people with entrenched >> views. I'll take this opportunity to remind you of another option: mandate >> a codec whose IPR has expired and have clients negotiate up from there. >> This compromise displeases everyone equally, but it allows us to proceed >> without any further delay. >> >> Gili >> >> >> On 14/10/2013 10:10 AM, Harald Alvestrand wrote: >> >>> I've read the H.264 Constrained Baseline proposal. >>> >>> It contains no information that hasn't been presented to the list long >>> ago; all but the performance evaluations were presented in Florida. >>> >>> I've written the VP8 proposal. >>> It contains new information, but only in the form of pointing out that >>> VP8 is more widely deployed, closer to being an ISO standard, and working >>> better than when we discussed this in Florida. It is also being universally >>> deployed in existing WebRTC implementations (Mozilla and Chrome). >>> >>> We know that for most participants, the IPR issue is the only real >>> issue. So far, I haven't seen any of the people who were saying "we want to >>> ship products but can't possibly use H.264" saying that they have changed >>> their minds. >>> >>> Yet the chairs are proposing the following 2-hour agenda: >>> >>> Frame discussions and process and agenda: 10 min (chairs) >>> >>> VP8 presentation with clarify questions - 25 min (???) >>> >>> H.264 presentation with clarify questions - 25 min (???) >>> >>> Microphone discussions of pro/cons - 40 min (all) >>> >>> Call the question - 10 min ( chairs ) >>> >>> Wrap up and next steps - 10 min (chairs) >>> >>> Celebrate on our successful decision reach. >>> >>> >>> Don't we have ways in which we can make better use of 2 hours? >>> >>> _______________________________________________ >>> 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 >> > > > --089e015375322511d304e8ba324a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Basically, yes.


On Mon, Oct 14, 2013 at 2:25 PM, cowwoc <c= owwoc@bbs.darktech.org> wrote:
=20 =20 =20
Hi Mary,

=A0=A0=A0 I understand. So you're saying that the WG believes tha= t this topic has been discussed to death and therefore would like to call it to a vote without (or with a shorter) discussion, is that correct?

Gili


On 14/10/2013 2:26 PM, Mary Barnes wrote:
Gili,

The concern is around 2 hours on the agenda at the upcoming f2f meeting:

We already spent around hours on this topic at a previous f2f IETF. =A0Here's the multi-media recording for yo= ur enjoyment:=A0

BTW, Meetecho is a great way for remote folks to follow the f2f IETF meetings.=A0


Regards,
Mary.


On Mon, Oct 14, 2013 at 12:56 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Harald,

=A0 =A0 What's the alternative? Whether the discussion happ= ens on the mailing list or a call it sounds to me like you've got people with entrenched views. I'll take this opportunit= y to remind you of another option: mandate a codec whose IPR has expired and have clients negotiate up from there. This compromise displeases everyone equally, but it allows us to proceed without any further delay.

Gili


On 14/10/2013 10:10 AM, Harald Alvestrand wrote:
I've read the H.264 Constrained Baseline proposal.
It contains no information that hasn't been presented to the list long ago; all but the performance evaluations were presented in Florida.

I've written the VP8 proposal.
It contains new information, but only in the form of pointing out that VP8 is more widely deployed, closer to being an ISO standard, and working better than when we discussed this in Florida. It is also being universally deployed in existing WebRTC implementations (Mozilla and Chrome).

We know that for most participants, the IPR issue is the only real issue. So far, I haven't seen any of th= e people who were saying "we want to ship products but can't possibly use H.264" saying that they have changed their minds.

Yet the chairs are proposing the following 2-hour agenda:

Frame discussions and process and agenda: 10 min (chairs)

VP8 presentation with clarify questions - =A025 min (???)

H.264 presentation with clarify questions - 25 min (???)

Microphone discussions of pro/cons - 40 min (all)

Call the question - 10 min ( chairs )

Wrap up and next steps - 10 min (chairs)

Celebrate on our successful decision reach.


Don't we have ways in which we can make better use of 2 hours?

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

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



--089e015375322511d304e8ba324a-- From ted.ietf@gmail.com Mon Oct 14 17:06:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073EA21E8139 for ; Mon, 14 Oct 2013 17:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCwElONCHl4Y for ; Mon, 14 Oct 2013 17:06:41 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0821F9AE3 for ; Mon, 14 Oct 2013 17:06:41 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so8876615iej.39 for ; Mon, 14 Oct 2013 17:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Em+CFMyYiEBK1FljElpZKvoSc4Wkc7tpJw8bRyUrOwg=; b=iDF/K17py+rpGedfFCIanSj0/Hj+PmAEdu0A6aB5eO+7iA35aUvHMSjE4b5U4Cuger dKF2o8D6f/KjT1+9AU6BEIIpClOLqHi5/S/UKcPW/3ZQMlFkAwKcW3387LYCDe4EQU5B c8G/J1iYEGeFcvzOZ3OrBxOSRKM7PNRicBYsY9WcYt2uMnM+N4SFJvv06cnXAFkcq43A Ar/3qTP1rIgQ5WIdwpFk01/zX5ehbKG/VHlMf3h86SJd8O3zHCSU7Q4fYaH7nTxKMfrs 0tUTjB6Rng+fgmVHVm2WvlFEz3usRr2qrqxh/uuVPdEsqjdb7WRMC3acoAaT4FdrSXn5 0z6A== MIME-Version: 1.0 X-Received: by 10.50.119.70 with SMTP id ks6mr15096505igb.22.1381795600890; Mon, 14 Oct 2013 17:06:40 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Mon, 14 Oct 2013 17:06:40 -0700 (PDT) In-Reply-To: <525C4524.20909@bbs.darktech.org> References: <525BFB6F.5080403@alvestrand.no> <525C3049.1000809@bbs.darktech.org> <525C4524.20909@bbs.darktech.org> Date: Mon, 14 Oct 2013 17:06:40 -0700 Message-ID: From: Ted Hardie To: cowwoc Content-Type: multipart/alternative; boundary=089e0111d9b8f184b404e8bc5bd5 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 versus VP8 - are we really going to spend 2 full hours rehashing this? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 00:06:43 -0000 --089e0111d9b8f184b404e8bc5bd5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 14, 2013 at 12:25 PM, cowwoc wrote: > Hi Mary, > > I understand. So you're saying that the WG believes that this topic > has been discussed to death and therefore would like to call it to a vote > without (or with a shorter) discussion, is that correct? > > Gili > > Please remember that we don't vote; we're trying to come to (at least rough) consensus. That's a harder process than voting, and it can take more time. A key part of it is ensuring that each of those with substantive technical points to make is certain that they have been heard. If the H.264 and VP8 proponents do not choose to use the full time for their presentations or the working group participants the time for questions, we will, of course, retrieve whatever time remains for other discussions. The more that substantive discussions happens now, on the list, the more likely it is that we retrieve time. If all the proponents of each proposal and all the potential questioners are satisfied by the discussion on the list, we can retrieve nearly all of it. If the working group would like the chairs to propose other topics for any remainder, I am sure we can do so; we'd also be happy for proposals from the WG. regards, Ted Hardie > > On 14/10/2013 2:26 PM, Mary Barnes wrote: > > Gili, > > The concern is around 2 hours on the agenda at the upcoming f2f meeting: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09037.html > > We already spent around hours on this topic at a previous f2f IETF. > Here's the multi-media recording for your enjoyment: > http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB_III > > BTW, Meetecho is a great way for remote folks to follow the f2f IETF > meetings. > > > Regards, > Mary. > > > On Mon, Oct 14, 2013 at 12:56 PM, cowwoc wrote: > >> Harald, >> >> What's the alternative? Whether the discussion happens on the mailing >> list or a call it sounds to me like you've got people with entrenched >> views. I'll take this opportunity to remind you of another option: mandate >> a codec whose IPR has expired and have clients negotiate up from there. >> This compromise displeases everyone equally, but it allows us to proceed >> without any further delay. >> >> Gili >> >> >> On 14/10/2013 10:10 AM, Harald Alvestrand wrote: >> >>> I've read the H.264 Constrained Baseline proposal. >>> >>> It contains no information that hasn't been presented to the list long >>> ago; all but the performance evaluations were presented in Florida. >>> >>> I've written the VP8 proposal. >>> It contains new information, but only in the form of pointing out that >>> VP8 is more widely deployed, closer to being an ISO standard, and working >>> better than when we discussed this in Florida. It is also being universally >>> deployed in existing WebRTC implementations (Mozilla and Chrome). >>> >>> We know that for most participants, the IPR issue is the only real >>> issue. So far, I haven't seen any of the people who were saying "we want to >>> ship products but can't possibly use H.264" saying that they have changed >>> their minds. >>> >>> Yet the chairs are proposing the following 2-hour agenda: >>> >>> Frame discussions and process and agenda: 10 min (chairs) >>> >>> VP8 presentation with clarify questions - 25 min (???) >>> >>> H.264 presentation with clarify questions - 25 min (???) >>> >>> Microphone discussions of pro/cons - 40 min (all) >>> >>> Call the question - 10 min ( chairs ) >>> >>> Wrap up and next steps - 10 min (chairs) >>> >>> Celebrate on our successful decision reach. >>> >>> >>> Don't we have ways in which we can make better use of 2 hours? >>> >>> _______________________________________________ >>> 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 > > --089e0111d9b8f184b404e8bc5bd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 14, 2013 at 12:25 PM, cowwoc <cowwoc@bb= s.darktech.org> wrote:
=20 =20 =20
Hi Mary,

=A0=A0=A0 I understand. So you're saying that the WG believes tha= t this topic has been discussed to death and therefore would like to call it to a vote without (or with a shorter) discussion, is that correct?

Gili

<= div>
Please remember that we don't vote; we're trying= to come to (at least rough) consensus.=A0 That's a harder process than= voting, and it can take more time.=A0 A key part of it is ensuring that ea= ch of those with substantive technical points to make is certain that they = have been heard.=A0 If the H.264 and VP8 proponents do not choose to use th= e full time for their presentations or the working group participants the t= ime for questions, we will, of course, retrieve whatever time remains for o= ther discussions.=A0 The more that substantive discussions happens now, on = the list, the more likely it is that we retrieve time.=A0 If all the propon= ents of each proposal and all the potential questioners are satisfied by th= e discussion on the list, we can retrieve nearly all of it.

If the working group would like the chairs to propose other = topics for any remainder, I am sure we can do so; we'd also be happy fo= r proposals from the WG.

regards,

Ted Hardie
=A0

On 14/10/2013 2:26 PM, Mary Barnes wrote:
Gili,

The concern is around 2 hours on the agenda at the upcoming f2f meeting:

We already spent around hours on this topic at a previous f2f IETF. =A0Here's the multi-media recording for yo= ur enjoyment:=A0

BTW, Meetecho is a great way for remote folks to follow the f2f IETF meetings.=A0


Regards,
Mary.


On Mon, Oct 14, 2013 at 12:56 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Harald,

=A0 =A0 What's the alternative? Whether the discussion happ= ens on the mailing list or a call it sounds to me like you've got people with entrenched views. I'll take this opportunit= y to remind you of another option: mandate a codec whose IPR has expired and have clients negotiate up from there. This compromise displeases everyone equally, but it allows us to proceed without any further delay.

Gili


On 14/10/2013 10:10 AM, Harald Alvestrand wrote:
I've read the H.264 Constrained Baseline proposal.
It contains no information that hasn't been presented to the list long ago; all but the performance evaluations were presented in Florida.

I've written the VP8 proposal.
It contains new information, but only in the form of pointing out that VP8 is more widely deployed, closer to being an ISO standard, and working better than when we discussed this in Florida. It is also being universally deployed in existing WebRTC implementations (Mozilla and Chrome).

We know that for most participants, the IPR issue is the only real issue. So far, I haven't seen any of th= e people who were saying "we want to ship products but can't possibly use H.264" saying that they have changed their minds.

Yet the chairs are proposing the following 2-hour agenda:

Frame discussions and process and agenda: 10 min (chairs)

VP8 presentation with clarify questions - =A025 min (???)

H.264 presentation with clarify questions - 25 min (???)

Microphone discussions of pro/cons - 40 min (all)

Call the question - 10 min ( chairs )

Wrap up and next steps - 10 min (chairs)

Celebrate on our successful decision reach.


Don't we have ways in which we can make better use of 2 hours?

_______________________________________________
rtcweb mailing list
rtcw= eb@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


--089e0111d9b8f184b404e8bc5bd5-- From adam@nostrum.com Mon Oct 14 19:41:38 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3AF11E80EA for ; Mon, 14 Oct 2013 19:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjnT5+sxtsJP for ; Mon, 14 Oct 2013 19:41:38 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 13A0421F9433 for ; Mon, 14 Oct 2013 19:41:37 -0700 (PDT) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9F2faDg073685 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Oct 2013 21:41:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <525CAB5B.8000304@nostrum.com> Date: Mon, 14 Oct 2013 21:41:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: [rtcweb] Partial Offer/Partial Answer draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 02:41:38 -0000 Just to make sure no one misses it, I just released a document that describes the partial offer/partial answer mechanism in more detail. This is an MMUSIC document, and should be discussed on the MMUSIC mailing list. For further details, please see: http://www.ietf.org/mail-archive/web/mmusic/current/msg12421.html Thanks! /a From harald@alvestrand.no Tue Oct 15 06:38:04 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF9511E8138 for ; Tue, 15 Oct 2013 06:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.099 X-Spam-Level: X-Spam-Status: No, score=-109.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_BACKHAIR_11=1, J_BACKHAIR_14=1, J_BACKHAIR_41=1, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8wdDsxjjmNt for ; Tue, 15 Oct 2013 06:38:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BB24711E8128 for ; Tue, 15 Oct 2013 06:37:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28DC939E16F for ; Tue, 15 Oct 2013 15:37:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8aifrMKsQ44 for ; Tue, 15 Oct 2013 15:37:34 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 482ED39E031 for ; Tue, 15 Oct 2013 15:37:34 +0200 (CEST) Message-ID: <525D451D.6090401@alvestrand.no> Date: Tue, 15 Oct 2013 15:37:33 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.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 Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 13:38:04 -0000 Thanks for the details, Bo! We had the discussion about locking QP at MPEG too; the H.264 reference model is usually run with a fixed QP per frame type (the QP for the I frame is different from the P frame, which is again different from the B frame if used, but in encoding to a specific bitrate, they change the QP once per run so that the data rate comes out right), which is fine for comparing two minor versions of a codec to , but doesn't seem equally obvious when comparing two codecs that have differing histories and are expected to behave differently on a large number of points. The VP8 codec was designed and tested in a real-world environment where rate controls have to be used, and where we can't make repeated passes over the clips to find the best QP values to use for a given clip. This colors the way it behaves; there's no reason to believe it would be optimal in a fixed-QP environment. When we debated this at MPEG, the MPEG conclusion was that they accepted that we would encode the VP8 clips with our normal rate control despite the strenous objections of some members - I don't want to second-guess MPEG's decisions in this forum. I'll look at the changes you're proposing. We did do one set of tweaks "as suggested online" to the H.264 parameters, the diff (from the public repo of our testing code) is: Date: Tue Mar 19 10:22:28 2013 -0700 Used settings suggested by x264 devs and updated vp8 settings too We didn't go down to the vp8 equivalent of very_slow for quality tests. Now we do also adjusted the x264 settings to match what was suggested on line. Change-Id: I2270d156cbe5893ddb7d37633f5fe61f93fae091 diff --git a/run_h264_tests.sh b/run_h264_tests.sh index a8a1db0..6d75136 100755 --- a/run_h264_tests.sh +++ b/run_h264_tests.sh @@ -50,9 +50,11 @@ do for (( rate=rate_start; rate<=rate_end; rate+=rate_step )) do # Encode into ./____kbps.yuv - x264 --vbv-bufsize ${rate} --bitrate ${rate} --fps ${frame_rate} \ + x264 --nal-hrd cbr --vbv-maxrate ${rate} --vbv-bufsize ${rate} \ + --vbv-init 0.8 --bitrate ${rate} --fps ${frame_rate} \ --profile baseline --no-scenecut --keyint infinite --preset veryslow \ --input-res ${width}x${height} \ + --tune psnr \ -o ./encoded_clips/h264/${clip_stem}_${rate}kbps.mkv ${filename} \ 2> ./logs/h264/${clip_stem}_${rate}kbps.txt We don't seem to have made any changes since then; I'll experiment with the settings you're suggesting. FWIW, when I run the head of our repository (which is locked to a specific software rev for each codec; I'll play with those too), the summary report says that the difference is 71%. Feel free to check out the latest version! On 10/14/2013 11:12 PM, Bo Burman wrote: > Hi all, > > We would like to counter Google's suggestion that our test has only "demonstrated that it is possible to reduce VP8's performance" (updated draft on VP8 http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/). > > In fact, what we did in our test was mostly undoing some very peculiar x264 settings made by Google in their test from April 3. By instead using the x264 settings Google themselves proposed in their earlier test (from March 12), and removing threading, the difference went down from 41% to 16%. (This is without touching the VP8 parameters.) > > The last change we made was to remove the rate control from the comparison, something that is standard practice in the world of video standardization. This involved changing both the x264 and VP8 parameters. After that, the difference went down to -1%. > > In summary, the following steps were taken in our comparison: > > 1) Downloading the latest software: 41% became 36% > 2) Removing threading: 26% > 3) Removing bit padding: 18% > 4) Removing other differences between Google's March 12 and April 3rd tests: 16% > 5) Removing rate controller: -1% > > Contrary to Google's note on our test the purpose was not to "reduce the VP8 performance" but rather to present a technically correct codec comparison. Below follows a detailed description of what we found: > > --- > > When we first saw Google's test which was posted on April 3rd, we were surprised to find that their results differed so much from our own. Whereas we got a negligible difference between VP8 and H.264 constrained baseline, Google reported that H.264 constrained baseline needed 41% more bits than VP8 for the same quality. This made us look deeper into Google's test to see how this could be explained. > > The first thing we did was to download the latest versions of all software packages. By using the newest version of x264, the difference went down from 41% to 36%. > > The second thing that caught our attention was that Google's x264 test used auto threading. By omitting the parameter "--threads 1", the x264 encoder defaults to "--threads auto", which means that a large number of threads will be used to compress the image (see for instance http://mewiki.project357.com/wiki/X264_Settings). This will have the effect of decreasing the compression time at the cost of quality. The VP8 codec, on the other hand, defaults to a single thread with no quality degradation. Even when we changed the x264 configuration to use the proper threading value ("--threads 1"), the x264 codec was twice as fast as VP8, and the difference in bit rate went down from 36% to 26%. > > At this time we proceeded to only test the first 10 seconds of each sequence in order to get reasonable running times. This actually increased the difference again to 29%. > > Our attention now turned to the "--nal-hrd cbr" parameter in Google's x264 April 3rd parameter list. As described at http://mewiki.project357.com/wiki/X264_Settings#nal-hrd, this setting will pack the bitstream with padding bits in order to exactly reach a particular bit rate. This is useful in some circumstances such as in Blu-ray or ISDN video telephony which has to be exactly, say, 64000 bits per second, but it is undesirable in a codec comparison since it will only add bits and not increase quality. The VP8 encoder does not do such bit padding and was thus at an advantage. Removing the "--nal-hrd cbr" parameter for x264 avoided the unnecessary bit padding and the difference now went down from 29% to 18%. > > At this point in time we tried removing the remaining variables that differed between the x264 parameter set of Google's first test (from March 12) and the x264 parameter set of Google's second test (from April 3rd), and this resulted in a further decrease from 18% to 16%. > > Finally we removed the rate controller from the test and instead used fixed QP. As we have argued previously, having a rate controller in the loop just adds noise to the test and also risks measuring the performance of the rate controller rather than the codec. Using fixed QP (no rate control) is therefore established practice in the video codec community. As an example, the Motion Pictures Expert Group (MPEG) recommends using fixed QP for video comparisons, see for instance (http://mpeg.chiariglione.org/standards/exploration/internet-video-coding/call-proposals-internet-video-coding-technology). The reworked test without rate control (which we published on June 22) then got the result of -1%. This means H.264 constrained baseline (in the x264 implementation) outperformed VP8. We also found H.264 constrained high, again using the x264 implementation, to be 24% better than VP8. > > Google's comparison on April 3rd also included a speed test. In this, x264 is set to use only one thread, the parameter "--threads 1" is set. This means that x264 cannot enjoy the faster speed of a parallel implementation. We do not quite understand this choice of parameters from Google: When threading should be avoided (in the case of measuring quality), it is used, whereas when it would be helpful (in the case of measuring speed), it is avoided. In both cases this is unfavorable to x264. This does not seem entirely fair. > > Note that the biggest differences in performance were not due the changes made to the VP8 settings but to those of x264: The threading and the bit padding alone accounted for 21 of the 41 percentage points. Thus, we do not think that our test is about trying to "reduce the VP8 performance". Instead, the major things have been avoiding what we believe are unfortunate parameter choices for x264 on behalf of Google, and to create a technically correct test. > > Best Regards, > > Bo Burman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From internet-drafts@ietf.org Tue Oct 15 12:34:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29E611E81E6; Tue, 15 Oct 2013 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6sUw6D6xUuw; Tue, 15 Oct 2013 12:34:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FE911E8149; Tue, 15 Oct 2013 12:34:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015193400.2172.18468.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 12:34:00 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-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, 15 Oct 2013 19:34:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : WebRTC Audio Codec and Processing Requirements Author(s) : Jean-Marc Valin Cary Bran Filename : draft-ietf-rtcweb-audio-03.txt Pages : 6 Date : 2013-10-15 Abstract: This document outlines the audio codec and processing requirements for WebRTC client application and endpoint devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-audio-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-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 suhasietf@gmail.com Tue Oct 15 17:10:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA94621F9FB0 for ; Tue, 15 Oct 2013 17:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_33=0.6, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnFGRf5xOKCM for ; Tue, 15 Oct 2013 17:10:57 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8319321F9D09 for ; Tue, 15 Oct 2013 17:10:56 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l12so6304633wiv.1 for ; Tue, 15 Oct 2013 17:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YFBGebjhDiKae5d76r8U1B2YndCvebj1o+vkWHb5zGk=; b=ftK822aYNzkRdDNoNAGxdASKujJiup0X8kdTf+JDmh3F93Vryt5bhdtqJh85cNjBAI ZfwOTSxF5/BQUD3wKW1M0kKRp5jTPUd5SxIBn0H0+EA4oujSyGv1Uru4pfUDbWkmfSgr TlwXIRIt0F6mCHkJajreDF+ThIF3ep8nVWYxalbqBA6DkmN4OJTTkQYFc7bczz2ir4NH JZCNo/iE5yGnTDOSMYPdDp2H7OMkBs5ippQ+e5E/tVcRZ9owOXEJR9NEhBpBcmUK4d/q Oav0eyvpC0o0FCBNzZcOpJpFpvzpQtm63AN/fkv1KeQd1bWiIvK+GOInppyYAgt0arka KbtA== MIME-Version: 1.0 X-Received: by 10.180.185.101 with SMTP id fb5mr19708107wic.11.1381882255377; Tue, 15 Oct 2013 17:10:55 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Tue, 15 Oct 2013 17:10:55 -0700 (PDT) Date: Tue, 15 Oct 2013 17:10:55 -0700 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" , Adam Roach , Martin Thomson , Paul Kyzivat , Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2448ef4086904e8d0881d Subject: [rtcweb] POF-iPAN-PAN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 00:10:58 -0000 --001a11c2448ef4086904e8d0881d Content-Type: text/plain; charset=ISO-8859-1 Hi All I changed the subject line to extend and discuss some of the issues raised with POF/PAN and group membership side-effects There is a new term - iPAN - Interim Partial Answer - that is introduced to avoid glare. But before jumping into iPAN, I have included few examples from Adam's email earlier on what i also feel as the least ambiguous solution while dealing with group membership when adding new stream under non-glare situation *Original SDP* v=0 o=Laura 289083124 289083124 IN IP4 one.example.com c=IN IP4 192.0.2.1 t=0 0 a=group:LS first second m=audio 30000 RTP/AVP 0 a=mid:first m=video 30002 RTP/AVP 31 a=mid:second If this is the new m=line that needs to be added, m=video 30004 RTP/AVP 31 a=mid:third *a=context:group:LS: first second* ( so what ever comes after the context is the one we need to match it against, in this case, it is the entire group line that gets impacted) So for another interesting example from RFC595) a=group:FEC-FR S1 R1 a=group:FEC-FR S1 S2 R2 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=rtpmap:100 MP2T/90000 a=mid:S1 m=video 30000 RTP/AVP 101 c=IN IP4 233.252.0.2/127 a=rtpmap:101 MP2T/90000 a=mid:S2 m=application 30000 RTP/AVP 110 c=IN IP4 233.252.0.3/127 a=rtpmap:110 1d-interleaved-parityfec/90000 a=fmtp:110 L=5; D=10; repair-window=200000 a=mid:R1 m=application 30000 RTP/AVP 111 c=IN IP4 233.252.0.4/127 a=rtpmap:111 1d-interleaved-parityfec/90000 a=fmtp:111 L=10; D=10; repair-window=400000 a=mid:R2 Now if i plan to add following m=line using POF m=application 30000 RTP/AVP 110 c=IN IP4 233.252.0.3/127 a=rtpmap:110 1d-interleaved-parityfec/90000 a=fmtp:110 L=5; D=10; repair-window=200000 a=mid:R3 * a=context:group:FEC-FR S1 S2 S3* This would ambiguously identifies the membership to be the second FEC-FR group line *Glare Situation* Now moving to the glare situation, we define iPAN as "partial expected answer for the POF sent by the Offerer." Let's say Originally, we had, a=group:BUNDLE one two m=**** a=mid:one m=**** a=mid:two Alice's POF Add m=line with mid three to BUNDLE and Bob's POF (at the same time) Remove m=line with mid=two from BUNDLE Now neither Alice or Bob can't process each others POF since they are awaiting PANs for their POFs To resolve this , we can use iPAN as given below for Alice So Alice --> Installs iPAN as the answer that is expected for her POF Send her POF to Bob On receiving Bob's POF process it as new POF/PAN. (Since Bob is also following the same steps, he will eventually respond to Alice's POF) On receiving PAN from Bob, verify if it is valid if invalid, send a new POF with rejected state otherwise, you are good to go Bob --> Similar set of procedures are performed to resolve glare. Also to mention, even when Partial Offers are awaiting Partial Answers for the same m= section, it might not be a glare situation , say for example, it the m=lines are updated to included/remove sources (a=ssrcs) This situation is directionality sensitive and hence not impacted by glare as such. Cheers Suhas --001a11c2448ef4086904e8d0881d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All

=A0 =A0I changed the subject line to extend and discuss some of th= e issues raised with POF/PAN and group membership side-effects

There is a new term - iPAN - Interim Partial Answer - t= hat is introduced to avoid glare.

But before jumping into= iPAN, I have included few examples from Adam's email earlier on what i= also feel as the least=A0ambiguous solution while dealing with group membe= rship when adding new stream under non-glare situation
Original SDP
v=3D0
o= =3DLaura 289083124 289083124 IN IP4 one.example.com
c= =3DIN IP4 192.0.2.1
t=3D0 0
a=3Dgroup:LS first second
m= =3Daudio 30000 RTP/AVP 0
a=3Dmid:first
m=3Dvideo 30002 RT= P/AVP 31
a= =3Dmid:second

<= /font>
If this is the new m=3Dl= ine that needs to be added,
m=3Dvideo=A030004 RTP/A= VP 31
a=3Dmid:third
a=3Dcontex= t:group:LS: first second

( so what ever comes after the context is the one we need = to match it against, in this case, it is the entire group line that gets im= pacted)

So for an= other interesting example from RFC595)
        a=3Dgroup:FEC-FR S1 R1
        a=3Dgroup:FEC-FR S1 S2 R2
        m=3Dvideo 30000 RTP/AVP 100
        c=3DIN IP4 233.252.0.1/127
        a=3Drtpmap:100 MP2T/90000
        a=3Dmid:S1
        m=3Dvideo 30000 RTP/AVP 101
        c=3DIN IP4 233.252.0.2/127
        a=3Drtpmap:101 MP2T/90000
        a=3Dmid:S2
        m=3Dapplication 30000 RTP/AVP 110
        c=3DIN IP4 233.252.0.3/127
        a=3Drtpmap:110 1d-interleaved-parityfec/90000
        a=3Dfmtp:110 L=3D5; D=3D10; repair-window=3D200000
        a=3Dmid:R1
        m=3Dapplication 30000 RTP/AVP 111
        c=3DIN IP4 233.252.0.4/127
        a=3Drtpmap:111 1d-interleaved-parityfec/90000
        a=3Dfmtp:111 L=3D10; D=3D10; repair-window=3D400000
        a=3Dmid:R2

Now if i pla= n to add following m=3Dline using POF
        m=3Dapplicati=
on 30000 RTP/AVP 110
        c=3DIN IP4 233.252.0.3/127
        a=3Drtpmap:110 1d-interleaved-parityfec/90000
        a=3Dfmtp:110 L=3D5; D=3D10; repair-window=3D200000
        a=3Dmid:R3
        a=3Dcontext:group:FEC-FR S1 S2 S3

This would ambiguously identifies the member=
ship to be the second FEC-FR group line

Glare Situation
Now moving to the gl=
are situation,=A0
we d=
efine iPAN as "partial expected answer for the POF sent by the Offerer=
."

=

Let&=
#39;s say   Originally, we had,


a=3Dgroup:BUND=
LE one two
m=3D****
a=
=3Dmid:one
m=3D****
a=3Dmid:two

Alice's POF
Add m=3Dline with mid three to BUNDLE

and 
Bob=
9;s POF  (at the same time)
Remove m=3Dline with mid=3Dtwo from BUNDL=
E

Now neither Alice or Bob can't proces=
s each others POF since they are awaiting PANs for their POFs
<= pre class=3D"" style=3D"margin-top:0px;margin-bottom:0px">
To resolve this , we can use iPAN as given b=
elow for Alice 
 So Alice -->=A0
              Installs iPAN as the answe=
r that is expected for her POF


              Send her POF to Bob
              On receiving Bob's POF pro=
cess it as new POF/PAN.


              (Since Bob is also following th=
e same steps, he will eventually respond 
                to Alice'=
s POF)
               On receivin=
g PAN from Bob, verify if it is valid


               if invalid, send a new POF wit=
h rejected state
               otherwise, you=
 are good to go
     
<=
/pre>

    Bob --> Similar set of procedures are performed to=
 resolve glare.

Also t=
o mention, even when Partial Offers are awaiting Partial Answers for the sa=
me m=3D section, it might not be a glare situation , say for example, it th=
e m=3Dlines are updated to included/remove sources (a=3Dssrcs) 

   This situation is directionality sensitive and hence n=
ot impacted by glare as such.



<=
/pre>
Cheers
Suh=
as
--001a11c2448ef4086904e8d0881d-- From hangzhou.chenxin@huawei.com Tue Oct 15 23:04:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9029111E80F9 for ; Tue, 15 Oct 2013 23:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjn6U1ymHSKC for ; Tue, 15 Oct 2013 23:04:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD1B11E80FC for ; Tue, 15 Oct 2013 23:04:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZC96501; Wed, 16 Oct 2013 06:04:31 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 07:03:36 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 07:04:22 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0146.000; Wed, 16 Oct 2013 14:04:15 +0800 From: "Chenxin (Xin)" To: Parthasarathi R , "'Christer Holmberg'" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHOyRG+14fmt6ButUmt5DEypMFDB5n2lTUA Date: Wed, 16 Oct 2013 06:04:15 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> In-Reply-To: <00d601cec911$b0fd4b60$12f7e220$@co.in> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 06:04:47 -0000 Hi Christer, +1. I think we should wait for the result of PNTAW@ietf.org discussion be= fore modifying the related use case and requirement. there seems no clear c= onsensus by now.=20 The related use case is 3.3.2 , F29 , 3.3.3 and F37. Best Regards, Xin=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f >Parthasarathi R >Sent: Tuesday, October 15, 2013 3:15 AM >To: 'Christer Holmberg'; rtcweb@ietf.org >Subject: [rtcweb] Query/Comment on >draft-ietf-rtcweb-use-cases-and-requirements-12 > >Hi Christer & all, > >In PNTAW mailing list, there is a discussion on firewall blocking incoming >TCP traffic when the firewall blocks UDP or allows only HTTP traffic. The >related link is >http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. > >Could you please clarify whether F29 & F37 requirement implicitly indicate= s >that incoming TCP/HTTP traffic is blocked for browser when these >requirements are met. If so, Please update the below requirement text with >those details. > >Thanks >Partha > >Note: > >---------------------------------------------------------------- > F29 The browser must be able to send streams and > data to a peer in the presence of NATs that > block UDP traffic. > >---------------------------------------------------------------- > F37 The browser must be able to send streams and > data to a peer in the presence of FWs that only > allows traffic via a HTTP Proxy, when FW policy > allows WebRTC traffic. > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Oct 16 01:02:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D8F11E8117 for ; Wed, 16 Oct 2013 01:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXHugCAAan6f for ; Wed, 16 Oct 2013 01:02:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFAC21F9BD0 for ; Wed, 16 Oct 2013 01:02:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-77-525e480cfb66 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4A.FE.16099.C084E525; Wed, 16 Oct 2013 10:02:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 10:02:20 +0200 From: Christer Holmberg To: "Chenxin (Xin)" , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHOyjWVN5kp1LzBPE2VjgDW3Xis9Jn293kg Date: Wed, 16 Oct 2013 08:02:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrS6PR1yQwb2XmhY3r/QyWkz+1Mdq sfZfO7sDs0fLkbesHkuW/GTy+DD/C3sAcxSXTUpqTmZZapG+XQJXxvPtzYwF+/gqFp9xbWC8 wt3FyMkhIWAisa/1DguELSZx4d56ti5GLg4hgcOMEjdnTmaEcJYwSiyeNpW9i5GDg03AQqL7 nzZIXESgjVHi+L33jCDdwgIREmfm3WUFsUUEIiVudl9jgbCNJM5cawSzWQRUJU5PbQSr5xXw lbg0fTUL3Lav166ANXMKhEl0PJnJDmIzAp30/dQaJhCbWUBc4taT+UwQpwpILNlznhnCFpV4 +fgfK8hxEgKKEsv75SDKdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ1FpKWWUhaZiFp WcDIsoqRPTcxMye93HATIzA+Dm75rbuD8dQ5kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUX leakFh9iZOLglGpgrHjH8P3w78D0laoHD1Q2yhR/sPqtaNjFWbxi460bX1lYyzbnnYjdsLNI ynrno1bH89vPbynYHMP8L7xRQ9x/YtnG+Wobv5mc/XKtd4nmXvfL743v+PGW5vJUq0V9Ubr+ Mtk1JNf7ppNhcffDX/tsok53LO55xFAa5szCxCL07baoYXjEBJPHSizFGYmGWsxFxYkAYc+p SF0CAAA= Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:02:27 -0000 Hi, > +1. I think we should wait for the result of PNTAW@ietf.org discussion b= efore modifying the related use case and requirement. there seems no clear = consensus by now.=20 > > The related use case is 3.3.2 , F29 , 3.3.3 and F37. Consensus on what? Note that the draft is only talking about requirements. Regards, Christer >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >Behalf Of Parthasarathi R >Sent: Tuesday, October 15, 2013 3:15 AM >To: 'Christer Holmberg'; rtcweb@ietf.org >Subject: [rtcweb] Query/Comment on >draft-ietf-rtcweb-use-cases-and-requirements-12 > >Hi Christer & all, > >In PNTAW mailing list, there is a discussion on firewall blocking=20 >incoming TCP traffic when the firewall blocks UDP or allows only HTTP=20 >traffic. The related link is=20 >http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. > >Could you please clarify whether F29 & F37 requirement implicitly=20 >indicates that incoming TCP/HTTP traffic is blocked for browser when=20 >these requirements are met. If so, Please update the below requirement=20 >text with those details. > >Thanks >Partha > >Note: > >---------------------------------------------------------------- > F29 The browser must be able to send streams and > data to a peer in the presence of NATs that > block UDP traffic. > >---------------------------------------------------------------- > F37 The browser must be able to send streams and > data to a peer in the presence of FWs that only > allows traffic via a HTTP Proxy, when FW policy > allows WebRTC traffic. > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From hangzhou.chenxin@huawei.com Wed Oct 16 02:28:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFCB21F9D04 for ; Wed, 16 Oct 2013 02:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQU600Ze4ouy for ; Wed, 16 Oct 2013 02:28:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8211E8169 for ; Wed, 16 Oct 2013 02:28:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZD14843; Wed, 16 Oct 2013 09:28:22 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 10:27:29 +0100 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 10:28:21 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0146.000; Wed, 16 Oct 2013 17:28:13 +0800 From: "Chenxin (Xin)" To: Christer Holmberg , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHOyRG+14fmt6ButUmt5DEypMFDB5n2lTUA///engCAAJWaIA== Date: Wed, 16 Oct 2013 09:28:13 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:28:28 -0000 Hi Christer, >Hi, > >> +1. I think we should wait for the result of PNTAW@ietf.org discussion >before modifying the related use case and requirement. there seems no clea= r >consensus by now. >> >> The related use case is 3.3.2 , F29 , 3.3.3 and F37. > >Consensus on what? Should we just consider the case that " one of the users is behind a FW tha= t only allows traffic via a HTTP Proxy "? what will happen if there is no h= ttp proxy deployed?=20 There are two options to solve this usecase discussed in PNTAW mailing list= . "5)UDP relay candidates via some HTTP/TLS compatible transport (TURN) - M= UST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have been proposed.= " List in http://www.ietf.org/mail-archive/web/pntaw/current/msg00162.html Also there is other discussions in http://www.ietf.org/mail-archive/web/pnt= aw/current/msg00166.html.=20 That all mention that we should consider more than the http proxy scenarios= .=20 I believe that the PNTAW mailing list is used for discussion of these simil= ar transport problems, including the related use case and requirement. In t= he end , some consensus should be make to decide what problem we need handl= e and how to solve it , which will influence the use case and requirement t= o make it more clear. Is my thought right? Or miss something... Best Regards, Xin > >Note that the draft is only talking about requirements. > >Regards, > >Christer > > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>Behalf Of Parthasarathi R >>Sent: Tuesday, October 15, 2013 3:15 AM >>To: 'Christer Holmberg'; rtcweb@ietf.org >>Subject: [rtcweb] Query/Comment on >>draft-ietf-rtcweb-use-cases-and-requirements-12 >> >>Hi Christer & all, >> >>In PNTAW mailing list, there is a discussion on firewall blocking >>incoming TCP traffic when the firewall blocks UDP or allows only HTTP >>traffic. The related link is >>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. >> >>Could you please clarify whether F29 & F37 requirement implicitly >>indicates that incoming TCP/HTTP traffic is blocked for browser when >>these requirements are met. If so, Please update the below requirement >>text with those details. >> >>Thanks >>Partha >> >>Note: >> >>---------------------------------------------------------------- >> F29 The browser must be able to send streams and >> data to a peer in the presence of NATs that >> block UDP traffic. >> >>---------------------------------------------------------------- >> F37 The browser must be able to send streams and >> data to a peer in the presence of FWs that only >> allows traffic via a HTTP Proxy, when FW policy >> allows WebRTC traffic. >> >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Oct 16 02:32:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92411E8167 for ; Wed, 16 Oct 2013 02:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BAFqKXyw1OJ for ; Wed, 16 Oct 2013 02:32:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC011E817C for ; Wed, 16 Oct 2013 02:32:18 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-67-525e5d21180d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BA.D4.03802.12D5E525; Wed, 16 Oct 2013 11:32:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 11:32:17 +0200 From: Christer Holmberg To: "Chenxin (Xin)" , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHOyjWVN5kp1LzBPE2VjgDW3Xis9Jn293kg///2p4CAACJ9UA== Date: Wed, 16 Oct 2013 09:32:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra5ibFyQwcwFshY3r/QyWkz+1Mdq sfZfO7sDs0fLkbesHkuW/GTy+DD/C3sAcxSXTUpqTmZZapG+XQJXxrojy5gLbktVdC7bxNTA +EC0i5GTQ0LARKJx9kJWCFtM4sK99WxdjFwcQgKHGSVu7HgB5SxhlDgx9wlQFQcHm4CFRPc/ bZC4iEAbo8Txe+8ZQbqFBSIkzsy7CzZJRCBS4mb3NRaQehEBJ4k3+1VBwiwCqhJ//+5iAwnz CvhKTL+ZDzH+MpNE28lp7CA1nAJhEj/ad4LZjEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nGeG sEUlXj7+B3aahICixPJ+OYhyHYkFuz+xQdjaEssWvgYr5xUQlDg58wnLBEbRWUimzkLSMgtJ yywkLQsYWVYxsucmZuaklxttYgRGx8Etv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjGEz//9iF4v8Fr3+eqP8XLbNk//ExjCFZ1qFczi0rrRXFfkzu9LT tmFpoe+vi4xqfossX+ttOezudlNwzZx3l3QTv7Xub1FhO8Gr+YojMmV1ya4N0yKVdypxHT1t UPetcCvX9uoijoLg7dw3L3yR2xpUu1U9+JmpXs4S3hkd68/oSt1Yy62xQomlOCPRUIu5qDgR ACay3rhcAgAA Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:32:27 -0000 Hi Xin, So, you are saying we shouldn't finalize the use-case-requirements document= yet? Regards, Christer -----Original Message----- From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]=20 Sent: 16. lokakuuta 2013 12:28 To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requ= irements-12 Hi Christer, >Hi, > >> +1. I think we should wait for the result of PNTAW@ietf.org=20 >> discussion >before modifying the related use case and requirement. there seems no=20 >clear consensus by now. >> >> The related use case is 3.3.2 , F29 , 3.3.3 and F37. > >Consensus on what? Should we just consider the case that " one of the users is behind a FW tha= t only allows traffic via a HTTP Proxy "? what will happen if there is no h= ttp proxy deployed?=20 There are two options to solve this usecase discussed in PNTAW mailing list= . "5)UDP relay candidates via some HTTP/TLS compatible transport (TURN) - M= UST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have been proposed.= " List in http://www.ietf.org/mail-archive/web/pntaw/current/msg00162.html Also there is other discussions in http://www.ietf.org/mail-archive/web/pnt= aw/current/msg00166.html.=20 That all mention that we should consider more than the http proxy scenarios= .=20 I believe that the PNTAW mailing list is used for discussion of these simil= ar transport problems, including the related use case and requirement. In t= he end , some consensus should be make to decide what problem we need handl= e and how to solve it , which will influence the use case and requirement t= o make it more clear. Is my thought right? Or miss something... Best Regards, Xin > >Note that the draft is only talking about requirements. > >Regards, > >Christer > > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 >>Behalf Of Parthasarathi R >>Sent: Tuesday, October 15, 2013 3:15 AM >>To: 'Christer Holmberg'; rtcweb@ietf.org >>Subject: [rtcweb] Query/Comment on >>draft-ietf-rtcweb-use-cases-and-requirements-12 >> >>Hi Christer & all, >> >>In PNTAW mailing list, there is a discussion on firewall blocking=20 >>incoming TCP traffic when the firewall blocks UDP or allows only HTTP=20 >>traffic. The related link is=20 >>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. >> >>Could you please clarify whether F29 & F37 requirement implicitly=20 >>indicates that incoming TCP/HTTP traffic is blocked for browser when=20 >>these requirements are met. If so, Please update the below requirement=20 >>text with those details. >> >>Thanks >>Partha >> >>Note: >> >>---------------------------------------------------------------- >> F29 The browser must be able to send streams and >> data to a peer in the presence of NATs that >> block UDP traffic. >> >>---------------------------------------------------------------- >> F37 The browser must be able to send streams and >> data to a peer in the presence of FWs that only >> allows traffic via a HTTP Proxy, when FW policy >> allows WebRTC traffic. >> >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Oct 16 05:16:51 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B304811E8235 for ; Wed, 16 Oct 2013 05:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.916 X-Spam-Level: X-Spam-Status: No, score=-3.916 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-58VtVfoL4r for ; Wed, 16 Oct 2013 05:16:45 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id AEFEC11E81D9 for ; Wed, 16 Oct 2013 05:16:40 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-28-525e839a92f0 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.B9.25272.A938E525; Wed, 16 Oct 2013 14:16:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 14:16:25 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AMtSyPQ Date: Wed, 16 Oct 2013 12:16:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4C0339ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvre6s5rgggx2PJCw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxsyti1kL/plWNK34zNLA+EOv i5GDQ0LARGLxDiCTE8gUk7hwbz1bFyMXh5DAUUaJs99+MEI4SxglHux7ywzSwCZgIdH9Txuk QURAXeLywwvsIDazQIXEmo+rwWxhAQeJRfNOsULUOEps3fGZCaRVRMBI4vwXGZAwi4CqxNw3 DcwgNq+Ar8SvmavZQGwhILvp2SUwm1PAT+LZ6rlgYxiBbvt+ag0TxCpxiVtP5jNB3CwgsWTP eWYIW1Ti5eN/rBBvKUos75eDKM+XWDF/LQvEKkGJkzOfsExgFJ2FZNIsJGWzkJRBxHUkFuz+ xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwcxanFSbnpRgabGIHRdXDLb4sdjJf/2hxilOZgURLn /fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY0v3qX01Jm2fOvK2iDNtWTzNK/VP6VWO tGDBrIsdf7s33SnIdK1y+DpT4YRtyIvoQ786n+kW3zng9uTGzZSbXyv3mWm/2122P632KWPn 04YLJm9/F/LzTZd8v6HG/Gnjrsvb+C52zjr9OsXUVvXnRDtNXbW2xcYbjPzLP0kzLj/35JR1 /4TAO0osxRmJhlrMRcWJAMcc9G98AgAA Cc: "Cullen Jennings \(fluffy@cisco.com\)" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 12:16:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4C0339ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Any comments on this issue? I'd like to have some e-mail discussions before= Vancouver. I'd also like it to be listed as an issue - unless, of course, I have misse= d something, and it really isn't an issue :) Regards, Christer From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 30. syyskuuta 2013 11:08 To: rtcweb@ietf.org Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Hi, JSEP talks about the usage of multiple PeerConnection to support forking, i= .e. for each new forked leg (SIP: early dialog) a new PeerConnection is cre= ated. As has been indicated, as each new PeerConnection will have its own set of = address properties, ICE properties etc, so a new Offer will have to be crea= ted and sent to inform the remote about the new properties. So far so I good. I also assume that the same camera/mic/etc sources are connection to each P= eerConnection, so the number of m- lines in the Offer of the new PeerConnec= tion should be the same. However, according the 3264, the ORDER of the m- lines also need to be kept= the same. So, my question is: how can I ensure that the order of the m- lines in an O= ffer for a new PeerConnection is the same as in an Offer for an old PeerCon= nection? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4C0339ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Any comments on this i= ssue? I’d like to have some e-mail discussions before Vancouver.=

 

I’d also like it= to be listed as an issue – unless, of course, I have missed somethin= g, and it really isn’t an issue :)

 

Regards,

 

Christer

 

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 30. syyskuuta 2013 11:08
To: rtcweb@ietf.org
Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnection= s

 

Hi,

 

JSEP talks about the usage of multiple PeerConnectio= n to support forking, i.e. for each new forked leg (SIP: early dialog) a ne= w PeerConnection is created.

 

As has been indicated, as each new PeerConnection wi= ll have its own set of address properties, ICE properties etc, so a new Off= er will have to be created and sent to inform the remote about the new prop= erties.

 

So far so I good.

 

I also assume that the same camera/mic/etc sources a= re connection to each PeerConnection, so the number of m- lines in the Offe= r of the new PeerConnection should be the same.

 

However, according the 3264, the ORDER of the m- = lines also need to be kept the same.

 

So, my question is: how can I ensure that the order = of the m- lines in an Offer for a new PeerConnection is the same as in an O= ffer for an old PeerConnection?

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4C0339ESESSMB209erics_-- From andrew.hutton@unify.com Wed Oct 16 11:07:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7437011E8147 for ; Wed, 16 Oct 2013 11:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8WapiAd3BW4 for ; Wed, 16 Oct 2013 11:07:38 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 19F2911E813D for ; Wed, 16 Oct 2013 11:07:37 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id D56A023F0564; Wed, 16 Oct 2013 20:07:36 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 20:06:55 +0200 From: "Hutton, Andrew" To: Christer Holmberg , "Chenxin (Xin)" , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHOyRG+14fmt6ButUmt5DEypMFDB5n2lTUA///engCAAJWaIP//6BwAgACvbGA= Date: Wed, 16 Oct 2013 18:07:36 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BF5B80@MCHP04MSX.global-ad.net> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 18:07:42 -0000 Hi Xin, I see the PNTAW mailing list as being there to discuss potential solutions = to these requirements which are documented in the use case draft. The requirement F37 is specific to the case when there is a HTTP Proxy and = F27 would include the case when there is no proxy. Do you see other use cases and requirements that need to be explicitly brou= ght out in draft-ietf-rtcweb-use-cases-and-requirements? Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: 16 October 2013 10:32 > To: Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org > Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- > requirements-12 >=20 > Hi Xin, >=20 > So, you are saying we shouldn't finalize the use-case-requirements > document yet? >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com] > Sent: 16. lokakuuta 2013 12:28 > To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org > Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- > requirements-12 >=20 > Hi Christer, >=20 > >Hi, > > > >> +1. I think we should wait for the result of PNTAW@ietf.org > >> discussion > >before modifying the related use case and requirement. there seems no > >clear consensus by now. > >> > >> The related use case is 3.3.2 , F29 , 3.3.3 and F37. > > > >Consensus on what? >=20 > Should we just consider the case that " one of the users is behind a FW > that only allows traffic via a HTTP Proxy "? what will happen if there > is no http proxy deployed? >=20 > There are two options to solve this usecase discussed in PNTAW mailing > list. "5)UDP relay candidates via some HTTP/TLS compatible transport > (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have > been proposed." List in http://www.ietf.org/mail- > archive/web/pntaw/current/msg00162.html > Also there is other discussions in http://www.ietf.org/mail- > archive/web/pntaw/current/msg00166.html. >=20 > That all mention that we should consider more than the http proxy > scenarios. >=20 > I believe that the PNTAW mailing list is used for discussion of these > similar transport problems, including the related use case and > requirement. In the end , some consensus should be make to decide what > problem we need handle and how to solve it , which will influence the > use case and requirement to make it more clear. Is my thought right? > Or miss something... >=20 > Best Regards, > Xin > > > >Note that the draft is only talking about requirements. > > > >Regards, > > > >Christer > > > > > >>-----Original Message----- > >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>Behalf Of Parthasarathi R > >>Sent: Tuesday, October 15, 2013 3:15 AM > >>To: 'Christer Holmberg'; rtcweb@ietf.org > >>Subject: [rtcweb] Query/Comment on > >>draft-ietf-rtcweb-use-cases-and-requirements-12 > >> > >>Hi Christer & all, > >> > >>In PNTAW mailing list, there is a discussion on firewall blocking > >>incoming TCP traffic when the firewall blocks UDP or allows only HTTP > >>traffic. The related link is > >>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. > >> > >>Could you please clarify whether F29 & F37 requirement implicitly > >>indicates that incoming TCP/HTTP traffic is blocked for browser when > >>these requirements are met. If so, Please update the below > requirement > >>text with those details. > >> > >>Thanks > >>Partha > >> > >>Note: > >> > >>---------------------------------------------------------------- > >> F29 The browser must be able to send streams and > >> data to a peer in the presence of NATs that > >> block UDP traffic. > >> > >>---------------------------------------------------------------- > >> F37 The browser must be able to send streams and > >> data to a peer in the presence of FWs that only > >> allows traffic via a HTTP Proxy, when FW policy > >> allows WebRTC traffic. > >> > >>_______________________________________________ > >>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 hangzhou.chenxin@huawei.com Wed Oct 16 18:43:26 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5704111E81B0 for ; Wed, 16 Oct 2013 18:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB7XD67Ro7pI for ; Wed, 16 Oct 2013 18:43:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C3CB411E8216 for ; Wed, 16 Oct 2013 18:43:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZD70224; Thu, 17 Oct 2013 01:43:12 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 02:42:17 +0100 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 02:43:11 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0146.000; Thu, 17 Oct 2013 09:43:03 +0800 From: "Chenxin (Xin)" To: Christer Holmberg , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHOyRG+14fmt6ButUmt5DEypMFDB5n2lTUA///engCAAJWaIP//g4cAgAGSCmA= Date: Thu, 17 Oct 2013 01:43:02 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE039768082941@SZXEMA504-MBX.china.huawei.com> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 01:43:26 -0000 Hi Christer, That is not my purpose . I just want this document less ambiguous. I wil= l try to figure out the things that need to consider in the use case and re= quirement based on the discussion in the pntaw. so we could decide if it is= need to add ,modify or just keep . Best Regards, Xin=20 >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Wednesday, October 16, 2013 5:32 PM >To: Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org >Subject: RE: [rtcweb] Query/Comment on >draft-ietf-rtcweb-use-cases-and-requirements-12 > >Hi Xin, > >So, you are saying we shouldn't finalize the use-case-requirements documen= t >yet? > >Regards, > >Christer > >-----Original Message----- >From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com] >Sent: 16. lokakuuta 2013 12:28 >To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org >Subject: RE: [rtcweb] Query/Comment on >draft-ietf-rtcweb-use-cases-and-requirements-12 > >Hi Christer, > >>Hi, >> >>> +1. I think we should wait for the result of PNTAW@ietf.org >>> discussion >>before modifying the related use case and requirement. there seems no >>clear consensus by now. >>> >>> The related use case is 3.3.2 , F29 , 3.3.3 and F37. >> >>Consensus on what? > >Should we just consider the case that " one of the users is behind a FW th= at only >allows traffic via a HTTP Proxy "? what will happen if there is no http pr= oxy >deployed? > >There are two options to solve this usecase discussed in PNTAW mailing lis= t. >"5)UDP relay candidates via some HTTP/TLS compatible transport (TURN) - >MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have been >proposed." List in >http://www.ietf.org/mail-archive/web/pntaw/current/msg00162.html >Also there is other discussions in >http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. > >That all mention that we should consider more than the http proxy scenario= s. > >I believe that the PNTAW mailing list is used for discussion of these simi= lar >transport problems, including the related use case and requirement. In the= end , >some consensus should be make to decide what problem we need handle and >how to solve it , which will influence the use case and requirement to mak= e it >more clear. Is my thought right? Or miss something... > >Best Regards, > Xin >> >>Note that the draft is only talking about requirements. >> >>Regards, >> >>Christer >> >> >>>-----Original Message----- >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>Behalf Of Parthasarathi R >>>Sent: Tuesday, October 15, 2013 3:15 AM >>>To: 'Christer Holmberg'; rtcweb@ietf.org >>>Subject: [rtcweb] Query/Comment on >>>draft-ietf-rtcweb-use-cases-and-requirements-12 >>> >>>Hi Christer & all, >>> >>>In PNTAW mailing list, there is a discussion on firewall blocking >>>incoming TCP traffic when the firewall blocks UDP or allows only HTTP >>>traffic. The related link is >>>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. >>> >>>Could you please clarify whether F29 & F37 requirement implicitly >>>indicates that incoming TCP/HTTP traffic is blocked for browser when >>>these requirements are met. If so, Please update the below requirement >>>text with those details. >>> >>>Thanks >>>Partha >>> >>>Note: >>> >>>---------------------------------------------------------------- >>> F29 The browser must be able to send streams and >>> data to a peer in the presence of NATs that >>> block UDP traffic. >>> >>>---------------------------------------------------------------- >>> F37 The browser must be able to send streams and >>> data to a peer in the presence of FWs that only >>> allows traffic via a HTTP Proxy, when FW policy >>> allows WebRTC traffic. >>> >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtcweb From kevindempsey70@gmail.com Thu Oct 17 01:37:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275E821F9A57 for ; Thu, 17 Oct 2013 01:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sngOetudBhHB for ; Thu, 17 Oct 2013 01:37:11 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 64B0121F9A65 for ; Thu, 17 Oct 2013 01:37:11 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so1519277lab.21 for ; Thu, 17 Oct 2013 01:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GAxG6tcceM1JXq79f14RMPaOIchqqcv4RpdmYklWgiE=; b=T935I5CyutMqeJdM36X/ddq2jbc86xpTE/mYyXumy48916JplHbdTQ4dy9mjrWEd9J /Q2GEgN+jC2TQH7xh+xqcjUFXrtvg+z6i/JHd0U9/XcssyNG0ODU0q8QxAoZdxf9ahZP mM9w2ksrV84wRVadxwlGxqQef7enWNsTjxU9djFIeOEo3+QC5h3Njw/XOhgGkdUVLLT9 d91JdcRgkXUQx1HYSyUgpEa4UMWFh/KEqAATP6LihBDtIdgY7294L77qwow8EpcwopQ0 sZvxGSxt6o4b7s5IbCsdt8lbc2c4hmGCyp/XmO57hVOShMT+1JqQXBmp+JWC+KUosYc0 QNEg== MIME-Version: 1.0 X-Received: by 10.152.170.166 with SMTP id an6mr6341533lac.20.1381999030280; Thu, 17 Oct 2013 01:37:10 -0700 (PDT) Received: by 10.114.181.226 with HTTP; Thu, 17 Oct 2013 01:37:10 -0700 (PDT) Date: Thu, 17 Oct 2013 09:37:10 +0100 Message-ID: From: Kevin Dempsey To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e0117747547a4a804e8ebb9df Subject: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 08:37:12 -0000 --089e0117747547a4a804e8ebb9df Content-Type: text/plain; charset=ISO-8859-1 The JSEP draft says that the fingerprint is REQUIRED to use sha-256 and additional fingerprints using 'stronger' hashes can be included. However, RFC 4572 says that the fingerprint hash must match the certificate's signature algorithm. Recent chrome canary builds have stopped using sha-256 and use sha-1 as that matches their certificate's signature algorithm. So: 1) does the fingerprinh hash need to match the certificate 2) do webrtc compatible endpoints need to handle hashes 'weaker' than sha-256 3) are there any rules for handling multiple fingerprints? Regards, Kevin --089e0117747547a4a804e8ebb9df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The JSEP draft says that the fingerprint is REQUIRED to us= e sha-256 and additional fingerprints using 'stronger' hashes can b= e included. However, RFC 4572 says that the fingerprint hash must match the= certificate's signature algorithm. Recent chrome canary builds have st= opped using sha-256 and use sha-1 as that matches their certificate's s= ignature algorithm.

So:
1) does the fingerprinh hash need to match the= certificate
2) do webrtc compatible endpoints need to handle has= hes 'weaker' than sha-256
3) are there any rules for hand= ling multiple fingerprints?

Regards,
Kevin
--089e0117747547a4a804e8ebb9df-- From hangzhou.chenxin@huawei.com Thu Oct 17 03:24:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ACD21F9ADD for ; Thu, 17 Oct 2013 03:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI9PwFBHkF8C for ; Thu, 17 Oct 2013 03:23:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF8611E8266 for ; Thu, 17 Oct 2013 03:23:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWW71957; Thu, 17 Oct 2013 10:23:45 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 11:22:56 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 11:23:41 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0146.000; Thu, 17 Oct 2013 18:23:37 +0800 From: "Chenxin (Xin)" To: "Hutton, Andrew" , Christer Holmberg , Parthasarathi R , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Thread-Index: AQHOypqiDFNQXq+XsEKEiGC0JWGDqZn4Hd7g Date: Thu, 17 Oct 2013 10:23:37 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE039768082A1A@SZXEMA504-MBX.china.huawei.com> References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF17BF5B80@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BF5B80@MCHP04MSX.global-ad.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.125] Content-Type: multipart/alternative; boundary="_000_9E34D50A21D1D1489134B4D770CE039768082A1ASZXEMA504MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 10:24:00 -0000 --_000_9E34D50A21D1D1489134B4D770CE039768082A1ASZXEMA504MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, I think you means F29 not F27:). When I read it , I realize that there is= cross and ambiguous between 3.3.2 and 3.3.3 More details: The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW* that = blocks UDP". But in the description and requirement, only *NAT* is consider= ed. The topic of 3.3.3 is "Simple Video Communication Service, FW that only a= llows http", But only *http proxy* deployed scenarios is considered. There are other usecases " FW block UDP, incoming TCP, Http allowing FW w= ithout http proxy deplolyed under the permission of FW policy" , which is l= ost in the description. If we need consider these usecases , I suggest to m= ake some change to the description. Proposal 1 : add FW related words to section 3.3.2 ------------------------------------------------- 3.3.2. Simple Video Communication Service, NAT/FW that blocks UDP 3.3.2.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1). The difference is that one of the users is behind a NAT*/FW* that blocks UDP traffic. . 3.3.2.2. Additional Requirements F29 The browser must be able to send streams and data to a peer in the presence of NATs *and FWs* that block UDP traffic ,* when FW policy allows WebRTC traffic*. ------------------------------------------------------- Proposal 2: If the" Http allowing FW without http proxy deployed" case i= s impliedly included in F29. I suggest to change the topics of 3.3.3 to "Si= mple Video Communication Service, FW that only allows traffic via a http pr= oxy". So the 3.3.3 is a specific case. Proposal 3: If " Http allowing FW without http proxy deployed" case nee= d to be explicitly mentioned. I suggest to add some descriptions to 3.3.3 ----------------------------------------------------------------- 3.3.3. Simple Video Communication Service, FW that only allows http 3.3.3.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1). The difference is that one of the users is behind a http allowing FW or a FW that only allows traffic via = a HTTP Proxy. 3.3.3.2. Additional Requirements F37 The browser must be able to send streams and data to a peer in the presence of http allowing FWs or FWs that = only allows traffic via a HTTP Proxy, when FW policy allows WebRTC traffic. ------------------------------------------------------------------- Best Regards, Xin >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@unify.com] >Sent: Thursday, October 17, 2013 2:08 AM >To: Christer Holmberg; Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org >Subject: RE: [rtcweb] Query/Comment on >draft-ietf-rtcweb-use-cases-and-requirements-12 > >Hi Xin, > >I see the PNTAW mailing list as being there to discuss potential solutions= to >these requirements which are documented in the use case draft. > >The requirement F37 is specific to the case when there is a HTTP Proxy and= F27 >would include the case when there is no proxy. > >Do you see other use cases and requirements that need to be explicitly bro= ught >out in draft-ietf-rtcweb-use-cases-and-requirements? > >Regards >Andy > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: 16 October 2013 10:32 >> To: Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org >> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- >> requirements-12 >> >> Hi Xin, >> >> So, you are saying we shouldn't finalize the use-case-requirements >> document yet? >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com] >> Sent: 16. lokakuuta 2013 12:28 >> To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org >> Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- >> requirements-12 >> >> Hi Christer, >> >> >Hi, >> > >> >> +1. I think we should wait for the result of PNTAW@ietf.org >> >> discussion >> >before modifying the related use case and requirement. there seems no >> >clear consensus by now. >> >> >> >> The related use case is 3.3.2 , F29 , 3.3.3 and F37. >> > >> >Consensus on what? >> >> Should we just consider the case that " one of the users is behind a FW >> that only allows traffic via a HTTP Proxy "? what will happen if there >> is no http proxy deployed? >> >> There are two options to solve this usecase discussed in PNTAW mailing >> list. "5)UDP relay candidates via some HTTP/TLS compatible transport >> (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets >have >> been proposed." List in http://www.ietf.org/mail- >> archive/web/pntaw/current/msg00162.html >> Also there is other discussions in http://www.ietf.org/mail- >> archive/web/pntaw/current/msg00166.html. >> >> That all mention that we should consider more than the http proxy >> scenarios. >> >> I believe that the PNTAW mailing list is used for discussion of these >> similar transport problems, including the related use case and >> requirement. In the end , some consensus should be make to decide what >> problem we need handle and how to solve it , which will influence the >> use case and requirement to make it more clear. Is my thought right? >> Or miss something... >> >> Best Regards, >> Xin >> > >> >Note that the draft is only talking about requirements. >> > >> >Regards, >> > >> >Christer >> > >> > >> >>-----Original Message----- >> >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> >>Behalf Of Parthasarathi R >> >>Sent: Tuesday, October 15, 2013 3:15 AM >> >>To: 'Christer Holmberg'; rtcweb@ietf.org >> >>Subject: [rtcweb] Query/Comment on >> >>draft-ietf-rtcweb-use-cases-and-requirements-12 >> >> >> >>Hi Christer & all, >> >> >> >>In PNTAW mailing list, there is a discussion on firewall blocking >> >>incoming TCP traffic when the firewall blocks UDP or allows only HTTP >> >>traffic. The related link is >> >>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. >> >> >> >>Could you please clarify whether F29 & F37 requirement implicitly >> >>indicates that incoming TCP/HTTP traffic is blocked for browser when >> >>these requirements are met. If so, Please update the below >> requirement >> >>text with those details. >> >> >> >>Thanks >> >>Partha >> >> >> >>Note: >> >> >> >>---------------------------------------------------------------- >> >> F29 The browser must be able to send streams and >> >> data to a peer in the presence of NATs that >> >> block UDP traffic. >> >> >> >>---------------------------------------------------------------- >> >> F37 The browser must be able to send streams and >> >> data to a peer in the presence of FWs that only >> >> allows traffic via a HTTP Proxy, when FW policy >> >> allows WebRTC traffic. >> >> >> >>_______________________________________________ >> >>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_9E34D50A21D1D1489134B4D770CE039768082A1ASZXEMA504MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

  I think you means F29= not F27:). When I read it , I realize that there is cross and ambiguous be= tween 3.3.2 and 3.3.3

 

  More details:

 

  The topic of 3.3.2 is= "Simple Video Communication Service, *NAT/FW* that blocks UDP". = But in the description and requirement, only *NAT* is considered.

  The topic of 3.3.3 is= "Simple Video Communication Service, FW that only allows http", = But only *http proxy* deployed scenarios is considered.

 

  There are other useca= ses " FW block UDP, incoming TCP, Http allowing FW without http proxy = deplolyed under the permission of FW policy" , which is lost in the de= scription. If we need consider these usecases , I suggest to make some change to the description.

 

  Proposal 1 :

 

  add FW related words = to section 3.3.2

----------------------------= ---------------------

3.3.2.  Simple Video Co= mmunication Service, NAT/FW that blocks UDP

 

3.3.2.1.  Description

 

   This use-case i= s almost identical to the Simple Video Communication

   Service use-cas= e (Section 3.3.1).  The difference is that one of the

   users is behind= a NAT*/FW* that blocks UDP traffic.

.

 

3.3.2.2.  Additional Re= quirements

 

   F29   = ;  The browser must be able to send streams and=

    &nbs= p;      data to a peer in the presence of NATs *an= d FWs* that

    &nbs= p;      block UDP traffic ,* when FW policy allows= WebRTC traffic*.

----------------------------= ---------------------------

   Proposal 2: If = the" Http allowing FW without http proxy deployed" case is implie= dly included in F29. I suggest to change the topics of 3.3.3 to "Simpl= e Video Communication Service, FW that only allows traffic via a http proxy". So the 3.3.3 is a specific case.

 

    Proposal = 3: If " Http allowing FW without http proxy deployed" case need t= o be explicitly mentioned. I suggest to add some descriptions to 3.3.3=

----------------------------= -------------------------------------

3.3.3.  Simple Video Co= mmunication Service, FW that only allows http

 

3.3.3.1.  Description

 

   This use-case i= s almost identical to the Simple Video Communication

   Service use-cas= e (Section 3.3.1).  The difference is that one of the

   users is behind= a http allowing FW or a FW that only allows traffic via a HTTP Proxy.=

 

3.3.3.2.  Additional Re= quirements

 

   F37  =    The browser must be able to send streams and=

    &nbs= p;      data to a peer in the presence of http all= owing FWs or FWs that only

    &nbs= p;      allows traffic via a HTTP Proxy, when FW p= olicy

    &nbs= p;      allows WebRTC traffic.

----------------------------= ---------------------------------------

 

 

Best Regards,

     Xin=

 

 

>-----Original Message---= --

>From: Hutton, Andrew [ma= ilto:andrew.hutton@unify.com]

>Sent: Thursday, October = 17, 2013 2:08 AM

>To: Christer Holmberg; C= henxin (Xin); Parthasarathi R; rtcweb@ietf.org

>Subject: RE: [rtcweb] Qu= ery/Comment on

>draft-ietf-rtcweb-use-ca= ses-and-requirements-12

> =

>Hi Xin,

> =

>I see the PNTAW mailing = list as being there to discuss potential solutions to

>these requirements which= are documented in the use case draft.

> =

>The requirement F37 is s= pecific to the case when there is a HTTP Proxy and F27

>would include the case w= hen there is no proxy.

> =

>Do you see other use cas= es and requirements that need to be explicitly brought

>out in draft-ietf-rtcweb= -use-cases-and-requirements?

> =

>Regards

>Andy

> =

> =

>> -----Original Messa= ge-----

>> From: rtcweb-bounce= s@ietf.org [mailto:rtcweb-bounces@ietf.org] On

>> Behalf Of Christer = Holmberg

>> Sent: 16 October 20= 13 10:32

>> To: Chenxin (Xin); = Parthasarathi R; rtcweb@ietf.org

>> Subject: Re: [rtcwe= b] Query/Comment on draft-ietf-rtcweb-use-cases-and-

>> requirements-12

>> 

>> Hi Xin,<= /span>

>> 

>> So, you are saying = we shouldn't finalize the use-case-requirements

>> document yet?<= /o:p>

>> 

>> Regards,=

>> 

>> Christer=

>> 

>> -----Original Messa= ge-----

>> From: Chenxin (Xin)= [mailto:hangzhou.chenxin@huawei.com]

>> Sent: 16. lokakuuta= 2013 12:28

>> To: Christer Holmbe= rg; Parthasarathi R; rtcweb@ietf.org

>> Subject: RE: [rtcwe= b] Query/Comment on draft-ietf-rtcweb-use-cases-and-

>> requirements-12

>> 

>> Hi Christer,

>> 

>> >Hi,<= /span>

>> >

>> >>  += ;1. I think we should wait for the result of PNTAW@ietf.org

>> >> discussion=

>> >before modifyin= g the related use case and requirement. there seems no

>> >clear consensus= by now.

>> >>=

>> >>  The = related use case is 3.3.2 , F29 , 3.3.3 and F37.

>> >

>> >Consensus on wh= at?

>> 

>> Should we just cons= ider the case that " one of the users is behind a FW=

>> that only allows tr= affic via a HTTP Proxy "? what will happen if there<= /p>

>> is no http proxy de= ployed?

>> 

>> There are two optio= ns to solve this usecase discussed in PNTAW mailing

>> list. "5)UDP r= elay candidates via some HTTP/TLS compatible transport

>> (TURN) - MUST/SHOUL= D (TLS via HTTP CONNET or TURN over WebSockets

>have

>> been proposed."= ;  List in http://www.ietf.org/mail-

>> archive/web/pntaw/c= urrent/msg00162.html

>> Also there is other= discussions in http://www.ietf.org/mail-

>> archive/web/pntaw/c= urrent/msg00166.html.

>> 

>> That all mention th= at we should consider more than the http proxy

>> scenarios.

>> 

>> I believe that the = PNTAW mailing list is used for discussion of these

>> similar transport p= roblems, including the related use case and

>> requirement. In the= end , some consensus should be make to decide what

>> problem we need han= dle and how to solve it , which will influence the

>> use case and requir= ement to make it more clear.  Is my thought right?

>> Or miss something..= .

>> 

>> Best Regards,<= /o:p>

>>   &n= bsp;  Xin

>> >

>> >Note that the d= raft is only talking about requirements.

>> >

>> >Regards,

>> >

>> >Christer

>> >

>> >

>> >>-----Origin= al Message-----

>> >>From: rtcwe= b-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On

>> >>Behalf Of P= arthasarathi R

>> >>Sent: Tuesd= ay, October 15, 2013 3:15 AM

>> >>To: 'Christ= er Holmberg'; rtcweb@ietf.org

>> >>Subject: [r= tcweb] Query/Comment on

>> >>draft-ietf-= rtcweb-use-cases-and-requirements-12

>> >>=

>> >>Hi Christer= & all,

>> >>=

>> >>In PNTAW ma= iling list, there is a discussion on firewall blocking

>> >>incoming TC= P traffic when the firewall blocks UDP or allows only HTTP

>> >>traffic. Th= e related link is

>> >>http://www.= ietf.org/mail-archive/web/pntaw/current/msg00166.html.

>> >>=

>> >>Could you p= lease clarify whether F29 & F37 requirement implicitly

>> >>indicates t= hat incoming TCP/HTTP traffic is blocked for browser when=

>> >>these requi= rements are met. If so, Please update the below

>> requirement

>> >>text with t= hose details.

>> >>=

>> >>Thanks=

>> >>Partha=

>> >>=

>> >>Note:<= /o:p>

>> >>=

>> >>-----------= -----------------------------------------------------

>> >>  = ; F29     The browser must be able to send streams and<= o:p>

>> >>  = ;         data to a peer in the pre= sence of NATs that

>> >>  = ;         block UDP traffic.

>> >>=

>> >>-----------= -----------------------------------------------------

>> >>  F37&= nbsp;    The browser must be able to send streams and

>> >>  = ;         data to a peer in the pre= sence of FWs that only

>> >>  = ;         allows traffic via a HTTP= Proxy, when FW policy

>> >>  = ;         allows WebRTC traffic.

>> >>=

>> >>___________= ____________________________________

>> >>rtcweb mail= ing 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

--_000_9E34D50A21D1D1489134B4D770CE039768082A1ASZXEMA504MBXchi_-- From rjsparks@nostrum.com Thu Oct 17 11:34:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEAF11E82CA for ; Thu, 17 Oct 2013 11:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho2DybWVp5l2 for ; Thu, 17 Oct 2013 11:34:24 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9012D11E82D5 for ; Thu, 17 Oct 2013 11:34:23 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-224.dllstx.fios.verizon.net [173.57.89.224]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9HIYMQw024219 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Thu, 17 Oct 2013 13:34:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52602DAE.2010605@nostrum.com> Date: Thu, 17 Oct 2013 13:34:22 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------060901080300090907090900" Received-SPF: pass (shaman.nostrum.com: 173.57.89.224 is authenticated by a trusted mechanism) Subject: [rtcweb] Registration for the second SIP Forum RTCWeb interop test event is open X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:34:25 -0000 This is a multi-part message in MIME format. --------------060901080300090907090900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The Second SIP Forum RTCWeb-it will be hosted by TMC on November 18, 2013. The event will be held the Monday before the WebRTC Conference and Expo, in Santa Clara, CA. Registration for the Second SIP Forum RTCWeb-it event is open. Details about the event can be found at http://www.sipforum.org/content/view/416/294/. Please register as soon as possible at http://www.regonline.com/rtcwebit2 RjS --------------060901080300090907090900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Second SIP Forum RTCWeb-it will be hosted by TMC on November 18, 2013.
The event will be held the Monday before the WebRTC Conference and Expo, in Santa Clara, CA.
Registration for the Second SIP Forum RTCWeb-it event is open.
Details about the event can be found at http://www.sipforum.org/content/view/416/294/.
Please register as soon as possible at http://www.regonline.com/rtcwebit2

RjS
--------------060901080300090907090900-- From martin.thomson@gmail.com Thu Oct 17 11:54:27 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7914F21F9A10 for ; Thu, 17 Oct 2013 11:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coe04wxlWueB for ; Thu, 17 Oct 2013 11:54:27 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4065B11E8191 for ; Thu, 17 Oct 2013 11:54:24 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t61so2736386wes.41 for ; Thu, 17 Oct 2013 11:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ujU82CkjcI7fCp6E+RD0WE9wBXk5I1sVEQ50DZQExHU=; b=uDVqzO85WdIMpVRTLdvxrJ8YhwD+AZalQAXBtjdw5pI9PuYzdHFONRBowYbFJJzZ+/ l+HoXYTY3XwfZB/bZ9Q9+QPCfUM4r4k2Z0+7KoTqFHmUcLdLiPkn302D1WVhD89y09V2 bC0IsfnrfKlhX4li1WdD/7oGeV3PjBcK3EKKprKchN2GwW9OVRbD/EjO9aHobMNddfQp b/j3M7413EqMGZYZrIjs657BCEcTWwKRMnY5TApmS/S42NeJFrBGtzOKZqXd55n/bpTr 5G4oznvzJHjVlUhAiVJQXvicA+SbQzBJyvnt7Cq+EnOqbX9w/Rn6ByRJaMjkmRq/v1pZ BZ0A== MIME-Version: 1.0 X-Received: by 10.194.104.42 with SMTP id gb10mr8704339wjb.16.1382036063336; Thu, 17 Oct 2013 11:54:23 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Thu, 17 Oct 2013 11:54:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Oct 2013 11:54:23 -0700 Message-ID: From: Martin Thomson To: Kevin Dempsey Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:54:27 -0000 On 17 October 2013 01:37, Kevin Dempsey wrote: > 1) does the fingerprinh hash need to match the certificate Yes. Without that, you've got no binding between signaling and media path, which is bad. > 2) do webrtc compatible endpoints need to handle hashes 'weaker' than > sha-256 No. RFC 4572 is clear: A certificate fingerprint MUST be computed using the same one-way hash function as is used in the certificate's signature algorithm. That means that you need to generate the certificate with a hash that is strong enough. > 3) are there any rules for handling multiple fingerprints? RFC 4572 is silent on that, unless I missed something, which I probably did. The only plausible choice given the above statement from 4572 is to suggest that multiple a=fingerprint values indicate alternative certificates. That should probably be written down, of course. From fluffy@cisco.com Thu Oct 17 18:06:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB311E82F2 for ; Thu, 17 Oct 2013 18:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ca7yS6xnT2i for ; Thu, 17 Oct 2013 18:06:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 217CF11E82E7 for ; Thu, 17 Oct 2013 18:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1382058365; x=1383267965; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YcNrq4SSyXjT0ELUJX/xH7IYfmKxpBsexXhp60A4k6Q=; b=Z0RZ6/aZBfRpUxEXlbK9wa+bSYKdpnGz7ogQN7CJKe26ibt/uMAj1xh/ uC8E0wj3OvzIW+DHymYDHrpr9SvdRLYNDRQysGLWY6fixyOKTkuj2EE/6 Fd3BCUM9pf8dLqLy84Im2XkgzCKXFhaU4yyVO59kGIpzTSmmc5RRzT6Cz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAPyIYFKtJXG9/2dsb2JhbABagweBCr4NgSsWdIIlAQEBAwF5BQsCAQgRBAEBCx0HMhQJCAEBBA4FCId4BsB3jhiBBgIxB4MfgQcDlCeOLoc1gySBcDk X-IronPort-AV: E=Sophos;i="4.93,518,1378857600"; d="scan'208";a="273558344" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 18 Oct 2013 01:06:04 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9I1644d025242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 01:06:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 17 Oct 2013 20:06:04 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AMtSyPQAFcb2IA= Date: Fri, 18 Oct 2013 01:06:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.129] Content-Type: text/plain; charset="Windows-1252" Content-ID: <64B52131F7EF5540A9FC30209F8A6867@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 01:06:10 -0000 Perhaps in the parallel forking section, we should replace UPDATE with "INV= ITE with replaces" . Would that work ? Alternatively we could just remove the parallel forking section.=20 On Oct 16, 2013, at 5:16 AM, Christer Holmberg wrote: > Hi, > =20 > Any comments on this issue? I=92d like to have some e-mail discussions be= fore Vancouver. > =20 > I=92d also like it to be listed as an issue =96 unless, of course, I have= missed something, and it really isn=92t an issue :) > =20 > Regards, > =20 > Christer > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Christer Holmberg > Sent: 30. syyskuuta 2013 11:08 > To: rtcweb@ietf.org > Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections > =20 > Hi, > =20 > JSEP talks about the usage of multiple PeerConnection to support forking,= i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is c= reated. > =20 > As has been indicated, as each new PeerConnection will have its own set o= f address properties, ICE properties etc, so a new Offer will have to be cr= eated and sent to inform the remote about the new properties. > =20 > So far so I good. > =20 > I also assume that the same camera/mic/etc sources are connection to each= PeerConnection, so the number of m- lines in the Offer of the new PeerConn= ection should be the same. > =20 > However, according the 3264, the ORDER of the m- lines also need to be ke= pt the same. > =20 > So, my question is: how can I ensure that the order of the m- lines in an= Offer for a new PeerConnection is the same as in an Offer for an old PeerC= onnection? > =20 > Regards, > =20 > Christer > =20 From suhasietf@gmail.com Thu Oct 17 18:16:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D466D11E80F6 for ; Thu, 17 Oct 2013 18:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOTlRucZWNjf for ; Thu, 17 Oct 2013 18:16:01 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AA3AF11E8198 for ; Thu, 17 Oct 2013 18:16:00 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ey11so246586wid.0 for ; Thu, 17 Oct 2013 18:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8TH2QmQsy25AMZz7Xe9VDgGeaGIfkgKGGyGgD5tJycM=; b=j0dhurWEJmpAQFHHU5JUh+77RtS8pXdLbsrwBItjTahx567Alh5DKvSyBV+HfhURFW WtPDRDMI47/g1e+S/j8z4NciU15P18bWgGM+m+UqbVlTfhgBUUEhu5X0MEhubPY4vESd RPrnmoEBVuhkSWv/H/2OdNhDlmSE+T2FS9LCR6JxELdOG6jW72PKS+a7pogBDA6piTHF a4fRzMb+iwtlPhow0NtTOf8K57BjdFrFgpO9kyKri8c0NzVW3PScPeKlKzMQmScbK4LL E0zZpRtXOZiRZ9tIac/t1GVfPMO/TwelFGgATrQjKV+n1k1aUwqQhsXrD//MnN3qP317 eI+g== MIME-Version: 1.0 X-Received: by 10.194.20.202 with SMTP id p10mr179698wje.39.1382058959675; Thu, 17 Oct 2013 18:15:59 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Thu, 17 Oct 2013 18:15:59 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> Date: Thu, 17 Oct 2013 18:15:59 -0700 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b5d965759a80f04e8f9adfc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 01:16:02 -0000 --047d7b5d965759a80f04e8f9adfc Content-Type: text/plain; charset=ISO-8859-1 Hi Christer, One idea is to pass the Peer Connection Object to be forked as input to the Fork API when creating the new Peer Connection. This way the implementation knows that the order of m=lines must be matched to the ones in the passed in reference peer connection object .. Any thoughts ?? Thanks Suhas On Mon, Sep 30, 2013 at 1:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi,**** > > ** ** > > JSEP talks about the usage of multiple PeerConnection to support forking, > i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is > created.**** > > ** ** > > As has been indicated, as each new PeerConnection will have its own set of > address properties, ICE properties etc, so a new Offer will have to be > created and sent to inform the remote about the new properties.**** > > ** ** > > So far so I good.**** > > ** ** > > I also assume that the same camera/mic/etc sources are connection to each > PeerConnection, so the number of m- lines in the Offer of the new > PeerConnection should be the same.**** > > ** ** > > However, according the 3264, the *ORDER of the m- lines* also need to be > kept the same.**** > > ** ** > > So, my question is: how can I ensure that the order of the m- lines in an > Offer for a new PeerConnection is the same as in an Offer for an old > PeerConnection?**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b5d965759a80f04e8f9adfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer,

One idea is to pass = the Peer Connection Object to be forked as input to the Fork API when creat= ing the new Peer Connection.

This way the implementation= knows that the order of m=3Dlines must =A0 be matched to the ones in the p= assed in reference peer connection object ..

Any thoughts ??

Thanks
Suhas


On Mon, Sep 30, 2013 at 1:07 AM, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:

Hi,

=A0

JSEP talks about the usage of multiple PeerConnectio= n to support forking, i.e. for each new forked leg (SIP: early dialog) a ne= w PeerConnection is created.

=A0

As has been indicated, as each new PeerConnection wi= ll have its own set of address properties, ICE properties etc, so a new Off= er will have to be created and sent to inform the remote about the new prop= erties.

=A0

So far so I good.

=A0

I also assume that the same camera/mic/etc sources a= re connection to each PeerConnection, so the number of m- lines in the Offe= r of the new PeerConnection should be the same.

=A0

However, according the 3264, the ORDER of the m- = lines also need to be kept the same.

=A0

So, my question is: how can I ensure that the order = of the m- lines in an Offer for a new PeerConnection is the same as in an O= ffer for an old PeerConnection?

=A0

Regards,

=A0

Christer

=A0


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


--047d7b5d965759a80f04e8f9adfc-- From ekr@rtfm.com Thu Oct 17 18:39:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29911E819B for ; Thu, 17 Oct 2013 18:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb0Q6Ezk5vGe for ; Thu, 17 Oct 2013 18:39:35 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2F73711E812F for ; Thu, 17 Oct 2013 18:39:33 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id x12so2178882qcv.14 for ; Thu, 17 Oct 2013 18:39:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FYGkTtE4A6Y+RhckKXwaeTXEmKB50Ylx1RaguViJW4M=; b=NL6Ku45Eo+Ex3YGK7K/C5lnmjzeXd0BxmvLDeTF/6DeWkpox0cLuKd0i23ELnlhwxf OTpi6Dn8AsfLhnBPTy7Zb1PxsYh2qurQX+mR02mKedmgkySenCERKkJCtawIplE4U7iJ 2yIkO+S8sHZ8KIh5wq+RBaOwLgl7E8fZj1cGqX3UCLzSnDR7/RNCHN26nMoJL8DrSoot sHPXkOLJRlRjTeh9qJlaTOx/5thyp6tYR7/8OkJVo7XwUjHHMZbYg+Z5TIJEhM76c0Uz apGQFlTUX3lXkm0j2z/dbmH7NSAQDMs9Dxp8JKPh676kp3BA605ZEqwvywrDKQopQrjQ +GyQ== X-Gm-Message-State: ALoCoQkTG+1i7VDc9OkzphPjIH0Mk+5hfVdwNw4zUAGStMGG7JwtC4cUpAJDgQJ2jdFasWxD66lt X-Received: by 10.49.12.194 with SMTP id a2mr412213qec.95.1382060372649; Thu, 17 Oct 2013 18:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.120.69 with HTTP; Thu, 17 Oct 2013 18:38:52 -0700 (PDT) X-Originating-IP: [220.136.6.174] In-Reply-To: References: From: Eric Rescorla Date: Thu, 17 Oct 2013 18:38:52 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b6787d292177804e8fa0123 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 01:39:46 -0000 --047d7b6787d292177804e8fa0123 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 17, 2013 at 11:54 AM, Martin Thomson wrote: > On 17 October 2013 01:37, Kevin Dempsey wrote: > > 1) does the fingerprinh hash need to match the certificate > > Yes. Without that, you've got no binding between signaling and media > path, which is bad. > > > 2) do webrtc compatible endpoints need to handle hashes 'weaker' than > > sha-256 > > No. RFC 4572 is clear: > A certificate fingerprint MUST be computed using the same one-way > hash function as is used in the certificate's signature algorithm. > > That means that you need to generate the certificate with a hash that > is strong enough. I'm not sure this was a sensible rule on 4572, but I don't think it's particularly harmful. Here's my analysis: there are two kinds of certs in play here: - self-signed certs (most likely) - CA-signed certs (less likely) In the case of self-signed certs, you can control your digest. In the case of CA signed certs, someone is presumably going to verify the signature and so we would expect the digest used to form that signature to be reasonably strong. > 3) are there any rules for handling multiple fingerprints? > > RFC 4572 is silent on that, unless I missed something, which I > probably did. The only plausible choice given the above statement > from 4572 is to suggest that multiple a=fingerprint values indicate > alternative certificates. > > That should probably be written down, of course. > Agreed. -Ekr --047d7b6787d292177804e8fa0123 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Oct 17, 2013 at 11:54 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 17 October 2013 01:37, = Kevin Dempsey <kevindempsey7= 0@gmail.com> wrote:
> 1) does the fingerprinh hash need to match the certificate

Yes. =A0Without that, you've got no binding between signaling and= media
path, which is bad.

> 2) do webrtc compatible endpoints need to handle hashes 'weaker= 9; than
> sha-256

No. =A0RFC 4572 is clear:
=A0 =A0A certificate fingerprint MUST be computed using the same one-way =A0 =A0hash function as is used in the certificate's signature algorith= m.

That means that you need to generate the certificate with a hash that
is strong enough.

I'm not sure this was= a sensible rule on 4572, but I don't think it's
particul= arly harmful. Here's my analysis: there are two kinds of
certs in play here:

- self-signed certs (most like= ly)
- CA-signed certs (less likely)=A0

I= n the case of self-signed certs, you can control your digest. In the case o= f
CA signed certs, someone is presumably going to verify the signature
and so we would expect the digest used to form that signature to b= e
reasonably strong.


> 3) are there any rules for handling multiple fingerprints?

RFC 4572 is silent on that, unless I missed something, which I
probably did. =A0The only plausible choice given the above statement
from 4572 is to suggest that multiple a=3Dfingerprint values indicate
alternative certificates.

That should probably be written down, of course.

Agreed.

-Ekr
=A0
--047d7b6787d292177804e8fa0123-- From christer.holmberg@ericsson.com Thu Oct 17 21:59:32 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C060E21F9E11 for ; Thu, 17 Oct 2013 21:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.425 X-Spam-Level: X-Spam-Status: No, score=-5.425 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4kTaINp9WCI for ; Thu, 17 Oct 2013 21:59:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 77BAF21F9E12 for ; Thu, 17 Oct 2013 21:59:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-82-5260c02a36c4 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 69.18.16099.A20C0625; Fri, 18 Oct 2013 06:59:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 06:59:22 +0200 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AN2sSmAAAv+KVk= Date: Fri, 18 Oct 2013 04:59:22 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_fxpfdprlgl8ik9kns46p8st01382072314943emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja72gYQgg13GFmv/tbNb7JzbwezA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZWxbcoGtYIZexbXeJcwNjJ3qXYycHBICJhJd U88wQthiEhfurWfrYuTiEBI4zCixZH4DlLOEUeLUshfsXYwcHGwCFhLd/7RBGkQEtCRWL57L BGIzC6hL3Fl8DqxEWMBT4vJpDhBTRMBL4uJWMYhqK4l3rY9YQWwWAVWJL7+6WEBsXgE3iR93 XjNCbJrEKLG0fwEbSIJTIFDi565XzCA2I9Bt30+tgVolLnHryXwmiJsFJJbsOc8MYYtKvHz8 jxWiJkdiUsdOZogFghInZz5hmcAoMgtJ+ywkZbOQlEHE9SRuTJ3CBmFrSyxb+JoZwtaVmPHv EAuy+AJG9lWM7LmJmTnp5YabGIFxc3DLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDo5Pb5wklv75udN6sNE2s39RV4eX93WmXfc+5yoi5LGHkOc26aNO5 A42XwnzCOj0mvX5q2sT88prcpYKz0Z0vJaYs063pDd9smtm20N45YCLLb2mjM1etPdzOR/U/ rOGaz+ukXWz0e2aY/aoz9hZ2XCouagki/s6N5yeqFT3YM8HIteLHtZQbSizFGYmGWsxFxYkA 2A1MdmkCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 04:59:32 -0000 --_000_fxpfdprlgl8ik9kns46p8st01382072314943emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Suhas, Yes, there are a number of ways how it could be done. And, I'm not asking f= or a solution at this point, simply that we identify it as an issue that ne= eds to be solved :) Regards, Christer Sent from my Sony Ericsson Xperia arc S Suhas Nandakumar wrote: Hi Christer, One idea is to pass the Peer Connection Object to be forked as input to the= Fork API when creating the new Peer Connection. This way the implementation knows that the order of m=3Dlines must be mat= ched to the ones in the passed in reference peer connection object .. Any thoughts ?? Thanks Suhas On Mon, Sep 30, 2013 at 1:07 AM, Christer Holmberg > wrote: Hi, JSEP talks about the usage of multiple PeerConnection to support forking, i= .e. for each new forked leg (SIP: early dialog) a new PeerConnection is cre= ated. As has been indicated, as each new PeerConnection will have its own set of = address properties, ICE properties etc, so a new Offer will have to be crea= ted and sent to inform the remote about the new properties. So far so I good. I also assume that the same camera/mic/etc sources are connection to each P= eerConnection, so the number of m- lines in the Offer of the new PeerConnec= tion should be the same. However, according the 3264, the ORDER of the m- lines also need to be kept= the same. So, my question is: how can I ensure that the order of the m- lines in an O= ffer for a new PeerConnection is the same as in an Offer for an old PeerCon= nection? Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_fxpfdprlgl8ik9kns46p8st01382072314943emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Hi Suhas,=0A=
=0A=
Yes, there are a number of ways how it could be done. And, I'm not asking f=
or a solution at this point, simply that we identify it as an issue that ne=
eds to be solved :)=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Suhas Nandakumar <suhasietf@gmail.com> wrote:=0A=
=0A=
Hi Christer,

One idea is to pass the Peer Connection Object to be forked as input to the= Fork API when creating the new Peer Connection.

This way the implementation knows that the order of m=3Dlines must &nb= sp; be matched to the ones in the passed in reference peer connection objec= t ..

Any thoughts ??

Thanks
Suhas


On Mon, Sep 30, 2013 at 1:07 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

JSEP talks about the usage of multiple PeerConnectio= n to support forking, i.e. for each new forked leg (SIP: early dialog) a ne= w PeerConnection is created.

 

As has been indicated, as each new PeerConnection wi= ll have its own set of address properties, ICE properties etc, so a new Off= er will have to be created and sent to inform the remote about the new prop= erties.

 

So far so I good.

 

I also assume that the same camera/mic/etc sources a= re connection to each PeerConnection, so the number of m- lines in the Offe= r of the new PeerConnection should be the same.

 

However, according the 3264, the ORDER of the m- = lines also need to be kept the same.

 

So, my question is: how can I ensure that the order = of the m- lines in an Offer for a new PeerConnection is the same as in an O= ffer for an old PeerConnection?

 

Regards,

 

Christer

 


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


--_000_fxpfdprlgl8ik9kns46p8st01382072314943emailandroidcom_-- From christer.holmberg@ericsson.com Thu Oct 17 21:59:33 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0821F970E for ; Thu, 17 Oct 2013 21:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGj9GP0mAugM for ; Thu, 17 Oct 2013 21:59:27 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E768F21F9E0D for ; Thu, 17 Oct 2013 21:59:23 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-49-5260c02a3d84 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E7.27.25272.A20C0625; Fri, 18 Oct 2013 06:59:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 06:59:22 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AMtSyPQAFcb2ID///JBgQ== Date: Fri, 18 Oct 2013 04:59:21 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvja7WgYQggxsfzSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxpMTuxgL5ghUzP3yl62B8QZP FyMnh4SAicSmx73sELaYxIV769m6GLk4hASOMkosmbGMCcJZwijx4e8E1i5GDg42AQuJ7n/a IA0iAoYSTXvmMYHYzAIpEofPNYANEhZwkLh6rJ0NosZRYuuOz0wQtpPEn4sPmUFsFgFViYcr OthARvIKuEmsve8DseoSo8StP52sIDWcAr4SHYffsoDYjEDHfT+1BmqXuMStJ/OZII4WkFiy 5zwzhC0q8fLxP1aIGgOJ9+fmM0PY2hLLFr4Gs3kFBCVOznzCMoFRdBaSUbOQtMxC0jILScsC RpZVjBzFqcVJuelGBpsYgbFxcMtvix2Ml//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6o NCe1+BAjEwenVAPjxZ7/M8/F5+adOKZv9vz19c19DnVLPrd9itO+d+99sazL0VcO2ZmXHPQN pUX8+suvNW74e2R/V9ydCaqLyvad3veopG9p2ubYTxtYij97JguW8G7m3vT3hf+N5H3v/h0V 69cqdp5ffiTnms6ehllaTpv/K6axzlTumCD+rUDv5vmML7MyTvNcV2Ipzkg01GIuKk4EAO+P J4dbAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 04:59:33 -0000 Hi Cullen, My question is how it would be done when creating the new PC, so I don't th= ink replacing UPDATE with REPLACE would solve the problem :) Also, the usage of a new PC can also be used for serial forking. But, that = is not the issue. Regards, Christer Sent from my Sony Ericsson Xperia arc S "Cullen Jennings (fluffy)" wrote: Perhaps in the parallel forking section, we should replace UPDATE with "INV= ITE with replaces" . Would that work ? Alternatively we could just remove the parallel forking section. On Oct 16, 2013, at 5:16 AM, Christer Holmberg wrote: > Hi, > > Any comments on this issue? I=92d like to have some e-mail discussions be= fore Vancouver. > > I=92d also like it to be listed as an issue =96 unless, of course, I have= missed something, and it really isn=92t an issue :) > > Regards, > > Christer > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Christer Holmberg > Sent: 30. syyskuuta 2013 11:08 > To: rtcweb@ietf.org > Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections > > Hi, > > JSEP talks about the usage of multiple PeerConnection to support forking,= i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is c= reated. > > As has been indicated, as each new PeerConnection will have its own set o= f address properties, ICE properties etc, so a new Offer will have to be cr= eated and sent to inform the remote about the new properties. > > So far so I good. > > I also assume that the same camera/mic/etc sources are connection to each= PeerConnection, so the number of m- lines in the Offer of the new PeerConn= ection should be the same. > > However, according the 3264, the ORDER of the m- lines also need to be ke= pt the same. > > So, my question is: how can I ensure that the order of the m- lines in an= Offer for a new PeerConnection is the same as in an Offer for an old PeerC= onnection? > > Regards, > > Christer > From christer.holmberg@ericsson.com Thu Oct 17 22:02:02 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78DC21F9E63 for ; Thu, 17 Oct 2013 22:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VEtF9R+C8rs for ; Thu, 17 Oct 2013 22:01:58 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 75E6821F9E6A for ; Thu, 17 Oct 2013 22:01:41 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-07-5260c0b4bbd4 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.77.25272.4B0C0625; Fri, 18 Oct 2013 07:01:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 07:01:40 +0200 From: Christer Holmberg To: Christer Holmberg , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: AQHOy78hb3Ik+8z8hUC3/ehEXYIlrQ== Date: Fri, 18 Oct 2013 05:01:39 +0000 Message-ID: <55rrdhpg4ufx751nkf0l3tk3.1382072494327@email.android.com> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje6WAwlBBns/6Fp0TGazWPuvnd2B yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyug7epulYLtQxYML19gaGM/wdTFyckgImEgc vPyZHcIWk7hwbz1bFyMXh5DAUUaJU7sXM0I4Sxgl5j+/ztTFyMHBJmAh0f1PG6RBRCBd4uDV Y6wgNrOAusSdxefYQUqEBTwlLp/mADFFBLwkLm4Vg6jWk7h3disTiM0ioCoxdek2sIG8Am4S /+96QyyawCRx9PpJFpAaTgF3ids7f4LVMwKd9v3UGiaITeISt57MZ4I4WUBiyZ7zzBC2qMTL x/+grjGQeH9uPjOErS2xbOFrMJtXQFDi5MwnLBMYRWchGTULScssJC2zkLQsYGRZxchRnFqc lJtuZLCJERgHB7f8ttjBePmvzSFGaQ4WJXHej2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwTnW/90jnY6+X5UWpjJ8L5M+Vz8tUXv97uca37KdfQpZODD3pm6QyZ6c90z7bHe41DJd8 Ni+vz1Q+o+vkeJfB/WLRkx3ir7/dmqURNSn+YpmoV0fCN8e8sMMlqf3cB/8rXpXe6i5tq9xZ clup7/Vm7XCbKTlvtvyp21WS5Pknf7XGb+m013EZSizFGYmGWsxFxYkAxM04hlECAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 05:02:02 -0000 Replacing UPDATE with INVITE, that is... Sent from my Sony Ericsson Xperia arc S Christer Holmberg wrote: Hi Cullen, My question is how it would be done when creating the new PC, so I don't th= ink replacing UPDATE with REPLACE would solve the problem :) Also, the usage of a new PC can also be used for serial forking. But, that = is not the issue. Regards, Christer Sent from my Sony Ericsson Xperia arc S "Cullen Jennings (fluffy)" wrote: Perhaps in the parallel forking section, we should replace UPDATE with "INV= ITE with replaces" . Would that work ? Alternatively we could just remove the parallel forking section. On Oct 16, 2013, at 5:16 AM, Christer Holmberg wrote: > Hi, > > Any comments on this issue? I=92d like to have some e-mail discussions be= fore Vancouver. > > I=92d also like it to be listed as an issue =96 unless, of course, I have= missed something, and it really isn=92t an issue :) > > Regards, > > Christer > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Christer Holmberg > Sent: 30. syyskuuta 2013 11:08 > To: rtcweb@ietf.org > Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections > > Hi, > > JSEP talks about the usage of multiple PeerConnection to support forking,= i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is c= reated. > > As has been indicated, as each new PeerConnection will have its own set o= f address properties, ICE properties etc, so a new Offer will have to be cr= eated and sent to inform the remote about the new properties. > > So far so I good. > > I also assume that the same camera/mic/etc sources are connection to each= PeerConnection, so the number of m- lines in the Offer of the new PeerConn= ection should be the same. > > However, according the 3264, the ORDER of the m- lines also need to be ke= pt the same. > > So, my question is: how can I ensure that the order of the m- lines in an= Offer for a new PeerConnection is the same as in an Offer for an old PeerC= onnection? > > Regards, > > Christer > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Fri Oct 18 08:48:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DA911E8263 for ; Fri, 18 Oct 2013 08:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXDjW9qUJtqw for ; Fri, 18 Oct 2013 08:48:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0379611E81F3 for ; Fri, 18 Oct 2013 08:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3028; q=dns/txt; s=iport; t=1382111310; x=1383320910; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tZkLwUF7962WprSYy2MVMSIsakTaM90LA6zUsaK47Cs=; b=GuDmiU00vBtGJd+UT6l6b08PNsyb2v/0QsJkRkkeyj4pX/t8jzrImwN+ G8td08qo1UvuZeEd9We8tsblPmhEPCRyeNavPZUW6OND8aIKZiOIp8oeb N5kScWm9lTAEJ40Qmix4prK6vErS4f8IOuUX+Bnz5G60/G/+/lR7NhOh1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAL9XYVKtJXG9/2dsb2JhbABagwc4Ur1VS4EgFnSCJQEBAQMBAQEBawsFCwIBCBEEAQEBCh0HJwsUCQgBAQQOBQgBh3cGDMEEjh2BBgIxB4MfgQoDlCqOMYc1gySBcDk X-IronPort-AV: E=Sophos;i="4.93,523,1378857600"; d="scan'208";a="273834838" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 18 Oct 2013 15:48:14 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9IFmEgJ027986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 15:48:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 10:48:14 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AMtSyPQAFcb2ID///JBgYABCSOA Date: Fri, 18 Oct 2013 15:48:13 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C0339@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: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 15:48:35 -0000 By Invite with replaces, I mean an INVITE in new SIP dialog that uses the r= eplaces header ( http://www.ietf.org/rfc/rfc3891.txt ) with the context of = the old SIP dialog. That is supported and used for lots of cases by PBX tha= t act as B2BUA because it becomes and effective way to do things like total= ly change the number m-lines.=20 Well, when creating a new Offer to use with invite with replaces, the numbe= r of m lines don't have to match at all. You are not even required to have = the same media types. So it seems like that would do it.=20 On Oct 17, 2013, at 10:59 PM, Christer Holmberg wrote: > Hi Cullen, >=20 > My question is how it would be done when creating the new PC, so I don't = think replacing UPDATE with REPLACE would solve the problem :) >=20 > Also, the usage of a new PC can also be used for serial forking. But, tha= t is not the issue. >=20 > Regards, >=20 > Christer >=20 > Sent from my Sony Ericsson Xperia arc S >=20 > "Cullen Jennings (fluffy)" wrote: >=20 >=20 > Perhaps in the parallel forking section, we should replace UPDATE with "I= NVITE with replaces" . Would that work ? >=20 > Alternatively we could just remove the parallel forking section. >=20 > On Oct 16, 2013, at 5:16 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> Any comments on this issue? I=92d like to have some e-mail discussions b= efore Vancouver. >>=20 >> I=92d also like it to be listed as an issue =96 unless, of course, I hav= e missed something, and it really isn=92t an issue :) >>=20 >> Regards, >>=20 >> Christer >>=20 >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of Christer Holmberg >> Sent: 30. syyskuuta 2013 11:08 >> To: rtcweb@ietf.org >> Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections >>=20 >> Hi, >>=20 >> JSEP talks about the usage of multiple PeerConnection to support forking= , i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is = created. >>=20 >> As has been indicated, as each new PeerConnection will have its own set = of address properties, ICE properties etc, so a new Offer will have to be c= reated and sent to inform the remote about the new properties. >>=20 >> So far so I good. >>=20 >> I also assume that the same camera/mic/etc sources are connection to eac= h PeerConnection, so the number of m- lines in the Offer of the new PeerCon= nection should be the same. >>=20 >> However, according the 3264, the ORDER of the m- lines also need to be k= ept the same. >>=20 >> So, my question is: how can I ensure that the order of the m- lines in a= n Offer for a new PeerConnection is the same as in an Offer for an old Peer= Connection? >>=20 >> Regards, >>=20 >> Christer >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Oct 18 09:34:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BA811E8301 for ; Fri, 18 Oct 2013 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmN5BrpoB5Zp for ; Fri, 18 Oct 2013 09:34:46 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7895611E8286 for ; Fri, 18 Oct 2013 09:34:41 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cb5so1284300wib.1 for ; Fri, 18 Oct 2013 09:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Axeru3SD5nAjFUl2Ik3wJMCus9jdGMZPsqmZD8gLjUQ=; b=W4VqbwUT6EoXbbo3EsJQszAqALh0EdmVARxMURZAN721+Tnyc1mvNLGX1cK5PsYai8 JgPHN1luCh52lvDFngmo2AgCYfs2CpDQbybiABWkT/bfNeVyJ7g6cGGUcPMiKo9Pf2JT cr57i9MKTioBkXC7L2hz7VjvGgT9njg7ENPyJFOGRjFwgaxd+IiHp97MjVFjbeg+7XrQ wF33CDq1PqtQT3JyKONk0mGRMMFVf4+habovakQ6ylai+i6CplPUMQ/x6HhOI4aAhxk/ yV94mOM+9NVs5WmWbNl0cJPyC5O0d43f1YoNze32lZrks+fmgtmibeRi/2TonnA16B3G GlAw== MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr186795wia.22.1382114080678; Fri, 18 Oct 2013 09:34:40 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Fri, 18 Oct 2013 09:34:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Oct 2013 09:34:40 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:34:47 -0000 On 17 October 2013 18:38, Eric Rescorla wrote: > I'm not sure this was a sensible rule on 4572, but I don't think it's > particularly harmful. Right. I'd have gone with a rule that said: MUST validate a "strong-enough" hash; MAY ignore others; MUST fail validation if any hash doesn't match. That gives you backwards compatibility + hash agility. That only works of course if there is only one potential certificate that can be used. If you have to allow for several, then that doesn't work. But then you lose the advantages of the above. >> That should probably be written down, of course. > > Agreed. The question is: where? I have a few hours, maybe I can write down an update to 4572 that fixes this. From christer.holmberg@ericsson.com Fri Oct 18 11:03:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA7011E825D for ; Fri, 18 Oct 2013 11:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.678 X-Spam-Level: X-Spam-Status: No, score=-5.678 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xxe5ojYGwiKy for ; Fri, 18 Oct 2013 11:03:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56D1911E826F for ; Fri, 18 Oct 2013 11:03:34 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-c0-526177f48ae2 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3D.90.16099.4F771625; Fri, 18 Oct 2013 20:03:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 20:03:32 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AMtSyPQAFcb2ID///JBgYABCSOAgAAu1RA= Date: Fri, 18 Oct 2013 18:03:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C2F12@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje7X8sQggy2TOCw6JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZWy89oypoEuq4sStNSwNjFdEuhg5OSQETCTm 3LrNBGGLSVy4t56ti5GLQ0jgMKPE/OmPWSGcJYwSN179Zeli5OBgE7CQ6P6nDdIgImAo0bRn Hlgzs4C6xJ3F59hBbGEBT4npBzvYQcpFBLwkLm4Vgyj3kzh95ykzSJhFQFXi4IMckDCvgK9E 84O3UGuvMklsftDPCpLgBEos6b8ANpIR6Lbvp9ZArRKX+HDwOjPEzQISS/ach7JFJV4+/scK YStJLLr9GapeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxjZ cxMzc9LLDTcxAuPj4JbfujsYT50TOcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbG8AtOt89M3sNm9mjORr8TphYcj8+9Sz2flbCpYPotNnvO8KqV189piAX9Ybo2idPz WMp87RsqHZ99+Woqn21Yv2t3y3Rpvbyb2t5yKknWxo59pqz7Ey7sVTF4zbHx3qeS/pR+6Tfb 9xw4zBP/IcA9UN1z65kvrNsL1JNszBjvt/+fZbhiatMMJZbijERDLeai4kQAJMrT410CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:03:42 -0000 Hi, > By Invite with replaces, I mean an INVITE in new SIP dialog that uses the= replaces header ( http://www.ietf.org/rfc/rfc3891.txt ) with the context o= f the old SIP dialog.=20 > That is supported and used for lots of cases by PBX that act as B2BUA bec= ause it becomes and effective way to do things like totally change the numb= er m-lines.=20 > > Well, when creating a new Offer to use with invite with replaces, the num= ber of m lines don't have to match at all. You are not even required to hav= e the same media types. So it seems like that would do it.=20 True, but I don't think one should have to do that. The initial Offer, sent by PC#1, has reached remote entities R_1 and R_2, a= nd both have sent an Answer. For R_2 I now want to create a new PC, PC#2, a= nd send a new Offer with the address properties of PC#2.=20 Regards, Christer On Oct 17, 2013, at 10:59 PM, Christer Holmberg wrote: > Hi Cullen, >=20 > My question is how it would be done when creating the new PC, so I don't = think replacing UPDATE with REPLACE would solve the problem :) >=20 > Also, the usage of a new PC can also be used for serial forking. But, tha= t is not the issue. >=20 > Regards, >=20 > Christer >=20 > Sent from my Sony Ericsson Xperia arc S >=20 > "Cullen Jennings (fluffy)" wrote: >=20 >=20 > Perhaps in the parallel forking section, we should replace UPDATE with "I= NVITE with replaces" . Would that work ? >=20 > Alternatively we could just remove the parallel forking section. >=20 > On Oct 16, 2013, at 5:16 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> Any comments on this issue? I'd like to have some e-mail discussions bef= ore Vancouver. >>=20 >> I'd also like it to be listed as an issue - unless, of course, I have mi= ssed something, and it really isn't an issue :) >>=20 >> Regards, >>=20 >> Christer >>=20 >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of Christer Holmberg >> Sent: 30. syyskuuta 2013 11:08 >> To: rtcweb@ietf.org >> Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections >>=20 >> Hi, >>=20 >> JSEP talks about the usage of multiple PeerConnection to support forking= , i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is = created. >>=20 >> As has been indicated, as each new PeerConnection will have its own set = of address properties, ICE properties etc, so a new Offer will have to be c= reated and sent to inform the remote about the new properties. >>=20 >> So far so I good. >>=20 >> I also assume that the same camera/mic/etc sources are connection to eac= h PeerConnection, so the number of m- lines in the Offer of the new PeerCon= nection should be the same. >>=20 >> However, according the 3264, the ORDER of the m- lines also need to be k= ept the same. >>=20 >> So, my question is: how can I ensure that the order of the m- lines in a= n Offer for a new PeerConnection is the same as in an Offer for an old Peer= Connection? >>=20 >> Regards, >>=20 >> Christer >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Fri Oct 18 11:14:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A95911E827D for ; Fri, 18 Oct 2013 11:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUtAWeaiwG1f for ; Fri, 18 Oct 2013 11:14:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 47FB611E8288 for ; Fri, 18 Oct 2013 11:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1097; q=dns/txt; s=iport; t=1382120093; x=1383329693; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kierg7TKpvXt2stERPAUr9AF2tOY2vy7aUiWYuV8LtA=; b=Mg4PLN7faHJQMtgamKEhCEj8HDqdNt3hGdSxFHh6kJVKwKcjf5iHtaJ1 zvItxKtSQbeJdzzvWlbBkwR7D4Q6now1C+f/sjCR+HUHPjVGtOz/6KTpR wZJAwRseC/msTj9SQBOBc3mrQ4HAi5AyFRmyV390m54aUGLqPv91827ev Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIN5YVKtJXHA/2dsb2JhbABagwc4Ur4kgSEWdIIlAQEBAwE6PwULAgEIIhQQMiUCBA4FCAESh2UGDMEVjyMCMQeDH4EKA5QqjjGHNYMkgik X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="273900913" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 18 Oct 2013 18:14:53 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9IIEqhb030895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 18:14:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 13:14:52 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AMtSyPQAFcb2ID///JBgYABCSOAgAAu1RD///ojgA== Date: Fri, 18 Oct 2013 18:14:51 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4C2F12@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C2F12@ESESSMB209.ericsson.se> 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: <90A56CF2BD7A43428210ACBF65679468@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:14:59 -0000 On Oct 18, 2013, at 12:03 PM, Christer Holmberg wrote: > Hi, >=20 >> By Invite with replaces, I mean an INVITE in new SIP dialog that uses th= e replaces header ( http://www.ietf.org/rfc/rfc3891.txt ) with the context = of the old SIP dialog.=20 >> That is supported and used for lots of cases by PBX that act as B2BUA be= cause it becomes and effective way to do things like totally change the num= ber m-lines.=20 >>=20 >> Well, when creating a new Offer to use with invite with replaces, the nu= mber of m lines don't have to match at all. You are not even required to ha= ve the same media types. So it seems like that would do it.=20 >=20 > True, but I don't think one should have to do that. >=20 > The initial Offer, sent by PC#1, has reached remote entities R_1 and R_2,= and both have sent an Answer. For R_2 I now want to create a new PC, PC#2,= and send a new Offer with the address properties of PC#2.=20 >=20 > Regards, >=20 > Christer >=20 Yah, I understand - that solution is basically the cloning proposal.=20 From christer.holmberg@ericsson.com Fri Oct 18 11:28:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7DD11E82E9 for ; Fri, 18 Oct 2013 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AM+dPRL1Z8D for ; Fri, 18 Oct 2013 11:28:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0668511E81B8 for ; Fri, 18 Oct 2013 11:28:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-4b-52617dd48811 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 11.E1.16099.4DD71625; Fri, 18 Oct 2013 20:28:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 20:28:36 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AMtSyPQAFcb2ID///JBgYABCSOAgAAu1RD///ojgIAAUZtw Date: Fri, 18 Oct 2013 18:28:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C3025@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C0339@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4C2F12@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje6V2sQgg7sXTSw6JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZexYcZ214ABnxZp59g2M29i7GDk5JARMJOb8 6oSyxSQu3FvP1sXIxSEkcJhR4v37PiaQhJDAEkaJHweDuxg5ONgELCS6/2mDhEUEDCWa9swD K2EWUJe4s/gc2BxhAU+J6Qc72EHKRQS8JC5uFYMoj5L4vesLM4jNIqAq8eH5BBYQm1fAV+L9 usdMEGvvMEuc3N8ONpMTKPGj4w5YAyPQbd9PrYHaJS7x4eB1ZoibBSSW7DkPZYtKvHz8jxXC VpJYsf0SI0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGy 5yZm5qSXG25iBEbHwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOM TBycUg2MKXnmTyaGvzJf8NfkhkrtgbfXCguYrjBFml+YEPrpWMOlWK5LN5vmRX3Z2z/Zd/fL dVu1z559crTf5maQk9zhpsof2V/N5h7ODp8tdnfDhXyLFv4t2h+O/nSu6PHa2rnRW5nxXNgG z5eH136c6PVnerToOZ6Ut0KT8hQ+lxc+fMM78/sRm209y5RYijMSDbWYi4oTARAEOztcAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:28:43 -0000 Hi, >>> By Invite with replaces, I mean an INVITE in new SIP dialog that uses t= he replaces header ( http://www.ietf.org/rfc/rfc3891.txt ) with the context= of the old SIP dialog.=20 >>> That is supported and used for lots of cases by PBX that act as B2BUA b= ecause it becomes and effective way to do things like totally change the nu= mber m-lines.=20 >>>=20 >>> Well, when creating a new Offer to use with invite with replaces, the n= umber of m lines don't have to match at all. You are not even required to h= ave the same media types. So it seems like that would do it.=20 >>=20 >> True, but I don't think one should have to do that. >>=20 >> The initial Offer, sent by PC#1, has reached remote entities R_1 and R_2= , and both have sent an Answer. For R_2 I now want to create a new PC, PC#2= , and send a new Offer with the address properties of PC#2.=20 >>=20 > > Yah, I understand - that solution is basically the cloning proposal.=20 No, because I would get NEW address properties. But, the order of the m- lines (and the media sources etc they represent), = and any property that 3264 does not allow to be changed, would have to be t= he same. Regards, Christer From fluffy@cisco.com Fri Oct 18 12:11:56 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC611E8312 for ; Fri, 18 Oct 2013 12:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eW7ayQzwNCj for ; Fri, 18 Oct 2013 12:11:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E027D11E8310 for ; Fri, 18 Oct 2013 12:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1296; q=dns/txt; s=iport; t=1382123510; x=1383333110; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v+EBiiiKoBRFn3SSmBescws5uszelRWMjC4FI2sUDcY=; b=lbvAgrrbthQ7fFAh3qvZsUNqRDTVw/nem89paKY50LFBpKFfOG87fCc1 DmDUQkrbv0Q+JzrVF/5PPSC+vJTRyFSRrq54/lPMnNV1LbTn/sCt3imgZ nKYgo8Hbt3hmwWGQeu0Cwu11qtN9/iIwZMktbkSd+wbvkXS6hIKMD0s6W 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAKCHYVKtJXG8/2dsb2JhbABQCoMHgQq+JIEjFnSCJQEBAQMBeQULAgEIIiQyJQIEDgUIE4dlBsEIjhOBEAIxB4MfgQoDiQeLI44xhzWDJIIp X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="273925551" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 18 Oct 2013 19:11:49 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9IJBmtO026106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 19:11:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 14:11:47 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: AQHOzDXkSk4xBHAwQSOQDX27ZZb6/A== Date: Fri, 18 Oct 2013 19:11:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@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: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1DC6A9C2310E404BB563CBCA7E8C77B9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:11:56 -0000 On Oct 17, 2013, at 10:59 PM, Christer Holmberg wrote: > And, I'm not asking for a solution at this point, simply that we identify= it as an issue that needs to be solved :) >=20 >=20 So I sort of disagree on two points here.=20 I disagree that it needs to be solved - I'm not against solving it if anyon= e has an easy way but every time we talk about this the conclusions comes u= p people don't want to bother to fully solve the parallel forking problem i= n the first version of the webrtc. Speaking purely for myself, SIP parallel= forking has not turned out to be extremely useful and has turned out to se= riously complicate the use and extensions to the protocol - basically the H= ERFP problem - so I don't really care if webrtc takes on that problem or no= t.=20 Second, I suspect that Invite with replaces actually does solve this.=20 I certainly don't mind marking it as an issue but it's not clear to me that= the WG thinks it is an issue that needs to be solved or that it an issue t= hat is not solved. I've sort of been waiting to see the other "easy" stuff = in JSEP / Bundle / Unified plan get sorted out and then figured we could go= back and see what was possible or not with parallel forking in SIP.=20 From fluffy@cisco.com Fri Oct 18 12:34:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223B811E82A3 for ; Fri, 18 Oct 2013 12:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpIjLKuF-GIN for ; Fri, 18 Oct 2013 12:34:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4563511E81B8 for ; Fri, 18 Oct 2013 12:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=339; q=dns/txt; s=iport; t=1382124879; x=1383334479; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NIY3OD1knbNiQLvWUUbBhwAFt2r6XDrXdWnFIXt7wpU=; b=JKeWqSsIJP2gTJa7R4hHDvNvrzIzmDp6ULRvJmkAKKfW1VGt2IPC0AlD I0Byk83DLTrzJiMexykDg2T4VFR4KkpMsNGvXxgQlxFOTHf0dl4YNk3rz t+EHY8VpdcPEL+LWLmfNjtEPyKYxtkPdrhtIBipxDDCRT4H/OmVfNQNX1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAHSMYVKtJXG//2dsb2JhbABagweBCr4jgSQWdIImAQEEOj8QAgEIIhQQIRElAgQOBQiHbAMPtxINiWuMZoI9AjEHgx+BCgOWHo47hTeDJIIp X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="273882928" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 18 Oct 2013 19:34:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9IJYcf7009822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 19:34:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 14:34:38 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [rtcweb] JSEP fingerprint hash requirements Thread-Index: AQHOzDkV8HvNDfV/akqm1ru7j7zqBw== Date: Fri, 18 Oct 2013 19:34:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:34:45 -0000 On Oct 18, 2013, at 10:34 AM, Martin Thomson wro= te: >>>=20 >>> That should probably be written down, of course. >>=20 >> Agreed. >=20 > The question is: where? >=20 > I have a few hours, maybe I can write down an update to 4572 that fixes t= his. that would be excellent if you could do that From christer.holmberg@ericsson.com Fri Oct 18 12:35:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BB811E8319 for ; Fri, 18 Oct 2013 12:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqavnq7qoaPe for ; Fri, 18 Oct 2013 12:35:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9F12B11E8311 for ; Fri, 18 Oct 2013 12:34:48 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-c0-52618d57b02e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 65.0C.03802.75D81625; Fri, 18 Oct 2013 21:34:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 21:34:47 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AN2sSmAAAv+KVkAGZQYAAAE0Y4g Date: Fri, 18 Oct 2013 19:34:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C3254@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW54b2KQQesyPYuOyWwWa/+1s1vs nNvB7MDsMeX3RlaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugSvj9PoVzAXfBSoaOp+wNjBu 4+1i5OCQEDCRWDe/uIuRE8gUk7hwbz1bFyMXh5DAYUaJZx8bmSGcJYwS7w/cZQJpYBOwkOj+ pw3SICJgKNG0Zx4TiM0sECjR3v+WBcQWFvCUmH6wgx2kXETAS+LiVjGIcjeJSWcmMYLYLAKq EitedbOD2LwCvhJ3Pqxnh1g1lUmie/EzsDmcQImdFy+D2YxAx30/tQZql7jEh4PXmSGOFpBY suc8lC0q8fLxP1YIW0lixfZLjBD1ehI3pk5hg7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcXInpuYmZNebrSJERgzB7f8Vt3BeOecyCFGaQ4WJXHeD2+dg4QE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUw+t4TSUicVDk59+l2nfaFR5Jzcpbx5lvOuFz7ILHhz+MHM5pj wpnm/jaZzm7d4Lf+joycq/myMGF+lQ+XPqVN54trXHDLxzSh9+x+x+bt+Uoa3OxxXbtDA989 +T7By2XefcvNTWm3J+UX7O51bDq6tpfr/Fbl8K+S2lwCG/h6PpW59t1MtjBWYinOSDTUYi4q TgQADC3RnGcCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:35:08 -0000 Hi, Again, it is not specific to parallel forking - it is also needed for SERIA= L forking, in cases where you need to send updated Offers on early dialogs,= and therefore cannot use PRANSWER. As far as the solution is concerned: on a high level, whenever you create a= new PC (or, when you add the media streams to it), you need to be able to = indicate the order of the m- lines. Whether it is done explicitly, or impli= citly e.g. by somehow referencing the old PC, I don't know, but I don't thi= nk it should be very difficult. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 L=E4hetetty: 18. lokakuuta 2013 22:12 Vastaanottaja: Christer Holmberg Kopio: Suhas Nandakumar; rtcweb@ietf.org Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections On Oct 17, 2013, at 10:59 PM, Christer Holmberg wrote: > And, I'm not asking for a solution at this point, simply that we identify= it as an issue that needs to be solved :) >=20 >=20 So I sort of disagree on two points here.=20 I disagree that it needs to be solved - I'm not against solving it if anyon= e has an easy way but every time we talk about this the conclusions comes u= p people don't want to bother to fully solve the parallel forking problem i= n the first version of the webrtc. Speaking purely for myself, SIP parallel= forking has not turned out to be extremely useful and has turned out to se= riously complicate the use and extensions to the protocol - basically the H= ERFP problem - so I don't really care if webrtc takes on that problem or no= t.=20 Second, I suspect that Invite with replaces actually does solve this.=20 I certainly don't mind marking it as an issue but it's not clear to me that= the WG thinks it is an issue that needs to be solved or that it an issue t= hat is not solved. I've sort of been waiting to see the other "easy" stuff = in JSEP / Bundle / Unified plan get sorted out and then figured we could go= back and see what was possible or not with parallel forking in SIP.=20 From fluffy@cisco.com Fri Oct 18 12:42:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8111E8315 for ; Fri, 18 Oct 2013 12:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGuClqeE3UPR for ; Fri, 18 Oct 2013 12:42:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8702C11E8145 for ; Fri, 18 Oct 2013 12:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2543; q=dns/txt; s=iport; t=1382125326; x=1383334926; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nxMx6J8donDPyakf/3Sm4prhjrCOnrRB2JyG6ZgxSuE=; b=Bd2Keain/gOkvvZZOFRlbZypex/8ctABOaagTCrB+Y/waNZ1v19eGxvV WuawMK1VfCGnjiebwpyHv6iHviABDLDWYhv4JmnXi50bnw9P0fjcKRGDw kq9mbidIaPhyWBiO9ImzTiYEhB0HG4NpXLE3fBTUt0wtRhvdjEVg/NOjg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALWNYVKtJXG8/2dsb2JhbABQCoMHgQq+I4EkFnSCJQEBAQMBDG0FCwIBCBgKHQcyFBEBAQQOBQgTh2UGwQqOE4EQAjEHgx+BCgOJB4sjjjGHNYMkgik X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="273727484" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 18 Oct 2013 19:42:06 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9IJg6HS003844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 19:42:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 14:42:05 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AN2sSmAAAv+KVkAGZQYAAAE0Y4gAArpVgA= Date: Fri, 18 Oct 2013 19:42:04 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4C3254@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C3254@ESESSMB209.ericsson.se> 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="iso-8859-1" Content-ID: <3B88A8BB97C09740BB43181628EA78A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:42:12 -0000 On Oct 18, 2013, at 1:34 PM, Christer Holmberg wrote: > Hi, >=20 > Again, it is not specific to parallel forking - it is also needed for SER= IAL forking, in cases where you need to send updated Offers on early dialog= s, and therefore cannot use PRANSWER. I don't think I agree on that but I really want to spend my time on making = sure we get the setLocal / setRemote text working for the simple case befor= e we sort all this out.=20 >=20 > As far as the solution is concerned: on a high level, whenever you create= a new PC (or, when you add the media streams to it), you need to be able t= o indicate the order of the m- lines. Whether it is done explicitly, or imp= licitly e.g. by somehow referencing the old PC, I don't know, but I don't t= hink it should be very difficult. >=20 > Regards, >=20 > Christer >=20 > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 > L=E4hetetty: 18. lokakuuta 2013 22:12 > Vastaanottaja: Christer Holmberg > Kopio: Suhas Nandakumar; rtcweb@ietf.org > Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections >=20 >=20 > On Oct 17, 2013, at 10:59 PM, Christer Holmberg wrote: >=20 >> And, I'm not asking for a solution at this point, simply that we identif= y it as an issue that needs to be solved :) >>=20 >>=20 >=20 > So I sort of disagree on two points here.=20 >=20 > I disagree that it needs to be solved - I'm not against solving it if any= one has an easy way but every time we talk about this the conclusions comes= up people don't want to bother to fully solve the parallel forking problem= in the first version of the webrtc. Speaking purely for myself, SIP parall= el forking has not turned out to be extremely useful and has turned out to = seriously complicate the use and extensions to the protocol - basically the= HERFP problem - so I don't really care if webrtc takes on that problem or = not.=20 >=20 > Second, I suspect that Invite with replaces actually does solve this.=20 >=20 > I certainly don't mind marking it as an issue but it's not clear to me th= at the WG thinks it is an issue that needs to be solved or that it an issue= that is not solved. I've sort of been waiting to see the other "easy" stuf= f in JSEP / Bundle / Unified plan get sorted out and then figured we could = go back and see what was possible or not with parallel forking in SIP.=20 >=20 >=20 From christer.holmberg@ericsson.com Fri Oct 18 13:38:37 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD71311E8312 for ; Fri, 18 Oct 2013 13:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.875 X-Spam-Level: X-Spam-Status: No, score=-3.875 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ULaLvgcq1+M for ; Fri, 18 Oct 2013 13:38:31 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B999B11E8311 for ; Fri, 18 Oct 2013 13:38:27 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-29-52619c42b12d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8A.26.25272.24C91625; Fri, 18 Oct 2013 22:38:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 22:38:16 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AN2sSmAAAv+KVkAGZQYAAAE0Y4gAArpVgAACKGa8A== Date: Fri, 18 Oct 2013 20:38:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4C336D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4C3254@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja7TnMQgg5ubDSw6JrNZrP3Xzm6x c24HswOzx5TfG1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6Ma3d2shRcFKzY/mMVawPj d94uRk4OCQETiWkXrzND2GISF+6tZ+ti5OIQEjjKKPHgxzooZwmjxPdXd4EcDg42AQuJ7n/a IA0iAoYSTXvmMYHYzAKBEu39b1lAbGEBT4npBzvYQcpFBLwkLm4VgygPk/j58BUbiM0ioCrx dtNFdhCbV8BXYuXTV0wQq+YwSxx+MxVsJidQ4szh86wgNiPQcd9PrYHaJS7x4SDM0QISS/ac h7JFJV4+/scKYStJrNh+iRGiXk/ixtQpbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFpmYWk ZRaSlgWMLKsYOYpTi5Ny040MNjEC4+bglt8WOxgv/7U5xCjNwaIkzvvxrXOQkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsYzoU2753jM2am+MGB/zpQVUsKqpYIv9JgS1t5+bawYPY/j7eyr 5x6YeDFpX79RdHxhYYq2bMS2D+r9ge7ukzbxF/ryf1HZfKropMhcWQ2X6b+Pi/4qNV5W694j rNUk33TO60xS1SrlBZM2COxizW4yfLVs5XIVWxOGGe5X9c2nP7Z93vzN+aYSS3FGoqEWc1Fx IgDyid59aQIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 20:38:37 -0000 Hi, >> Again, it is not specific to parallel forking - it is also needed for SE= RIAL forking, in cases where you need to send updated Offers on early dialo= gs, and therefore cannot use PRANSWER. > > I don't think I agree on that but I really want to spend my time on makin= g sure we get the setLocal / setRemote text working for the simple case bef= ore we sort all this out.=20 This is how I understand it would work when discussing with Vijaya . Now, if you don't agree, please then explain how you would implement the fo= rking case I provided :) Regards, Christer > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 > L=E4hetetty: 18. lokakuuta 2013 22:12 > Vastaanottaja: Christer Holmberg > Kopio: Suhas Nandakumar; rtcweb@ietf.org > Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections >=20 >=20 > On Oct 17, 2013, at 10:59 PM, Christer Holmberg wrote: >=20 >> And, I'm not asking for a solution at this point, simply that we identif= y it as an issue that needs to be solved :) >>=20 >>=20 >=20 > So I sort of disagree on two points here.=20 >=20 > I disagree that it needs to be solved - I'm not against solving it if any= one has an easy way but every time we talk about this the conclusions comes= up people don't want to bother to fully solve the parallel forking problem= in the first version of the webrtc. Speaking purely for myself, SIP parall= el forking has not turned out to be extremely useful and has turned out to = seriously complicate the use and extensions to the protocol - basically the= HERFP problem - so I don't really care if webrtc takes on that problem or = not.=20 >=20 > Second, I suspect that Invite with replaces actually does solve this.=20 >=20 > I certainly don't mind marking it as an issue but it's not clear to me th= at the WG thinks it is an issue that needs to be solved or that it an issue= that is not solved. I've sort of been waiting to see the other "easy" stuf= f in JSEP / Bundle / Unified plan get sorted out and then figured we could = go back and see what was possible or not with parallel forking in SIP.=20 >=20 >=20 From juberti@google.com Fri Oct 18 19:23:10 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9C811E8135 for ; Fri, 18 Oct 2013 19:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKlgGXoU9mmr for ; Fri, 18 Oct 2013 19:23:10 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E5B6311E8128 for ; Fri, 18 Oct 2013 19:23:09 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so2395546veb.41 for ; Fri, 18 Oct 2013 19:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tfoTKs5zo9jSEMFzjtvB9P9iKvYbhRpM/ZrRX3ShG0Q=; b=O/Ph7RA+t0oPRcm6XZfwTFPtybeIvo5qeb3DRGPN9JDfgs8fRkZO5FNJOWDAi/uan/ ERfL5fFqX7MgAdjY4M66G9qk+qRbalyl35OnZmhh+E54oCRYgKs9P3zDcE2TXsAyNXaM fRK8RQ/dmsabZutilxs99Vmqq9GUF1lIdlUnGibemKa9xYwMLmmdh4xEFRH/KOBKF1GU GA6UwTigg8I6CrN7vSVfg55o9kkjME7kN4tKHCof26X02ccIj7pRa/0pkaMwWhcSuiHc n8c3gWzhB/2YCkcnXM9G9+2sxH9B86oAr/pMy5mB9Zd349sbJ2PlWsVARB5E3K7ON1r3 +2JQ== 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=tfoTKs5zo9jSEMFzjtvB9P9iKvYbhRpM/ZrRX3ShG0Q=; b=C/7h7XSTzaGDbaNe4e/MauU04p8b7U71YWgYfVoW3mZ7usvvJTyXYYVTyPvQIVF4Bu Lhp+3XrWIXAkFwaRcAPGREcLsYCBGO0j+3SeomYrSsw8yjWq3tnvoNY/+Dj4jGPQvlk6 RXvyCQzYZF6KfpUWxXqKKCgDq5DBYUvuWzH/2vv+c0AhvRW3M55AF9SujiLaB8eQEWGD oHD9r1kt7lkQEx+Jq7HOgfC1skuZVW59dGVGsQIGW+q8iXUySosJWUtjPTfXWgeGftiY bSIBygKq0vvIiIXbNF/6xHQz5/4mxCfXhHrw8TgVXhRSMESd5hYr1ufrpYco7NRHGPwX 2zhw== X-Gm-Message-State: ALoCoQmPEI8dBqiOQSwFzTQSxO09K2wjbEbtjK3YdiNss99WIUXB2Mk3pHfUhf4MUvx1dIQP5hLNLaw5QhOvJ2xJuofdEeUv/VnbDrpzPDwLUFyE/yqJU0T2/yXTTITHXkeWBhyO8DH+qrCVagN4+66Dx2R0Nt1kA/Xvt8e5c3mOmrZbmluyQ4wMZPNPHeu4vy7nmySi3Mw3 X-Received: by 10.58.168.205 with SMTP id zy13mr3394445veb.19.1382149389274; Fri, 18 Oct 2013 19:23:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Fri, 18 Oct 2013 19:22:49 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 18 Oct 2013 19:22:49 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b6dc2245ff74304e90ebb38 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 02:23:10 -0000 --047d7b6dc2245ff74304e90ebb38 Content-Type: text/plain; charset=UTF-8 FWIW others have complained about this exact thing in JSEP and it will be fixed in the -05 version (to agree with 4572). On Thu, Oct 17, 2013 at 11:54 AM, Martin Thomson wrote: > On 17 October 2013 01:37, Kevin Dempsey wrote: > > 1) does the fingerprinh hash need to match the certificate > > Yes. Without that, you've got no binding between signaling and media > path, which is bad. > > > 2) do webrtc compatible endpoints need to handle hashes 'weaker' than > > sha-256 > > No. RFC 4572 is clear: > A certificate fingerprint MUST be computed using the same one-way > hash function as is used in the certificate's signature algorithm. > > That means that you need to generate the certificate with a hash that > is strong enough. > > > 3) are there any rules for handling multiple fingerprints? > > RFC 4572 is silent on that, unless I missed something, which I > probably did. The only plausible choice given the above statement > from 4572 is to suggest that multiple a=fingerprint values indicate > alternative certificates. > > That should probably be written down, of course. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b6dc2245ff74304e90ebb38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW others have complained about this exact thing in JSEP= and it will be fixed in the -05 version (to agree with 4572).


On Thu, Oct 17, 2013= at 11:54 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 17 October 2013 01:37, = Kevin Dempsey <kevindempsey7= 0@gmail.com> wrote:
> 1) does the fingerprinh hash need to match the certificate

Yes. =C2=A0Without that, you've got no binding between signaling = and media
path, which is bad.

> 2) do webrtc compatible endpoints need to handle hashes 'weaker= 9; than
> sha-256

No. =C2=A0RFC 4572 is clear:
=C2=A0 =C2=A0A certificate fingerprint MUST be computed using the same one-= way
=C2=A0 =C2=A0hash function as is used in the certificate's signature al= gorithm.

That means that you need to generate the certificate with a hash that
is strong enough.

> 3) are there any rules for handling multiple fingerprints?

RFC 4572 is silent on that, unless I missed something, which I
probably did. =C2=A0The only plausible choice given the above statement
from 4572 is to suggest that multiple a=3Dfingerprint values indicate
alternative certificates.

That should probably be written down, of course.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b6dc2245ff74304e90ebb38-- From vsingh.ietf@gmail.com Sat Oct 19 09:27:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCDB21F9E88 for ; Sat, 19 Oct 2013 09:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9maQQ9V-yCI for ; Sat, 19 Oct 2013 09:27:51 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7D30211E81FD for ; Sat, 19 Oct 2013 09:27:51 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so8488230ieb.2 for ; Sat, 19 Oct 2013 09:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=HLzeEs8w3arY/pTz03v+bUNslCKHHVadUHJYVdEZEcs=; b=WtiS34vZas5R3lrWCYFjZ7qAzd5dROSaaH1oONhFK8d/yDJvzNZzTAe2RGtAEzn4hv Y09DtCadErl/zM74c9+hj2POUAcGzbVerXOK53rWsVAMm47VHtPVJtcSUQEGEc8YyJoq uCAKCA85V/JTkC+/xA2X1fwkw0Ky2PT9L3BkoPALmue8husuFSpIWilOZwk+oVr35pAv WL7asKgIXdJ2pMzR6vzmNGd3RLHHtLbxRE4yelFx37VfMN4pzlqFyZ+Jhv/vYevcF+YU RSSsedEl4NRK+J1Qsahx3DQuYuGxi4RDiiZGzJtDUJDopLpwpaRyIsPK6aP46lh3M3UP QiIw== X-Received: by 10.43.154.18 with SMTP id lc18mr1132048icc.41.1382200070640; Sat, 19 Oct 2013 09:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sat, 19 Oct 2013 09:27:30 -0700 (PDT) From: Varun Singh Date: Sat, 19 Oct 2013 11:27:30 -0500 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Additional identifiers for the Stats API from an XRBLOCK perspective X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 16:27:52 -0000 Hi all, In the XRBLOCK WG, we have been discussing on how we can aid in meeting the goals of the requirement: F38 The browser must be able to collect statistics, related to the transport of audio and video between peers, needed to estimate quality of experience. We have recently (a bit before Berlin IETF) published a draft discussing the metrics that could help the receiver monitor the incoming media stream better. These are discussed in: http://tools.ietf.org/html/draft-huang-xrblock-rtcweb-rtcp-xr-metrics Following Berlin, we've formalized the input as a proposal to extend the stats registry. The following draft lists the additional metrics: http://tools.ietf.org/html/draft-singh-xrblock-webrtc-additional-stats Comments and suggestions for improvements are appreciated. Lastly, both the drafts will be discussed in the XRBLOCK WG in the upcoming meeting in Vancouver. Cheers, Varun -- http://www.netlab.tkk.fi/~varun/ From parthasarathi.ravindran@nsn.com Sun Oct 20 00:22:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85BE11E8165 for ; Sun, 20 Oct 2013 00:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wl6cMqoKZvL for ; Sun, 20 Oct 2013 00:22:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 86AB311E8356 for ; Sun, 20 Oct 2013 00:22:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9K7MWLt007812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Oct 2013 09:22:33 +0200 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9K7MHKp015436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Oct 2013 09:22:32 +0200 Received: from SGSIMBX006.nsn-intra.net ([169.254.6.23]) by SGSIHTC002.nsn-intra.net ([10.159.225.19]) with mapi id 14.03.0123.003; Sun, 20 Oct 2013 15:22:25 +0800 From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" To: ext Christer Holmberg , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/ANqHoOAAAfNNAAAHcUNAAAAzXyAAABBawAAAfYrAABZP2cg Date: Sun, 20 Oct 2013 07:22:25 +0000 Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C47C5B@SGSIMBX006.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1C4AFB57@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4C3254@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4C336D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C336D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.122] 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: 2937 X-purgate-ID: 151667::1382253753-00004A43-3580334E/0-0/0-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 07:22:43 -0000 Hi Cullen, I fully agree with Christer for PRANSWER state usage in serial forking. Sec= 5.2 of draft-partha-rtcweb-jsep-sip-00 explains the callflow wherein PRANS= WER state is not possible to be used in serial forking. Thanks Partha -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= ext Christer Holmberg Sent: Saturday, October 19, 2013 2:08 AM To: Cullen Jennings (fluffy) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Hi, >> Again, it is not specific to parallel forking - it is also needed for SE= RIAL forking, in cases where you need to send updated Offers on early dialo= gs, and therefore cannot use PRANSWER. > > I don't think I agree on that but I really want to spend my time on makin= g sure we get the setLocal / setRemote text working for the simple case bef= ore we sort all this out.=20 This is how I understand it would work when discussing with Vijaya . Now, if you don't agree, please then explain how you would implement the fo= rking case I provided :) Regards, Christer > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 > L=E4hetetty: 18. lokakuuta 2013 22:12 > Vastaanottaja: Christer Holmberg > Kopio: Suhas Nandakumar; rtcweb@ietf.org > Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections >=20 >=20 > On Oct 17, 2013, at 10:59 PM, Christer Holmberg wrote: >=20 >> And, I'm not asking for a solution at this point, simply that we identif= y it as an issue that needs to be solved :) >>=20 >>=20 >=20 > So I sort of disagree on two points here.=20 >=20 > I disagree that it needs to be solved - I'm not against solving it if any= one has an easy way but every time we talk about this the conclusions comes= up people don't want to bother to fully solve the parallel forking problem= in the first version of the webrtc. Speaking purely for myself, SIP parall= el forking has not turned out to be extremely useful and has turned out to = seriously complicate the use and extensions to the protocol - basically the= HERFP problem - so I don't really care if webrtc takes on that problem or = not.=20 >=20 > Second, I suspect that Invite with replaces actually does solve this.=20 >=20 > I certainly don't mind marking it as an issue but it's not clear to me th= at the WG thinks it is an issue that needs to be solved or that it an issue= that is not solved. I've sort of been waiting to see the other "easy" stuf= f in JSEP / Bundle / Unified plan get sorted out and then figured we could = go back and see what was possible or not with parallel forking in SIP.=20 >=20 >=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From partha@parthasarathi.co.in Sun Oct 20 09:36:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F0E11E82A9 for ; Sun, 20 Oct 2013 09:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd5n7wmj-lBe for ; Sun, 20 Oct 2013 09:35:45 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2711E8200 for ; Sun, 20 Oct 2013 09:35:36 -0700 (PDT) Received: from userPC (unknown [122.179.103.73]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 2271B86920B; Sun, 20 Oct 2013 16:35:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382286933; bh=BL7HNU2EGLnDYFzOnooBETDaHYQgo0Xt279ednY3paA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=WKPNxq97dLoUSlviVEcx30xb6Ooz6jEAuhQSz/lANwIEZ9/z3syEzPFgLh0Y8VE/C 6RWs0GS56MMLntSOoPTvMTUJa1dIprZomQPQTmmumXmcqyyMWp/VyKU1nvZYoHniT9 BNP8XF+jm2uAhP258rIg3CYcgXcxgQyMifq4a7pU= From: "Parthasarathi R" To: "'Chenxin \(Xin\)'" , "'Hutton, Andrew'" , "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1C4BDDF9@ESESSMB209.ericsson.se> <00d601cec911$b0fd4b60$12f7e220$@co.in> <9E34D50A21D1D1489134B4D770CE0397680826A3@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFAC8@ESESSMB209.ericsson.se> <9E34D50A21D1D1489134B4D770CE039768082747@SZXEMA504-MBX.china.huawei.com> <7594FB04B1934943A5C02806D1A2204B1C4BFDA9@ESESSMB209.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF17BF5B80@MCHP04MSX.global-ad.net> <9E34D50A21D1D1489134B4D770CE039768082A1A@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE039768082A1A@SZXEMA504-MBX.china.huawei.com> Date: Sun, 20 Oct 2013 22:05:23 +0530 Message-ID: <000d01cecdb2$63c1ef90$2b45ceb0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CECDE0.7D7A2B90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOypqiDFNQXq+XsEKEiGC0JWGDqZn4Hd7ggAWs/6A= Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.52640654.0113, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154 Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 16:36:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000E_01CECDE0.7D7A2B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Xin & all, Apart from modified F29 by Xin, the following requirement has to be discussed: 1) New requirement for blocking incoming TCP connection: a. The browser must be able to send streams and data to a peer in the presence of NATs and FWs that block UDP traffic and incoming TCP connection 2) New requirement to cover both browsers are behind the firewall a. The browser must be able to send streams and data to a peer in the presence of NATs and FWs that block UDP traffic and incoming TCP connection in both browser side as well as in the peer side (TURN only works) Thanks Partha From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com] Sent: Thursday, October 17, 2013 3:54 PM To: Hutton, Andrew; Christer Holmberg; Parthasarathi R; rtcweb@ietf.org Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12 Hi Andy, I think you means F29 not F27:). When I read it , I realize that there is cross and ambiguous between 3.3.2 and 3.3.3 More details: The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW* that blocks UDP". But in the description and requirement, only *NAT* is considered. The topic of 3.3.3 is "Simple Video Communication Service, FW that only allows http", But only *http proxy* deployed scenarios is considered. There are other usecases " FW block UDP, incoming TCP, Http allowing FW without http proxy deplolyed under the permission of FW policy" , which is lost in the description. If we need consider these usecases , I suggest to make some change to the description. Proposal 1 : add FW related words to section 3.3.2 ------------------------------------------------- 3.3.2. Simple Video Communication Service, NAT/FW that blocks UDP 3.3.2.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1). The difference is that one of the users is behind a NAT*/FW* that blocks UDP traffic. . 3.3.2.2. Additional Requirements F29 The browser must be able to send streams and data to a peer in the presence of NATs *and FWs* that block UDP traffic ,* when FW policy allows WebRTC traffic*. ------------------------------------------------------- Proposal 2: If the" Http allowing FW without http proxy deployed" case is impliedly included in F29. I suggest to change the topics of 3.3.3 to "Simple Video Communication Service, FW that only allows traffic via a http proxy". So the 3.3.3 is a specific case. Proposal 3: If " Http allowing FW without http proxy deployed" case need to be explicitly mentioned. I suggest to add some descriptions to 3.3.3 ----------------------------------------------------------------- 3.3.3. Simple Video Communication Service, FW that only allows http 3.3.3.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1). The difference is that one of the users is behind a http allowing FW or a FW that only allows traffic via a HTTP Proxy. 3.3.3.2. Additional Requirements F37 The browser must be able to send streams and data to a peer in the presence of http allowing FWs or FWs that only allows traffic via a HTTP Proxy, when FW policy allows WebRTC traffic. ------------------------------------------------------------------- Best Regards, Xin >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@unify.com] >Sent: Thursday, October 17, 2013 2:08 AM >To: Christer Holmberg; Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org >Subject: RE: [rtcweb] Query/Comment on >draft-ietf-rtcweb-use-cases-and-requirements-12 > >Hi Xin, > >I see the PNTAW mailing list as being there to discuss potential solutions to >these requirements which are documented in the use case draft. > >The requirement F37 is specific to the case when there is a HTTP Proxy and F27 >would include the case when there is no proxy. > >Do you see other use cases and requirements that need to be explicitly brought >out in draft-ietf-rtcweb-use-cases-and-requirements? > >Regards >Andy > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: 16 October 2013 10:32 >> To: Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org >> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- >> requirements-12 >> >> Hi Xin, >> >> So, you are saying we shouldn't finalize the use-case-requirements >> document yet? >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com] >> Sent: 16. lokakuuta 2013 12:28 >> To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org >> Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and- >> requirements-12 >> >> Hi Christer, >> >> >Hi, >> > >> >> +1. I think we should wait for the result of PNTAW@ietf.org >> >> discussion >> >before modifying the related use case and requirement. there seems no >> >clear consensus by now. >> >> >> >> The related use case is 3.3.2 , F29 , 3.3.3 and F37. >> > >> >Consensus on what? >> >> Should we just consider the case that " one of the users is behind a FW >> that only allows traffic via a HTTP Proxy "? what will happen if there >> is no http proxy deployed? >> >> There are two options to solve this usecase discussed in PNTAW mailing >> list. "5)UDP relay candidates via some HTTP/TLS compatible transport >> (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets >have >> been proposed." List in http://www.ietf.org/mail- >> archive/web/pntaw/current/msg00162.html >> Also there is other discussions in http://www.ietf.org/mail- >> archive/web/pntaw/current/msg00166.html. >> >> That all mention that we should consider more than the http proxy >> scenarios. >> >> I believe that the PNTAW mailing list is used for discussion of these >> similar transport problems, including the related use case and >> requirement. In the end , some consensus should be make to decide what >> problem we need handle and how to solve it , which will influence the >> use case and requirement to make it more clear. Is my thought right? >> Or miss something... >> >> Best Regards, >> Xin >> > >> >Note that the draft is only talking about requirements. >> > >> >Regards, >> > >> >Christer >> > >> > >> >>-----Original Message----- >> >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> >>Behalf Of Parthasarathi R >> >>Sent: Tuesday, October 15, 2013 3:15 AM >> >>To: 'Christer Holmberg'; rtcweb@ietf.org >> >>Subject: [rtcweb] Query/Comment on >> >>draft-ietf-rtcweb-use-cases-and-requirements-12 >> >> >> >>Hi Christer & all, >> >> >> >>In PNTAW mailing list, there is a discussion on firewall blocking >> >>incoming TCP traffic when the firewall blocks UDP or allows only HTTP >> >>traffic. The related link is >> >>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. >> >> >> >>Could you please clarify whether F29 & F37 requirement implicitly >> >>indicates that incoming TCP/HTTP traffic is blocked for browser when >> >>these requirements are met. If so, Please update the below >> requirement >> >>text with those details. >> >> >> >>Thanks >> >>Partha >> >> >> >>Note: >> >> >> >>---------------------------------------------------------------- >> >> F29 The browser must be able to send streams and >> >> data to a peer in the presence of NATs that >> >> block UDP traffic. >> >> >> >>---------------------------------------------------------------- >> >> F37 The browser must be able to send streams and >> >> data to a peer in the presence of FWs that only >> >> allows traffic via a HTTP Proxy, when FW policy >> >> allows WebRTC traffic. >> >> >> >>_______________________________________________ >> >>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 ------=_NextPart_000_000E_01CECDE0.7D7A2B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Xin & all,

 

Apart from modified F29 by Xin, the following requirement has to be discussed: =

1)      = New requirement for blocking = incoming TCP connection:

a.       =  The browser must be able = to send streams and data to a peer in the presence of NATs and FWs that block = UDP traffic and incoming TCP connection

2)      = New requirement to cover both = browsers are behind the firewall

a.       =   The browser must be = able to send streams and data to a peer in the presence of NATs and FWs that = block UDP traffic and incoming TCP connection  in both browser side as well = as in the peer side (TURN only works)

 

Thanks

Partha

 

From:= Chenxin = (Xin) [mailto:hangzhou.chenxin@huawei.com]
Sent: Thursday, October 17, 2013 3:54 PM
To: Hutton, Andrew; Christer Holmberg; Parthasarathi R; = rtcweb@ietf.org
Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

 

Hi Andy,

 

  I think you means F29 not F27:). When I = read it , I realize that there is cross and ambiguous between 3.3.2 and = 3.3.3

 

  More details:

 

  The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW* that blocks UDP". But in the = description and requirement, only *NAT* is considered.

  The topic of 3.3.3 is "Simple Video Communication Service, FW that only allows http", But only *http = proxy* deployed scenarios is considered.

 

  There are other usecases " FW block = UDP, incoming TCP, Http allowing FW without http proxy deplolyed under the permission of FW policy" , which is lost in the description. If we = need consider these usecases , I suggest to make some change to the = description.

 

  Proposal 1 :

 

  add FW related words to section 3.3.2 =

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

3.3.2.  Simple Video Communication Service, = NAT/FW that blocks UDP

 

3.3.2.1.  Description

 

   This use-case is almost identical = to the Simple Video Communication

   Service use-case (Section = 3.3.1).  The difference is that one of the

   users is behind a NAT*/FW* that = blocks UDP traffic.

.

 

3.3.2.2.  Additional = Requirements

 

   F29     The = browser must be able to send streams and

        &nbs= p;  data to a peer in the presence of NATs *and FWs* that

        &nbs= p;  block UDP traffic ,* when FW policy allows WebRTC traffic*. =

----------------------------------------------------= ---

   Proposal 2: If the" Http = allowing FW without http proxy deployed" case is impliedly included in F29. I = suggest to change the topics of 3.3.3 to "Simple Video Communication = Service, FW that only allows traffic via a http proxy". So the 3.3.3 is a = specific case.

 

    Proposal 3: If " Http = allowing FW without http proxy deployed" case need to be explicitly mentioned. = I suggest to add some descriptions to 3.3.3

----------------------------------------------------= -------------

3.3.3.  Simple Video Communication Service, = FW that only allows http

 

3.3.3.1.  Description

 

   This use-case is almost identical = to the Simple Video Communication

   Service use-case (Section = 3.3.1).  The difference is that one of the

   users is behind a http allowing FW = or a FW that only allows traffic via a HTTP Proxy.

 

3.3.3.2.  Additional = Requirements

 

   F37     The = browser must be able to send streams and

        &nbs= p;  data to a peer in the presence of http allowing FWs or FWs that = only

        &nbs= p;  allows traffic via a HTTP Proxy, when FW policy

        &nbs= p;  allows WebRTC traffic.

----------------------------------------------------= ---------------

 

 

Best Regards,

     Xin

 

 

>-----Original Message-----

>From: Hutton, Andrew = [mailto:andrew.hutton@unify.com]

>Sent: Thursday, October 17, 2013 2:08 = AM

>To: Christer Holmberg; Chenxin (Xin); = Parthasarathi R; rtcweb@ietf.org

>Subject: RE: [rtcweb] Query/Comment = on

>draft-ietf-rtcweb-use-cases-and-requirements-12<= o:p>

> 

>Hi Xin,

> 

>I see the PNTAW mailing list as being there = to discuss potential solutions to

>these requirements which are documented in = the use case draft.

> 

>The requirement F37 is specific to the case = when there is a HTTP Proxy and F27

>would include the case when there is no = proxy.

> 

>Do you see other use cases and requirements = that need to be explicitly brought

>out in = draft-ietf-rtcweb-use-cases-and-requirements?

> 

>Regards

>Andy

> 

> 

>> -----Original = Message-----

>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On

>> Behalf Of Christer = Holmberg

>> Sent: 16 October 2013 = 10:32

>> To: Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org

>> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-

>> requirements-12

>> 

>> Hi Xin,

>> 

>> So, you are saying we shouldn't = finalize the use-case-requirements

>> document yet?

>> 

>> Regards,

>> 

>> Christer

>> 

>> -----Original = Message-----

>> From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]

>> Sent: 16. lokakuuta 2013 = 12:28

>> To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org

>> Subject: RE: [rtcweb] Query/Comment on = draft-ietf-rtcweb-use-cases-and-

>> requirements-12

>> 

>> Hi Christer,

>> 

>> >Hi,

>> >

>> >>  +1. I think we should = wait for the result of PNTAW@ietf.org

>> >> discussion

>> >before modifying the related use = case and requirement. there seems no

>> >clear consensus by = now.

>> >>

>> >>  The related use case is = 3.3.2 , F29 , 3.3.3 and F37.

>> >

>> >Consensus on what?

>> 

>> Should we just consider the case that = " one of the users is behind a FW

>> that only allows traffic via a HTTP = Proxy "? what will happen if there

>> is no http proxy = deployed?

>> 

>> There are two options to solve this = usecase discussed in PNTAW mailing

>> list. "5)UDP relay candidates via = some HTTP/TLS compatible transport

>> (TURN) - MUST/SHOULD (TLS via HTTP = CONNET or TURN over WebSockets

>have

>> been proposed."  List in http://www.ietf.org/mail-

>> = archive/web/pntaw/current/msg00162.html

>> Also there is other discussions in http://www.ietf.org/mail-

>> = archive/web/pntaw/current/msg00166.html.

>> 

>> That all mention that we should = consider more than the http proxy

>> scenarios.

>> 

>> I believe that the PNTAW mailing list = is used for discussion of these

>> similar transport problems, including = the related use case and

>> requirement. In the end , some = consensus should be make to decide what

>> problem we need handle and how to solve = it , which will influence the

>> use case and requirement to make it = more clear.  Is my thought right?

>> Or miss something...

>> 

>> Best Regards,

>>      = Xin

>> >

>> >Note that the draft is only talking = about requirements.

>> >

>> >Regards,

>> >

>> >Christer

>> >

>> >

>> >>-----Original = Message-----

>> >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On

>> >>Behalf Of Parthasarathi = R

>> >>Sent: Tuesday, October 15, 2013 = 3:15 AM

>> >>To: 'Christer Holmberg'; = rtcweb@ietf.org

>> >>Subject: [rtcweb] Query/Comment = on

>> >>draft-ietf-rtcweb-use-cases-and-requirements-12

>> >>

>> >>Hi Christer & = all,

>> >>

>> >>In PNTAW mailing list, there is = a discussion on firewall blocking

>> >>incoming TCP traffic when the = firewall blocks UDP or allows only HTTP

>> >>traffic. The related link = is

>> >>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html.=

>> >>

>> >>Could you please clarify = whether F29 & F37 requirement implicitly

>> >>indicates that incoming = TCP/HTTP traffic is blocked for browser when

>> >>these requirements are met. If = so, Please update the below

>> requirement

>> >>text with those = details.

>> >>

>> >>Thanks

>> >>Partha

>> >>

>> >>Note:

>> >>

>> = >>----------------------------------------------------------------<= o:p>

>> >>   = F29     The browser must be able to send streams and

>> >>           = data to a peer in the presence of NATs that

>> >>           = block UDP traffic.

>> >>

>> = >>----------------------------------------------------------------<= o:p>

>> >>  = F37     The browser must be able to send streams and

>> >>           data to a peer in the presence of = FWs that only

>> >>           = allows traffic via a HTTP Proxy, when FW policy

>> = >>           allows WebRTC traffic.

>> >>

>> >>_______________________________________________

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

------=_NextPart_000_000E_01CECDE0.7D7A2B90-- From suhasietf@gmail.com Sun Oct 20 21:15:50 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D23611E8132; Sun, 20 Oct 2013 21:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXRGX3ZZ3Qrq; Sun, 20 Oct 2013 21:15:49 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C5B5611E8331; Sun, 20 Oct 2013 21:15:46 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w61so6117884wes.10 for ; Sun, 20 Oct 2013 21:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=J7rAvLJWqb947tjl/QGXz7PnLpQC4g+F4JNkzPbGChg=; b=EVcW5sUI3KBx702zXL41x4AtP2F0fXA2M0XuvwEKL4p2E+6H92orXR4uplPHopqVlV lggY5Oghk+BVBe9DLsgIC7zBNug6QEL252kn1X5jyP3ePEcFJ2bEosy0kbVLynEumxQL F3JLE13P9NNxOGpqTXxkI3ryipY1zG/AdpjKvT9SJrHrPAAIS6KFX6kZEiQmcKb5zIH8 wvjDZShJvVnV8fsGdHCf7V9eh83ZVb9Y8B3arXXq3exW8KL/EC58NOXReH1D4n3xeajI A1QNeURBb7r6/VktpsQBlLra9QpLzVMcms6OQ5TlD+9iK01E829GlWFumsXy7Z1zyrDI DiFA== MIME-Version: 1.0 X-Received: by 10.180.182.82 with SMTP id ec18mr8020801wic.13.1382328945431; Sun, 20 Oct 2013 21:15:45 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Sun, 20 Oct 2013 21:15:45 -0700 (PDT) In-Reply-To: <20131021041042.22714.10689.idtracker@ietfa.amsl.com> References: <20131021041042.22714.10689.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 21:15:45 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6250b8c1593a04e938896d Subject: [rtcweb] Fwd: New Version Notification for draft-nandakumar-mmusic-sdp-mux-attributes-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 04:15:50 -0000 --047d7b6250b8c1593a04e938896d Content-Type: text/plain; charset=ISO-8859-1 Hello All Sorry for cross-posting. A new version of draft-nandakumar-mmusic-sdp-mux-attributes has been submitted. By this version have analyzed over 80% of sections by various experts. A Big Thanks to every one who has been helping improve this document every time. I have also listed few OPEN ISSUES that needs to be discussed and I request everyone to go over them and provide their valuable insights. I plan to send follow up emails on these issues in the coming weeks. Cheers Suhas ---------- Forwarded message ---------- From: Date: Sun, Oct 20, 2013 at 9:10 PM Subject: New Version Notification for draft-nandakumar-mmusic-sdp-mux-attributes-05.txt To: Suhas Nandakumar , Suhas Nandakumar < snandaku@cisco.com> A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-05.txt has been successfully submitted by Suhas Nandakumar and posted to the IETF repository. Filename: draft-nandakumar-mmusic-sdp-mux-attributes Revision: 05 Title: A Framework for SDP Attributes when Multiplexing Creation date: 2013-10-18 Group: Individual Submission Number of pages: 57 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-sdp-mux-attributes-05.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-nandakumar-mmusic-sdp-mux-attributes-05 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Sessions multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7b6250b8c1593a04e938896d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All

=A0 Sorry for cross-posting. = A new version of=A0draft-nandakumar-mmusic-sdp-mux-attributes has been subm= itted.=A0

By this version have analyzed over 80% o= f sections by various experts. A Big Thanks to every one who has been helpi= ng improve this document every time.=A0

I have also listed few OPEN ISSUES that needs to be dis= cussed and I request everyone to go over them and provide their valuable in= sights.

I plan to send follow up emails on these i= ssues in the coming weeks.

Cheers
Suhas

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Oct 20, 2013 at 9:10 PM
Subject: New Version Notification for= draft-nandakumar-mmusic-sdp-mux-attributes-05.txt
To: Suhas Nandakumar = <suhasietf@gmail.com>, Suh= as Nandakumar <snandaku@cisco.com<= /a>>



A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-05.txt
has been successfully submitted by Suhas Nandakumar and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-nandakumar-mmusic-sdp-mux-attributes
Revision: =A0 =A0 =A0 =A005
Title: =A0 =A0 =A0 =A0 =A0 A Framework for SDP Attributes when Multiplexing=
Creation date: =A0 2013-10-18
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 57
URL: =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.ietf.org/internet-drafts/draft-nandakumar-mmusic-sdp-mux-attributes-0= 5.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker= .ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/= html/draft-nandakumar-mmusic-sdp-mux-attributes-05
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www= .ietf.org/rfcdiff?url2=3Ddraft-nandakumar-mmusic-sdp-mux-attributes-05<= br>
Abstract:
=A0 =A0The Session Description Protocol (SDP) provides mechanisms to
=A0 =A0describe attributes of multimedia sessions and of individual media =A0 =A0streams (e.g., Real-time Transport Protocol (RTP) sessions) within a=
=A0 =A0multimedia session. =A0In the RTCWeb WG, there is a need to use a =A0 =A0single 5-tuple for sending and receiving media associated with
=A0 =A0multiple media descriptions ("m=3D" lines). =A0Such a requ= irement has
=A0 =A0raised concerns over the semantic implications of the SDP attributes=
=A0 =A0associated with the RTP Sessions multiplexed over a single transport=
=A0 =A0layer flow.

=A0 =A0The scope of this specification is to provide a framework for
=A0 =A0analyzing the multiplexing characteristics of SDP attributes. =A0The=
=A0 =A0specification also categorizes existing attributes based on the
=A0 =A0framework described herein.




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

The IETF Secretariat


--047d7b6250b8c1593a04e938896d-- From suhasietf@gmail.com Sun Oct 20 21:37:09 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C232911E8140 for ; Sun, 20 Oct 2013 21:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQmYTkVU2mxB for ; Sun, 20 Oct 2013 21:37:08 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC011E8132 for ; Sun, 20 Oct 2013 21:37:05 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w61so5872167wes.38 for ; Sun, 20 Oct 2013 21:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+gSVS2TDnUxoeMWH9gWi8/UUeLxeZNA0j1bVOHSw9aM=; b=KpRxuU5XWxBWYMj5QG+X2eqecAqPGz2SJ2mvHG1Bq/WfxQt7+e8NScQNdcnM7oooD0 WDGNoUn457BxYNJA6Mr0/pbeXMZ9JwI/xqW246ZdevWFyph3DBTLsGE1xncNSor9ERcJ xzyZvUWPFlbzm1q/ohJq6dystOpq8yADmyxZE5kRLcuMnE+ZcDkOAzsnfIn/6oU11KQp 0UWK4BOFV5Y+GvJYF+F3h0Vj/yTXDlRL2rMP83GUDOlHuabB9WU8Uvo+WnkGJRL1/or8 4AKU/vPlgc/lqx5q4atX3XfjeKH68xWbSnuJ0t906ayG4yZQlepWUp0PVVTjBM+YlEsN cA7Q== MIME-Version: 1.0 X-Received: by 10.194.193.4 with SMTP id hk4mr11823827wjc.29.1382330224523; Sun, 20 Oct 2013 21:37:04 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Sun, 20 Oct 2013 21:37:04 -0700 (PDT) In-Reply-To: <20131021043533.22792.53200.idtracker@ietfa.amsl.com> References: <20131021043533.22792.53200.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 21:37:04 -0700 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb03946febe2504e938d5fa Subject: [rtcweb] Fwd: New Version Notification for draft-nandakumar-rtcweb-sdp-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 04:37:09 -0000 --047d7bb03946febe2504e938d5fa Content-Type: text/plain; charset=ISO-8859-1 Hello Everyone A new version of SDP Examples draft has been uploaded that reflects latest JSEP updates as well as adds more examples to the list. Please have a read and drop a note on your thoughts. Cheers Suhas ---------- Forwarded message ---------- From: Date: Sun, Oct 20, 2013 at 9:35 PM Subject: New Version Notification for draft-nandakumar-rtcweb-sdp-03.txt To: Cullen Jennings , Suhas Nandakumar < suhasietf@gmail.com>, Suhas Nandakumar A new version of I-D, draft-nandakumar-rtcweb-sdp-03.txt has been successfully submitted by Suhas Nandakumar and posted to the IETF repository. Filename: draft-nandakumar-rtcweb-sdp Revision: 03 Title: SDP for the WebRTC Creation date: 2013-10-20 Group: Individual Submission Number of pages: 105 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-rtcweb-sdp-03.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-sdp Htmlized: http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-nandakumar-rtcweb-sdp-03 Abstract: The Web Real-Time Communication (WebRTC) [WEBRTC] working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism described in the RFC 3264 [RFC3264]. This documents provides an informational reference in describing the role of SDP and Offer/Answer exchange for the most common WebRTC use- cases. This SDP examples provided in this document is still a work in progress, but it aims to align closest to the evolving standards work. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7bb03946febe2504e938d5fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Everyone

=A0 A new version of SDP= Examples draft has been uploaded that reflects latest JSEP updates as well= as adds more examples to the list.

Please have a = read and drop a note on your thoughts.

Cheers
Suhas

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Oct 20, 2013 at 9:35 PM
Subject: New Version Notification for= draft-nandakumar-rtcweb-sdp-03.txt
To: Cullen Jennings <fluffy@cisco.com>, Suhas Nandakumar <suhasietf@gmail.com>, Suhas Nanda= kumar <snandaku@cisco.com><= br>


A new version of I-D, draft-nandakumar-rtcweb-sdp-03.txt
has been successfully submitted by Suhas Nandakumar and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-nandakumar-rtcweb-sdp
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 SDP for the WebRTC
Creation date: =A0 2013-10-20
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 105
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/= internet-drafts/draft-nandakumar-rtcweb-sdp-03.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-nandakumar-rtcweb-sdp
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-nand= akumar-rtcweb-sdp-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdi= ff?url2=3Ddraft-nandakumar-rtcweb-sdp-03

Abstract:
=A0 =A0The Web Real-Time Communication (WebRTC) [WEBRTC] working group is =A0 =A0charged to provide protocol support for direct interactive rich
=A0 =A0communication using audio, video and data between two peers' web=
=A0 =A0browsers. =A0With in the WebRTC framework, Session Description proto= col
=A0 =A0(SDP) [RFC4566] is used for negotiating session capabilities between=
=A0 =A0the peers. =A0Such a negotiation happens based on the SDP Offer/Answ= er
=A0 =A0exchange mechanism described in the RFC 3264 [RFC3264].

=A0 =A0This documents provides an informational reference in describing the=
=A0 =A0role of SDP and Offer/Answer exchange for the most common WebRTC use= -
=A0 =A0cases.

=A0 =A0This SDP examples provided in this document is still a work in
=A0 =A0progress, but it aims to align closest to the evolving standards
=A0 =A0work.




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

The IETF Secretariat


--047d7bb03946febe2504e938d5fa-- From harald@alvestrand.no Mon Oct 21 07:21:49 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA4F11E85E3 for ; Mon, 21 Oct 2013 07:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZqbMimn9KuC for ; Mon, 21 Oct 2013 07:21:44 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9A11E81CE for ; Mon, 21 Oct 2013 07:21:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9EF239E095 for ; Mon, 21 Oct 2013 16:21:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHCyl9nf+yWv for ; Mon, 21 Oct 2013 16:21:26 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 28CCF39E070 for ; Mon, 21 Oct 2013 16:21:26 +0200 (CEST) Message-ID: <5265386A.2020005@alvestrand.no> Date: Mon, 21 Oct 2013 16:21:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.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 Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:21:49 -0000 On 10/18/2013 06:34 PM, Martin Thomson wrote: > On 17 October 2013 18:38, Eric Rescorla wrote: >> I'm not sure this was a sensible rule on 4572, but I don't think it's >> particularly harmful. > Right. I'd have gone with a rule that said: MUST validate a > "strong-enough" hash; MAY ignore others; MUST fail validation if any > hash doesn't match. That gives you backwards compatibility + hash > agility. > > That only works of course if there is only one potential certificate > that can be used. If you have to allow for several, then that doesn't > work. But then you lose the advantages of the above. The interesting cases are: Consider 2 hash algorithms, A and B. Receiving browser supports A, but not B. Fingerprint uses A, certificate uses A: No problem. Fingerprint uses B, certificate uses B: Browser can't verify fingerprint, but can't use cert anyway. Fingerprint uses A, certificate uses B: Browser can verify that it got the right useless certificate. Fingerprint uses B, certificate uses A: Browser can't verify the certificate, so can't trust it, even though it might have been useful. Note that whether A or B is the stronger hash is not relevant to this exercise. When receiving browser supports both A and B, we could argue that they should be allowed to be different in the name of algorithm agility. But is there a real gain in security achieved by it? > >>> That should probably be written down, of course. >> Agreed. > The question is: where? > > I have a few hours, maybe I can write down an update to 4572 that fixes this. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From internet-drafts@ietf.org Mon Oct 21 08:22:03 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81E11E840A; Mon, 21 Oct 2013 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTY8TducAVHX; Mon, 21 Oct 2013 08:22:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B344E11E83F2; Mon, 21 Oct 2013 08:22:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021152200.29469.13282.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 08:22:00 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-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, 21 Oct 2013 15:22:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-10.txt Pages : 41 Date : 2013-10-21 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-10 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 martin.thomson@gmail.com Mon Oct 21 09:39:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A34A11E85D6 for ; Mon, 21 Oct 2013 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpwV0VATb8sJ for ; Mon, 21 Oct 2013 09:39:56 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id A856311E8532 for ; Mon, 21 Oct 2013 09:38:12 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm4so4313499wib.6 for ; Mon, 21 Oct 2013 09:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d3NKKqbZFBWOb6rKOZl3LbowrHo2CPfQpraRau9hc8Y=; b=EWODzR6ZffP2ExkDKEatlbZCqZrcNLXMrq5UIp4VtjmMeqgUKH5dF5GMIR2mh+drvO qeByIMc4pxw33oMaO04nzyhWHWP3b9e57kwpX1XpZ+moG93Gh57U8+KyvyF2Y1vi7hnW zweIpkvbeZ8aRxXWGBIUpJ3I7D2tDTTWTk4uecyBn85L/H8qiljkBbfMzIZBCTzIkbiw QwtMw3Pr41TRQS0e1ziC88c85bpiwFChpqGzgsiDf6RhkDBTcqp7G7OpbSHA93Cqdc6e xDqgZDj0G+6xYK0cu+Pnc8+nHXcr1fhU+pDB+f1rq127AVAE+ytFI//R4CWjdlMvGIqL OoFA== MIME-Version: 1.0 X-Received: by 10.180.92.100 with SMTP id cl4mr13650337wib.1.1382373491269; Mon, 21 Oct 2013 09:38:11 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Mon, 21 Oct 2013 09:38:11 -0700 (PDT) In-Reply-To: <5265386A.2020005@alvestrand.no> References: <5265386A.2020005@alvestrand.no> Date: Mon, 21 Oct 2013 09:38:11 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:39:57 -0000 On 21 October 2013 07:21, Harald Alvestrand wrote: > When receiving browser supports both A and B, we could argue that they > should be allowed to be different in the name of algorithm agility. But is > there a real gain in security achieved by it? Those are interesting cases, but they easily solved by saying something like "MUST include/implement SHA-256". I don't think that the hash used by the certificate is actually relevant either. Fingerprints are calculated, not observed or extracted. From partha@parthasarathi.co.in Mon Oct 21 09:56:44 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7088D11E840F for ; Mon, 21 Oct 2013 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOQbhr3bUCaq for ; Mon, 21 Oct 2013 09:56:39 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id B474511E8698 for ; Mon, 21 Oct 2013 09:55:06 -0700 (PDT) Received: from userPC (unknown [122.179.74.220]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id BB376869390; Mon, 21 Oct 2013 16:55:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382374506; bh=rSxF9BvFt0fUbZJMuwMctpowELGmmGV8dGqLN3ZJlnU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=cn8QxfxlHXNmG6oRZ3rFGmK+4CGpi9qhGMpq+4vvM/jO+DZ/RqMxK7MctNg2cuWIm DnZL14C0GSs9T+gQgsQuy3o/5hDxozbS4lUoBEDeBx2dAZKchSkTL0qt0E7oqEBQax QMSSOV8EZM/Jiydmtf6brLAuFJI0UGdLAmf88xQ8= From: "Parthasarathi R" To: Date: Mon, 21 Oct 2013 22:24:58 +0530 Message-ID: <008e01cece7e$49d107c0$dd731740$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7OfMle3W1kE13gRIe8C7JB0g8RzAAAKOjg Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.52655C6A.006A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.154 Cc: elangovan.manickam@nsn.com Subject: [rtcweb] FW: New Version Notification for draft-partha-rtcweb-jsep-sip-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:56:44 -0000 Hi all, Offer & Answer interworking between JSEP & SIP (-01) draft is updated = with the following changes:=20 1) Callflow for Trickle ICE handling in JSEP-SIP O/A interworking 2) Added clarification text why PRANSWER is not possible to be used for = JSEP to SIP interworking. Could you please provide your valuable comments. Thanks Partha -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 21, 2013 10:14 PM To: Uwe Rauschenbach; Elangovan Manickam; Parthasarathi Ravindran Subject: New Version Notification for = draft-partha-rtcweb-jsep-sip-01.txt A new version of I-D, draft-partha-rtcweb-jsep-sip-01.txt has been successfully submitted by Parthasarathi Ravindran and posted to = the IETF repository. Filename: draft-partha-rtcweb-jsep-sip Revision: 01 Title: Offer & Answer interworking between JSEP & SIP Creation date: 2013-10-21 Group: Individual Submission Number of pages: 15 URL: = http://www.ietf.org/internet-drafts/draft-partha-rtcweb-jsep-sip-01.txt Status: = http://datatracker.ietf.org/doc/draft-partha-rtcweb-jsep-sip Htmlized: = http://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-partha-rtcweb-jsep-sip-01 Abstract: Real time communcation Web (RTCWeb) workgroup defines the real time commmunication using JavaScript Session establishment protocol (JSEP) as an offer/answer mechanism. Session Initiation protocol (SIP) is IETF defined and well deployed protocol for real time communication. This document provides offer & answer interworking between JSEP and SIP. = =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. The IETF Secretariat From harald@alvestrand.no Mon Oct 21 10:53:57 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B2A11E836C for ; Mon, 21 Oct 2013 10:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxRiUFzgYz5X for ; Mon, 21 Oct 2013 10:53:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7852311E8377 for ; Mon, 21 Oct 2013 10:53:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F2C639E095; Mon, 21 Oct 2013 19:53:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EN0ToASKmrB; Mon, 21 Oct 2013 19:53:10 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7DF8939E070; Mon, 21 Oct 2013 19:53:10 +0200 (CEST) Message-ID: <52656A0A.5010006@alvestrand.no> Date: Mon, 21 Oct 2013 19:53:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Martin Thomson References: <5265386A.2020005@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:53:57 -0000 On 10/21/2013 06:38 PM, Martin Thomson wrote: > On 21 October 2013 07:21, Harald Alvestrand wrote: >> When receiving browser supports both A and B, we could argue that they >> should be allowed to be different in the name of algorithm agility. But is >> there a real gain in security achieved by it? > Those are interesting cases, but they easily solved by saying > something like "MUST include/implement SHA-256". > > I don't think that the hash used by the certificate is actually > relevant either. Fingerprints are calculated, not observed or > extracted. Welll... if the hash is what I think it is, you need to compute the hash of the certificate (in the algorithm specified in the certificate) in order to verify the RSA signature of the certificate. So if you don't understand the hash algorithm the certificate specifies .... you can't verify the certificate's signature, and you are open to a forged-certificate attack. Again - saying that they have to be the same means that you only have to deal with one bad situation (you understand neither), and not three bad situations (you are toast because there's one of them you don't understand). But I'm not a REAL crypto expert. I may have misunderstood something. From martin.thomson@gmail.com Mon Oct 21 10:58:17 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DE11E8361 for ; Mon, 21 Oct 2013 10:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peLc36LIytl0 for ; Mon, 21 Oct 2013 10:58:17 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B6B2B11E825C for ; Mon, 21 Oct 2013 10:57:57 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so4947293wgh.2 for ; Mon, 21 Oct 2013 10:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wRQF+2efBAPyu2cacs5RZP5RqE3ibmPxrstb+OfegNg=; b=AgZcMyul7eL+WfCjty2bENXy4HaBbAyUSxNaZ5MuNlihjlm2pJ9j3SwTxXtqXDAV7V y33mSof193DIBQ4iiz7bka/cJxf8FCJT4w04exeZQXGGSRnRtS7kzaNDLMY4Wz0fiNVf NJDQkunyzjTmbyfguoGbTqOQMy5+TfVH1dPE4HdPVt4c8PyNRGqB0HccXd6pcC2c9nDK 97BPikM86HE3hOVViCBNiQtj8xKcCgJjeosWSNfxLmEbkLcFonVnPJAnuOKo4a+jVQ6j krcupyk6GD4m3sQAmNy0QbalA5zVzV042iXY5iPjOjyQCb0ukpsxOwbnd4DrMMewGIm4 klRw== MIME-Version: 1.0 X-Received: by 10.194.21.131 with SMTP id v3mr2869875wje.44.1382378276881; Mon, 21 Oct 2013 10:57:56 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Mon, 21 Oct 2013 10:57:56 -0700 (PDT) In-Reply-To: <52656A0A.5010006@alvestrand.no> References: <5265386A.2020005@alvestrand.no> <52656A0A.5010006@alvestrand.no> Date: Mon, 21 Oct 2013 10:57:56 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:58:17 -0000 On 21 October 2013 10:53, Harald Alvestrand wrote: > you can't verify the certificate's signature, That's somewhat orthogonal. And thankfully, not necessary unless you intend to use the certificate for anything more than its public key. And in at least some of the cases we are talking about, we only need that to work. But then you are talking about a different sort of problem, which is a well-known one, which is the validation of certificates. I'm talking about a=fingerprint. From internet-drafts@ietf.org Mon Oct 21 12:14:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB51E11E8248; Mon, 21 Oct 2013 12:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INCGikczBoMe; Mon, 21 Oct 2013 12:14:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A520711E8416; Mon, 21 Oct 2013 12:13:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021191313.32469.99466.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:13:13 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-06.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-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, 21 Oct 2013 19:14:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWeb Data Channels Author(s) : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-06.txt Pages : 15 Date : 2013-10-21 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies the non-media data transport aspects of the RTCWeb framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the RTCWeb context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-06 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 internet-drafts@ietf.org Mon Oct 21 12:14:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7249511E8253; Mon, 21 Oct 2013 12:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ00dMGz9kkn; Mon, 21 Oct 2013 12:14:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F80511E86DB; Mon, 21 Oct 2013 12:13:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:13:43 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-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, 21 Oct 2013 19:14:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWeb Data Channel Protocol Author(s) : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-protocol-01.txt Pages : 11 Date : 2013-10-21 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-protocol-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From grs@well.com Mon Oct 21 12:15:00 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B876B11E86C1 for ; Mon, 21 Oct 2013 12:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ-mFIxO+or0 for ; Mon, 21 Oct 2013 12:14:56 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6C11E824A for ; Mon, 21 Oct 2013 12:14:05 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.236.158.246]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id r9LJE38Y028114 for ; Mon, 21 Oct 2013 12:14:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 2DC714012A84 for ; Mon, 21 Oct 2013 12:14:03 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XpSFfooQ_cr0 for ; Mon, 21 Oct 2013 12:13:56 -0700 (PDT) Received: from zimbra.well.com (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id B84FC4012A82 for ; Mon, 21 Oct 2013 12:13:55 -0700 (PDT) Received: from [10.30.65.161] (router300.core.archive.org [208.70.31.249]) by zimbra.well.com (Postfix) with ESMTPSA id EAEC04012A80 for ; Mon, 21 Oct 2013 12:13:54 -0700 (PDT) From: Roger Macdonald Content-Type: multipart/alternative; boundary="Apple-Mail=_823AAEAA-E47F-4BE6-AF2C-8E2EB45A6668" Date: Mon, 21 Oct 2013 12:13:53 -0700 Message-Id: <398D0635-2F8C-42A4-9C11-9C1CC524D587@well.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [rtcweb] NSA-issues TV news quote library X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Roger Macdonald List-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, 21 Oct 2013 19:15:00 -0000 --Apple-Mail=_823AAEAA-E47F-4BE6-AF2C-8E2EB45A6668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 To assist journalists and other concerned citizens in reflecting on the = extent of National Security Agency surveillance and weakening of our = digital infrastructure, the Internet Archive has created a curated = library of short television news clips presenting key statements and = other representations. https://archive.org/details/nsa The experimental, Chrome and Safari only, library launches today with = more than 700 chronologically ordered television citations drawn from = the Archive=92s television news research service. The TV quotes can be = browsed by rolling over clip thumbnails, queried via transcripts and = sorted for specific speakers. Citation links, context, connections to = source broadcasters and options to borrow can be explored by following = the More/Borrow links on each thumbnail. My best, Roger Roger Macdonald Director, Television Archive Internet Archive --Apple-Mail=_823AAEAA-E47F-4BE6-AF2C-8E2EB45A6668 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 https://archive.org/details/nsa

The experimental, Chrome and Safari only, = library launches today with more than 700 chronologically ordered = television citations drawn from the Archive=92s television = news research service.  The TV quotes can be browsed by = rolling over clip thumbnails, queried via transcripts and sorted = for specific speakers.  Citation links, context, connections = to source broadcasters and options to borrow can be explored = by following the More/Borrow links on each = thumbnail.

My best, = Roger

Roger Macdonald
Director, = Television Archive
Internet = Archive

= --Apple-Mail=_823AAEAA-E47F-4BE6-AF2C-8E2EB45A6668-- From basilgohar@librevideo.org Mon Oct 21 12:23:59 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCD011E83BD for ; Mon, 21 Oct 2013 12:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMRg7DUkrGOd for ; Mon, 21 Oct 2013 12:23:54 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6086311E848A for ; Mon, 21 Oct 2013 12:23:49 -0700 (PDT) Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 9D580659DBE for ; Mon, 21 Oct 2013 15:23:48 -0400 (EDT) Message-ID: <52657F41.1090206@librevideo.org> Date: Mon, 21 Oct 2013 15:23:45 -0400 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <398D0635-2F8C-42A4-9C11-9C1CC524D587@well.com> In-Reply-To: <398D0635-2F8C-42A4-9C11-9C1CC524D587@well.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] NSA-issues TV news quote library X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:23:59 -0000 On 10/21/2013 03:13 PM, Roger Macdonald wrote: > To assist journalists and other concerned citizens in reflecting on > the extent of National Security Agency surveillance and weakening of our > digital infrastructure, the Internet Archive has created a > curated library of short television news clips presenting key statements > and other representations. > > https://archive.org/details/nsa > > The experimental, Chrome and Safari only, library launches today with > more than 700 chronologically ordered television citations drawn from > the Archive’s television news research service. The TV quotes can be > browsed by rolling over clip thumbnails, queried via transcripts and > sorted for specific speakers. Citation links, context, connections > to source broadcasters and options to borrow can be explored by > following the More/Borrow links on each thumbnail. > > My best, Roger > > Roger Macdonald > Director, Television Archive > Internet Archive Are there any plans to transcode these videos to either WebM or Ogg Theora formats to enable support in Firefox, for example? -- Libre Video http://librevideo.org From vimandav@cisco.com Mon Oct 21 12:32:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFDB11E86DB for ; Mon, 21 Oct 2013 12:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbMfp8zpGyF3 for ; Mon, 21 Oct 2013 12:32:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B9FA211E86E6 for ; Mon, 21 Oct 2013 12:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9375; q=dns/txt; s=iport; t=1382383904; x=1383593504; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Vkf+w+/wYYstiK1OQSHDB3s5YwdpJFGTRV6DqkqYYJ0=; b=DSNIXxoe7RzCUjqX7iKV7wmtj6V6Y42n+FlVo5TM4UBJml2xCVQ2LadA IbKcH01pyVBNzpR8Mnws6Ebk2Nn3i/pbkj8bVz4f6Uz3vLWtfKiK6v/Is HshgfWTxbeQZ90zaHc52BlM1PfM43FczhY5+Duwec5fPbaN/NDO57Q70A w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAMqAZVKtJV2a/2dsb2JhbABPCoJDRDhUhEi5GEuBLhZ0giUBAQEDAQEBAQkRUQsSAQgiHS4LFBECBAENBQgTh2UGDbovBI4YgRItBAeDH4EKA5QqjjGHNYMkgWgHOw X-IronPort-AV: E=Sophos;i="4.93,541,1378857600"; d="scan'208,217";a="274779464" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 21 Oct 2013 19:31:44 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9LJVisA002202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 19:31:44 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.2]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 14:31:43 -0500 From: "Vijaya Mandava (vimandav)" To: Christer Holmberg , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AOFXEGAAAfNNAAAHcUNAAAAzX2AAABBagAAAfYrAACMKwqA Date: Mon, 21 Oct 2013 19:31:42 +0000 Message-ID: <1CDFD781608D924094E43F573C351961124C7D16@xmb-rcd-x13.cisco.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4C336D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.30.247] Content-Type: multipart/alternative; boundary="_000_1CDFD781608D924094E43F573C351961124C7D16xmbrcdx13ciscoc_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "Suhas Nandakumar \(snandaku\)" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:32:10 -0000 --_000_1CDFD781608D924094E43F573C351961124C7D16xmbrcdx13ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Christer, I agree that parallel and serial forking call flows can be solved with mul= tiple PeerConnection model. But going back to the original question you had - >>> However, according the 3264, the ORDER of the m- lines also need to be = kept the same. >>> So, my question is: how can I ensure that the order of the m- lines in = an Offer for a new PeerConnection is the same as in an Offer for an old Pee= rConnection? The Jsep doc 4.1.4 setLocalDescription already implies that a new PeerConen= ction would use/support the old local description, and reading it, assumpti= on is that the old description m-line ordering would not be changed. It definitely didn't mention that we would send entirely new SDP on the new= PeerConnection created=85 We can call for clarification in the Jsep doc, but definitely not a issue a= s far as I see. Thanks, Vijaya On 10/18/13 4:38 PM, "Christer Holmberg" > wrote: Hi, Again, it is not specific to parallel forking - it is also needed for SERIA= L forking, in cases where you need to send updated Offers on early dialogs,= and therefore cannot use PRANSWER. I don't think I agree on that but I really want to spend my time on making = sure we get the setLocal / setRemote text working for the simple case befor= e we sort all this out. This is how I understand it would work when discussing with Vijaya . Now, if you don't agree, please then explain how you would implement the fo= rking case I provided :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] L=E4hetetty: 18. lokakuuta 2013 22:12 Vastaanottaja: Christer Holmberg Kopio: Suhas Nandakumar; rtcweb@ietf.org Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections On Oct 17, 2013, at 10:59 PM, Christer Holmberg > wrote: And, I'm not asking for a solution at this point, simply that we identify i= t as an issue that needs to be solved :) So I sort of disagree on two points here. I disagree that it needs to be solved - I'm not against solving it if anyon= e has an easy way but every time we talk about this the conclusions comes u= p people don't want to bother to fully solve the parallel forking problem i= n the first version of the webrtc. Speaking purely for myself, SIP parallel= forking has not turned out to be extremely useful and has turned out to se= riously complicate the use and extensions to the protocol - basically the H= ERFP problem - so I don't really care if webrtc takes on that problem or no= t. Second, I suspect that Invite with replaces actually does solve this. I certainly don't mind marking it as an issue but it's not clear to me that= the WG thinks it is an issue that needs to be solved or that it an issue t= hat is not solved. I've sort of been waiting to see the other "easy" stuff = in JSEP / Bundle / Unified plan get sorted out and then figured we could go= back and see what was possible or not with parallel forking in SIP. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_1CDFD781608D924094E43F573C351961124C7D16xmbrcdx13ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3DA94E04EA913946B6141F73BD65A9EC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Christer,  
I agree that parallel  and serial forking call flows can be solve= d with multiple PeerConnection model.

But going back to the original question you had -
>>> However, according the 3264, the ORDER of the m- lines al= so need to be kept the same.
>>> So, my question is: how can I ensure that the order of th= e m- lines in an Offer for a new PeerConnection is the same as in an Offer = for an old PeerConnection?

The Jsep doc 4.1.4 setLocalDescription already implies that a new Peer= Conenction would use/support the old local description, and reading it, ass= umption is that the old description m-line ordering would not be changed.
It definitely didn't mention that we would send entirely new SDP on th= e new PeerConnection created=85

We can call for clarification in the Jsep doc, but definitely not a is= sue as far as I see.

Thanks,
Vijaya

On 10/18/13 4:38 PM, "Christer Holmberg" <christer.holmberg@ericsson.com> w= rote:

Hi,

Again, it is not specific to parallel forking - it is also needed for = SERIAL forking, in cases where you need to send updated Offers on early dia= logs, and therefore cannot use PRANSWER.

I don't think I agree on that but I really want to spend my time on ma= king sure we get the setLocal / setRemote text working for the simple case = before we sort all this out.

This is how I understand it would work when discussing with Vijaya .

Now, if you don't agree, please then explain how you would implement t= he forking case I provided :)

Regards,

Christer



-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
L=E4hetetty: 18. lokakuuta 2013 22:12
Vastaanottaja: Christer Holmberg
Kopio: Suhas Nandakumar; rtcweb@iet= f.org
Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections=
On Oct 17, 2013, at 10:59 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrot= e:
And, I'm not asking for a solution at this point, simply that we ident= ify it as an issue that needs to be solved :)
So I sort of disagree on two points here.
I disagree that it needs to be solved - I'm not against solving it if = anyone has an easy way but every time we talk about this the conclusions co= mes up people don't want to bother to fully solve the parallel forking prob= lem in the first version of the webrtc. Speaking purely for myself, SIP parallel forking has not turned ou= t to be extremely useful and has turned out to seriously complicate the use= and extensions to the protocol - basically the HERFP problem - so I don't = really care if webrtc takes on that problem or not.
Second, I suspect that Invite with replaces actually does solve this. =
I certainly don't mind marking it as an issue but it's not clear to me= that the WG thinks it is an issue that needs to be solved or that it an is= sue that is not solved. I've sort of been waiting to see the other "ea= sy" stuff in JSEP / Bundle / Unified plan get sorted out and then figured we could go back and see what was pos= sible or not with parallel forking in SIP.

_______________________________________________
rtcweb mailing list

--_000_1CDFD781608D924094E43F573C351961124C7D16xmbrcdx13ciscoc_-- From ted.ietf@gmail.com Mon Oct 21 12:53:28 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17FF11E8739 for ; Mon, 21 Oct 2013 12:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxWun2O1c6VG for ; Mon, 21 Oct 2013 12:53:28 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9997421F8FF8 for ; Mon, 21 Oct 2013 12:52:02 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id aq17so12916285iec.10 for ; Mon, 21 Oct 2013 12:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YaNf1VpQvDBUw4/dT2VeIwGdULoct66axpkaTVINT9k=; b=I8LlaKHqiL5Sr5fj869yMUubnhVaIiVLLrxEKFc4qWAHvQ86QBrDqJIo7Gh/f9rJWl bQMopjlQ5cU4x12Z+yF83b/6EVwYFjPnr+0Ms2UWoygb/3pwJvthe2EGfPuDKCGHfXC/ qRPsUh1L1Yw/cc78bHLmhYVSMfceXLnrR7wXZKwMALVg6H0igppqb3cuu7llstrQgkTx Iyl1TgwEl2Te2XDpw2lvGA9IUmftqkFbpJ8/pcj/dFaHa5WCvBy+MRYTdOyYgcs+TTjP rTBFXftPL0sTatYZiX6YIXonzmxkYvgRYY8PZCBB9dTOMWJ1Jqzz8roms1y73hDsYnum 1pBA== MIME-Version: 1.0 X-Received: by 10.42.98.76 with SMTP id r12mr1828768icn.59.1382385121667; Mon, 21 Oct 2013 12:52:01 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Mon, 21 Oct 2013 12:52:01 -0700 (PDT) In-Reply-To: <398D0635-2F8C-42A4-9C11-9C1CC524D587@well.com> References: <398D0635-2F8C-42A4-9C11-9C1CC524D587@well.com> Date: Mon, 21 Oct 2013 12:52:01 -0700 Message-ID: From: Ted Hardie To: Roger Macdonald Content-Type: multipart/alternative; boundary=90e6ba614a961eb34304e9459e6c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] NSA-issues TV news quote library X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:53:29 -0000 --90e6ba614a961eb34304e9459e6c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roger, I think this topic is better suited to perpass@ietf.org, which is looking at pervasive passive monitoring. regards, Ted Hardie On Mon, Oct 21, 2013 at 12:13 PM, Roger Macdonald wrote: > To assist journalists and other concerned citizens in reflecting on > the extent of National Security Agency surveillance and weakening of our > digital infrastructure, the Internet Archive has created a curated librar= y > of short television news clips presenting key statements and other > representations. > > https://archive.org/details/nsa > > The experimental, Chrome and Safari only, library launches today with mor= e > than 700 chronologically ordered television citations drawn from the > Archive=92s television news research service. The TV quotes can be brows= ed > by rolling over clip thumbnails, queried via transcripts and sorted for > specific speakers. Citation links, context, connections to source > broadcasters and options to borrow can be explored by following the > More/Borrow links on each thumbnail. > > My best, Roger > > Roger Macdonald > Director, Television Archive > Internet Archive > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --90e6ba614a961eb34304e9459e6c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Roger,

I think this topic is better s= uited to perpass@ietf.org, which is= looking at pervasive passive monitoring.

regards,

Ted Hardie=


On Mon,= Oct 21, 2013 at 12:13 PM, Roger Macdonald <grs@well.com> wrote:<= br>
To assist=A0journalists and other = concerned citizens in reflecting on the=A0extent of National Security=A0Age= ncy surveillance and weakening of our digital infrastructure, the=A0Interne= t Archive has created a curated=A0library of short television news clips=A0= presenting key statements and other representations.


The exp= erimental, Chrome and Safari only, library launches=A0today with more than = 700 chronologically ordered television=A0citations drawn=A0from the Archive= =92s television news research service.=A0=A0The TV quotes can be browsed by= rolling over clip=A0thumbnails, queried via transcripts and sorted for spe= cific speakers.=A0=A0Citation links, context, connections to=A0source broad= casters and=A0options to borrow can be explored by following the More/Borro= w=A0links on each thumbnail.

My best, Roger

Roger Macdonald
Director, Televi= sion Archive
Internet Archive

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


--90e6ba614a961eb34304e9459e6c-- From christer.holmberg@ericsson.com Mon Oct 21 13:17:18 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3DC11E8243 for ; Mon, 21 Oct 2013 13:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-bFx4RL3oUM for ; Mon, 21 Oct 2013 13:17:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 12E0711E86DC for ; Mon, 21 Oct 2013 13:16:37 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-ee-52658ba433fd Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FC.EF.03802.4AB85625; Mon, 21 Oct 2013 22:16:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 22:16:36 +0200 From: Christer Holmberg To: "Vijaya Mandava (vimandav)" , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AN2sSmAAAv+KVkAGZQYAAAE0Y4gAArpVgAACKGa8AB/NYkAAAWRWswAADD9eQ== Date: Mon, 21 Oct 2013 20:16:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E6402@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4C336D@ESESSMB209.ericsson.se>, <1CDFD781608D924094E43F573C351961124C7D16@xmb-rcd-x13.cisco.com> In-Reply-To: <1CDFD781608D924094E43F573C351961124C7D16@xmb-rcd-x13.cisco.com> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E6402ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje7S7tQgg+c72S06JrNZrP3Xzm6x +MB9VovmaSdYHFg8pvzeyOqxZMlPpgCmKC6blNSczLLUIn27BK6MLY3SBY9CKj78fsHYwPjN rYuRk0NCwETiw7SbjBC2mMSFe+vZuhi5OIQEDjNKNB54wwrhLGGUWHlqMUsXIwcHm4CFRPc/ bZAGEYFUienPGtlBbGaBWIlDc64xgdjCAp4SXZe62UHKRQS8JC5uFYMoz5J4Of8M2C4WAVWJ DTveMoPYvAK+Euuu/maGWNXHKLH84mewOZxAic3/PrOA2IxAx30/tYYJYpe4xK0n85kgjhaQ WLLnPDOELSrx8vE/VpC9EgJKEtO2poGYzAL5Eo/epkKsEpQ4OfMJywRG0VlIBs1CqJqFpAqi xEDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hJPNpxkQVazgJFjFSN7bmJmTnq50SZGYNQd3PJb dQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4u/DEvOkljddS 2IXesjCHPQtY8rTsV0euXHVR86Wi1PDjxQX/OkL0TB8tfjvtUBLPBsadbqzSC34/f6F3cfbW rXoHi5ramg/tU49entUmxr4sP8HllGDEtBkLN1qU7d7YWPObbYnhlP/2O2edvJ/fYV/f2ihc 9azxea9gdu/7h1bT+HgOBzkrsRRnJBpqMRcVJwIAoLTmvIgCAAA= Cc: "rtcweb@ietf.org" , "Suhas Nandakumar \(snandaku\)" Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:17:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4E6402ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Vijaya, > I agree that parallel and serial forking call flows can be solved with m= ultiple PeerConnection model. > > But going back to the original question you had - >>> However, according the 3264, the ORDER of the m- lines also need to be = kept the same. >>> So, my question is: how can I ensure that the order of the m- lines in = an Offer for a new PeerConnection is the same as in an Offer for an old Pee= rConnection? > > The Jsep doc 4.1.4 setLocalDescription already implies that a new PeerCon= enction would use/support the old local description, and reading it, assump= tion is that the old description m-line ordering would not be changed. My understanding (please correct me if I'm wrong) is that you have to call = createOffer before you call setLocalDescription, so it would be useful to g= et the right order already when calling createOffer. > It definitely didn't mention that we would send entirely new SDP on the n= ew PeerConnection created=85 Well, it depends on what you mean with "entirely new". At least the address= /candidate information would be new, as the new PeerConnections can't share= the address/candidates with the old one. Regards, Christer On 10/18/13 4:38 PM, "Christer Holmberg" > wrote: Hi, Again, it is not specific to parallel forking - it is also needed for SERIA= L forking, in cases where you need to send updated Offers on early dialogs,= and therefore cannot use PRANSWER. I don't think I agree on that but I really want to spend my time on making = sure we get the setLocal / setRemote text working for the simple case befor= e we sort all this out. This is how I understand it would work when discussing with Vijaya . Now, if you don't agree, please then explain how you would implement the fo= rking case I provided :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] L=E4hetetty: 18. lokakuuta 2013 22:12 Vastaanottaja: Christer Holmberg Kopio: Suhas Nandakumar; rtcweb@ietf.org Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections On Oct 17, 2013, at 10:59 PM, Christer Holmberg > wrote: And, I'm not asking for a solution at this point, simply that we identify i= t as an issue that needs to be solved :) So I sort of disagree on two points here. I disagree that it needs to be solved - I'm not against solving it if anyon= e has an easy way but every time we talk about this the conclusions comes u= p people don't want to bother to fully solve the parallel forking problem i= n the first version of the webrtc. Speaking purely for myself, SIP parallel= forking has not turned out to be extremely useful and has turned out to se= riously complicate the use and extensions to the protocol - basically the H= ERFP problem - so I don't really care if webrtc takes on that problem or no= t. Second, I suspect that Invite with replaces actually does solve this. I certainly don't mind marking it as an issue but it's not clear to me that= the WG thinks it is an issue that needs to be solved or that it an issue t= hat is not solved. I've sort of been waiting to see the other "easy" stuff = in JSEP / Bundle / Unified plan get sorted out and then figured we could go= back and see what was possible or not with parallel forking in SIP. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C4E6402ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Vijaya,

 

> I agree that parallel  and serial forking call flows can be so= lved with multiple PeerConnection model.

>
> But going back to the original question you had -
>>> However, according the 3264, the ORDER of the m- lines al= so need to be kept the same.
>>> So, my question is: how can I ensure that the order of th= e m- lines in an Offer for a new PeerConnection is the same as in an Offer = for an old PeerConnection?
>
> The Jsep doc 4.1.4 setLocalDescription already implies that a new= PeerConenction would use/support the old local description, and reading it= , assumption is that the old description m-line ordering would not be chang= ed.
 
My understanding (please correct me if I'm wrong) is that you have to = call createOffer before you call setLocalDescription, so it would= be useful to get the right order already when calling createOffer.
 
> It definitely didn't mention that we would send entirely new SDP = on the new PeerConnection created=85
 
Well, it depends on what you mean with "entirely new". At le= ast the address/candidate information would be new, as the new PeerConnecti= ons can't share the address/candidates with the old one.
 
Regards,
 
Christer
 
 

 
On 10/18/13 4:38 PM, "Christer Holmberg" <christer.holmberg@eric= sson.com> wrote:

Hi,

Again, it is not specific to parallel forking - it is also needed for = SERIAL forking, in cases where you need to send updated Offers on early dia= logs, and therefore cannot use PRANSWER.

I don't think I agree on that but I really want to spend my time on ma= king sure we get the setLocal / setRemote text working for the simple case = before we sort all this out.

This is how I understand it would work when discussing with Vijaya .

Now, if you don't agree, please then explain how you would implement t= he forking case I provided :)

Regards,

Christer



-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
L=E4hetetty: 18. lokakuuta 2013 22:12
Vastaanottaja: Christer Holmberg
Kopio: Suhas Nandakumar; rtcweb@ietf.org
Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections=
On Oct 17, 2013, at 10:59 PM, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:
And, I'm not asking for a solution at this point, simply that we ident= ify it as an issue that needs to be solved :)
So I sort of disagree on two points here.
I disagree that it needs to be solved - I'm not against solving it if = anyone has an easy way but every time we talk about this the conclusions co= mes up people don't want to bother to fully solve the parallel forking prob= lem in the first version of the webrtc. Speaking purely for myself, SIP parallel forking has not turned ou= t to be extremely useful and has turned out to seriously complicate the use= and extensions to the protocol - basically the HERFP problem - so I don't = really care if webrtc takes on that problem or not.
Second, I suspect that Invite with replaces actually does solve this. =
I certainly don't mind marking it as an issue but it's not clear to me= that the WG thinks it is an issue that needs to be solved or that it an is= sue that is not solved. I've sort of been waiting to see the other "ea= sy" stuff in JSEP / Bundle / Unified plan get sorted out and then figured we could go back and see what was pos= sible or not with parallel forking in SIP.

_______________________________________________
rtcweb mailing list

--_000_7594FB04B1934943A5C02806D1A2204B1C4E6402ESESSMB209erics_-- From internet-drafts@ietf.org Mon Oct 21 16:36:12 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7C111E82CC; Mon, 21 Oct 2013 16:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ-JHQkKNls2; Mon, 21 Oct 2013 16:36:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B567511E82CD; Mon, 21 Oct 2013 16:36:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021233607.32561.21294.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 16:36:07 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 List-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, 21 Oct 2013 23:36:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Javascript Session Establishment Protocol Author(s) : Justin Uberti Cullen Jennings Filename : draft-ietf-rtcweb-jsep-05.txt Pages : 48 Date : 2013-10-21 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-jsep-05 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 martin.thomson@gmail.com Mon Oct 21 16:41:15 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE0E11E82C9 for ; Mon, 21 Oct 2013 16:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7SJctSDomAj for ; Mon, 21 Oct 2013 16:41:14 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE9611E8834 for ; Mon, 21 Oct 2013 16:40:32 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so5267435wgh.1 for ; Mon, 21 Oct 2013 16:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hg6M8E8dFerSuoqRNeSN9KO12qhGc3zuU3klRA83GJw=; b=SBvv/iGA9K4qWq61REpdCjr9tD2PS+y5syqve+c29X+VhnHHylGTQve51cM7toQ23D 2hjt0gdsZXIVF1saTuRFTGkwKbbcCYiJSfPu7ntwG+HUXiGe8GQwDb8Z3mqCMolQDj8f KeYbibwLctnUGy+5bsFN7zB0nsztfgaIZK1fOgzDiAgcMI6CDU7DuoA6LXSw13FqXrUi Y1osE0OttT5WT3J5Z4Y+aHjUfKav6vJ+MJa4hAAxNedVKpCKsbzue9j4LaohsveNzNJP lUhRRr/Q/kb4duASFWaunrO6RTDkhlElFUDXr2wKPDwOyk9XmiYBG4tOmupSc6OMt40m b1zg== MIME-Version: 1.0 X-Received: by 10.180.86.230 with SMTP id s6mr11924120wiz.64.1382398831778; Mon, 21 Oct 2013 16:40:31 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Mon, 21 Oct 2013 16:40:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 16:40:31 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:41:15 -0000 On 18 October 2013 12:34, Cullen Jennings (fluffy) wrote: >> >> I have a few hours, maybe I can write down an update to 4572 that fixes this. > > that would be excellent if you could do that Done. http://tools.ietf.org/html/draft-thomson-mmusic-fingerprint-00 I wasn't able to pass this under any noses before pushing the button, so this is probably way off base or duplicative of Justin's promised efforts. We can discuss in MMUSIC. From juberti@google.com Mon Oct 21 16:57:52 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848E911E82C5 for ; Mon, 21 Oct 2013 16:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zThglP3-ZPpZ for ; Mon, 21 Oct 2013 16:57:50 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2A26821F9EAF for ; Mon, 21 Oct 2013 16:57:44 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id g10so2219767vbg.16 for ; Mon, 21 Oct 2013 16:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yPNiY4QQ/42EBNuw7ntZViQM7foelHOpkNVPvVUmuvs=; b=SRD2o5WXjk+/QZ+pDzC5EIyYjKnImNC7nkuLc7OPjn5sn44mnrFHgZV4Z9Jg28XwLR 1KY7NzXoqG1cqabEgnbyUVGZCVrbHYlfx/VR6N3xlDLUwjjVex+LO00yF+uFr2ygCUfO lTG+qBhK9ndUSzszKLXV6FZxs8PcJT9tS8TDHDRSNKpE2mLdl1AAJiteue2v9IK1bueC WpkxVQ1B7l7AcU8cY9GEYHoYgFX1qC03iufJQXROphCl9s5SeSRdvuZIznbM+r5sV/5K Y9xKx5Dv5uUZpv4zS36jkrIbIHF3EOLc9jMmcjMXAtBcNYGkPR1eG6skPHvL3Ch5yYLA QbXA== 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=yPNiY4QQ/42EBNuw7ntZViQM7foelHOpkNVPvVUmuvs=; b=Bs916cqVr+alHjydFeQQUFPPuavYcWpkpweDOaeGc1oaOtmbKJnV0hnX07LfmVNzQu FrBEshBXuI8/ATE/JcZe5Y2BtqgdgPnc3hWnK7V9OxOLzOqC8QfiUKd284EGsiko6Uhw Xw4aI67ZRMNc/v/utRbjqLei7b4YhbIxvL/Bw9ZJOvvPCURr4DaYVKZDbBWnc1WMYJtD HOCWwfWS3X0d69k5QiiXhmNSE0XP9UjIE4rWAwcP6BElRdtRE2rARy62yUlZP8DfSDOd InVbDPCY1i6DIpynmqAb5jtyAfhGNazFQGWmwQmfJCNcHH3UM5888dtf74ipeWq+ueWQ xKTQ== X-Gm-Message-State: ALoCoQmkmLCL2Lu9tfYM9rOEhNw3ORMzoVAXgibbjbysW1iLIXSz84e2/QxJBUVXq5XgslO1sC6vJXhdF4Yfv8vqCk1xRbULTdE1OHTD9DtYvEwh13dhTo/sh8niaWIJhigN18xONfEpyVVAWe8+xzrKmm6pf2CQaZQq6zXxVcR0R3odNLQ8cFNgdyzwrgo+AgsrCwNvtKzJ X-Received: by 10.52.170.111 with SMTP id al15mr45827vdc.43.1382399861569; Mon, 21 Oct 2013 16:57:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Mon, 21 Oct 2013 16:57:21 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Mon, 21 Oct 2013 16:57:21 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b86f11eafd71a04e9490cc3 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:57:52 -0000 --047d7b86f11eafd71a04e9490cc3 Content-Type: text/plain; charset=UTF-8 Lacking anything else to point at, I changed the text in jsep-05 to just reiterate the policy from 4572. However, it does raise the larger question of what digest (and perhaps key length) should be used when generating certificates in WebRTC, and where that should be specified. On Mon, Oct 21, 2013 at 4:40 PM, Martin Thomson wrote: > On 18 October 2013 12:34, Cullen Jennings (fluffy) > wrote: > >> > >> I have a few hours, maybe I can write down an update to 4572 that fixes > this. > > > > that would be excellent if you could do that > > Done. > > http://tools.ietf.org/html/draft-thomson-mmusic-fingerprint-00 > > I wasn't able to pass this under any noses before pushing the button, > so this is probably way off base or duplicative of Justin's promised > efforts. We can discuss in MMUSIC. > --047d7b86f11eafd71a04e9490cc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lacking anything else to point at, I changed the text in j= sep-05 to just reiterate the policy from 4572.

However, = it does raise the larger question of what digest (and perhaps key length) s= hould be used when generating certificates in WebRTC, and where that should= be specified.


On Mon,= Oct 21, 2013 at 4:40 PM, Martin Thomson <martin.thomson@gmail.com<= /a>> wrote:
On 18 October 2013 12:34, = Cullen Jennings (fluffy) <fluffy@cis= co.com> wrote:
>>
>> I have a few hours, maybe I can write down an update to 4572 that = fixes this.
>
> that would be excellent if you could do that

Done.

http://tools.ietf.org/html/draft-thomson-mmusic-fingerpri= nt-00

I wasn't able to pass this under any noses before pushing the button, so this is probably way off base or duplicative of Justin's promised efforts. =C2=A0We can discuss in MMUSIC.

--047d7b86f11eafd71a04e9490cc3-- From martin.thomson@gmail.com Mon Oct 21 20:01:41 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817FE11E8102 for ; Mon, 21 Oct 2013 20:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LTC2Kg1GRWB for ; Mon, 21 Oct 2013 20:01:41 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B659F11E8104 for ; Mon, 21 Oct 2013 20:01:37 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q59so7325853wes.37 for ; Mon, 21 Oct 2013 20:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ylMC43/KfrKvg4jM0fZUileHdb4Xj/+fVEZ2FC5XLbM=; b=nnLxhcnCZOW8MEDxn9IABjWznW+9UwDEu924vFxqIAmCtINMgAO/W1nUtKV0NYnTO2 dyM9965qQLOxZaLihfB++fIAXvBMBFM3fw6suxis0F5+thnU74cZCpV1F0M/Di6XB0pQ PkhO03CZ+5k3BIhZE2S1oOOrSdgvz0fxPpc2tXRt/n3Og/nk/dPu81asnAvtm6VcMIvR hcWKdlAt8i+Rqnss7g18UYEFCuxOt0vOPdLST2VjEUx+7o2D5BOyxEjE7PVEfrN2wy/a cfGp5K2mabMQ0vTKl+nky7z3/hNajVxWEAsZwwu8uyzXEzCKXtTGvT8h2D1gLrC9FlmR po0A== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr12527646wij.30.1382410888417; Mon, 21 Oct 2013 20:01:28 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Mon, 21 Oct 2013 20:01:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 20:01:28 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 03:01:41 -0000 On 21 October 2013 16:57, Justin Uberti wrote: > Lacking anything else to point at, I changed the text in jsep-05 to just > reiterate the policy from 4572. Probably sensible, even if 4572 falls short. > However, it does raise the larger question of what digest (and perhaps key > length) should be used when generating certificates in WebRTC, and where > that should be specified. The main factors that affect WebRTC are the size of the RSA modulus (if we're still doing that) and the digest function used for identity validation. The first is largely a unilateral decision, once we sort out whether we want RSA or RSA + DH or one of the EC options. Currently, there is no way to get hash agility with the mechanism defined in security-arch, a problem I think we should discuss. --Martin From juberti@google.com Mon Oct 21 22:14:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0108B11E833C for ; Mon, 21 Oct 2013 22:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhAa4OTZ+kY0 for ; Mon, 21 Oct 2013 22:14:24 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7F34F11E8127 for ; Mon, 21 Oct 2013 22:14:24 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so5039781veb.27 for ; Mon, 21 Oct 2013 22:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=bFV3vDRlalFz3+DkciIRQ6BTlDHaI/NL2bj7PYwB09w=; b=oxDXpYoCfDIhMIba/Co/XsXO8ckgCo9bzIM19yb8DwcRmE+zFQFqzhOID1BLeZNh1+ gtYSpAVu2Sp3Rw0rKVG53lm2jYbUxjibbCJMWjTYCI49aFmkpneGUCCzvAJ62Va43RT2 Ea7/ZfGme8CkApsH0oRcBFQLCtHujJnQaDP1Md7JcSyH+8GCkhmas9UB/AQv2WpBcEVJ Op+mFqZikSa6xetBTFt+PbQ+rCPCQajtPwcf8LxhYJFrUUSzgrv7JbRjZUbIMkdfWnPX Bx4pmslsEkCLEpHhkycErt14q7cbbNfsQNHvK40Fb3VhD4wu45pxG5HmNX7VAYhdT6Hh f08A== 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=bFV3vDRlalFz3+DkciIRQ6BTlDHaI/NL2bj7PYwB09w=; b=F4EdHHvIcjW3QEi94LurmRwoqZ/8qn22f3bRGCJzJMgtIU3UxpWs9gX6o5FyRlatxP eScC9o/ALBd9ZAvkwrRK7jxZTgcqYiQ2sTQdh1oN6oR8EAfZ2/xYfeapOmboE8lRSsso nztLtbl+/NpoJaU9Ckfkh9kql5U/eNo83LDT1SkLxarK5fK6GU4NuRKWfHnFYQpGioB2 5HsPBao2b3/jUI6hfYMIQO7bj2rL9WPJLH+t7E25DUrD6rXPfgEDamV7wWfhKe3/ArJZ qHGdg5mcU8WIzs4vmX3n8ChnZYlFzHfPoG1WGCPvh4QJKceDPOQim3+ajOBpYZ+CGdC9 v1cw== X-Gm-Message-State: ALoCoQnWgV5bFMGBXWpZGzd+tnjNuUHCYBSrpcd8jCFkn7g9cPpCgBgKt+cS4T65VCCl4qzHsauWDjka+rY2taYQWkbqcPVAJvSK6N/nhc9J2rc1MoK1l+mkexM1VzXQAEEGReIsY+gHcqSDfJXwZ+ALZhN50iD9t5cuch554HAxtXB3EWHNsAlEaO/6cuTo/8twBqO7Uh54 X-Received: by 10.220.58.1 with SMTP id e1mr13862019vch.0.1382418863708; Mon, 21 Oct 2013 22:14:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Mon, 21 Oct 2013 22:14:03 -0700 (PDT) From: Justin Uberti Date: Mon, 21 Oct 2013 22:14:03 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2c7da4d73ef04e94d79eb Subject: [rtcweb] Definition of "webrtc-datachannel" protocol? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 05:14:25 -0000 --001a11c2c7da4d73ef04e94d79eb Content-Type: text/plain; charset=UTF-8 Maybe I just missed this, but which draft defines the "webrtc-datachannel" string that is placed into the a=sctpmap line? http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 refers to it, but I can't find where it's actually defined/registered. --001a11c2c7da4d73ef04e94d79eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe I just missed this, but which draft defines the &quo= t;webrtc-datachannel" string that is placed into the a=3Dsctpmap line?=

http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 = refers to it, but I can't find where it's actually defined/register= ed.
--001a11c2c7da4d73ef04e94d79eb-- From Michael.Tuexen@lurchi.franken.de Tue Oct 22 00:35:31 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597BB11E82E9 for ; Tue, 22 Oct 2013 00:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGObxYns3uVM for ; Tue, 22 Oct 2013 00:35:27 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id E8C8811E8355 for ; Tue, 22 Oct 2013 00:35:23 -0700 (PDT) Received: from [192.168.1.200] (p508F12E5.dip0.t-ipconnect.de [80.143.18.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C37A81C0C0693; Tue, 22 Oct 2013 09:35:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Tue, 22 Oct 2013 09:35:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1639895C-DE36-4F2E-8247-3B8A74D2DDE8@lurchi.franken.de> References: To: Justin Uberti X-Mailer: Apple Mail (2.1510) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Definition of "webrtc-datachannel" protocol? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 07:35:31 -0000 On Oct 22, 2013, at 7:14 AM, Justin Uberti wrote: > Maybe I just missed this, but which draft defines the = "webrtc-datachannel" string that is placed into the a=3Dsctpmap line? >=20 > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 refers to it, = but I can't find where it's actually defined/registered. Should it be defined in draft-ietf-mmusic-sctp-sdp-05, since it is used = in SDP? Best regards Michael > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Oct 22 02:49:46 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78C811E82F0 for ; Tue, 22 Oct 2013 02:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5-dmshV+VqZ for ; Tue, 22 Oct 2013 02:49:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F242A21F9DDE for ; Tue, 22 Oct 2013 02:49:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5508D39E12D for ; Tue, 22 Oct 2013 11:49:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9qLAfprMInN for ; Tue, 22 Oct 2013 11:49:40 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 57A7139E062 for ; Tue, 22 Oct 2013 11:49:40 +0200 (CEST) Message-ID: <52664A39.5040105@alvestrand.no> Date: Tue, 22 Oct 2013 11:49:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.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 Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 09:49:46 -0000 On 10/14/2013 11:12 PM, Bo Burman wrote: > Hi all, > > We would like to counter Google's suggestion that our test has only "demonstrated that it is possible to reduce VP8's performance" (updated draft on VP8 http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/). > > In fact, what we did in our test was mostly undoing some very peculiar x264 settings made by Google in their test from April 3. By instead using the x264 settings Google themselves proposed in their earlier test (from March 12), and removing threading, the difference went down from 41% to 16%. (This is without touching the VP8 parameters.) > > The last change we made was to remove the rate control from the comparison, something that is standard practice in the world of video standardization. This involved changing both the x264 and VP8 parameters. After that, the difference went down to -1%. > > In summary, the following steps were taken in our comparison: > > 1) Downloading the latest software: 41% became 36% > 2) Removing threading: 26% > 3) Removing bit padding: 18% > 4) Removing other differences between Google's March 12 and April 3rd tests: 16% > 5) Removing rate controller: -1% > > Just a quick update on this - I did not manage to get a new draft ready before the deadline, so I'll have to resort to sending email: I applied steps 1), 2) and 3) to the repository mentioned in the draft. The numbers I got were different, but significant. Below are the VP8-to-x264 differences I encountered each step of the way. - Master branch before October 15: Difference 71.52% - Updating x264 from 198a7ea (aug 16 2012) to c832fe (March 1 2013): Difference 71.44% (I could not go beyond this because yasm 1.2 was required for newer versions). - Adding the --thread 1 parameter: Difference 26.11% - Removing the --nai-hrd=cbr parameter that was suggested by x264 people: Difference 13.87% - Removing vbv-maxrate and vbv-init 0.8: Difference 12.74% I did not shorten the clips to 10 seconds, nor did I try to control rate by constant cq instead of a rate controller; if Bo's numbers are right, this shouldn't matter. I did try removing "vbv-bufsize ${rate}", since this was the remaining difference I could find for Bo's point 4 "other differences", but that was actually harmful (difference increased to 19.05%), so I put it back. I checked this in to the repository - the commit is here: http://git.chromium.org/gitweb/?p=webm/vpx_codec_comparison.git;a=commitdiff;h=ada7d7937a54e47fc18e2e0a1287aea29dc5d1c5 This number does not fit the impression the video codec team has from other tests - they think VP8 can do a lot more than 13% better than baseline - but at the draft deadline, we had not found the set of VP8 parameters that showed this for this particular clip set. Commentary: I'm surprised at x264's choice of default value for the --thread parameter. Accepting a 26% bitrate hit seems like a large price to pay for going faster by default. Is there a bug here? From harald@alvestrand.no Tue Oct 22 03:25:08 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A945311E8117 for ; Tue, 22 Oct 2013 03:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9-kRFIFfcga for ; Tue, 22 Oct 2013 03:25:07 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A48D311E834D for ; Tue, 22 Oct 2013 03:25:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B412F39E12D for ; Tue, 22 Oct 2013 12:24:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUZPNF93nQ7Z for ; Tue, 22 Oct 2013 12:24:53 +0200 (CEST) Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 716B639E062 for ; Tue, 22 Oct 2013 12:24:53 +0200 (CEST) Message-ID: <52665274.9080705@alvestrand.no> Date: Tue, 22 Oct 2013 12:24:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/mixed; boundary="------------050909070407080102030004" Subject: [rtcweb] VP8 vs H.264 - subjective evaluation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 10:25:08 -0000 This is a multi-part message in MIME format. --------------050909070407080102030004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In my VP8 advocate draft, I referred to a subjective evaluation test (test with actual human viewers) done between VP8 and H.264 Baseline by a neutral (non-Google) laboratory. The attached presentation is the writeup of the results of that test. -- Surveillance is pervasive. Go Dark. --------------050909070407080102030004 Content-Type: content/unknown; name="VP8 vs AVC Baselinev2.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VP8 vs AVC Baselinev2.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv TGFuZyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDU0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0 cnVlPj4+Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDE3L0tpZHNb IDMgMCBSIDggMCBSIDIxIDAgUiAyMyAwIFIgMjUgMCBSIDI3IDAgUiAyOSAwIFIgMzMgMCBS IDM1IDAgUiAzNyAwIFIgMzkgMCBSIDQxIDAgUiA0MyAwIFIgNDUgMCBSIDQ3IDAgUiA0OSAw IFIgNTEgMCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIg MCBSL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L0dTNSA1IDAgUj4+L0ZvbnQ8PC9GMSA2IDAg Uj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJv eFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMD4+DQpl bmRvYmoNCjQgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzkyPj4NCnN0 cmVhbQ0KeJx1kltLw0AQhd8D+Q/zuCu4nZ29BqRg4wUFoWrQh+pDW1OptI020d/vJtrSRPOS C5wz35zhwGAMJyeDm/TqDHA4hNFZCh9xhIACESUROnCEYDTCNo+jxyPYxNHg8t7AaxlHEl73 YkQrUbfUi6M4uo0jOL9JAQ5I8pc0ysKsCwkqEYnXkC3qiWEcSEiMIEWgtBc+gWxdYxrWZRxN 2AWXhhXb9XQF95+zt3zOj4lVyy8uieWQ8SS8Si4Vq+COSx9+PldVCcUC+DNk13F0HsiHdNuC exS+hiPu4HVEIgfZfMIexp0hO5skLaT5Y0PV2HyXvbcZJbRq2xrHnCesWL9P63DbOk3+AhV3 rIBTrjV74J6lkBb8WLFNWUevtpyQTZebIOwJ2jkzSSuUBjIkvG3YEzaalvlqyTXb5BCeT6xn b+WoPlzL+8hVuPasWa3HphMpbMf2xHvEBpVwvi0+jPanWtSplqRWXutQ2DAPRUL+p1bCKNdU q/lo6iV7trHOipb5n2W+AZ6Erk0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9U eXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvY2EgMT4+DQplbmRvYmoNCjYgMCBvYmoNCjw8L1R5 cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZvbnQvQUJDREVFK0NhbGli cmkvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDcgMCBSL0ZpcnN0 Q2hhciAzMi9MYXN0Q2hhciAxMjEvV2lkdGhzIDc5NyAwIFI+Pg0KZW5kb2JqDQo3IDAgb2Jq DQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpL0ZsYWdz IDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1 MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1 MC9TdGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDc5 NSAwIFI+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jl c291cmNlczw8L0ZvbnQ8PC9GMSA2IDAgUi9GMiAxMSAwIFIvRjMgMTYgMCBSPj4vRXh0R1N0 YXRlPDwvR1MxMCAxMCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0lt YWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgOSAwIFIvR3JvdXA8 PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1 Y3RQYXJlbnRzIDE+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDEwOTE+Pg0Kc3RyZWFtDQp4nJ1XSW/iSBS+I/Ef3rHcUiq1umwpshTIoowUKTMT ZQ7RHBwwjUdg09h01P++3ysDsSEmmRyAWt761duA8we4uDi/H99dgUgSGF2N4cdwIEBwIYRU SjhwSoA1AtbZcPDPNyiGAwnf9zRChFKYDtHs23Dw53AA1/djgJYCuVUwehwOzm8kGMNFaOBx RhJRHEhQJuKhAmMjbmN4XJIa1HV++7fERUXb2+Hgmd0VQcTqdSAdK6fBmWKbSZ2XRfAvPP4x HFyjAlKyk2qc5DpqS31m0KI9slR1LFWgRcdKoznaKBV3USPtQojIJV3l5OEBnxNcKdPhZH8F 0rKs2iwCw+oK8HuGbkWsXEJwplkKs0ApVq6X6QJ+5tMs0KyEiq42L/9l6DUe/EQwMuhxfqtU R5rHO6VpVWVVtSQpWRFIyWoILKtplVWB1M0+RUMUCTZshUuDd0SttoRT1Mz7EDeOY+h0lJ5E XB8hzoUyx6hrFBzbj1A/4t2B0OJmj3MCE2ryl7xG/OGVNmkFE0S0LKYbdH2y89YwyPGrIDzu CZuQTeZ9qBsX0Ru3FFK6SHr2yTNTQuo+TmtCbg84PROatUrXNakvZ4fc/dGmZczlzucUQ4ce cDP9BWm+9G8IaRA3D75qIo8iKqebvPjug/D+4ZowuCWa17yew7Js4uGDmFOx4HqnGkPXNZGT 5gsUXkH6Um5qmFNE4+cVnkjXQ49IrRx3ri2SANUemajPDm1i7myXyXNM0JZyuaJXpJAH1F/T EXl494Srce/rRFyFXc/6ksBayyPVpT2ZBOaTSaCs4Vp/NQna3F9Jghc8/kVR+JTXVIA9cOu8 7E2FOOa6q3WUNqW7mOQFCsp7OEOpeRh1WY8DX/cEvlKW2z1K2l0LYYwQ1mFjGydSIHLKCW1H SSgvhIypl+nE0vIykXQkr+k4kdqf0TWeIbe9FFJgDtsrIaMxir5BMTYxFw2JUMmZ2kskkkSa rbholJC0kaWtX5ICeaBUXtJVI+wmcXg6dn77vgeRt/zDghAKyY3q4HI6Hu0n2qCM4hbK/6cN tjjfUvmpL/8RVe56mHrzXyrDXZfHM2wL3aostu2vaprtosIoxmli7dPhB2bGhtKj8jT7pofZ gjTzlEYQoNo59z2y2z5PFkYZCu52T5AXE2r+GyyQmF2XgZHMVyAqSr5OFY3+daAE1s6CyKZ0 +ZJW2cKX6QzLFkfLLeUz2dI4sJ8qcIaQmKPvN42+OiG15LtpqZ7nfjZpNaBDr03TQ15pFvHN MaNtUdawejOIbC8IsrdyUiMVoh42XUaz275yGuIUJ7pmnYze8BPRG1seo8wvRG+bE1FHeFY7 H99mpJRaHs6lgL+HzRW7jodQHz1We/6r517GB/EUOi73xrTjsA9LqTSPwi7fSTDdwewuVbe0 oCFUqQWPVTPvCUw55/8n+IWf2lXvy4a8w/yOMb8B142ztQ0KZW5kc3RyZWFtDQplbmRvYmoN CjEwIDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvQ0EgMT4+DQplbmRvYmoN CjExIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BcmlhbC9F bmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyAxMiAwIFIvVG9Vbmljb2RlIDc5 OCAwIFI+Pg0KZW5kb2JqDQoxMiAwIG9iag0KWyAxMyAwIFJdIA0KZW5kb2JqDQoxMyAwIG9i ag0KPDwvQmFzZUZvbnQvQXJpYWwvU3VidHlwZS9DSURGb250VHlwZTIvVHlwZS9Gb250L0NJ RFRvR0lETWFwL0lkZW50aXR5L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAxNCAwIFIvRm9udERl c2NyaXB0b3IgMTUgMCBSL1cgODAwIDAgUj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9PcmRl cmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4NCmVuZG9i ag0KMTUgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQXJpYWwvRmxh Z3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMC9DYXBIZWlnaHQg NzI4L0F2Z1dpZHRoIDQ0MS9NYXhXaWR0aCAyNjY1L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQg MjUwL0xlYWRpbmcgMzMvU3RlbVYgNDQvRm9udEJCb3hbIC02NjUgLTIxMCAyMDAwIDcyOF0g L0ZvbnRGaWxlMiA3OTkgMCBSPj4NCmVuZG9iag0KMTYgMCBvYmoNCjw8L1R5cGUvRm9udC9T dWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL0VuY29kaW5nL0lkZW50aXR5 LUgvRGVzY2VuZGFudEZvbnRzIDE3IDAgUi9Ub1VuaWNvZGUgNzk0IDAgUj4+DQplbmRvYmoN CjE3IDAgb2JqDQpbIDE4IDAgUl0gDQplbmRvYmoNCjE4IDAgb2JqDQo8PC9CYXNlRm9udC9B QkNERUUrQ2FsaWJyaS9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURN YXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDE5IDAgUi9Gb250RGVzY3JpcHRv ciAyMCAwIFIvVyA3OTYgMCBSPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8L09yZGVyaW5nKElk ZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQoyMCAw IG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ2FsaWJyaS9G bGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUwL0NhcEhlaWdo dCA3NTAvQXZnV2lkdGggNTIxL01heFdpZHRoIDE3NDMvRm9udFdlaWdodCA0MDAvWEhlaWdo dCAyNTAvU3RlbVYgNTIvRm9udEJCb3hbIC01MDMgLTI1MCAxMjQwIDc1MF0gL0ZvbnRGaWxl MiA3OTUgMCBSPj4NCmVuZG9iag0KMjEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAw IFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDYgMCBSL0YyIDExIDAgUi9GMyAxNiAwIFI+Pi9F eHRHU3RhdGU8PC9HUzEwIDEwIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn ZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAyMiAwIFIv R3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv Uy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5kb2JqDQoyMiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAxMjM2Pj4NCnN0cmVhbQ0KeJydV1tv4joQfkfiP/jRWR1c3+2sqkgU 2p5dqVJXB7UP2/OQtqEgUegS2u7++52xoUoCobQPBBx7Lt98M8OYHF2S4+Oji8G3IeFZRk6G A/Kr2+GEM865kJI74iQnRnOyLLqd6y9k3u0I8vB2hnMruK4dGn/pdn50O+T0YkBIxYBYGzgZ dTtHZ4JozbjVZDRGjaCOCCKNZ45oeJqUjB7RCpg6Ov9PwI8Sl+fdzk86SnxKizJJ6YoMi8TQ VSIEzaezMvmfjL53O6dgAs1s9GormJZVxT8pqZzd8lXWfJVEupqfWjFJVMpZqqO2Y869y+rG EWNDznEmpa5J0tGkWCbC0IIknr7CB5cWl5pqfNzN8rIsSpI4Op2TRNHVpCCAWGIIBCz/wa3J AnaCOMTjJaghGJV+oi29ggMDkuzyj3Gpd/poNUs3sbpLBKeLeTS3TKSDYM+Le4Kvb/OymMEK FpqW+IATAuznjyW6/wo0ISSHkAxomf0heSI5OAkQgLT8dgY7lo4TKehiudvNnS6qlEGCRhdX k2g1xG0xTnqK4q/VZFEWtShCTG7gNUSrwJ2UblChh+jzK6J6I8HTBwQwhxfS0hzWIdkQfNNP 1eanUEyYTaII6TMp4NsNufADqCDFudacGwclN8iEgWSSjitzklkF51KsMpX1NL4/AzmbeXzd zwSqEadBDb5WYZmZsBuEBAo5xYUZZj2J2/0oAcaDYSGjI/jeDFELfEeDKGp15t3aiIDTph+P oIg9i98G3XZBPYqBb0Erl/GIPct6KmxF6LwG/eCakd4xqdZkXwIZki6eFklP0jKfleQWEugP eSweb4uQByUyt0mD3U1BGcmcqSs+iyw/zycgKzWmQUtHcYqlDeE2Q9qlLPUNQ/+e3ySsRcBo wYRvV77VrtQB7Uoazbz6TLuqSkK7mpbkKVZLWcyxVlbYvkJlTBfQoKCqYR9r+WV6jxVnaCym 8nm2KrHi1pX+tS1eXoZ4Vc3uha+b8BsdLY0wpGEyfQvAidgVgLqk4II5X5Okg1kesi5kWB/R 3VCRSmgx/Lfg8OXxcZN8jbkHvUJi0y6LX88FCs7vCtwp28jXKsCu2dyL3hyEXqSW6U+hr0rW 0Z9E9F4h+t86AN/ZFhv/8jZlXjQ8Uk6/75H0oinZWnWhehpnr68wO8/7VXb0x9gBdcK3e7DF jj2MHeuY/Rw7Fck6OwP827uhWlhkR+oPsGNcw6OD2WlI7mHHsrRx9hqbyQ/wfIsl+0GWjABP dLsnWyy5LZa256I1U8ozb99jakt6w1ZFmvZnM5x7HnMcZOPQMc1n2CBfwzwbRr6nMBwuHoC8 JQ5XRVlOX8KPNvDKeZaKuqm94P1hKSpg4H8X+E7QFckI2mxTiWOXDGMXPMlTvsTNFcZnMSYw 8cZMgClxulwPmiJuf7vC9YAMUCCP2sc4X8IoebmJGo4KOkwKbVGzeDewdV/3Ri094D8XmFD+ U1eEqiS9uvSkmMch/B7n+s2EjzDLaZiC5pg3cK1gNg6wMXuey+K+tZVBocNYWrO0F7HgB0DW Bv67PwW5Klm9tny/IElPU2HjbQKGdcD2HNpBKzaZptj8ayr3Y2veToWs+WjBSQuTAERY+ng1 ZUa5cBMOP8LFVLUll7OsJrzDm78t6EErDQplbmRzdHJlYW0NCmVuZG9iag0KMjMgMCBvYmoN Cjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDYgMCBS L0YyIDExIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTAgMTAgMCBSPj4vUHJvY1NldFsvUERGL1Rl eHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0Nv bnRlbnRzIDI0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2 aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMz4+DQplbmRvYmoNCjI0IDAgb2JqDQo8 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDcwMz4+DQpzdHJlYW0NCnicnVXbTttAEH23 5H+Yx10kNrvrXV8khFQSilIJqW1c9YH0wcQOWPKF+gLi75ndYBSHJKW8ecczc86cPWPD5Duc nU2up/MZ8PNzuJhN4a/rcOCMcy6k5AEEkoNWHJrMdX6fQOU6Au7ecjj3BVejpPWJ6/xwHbi8 ngJsAYhXgIvYdSZfBSjFuK8gXpuO2A4EiChkkQKlQ6YjiEsDg1iTq4XAh9Ycr1znhsQ0jEjW 0oh0cJ1RTbr7Oq3pqUeK+u6Z/oH4m+tcIo7BGpprKRBwu/kNga3cd4TliLAETzI+5qs8huGQ My/cNDzjPAzOx/hm1velAWdSqlExmdZV2q86KjTJUqCnIenbnCpS3eFBkwTwFTdzCw8Hf2io 8EmNMUnqFcXHAtKsMQWPNi+FNfXIJqsEup+Vv5+WEizSr7S6+wz7wDz+dUBZ4WsmdopOD+UG ikXhOPcnzBBgMV/gmD5Zklnd3xY4RmbHXnR5ia/7osdQi6GAzMsHjCR5U5qsyvrgwHz7x+Me 0wP6wmiXFNmSwkb6V31LM7UxFkNMSeL7DFqMrGhgsqFvDXYKT4ietLAedOa7THawpRHrTVoD VYNxruDskGRKY+W48KhxvY8ZV4qIcf1J424XW20ejUi5WcYnVChDOSJzW2jE4SzNhWJw1Zip s6wyJsf3ayoVqRvTwSO50bhPCqtJsurzDs/P/9BU4Bb5A5mkMruj7EXVBfZFSreF3aO0ykz7 1twoAn+Bjf52hSwk8liDxBQFj3n2ZNdomCQYD3KckJJMDoT6FgfNKzsR7tIGdHDZkuCns0RD tbAhrhEbFUEkG13SQ7bwBX7P5BjqqC3Ux2wR+bjM6pO22C7+P1t0DZUCdxpdcWhixX2zASOM oxPrnV+OkCPOPpL2Q5CcRXLzDeZMe4H9vdkH+7NRh/QPfDYq3kPmBYyJllQNCmVuZHN0cmVh bQ0KZW5kb2JqDQoyNSAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJj ZXM8PC9Gb250PDwvRjEgNiAwIFIvRjIgMTEgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMCAxMCAw IFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFC b3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMjYgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0Pj4N CmVuZG9iag0KMjYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTEyPj4N CnN0cmVhbQ0KeJyVV01v2zgQvRvwf5gj2QPNb0ppkEOTbrELFOgiBvaQ9qDYdKzd2Mpacor8 +w6l1BFtU3YuiSLNmxnOe49kYPINLi8nX6//vAF+dQWfbq7h//GIA2eccyEld+AkB6M5bPx4 9M8HWI9HAh52MZxbwXUUtPgwHv09HsHnr9cAvQLitcCn6Xg0+UOA1oxbDdNFyIjpQIB0ijnQ JmMmh+kqVMFSky+3Ah/q8OeX8eiOTGmWE1/TnDRwO6MZKR49/QHTv8ajz5g8FPidUWvLdD/j HYFe6EGTMmpSguJRg1oxfJdlzGVdtkvOM3cV1w6L28M5zqTUfWQYn4Lp7I7kkOg9l0xke6AW 0VBHqhRKSM1MFjVJslSsylkWL4hcQF2tPMypJv5hQ6UkxbzAgk1ZraGkhtSpypo7pkycrfZ+ jZmSECeYEjHkO2mWHuotVeT+Xz9rgFrykwpBioPK3aQZl/rotE3OcvOataj/o4oTH9YFDUqn Cnm3tccy0Cy7hXn8+Ix6eu3ZknLRffZUKPICxYYKSTxg8Lpquh434ZOHagPFAlFN6NRvjqx5 QBZKMLFrFFpFd5Wo4GSxfQzZSvyxrp9wICVWRS6qRWgMMLhcFQ/IkP9OWWrOWTBbXGjQB+oM H8jc7LK9zwd9ZFIbzrJc78XWMySl6maT1KGwnGnbB76ZzSVBmWRaxqAWUaznKYxUGKyOF7JJ kHGM50cKXUwDm5rU253sS1yjwhevGlv6CZWC1F3c8tAP+2O2NhgydmLn7gNrp5SjLM7FxakG laMPlHPgz049+EGpU+pJebuPJngGuFYVakgVxjBr+8BAlgjbDg7fJGHOMadj2GldtMFRjzoV qw0zLo69gJuwEwWKREtR1u2++A4VMXsMH4vN40ug87msy3t8SJ6AluO643EPE2jOsL7I9Rnk HSOujwzEnWHnjrge8M1l6gRtEehM2qIO5TBtUWygLXCm+idm2MgNerdcrfw8nDLtl/aQCNv6 ywkLC4t1fhfwOK3nco5bAloZMzQf08u3eHeI0YOk2zNdK2TOTm75KdP2wO/y7Buub1lxivse 6lzqew3yE8z3Qi9gugykoBnx1zzYs2rP6xp+lvNww+i8GhqYe48ieDrK/YBrOMeLcVetG9xm +7QTUlAESy4t+F9EGQaV4Pau6UJGDVnsyGaYleWyu7FxlJhr/yVoH9obukltRqjLCHykmV/E J5suDQplbmRzdHJlYW0NCmVuZG9iag0KMjcgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg MiAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvR1M1IDUgMCBSL0dTMTAgMTAgMCBSPj4v Rm9udDw8L0YxIDYgMCBSL0YyIDExIDAgUi9GMyAxNiAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29u dGVudHMgMjggMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZp Y2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9iag0KMjggMCBvYmoNCjw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODI1Pj4NCnN0cmVhbQ0KeJydVdtu20YQfReg f5jH3SBez+yFF0AgIMty4KIBXFdoH5I+MPTKEiCTjUjX8d93dim5piM5TgHLIJcz55ydnTkL p1cwmZx+nF2eAxYFnJ3P4Ot4hIAKEUlrTCHVCM4ibP149Oc7qMej0w+/O7htxyOC26dgxITQ DqKX78aj38YjmH+cATxjoh3T2YKxLgisVZhYWCwDIsMBgc4TRRasy5TLYXEXaG4jM2GkRvgw Hn0S15JS4dv7TdfKv2Dxy3g0Z9AAvEey2qhsgPRJwLPY79TpgToNRiscirNG8XKGymQ94AQx S4shf9jY96kpKq3tIFlc1iBPjOhWHraSdNyOtIJ3ZAR0q1KmooOl1EY0m00jnXiAX885JRV3 vqxbuLy6ugJ5mD05TG9J5W5H30pi8u09U1bdPXP2It7D9ZSXoOe4Luub5u4ly1NBXKrQDGGn VeUZrG0DCIv+LMoaLo/pPCwTjXJ7vOVWahLlnQfPaP9IQuG38kSLx2OqtDHKuiEKKYp6jmRk pIwZZrS+krlo6pv2s1RHC0AMnA8TFyvWx6X1YfcPfIi+LyyE/029eYyneBhvVwCdOEX/Cfl6 72suaeVbKEPfcxGsKNeb8kvoFwY+cYL7xIpmC3x2mfiDlc/UMc2We9ANOV4dDPO2wdCUK3Sv DYY5fuQvkhOL5KZINGd/Mfw3R0LNv4u4RslFXDduXpwYjuc9oT1D5Hc34eX+M7lzpBz75zMX n2M6TYuQFZZ1Vmg9QUo5NJv1a/k0sIeQvQBeKgj7d0YpKHzjsP5bQMUie0IpiPpQ47I3uUOi bfCq50V4/Ujs246EUq3y9H961fPk0NTwZd31sxiMKXZ4u7OnLduVDB3fxfHsnQX+bta1zHZ+ Fnr0poG6CaPbQblZ39Y/Z15krHJ2p8dLcuKbpEyUVRem4DFISaIUfmO13WobxsR7qIKosvV7 R2pXjUzEQ/0eVs1DFMwfdsbyUz4V76q9omDjXT/49Q00S/BltYLqnr1qjw7rKKHa+JIDEcXR EU0TZdMh/g8sw2Fftx/3jntxC5Me9iIDJhloVLnubypUzqTxxo8P8f5NjqhJWPkg+YCYfwFB kstaDQplbmRzdHJlYW0NCmVuZG9iag0KMjkgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg MiAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvR1M1IDUgMCBSL0dTMTAgMTAgMCBSPj4v Rm9udDw8L0YxIDYgMCBSL0YyIDExIDAgUi9GNCAzMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29u dGVudHMgMzAgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZp Y2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA2Pj4NCmVuZG9iag0KMzAgMCBvYmoNCjw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjM3Nz4+DQpzdHJlYW0NCnicrVpbj1u3EX4X oP/ARynA0rxfAMOAs06DJjWaWIv0wSmCNLAdt76k3gLtz+8Mh+QZ6pyz0q7WD2tx+A05nG84 Q1IST34QT58+eXn95xdCPXsmvn5xLf693SihpFJKG6OiiEYJ75T48ma7+dtX4tN28+Tbgxfv brcbLd51sFJBKzeg33613fy43YhvXl4LwWbSdaavb2CsP2nhnFTBiZu3OCIMJ7TQSUnvhfNJ +ixuPuI078rMWpWplfh2u3m9u/7w6+3t/sruxHPx805no/6nVVJ7u/t5v/+7uPluu/kGZsGZ 2tDeZukMH/r1TjDszFwzmGuENVKN1jorQQwm20QDPlUqxWfj/LjSuWpU0hg3KO++f//x86fP sJ6VFegUpQtcR1wBB85ZcfPb6x0Mt6JoTJRGD4qqqLz9Yx92t6suM9HLpEcj73SZPWIY1x2W fGadNPGcEd3RiNoMowXwY0jCKJkNWQjxY2OJz/KhREtcWV+IQQ7KJ4zx1RgloxH/LVMYj1PA WP8UG62ijEHkLG0QMBrsB+lSbX/Ytn5tknSsn9qs3wPNA4AEDJECyhmCBBPCaA+2MUQVMATs vsDHqAKGiBbXyRAkmBBWGfxvQlQBQ1gt+STUZv1BycTXWgWAOGw3DYWbBTGjUseA3e4YU5pl ntLbORk4mvo7JwNHrL9zMpLEEJ2TkaQJMXEyksQQnZORJIbonIwkTYiJk5EkhmicDByx/s7J ir8HTipvzd/rrIUoFU0TYL40dVOzdxs9qeLnqSOqqQM+9w5rnIS80Ppqc+qOSZopQGqzdztI Uqy7NqduoNFOFtVm7+bLn7zRuw+1YsFKLBqloQjlujQSuCx1oHWTAOqTqY4obucqXvY2A5DG BOgjIBnGZaFzWTIioGWUbVOWVmr+dQFDiYG9RmAVTIiqMiGmMXBGC0ELYW0gx+cSiE3gTA33 JvA1aCz0gFO5RknM1GYA3zikfs+CzkGtUpiBFHoRmWoCR9Hd27luSxcNOpJrRJylCjgi163d EW2MA1HbaFzjFdw3CIAjXfMJaQfcAgzMu0m7IYjThK1K5AKttdtLS4HTBKpNU/BTd2Z9nEJi rFJYEtQxhc5RLultVRNr12CA0m6AgbQKwrZZoCzWeOsCg2N9mBQ4wLD+4i0VSj6GYk+LaYJk KMf3dt95YABWVaaR8QBXBQyR+tariDTuvWIHglPdfiTQuhaPLkioXQRUapmKwxisAoYgFYbo YxQGbcC4MZCJaEfVNviHikETJFuzibUWdxvTSIXR0mb9pMAAfYTCaDAY/lY7qqe9nTHYPkwC SNKUVJzPOC7TwA/UZN2En/q7fqO41GBDYywxnNLYLngI2tAUiqBt/a7BEUXQEI1gdIHu23WJ 4FLquaCotELeBKrnh6bCESjoiEYwGFIJXWMYk+YgKCotcrrA1nTWVTjCBoaoHDdC1xjGqw0X AF+awoqUY11Jw7Je0o1sqQZaWDp98we1nel1sLR95w7KIO5FplDydRUwhG+pvyH8wG7wSJqO vdxVAQRFJbMKsqKEZULJwVwDd09tM0BRmPqbfiE2OrQNruDVtibop8UmMK5ueBs1BcikArHQ 2gxAGhOgj4ATe6riJuR2daiCfsTsglg976GGYOqZVHRJ71XAEKTCEH0MxjAxWhm2CxQ7L4cI UDXNdzzrtxzQ6EQhsbdGZ0GEFjhNYNrebCoc4RxDEIWWMnI78C9SqMMgqCqxlsvWtq2eNo0O qG3L6qkHxvNwc1ui0AztqkHXuNZq2arBQxvMsE6Ysay63IRNhmuxyw4vx9aKV3Qr/k4cHYhm h5XZ4fD43IZHaGnhyi69Cji60+LLO3ZehoxbT15QndPCiRqiIlJOzzLwo9nv281bHD16XINQ 3NzLhj2wQ1doA8GQ1s3PaRouozQQjGgTA5B9jzTSgfka0j6lAQd8J1GrFmMD7hiaKoLTUhmG qDY90lAHxnfC57lyhoNzhSsBkMeI0Pj8VQQaKZkQ1ahHGmqI6+i8wOjGwDbJ8MDmh4yl2j+r yLNSeaDoswIjHGeAkysFNzBnUikcYFbATVn+lOfVWcjeAca12EyXtNh7+Fh39mPQWDp9RFzm XPuObiQX7qL4pAB5bnHuu/oHGnwue98gGRZyDc8vR7XjOKvPku8sKRYaAogod8EMkKIox9DY ocaTMQq3IF7BXc8FkbWXM8r9Bzmw2gO01HKVZKQTaK6HCS2TYYKWLx6keWBFJ7dNjfddvGuY toejwlVMgpYOHqR5GI4Upp4PNG5Zgy8qgdhyuEMnQZ3yYZqHhWfdMH0DUt5BRQALLXycvvpo z89wF0njeza4MKbyXgQu719Y1K8plFT7q7hT7FF56YuReC8DwtL8GaJLpZkBGg3Q6qQF6XIL tIF9F2cWmDMtyI9ggXcYAMcW2DMt0OoR4kDDbTjMTHDnxYHWlzsBN1jIMwv8uU4wj2ACFHpI gMcmhHNNsI9gAuz5NN+P8VwT3COYAIexOQ/pXAv85RZYAweC+Y7M55pwv7w4mhDLVdtCeVd2 npXAgLyT6qQFlyRGDTdPSPuQE+AcNs/Mp6a+JCNiIrJrM/uy+JPzX5IP8Wk3+TUDyPsnnW/u lw6PLMBXO7dqgT/PgkvSIT4gqlULzJk+uCQbWjh16XULzvTBJcnQGSPNaiDaM31wSS50McDc qxac6YNLcqG35dy5YoE70wdnp0I3WXBVfx8D/+BcIK60GCSBzhA6WzwQHxv2cn/ld3897N1O 3P62v3K7z/hrly8ofTMa+/gmGRvxu4Zjk8QpJ52drd1CwshwEbQCr6Lzsv1qf2V2v/7nDfpB vP+ELfEvbPwD//yBf24f7pS+X11eN+Hk4lu9OONFzIeA93V8WKLnWp88faUTptfnxTcvjz/I CeWaRe/LHu78RRDa99ENYbvAjIjf6Qda7TcsdEd9jIHHMT4s37XMJXXNw43W52KDnh+tvn+/ t7uPeM7+jBHyqe4as/sFdtFP5cjzQ8LPr8rn5ycYtWrG6PpbUKVU58T41Dnd+chTPIgwL4II /adzx8zMQEt+tZfUyupXmEPqh7v1Ly9OedTMPLr+rNM8GjMunzmVBHe92tRAxIe5+p0DBTN+ fVu/t6DYnQR3bYr7jDOqrOwBe0lNb1zFiI+p9yLrObF1/QtKF9n6P5QB4QMNCmVuZHN0cmVh bQ0KZW5kb2JqDQozMSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFt ZS9GNC9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaSxCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNv ZGluZy9Gb250RGVzY3JpcHRvciAzMiAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDExNi9X aWR0aHMgODAxIDAgUj4+DQplbmRvYmoNCjMyIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpLEJvbGQvRmxhZ3MgMzIvSXRhbGljQW5nbGUg MC9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUzNi9N YXhXaWR0aCAxNzU5L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUzL0ZvbnRC Qm94WyAtNTE5IC0yNTAgMTI0MCA3NTBdIC9Gb250RmlsZTIgODAyIDAgUj4+DQplbmRvYmoN CjMzIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0V4dEdT dGF0ZTw8L0dTNSA1IDAgUi9HUzEwIDEwIDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMiAxMSAw IFIvRjQgMzEgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUld ID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDM0IDAgUi9Hcm91cDw8L1R5 cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBh cmVudHMgNz4+DQplbmRvYmoNCjM0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDI0MDk+Pg0Kc3RyZWFtDQp4nLVa3Y8ctw1/X2D/Bz3OBtixvkcDGAaccxo0qFHXe0gf 7MJwjbOD+mKkdoH2zw8pURI1H7dz2W0eciZFUhz+SIqaWfHklXj69MnLmz+/EPLZM/H9ixvx 7/1OCtlLKZXWchCDlsJZKb7e7Xd//0582e+e/Hhy4tO3/U6JT0VYSq+kbaQ/frff/W2/Ez+8 vBGC7aRop+9vwdaflLC2l96K249oEcwJJVSQvXPCutC7Udz+itt8ijsrGbeW4sf97k13c//+ 27fD0XTiuXjbqVHL/ykZ5MF0bw+Hf4jbn/a7H2AX3Cmbdmbsream33SCyc7c1Y27Whjdy9Zb a3pgg8smJINPpQzDs3Z/fNK56iB7rW2j3L06aNO9//r59OHuy93KU2hpezXRE2uySvXKtLJv uzVhLfvguLA4AsDWGnH74U0Hvq4petn7sVGUUeXjbwfffVvFw8ix1+P6k8zwMJP0waD6JUCM 7fWwxaKdWFS6seYBJB8g5P2ok4eQnGaIyR//EVMxrDyfH3zfKJ9xxpEzsh+0+G/cQjvcAmz9 S+yUVP3gxTj2oxdgzekRnUv0/T6vK2Sz9USzdQdRt1wgMZhECH0IXCIxqoRWUEKaSRCDSdjQ a26DGExiGCAwXCIxqoSRQ+/4oxCDSZih5yYSzdY9IMCflRggcdrvshRWIsq0SiQzhh5SbCIS SRBIiwWRBqGyXABpAKrLBY8WoCpQ4GjxKQIVjRaeKlDAaNGpAgWLFpwiUKFosakCGYkGmbpc gFgM8gQIAitHeR0qP/Qy5ZQd8YHKciLr8ujxccpyIsuyhnPIVpCJrMujQkDLciLLssFjpe5N ZF0OQ6/q3kSWZQu9iiUYkXU56F7VvYksyzxSNXBl+UTH5U5LgwFRVlIqFUZAhfvKcB69jwzV yDvEmxh5OQmz5aKNmGk3YBpiusqIfWaMJgFb6NAbnxgOU59rlAYkLZdIKkyi2MCdDQ4WmPeG SiszHBw1cevCGKhSjKXKqCoevCSaCSSNKlAs4MY2GERXw4iRWkJmACTJvcwYHFqLDImVwFVc X2gmkDSqQLFwIoCVz3iuAWwnNGpASNK+xQRgyBSadVuXM8KW8FzBF5ddwSrRknpLkecCkZEl EpgGKcJuDUzlGwap6NR5Mw0Pr3yjUQQSXQQIzAzcGpKQGg0DqJHSI1Gu1DEJs+XEcLVWIcQa IqdgbtAEYqSh6FOKZToQ8gqPmlbBYgESg0kkFSZRbMR97YCTihpzOSda21zsiTaSMsM6dIjL xyOPGEwiajCBbCHiqgP2DO1ix0MQiOENFXtmDIrOGqPjczEVE4clYjCJpMIkio2ILMAAPMi7 dOol2kCCE5KJVpJqxWJHtVwBzMGTEqNKkEqVqDYyvjJkQFcANlNG1AAoskKkZW6ZWYMJRFqy foj4+QLoCsBYIA0jagxYEL8yhsZwchUuERlZIoNsbcZ0DWSbCoHKOzPyUVNUuERkZImKKWFI mJoFUOGkSrmTaZVLNCtwAcMlMoRYUE7VeEc6D22ZAQNObrQyzXlFI5Z8otl6UmACxUJutXEY 1LmQMyMPg5kxunxQGt/IUyfQVPhZAuTZctLOhygeeDDP+HKIxiPSYyO8r4zYRSOtY1UwjVQ3 icEkat9NAtlCaruYm0blcBCtLfUWouHyZxMZWw2Th9NDFgNMImowgWwhwxrYLL4IK2KiWOWm cWn0DexcIFrIEpORiApxCcVmxi9nosp1lm34XImk0khEG55XorXpLhDRW4MzhAmDrg8lAXwa q4JtNJhApA0b7hEvXwBcAXTUE0bU8GXiIYamA76ocInIyBKwcxyV4z1aj3CptqPFq7Ux4nW6 U/8kJlPSwggzmzVmYwDO2L2BO3/vpMcNrBJfP7H5CtygsoaE1AsTGJyVWufD2nsm8ct+9xHN Dw6fQ8js8hXsnuo4BjGMdrCd+tn0FkZ4pETDEFWXk2+XGzmxcQ3+lL5hQoy6tXygg9Qc05kA FxGrmQS5cyVTJzaoxweKKeZ7FxZGeY+PhPQwIhBVgHy6jqUmoQfrBKY1ZrQOusloNlEsnPSz 83c6+5xSwhmBWY32jdQxofGKNeCwOcYraLwD4//iC99plj4kfEpXbBwVYrOcmXpoGdMFHgaH yXTzm2s/tI7AwhyBEyEURVhSf2i9AcGNsd41QmGgxbQg1NNjqc3Pmu+0KUYYPBxTqWXBDnak vpIOIk3JhOWvsR+4lDtY7KaSyy3ksSZObLyAzEqVDscNPBGcrVTZ8b10ZbAG8Vi9EwtQ7Byx kAO2Mw0TxBDyhVx7xigt4I9onioEcAdMY0KUMpCFiiYNC2GpdCnvR6udFt7++voVBruRFR6/ DkBI6ueX/JYaJrUw+ZgAjxziayM4pcpHE/pUAtPO4Th0kr17Xvo4MzzKAb+0/wjTnAwzBxQ6 oORZD8LlHiiYCPww80Bv9GC8ggcw8Bk788Bs9EDJK7gA54uc54Hd6oK63AWtHH4Tmrrgtrqg r+ACzD/GzVzwW10wV3BhcEtADFtdsJe7YCT8nXkQtnrgruCBgf43d2Hc6sLjGmPrAsw2cJQb D6lv5m0JHBg76FjnPLikM8JRquH4g0POwHw1a83ntr6kJSp8Yz2sbe3i05914JKOGC+g45oD Kfxno68vaYgac281+spt8+CSfqiD6ldDoDeG4JJuCJNpD7eFNQ82huCSZmiGAbvgigdmYwwu 6YUWxmq4cK15sDEGl/RCO2j8JcaKB3ZjDC5phU5BL1x1YGMINndCWx040q+E4D8YTcRRiYaD d148KmXAW/jUsZeHo+v+emr9+j/sDtP7PCriXDg2d2e70BjG+ALHjHgBnO78+nDU3fv/3B2O thNvO/yd0+d/Ho6++w057U9qHhmQUpWwM7TG5f3PPnk+Fja8Y3Nwj7Tp61J68ehgMPCF8cAr NAc3cSga/KIg029JfIgM0KTv3yShfGHoVuKX9Gu0/JuadAG+huHWxv3ypc5ccng5/P2Qjz6o +Sj96j1mxdfPmCmnD3dYJ18wOe4OtnuH972fX4V3mDKvn58B06gZmOvvlzKaUnEogXro1REG T8aP9MILX34iOAVlJrQY0ksOQwopvp1Sfzyif3lxLqJmFtH1l0UUUXxlR7+6SkElxkPvgigH 8d0J/ZQq5TG+dkvfJSltK+OheniMnVZlLf0vObQzVkEu3aHOgvX85xv88w7oRbx+B/EfEB0N CmVuZHN0cmVhbQ0KZW5kb2JqDQozNSAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNiAwIFIvRjIgMTEgMCBSL0Y0IDMxIDAgUj4+L0V4 dEdTdGF0ZTw8L0dTMTAgMTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdl Qy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDM2IDAgUi9H cm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9T L1N0cnVjdFBhcmVudHMgOD4+DQplbmRvYmoNCjM2IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDIzNTE+Pg0Kc3RyZWFtDQp4nK1a244cNw59b6D/QY/VAbqsu1SAYcAz kw02iBHHPUgenMCYXdhO1p1F1hNg8/khRUlF1WW6xz1+8LSoQ4rioSipqsSz1+L582evrv95 I+SLF+Lq5lr8b7uRQvZSSqW1DCJoKZyV4vP77eanr8R/txslPlaMlF5J24A+fLXd/LDdiK9f XQvBBlB5gKvb7ebZP5SwtpfeitsPaBHMCSW0NL3XwrrYu0Hc/o7DwFjPvjko+HGPzW+2m7fd 9fHu/l5ciZ+73S/i9tvt5muwiXaLIePAO8sNiT1INMhu//22i0avKFoVGi2Z8H+toY3vZVwd xka5ouhgotIvjPTzbk1D+d40Q73tBMPOwq2bcGthNEaER9uaHsRRot1k8LmUMbxox0em5qpB 9lrbRrm7urv/tDOxe7+z3Z9Xd0f4c7z5/NvOdcfjyqS0c713rRmxhvXgrmqxq/zroPvBcHAi xlqTouzk2ihG6YlHmZgPf+x8d79Kj/Gq12F9JjN6zGQ1YIz9Ej/GouEzLNpsUfZBi//DWumd drhewNR/xEbBCNChJMi9AHNO296W9nFbAZDTg2YAajNAAL8iA1B7BGg5wNAjILcZwLo+Mgu5 zQBR95BeI4DaI8Co2LNJUJN1O9tHpp/bADhsNwXkIbAIaXUKRg9gcQJJTRwldY6RbEM7Amok 29COgBrJNrQVMEayDe0IqJFsQzsCaiTb0FZAjWQT2bG7RnI5TG0oKdolTOuxhsUiyckhjn34 u3Sk1T72lWbpNjpiqEt3adbuwaCTtTs3S7d1Q69Gp0qzdLNZjHMqnYe8CW20iUimcoWBIvCu tzSHLAi2HzwJfA9rnKnYZDYLGIJUGKLawKDqMPQGuCUworIAKoahkYpgKEOHgHaYSlT4KwsY glQYotrAoY3TvYEsgpClGZS2L2aKADKZopC3YqZhMS9Tk3UTfuyv+jgqMgTTMVph9mTKkiDm BVUEMB2VBWk6TMWn6WQBQ5AKQ1Qbh0yzj4XVZZoHnEHLe1IJffBFJQkMLYyqMQKywIwrBynU tnC6RrKNE4GmckpVowrqsioqHJEELL8Th5XTNZKtnQgQEHPBK22bPasKHJAEBVFoxlOFLqhF mm2cCFDFqHEtJxPFs6LBAclCARDJ4ArUOxo1tYCyHDJsWZ+LpgY7sQV7rExZwBCkwhDVBrHr cVVpOM6FTAQJ/JB3gCIAgihfNdQAyCKuQuySgCFIhSGqDWI3VXAdPZKaVxwKBkfZl9tG2lJO gSznG41QWmN3xufuUTsx6zWuKaPKllkFebcp7YY3dIJp0E5f9tgC0CVLM2BCrMHKmtlc4hZH 5QLCW1kWXTHgKr2kwhDZRkEUejGkxOYyvVRuG75RJag84WojcDzrzgYCJxZ3+MTjCq/oA28n fGClNwl0nkrV4Igk0GyywN14jFgiVtumDRzJXPhItSRSwfJuUi4I4lSnLdHIPlOa20POjCKw MWvh4mwUUtGh9thNcNZf9dOo0aZ9Spb9pAiUzVZyW6eifqT9M/hGI00jCxhC130gI6oNojXS llvWfRGw6ksCWP4ul1tPe25V8bL3rFIUAGmMgGoh8QqXmYHWtaUVlgXKFMKyQOsiCGmn4yom MUgChiAVhqg2iGOFhjOnayTrpk0atka7mAhlgZEGA5CF0k8sG0xsInWFZOV5O+N9PTRlgc7n 9KoxIrKgIArH7Y67QPFkx42THTdOdtw43XHjwo4LBKYqayobM4rTyaDlPKm4vOBLW+G0uEYF 5HYBwMAaf6Y7qh7gwmoHi9dWY8Qbuq9+KybnrKXzz+xYMjsu4GG9N3Cf7p30OIJV4vNHOpDh eQxw+RwOqeAnRzgEQNLlqu96w/p/3W4+oO3gcBZwW88OX2r0wM5sUP1zwsCdaeGUB6k/UNvB xBiAnHsaQwd2opc4nZRJgIsp7qElAhRTGypn1AyQPXoaSwd22oc1ZMtGEXFjSedongpw0M13 PodhGBHZpycy1eR0sE5gZmNSQ9CbpLb8MDI9FEx37OlmeqCcMwKzGq0byCRKaHzaI3Dnwus1 Wk3/peex80RdB6cETFcvDXkZ56Ye6k7JolJODekQPNd+qD8RG9MVDGqHWpjHg/0NBW5I610j EUBUQwHfSRZq/Kz2zmpiosGDEapZMIIdMg15E0pPd3+nJW7pwY+iowYUYT+2l+vI440c2DTA e5pW6B00FXhHG5HEDB8FpUx8gd6BnTnqWobbc1rLZeliLrOlXGvA4/UObJcBuvPBAvYxOFcM WG3TuSKgf6OgrO8vUTwsPF514/sRcFdB7kspoD6xFyPlWW56YMKf5Crp8mMvmHp9rZFfZshe 7vZKdvxdwdL7E/8oB6Jd8gAO8h6yfuqCQhfCSQ/C5SFQUHTkPAb6zBjEJ/AAMs+4mQfmTA+G yz3QEirLMPPAnumBkk/gAhaXOQ3uXBfUE7hAx7mpC/5cF/TlLuA2EmYehHM9ME/gAZx3pJm5 EM91wV7iAhwDtMBL7gINJ0e+qBwOEje0laEdzH047cDjymHrgHamB40VBxQ5cNKDS8ohHuns ugfuPA8uKYcGbqph1QN9ZgwuKYfWDukl+IoH58VAX1INHZz5TFjzwJwXA312MbSjB/v89QT8 s+DIXolWIqGFC2XAhTJ17NVu77rvD61fTz+6VvgGcDq4OBWOswuzXUhKafshwG0Mj/fTkd/s 9rq7+/P9bm87/PRjb7pP/9rtffcHStp3848MyPjdCFwh3Mr4J2deNoQznm44h8VXK5nfPTm4 A9rSfuDJhUvvzTRcRegK6fC2mvTyu0vql6G2fdP/K32fU74RoBvHpUYb/ePy8VlfslU5fOpt kwdqfnC6urvH0+un9/jVyRE2TtXdfP4NfpnuHXb8+Dq+wzR58/IUgW5G4PpVnhhUA6NPsadO S7d0ipuKg4Bra/1WasrFFLMYzUt2vxxNGAPuj18azO9uTgUzzIK5finPwQymfBdC8aT2Qzdu Sj0V6jcrKXXxjE9c5HDW9gP5f76RBr+W75fszYUh+LNwSmcUvUzHxGP6zsrgd1awYb3b2e7l j6nj+t0udN/BT9OdpGuYfJCEBZC55GH2+G4RY0AfOAGfsHd+LD+Sa8PK51E+pIoxKi98y/Q3 +o6cpA0KZW5kc3RyZWFtDQplbmRvYmoNCjM3IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50 IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA2IDAgUi9GMiAxMSAwIFIvRjQgMzEgMCBS Pj4vRXh0R1N0YXRlPDwvR1MxMCAxMCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMzgg MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9U YWJzL1MvU3RydWN0UGFyZW50cyA5Pj4NCmVuZG9iag0KMzggMCBvYmoNCjw8L0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGggMjMxNz4+DQpzdHJlYW0NCnicrVrdjxy3DX9fYP8HPe4GuLG+ pQEMA7lzGiSokTh7SB7swnCDOEG7LpK4QPvnh6REDTWzc7f22A/nFb/E4Y+iKM2oJ9+rp0+f vLj75rnSz56p2+d36o/9Tis9aK2NtTqpZLUKXqs/f9nvfvpC/We/M+rXJqN1NNp3Qu++2O9e 7nfqqxd3SokJTJ3g9n6/e/I3o7wfdPTq/h1aBHPKKKvdEK3yIQ9hVPfvcRqY68nXJwM/PuDw 6/3u1eHu/PbDB3WrXh+O/1D33+53X4FNtMuGXADvvDSkboBigXb/86tDdnZF0ZvUaWmS//+a tIuDzqvT+KxXFAM8qI4XZnp9XNMwcXDdVK8OSsguwm27cFvlLEZERtu7AchZo10y+FTrnJ71 8yNSS9WkB2t9p3y4ffni7fm84r6JcQi5V1BrsskNYy/6+hC1evf7MR4+rEbIJjOMaX2KRYTc LCHxMeOlEDk/2HSNRV8t6iFZ9T9I1yHYgCkLpv6ldkZbZIwGjIKx4M0Qcxme98w11nfsMhb8 kDDnhEAhCIlRzyQKYZKw1vUSlSAkQhjGKCUKQUjkPJMohEnCWdNLVIKQCH7IXkoUAkic9juW gpSngPRKVWYchziXoCHwicfRlsFnXot1F/vGbZHuQ9/4Lc594Jk/RbkPe+O3GPdBb/wW4T7k zJ/i2we88Vt0L0ZuFt2KAMduPf7gZE2VBO4Kdh0y2/qx8eg3M5y1w6RWR405hsFPzDJipo95 8Llxechs+QjiiZh9qvvHzkItJTihpFL8mBD9YCh+TEiWH8b4wftOZeSRYBd5ZjdtDCaCC5h6 zQbqeCT9MoD8ir6M3eBsJ52GnJkgJIqKkGg2cFLnEi1NCGOJZxk7TRXqLAhxsL4QMOJCYcSU KuPGruITf9LHWT1s7R6Xe0AXEahKcAYJZ0FIjYBZIDUAgMiESaAoCIFm4VSBjQzjGq6wAnpC pN3Je9bAse2kJZcIVqLqM8F4CVNctNMIBYNh31gzVihYvpMgAyzBiIbICK5BOh+ThmPxgIBm fCYh3rhZMBlNFxm8NTTjbEwa0M2xAo7tWKPOCoIv2QVKi/haDdEoJaQSDM/CBCh6oRI0RVSo BGxcKkFIFBUh0WzQ1BDwscw01upVCFZjpM+CMNY4WXyC3KmMuCAqQUgUFSHRbBR0LS3iSO0r AVIJocFVCNCB5UrQmHNCI2AYK2ESKApCoFkgkLFolkJRHqASnMb1fp7GJpRRlLIw10SobJSc eFWPkY2egVxDNucZgVQcwvd+IuixPmRTkRJIaBKMbPYM5GVkaYvvoSYVW/daJpg8+E5jEigE FmBc8RELjJdxdTOUST61VV4Jrq6RIj+xneAxoCZW/Fbw9P2QxFONTCO4WthZQQp4waf4IhfK Y66pVscpM45lnBMvCk3lXSqMGJZKEBJFRUg0G6UKW16xdftlAoNUxxbrM401r1dWCLxe64Zf JUhDCLAFQhX2YALFVueYAEurFJxG4F3KQXXHCiRUIlWgQhASiXc6lkhyp/OJwmCzq60Qj7lD ZMLo6zbgUyo9JGtkS2WAxoJfFIRAs8AIg3cV0hWIqXOSBNTIugaSLUReulVDCpCFKFcuANhW 3UWAXbfoWN5S9Xk/EWAHr3tB1RAS1QRLMMRYaAqiaxDXgjwRSMUWV3kMi7VWbNYQAlQLkizI gF+SZ4AlwlnP8EZ5PN94licDsVYykp/YpM08mJHApjOrHeEA60ePx1ioKz+U8+u3atZOzfud RSOy6BOwAR8cnK2HoCNa90b9+evUdAHuZTECJrr0cTbLLg12rLofQKkT/N/2u3doOwV8Aji5 V2e3Gj1NnbkdQnniEa30bbsPQ2hZZ5hZnNpm4CTCCj1USRc41hhPcc5eBN6OCS8+iAAAZSFR XflMpk4CWj+MJZ1g04NfiHXZwdoZAOgl/eDoMmYhUZ36TKa6DE4+KMxjTGEL6MoUlr3GpQ5g sTPPd85TyTSnMJdxBqdtSWNNDSzWL4gVmaU/dCm6SM8HhPFZPDUy1lDRX9h6kI9JA10ltnPR NE6n/hAf4Q2+JApd/C3VH+J3QISR1rlFOGBOCYTcNy4U9EWdXdQ/wiFCxS5lCiaAZVNwKF2G qQlFmzrO5Wv+WFgARowvlo9PMHISjQbolceCsyPsqoay+1zafh8FoZWJT1A8iTjBf3U3SYMF RTi0ppLQ0MnYKAhcDT5J8yRaC4tXurSXOCwoNochVqzosnoi8Fr/JM3ThZvWML2twGYCloCh 20PxmoKvdemCoru8DvUaCzKvvWOobxZgjzjeGH2QF/eXXmbEzfNDHltkzBwwVzqQNjtgINXq tbZ0wF7pQN7uAFQRu4TAXenAuN0BOEQs5/dXzm/0RzmQ/QUPcNuBk/HchYAupMc9MJtDgE2v cQsH4rUxsNs9gCbULBxI1zrgNjvgDHVkcw/ytR747R5A7ddLEMZrPdhSDA10dlZ5Ozi3jMGj M28pg3jIh5ZgZeoAzz4+7sCWMmhdxjP3igOmOPCoB1vqoDPY7q85EK5zYEsddLDPwh6w4oG9 LgT24wph7wFdI4VVD66Lgd1SCAMcI+KaA+7KEFxdB/3kwE39ggL+efDjxqiOEsumYUZqBOeO vTjehMN3p96vzz87HpJDXsyuHovH1WXZX1iXYx4ivs/Hzn8+8w/HG3t4+99fjjf+gN9/3LjD v/95vImH35HSfx3wkRFpiwKO4ymtzP/ok/N2cMV9SoipvLBI9XIplAuZSnjgxiSkRHeCpr3p z7q86uA31CwBpxQm+F7it/KpDn+rUI49n8Nwb+N8uYG3WzatAM0zIoRHsHEB0e1LWBzGHN6e z2+O7vAjbaLf5zdHj9kDv798DMO4wHD9RqGCaPIoEMTRQ1cFFDMUg4Oziu2zqTkWC6GLkdyy B9ZImotN2AOB/Pvzx2KYFzFcvwzgGOIrqSzDWAgPHfZrstE3Q1YkLF78lQv1mp8T4aHE/xg7 vcpanm/Znhkd6JT0shTN4PmS4PnxDtB5g6eHRyFyevYBFJY7MXuMnl7raXi8ugUMwSXygH4g fhAk3DZ/pobp8odZEc70WZqp37otPqX6C53+lNwNCmVuZHN0cmVhbQ0KZW5kb2JqDQozOSAw IG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8 PC9HUzUgNSAwIFIvR1MxMCAxMCAwIFI+Pi9Gb250PDwvRjEgNiAwIFIvRjIgMTEgMCBSL0Y0 IDMxIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9N ZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA0MCAwIFIvR3JvdXA8PC9UeXBlL0dy b3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRz IDEwPj4NCmVuZG9iag0KNDAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg MjM4NT4+DQpzdHJlYW0NCnicrVpfj9w2Dn8fYL6DHmcKjKP/loEgQJP0iisaXC6zaB+SosgF mxR326CXBLjrty9JURI9tnecOHnIjqgfKZqkSEq2evBcPXz44NmTvz9V+tEj9fjpE/Xf/U4r 3WmtjbW6V73VKnitPtzudz9/o97vdw++Pwf17uN+Z9S7CtY6Gu1H6Lff7Hf/3O/Ud8+eKCVW MrzS4xuQ9TejvO909OrmLUoEccooq10XrfIhdWFQN7/jMu9oZaNpaa2+3+9eHp7cvf74UT1W rw7HX9TND/vddyAT5RZBLoB2XgpSJ6BYoN28eXlIzi4wetOPuDTh/7+EdrHTaXEZn/QCY4AH 1XFmpVfHJQ4TOzda6uVBCezE3HZkbqucRYtIa3vXATlplEsCH2qd+kfj9dFTU9Zed9b6EfPh +dG6w+sPn/48v7l9f7vwGNb4LoUxo1rCWtMNbox9dQhaHU/u8PaPYzx8XDSXs+CHYXmdibnc RXTiM8c5eznf2X6NRM8Sdddb9T+I3S7YgPELov6tdkYnnBhiFxUIC6Cw93l4ty+zxqYuJTHP BIGIpjNSAhMEYnBIF4hMaAhrA/5pCCYIRJBK4EjMDRAMo+lMaAhnbRekjkwQiABhIXVkAiDO +11BRTA9YsZMFRPAdBcQGtIyOFlsLU1fJ5upx7ZvgGrpsekboBp6bPkKaHYeG74BglSgmpmm qpXHZq+AZuSx1Rug2njBfiMbsx+KAZe9AEbQWY0ICrXZPCqT1pgupjpbhnU6OjRlneZhmXaQ NUKTXYZ1OjZW+l0mIJt3vq1ahnU6pm5orGVYpqUJhEXK9JnL0c4MqYNkaAJYOduXCbG6nwm9 wT9ECLhUY7Ea00MhCERmEYgqA13CQQC5uOvJ94XgSnBUQujyOI3hFCNMKNOEFbOFF1d0wcLA ghZDtnceJ4Ml4q6Oa3BiJYYnkgwBDcgEgagBXhBVBq7rMbGkniE0Gkp851GP9qKRwbCW4Egm yASByCwCUWWc2a3GFi8uudXFCwKx1H1eCDVTFBaJcFEgiltNLF5ccqu/GBNHSQKFYEkBwSEB XswL52ZnsnPBSRPvJtc56f2+ZMrKIAFIqIjsS4cjduCcO1EnSWB8SWCVgI8gORqACQzI/nS5 +pW4YILVFnPRnSCUMDADeUWyhJzYSygxglkaoskgf4I90Aoxdnkv8xj2AG9KHvdoNiIY2hON AQKUh2I649t85c/OpB7Y9gMbpRBS3Zg4giqYA8/5nowq8BbFMUEgMotAVBm8U6kcBd42PHb8 rGWY6ma0uSVo+IirMEEgMotAVBnFvahL9uaSezGdjQjE4qvzmMBhUzkkgAgirtB5iX0561uf 3SB8jXCPOe73Oo4DJ/6Kb4BMqAhyrh/yRkvznsWY5BEjW3otrKX3KHiRgFlAQQi3On5MHGIP cenWonWJgqJ0xUsAdSnysUyiaQMq5gxUCCFi5b5rhOg5JZmEGkiOSAk1ExogMwhAlZAzbiQL God5g9JjJtiSlythKD0LxAIUTcmSKHoyQSAyi0BUGeRKaDvIeZoDtxK4uckjyCt5bzusHVHi 8TRWxgKQORqgSiB3Ag33kI6lBjLBZHfyyBYrYnMUR3Bq0ZjQALb4oQCqhOxfl/secueSf+1o zByJW5ZK8Pw0haMB8tiLp8Vnx5i3pYWfdS/Vy0ZgllLKCsGUUlZZGiITjCx2LvZyp174tr/Y mwVc92bxfkOwgNHeBG/Bw6PvZjxppFMRZouwyleEEVhMGzEHC1l8PDrK2gHOtX7weLp1Tr3I x9of1EWTNNe6XHaM4+KPXXXn4MjdBR1RujfqwzvRfPV4cUL9sOl6WifUzooAkLvyGPKLF4Df 9ru3KLwP+AhwopfabpF6Fu0XxGZ+aLrIwof2sj2zsFs4y8PhMzZAVu6ryDk3E3uco4QO7UEk m3Ot576th4flGuHENGvzFcSci39hZ3DahzNYJIfHVN2fhs7mAPTgeDHLmmyVMYrd3geFEYzB a5MdBa9sGWaK+bjQXnQ25xxdTmEAo3CnbY7dRB2UGQY8EtMZE/+jy9JJRC5j8SHwPgsbwURH 0UtR985jXEDjhO0LenSO/b75cz43GSzZC6vfNz/yQBhoa1v0AxQI6YFRPZhL1OMMOs515IEI /DkrgXA/sAdy0aBtTDUCIgiLBNQobhI0hlQjzGaLL5FyFqWkbCQL3nWwcQxvHIxVb9u4ZoPP 5zuLqmIwd1D9N8SWNzLZ0BNfJZQN/0WcZ9EuGNh5VDmg+kLLjhc13D70KKgRysb+EsbzzG1r aO8xAAfhECGhO4ih9gKjXO0O6ER5sQsJK19kwdapLx34VQPs9+PJ6IO8yZ97uxE3r0+p3k8U MCsV6DcrYODENbiJAnalAmm7AtDD2akCbqUCw3YFoLyGqQv8SgWM3qyBtRbT/6UGYa0G5rM0 SH5OhRAwi1+qEFGF/roGdrsNclq9VKBfawO3WQNnBiggEw3SWg38dg2gs9JTDYa1GmxJh0bj ZZKHoyockyf58NrKWxKhgacOw9LSAZ59uK7AlkSI7T80cAsKmKzAVQ22ZEILvYM2ixqEdRps SYVOQ4lfdIJdZwO7JRXiCwDozpc0WGcD+3mpcKyB15SCFjRwK22wJRXii35ojJY0WGmDLakw GI33ZAsa+JU2WJ0KfdPgxJ+WwD9gUSejRpQ+UOXCI9JMmXh2PIXDP85jvb7+6hZKxNQq6po5 VudlP5MaoDsZ8Np7rjy/OJ7s4fWn2+PJH/C7mJM7/Odfx1M8/IGU8YcSn2mQui1dwmPN/PpX n7zUhRV3SAFfx6GJNd+shkjvAphwzy1RCPiqEm9g84VrwF1EfPxKN8/D7i5jO5r/LX++VD7Z yMe+rUJH/Hfzxxe7pWoFOCNB1UINzDDxzPPXGAwfPv2J7dv5zS3uj/fH/nCL41+P/vATtRTP E/5+Qb+/vebMNHHm8qUKe9MM0pVmsPdemZAN0Q6DiirW78ouHTMBzdp2SzVk2+K1jNlm2h/h tzs8vWJapyemXb4tKabtXflKiK2bCffdiOSgNH3k1/I5qA0cx7NnchC38T07Y72QEX5hJ7gt dbt4q4dT8zRHXXXXt+Sun57Az1+R9uNVb9mLz8YwMwp9YvT5fSE8cP4MDdzpetKJfqArIU9g gX0D7Z1Z+JwtgsmSFMOfC04+QPsLeb/YnQ0KZW5kc3RyZWFtDQplbmRvYmoNCjQxIDAgb2Jq DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L0dT NSA1IDAgUi9HUzEwIDEwIDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9GMiAxMSAwIFIvRjQgMzEg MCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlh Qm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDQyIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAv Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTE+ Pg0KZW5kb2JqDQo0MiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMzM4 Pj4NCnN0cmVhbQ0KeJy1WlmPHDcOfm+g/4MeuwNMWfcBGAbicTbZIMZm3YPkwQkMrzGeYNe5 PAskPz8kdRRVx3Tb5fjB0yQ/SiySoihViUffisePHz2//uczIZ88EU+fXYvf9zsp5CClVFrL IIKWwlkp3t/ud99/Jn7Z7x59eXLi7n6/U+KugaX0StoO/faz/e7f+5344vm1EGwmVWZ6egNj /UMJawfprbh5iyPCcEIJLc3gtbAuDi6Jm59xmjuaWUmaWoov97uXh+t3r+/vxVPxw+H4o7j5 er/7AsbEcetAxoF1lg8kroCjgXfz5uUhGr2iaFXotCTh/1xDGz/IuDqNjXJF0cGDSr8w0w/H NQ3lB9NN9fIgGHbmbt25Wwuj0SPc29YMwI4Sx6UBH0sZw5N+fozUXDXIQWvbKR9evH5z+9Wv 748qHe5v71ceA3JriK5XFKvYMCTTY1cjrk0YfDcwhcJaQ341cnWWEAabOsUcire/Hf3hfjUg RkPs0/qTzAJiJvmPXvVLETF20OGSEW0ZUQ5Biz9gdQxOO1whMNR/xU5JjQL84wWMZpMfYiHf 7ZsYpouRyTPNAD4Mig+QaQZIabCWATI9ArRR+KcBCs0AnqkjwUTA08y8Qo8Ao2FFMPMKzQAe Uo6NX2gAnPa7CsKERkivUzDwPH6KIBLkJGsu7lzepM3DvcubvDm493iTN//2Dq/y0b29v5vc c+Xi3ixpzu29XeWjb3tnN3lz7aLfJr7N7q+OW3c+PL3MEfZxMMzzmWxiDW5Uo3YhRzGYGEbt Qjax8W6wTZqpJrTgQTXqFnIUj0/SnqsJT2Wb2mkpB3C2wqHJyZUR/EA+qnQM2SUq0QNyBU0L jmgGIIVRXvXRpdo59IJ2qkS2MQIW8Xcjw+sh6czQGDSuAiWx0gyQNUZAGwEnxtRIOKwqxjcG zdooD0UqMzw+PMODk5s+B5AGA9QRcFYLvsG8A0dkUGO4gmqM2BgGVw9XCbgcC4Mj4hQR2dQY vRrMleBCvnU0iuuKqjQlLcdzADEqooS3hnItttr2DKDSYErckKrFp4GZODMqosY11hoyjWnC aViEI4VHt/hHimfQHXoEFEZF1ID6Gr61eEY7YaAGhKgqIGnwUTieyYmuACpEuaJid1IqbWW0 va4wjMGgEINEo4qWamg0A2SNEdBGyPE06CQIesFkOtqCKXSSjVb42FyBWtDCYIiswhBtjBpV g+OYvHFVOpbq3GgsbWUxYqwa3khcpplmcsIzedWn0AImQWhgGZd2oTJCBlUaTga6MOzgY6eR MOELgyGyCkO0MWp48Wl022iXwuv8hEEqdXE0RmuPqgpHEIMvHwygbxFdiTAuqY5BGuMqLwxd KmNT4QhiVEQNcY3oSoTRBZzOQ5iWEZq649TjOQAZDVFjjKvL1NU2CzFtk13IEW8lsn8eGcYN 3nINhihDVEQuxmbIW60qOyPRoZaWSseSN7gWle4UHAavMBgiqzBEG4PmzduVhr4bIYVq/Vdj tHldyaKCp1qAFJOZNmMRGz6jsWnIJT/nU6F9bdwKDbtGiZv1lBujAhQIiGBhMERWYYg2BkUW rWhZSE1RZrSWsTCMKhmFp2PNFSxVoDFLMyDjR3nTr3FVvgZyJbBOTxikYSscKZ9K39rwTYxU E9eYGt5WL4a167Obiq14kytDiXrFN3HQTFzDKrvtcyGuZsogjdowNEZtGJoKRxCDtxQYNsPP AouB9ROaNNrJqzLquFWDA7gc5tUYFzq06gQnWJssnmONES/yAfZr0bdUS+1O347MWgXsxAcD h+vBSY+jWyXe3+XOinIgDalmQYp9q0Zy6G/bVi71CPhpv3uLYweHTwBH92Ls1kFPpUWDU5Qv mwWEIq9V5cd+DspC2+qZMJu1dYgT82vA6zjazjXecrDUqgiahhhwSOGpVYz5REOdxsYO9vfc C8CilblVHOPvqY1XOU3hfKKYvFj0Kcbp8jdYJzCLMYGhuLEE7tuMhc1/uilPt8tTzjIjMI9x fLCKUlgl6mK1ptaAlOg/uoCdpuZDYEo5SXVa4Ql4OtIDUkoUS6UMchgP7jPlh+QYUrDIeLrx sktzPyTvQuASrW+NgYBjRVdD2H6xVMundXZW/SgGHgprLk8wgU2ljBiEqOCGUtglPCZ2IREz vLSIITLGcuH4mGFO7FGaIqyYhHGuOFzXKTJGrRAfpXliW0wpcsbBmbncBOSKbKH4RsaoZeBj FE8sGkXPWkWGpgqzkBtoaJpM+FGKp4VLVje+IMHxIA2NhG40sjcj9UYXpoqTe3JXLrRgkbfX GeUlBvSzx6tw4K8Ill6b+A+a3y9Mj1d1oDedX+H8Sp41IGw2QMFiS2ZmgL7QgLjdAEhvPTfA XGhA2m4AVBM3D4G90AAlN1uAKznOLXCXWqC2WwBFR80t8JdaoLdbkAw2FlMLwqUWmM0WYGsT 5okYL7XAbrcA2kE5tyBdasGHlcPeAiWxlXB2MLCpz8rhuZm3FEKF7yVWp3bw7Om8AVsKIfZe Ka0ZoLIBZy3YUgl1TNj9rVngLrNgSyk0cHwzYc0CfZkP9JZSaLXCVn/Ngst8oLeUQhuht1v1 gbnQBxeXQjtacFW+14B/0FuKKyU6js/NC15yLZTI58crd/jXqbfrb5hd48lrOrk4546L67Jd WBZwNFFBGLo1ns784nilD6//f3u8sgf82OTKHP73n+OVP/yGnP7bgA90yPgZARxx3Mr8Z5+8 7gcXXKY4je+ktfLlwtNBQxwr/cBliYPzOmydKpXrVweHBk16+XVnlZtK69TJf8pfBNVvFPKZ Z+ugnf675cZdb9mqnDV0XAALVJrnxes3kBPx8BVmxK+YJO/vj+5wi/08/niFP/AjI8D8iV8B wap+dbSH776NtMvi7xefnwuunwV3/aYhR1elOIYWiYeuELJPVXICTtXty61JnGaYRU9v2RmL p/GOQv0tjv7m2TlHx5mj1+8TiqNDKp90FF9n+qHbgpyyKtZ36Dnl8fYv37EXVzf6gXVz+SAd fm2dbNnTa/QC3WV+qvB9/h1F7/rVMZwPn5GTD6uwkDITPRz+8LWcBB/kD7UgvtCH3NUfGFvY jHA/fgOd0NqngT7Q90fjMOU7sdknWn8BcjrBdQ0KZW5kc3RyZWFtDQplbmRvYmoNCjQzIDAg b2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA2 IDAgUi9GMiAxMSAwIFIvRjQgMzEgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMCAxMCAwIFI+Pi9Q cm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg MCA3MjAgNTQwXSAvQ29udGVudHMgNDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5z cGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxMj4+DQplbmRv YmoNCjQ0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIzODE+Pg0Kc3Ry ZWFtDQp4nLVaW49btxF+F6D/wEcpwNK8Hx7AMJBdp0aDGnWtRfvgFME2sBPUcpFmA7Q/vzMc Di/nstJaqgHbmhs5Zz7ODMlzxIt34uXLF2/v/vhaqFevxO3rO/Hv7UYJJZVS2hg1iMEo4Z0S v33cbv72jfjXdqPFz0VHqaCV65Q+fbPd/GW7Ed+9vROimUDnCW7vt5sXf9DCOamCE/efcEQY TmhhlJUxCOej9KO4/4LTwFwv3hw0/HhE8s1282F3d3x4fNzf2J24Ez/s9n8X999vN9/BuDg2 D2bdKEfTDpZctt6L+58+7JwOK4YgkTH2hsnkv2sG1ssxrM5knFox9MrI0S3M9MN+zQJ8M91U H3ai0Z1F3XRRN8IaqfqgOyuBHZW0kQZ8qVQcXvXzI2Bz00FJY1xnvLt9ePy8t3H3ce92v98+ HOG/47u9cTuEbPmhjB+l0v0wYk03BGltr7u6BMwQpPKtsrgBZJyzKcperc1itZdx7AwJmE+/ 7sPucRUeG5z0TzzJDB47SQqMcVjCxzpphnNGdHlEJQcj/gMpI73xmDYw1D/FRpskGI10Agbz zkgdiDxuWapNkKERE93Ig5KxlSe6kY++lQJVZcaM8DxVSnQjD7ZzjehGPg6db0RXubW6843o Rh48ZnejQAzQOGw3rAX5lZzsjVhH45QTlUTiNEnI8W3DXYQlvF24q5ij20W7iim4TaiLqMS2 i3UVc2i7UFcxR7aLdBGXwHaBruIS1+WY9XHNseegrUfee6lollFhOS/iTLLYBC2hFLGYSRaj s66KmWSxU1qGKmayiAeNBb6IM8ni9mGaZ2PxIfetjfFaDgBgDGiOXmYGYZgpbIIqwWKgg7nY 6Vt86MyoGtmkatQxMLJm9MRUrMWMER/zWBl6xKglhiVfqgk+XaYbBbKoCmUEnNhCoGAJGG9o YTHN647pwTFMYcSFWPUdTkd0FZN6Iy/2OCk21SisGvCJEA6iYZGS55mGnDOEnsIS2Rkk5DKj 0SCTRqOMccjoOs7OKbKwIkyLMyoOeTSmDa73VrsqZAZrMKg+MIbLoCb3epTRROv8pGWMQdrQ mjQaeQzWYFh9U6nnsCZ/O5iTfprtS8PQqNdaVI3MYA1GFrI2Q7kIrU0VvcM6WYzSlsWQGC7X pmJSNTLDNdWLERjsBJJoEOZjh5EtqRldZ+LwV2Y0GmTSaJQxUrBh8WEkoGJRZJiOeXUyw4WS uwOWh8YCuw+RjZj0q7zYE8RDSm8oYjYDQoyKKdFDKqSJ4WVnEBXlrs8PkxXIoFEoIxDEQ4KP 8wwo47DEHTMFT+EDUQ6j1yqP+CszGg0yaTTKGIe2KCck16C1oWNkE1+qbmao7GoxqRqZwRqU wmPKG4JyDVsXGwabOJ37HA8Rco6zBSuUEViB0XVt/k6xjZP8JfWanETX7I3T7I1L2ZtcyHgu oYsRahlZP+QCVxhGms6iKmSGqbsKYwYMkLYlyTLDWUYzM7zn1mZwoTYWNi3UzKgKvoCbFcoI aWKIgUsNM6d/pgfOUqI1ty48q2jTGsBaCZEZjYbm9scaum1/1ocEph1ymJlR8psZ4G7Gzzta I9UkrbfMaDTIpNEoYySE4dSEA8NOIBDCxMBOagmyzNA+b2C8trK3iKkoEKMoZIOqUEdgkKGf ZEyXQY749D3qycRzp2OG5hxmk6qRGbrN4YEcJlxXcB7ChJEsRlkMEu14U8cWjUKiXfPICKJr i/gc5aFvC2wR8TG/VLrsvdigKmRGt7uCwDtGdBnitEp7zNFizMe2THKuFP0iz3STTGk/nc6y ZoSDrRsdHm+tFe/pXPu9aDdcS3uh6RZlunPAPbq0cOSWUGVwcKfFbz9TZQ/YozkoacXjNFIZ 7gVJgXsKxk+7RuOX7eYTjj54fAQ40mdvLx/20Gzcyy4DGoKlTd8Q2609FE+bWwi0e9NokIPX GupAwU79JHBfg9ZvckMxDEcqQWNe0jZEvNeqGtmpKw11qNt+xZVGpZs0XAI6tkvC5k22w8dv 5Nmja4zTLenBeYELG9e0iaZb0+1OZHF/MOncfUs90LKzApc2Dg87PVrVlON6GDFE6TCZ/knX t7O1+oTygU4IAbeX0PzjfKwn5Qc6wuEBA+FzC+ZPyQ+0W09HM41pMTd/St6h4MeU9gaxsFBl GhS6XrJQ4Weld1YTExABiihVLZjBjQSESfhpV456sDc12IUUpxigaULDWCwnXzXMoW5CFD9a 1HgBn+7hqRVBz6kkV4pnWx0oSrgO3JiviWyAxQy04bXsLVa4yuAS8DWGh2avocrWYcSgWO47 JuUtUZzcz7Q5LFzA+voiJeBdnwhWpcswHZqXKHzhm6pWe9072nztBTiVNyD5vQdsM/c3Wu3a 9wlLr1rCNVyII2bO1AV9pgvDNVzQJv039cGc6UO8ig8+XQNNfbBn+jBexYcxNYKpD+5MH7S6 hhPGhKU16c91Qj/XieiWvIDk9zMnAjoxnPbBXCUQo5PDzIXh3DjYa/hg4SwyznyI5/rgruID 7Dr0zIfxXB8urJNa430z1HwLh/JZoTw1+YUVUkeLW+OV2Q1EYDztw4UlEq/6g13zwZ3nw4Ul 0kKBjqtxCOf5cGGJtJCOejUO8SwfzIUV0oW0A1rxQZMPJ514doXsnfAWusSqD+Y8H55TIV1T pW/y5yDwB06p4kaLjhOhNCk8S6Y4TZ17u78xuz8fet/+Tx4Yg58ETD0Qp+LynKrtFhYpnAWi F2ZY6uPv8fEffv+4v3E7/J7lxu4+/2N/E3a/Iqf/2uA5gZm4gNeTesWFk8/PHeOMqxgf6AUD bJbzvWwc0pt6Yjxx2+LhOOvxZOHx65ZkqYhhkHGsGmosDNdr/EJfIPHnD3RAusbA/RjH5c2/ ubCredh1m4FuVOa99fbhEbc5nz/ihzVHaLN69+4Bl8vj3sNfWDE/7t3ur6n/vov4+336/e0p dMMM3fVbiQyvhrJLd1cZ3sx46t4hxTTQrRZERoTywdgUriW9xXhf2ERzvHEm/Ozm4nj/6fWp UMdZqNevHjjUQ5BtIhH91L1CXqvpzsY26x1fPgKjLu/KeCpvnjNOb7KWJhf2fIYNZvVfC9u3 hNvdj1hkT+Jm1eRLLSyijUchOHqVDodF+vILAmWH5FX68Ya+CsTW/BO0Y7vyBVkAbGM7TP7w bPbN1/8ApBTTQw0KZW5kc3RyZWFtDQplbmRvYmoNCjQ1IDAgb2JqDQo8PC9UeXBlL1BhZ2Uv UGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA2IDAgUi9GMiAxMSAwIFIvRjQg MzEgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMCAxMCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9J bWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVu dHMgNDYgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VS R0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxMz4+DQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI0NTE+Pg0Kc3RyZWFtDQp4nLVa244cNw59b6D/ QY/dAbqs+wUwDGTGWWODNTbrHmQfnEUQB7aT7MTJZjZwPj+kRKmorqqZGnfHD54WdUixeETq UiWefCWePn3y8vrvz4V89kxcPb8W/9tupJCDlFJpLYMIWgpnpfjt7Xbz78/Eh+1GifcNI6VX 0nagd59tN//absQXL6+FYAMoGuDqZrt58jclrB2kt+LmHVoEc0IJLc0QvbAuDi6Jm59xGBjr yYujgh932Hyx3bzeXd9+d3e3P5iduBbf7Pb/ETdfbjdfgF20XY0Zm4akubHssnFO3Hz/emeV X1CEniHGXjGr/LGkYNyQ/OJI2soFRSf1kOzMSN/slzTAN90N9XonGHYSdd1FXQujB9kH3ZoB xFEOJhaDT6WM4Vk/PhI2VQ1y0Np2yrur21/2bvfxxw/vr35/sze7N7dv7xYeRocw2NSriyVs dIN0PXaRep3sEAIHiwMwYq3J0XVyaRRj7IlHRMi7X/d+d7dIi4lmUGr5SSa0mJNkwNj6OV7A IR3WWLRkUQ5Bi4+QKoPTDtMFTP0kNkpZ7EgKcwKsWQiR8tS+3dZ+pR3oMQAJGMKlQXWIImCI pPEPQxTBiNDaD9YyBAkYwiNfHFEEDJHM4DtEEYwIo8OgOYIEDAFGY4coAkAct5uKglzLT9Mr NYwa/CkkN/Mw2Nli3nHQuseQ9xyMgBbxnoIR0ALeM9AAY7x7AkZAC3cf/xHQot2HvwHGYPfR HwEt1gtx7GJNfNRALrPhoCzEPIrT6FDrpmbrTpAQjChq1m6tI6ORWq3TeySk9VKzdhtpMZi1 uzZbt9WDGW3XZuuGmsGUS6t2WhUHw6JCzdbtPMa4dVOzdbMgspjW7iOtpxstE0tkfEISBEXz rAqwzJEgcDwwDI88zsvcXcCsu2kjnRrX/yi0khgORFVBonlTBbqQYHPacLzHXyRgCMCzbl2f dWO0xuhpn2iuV0HwNBGrIFqa20bnNOAqNqdLouyogKIxApoFHNiCKwhKvtbWIjCw3SmP2gQJ NxJZYIbgOxVkkdojgDQaYLSQYyzjECuNS7yCn1xQNMxgi0Ju+kgBavjWX9oNUJg1uUIUIpeY db4TFBWtyG414elpqsYIIAuePa6BXmgRn0sE+9gJSKVO5SbI9rnKiCBBRRSKHQqJ0SWK+zZp tAW3CmSbA0XDsVljWX9lGEKrIKl9YwwF3tAiUwVBD9R2Q6dQ8ocEIyDjWX/Vr7mLmQau1GQj QajziATKNAJzPeYqIU+KImCIosIQzUbhOC8r2mQSMh0kiLSiVUGZdLclJZFSppIwpCRgiKLC EM1G5hiWFIcLm6dHqIKyMb5lgkDBt06iL1zFZpKLgCGKCkM0G4XmkNf1wuoSzVhjmYBUPPFY 26rxTBoNQG3FSlfNs0LsPNMOH6WnPqukPlWlbVOBNBqA2rbjOR/CiNYlnn3XLhpWDr4okAWP NW9UGPuLfu2uFGPWFkaXKI7xRJBVLJaan0cBTKEYOxWOQEFD5EgXR+DMTQ/cBHWrVgUmF7Us MPkJmUoOBgkYoqgwRLNRZpcsq3utm1XQtpFNEOu+MgU0zFWyRRIwRFFhiGYj06zgCAjLZaJ5 Te3k6/qa2wZUiUPlcJpxhZRnVxGMCFIZEaONuiTn5bPuUapA1dA1QcA/WQD7utippFrileaI osIQzUYhGuvruCWf5dnpTlA0Ypm4tWnpeRq+9VPbsgdWKWFZGY8Ksxy77uxQVVzZMVNL0rLX 8K6ayy3JVkV8cNnoXKCXtjmjIGtEmrBNYCiETYUjgmeIyq+tbM7Tm+tVzzdqtLMrrbaRgtgU RkARNASMm6dYPnzrBCdx2HHjedwY8aocxL8UJ3uwud3RZNcy2Uvgzn0wCmw76XEEq8Rv79n+ Do5GtLjDEqfzYLpt4BDhIWaxrvbeM8QP2807NB8cPoiQnc/n2T2yPb2uliCKzs7s+iGNyRIU bMfjUzy8lKljCTjWFIgpLTXZ937biIQYvN3JcxBqGOsnjy5h51g2ggknlsfLUCojplQe4+ve ERdhSMlU2nqwmgHIoctY6uZ1sE7g7MaJraPuJjbfksxtFSZL+GR1PZaZZwRObxwCqjbN7Fxa lc/lJW/683/5wnk6XZfBx3JOxPySuWBMbN3bn2dLvvnQxraeTv2+/mM5pyEnWK3jjPp9/R0T LuXU18gHbCU4E92KMlfrT+vwpDxmIjzQWcoXzuhUiDDlLAt7l0TLFyyvOQtTyTEgE7OwCWYL yqdYOZYHAT0Fjht6MgN6KibKKOxxlglqsfgUxWMJFO5NcfGjXSPmAAgglCWSBotLa9dS8Al6 R8YDvhspW0W8Yod8hByqx37tx3ZL9MfrHWcukd34EshLAVnrYFUt96LsBVC9tM5XDfzKOga6 koP0aW9v6J0NxH9/UHLH34XMvSbyl3AhQg75OPFBrfQhXMIHBXOXv8UiH/RKH+JFfCg3gqc+ mJU+pIv4ACkFq8+pD3alD0pewgkNRdlOyXBrnVAXccJB9k3Z8Gud0BdxAnboYUpHWOuEuYQT eOECe9ZTJ+JaJ+xFnHAwnpk4kdY6cWaxVAo3g/g2wEzpeHDwM8uksvktwMLoCiKQHvbhzDKJ 7wOkW/JBr/PhzDKJVyUpLflg1vlwZpnULubPB+Z9sKt80GdWSdwKLobBrXPhzBqJ92MxLPng 1/lwZok0QQ9xMSnDOh/OrJAWNuFhMTXjOh/OLJB4CAlmyYe0zocz66ONdlCL5YFK1INOPKZO 2tGJA33dBP/gUCAOSnSSqOBYgseJhKflU99e7g9u989j79pf4gDeZExjIx4KymMKt50pFlHm g30+158O/mp/0Lvv/v92f7A7/DjrYHb/fbM/+N2vKOk/oXl8WFqiwvFYLXjw4OPXNWPFbZ1T eWh8CVZu65zJF10kuOcuzuErpJTfXpV3Ss7oIpD0TqkiZGgC3yN+KF/T1U96ytn5EoZ7G7fz h0F95rrm6j0KsDTdel/d/vJxfwi7Hz/gFMkfi8EkeYOT5Pbt3u3usPktIr7+Kn6LjVefP0Cs kRNil6+riFmVOK0q6XuvoXIg8U1JEl749rnjKUET0Fx4zZnrJYUXj1fTnfTjo/uP5w9FV0+i u3wFVaMb8vsnFuAiuO+GieamCn6o3OgikPSKh6bzKLgvTx5jp1dZSAtz5vpeeQtqkNPitZ64 z7++3tvy82Hu7Mn3hlg2mU/e0ztaeG66NhmcCdmv/ONF+aYVF+LvYfG1C99BerzK5mbo88nJ l4t/ApSMV58NCmVuZHN0cmVhbQ0KZW5kb2JqDQo0NyAwIG9iag0KPDwvVHlwZS9QYWdlL1Bh cmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNiAwIFIvRjIgMTEgMCBSL0Y0IDMx IDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTAgMTAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1h Z2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRz IDQ4IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC Pj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTQ+Pg0KZW5kb2JqDQo0OCAwIG9iag0KPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMzA2Pj4NCnN0cmVhbQ0KeJy1Wm2PHLcN/r7A/gd9 3A2wY73PDGAYqM9p0KBGY++h/WAXwTWwE7R3RWw3aH5+SYqSqHm53fNu/cE4UQ85XD4URWlG PftBPX/+7PXNn14p/eKFevnqRn3abrTSndbaWKt71Vutgtfq84ft5m/fqH9vN0b9XDBaR6N9 A/r4zXbzZrtR376+UUo8wPADXt5uN8/+aJT3nY5e3X5Ei2BOGWW164aofBi6MKrbB3wMPOvZ d0cDf3zB4Xfbzbvdzf3dly/7g9upG/V+50383Xr9fr//u7r9frv5Fh6AD8lWg4mdbay+2ymB nXlqG0+tcrbTraPedSAedOeGZPC51kP/on0+/si5aq87a32jvHv55vjpt7vPe2N2H1Z+hBnH rm+11ArU6tgNpsW+362BITjBSbA6ALPeO3X707td1KtPCbFzjUcgRpWPv+7j7ssqG077bnzk l8zYcJO8wZDGJTqc72x/jkXPFnXXW/VfyKou2ICZBab+qTbGRpwwxnUmKjAX0L7PgvttQUAK GysRSSAQfej0IBFJUBFIFmRIRbBAICDKYhpGYi723Sh9ZIFAjEM3Sh9ZUBHOjt0gfWSBQETd DdJHFgDiuN1k1GA7ek6rVDCui1MIDekxOFnj3RJQASXcbfwroES7DX8B1GC30a+AFGsR+TpV Qt3GvgJKpNvQF0ANdBv5CihxXolhE2fmIgdxnYl+5CBYqKJ5Dv+uEyOYGupcGpZp18cu1mke lmkfRgxEnuZhmZZ+VrfL9JGr+sb3PbLpgJLEchYY31EM8tjaLj239xgdqTCi3ywQCNIQgGwB Y+agADrkGnYHojcLPHGbR8F3PQs8pozED5Q5NBaApFEBxQI+1aIMQOBJz3ywYGDfs8DlLMNK 7QepYjXmFwsEwuVMzYhig5IEmDC4WHReCywYfF4sLBhtXl6DbvBAiM+CPJ3AYrpoH4nciKme uFzhFgtLHTOeUu1BCCzipEZFsCAjMruJy0VmwU8xwqkBE+Shjh0vwIKWABI4sUSRtGAzi2u0 DsNEgCpOs+FiI7DhrNIgyEaQ1WGgVoNZXKPVT8akAVGJWYMEJtct1pAAOZ+eSzXKRFtASQDp kfK9CMacLz2tFaniMBosEIikIhDFRop2yvcUsAexRMJkzTiHCBJ4SgGhMqCbLBCIpCIQxQbl lTVkGHpKSw5mQXTI970Q5E3AmREzSmg4spsEFRDzNpIBxUJaSBQBrCm16KHAWd4ss8DHzjZL qWgAf85mgUCQhgBkC5lm2lE1V7UFmg0mVss7qdi8L7IAfpAfGpWKSIKCyDRDWjCrazT3diIg lRzsInDd0GhIAAmc2BqAQlRKnK6RHCdj0ghpwyljw4mdFcS8nE4ME99M6BrDuI0JAatQ5X2o gtJgFJWK4K0wI4hkEAbsqwLyj3ywIAQE31cB/ADeGlLVFSpA4ZDHApA0KqBYyHUT3MAp70WJ w02kLYLal7oZseWrGhBKLl7eVwArVEC1QBQ7Q2W+59YmDetmn8ZYl9IathRXgXfEL43FfFIQ gGKBGB57tO/0wJshj9NWdl8F1nM++zFg4hWNoGnvTWMxnxQEoFjI9PpM5hq70U8EOO45yHns GrScjWVatDlM4zKv44Rlwod2/zSj5u4q4ev0KOYSoRp/sei+FihtG7qs0fNeUwSWi1BRqQgW WFGmkLRgZUOyRGttalgQUiVOtBVBboOyhgSUPio9mIoAnWLtCEdaP3o82Dqn3qYT7feq7bZm jdCsR5l1Dtijdw5O213QEa17oz7/TC0X+aZ524CnR3pK4H0Fp2HVcZGCDVTM/rLdfES7fUDv 4RyfHL3I4LE2bpCKaQXCrhpxieZDQQZYFNMY+mcxn/y6ip2jaOMN28F23Sz0+bBSI9MB2S3p YIeuY+ko6IX0TAU5oEWku6Ufic7dWIwVwA5dw06Tv70PCrMYE9gOViRw22wstQCzrXm2ax5T sjmFqYyPcJBlmMW4QzlsR3usehEN0n90mTnN0MfARLejA1mc21mdo6SlZW3hvG+WVB+bP+Jv DVgCcfeJC7/g0fmGgTDS8rbIA7QGkoFmr1iq5NNCOyt/RECEipLKEzzBj0wA24ZGuxxdRrAd oFPgJiJiTaiCpeLxdWaOpcM3I1RFn1eWxUwe8Y6SV5KNQiDW5NM1jylYms8PvE1BGcNbA9hZ Uj7DTjDUca5KX6F3TFxEbAcgf9JVnzZQO5xx6C2R5bFUVAE/76sUjwt3rqG+XqCLLaxIEeq4 cwHTqL5dyNe8dIkkL3nxApwusxx0G+XdAL8RgG5nfzB6p8W979JLiHglN4yB9J15Yc70or+W F95gGkzdsGe6MVzLjZ6SfuqGO9ON8Upu4Nsja2Zu+DPdMPpafsCSNP3Mj3CuH+ZafuARa56k 8Vw/7Ff4MfglR6A86nHmSI+O9Kf9cFeKB5ZGPedlODce/lp+QPHWc17Gc/24vJQaix1YhE3L zavHyedfXkOttnhkXHEgQBzG025cXkTtQJvWihsmuXHSj8urqAMPQlj1I5znx+Vl1MNhZ4hr ftjz4mEvL6PBOew21vw4Lx72iWXUi/J14G8b4B8cOtTBqEYCLY/GJszQVdPUv9f7Q9j95di6 9/9zIh0Hp06oU9F5YnH3C1mLP19Bn2nmj3+7P9jd3X8+7A9+p97v8FONf/1jf4i7X1HSfhzw xOhMnAj0omDZi5NByDvLGVcoIdJxks7c6T3mQFfHLHjkkiTgqTddTvOnAINJApvfkDLClFem fWgRv6TPavIHC+m8cw3DrY375d7dXr7zhRFiE8gTM+8EXr450tb3CbPjt32/u/uMCfQB24Mf 9373V5r9YcC/39Lfd6eoDTNq128XMrf8HQYTW94zLd8aUCgRZhSUzPLl05SiGWgxwJdvqTnA dDy7JL5/fnUqtP0stOvXBhxavBrib0xSdFnw2K0Ap6YZygcsKb3pVG9FNlfBY8vkKXZalbVV cfnGz6Thy009L1+nWPtDou3mR5w/Tds4+Y4KC6bwJUaPlZS+GEjfZQGvrid/6A/kFDYg3JF/ oq5k+fuuiC8TpRn+LGz2Rdb/AO1Pk1INCmVuZHN0cmVhbQ0KZW5kb2JqDQo0OSAwIG9iag0K PDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNiAwIFIv RjIgMTEgMCBSL0Y0IDMxIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTAgMTAgMCBSPj4vUHJvY1Nl dFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIw IDU0MF0gL0NvbnRlbnRzIDUwIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVu Y3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTU+Pg0KZW5kb2JqDQo1 MCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyNDE2Pj4NCnN0cmVhbQ0K eJy1Wt2PHLcNf19g/wc97gZYWd+jAQwDyTlNGsRo6j2kD3ZhuMY5QevLh69A8ueXFKmvnZm7 OY/rB+NEkRTFH0lR2hFPfhBPnz55cfXX50I9eya+en4lft/vlFBSKaWNUYMYjBLeKfHxZr/7 xxfil/1Oi58Kj1JBK9cxvf9iv/v7fie+fnElRLOA5gW+ut7vnvxFC+ekCk5cv0eNoE5oYZSV MQjno/SjuL7FZWCtJ9+cNfxxh8Nv9rtXh6sPb+/ujid7EFfi9cHp8Kdx6vXx+E9x/d1+9zUs gItkrV4HaTqtrw6i4Z1YajpLjbBGqt5QZyWQo5I2ksKnSsXhWb8+bnIqOihpjOuEDy/fvrv5 9tePRz0e7m7uFrYBaMjoe0GxyDvI0fa8rw9LzHaQoVMsTgCuc1Zcv3t1sGpxlWGQbuwEVRJ5 /9sxHO4WAbEmSDUu72QCiL0IHfRqmEPEOmmGNRoda1RyMOIPCCzpjcfgAlX/FjutHU5ohVpB mxuttHn8YV/mbejn07iZD6NUsWUgQuUwyvQcTGg4rL/gIELDEQDs0HIQoXJYpXoOJjQc1l5w EKHhCEFG13IQATjO+13mwuhGnl6o8GgZLlnSMC2Dk8XjHQJ1Oju8A6BOF3/3ABSG6u7e/5Wh eLt3f2Uozu69Xxiqr3vnV4bi6t73laF4esGLnacZjezGZSzATt6IT+rKNA3r9Bi7aRqWaai0 aG2e5mGdjqabpmGZtia5M0/zsE7TX2WahmXaqVE2O0+jOul1ccRtGdbpxk/VbWX6zIfLzoBJ sF8dRwYhE0YgpB3S2MDqwRHBSh86iZhHdZr5ebpKI2AGKiGYYSAQdCC3MWGUQyC3EsEFaYkA tbeXMDjDhMpAAg1D0YALW5ucZOBodCnqM6EEdSaANk8EM+IKrYiVZdwwkERlKBpwYecgLjA3 tKTaxmOtpEtuKYTIhjgINPBYI5FCh8bNPAk0DEXDmdGF7ROYs+BiQemwRqfBIqS0yMNmTBVo GUhBnk+LDmMqLQnMJXRh2w2BJFzqHm7LGA5qF1uBypA1ZA5CN+VmLVmz6MZuTBKYJY4kWIUn h7BAM08KeDpD61yGch5bKOrxAuwkYmTIEjhWkYO5SBQGGhcGwhbiDDJvcByZmRBzAS6EAd2Q CFq6TsIjKxMqAwk0DEUD4TtQhg9ZDROgnPuSjIngc9gMXqYyUEVGOo8KxMxBIg1H0ZEgNqmO mFEh8+2+EqCTLumYCNDk0Tit0EgAhAAPE1qOQYaOgTV0+RvZugKyl9q0CWy07PO3SnACR95P 5kgSDUPWkDE2GdF5iB2mRI85Sli067aMh4hyrUBlIELhyBBjyhKiSxCjlzpCErEI220l4LEV O5GWAwmFI0OMgUCIzkIMSarNBeZJJPDpUAgaV2pFCkcmZI4ulT37ZgZlTswW9iQCMdSmMmRu 7JO/MJTUrj1OLrO+BD8TAiRmU5j1YLMvAVZwbisxoJeY0HCQSMNRdNBRbFMhhaikPjAT8BJJ SzMBwoSXjjodeI2Ip1yOpSkiDhJpOIoOKtepETNwpUqA0Mhzh5vHwfJ+8LKDEZjZx4QfjJo5 Ym6mi3SC19ukcnQcf0yw0HRTj5AJjK1Psd3yl1GdtrrMsRwjyugtoImncDOGQcD8u80jwwFW eJtpImQOgjH1nYzaEoyxG7NErk+FkLvzLFEZaGyb/gJRwtrp+Z4yRXGghqtBNfHXbooJqQi1 EpWDCZkjQ2lDRm4eSoc35A7aJOG5LS0EXRpqkqgMNNa1ZTYY1un6bEa4S7vR4Y3aWvGSrtLf ib7Dmmt+Jk3JpF/A3lxauOlLrwIu4LT4+BMhn/IMDKdIgCCPffeGl0AocpbjykjTtHc/73fv UffgcRNCZXu3Kj3TaY3RA9XN1jpi0r5jzD0eciDg3BPAX6HhIPM+l6pz08xDonIsQfJi/5Yr VQHDyWByMxBNw8FGfSZVZ4Ib6z+kER8I6bmu7w6xTwhypLiEXdlmni36HHq6kB6cFxjYGNNQ DLqYbruOuW5gckZPTs4zBZ4VGNq4hFWGo1rROZW6sJCuz/hfeludRusyc4rCVJz4JJrounce 48Wk9gBbQyh5U/H75s/sYNyzRl9Mxe+b75DwY0p7g3iAZy+qSzlJ5sr8ZQGe1MWEQ4DdU+GC BeAIzdUlqQbfcEcRMX51gAIY8uUghoawVE8er+ZMW8H80VAoeW8hZRh0SkNJe0yoQsgF45Mk z42z0iwmNbTkFsYGDfxAV3nrGkKpBp8geCY00hNZQHI6YwastgaK6Uhw4XN5Hedc/wS588wz sK8/egQFFVYESE7rXfNrR35zBkWxf3KGOyA9q4Gvy28V/AsFZOXxNBxU8wY995tIeNT6YWZ5 rdDRl8trXF6rB9cftq8PwPKTe2uAWWlA3G4ANIJmCoBdacC43YARnyEv13cr19dqswHGGoz9 Swv8Wgv0dgsCnGrTKAxrLTDbLRij1BMDhrUG2O11ANsdKN+XJsR1hUC7zS6wcAaqKQjjWh88 rhb2Fmg4SIyA+wEcBNNa+NDKW6qgdpB9emlpDXsfHzZgSxnUo8Y7/IIBZp0BW8ogPvnbRQPs OgO2lEF8qYRWecEAt8oAs6UM4luSXww/v86ALVXQQt/jxyUDwjoDthRBB5fyEJYMGNYZ8Lgi eGEAXE6HRQPiOgO21EAXvYx2yYBxnQGrS6CrBpz4Oxj458COkxYdJep0XuANy027hBfHkz/8 7dzb9X9YHa4cU6eIh9yxui67maJAP0jRs+Plyi+PJ3N4+9+b48kdxOsDfsnzn38dT+HwG1L6 D0ce6ZD6jcmAzw7z6z+483wgrHjfwq+LQrpr0buntz69Co7tPX/m8crTD4cmf5Dg8Yk+ydHj CM+D9jy23fzP9KVV/oCFLptblXbyH+bvTGbLYeXtgM8zaIEep3Hx9h3ERDx8ixHxKwbJx7uj P9xgB4V/vME/nA7Ig598YVK/ObrDjz/E1OPg3y+/fAjccQLu8ksPo6t0Ay0M7nu/IZ/qMYog Qvki7hKnS545T9sthyJ7Ws82xp/D0d8/f8DRVk8cvfyQQ47W0fCPXORrHt/3TEMhq6H8j6aG vMYXUVNDvI7vyZv1Sjr+hTyxWw70jB4+ls/Uz0+E78sfE3pXb47DCvguv7rDQtqYGAL9xqTA B3z7lGB2MjP9gdiC+Xgcv4NWPCx8DRiGkLKqqOGPCCff7/0P223+Yg0KZW5kc3RyZWFtDQpl bmRvYmoNCjUxIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8 L0V4dEdTdGF0ZTw8L0dTNSA1IDAgUi9HUzEwIDEwIDAgUj4+L0ZvbnQ8PC9GMSA2IDAgUi9G MiAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4v TWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNTIgMCBSL0dyb3VwPDwvVHlwZS9H cm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50 cyAxNj4+DQplbmRvYmoNCjUyIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDg5NT4+DQpzdHJlYW0NCnicnVZNb9NAEL1Hyn+Y4xrBdr/XlqpKNIUKBAJEBIeKg5s6jZFr t7Hbqv+eGdsBb1KnEYcqtjsfb968mV04+grHx0efZx/OQJycwOnZDO6mEwGCCyGkUsKDVwKs EbDOppOfr6CcTo7Ov1u4rqcTCdd/jYVwUpjAevlqOvk2ncC7zzOAQSbZZzqdY6z3EozhwhmY LykihgMJyikuYzA25jaB+Q2luW4zS9GmFnA+nVywWRW9UaxcFPd13j1Gv2D+cTp5h7Ep/iag sZ4H8S4YDEx3MKoAowItAnxGc/wWW94HOxYi9idhaipty80LrpQZOrIPJYxAloKsA2M/Ziot Ny4wPRozVZ7LgSV1T8N8ccGQ2TEfZ7gOfFqHOru7zyKL9Gc1RJo1kZQsqyO5ebzCj/Dj61hL pOHOPwslHkNitOPuGSifzoC6/0hp0xoWRYap03XxtB2oawoXyjzbGKu58T2Dl1kUUyG2r2Yd GQbNKi3p921kHPsReTYDfF3gQ1Vi5Yo160ghhrwkZq7on5dpnRX4kpNjxkcqswqlGYcI9ipU H6JQqXns/0uiA082X2VUyFWOpC6jBP+UJT6QmqzEb4sMkHlDzN9UNRo08EC2dX5ZUM2QkxUs qEVFWtckF8feQlpejTW6h6Fi+Y+O0zHuEsNp9wTGe7kzO9ztKKLlTxnJY/sSf2NqGnq3c25Y syJhwk36u1oTQ80TVMuOG4f0ETGejU6MThRP7DAujYz08QtDg4OWyNCtG+BWt2saWMps2A29 KGwYypWUPhbRacWdORjIuMyUSLgJMFUlNKSTjqimw9auFAJVtzy1000SWtKsVWucygxW+C2/ RjfDaprXBnASFUuxxG5+OVU4X+U1VOXuYtgCJr3nYtO7VXp7S3HLusP2mKPicTnkJfQNXaDo sX2EqVrScrCb5aD/LQfZLgfRLQfDdrS/X00Sj0m3QXTYTsGG8FiFnnvnwh6wU6SwCPF/dsrQ k315QK5whyjc00WBNL2m9oxKXwmUfhDigNMCk/JEh07D4+IW1R6zCpM/5HRWdQfWJW3uYO/j x7t7RJcW/cx2CsX5GB4De/XkcWCor23texSh+9ailtsTZKy1Go8Lk4RhX4CgdSetl2Xgti5o UgXtdHgdsA5bwhMVd5czbrVvL4Ptw3nfHdfdK8ZuLc47vJMNwvTd2cH2B7LmPSsNCmVuZHN0 cmVhbQ0KZW5kb2JqDQo1MyAwIG9iag0KPDwvVGl0bGUoVlA4IHZzIEFWQyBCYXNlbGluZSkg L0F1dGhvcihwYykgL0NyZWF0aW9uRGF0ZShEOjIwMTMxMDE1MDIzNDAwKzExJzAwJykgL01v ZERhdGUoRDoyMDEzMTAxNTAyMzQwMCsxMScwMCcpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8A cwBvAGYAdACuACAAUABvAHcAZQByAFAAbwBpAG4AdACuACAAMgAwADEAMCkgL0NyZWF0b3Io /v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAx ADApID4+DQplbmRvYmoNCjU5IDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDUwMC9GaXJzdCA0 NzEwL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTU3Mz4+DQpzdHJlYW0NCnicnVzNju66 cdwH8DvoDQ7ZbP4BhhfOJoa9OLCzC7JwYCMxEMRB4IXz9qmixG/UksgRA9xzP84MWSS7urqb HGli3tyW/BbiltyW/ZZk8z5vSTcf05bC5qvf0JKAb6YtONlS3QK/KlvIYcN/6uuWZdNYthw3 rfhKtxjwVd5ixlcA8viqbiniqwKEshWPoXUrmBXfwcyFKG4rJW9FthoCem8VSAVrceya8YkJ SsISPbp4fAKwOnxi0orFivqtYgsC+Ip+QcJWIz6xE0zq1RETn4pvOgxUoGKsj0J0jIxYg3eA Th7/c5g7xbYANIBU0c7YmndALw4jgehL5CB8t3ARDlAVFi34acXmStnEKb7wDg0uC+PEB2wt 4LPQ5LKJtC4RjbZDhc1FuTUaH7AwIbaH74hHA8b2Ajya22OXEpX7B06kwcChJEEfD+4STSdA ziHRRmg0QOAUobXQudBsAYBVCIhJa8IoLDI4T0sGNCK/Ay9oBsIOg1eOgid4rhleEYSGVIdG Zh/6CjbHfiHAjzwICoEUBHxHlX3ofpxCMVcE6R47CYlkCOZKEX0UjSxsADBz70r3oy0jOhfS GQFYuIyIhVVsxYM4TOVJ6qbOx+bTcAH28XBbOgCYU3oR/6mQQ6CrEBD/VEg4BKKBksA/1eYc 8HrF5jxUoAqCPYylkaaDSjTm5i6bJu4LW9KEZXosRTOcwMPHNGumK6HBXVA4JbAPpij0QYhH K8j3kI9WrhkCio7uBp+KjpaHl0dHHUBG0ZNueFTkUHpVFN98Ew0uvlCUtCq8IQZaFcaCTCvd doP7cDiQFRM21Ue4jIe6YmxxAMiJVMJRwBJWCDnERPeDjbBjej0FTwqwpVjovfhxLLQG1Bcr PQ7mizVRCUCuldqA1B2sIQwuDusVbDLR9SAbNBBbBJpKQseH7pKAKwgJ4clxOAJKgIMI0FPA ogQmThqoLSArLCFYd4qUC/STsOiNpkmYAw0AJjgIhIhGG465chuOKTKHY+JUOBz/UoGDiDAO YlFQLRpK1QbGNTIoiGPwbs+IGrA5gRsjZmDxwtBIHYOqrC2sIoJGbBdaR4O7gBxyhNUF+8+J y4Ar55T5HeBkihXSyzkxQgCncBdQXGYUksAIC4YF/pErRjAk5prZBwHHMUJAX8XRhpivMG7R 3Qv9XZSRGXyKMgwHhhPEZIZThqcSGI0gtBLg+AIfKgpCEHvQgOwEXl60MhoBOSqHAznCPRGW ELkZV2DrkhLjE5Az41NkcAcGIhaCJS0GxZWChdNxS6E14IIIUZgU+io1cziiMUWN8IYGrQHQ yiAuMFalxAVMV3q3gJRKazEqVYGHC4RWwx4U0QA8v1uVkTgzztOYEFplgEW8RBoJDJNAjoXD gZwYSlumoXmZtTLjLpyg5sTgymTD4ZAeXIM/whSMUQKh1dqGM/9g30IdOkeFUNCOCUOY2pwj m1SXY+wVitIp991yTbN2yymxRW/+NDI3M7i5xPVQoi7Ra5kCXYaFAoOYy2S8trRa+D3iFYZs BhlMy3zP3Fc9gz/7caXBtQxW2a8lNYZiBk5P7QamTd/yBiOdZ9ALntmG4mm5wNMFAmOTJ1Zg TsMAjshsYUfBtxTI1MAQiGjPsZwj4v9BWupPTDecI2G9zPS+5erAlIboi5XSVoioQGmZNIO0 wPyE6EgUzlFY1TBuI+QRhXNU5hTMjQRLWzGVIBJhBQzQiDdMasxOTJzIamzRVoG5mREmtDRL l2WhhOzs2I8Jm2E3KPFCQ2GqVaIwEQojb2hpPBKFER76aXmSudBxLJETOWKGgsfnVpNhJcyV yjkqhBGYXOAC9I2W14nCmB2Y4wOTUWDKCpE/ZbwNLbdTyS1NB3pSiCyduMrAlIstEEVZFYAV pGi2uGZWjdga03YrDDBTy5ch0kuYPfA/9iNyopcwzSOjAy8ROdNLWr1RHBM7kQu9BAJGCwEJ nVlOsDTYCwvoLkDDqDW4I6YYhCKObUUGPAl1AlusBjILBiaTwNSojI2YiK1KlMqSAz7A/aGF 3ozWqEfghYHVlCptyuCOsMB6g3M0ZkqrE6DTwCJAGzOstrQxQ/1qY4bqVobsQD6UMTtQ51ro ESwytEKx9H20WFFRyVoLUVivOGqBWo2sgUOrWX1DYcnS6plWzjCtaitkGe5asRIZ2ZTqjlQE a2C0WMJQ3ZF9QquAGPOUOkeGZMXEeTPLPFamSOwoTah4xD9U+1RyLFiHUvGxwtNpL7RgHcYn yFL4PdZNjqUP1Z1Y2CrjQdprMFZMTOFKTSdpNZdjC1woNZ2oRKWmE31FqelELJVWkcEfqSBI HztUafUWFKatFsMC0WJ5lvATxhO0WGtR0yljHawT0OKOWs4utB81nZDI0OIczKdKJScmVKW6 E08mrQJEOCVKYYuFIpWcWeordZ5ZqKq24o82paYz83c7gWRmBtV2psAOdS8JaSvqPNPaSttn lvtKdWetrC85R6StqGnUw1hBKzBT4DmMc7BgYEpG0IONaSW0WAdT57k4onCOgtnbYSLz7KL0 g9y4pLozVaZUd3G+lbNsEYWaLjwEURloEaUVmSw8lTovrGSU6i7SSmEWpYyELIDQYilOdZdE 5HZ4SvRJqrswZivVXXg6VKq7FHiX5laksqJuRW7lCqj4Uum7udWy3EdupStYViq5ModqaadZ YYHNMraV9dRvZcGo1Hll2cMjIVq0cytlGfW1neUYH1qxX+m3Sv1W7lBrq4YdD7+cI9InqfMa 8X+lkmvijqhzFAsc26pl4VjOkXlqaKV08UThHAWMRuq3Vug5Ut21wqfo52ixZmet46iyVkI6 B0vgYMAaGyqLLE8djyqRNZprlTdPno41XWylM+uQ2KpyZqrYDqiMm4zliJewVWRB5OgD0bfK HL2ZndCCZ/LchhaLe1YaqMLYj8iJhwuWzC43FM5LlcVWxBei8NTqqLLIotRRZZElkaPKcGZh izcJ0kp6T9uzgqfKeFxHdc+4wcLYM4/x9IXsC84j61aGYLQ8S31YJ7J28mQGZx+2eHrhEcMz ZrfaDkIHSiv8qZkYiJdpU1ainjGbkUXacZ/HbaGzba3M9W3NrKdIHFrKwwL2FXmwEca/Vt0L y21aDi3oKCoPA+0AxXJVWJoze6LFs13k4YH1B3MNWvC1yDJbGP+4F7TwdeTxRch8jK1CJAus 71FZE4VzsPSOLEpRMwCFBzBh8c2zHVqJZznOwfKbh3C0aFOW1cICnNUWzi+0VeIcLMHbQQrl B1EKW4kHQc8zDG3VjiyM8r/85Y+fvERy2+9//OHHH/77j//14+e/b6F9/dvN/epXv/iH1gWL 2rv8k//x23/Z/L9un36fPh+Yf/7z3//2b3/9OztiW/jey95P3VI4uv0knLyeV4fzat/sf/7l T39m38ibtt8fW+Q1W/sIIwAwYK1V7tYqT9YqzzDnVdevSW3vLEfv3/36r3/635MpLt187/Yb 9slhiKdXvPAGLw7x0hVP3+DlIV654sU3eEP7FXfFSy/wih+u74PX5t19ZjfqYYtjC8fMbz0g D2d87P3U8e7gaV/Q7pXH0nmTO7JVl1x3cPE3Dy+db+Phe8c70GnJ5UT5pXu9cSTPsNWQVP0Y 8aaa8AoxjBHjFVGf+6lFTGPEPPD0bxDLGLFeEdMbRN65jiB5q3zBzO8wZYIZrpjlHaYOMb+I bDZqZB0WPszSt9KnHyztRnN94zisuseYN6K9ewc6proUs99d2bvXH2bre+nzvxdqnWylr7Al Zf9e/Tx8jVDvcavsO9hjzbHXPvnzwnx300/oupcyLMCfYlcYQJnlnxLgbcAtZcmg48cRdn59 HYPKLSaGd6DiJ6C3sKgvQcNk+58KYN/Uwda+gT7niqnzZAOdwZ/nePkGVcYE3v2Pv/tri/eH lPY99vkHa7sW0/uU1gWlC8i6YBxAnXcQzgq6DAi3iCqDjmKJDToBvcXC8BI0TUBvwVBfgpYJ 6C3xxXegOrGp3jJfegkqk5V+QPdNhd2vwhGqd+v0DfU1rDjJZG41J6q8gKpjL3kQjxybkGMT 4ci7GiZru56tdhArHn08Xe09H6DMDs6h9jIgjo5Yt472kMBfc49BR+esb0HjBHR02PoWNE9A zYnmsEbfQJ9zwdTRT+bqDJr4/Qp1TOCDC+oRr/VIRvFIRrGM1/a56fi4YL274OdWwrpgHUCd d3C+mbgNuEVFGXRMlthUJqDREJvyi64/z576aleHpc83GNeBnzPzz7PLvkE/n4pvqDLiK546 mYIhfYNkpo6TqdMZNa+gTkjIRhxlBXVi/GKMXxdQy8T4Rc6on/PMK9gwgTV0+YG8nmEnfBXD lx9o6xl2QlgxhPmBbJ5hJ4xVw5gf6OURtk4oq5ayuAI7oaxaylYkVieUVUvZisbqhLJqKVsR WR1Txl/wnmEXVCZuTJk4Q5ksqEzcmDJxhjJZUJm4MWXiDGWyoDJxY8rEGcpkQWXiJpR5Q5ks qEz8hDJvKVtQGZ+M+z7ZnQcsaE2+E9AtiUo5bSqbTa24t58UKOPJw1fJJWKICiveKv+v8iHI aXJzZgorziezeq/v6R//44//87c9wh1HweN3CUeN0auCnsd75u2psue2nox69ujhvsfnHlB7 BOwhq8eYHhS6irvsuk66Y7enNffPeHwe/XcfaQ9ots/j/kfkGCdj734o4NNxZkyHVdJxQD5+ h3FY/FmCcj1LhvtdIJ/2dPdCPoQBlCH2FFWuA77uAi6F/K2jPaFJCBNQc0KT8xl/2PVcyL/a 1XFKl/ON0A3dHBN0BT1NUPOIr3jqZG6e0zdI56nPdzzXAZ87nnMh/w51QoK9aCkrqBPjqzF+ XUGdGF9NaO+F/DvYMoF9/EXBK9g44SsavvxIW4+wE8KiIcwPZPMMO2EsGsb8QC/PsBPKoqUs rsBOKIuWshWJpQllyVK2orE0ocw+HuJXRJYmlNmLEL+isjShLNkCakVlaUJZMpTJisryhLJs KJMVleUJZdk+0bOisjyhLBvKZEVleUJZtpStqCxPKMuWshWVlQllz+tYAV/NzVK/etlrm7Di 3udrm/eTB3+a3BAVVry1TIiaTB6+etm7mrDifOe7mmEN9TkfSDjq8eNXQ0fp0ouNXh70hN4z cE+ZPcf1pNSzSA/7PU73wNojYQ9dPdb04NDV3OXX9dIdvL2Ds38e9X85+h/nFjnOLQd97V2b 9lnHXn4/J4gcKNKtc5w6jl+oHZZ/NnK9ngDD/Re28nnux54T4gDKEHyOLtcBt99YyqDj5+GC 3+zachPQz28R9vnri67mnPBqV7ulw/ne6jIwuKFl9dTp6Xf5Q6TTEsL5Euo2wFxCpRXUPEE1 d1B5BXVMQrBXUGUB1U+Mb2+g6gpqmKDaa163Ajuhy9tr3md5DWAnfHl7zfusrQHshDB7FeWf ZfMMKxPGxDD2OSe8gp1QZh+W8SsKkwllYilbkZhMKBNL2YrGZEKZvRDxKyILE8qCpWxFZWFC WbA38ysqC7Og+Hgzu9D3OwHd4ryE06Zsybvi3jrOdrPJv+6Ngtr7+BVv1QlRk8nzaXJ7NFlx Pp0VD33ApzoM+697elLtabAnrp5qenLo4bzH3x4we4TrIanHkC76rtIuq66D7rjtLdv9Mx+f vf9e3YWjaj1oaW/R7p8T77VXVPKstcdiJZgrqu8eXJJ6lKjH48NHkdQJ6gsZLLI7+cch7g8w hc+TRraYzAOo807OzxpdB9wfC5JBx88TIXsxeX4s6Nb38wDT3jW96GqKyVe72i0dzL3UFX1o 2VMxaW+Z4jdI5yWYS6bLAHvJlFZQdYJqokJeQZ2QYK+YygrqxPj2hqkuoJoLpssAe8H0KSZf wU7oshdMfiCvZ9gJX/aCyY+09Qg7IcxeMPmBbJ5hJ4zZC6ZPMfkGtkwoK5ayFYWVCWXFUrYi sTKhrFjKVjRWJpTZqya/IrIyoaxYylZUVieUVXuNu6KyOqGs2mvcFZXVCWVPA2RBa/KdgG7p Q075wz4XJCvuba5Z3k+ePr3UWaIWvFXdhKjJ5OU0uT1yLDifmnuYUbr/qlGP92yPXN2za8+H PYP1nNOzRA/rPQ73wNkjXQ9NPZZ08Xe1dnl1PXQHbn/NY/88atZe7h03XPzbHfunPz7D8Tn2 YrXXT2GguadaSM3903dPOIfjieajpOw1WCeqL2SwyO7sH8e4P+msn7dobK1aB1DnnfizU14G +NtLJTLoaF/+U58moJ/XX/au8UVXU6u+2tVuYTX3Tlf0oWW/Yo3aW6T4DdJ5CeYS6TLAXiKl FdQwQTXRIa+gTkiwV0hlBXVifHuDVFdQ6xj1coHkFmDDhK7LBdJAXs+wE77sBZIfaesRdkJY sHd+A9k8w04YC/bOT1dgJ5SppWxFYTqhzF4l+RWJ6YQytZStaEwnlKmlbEVkOqFMLWUrKtMJ ZdFQJisqixPKor39W1FZnFBmLzxkRWVxQlk0lMmKyuKbpGQe3lro+52AbsnuXNym5+L2zabS rI4YT34qbtNzcftq8lkRMZz89OCy2huZsOJ85kpmVJx8Kms9nrk9KoteC/Ts3fNtz5A9p/Uk 1LNGD/M9LvdA2iNfD1U9tvRg0NXb5db10R26/S2z/fNY53ESOHyj/eWy/fMYd7xUpmni1U81 WnhW4r18VnesxB8r8McKjntwTZNY9XmdrbOv9z+Top+7KFM+qx9Anck/30XdBnx+xX8pn28d 7YuCer4yuvU1Lwrq+R21Yddz+fxuVwen53fVrgPL0LKn8tm+eha/QTov4fzm2W3A04uC71Dj BPXpRcF3qBMS7HtnZQV1Ynz7KFNdQD0/yXRDfXxR8B3shK7LW2cDeT3DTvi6vHU20NYz7ISw y1tnA9k8w44Z458fPMPqe9joxpRF+9aZX1BYdGPKor1o8gsSi25MWbQ3Ln5BY9GNKYv2iR+/ ILLoJpTZR378gsqin1B2eetsQWXRTyizD/3Igsqin0XFhwGyoDX5TkC39HG66o3ePo6w4t7i XmzqPvlXNRztLY2seKvMstd48nKa3D6OsOJ8ksaTf9L9V0F6XMkeubpn154PewbrOadniR7W exzugbNHuh6aeizp4u9q7fLqeugO3P4k6v6Zj8/efy8D436x1ulpf/J0/5x48VOVE56V91CA HpfbR53YC6tu/fbHVIeylOvxQ+8vuMXPC2a2AA0DqDPZ4XTuug64/1EgGXS097fx/AbYra+5 v43nm6hhV1OAvtrVwen5QuqGPrTsKYDY66X4DdJ5CefbpesAfbq/fYcaJqhP97fvUCck6NP9 7TvUifHt1VJdQa1jVHuz9ClA38DGCV3x8f72HeyEr/h4f/sOdkJYfLy/fQc7Ycz+OZ9PAfoK dkJZspStKCxNKEuP97fvYCeUpcf723ewE8rS4/3tO9gJZclStqKyNKHM/okfWVFZfqTs/wAN GKTbDQplbmRzdHJlYW0NCmVuZG9iag0KNTc0IDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDIz OC9GaXJzdCAyMTQyL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzc0ND4+DQpzdHJlYW0N CnicnVtNr+W2Dd0HyH/wPxiLor6AIIt20yKDYJDJLugibQZtgTYTTCdA8u97KB/eZ713rXeV xYs9viQl8fBQMs2kErd9S0W2WHFJWy245C3EgGvZAh6l0jYJEde6ScLzum9xh1aFlqnVsEXo pBo3FcjXtGmGfNUt7ZA3mWTyZSsN9mveaoSc1K2aTG1by7KlJltrDdewhT1CsGEiO6RTS1sI Yk8UNwU2YSdIgHKLuLFZQTPEvW4ZQ4aoCTc7bjDJvENGsaK8C26yycBgCgU3MJiS4gYGTTDv GDTrjhsYzJhbhtFQJG85wHKBR3KA5QqXZPyFirnnAMsNA+YAy02hhcmFhiVnDCN7NPWMm4Kx gjlUTB0eDRkTk7CJwGqWHTeKGeJnEawyi2wS4a4M10qEv7LoJorHGR4RLaYOywnzzQLLKZm6 YQX/ZSxbsnkjwnIGRDnCcolQx5+UgkFhXSomlSMs14RB4X1pu6nDclMMGmG5NVOvQN+cqYB9 RyyYs2LAUrIiIEKGusYtSjAZxU3C6JpxY+qYSoxdvVj0mHrbonZ1WNaEQREsMQGinGAwwVgG wNHiLDXI2FIyMIvNlpwwVlMLK/zUbMkwod3PqW0abBrwiAYDBWGpQAU3gliN9iTgxtySddNo KOcdN9mewI4CkIyIUTW3YG2qiMEMr2mfWMYQRogMCqm5PwMPNdWMGQAcrAIc04KlZJBEK8Iz I4a0wpEZlNJqQQKuaQPCGba02eTBOrAHWojgtFuQ2Pp3hHk20gQLEsw7If5wA5KIBUk1XmHA DG+kaEFijI5YU26goJrHENNJ4bEMwiU1j4FxKQH8jLUl43EGVMmiMuPnZMvNzTKB8av1TGHq livwOBtpK6AuPStg5GK0b4ivAkaBqztujIe7/WRkg3qx8NqhXgzpgKgsu7GlmpaFspiWhbLF c+4RDK0OJ6KpGFssxWQLLwvqYoS030vo3sdY3fvwTTEULecUi/JaTN1WYkMcizR1m9NuT2wq NkOxycElBYwrlhKL2AyqyZhR0wDk+If9C+OBGPgP5CLgxr/wB2cXm5xG+x1PEQr2+4aIgFU4 vcDRuIEtSzAFjCvGiYLoLObsYpr9MRhXChAuYFyp0q3ipphV/DW4pIBfwASqhkcDRBhwq7t5 DH91h8cKrNfucPioWjot4FftDgf1qjm8gFa1OxwrqZZOC/xco3kD1KtqS4GPqlZTh+UE1xYM XFM2dVi2VIo14QaqBSFYLawKfF37fLHsWsyZoF6t5kigDDaYDAw2cy9s1dbVMVbr6tgtdlPH vJvlH0thzfJPgSOa5Z8C/gDbZG7DjTkJTGjSTCtvLRncgKHZXlHAsWYpB67dWocRS2o2F5tc q4YpnN6qYQr3tdq617FZGWgIL7jZtLBf7LuYULU7G6RvZcHcCPbhzoIS9MKdzQWhHnYxsGwX 2233Ks2edX/b9rubw+HvAACNmrixJJRsgGqBbzIV8632U4Nbgm1JffsMWArubGCEAPJgsg3N JLD5YHOxZ1otrfdNFT6LCIMgmBuSJLQggqSGP2ywavu4PSs2IbMZd0shCAFEkgWD7XfRzgyl 2E5cMeuvvnrzrh8u9u27N+/fvHvzzQ/Y7/62vXn3T6RYe/r1119+cUghyA+p7z/89vnvH38z 2dRPJ989riCyIBtfkX3/y48/Pwm8+QZ77ZNUqcOi0sqi2gOLejl4fpIC3ufBy8LgVf7Q4PU0 uA6Dt5XB0/Xg4gp//tePnz538dgdZZsWr8Kr8pp5rcc1US5RLlEuUS5RLlMuUy5TLlMuU65Q rlCuJF4ph1g/rpSvlD/g6efh46rXy6757M24v+KcwZvl2qxj9P4///7pQ5cWOjNycpGTiz75 PJnki8BIDIz9Sah5UP4l2IBO83Rh6rySdg7KZwotUeHtnz7+9HsPuQtBX/Pbvx5G88RodNlD ND0gegC0siqGVSsT65eefco19h5zmkJ6xdJpCra9XQ1t70Inq3nFapxYHbJDWbF6DYIdJE5W 64rVa+fbe93Jalux2q6thgGtsC+YDRO4wgBXuKDXfbMTvMKAV7ji1l2zE8DCAFi4oM19sxPE woBY0BWzE8hkhGyFYTKBTEbIVigmE8hkhGyFYzKBTEbIVkgmE8hkhGyFZTKBLA6QyQrL4gSy eP+s+pDZCWRxPDOtsCxOIIsDZLLCsjiBLA6QyQrL4gQyHSFbYZleQ3ZXQRa4Jq8R6MXWfDoN Z03DolbCW2cHlMvB434afAAqrkSrXgM1G1yeBk/DS0hcCb40Oe/djlJP7wHtOLryHOQnFz9r +OnA93PfgX3L9D3ONyXfRTzte572xOqZ0FOX5xpPDs5mp5/zxQO8l0GPa+SV8sdSe+XzuFKP 7y306H3ypPEYesHJe+fQnPTS7J33hMr3hMb3hMb3hOaTnaS55GS4BU5h4JyCNvkcx/eEcmFq WMk5aJ8pZM/cL94Tngt63B7vCVYSvjbqKevtISoPiA7vCY+s6phQL0BfW7/07Ok9IZfzFNIr loYp1MnQ7Ww1L1g93p/vK5Qhe5QVqxMQysCSumJ14vwy5Pi2YjVPrA5o3d4THjI7gasMcIUL et01Wyd4jSWncMWtu2YngNUBsHBBm/tmJ4jVAbHbe8JDZieQ1RGyFYbVCWR1hGyFYm0CWRsh W+FYm0A2FkTCCsnaBLI2QrbCsjaBrA2QyQrL2iwp3lGQBa7JawR6kecl3qTKWLqRhfAu+2y3 ux48nQYfT7wL0Vr2CVCTwctp8PHVZCH4yj45PNz25duhM7MYzE3Vt0HfuHyr8c3B07nnX0+Y nuE8JXkOcdI7S51WzgMP3P5t1a72afW4Bl6FV+U18Vp4vY7eMpao5IJr9w4rZShRjQovD5OZ lXee+fyQ5AD5RC4m6UF+C4jGgNhPQj7H8TDZLkwNKzkH43MFz8gvDpPPBT0ej8NkkX1i1FPR 22P89oDocJh8aFWHp8tQl3qmKJee1ZPQULJIr1g6T2EoMj1XGCoWecVqmVgdskJZsToBYSwx 1QWrceL8scLUVqzGidWxJrivmJ3ANRaYwgW97pud4DUWmMIFt+6bnQA2FpjCBW3umtUJYjqW cXXF7AQyHSFbYZhOINMRshWK6QSysdQUVjimE8jSCNkKydIEsjRCtsKyNIEsjWXcFZalCWRp LOOusCxNIEvjWWmFZWkC2VjokBWW5Qlk+f6Z9iGzE8juKcgC1+Q1Ar3YQ8/H1bEiIyvhPZRk Hh+8PUmVsSK1Eq3lD50eYjgNPtYrV4JvKMVcnXluB/VyfCrzA4sfMfxQ4Nu4b7y+Vfre5puR 7x6e7j0/e0L1DOgpy3OMJwVnsdPOeeKB3ZvcjivPvnzBYIz0vrZ+ZddJYddJKZPoHitTceWg WK6Pvy8P8iXQycEP7py0+CQn6e1W6PKA4ZeD4SBfPViHg/whecfUeSX1FKzPFW7NSs8P8i8E bx0hx0H+3Kr0QjY/NxofNFomRutzo/qg0XZttO3PjabHjLaZT2+V9mN8xnVlPFfG/7k09RiO cbKQe80qD1lt11bvxDlbuRiOvlYf/46V73//5cOb958//fqPz99/+vDhu48fP7959+OnDz/3 f258hzbH+6twv7AqEI7XaRyBj18DPxEFJg853qU2Ocbf4sGtTfmpS71FTbyLy7/SOE+dn7fI u83tWzjpmw+/4yzHpXz763//98NmHdzHHDZmJtlYu4i9ubSP25tL+4i9ubSP2ZtL+2i9ubQv szeX2l3rzaXd7t67S4/l9/bSwwO9v7Tfxt5gevijd5j229RbTA/v9B7TviCbu/VUHlNgLYUb iP3iZRwmV6YxeodJ7PiNBRuvVpsyQ5slG1ZqWKg5io4bP4uFnRNmWSawLBP4bTIQsOAVDzMf iE5gVg1HScD+xxZeGSX+Rt2V6Npw8xZH4n4WuJ8FdRdyED15JajHG0dMHIlxE25Obyclujdk h4Ej0bmBpbFALwe6OdDPgY4O9HRwEjC8Av0cWBoLdHigxwNLY4GlscDSmLAkJkdtcxOWwoSl MNkpR7IJg1gYTkL3C78PC2soQjiEcAg3O5GTJ4XMFfZXCvsqhbAIYRHCIoRFCIvwmCFERHjM EB4zhMcM4TFDmEeELBXPFOSeEBxh4AtBEmYKId+kUI7NrMLMJ8x8QpCEGVAIlhAsYbqX6npc v+8c3TlETkiWSJZEIhaJWCRikYhFIhaJWCRikUhFHj8iEYpEKJIwkWkzkiuR4EQ2v0aCFCPl CFKMlCdYkWBFpR6/6EeCFgla1Pq06EjkIjkVyaVIxCIRi0QsErFIxCIRi0QsErFIxCIRi0Qs ErFIpCKzViRCkQhF5tToewkzcyStooNEesXme83Oq/DKPYCgqbdY2uKVyClTm5JTSsSUiCkR UyKmREyJmBIxJWJKxJSIKZFS9ogrEVIipNxIlZuT+sbJTUgJjjLhKUFSgqSJ8gRLCZZm6nEf V4KmBE3zKWEqE6ISOS2+a9M4OabklpJbykSo5JQyESrppERMiZQSqURaJSKUiFAirRLBSaRV Iq0SaZUIViJYiYkwiZ8yqEfQEl+5EnNgklMkPDWcs3ueHEtE7qm7n0aJXCJyicglIpeIXCJy icglIpeIWOIulYhUIlKJp5nE3SoRHP4/JpPufsrfuvu5nlt3P/XqefG3LhoKk1vsBT+1NPHE QsTYBO1ty95o7J3B3srrvbfeLOvdrd6O6v2j3vDpHZreUuk9kN606F2G3hbofXzeeDdpaeLx 6tbSRL1bSxP10vlIdjsKU5hIsQHm9OmNh1kmQnZ+eK+Gd1d4O4T3L3jDgXcI+Cd9/wbvH839 K7d/lvbvyP7hd/LpjafI26c3vvncPr1RL5y2wqc3aC9P0CgReypj8Gwq/obtJ1fKETGW7b3O 7oVxr2R76dlrxV7c9Wqsl0+93ukFSq8oegnQa3ZeZJuUMbzs4WUM6t3KGNTzukN3yu11i8Lk El+U/d3WX0efXua+/OL/f11Cwg0KZW5kc3RyZWFtDQplbmRvYmoNCjc5NCAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MzE+Pg0Kc3RyZWFtDQp4nH2Ty26DMBBF93yF l+2igrExTqQIqSVByqIPNe0HEHBSpMYghyzy9zVz6SuLIIF0NA/fO2biYr1cu3YQ8Yvv6o0d xK51jbfH7uRrK7Z237qIjGjaepiIv/Wh6qM4FG/Ox8Ee1m7XRYuFiF9D8Dj4s7i5b7qtvY3i Z99Y37q9uHkvNoE3p77/tAfrBpFEeS4auwuNHqv+qTpYEXPZ3boJ8XY434Wa34y3c2+FZCaI qbvGHvuqtr5yexstkvDkYlGGJ4+say7ipFC23dUfled0FdKTRCb5SCSZUgUqQJpJGpABlaA5 k1qBCqY0BS1BD6CSSaOLxnkadRrnZajTKZOBMp2NRAmUZcS2Jv307ebbPSUsiyhBtpyyEZ9f mCe6RxofSAQxGdslOQPheD01NKCpbgZagngUlGEwGY+CTAZagabM8rqJGU+MZhi/oX8mzKWJ OaQZniHNIc3A0oMGwVKB2RsWqjRisgDBrlyBRgUydLsqVOH6lC6RXfwTShdClUmRpq43NWhq MMdwDX+bjr/0uHk/+1KfvA+rwuvJOzJuR+vszwb3XT9Wje8XXrAOPw0KZW5kc3RyZWFtDQpl bmRvYmoNCjc5NSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5NDQ4OS9M ZW5ndGgxIDE5ODgzMj4+DQpzdHJlYW0NCnic7HsHeFNHuvaMjppVLMmW3GRbsoUL2GA6pgQL XKgGXAS2wWBj00I3vYZUEhOSbCCFVNILJMgiBBNSSEJ6z5KyyaZtyrIJELIpm0Bs/+/oO2MM KT/5/3vv3n0ej/2e951vyplvzsycT1gwzhhz4aJlEwrKRo14bXX3SUxzbAhjCUsLhxeUP3aj dyNjxzYwFvdJ4fCx+Q1ry9IY+8LImHHliILCor8//R1jmi/HMqYcGzFhfNmc+sEXMG6oZ/wm y4iywHBF6foT09yxiLGi98aX5fT+6a/vfM8Yfxd3rambX7to7LzyFsYyl2IAPeuWL/UGbzz4 JmOVrzOmS5y5aNb8H34otjCWfSdjEQmzapcsYonMx9jnP6K9fda8VTN/jLhiPmNTjzA2tmH2 jNr6Ix/2/hj9T0F5/9kwWB8w5CK/Ffkus+cvXZl0XdJjGDBs6YPmzmhYMPeOxc2MvRBkLPLw vIV1tSsqZ7kZ21HDWPK4+bUrF6X06/IV2qMO8y6onT8j/v7Faxh793rGrEMXLVyytM3NLsF4 hD/eRQ0zFs3dpWllrN8B3M7OxNzqmkuHbno3eZptyPcsHtOGtP+rtS8Lfum93ReePNGyKeKI 4WFkI5iGUUI7PWtl/KBp+8kTJ7ZHHAn31CEp/xIWWzqrYTo2iiloaWc5bAZjjqvC9+VM0Wbx q1Bq1G3T9UGXycTK6+wSDTMyjU2n0Wi0ikb7MdO0+dnONrovY8VlXi/zw50kGoPhFk26l/Fb w/fdq4sUnqL3yFOj4a/h6d0mnssfS9oqtlNbwGp/tewI23max4dPz/9WUh5gO3UWNvkX/f18 qr1Ge3Z9hetuZoZw+0xqo1T/elv9O7/dp24sqzvb+4XvlUp96aazOm3FGfPwABvxa22UL5jt tHumsvvP+n6NLNWQzM75I2PsTJ1JJOUtNuWPttH2ZduU6azqLOvWnHa/k6z6bNppFrO0Pzqu /8mkHGT9zqaemCup+dvs4j9yD/5l21vt97vjtH62/Vp9fT3b1vF+vxhL7tk9s/b6al/iGWpe PL1fJYWVnE0fmgdZyh+55/9Pwji3nm1d5WaWqmv+5TNUVrCuyq0s9b92ZJ2pM3WmztSZ/tOS 5kZuOtu6vI1103RhI4H9Gh27rqNdaqWSXQpk/dFxKLFnfoZUx7eEFYbLf2774Vfb/dz202n1 57OLgdV/9P5/JCn92Kb/zv7/JxM+J89VufTfPI6RwINAAzAL6AnMEOMD6sT4/t1j7EydqTN1 ps7UmTpTZ+pMnakzdabO1Jk6U2fqTJ2pM3WmzvQfnxQVifRXCd4TOSglkWm5k4lvmHmZNlzT ylJZVzaYFbNJbBpbxbazB7x2b7Q33pvU1qbW8LJMls2GsfGoUduhRiJq8Lbv0e9E9bZuxtrq NM98Ov3T2k+Hfzpc/ZtIIpDMhrBy8PQzR6qMVq5TAkqDUqHMU44oR5VjytfKceUb5Z/Kt8p3 yvfKJPSuZQ4WxeLQUzrLwFhy2CD0N5QVsDEYdyWrYlNZPZvNlrClXMNt3M4TeDLP5BN4Fa/m c/g8vpAv48v5On4Z38Qv51fxG/gefoA/yZ/lzzE9PxIeyze/+BsOZxr1W4Ma9vuJn/Kmg3Pr lfPC/H/z71T6bU/ZL309YypXYxh/3Pv/7UnpIOGxMlWZhusvvoF4lqlz/f9iBfhH1E+bWj1l clVlRaC8rLRkwvhxxWPHjB41ckRRYUH+8GH+vKHnDBk8aGDugP79cnp0z85MT+viS/XEOR12 m9VsijAa9DqtouEsu9BXVOMNptcEtem+kSO7i7yvFobaDoaaoBemotPrBL014Wre02v6UXPm GTX9VNPfXpPbvUPYkO7Z3kKfN/hKgc/bzKtKKqA3F/gqvcGjYV0c1tr0cMaKTEoKWngL42YX eIO8xlsYLFo+u7GwpgD9NZlN+b78Gabu2azJZIY0QwUzfYuaeOZQHhaazMJBTRpmtIrbBpW0 wtr64ISSisICd0pKZdjG8sN9BfX5QUO4L+8cMWa2yduUfaDx8mY7m16TZan31ddOqQgqtWjU qBQ2Nm4MOrKCXX0Fwa6rP4uDyzOC2b6CwmCWD52NKW2/AQ/q0uw+b+P3DIP3HT1yuqVWtejT 7N8zIYWL7dOEcqkZxoYRwr+UFDGWTc1+Nh2Z4IaSCsp72XR3iPlzsiqDmhpRckCWuAKiZIMs aW9e40sRj6qwRv1dPjsuuGG6t3s2Zj/8m4ZflHuDSnrN9LrZgmtnNPoKCmjeyiuC/gIIf63q a2FTzxzUr62BE3PENJRUBHN8i4JO33CqAINXPIM5ZRXhJmqzoDM/yGrq1FbBnMICMS5vYWNN AQ1Q9OUrqdjH+rR93NTX697dh/VllWIcwZh8PJT0wsaK+plBT427HutzprfCnRL0V2L6Kn0V MyrFU/LZg10/xu1SwncMt4JvZ9SWlYXnhjSjt0LjVirF04LBW4SLb/gQFNjxuMJZ8USHD/FW cDeT1XAXtYZQp/WDjJKWP1IUKaJp/kh3SmUKpd8Zklsdky4taOzQlx2G9jHRfX5zaFRbDKir t3BGQYcBntapTh2g2tuvj1Mj5kK9MVoYxeMcKYuUNOxc2DToJmwSTzHOG2QTvBW+Gb5KH9aQ f0KF8E3Mdfj5jinzjSmpqgg/bXWVlJ+Wo/JcygVZCoplRpOPNViU5ZaPNZwfEc63Z0eeUTxK Fnsbjb4xZY2ic5/aIfNiB8Fpffqo2k25UX2xNYtwuvmKan14kRQ11ja3bZje2OT3Ny4qrJk9 SPThG1Xf6CurGOIOj7W0Yp17tbhVFBvDx5QP756Ns2d4k49fWtLk55eWVVXss+Oddml5RUjD Nfk1wyubuqCsYp+XMX/YqhFWYRQZr8iInkqRMYbru/f5GdsQLtWGDeF8XTNnYZtR2jira9aQ zS5tGti0ZPOHbSLhIcXNxhTjuC301ovHs7ZydmNNpdhcLAaPEr88yH1DWVDjG9rENXpL0OSb MTxo9g0X9jxhzyO7XtgNWBg8hmNyxJnUWOPDOYUFVcHcnJaiIrr0Nre1lVekvOI+WpmCpTYF qKoIRmTh7NeljUa9EQI1MI8IbqirFeNggQrR1pA2qq4Sy1Z2iCqjghHoIULtATWKwm3EckSj OjwbPMBw+w3IBDdUBiuzxE0r5lSGl7M9yEb6BuGxU5+6dHGjnMrGKF/v8N7EVjClbRQUgbGx sgqyuJHFzSppkgwWjLzOh6K6Gi9mW8vqyrDU6Sw1uckyA0eiNn1GGCa3WsiEW0qa2WoKRvRA h/gV2txDbEldmqGykgYfzm1UK+De9qAZI0rvMJVqA8wOikaJseB3I4Yqqj4puilpZqW+lThZ xKDDPRlQHLSmjarF4U/tzbD4cmVjozgjzGofB8lqEJ5bMO9KWnlz2z2+VSkdUvdsn3g5iIXJ 3PuwsFll45mG4OSs7tnGM63WsLmx0Wj99QY0X0ZrOwujtxBvDcZCEYq3WXPRQxFxfDTEhVJc IMX5UmyQ4jwp1kuxToq1UqyRYrUUq6RYKcUKKZZLsUyKpVIskWKxFIukWCjFAinmSzFPirlS nCvFHClmSzFLiplSzJCiXoo6KaZLUStFjRTTpJgqRbUUU6SYLEWVFJVSVEgxSYqJUgSkKJei TIpSKUqkmCDFeCnGSVEsxVgpxkgxWopRUoyUYoQURVIUSlEgRb4Uw6UYJoVfijwphkpxjhRD pBgsxSApBkqRK8UAKfpL0U+KvlL0kaK3FL2k6ClFjhQ9pOguRbYUWVJ0k6KrFJlSZEiRLkWa FF2k8EmRKkWKFF4pPFIkS5EkRaIUbikSpIiXIk6KWClipHBJ4ZQiWoooKRxS2KWwSREphVUK ixRmKUxSREhhlMIghV4KnRRaKRQpNFJwKZgqeJsUrVK0SPGzFCelOCHFT1L8KMW/pPhBiu+l +E6Kb6X4pxTfSHFciq+lOCbFUSmOSPGVFF9K8Q8pDkvxdym+kOJzKT6T4lMp/ibFJ1J8LMVH UnwoxQdS/FWK96V4T4q/SPGuFO9I8bYUb0lxSIo/S/GmFG9I8boUr0nxqhSvSPGyFC9J8aIU L0jxvBTPSfGsFM9IcVCKp6V4SoonpTggxRNSPC7FY1I8KsV+KR6RYp8UzVLsleJhKfZI8ZAU u6UISdEkRVCKXVI8KMUDUuyUYocU90txnxT3SnGPFHdLcZcUd0pxhxS3S3GbFNuluFWKW6S4 WYqbpLhRihuk2CbF9VJcJ8W1UlwjxVYptkhxtRR/kuIqKa6U4gopNktxuRSbpGiU4jIpLpVi oxSXSHGxFDLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs4TLs 4TLs4TLs4Q1SyPiHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iH y/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy7CH y7CHy7CHy2iHy2iHy2iHy2iHy2iHy2iHy2iHy2iHy2iH5+8WAlFzKHmoBzFzKNkFuoBy54eS B4E2UO48ovWhZAtoHeXWEq0hWk20KpQ0DLQylJQPWkG0nGgZlS2l3BKiBjIuDiUNBy0iWki0 gKrMJ5pHNDeUWAg6l2gO0WyiWUQzQ4kFoBmUqyeqI5pOVEtUQzSNaCq1q6bcFKLJRFVElUQV RJOIJhIFiMqJyohKiUqIJhCNJxpHVEw0lmgM0eiQexRoFNHIkHs0aARRUcg9BlQYco8FFRDl Ew2nsmHUzk+UR+2GEp1DNIRqDiYaRM0HEuUSDSDqT9SPOutL1Id66U3Ui6gndZZD1IPadSfK Jsoi6kbUlSiTKIO6TidKoz67EPmIUqnrFCIvtfMQJRMlESUSuYkSQgnjQPFEcaGE8aBYohgy uoicZIwmiiJyUJmdyEbGSCIrkYXKzEQmoggqMxIZiPSh+AkgXSi+BKQlUsiooRwnYmHibUSt 4Sq8hXI/E50kOkFlP1HuR6J/Ef1A9H0orhz0XSiuDPQt5f5J9A3RcSr7mnLHiI4SHaGyr4i+ JOM/iA4T/Z3oC6ryOeU+o9ynlPsb0SdEH1PZR0QfkvEDor8SvU/0HlX5C+XeJXonFDsJ9HYo diLoLaJDZPwz0ZtEbxC9TlVeI3qVjK8QvUz0EtGLVOUFoufJ+BzRs0TPEB0keppqPkW5J4kO ED1BZY8TPUbGR4n2Ez1CtI+omWrupdzDRHuIHiLaHYrJA4VCMZNBTURBol1EDxI9QLSTaAfR /aEYnNf8PurlXqJ7qOxuoruI7iS6g+h2otuIthPdSp3dQr3cTHQTld1IdAPRNqLrqcF1lLuW 6BqirVS2hXq5muhPVHYV0ZVEVxBtJrqcam6iXCPRZUSXEm0kuiTkqgVdHHJNB11EdGHINRN0 AdH5IVcAtCHkwmHMzwu5+oPWE62j5mup3Rqi1SFXPWgVNV9JtIJoOdEyoqVES6jrBmq+mGhR yFUHWkidLaCa84nmEc0lOpdoDrWbTTSLRjaTms8gqqeadUTTiWqJaoimEU0lp6tpZFOIJpPT VdR1Jd2ogmgSDXci3ShAvZQTlRGVEpWEnH7QhJBT3GF8yCmW97iQ80JQccjZHTSWqowhGh1y Ii7goyg3kmgEGYtCzvWgwpBzI6gg5DwPlB9ybgAND0UVgYYR+YnyiIaGovB+5+dQbkjIUQka TDQo5BBLYyBRbsgxAjQg5KgA9Q85qkD9qKwvUZ+QIxvUm2r2CjmEYz1DDrE3c4h6UPPudIds oizqrBtRV+oskyiDKJ0oLeQQs9SFyEd9plKfKdSZl3rxECVTuySiRCI3UQJRfMheDYoL2aeC YkP2aaAYIheRkyiaKIoaOKiBnYw2okgiK5GFapqppomMEURGIgORnmrqqKaWjAqRhogTMX+b bbpHoNVW52mx1Xt+hj4JnAB+gu1H2P4F/AB8D3wH+7fAP1H2DfLHga+BY8BR2I8AX6HsS+T/ ARwG/g58ETnL83nkbM9nwKfA34BPYPsY/BHwIfAB8n8Fvw+8B/wFeNc61/OOtZfnbfBb1nme Q9Z0z5+BN6HfsGZ5XgdeA15F+SuwvWyd73kJ+kXoF6Cft57rec46x/OsdbbnGessz0G0fRr9 PQU8CfjbDuD6BPA48JhlsedRS4Nnv2WJ5xHLUs8+oBnYC/vDwB6UPYSy3bCFgCYgCOwyr/I8 aF7tecC81rPTvM6zw7zecz9wH3AvcA9wN3CXubvnTvAdwO1ocxt4u3mu51boW6BvBm6CvhF9 3YC+tqGv62G7DrgWuAbYCmwBrka7P6G/q0zjPFeaxnuuMM3ybDbd5bncdI/nYiXNc5GS67mQ 53ouCGwInL9jQ+C8wLrA+h3rAuZ13LzOvW7MujXrdqx7f50/Sm9aG1gdWLNjdWBVYEVg5Y4V gUc0l7CZmov9QwLLdywLaJc5ly1dpny3jO9YxguW8Z7LuIYtsy/zLlMsSwMNgSU7GgKsYULD hoZgg3ZwsOHjBg1r4KbmtgO7G9zJRWD/2garvWhxYGFg0Y6FgQUz5wfOxQDn5M4KzN4xKzAz tz4wY0d9oC53eqA2tyYwLbc6MHVHdWBKblVg8o6qQGVuRWAS6k/MLQ8EdpQHynJLAqU7SgLj c8cFxsFenDsmMHbHmMDo3JGBUTtGBkbkFgUK4TxLtCd6ExW7GMC4RIyEufnwnm6/+2P3cbeW uYPuA24lypbgSdB0tcXz/PHxfGH8efFXxiu2uNfiNP64rtlFttjXYj+K/TpWG+2P7dqjiMXY Y7wxikv4FlNcXhTmvALiXv3CvhbH+NKLbC5uc3lcmkKPizPHx47jDsX1hP01u8Zm4zZbm03j t6G6LdITqRGXtkjFH9lrQJHN6rFqxKXNqsT4rbCIHjMsE8qLbGaPWRPIM483a/zmvPwiv7l7 zyKmcC/njNtBilGMgrs8RdjXu2O4juN93lRelpU1ptnISscEjRMmB/mlwbQycfWXVAX1lwZZ oGpyRRPnV1Q2cU1+edAp/mIbzl+8eTMbnjQmmFRWEdyeVDkmuAHCL0QbBEtqimHDK7OmLlm2 JCtr6VRcpi5ZmhX+RY4vE7ksYRS/S5YiL36WhfMs63cTVQNNW4K0VBqX/n6r/+2J/7sH8J+f mpj4ksGwNs1FrF5zIXABcD6wATgPWA+sA9YCa4DVwCpgJbACWA4sA5YCS4DFwCJgIbAAmA/M A+YC5wJzgNnALGAmMAOoB+qA6UAtUANMA6YC1cAUYDJQBVQCFcAkYCIQAMqBMqAUKAEmAOOB cUAxMBYYA4wGRgEjgRFAEVAIFAD5wHBgGOAH8oChwDnAEGAwMAgYCOQCA4D+QD+gL9AH6A30 AnoCOUAPoDuQDWQB3YCuQCaQAaQDaUAXwAekAimAF/AAyUASkAi4gQQgHogDYoEYwAU4gWgg CnAAdsAGRAJWwAKYARMQARgBA6AHdIB2WBuuCqABOMBYPYeNtwItwM/ASeAE8BPwI/Av4Afg e+A74Fvgn8A3wHHga+AYcBQ4AnwFfAn8AzgM/B34Avgc+Az4FPgb8AnwMfAR8CHwAfBX4H3g PeAvwLvAO8DbwFvAIeDPwJvAG8DrwGvAq8ArwMvAS8CLwAvA88BzwLPAM8BB4GngKeBJ4ADw BPA48BjwKLAfeATYBzQDe4GHgT3AQ8BuIAQ0AUFgF/Ag8ACwE9gB3A/cB9wL3APcDdwF3Anc AdwO3AZsB24FbgFuBm4CbgRuALYB1wPXAdcC1wBbgS3A1cCfgKuAK4ErgM3A5cAmoBG4DLgU 2AhcAlzM6odt4Nj/HPufY/9z7H+O/c+x/zn2P8f+59j/HPufY/9z7H+O/c+x/zn2P8f+59j/ HPufNwA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4A jjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzg2P8c+59j/3PsfY69z7H3 OfY+x97n2Psce59j73PsfY69/+8+h//DU+W/ewD/4Slu2lTGDLcw1rrltO9wT2DnsiVsA34u YZvZFvYEe59NZxdCbWPb2d3sPhZkT7IX2Dv/j99Z/9XUuko3n1mUvUzPohlrO9F2tPVuoFkX 2cGyBblorfeUpc3eduwM27HWLW321mZ9FDOF21o1b8L6LW9pO4H3K/Jt/UVesxHaFm7xjeGW 1l2t95wxByWsik1mU1g1q2G18F98H30OZmYum8fmswXh3AKUzcJ1JnLiu/Q4S8L6VK2FbBHQ wJayZWw5fhZBL1FzomxxOL+MrcDPSraKrWZr2Fq2Tr2uCFvWomR1OL8SWM/Ow5M5n10QVpLJ ciG7iF2Mp7aRXcou+93cZe2qkW1il+M5X8Gu/E29+bTcVfj5E7sa62Eru4Zdy67HuriR3XSG 9bqw/QZ2C7sVa0aUXQPLrWElSh9lz7I97EG2iz0cnss6zBrNiJyXmeE5XIQ5WAsPL+wwYpq/ Fe2ztR6+C98aVU9Xwn5BhxbL1XkUNS9ETeqFnoPoZd0ZM3EVfCB9yiPKXRP2/5S146z8nlXO x00dZubGcE6oM62/pa9lN2MH3oarmFWhbocmdWtYd7Tf0l53ezh/B7uT3YVncU9YSSbL3dD3 sHuxt+9nO9hO/JzSHRXxg+yB8JMLsiYWYrvZQ3iSD7O9rDls/72yX7PvVu2hdss+9gjbjxXy ODuAk+Yp/EjLY7A9oVoPhm2Uf4o9jbyoRbln2XM4oV5kL7GX2WvsGeReDV+fR+519ib7M3uH W6HeYP/AtYW9rvuMRbJhjOkewTzfxKbiR4dTaYnyJk4RhRnYQFbMxrHJjzIrXvcxbBDfs8dV UGDsbngcr3IN8yIYMDLO8/02rca6NyEhz7e3n36z4hjVzLs/lGfYjDA3r+XDlldzWj48GjUw 5yjP+eCTDz+xf/OqY2BOn08OfdKrJ3ekOMJwRmoMBqfel9pD0y8jvX+fPr2Havr1TfelRmrC tr79BwxV+vRO1ihOaRmqEXmuvPlzlTK+Ra9Z78ub2EeXnGBzWvU6TWJcVPchafayyWlDeiQZ FINe0RkNmQOGp46ZV5j6nsGR5IpJijIao5JiXEkOQ8v7usgT/9RFnszXzju5VdEPnpLXRbne ZNRo9frm5Lj4boNTRk20Rdu15mi7I8ZoiHJYMgumtFziShR9JLpc1FdLMabF13ZCu17nZKks nd28j3VpO/yQxc7H+ppVkd7cdvwhM4RZChOEP0GoNLu4WsNXS/jqz+RpojjbzIu7+NLTvrOY LXGpST6TlcdoLcxit2h2+Z7wveZTfBafJSqpNCqgC7C8vLyogQNzcqqrHbEDHZCOPvajvR19 MONZ1fQqZFlZaTEx+vCUZygpSqTiS01P7z+A0zzHGnxKinaZkdvTPJ606AjtwpYvzlVM0b7E pDQbN/KQ1hqfkeztlhCpXcM/4k+dE+OO1CoGSwQf3PpChDVCq4t0x2hD5kijohht5s0ta8T/ A9sp/vsWVlcyy2K57Hl/gifOzos9dpu4WHGJs+Diha/ib8T+zASXH+UuP8pdLnO2qJwtKmeL ytmicraonP0IPhOytgN7oFl6H8z0btQEH99tU9ka5h92W8J8eLdZsMbut243HzBrzAkZ3/Xq ZegS/lfpkr7N3NxkKGd5R/PC63Ygz6n+JDxpvQ9lkYA5K2sgaUyqM1LrS0lN7+fo279PCmbP JdZzssL79tD4fA6xmKNPSS335I6vWzyq9cHYrl1jefrSrXW9Y7KGdes3pTCztSUht2p06GB+ af/4cWkj5pa8emJwRX46X3LOrNKh3VyeDO0FGZ7s8tXFPcpH5EaZ+pUu0PCcsf0SW6t9g8e3 fDCoYoinNTdxQCnjrLbtuNaiS8Yunr47kQ3OUmclS50V8BExK+BjYlay1FnJehyfsSNZHM9h KSydZ4eiy7T7eTfWj/XkPZoiJmJLHzoqwHPIffvbB3v1THNG6jtsS71L3aZiA7ucyRrht1hW WotGZ3T6p60Ztf6lK4vLrn3jvNxzq4rcRp2iNZqNkb3HLx4/cXP9gH51V00uXlLS12Yw6ZW9 9rioSGfXDHf5nd/cfNvPu6a4vN3ckdEJUc7E6IiMnIzCS55cu+ax84al56TrHcnYgWKVXYlV FsU8bIU/KS+FR4uVEy1WTrQTPkdHweHoOHgbvV+sHJZAc5Ogzk2CumIS1BWToM5Nwn587o/A 3FhCkSXuZp7epKNVIufikFwR1eJEO21JGDosgCsn3nX87tZj4cefdu/hm0v29F14/yW7mtbe 3zBQc8O9J+8qpQc96Y7D2+bsuWj0z46hG54U/0MVnilr4Vk2W96UkKE+0Qx11BnqqDPUUWeo o85o1jj8ERHR3mgvBp/QzI1+64Z0fiCdv57O09P18eIPNNaSDFCTvn3VVy9ugFs54WPErq7+ 8HPW/GKl+1IcZ0hlrdZkNbZsER5qZhqtRp0Ol1Y9DxlxNGgjoMdpuNFq0o6IckcZyVtjlNsZ 5XYYW8+NsCdGRyXYDa29jA532O+2E0o5/M5gU5oM0arf0arf0arf0arf0arf0fB7jzWJJScZ 4Nru6Oh4fTPP3J1aEi8OSPWNlHPQMbDdO/4LZ+TbRrqrlMMxQytmz4DBh7Xf6PQmxKU6jXC1 KGw9GJ0IL0Ya7G5XtNsR0fK5wWrQ6XDRPii8TBIeTW47pl2p87I8drs/KTHRFidWaJxYoXHi bIszWYSCF3Hi6VnZExncm+HPqMlQMmyq/zbVf5u6k23qTrap/tvEt8Nz+vK+cc3c9FBq6sCc ofu5Ce94E+8aGljmbObZTTkTxfPGbnbQdKjn3KHq6oPtB506L6ft5v4DHGIViN0eni2HOAFP 7X+tdqXWaDFYcqdeWDX3/uV5havvmzFkTb/WQw6HNgLviBvNMVGmqEFTptf3uvbIHROr7zt6 1egLZhQmmLRTo5Oijek90sc1Pr5w7YGLCpKS+KrULphGo9GeGNUanZCelBpnqd55fOsNJ4K1 Cb6uCam0PrQT8M7NYc0P5fXiPos6RRZ1iizqErGoS8SiTpFFTG5ibBezmH2zmH2zmH2zmH2z OB/M4h0Ry/wuvFj80eJid/CxzI9yFiv+aIECwQ+jLLZbKV4g2X7bAQt/3cItp7+NsaGO5nG8 NQ6JaVWX3KmNVZ3WvtQ6rjo6NV2wSamdYHSmxCV4ncaW3VDxYuUZnalx8SlOo6Y4vBahEjD7 WHIWo2Zoy1NSa9+TquWERi+1ur94BebPxSbszYsdH7srVmHqFDJ1Cpk6hUydQqZOIXsEZ6Kp 7cBezITJXhp2F262H4Rpv3CGV8hxR7hSYuM7jvbUCMWoDG3H+GcYVSar2IfX+9kPJwnDcfDi pEhfacR+3hsfk+Pw7tKp7y5s+qwOb24xOr0MJ8Nx56mRfpZYsLA0cUCPVLNBp1HwhjLG+3p4 Unt67eRCdAQvKt5Q1SvC5rBYHPFRMYglbVE2R4+SYcotwh+xC9Tz60d40odN9zt6iW3dU6yu HKFSTOpMm1TXTKprJtU1k+qaSSxWiyujNMVkd5faT8V5efL1g3WEK814enoG/5WFpIZ3Lqfe wHlMjPKjwZnq9mXHGFq7nLma+It6e2xKQoI32mCNai3jrzoMieIo19tNmo0tq9oPtVOr6klN XoTFoNXBYE2IbWlruSEhWn1rjYH3CWzkPuYiZ12qsy7VWZfqrEt11iX+xwaLsJW6mnmW+lri Oa/I59bhPdS+RcTxPAbvloiWg7Fd2514XQSjY5zu6Ai8ZR6UQz15W4QjUV35+iy8WYawnX57 zdBFQzXWnj1jc3JMPeLiEprPMiwQDya5Sy+LxSTOEZM4R0ziHDGJc8QknrRJLEtEqP54sUa7 9C8xx8Vac+J69dB7Mks8AXlM5EUhXO8DR2WciZjd3q4cA8/J6dNHRPEddpWPi8gdMTz3nfa2 CgfxvI943uH50WcZnZ742JRoo6a1j2J2JTldyU6zpnUEx5kRH4eHnO2e7e3ZJS6Cr9DxS8wJ nvT4+TZ3tOXU5px1cqvBZFC0CMrwMWlbu/3ubl0sCZnunycpdyd3izdHRCe5xP8pbTuqPaxL webLYGv9CU4xNU4xNU4RgjlFCOYUU+Ns1vTxR3hZT7YBnxCS1TlPVuc8WX25Jasvt2R1zpP3 I0w1sXi8ymxlPrFGdBNPD8Wqz9jj7R8Zw5FYh7hUe3j0lg+3Xv3WpoLRWz/ceuWhzYV7MiZf v2jR9dO6pldd17D4hqmZmmtv/rlp2qS7f9i+7cSuaRPv+va+BY9tGld++f5ZDQc2FZdf+aiI OrHHn8NKSmRd2cqmLnrVEb3qiF5dPHp18ehVR/Ri8cQ6ksT0JInpSbJbrHxskvhckyS+RMsc aXh/79brLXDTvNtVYukQvlDAaT89gvGdGbZoOwSfynP+FQ+s3BIRnRIv9ke3BO7qVjxn/tiu ewZPqs6+9cZxs4q6KFtqb1owpLVH+xO+PzPVEJs3ZdWk8ef2jWz5KXNEHQs/4WG6jXjCGWzw /2Hvy8Pjqq48331L7ctbat/3RaVSaSmVVNrqSZYllRbbsrxjybvBLF4xBuwGA4aEACEQSD4I HUgmY7I1YPAimzBxvqaTySIaEsLSk2TIdGcAZ9xp6EyAgEpzz3uvSiVZ7iTd880/Ix37vVev tnvPPevvnCsRnxW9uiCfgFkkYBYJWOQELHICFjmBZyLqiICn3nPUQ3kaFeY0KsxpVFa5UVnl RoU5jbDTjQ/qjOlJlDxpH4vSLbDURljqV6eACfnZ9a5ELPmGekbhQFxVnZYoeRmD5kkAnoXO oLKsv/5YV8MXtpUl4Z6f3T8gJLtqirsHEhZN6dvzhWK/3c+pgoUNHb7aNcc/eOLRj0Ay3v/r 0YeO7U13LAmZhTD51u7v3LNs7L5zV+3/7r1YTOAP60mxih7LSY7oJR4QfWwd16LBU20BrrVI a98CXGwBtrXg+Z9JQg6cLHDAK3zFKTzjFIHiFIHiFJ5x0JLsqWNxnH96r4hE0d6J5eZUcNSu GBkpur9YYVxVTptXDKsECdRRlwiSze6jlNTWLthsKBuLx2LlpEavskR8rqBFTx+yprtWtR8o ixhOcoSGbtfQgWXxcM/GfCCbTliuN2lK070rnIWmB77eu63Hj40MdpZa1oAasmsL4ek3K6KH Q2aGMrau2bOk+8rlbRZTqmNZQ+kfI17qzuFddrWqNBxsX4HteP/MRWoblsUi8fZZonvmnZNm Fg13KyzqVlgnnQ3SWWJV9yRZK6YaRcGChhtFHDFEGiONBrcD3usGA+5mWTjgt7hhOdznyAaw 4s+5pYDj/HNO5WyRz6fNEBwa6p5HcaIFh9kxUc8FWlCLqDegYQ76YXRw1cK1cLYOnJOc6nYz yTEblm3FeuEluMhBxpVKjbMXWVDw2WiRl5+YZ9boOaFLthLKzE/BVdS2JYe+Mt69Z227XY/D Eo2pacW+wdbxJZHGlbt2X7WyqX3XA6tSa0c6BBVNUiq9Wp/pHW/Lrci6Gseu3n31WBO65orP bmu0BUKOqN/m5dWhRNjXsqKpZVl7Q1PXqn3LR29dkzY7/YKecwg8zsw9Ya+3vieaW9bR2NQ5 tg+vkRlbyNex5IeIHWccImQ5HHDtJIRxf7a5BEfKzZw/BZKv4iGh8yoWsRGHne9JzPm7FPti qpLOzQbWZUsghQqvS2noQ+WoB18paSp1TEpSpSzu4y9XBHGrhvMIggz0QeTwTezfbsJRTYp4 RPRuTqMAaG0AtDgAohMA3x8AqYE9pyJXnUNgSSNsyoRtyoRtyoRtyoRtyoRt50gW4mvINKAx TdTij9DFVrIr3bNyIyUWih1MzYrIOLo0ALTMD3Lpm5YenTx4zTO39MqJrKCpHTtYHDo4mpJY E8Qx7q9uOHu0p+um04eocJkdn7y/4a716dp1t6+l7NUxewhbt6swVyLEbtEbAcOWiCAXnGMu lLCjmBHVOlGtAzknFSWVLsDsOcp34ELk4ZbT4XTEov6VDoaXMws+X+B4JCsCzJAYH0fj4+Op 8VRUCoPoOIrFcrmq4KfRZlOpyTO0yRn32oIOzqCmSus1iE+EPEFeS6MDCO2iNNh0+SNGSuMD wBLhCFavoZ+VIE2NUffxd+kC3AdIE+bYiWPGt/AcO4grn4t1IOysPhSXgGJHsQhq4CKRQVFW uhNFIQdcJEPIEYCLdANK16N0BKXDqGVlzcpwvZ6qThTt+UIBrxz+AahWoWglxqPKV/OnOXfC zB0060n6/CmPiS69R/6RMrmSgWCtx0yVvqlCXCzgjwhqEoURslBaS9TnCVq0FEqSyEuphLDX F2YREzNxgNVwJuqVTzLla/pbdhdwxaT/+EW6TW+GFMes//j7dLsOXzMmlx183EZsjQvUj3C+ IxLPiAFzj78n00PptfasAYt2FvQjC6qRZWG9s5PoA9FExONmAhkI0CCiTbHUbaAFRuWsl8+S jLRNkhrRwtn/jsiyWbL9fBYRWZTN1nXXTCK3aH45hEIh2nuhbrDzF4YRmsiUUS0J6BjfNzFe DhRfTE2M5xWEqxE7wAkcW0PQEIs1N1cFD03NSsyg3KEl3VHLxtUGgAhVYD1ul9/U/sBo/4HR dNf1X991xNawLN+5pdhg0Bi0tNrds2ZndsunV8W+dl/v9h7/+hXdezodBgOO7AwbCn3Rvp3d w3sHo33ZFc1ub9irYZ1mp9cV9gq1q29Z9aI9XUj2jfX0Yu4+grn7c2YfUUN0EneewsqvC+YU q5FTrEhO4Rc8lviVm0Qfim5rCiKyVABwX+B/CmxWipXgYFInagmrLtccpJn6ScScjg26+9jh PL48wYxIVgaz0J4vB52pWZ5V7EzceqnBkYWzHHSrOZtNCkN/3rTtc+OpYl9fXMO7rRYPr1IL AYczwGsSQwMDia33rE08Zc2uEQNd4tJ475ElXetanOjtg88f6+Nibcnd2ObQNLY5TKtGTrM1 079JtobZZXc8c3Dp7ds7+ZqextIjY2s7th3GGrsBcyxA/ZBoJu4+4ZE8tgwlvKVACO+chLRs AUD1n+cCqTMXZICV1IvGjAmZnG/7RZ1xwB+ZRORJYZD6bQP4M61xoKF2EqlOaEcAcUhdlA4V cO3FCpQ6DzJXye5aVQ2YUwGSUTs7htZltnxhR3P3vkfWp0Z7mx1aFckbzfGO1W2Hbg2K4x35 NYWUAZKzr3JOzuiMennx8HMH7/zuze2sK+QwCQ4+7g8mgmeeWnvHulQkFdYIXtDTzZgvjzHX ETEiT9wj+gvtSO/Og3bmwXvlIfrJg3TkQVjyzyP4S1cZmWsZhVkZhVkZRWMzCrMyIFA6Idin z8fdtKkGmvodg1jV6edMI8wwOGxJnArzsHNJnirpbbUK4vCzIlVULFYdwLdQj6k5jwXKcf2P XLHt3rWJxq0PbFp+h6i2+EGmtMeX/FVvAUsQlqjuYKfYF3eWBejQyJqRO05svf75Y/1Ll5D6 MqoxvRTLztYjYu/tO7AsLWkAbo1jbj2CrVqKyBJPiTWZXCG3J0cJoE1CAIBoIVgLsWItcEsu UUn2DcvCR6d6U19LkVB8OQXalqUV4aMVGZMe66WzbOBo4F8wWPuDo/TnaPI8jV6mEU17Mr+I DToubDbtNZEm7QWPJGDj1Yi9rJS/TMnCJtWpJAVVhYNVYmWdK3ykNZ6TGKqmHok7p5/19e0d FbcXMwa1XkWRlFqfW7NP3PPk/raOfU9su/rhzenj1E2HOjd2hUiSjAeHblxTZ3VZ1SYnbxTM Br3TIXTdPHnz9WdvW9p74EvrhNsfqhve0QKeMzrzR/Iu5kbsObc/a2NBASXFcytWy122Vm7F nLkVYXLD9sX6mujkzMsiDwhsVHcx1++KXawfCAyzA1JW0wi5f+rFpvdkHWt6cR5ubVVwr+qs Jqxg2E1l3Jq8C/t+ldrqS7qj2YDphxq9luHNP9Rg0+QICJpbWRZMza3hgesGwz0RA44JzILd xGj1WkfTaNtWNecSIoFPfgvhAxS0KGsgIrg49fjEp9YkjWaD4IYqaHPp89Td1H8luohlxCbi ZdHKp/tBy/o1eMr9AVZAw/1NBRxVAAsKin7h81un4amCejm+FI1mHg0vd9PmeqpJrQbpYSV+ nReN+CLdpHa71U1pGngsZoHJ6+Ar1gVY/LZ1NVFRj89Rc72aah38B8PYO1br5lbq3Y6BmkDP m62DV7wZWK4UggpyaeA12fSnmqaAuXYcgEEIxuGb7FQK/0uVD8B1zGObTXYFMZyBYwdpVzLH ssy1YPeazUlHWbNxcomysYo7hYJpLB43Ucoj6m7BfFvY0zh+dFnLNjdv7879dsnelXXZa47v u+6RrbVssCHQkGmM+iPZjbcNJ/v9iOW4UmnHeH1/xr7jioaBjH1s0+i7gaRDe+yGoR1dbur6 sD+yNrPsxrFar42v84XrSB0Z7Fzf3rV3dUNUXJ8NdrU2OZ3DtZ2bY9HxnpGbV6W1mmDpvY1X BlqLifU7/S0D0xNtBVLjTCcT1u4l3voukO9HcIbzBPbMjcRNJwtZVDNbilIEu6pGpdSssFu2 ++SCg1R6kKoOktnQw3M6udbgq3HihF51Jj0Y6XMOS+ZTSuQrWLbsjPNzAXfJm6gXQIHl0NFK PaHhZZ/rqCvWdx3pxQ8lKLDsivs/V9xweDjoLMszaR6Z6I2sWz19T/lOtf8dKnbuvHsLWMo7 Z/6IRpkMYSWCxL1nCuHl4T1hyqbEcnMyHEE6vzUvE5Izn+fJfYSHsF4OIFZYasVsOq3zQ48A bOQ76WSLEn9eu5hSrKHiWRauRgjgdkEYsRSirvkMEGrb21Lwv8IC6lgZ10f1bTXJPP6PZzzz 89Ln0XY84whRT9z13PJG6NqQggV8fh/GHS0bdmjngAlE4XcapAyE8rqqQoY8r0pFA9s+Ued0 Eo11MMc6PMfnEv6iBXvSE4ykpXimXFNTOZ6VZ4vnyswBCGxzs7450x71idv7A2kHTocotVat CtuDGZ+pbPSABzWp9vYa8/bDq1IanZHjjVCdZSzpgSL1rUvZIevBEawHWeJh0VDIoWQDahB5 NILDo5elyTUo7q8BZm+QzpL7a3iejBMhwqDw4PJ1O6waLls6TQBLZBWxhfRMoujp48rqIYGD ONjC0b3kExrfKktBRQz+rBLJEY0QcrnDDrOqdGy+fKBVGt4ZcjhDVq3RXDqHdhv1EpRFqY1a 9H7JeKmafPJTdIPOqKWwU9UaHGzpXCnKWRXbgbowz6yEKNXg9kg1uIWLXLMygj48qWP7pBkr ArBwze0SyXZeOjRlFMzLOMZZQVwQ3TzUp6Q+iZiUzcalVHbvStR3aa1dRtiqavIXKvbN57MB gu9rlOshUmVEKopIZk6H5fvMCsBEVnRd2rogf+wlLQ7Pow+xkWWR6tmhQRx8q0Rj92BXX7q1 mB52Vq1/dUEgr+CcXL5c/gNrKW3o+rdM5uVsqFVJvxVhYV6WTamgsdT21uUPLAXtsQcFta12 SV3++oplVfEeu83LqofvL7au761n06ND/ZG1NxT9szY2nJ9nYy+9Qx3DgQlFafWaQ6uXuzLd iYbeGgEb3+GyD8Ir2Eg8JJrlFYSD4o7mr9JlOicgWfTpWbbslaTSeFVVHH14RnFM4JZEXXqw xhkpllkPUcNslZWdw+0/wz1Z/5R7qjDxiyN/wj3NYRRm0GbwTpAN/gpzCCpTXxc9hSRK8CjJ ATYVM6CYBsXUqEZCQxaoRr21YDUKgnVfRod0VWWuwNwy1zlSB9jxGTMxshcvkxN2MpsHwzhz VNJryBAVlmUqxavx8s+fqmJRv2o78Df79/zn3bn8gW8fwOeWp9xdVy8v7uoNugtXLx+4ujeA frP77F1DPbec3I/Pg/h8pHj71nx20+0jg7dvyWcnbgdsofQQ9XPMG8AWjgK2EMwtUI+Wrc9s YRqCGKsMK0gAg4SgywjDgrhCkV1+WVxhIVhhARm5PKzw4ESit1uMVAmLxerm1cnhkdH01s8A rNAkwQp98d6bl3Stb3Ghd2/4zh39bCgbLnWVbSH9LpYZisLSc1NNV9I6fOzpg0tv294hJJc0 lB4dW9ex/YiUP2NuPaZw6y7Rjdnl16dAYVI6QxlikYxcCnLnGqJJFpuqzsQLSmdiuWOx3JmI c2drtKjvTPlptg5yZ9dgK+TO7Aj4/IVz5zk8a+ZkpLAsL/bmy+fOWlAzv0WdHBwoxoFFjdse 2JToW9pfA82tFg+nviR/Lp0scwpNJfNhczmH5qLtyevKrCv9bzmJlgEZnERL1ol8UkIGt53c 24xiZkWoZpuWFOEyK1JnBuHiq4BzkDLChWUuKmpTgzGzNVC0DhOKuZccfqoSC1cngAsZGkmI VOSTpEqr0di9EauzvrktPN/MRLvb8l5jMOI10BSittp8nFar1Vjqhlumn7nU0NyR642bKY1O pzVJvWujMxfJl/CMi8RLoiEzVBhaPnTr0NNDTFVx6g9KUUoSim6Ap4R5RSupWIV+IfrlCpVU mwIRUwpUkCKDzXGfQ3+Q2gx0EBYZRClUwg9j+PMKhqcNpKHuly2633IruM3cXo6SC1H/DapQ g7Z3ZGWslKCUAtQ4lBSqClCzsfRfWoAiX2qauH1Z/dql9TYdDQWmVGFNa01vozsurlg9KsaT Kw+vjAy0Ja1qCkdHOpU2lCtmasSkNSGuXD0mxpFp6bV4ve1OS8Qv4PjTHXDz4Vw0lk34Q6mu NR3NW4q1Bt7KGsw2lnOyapvTJoTrPfHmRCBU07EK1iI48zvyOvpviDZi48kkwYXTCs/Tylqk lbVIKwqZVqQyDUJosBvTF8MDXuNF+0ADRN9q2WxPgdg1KejV1IsytEcvDDDMhSFsZTiGvE7D BpJ19r7tovcWMw9VqL8qB2pvA3bMm99u6bdHPBYNo2XoK7wh1qRVRYcOLCNNMsLwmtoAAL0B X0gYREk3vkmr0zImB8z7IcD5qO/gmOBB0Y8jAX0cJCgOEhSH2kxcMlJxVgq50EenZU3zK1zx K1zB5w8l3YSL56QmbUVZ/YqM+iFX0QrpYlzPOIs4MGNmwb7qRqWKSC0I9s0rVuVaZmG/x9S8 12r3cqqRL0iuX22RcxR7ZqC+6/BStcWPNZfXViKCQ6uXdVx591YyVNbO6d8v37Qkum41ebB8 R6laUYcxf2qJfzxLhGewN4NA1y/VcqJ+5JMvfMimzNOqnC2z4a905is1+Jl/EVuggI+jCg7F WZRgUCiBb3SGUCSEgnBZCKJIEAWkuwEUCaC4Gd0QREEAubScdSAYwFobhFqYFotiEBBGeAQr EYTPN0DzWKIY1LuKetkASmXAFPT2j0uRQ0r+BxUypesfqkkpabdFpW2oykUI9hZB2WZxGJEU WZqija6Ez5dwmujSSzSDNILf7g0LWrpEUx+TOiHotvs4NfU4rdUZ1J98A4pktMako9YaeC2F c0ISH7TTLoOB/J9ag4YiNXrgdjPOMY5hbi8lfnWW6MfmqRNPrRXAr2QraoFztA7FgigWQDE/ ivlQzIviHpSgUZJCbe2ovQ21p1EH/N0QKxphFfgAzqIOiysbwJ/AmpXbcBYN4Ejgtrm7KL0O mFlgl7N72FtZmhV52wDbVIwW2z5Xi2rhuVqwmqxgG7iy9lAtuRTftQ9rgck/B06Ov1goTGFO yvyeLUXKxUj5R2a0qsJnKq6uqt0twPKqS+YYzZQ+oIz2hM9f4zRQL5Dk05TRlfT54/hR6SOG xtmF3RPiNdSbJPkDUstjsffzGvJ1Er1GaoWgy+GFZVFbzLOLQt6n1U4fmF0is0Wt1eMVwpnq tEurxStkxIYX2vgc5UekRgfrlcTaMYTXK0PcdZZowIzhAN8Hu1EHFqO9DjmwPJ6Gep4D2RXb YCvfsiEtSGsN5K3wng4CtYZRTo/0AUgvYFX0+ob6ZDGs57xFrpJCyJXeTKXKC8Iry28qarOU N67M7luZrYgKQrkMiqglGiHu94WtevqN12m9NeTxRjmkRY7SBxokxAPesEVHT71M6zi/2xvl SW3po1qTYGBwdq5GO0pfwieKMQgmdAY9aRKMNKXSqUsn0HIV9MHpLebSBFgPHAUewfyJECvP Em4812bQfDdKupFDSp4dKGbKmci4FrnAJbe5kLMVGOdE/qJTJxR1Q/RyYkhJWqH6m5KVFpQ3 SMlTbRGgozOWrVR9BQnVsVnUZNONqoZGV4AjVUe0LFX6roaN+Hwhi5ZBiPpQxYUCnginKp1i OcZgMaE8zeuojVaHiaE0ZuN0HfmaoGewn+AJEulm/oB+wUwQViJJmE4xUfcI24eH9cuXqrro qFgFQpq3FesFNWyF8vBqDmmsYY87bNWYtM6E35/EEuVI+v0JpxYdLMeN1DkDb2BUBs7wcT6Y cuv17lQwmHbq9c405mlN6VfoAPEW4SZ0z+rtHoJ9dUpuTlKrZS1qESrfe0BlsnN3M0bBKXB2 HaLv1DsiLmfErr/fn61LO19S6zSSYCPhqDvAqlRsAGL3gdJ/R/dRD+MsMEMET0Qsz5PLiRh+ 4vApnT9Vz5iJzBT+UuyxXv319y9tIuQWHsp9MN9AAuabCMB8VUY792nGyDt5aWh3GOwRpwMP jQoEamHOtYFQGs7p6RFpsD/R6NQ0xM6IqwyWJJ6f+UAZa5xwnyAsk+ThMzpfGOfb5gGiMFWY ggCkceFRzlmiS8Y3//Gl40oE5Rt4cbAhd6XBInwRj2c3Xh09YT8BrTvnT0OLjpbCqouHkvoe LFUVvrg709VRB/+v68/ULcX/4TNqqIPoAHMjXmEtXuF+/E55/H/JAjMxf1Mm7XhJbZBMlxYJ t7oCvErFSyv8aeoQVSd9QwthPKkK2RrxtzRNAZ/m1CKUrYXqBe5K+nVcbw87HCGbHi8m+ynG gBeTtekQU7Iv8AS2NHT/LcooXL4mvKZT0ppiASxdvMwTMNoUdYh8pTJafdzeVBlthSuxWHaW LcyCzCJfgcF8mjbyDhgMdUxnDzvtYZu+9GjVE3j4tPQMjJ6J+/FoHFMaPYge5iKHucipVFzA dbkn8Pqh0tuUjvkv2FZoTrAMkck01NuVwSgIqvrrtNHitTqDPK0ix2mj4LPigJZm3jOaNbTa KBhVh41mLZ6/xYg/byk6SdaRnYSZMJ0k1PqLNAENrko9KSjLEjRukXU8V5rg8Q/6qsaIjdxH cZ8/FvOpOBeBsP26SJPkLfhTuGfxp5xFHuJyH0STgvBJQeB5gfqe1qxlyFwsHI5Fw1ppz9HM R6XP08SMgzAS5lOEWvcuDVj7pZ9jowmW+6ST43mO+luWK70WDvjCoRBw6M7Sk+hfmXuIMBES rRS4SgqSNEpq8qSsfv2dRCGDNVdu51PhrIC3V7Zk1lGSFMqcRL/bNL7pCgaZvE7eJRio3MpW jz+/sglpWY/N7mFJZusPS+tfe7204ccGTs+QKg2z85U3frlv3y/e/OmVtEqF3RYLOnczHtHb eERBoukswcsxLK/kQHA+BSPjpVZGvZRlyyNMNVY6DtVlf5vjm7NkXPEFdhuP3va0juYog+Di XV4jYjZOTEzQJOuxWz2chrzyIOnc98s3XtnJaFQko+cMP0JPvv4aevKHWlaHR6eip0rLsQ7c Q+0kH2UOlv2PO9bPYiUoTFWbNqoMgM27Y7OSd6hYO887zCq7zhK0O4IWLSp9as69+hh1VwW4 +PvyValh7j2WxWO5BudMLzABIksMEI+cJQZx3GM3kyObB1HqYAHtLKAlBZQtoEgBFSbJJaLF 4PEYbm5GVzejoWbU1oxSzagZP3F6L4FAGCAclfetvHMGfwxRb0A4Nf8jztTJEUPbTH09E5tE xLPC+t5JZD3BbKrsPsXsH38VRz7jv5biSh6alaQr2DWUqkrC6flJt3oeRlZGCl/IXnt83+iR jZ1Rlq9bfuj47uiwWGtS0yRS67X6WG6kafyu1UnK1T2ypmHX59bHnrLnNvREB5cWXMHCREGc 6PKi/7T68ZuKicFrP/O1ibFvfvmeKzu0Zl5vNAsm3sVqTJxp+Og3Npp9DnN+x92b2zb1RIx2 P3/bU7vS9aM7oAK+EvP2nNQ53kL0o9vPEjlIJDloU8IXIITNk8qd5vKdbPlOtnxHgtG4WTit KLXg4iUqovrya+rLKWr1HanUVD9JOkWnJSFpY0JKgJXrgNyw7hBdPnPYh2cBEC4cfBafrlV6 TSskaVYvTlukNyo34Y2t58glBDHz6nOwyLOLXukRVjqPzit1nfNSA0QPRMg6+IyeevyhPeVB 95QH3aMMugdEjdNBFKlr7mTS0871S6crwpKvbLx6VU735jQO4xNbhbCC9FR+nV114NAim57Z fnmKylb6kuy5HGxlLlfmc9S5jn3Hr9n+5d1tiaHdSzs2isGGbY/s3Hr/eC20JfXvGYq/4W0d a752jzu/tmPHtTWhpVf2FjZ1+u88dvQONLzqjg11NStvHOncuWYo5F86ujHXe2hdU2Z0d6Fp YlUxEB5cvYncVNNb79y6Or6kI+/P3jL91bqh7s6gv6unWLvl6msgjsOy9ANpn0mKuCA650H5 0TKUn4aMLgrSkUZVID1UpiyAg1hg8SywpRxHgjjIIQIyBBRQhCugYLUBBQzB53cg6sF5O/xl HVGrgy0sIkFJu/m10BGlW64jCSmblzYEyQJxXtJ4Qkfo0rVu+GWo5jHY31HevjLb3Yqjf6zo 1RUUacn+jXoAXQXr0tQPMtc9c9vNT+5M1V/7zNHD+PyMyZ3qGKlffXWnzde9Y6B1dSeO+8jP PPyHE1vWfuODJx76QDp/e8ujN6xuca649zvXPvDjo22RJRP778Tm6ymsto8zdqKO+I0YifhQ xIsiHhR2o4gLRZwIUhw7Skq85yGvq5c6UYDd9YgA1hJJBVNLKgxNKuhSUmFoUkkck7AhxuRz wJscejjqOUWP8FnSK07Ro6r755UtEJj1+B1PcIgT+ElUeC68MslOIrW8g6yxMD0lIZrwMwVN QuV+cVkZZrP3cWWDWblhnFOrVHLW3hJVKn6chJM8rtIZ1dMb1Qa9SqU1apDpj9APRKlwAF9D G3Co5cAB3wWcBzG9gFmqWZfAuzgt9cbDOtros3MO1qD6LkXTiFbrVR/fr8VBDOb2fsztx7BM dxEPicZkDqV8KOkFJEScLLshEdlAim2S5bEFpIybTJ9uimIi8gqv8+fIWwm9zBw94B56qONx rflAII+Fr+50k01VN8bmJ1GizCEZ/83IxgQbkKnKBnCJRxLCMYc5AFrMa45VVWyHWmq1f4zB 8dV0s8lqVlM6s+HjtbvyvKd5RVZqjcUpNk0yGkf7+mvaJ+4br7P137VnimzSmPXMIOwjULM+ m8VntxuRbuODN25NpUbaQqFESMP7rGYba7JGwo7mjTcv7Tp8/9P7X9PyEuZ+JbYJD2L+rUPM WWIDZpkHWLYBNWgwUxpA8RskvjUA3xomyWZRt2wstmyZQ0AjIiBuMfySGABBIr4bEymTW8OW MXbpne6A1JYmi6wbc/6UBG5IvaSg3yZFNE2KtJtg4QS8DKZ2aFloB0hqONOOJNFVRFj2AO1c O2fLTSK9qCuO1f5rIMAUYYuIvrJFJHMxz1Z2iWDTnZHtvWLrpdYsKHPz+Vk7P7vNNVeF1JPh 2fbm8p2FFtGKPcCDXdd/85rufevazBoVZTJqm8f29PZs7w2lxm4aOYzXSq3Sm7T7enYV467s aHPbluFGHWAnOBIV2lbvETd8+op0oGtD+5I9K9Jo//r7d7ZYvX6TCWcHEU8gGgh1rW5sWSeG sHpYBadZHRLXtySKOX84EWbMbpvZzpkEvM51qw72d+4azetJdfMKsP31M3+kfsZYiBpslz4W 2wA2TKN4LYrEUSSGoh4Uc6OwZKCiDhS1o5gNxawoZkExFuEljjAoQqOUG0nWipetVdrmwBe2 AKt0JskdSW+dgY4lT10dOznziejFr2BB/ViQCBbAdBacCAtBPgu/JSJO0LKtorEDKDd4ijro 8KTrM3F3nbTAdCrIsrrgSp28twFrXdPFxkYF90opNQXY+jklnWc1cN4PmtvWWFFNNGurbCiM gtTPLPyD5f2e0xcMrBHnCjo1+ikj+Gp9wQYf+yBnLX2FLF2BnkR7g7HSv5SBdMSqWJ9D8Dnt RooH9IbBudcn3w+T7063gcbtwBr3BcaELdb3RGO8BcVzUiGdkizWadlgtShWqUX6xTew0Q02 8yQw6xOwbRD0ImFa3rin8dZGqnHhDZHnyCZpJ7jiS09J3T/CJJTVobtOcORgB76htu33AdgB wNSOOuaozvhFUJ1MCrGvKRrz4virsvLIzAXuLrgpXA6BwnN+9QVOA5VWOuoLfUdPXNtx7aqc WSXtFFfravp3DSzZO1oXHz2ypnNdzOPwe8lOjVnHWPiSN1ys33N8Tx49cdVX97RxTofJwLl4 zs1pnF5XoPfKwa5NBb/BFSXNwYAWG8FIovQwQzZv+czMTDkvIVXUjwjg/DasA09jzvuJ188S HLZdOi6IhjmWVbYEzt0q+I7iJz+UZPF6qTzBTpbfxbIykC69i1XeJT2thwrIQRYUR6UUP4Ll lQ2iqsD2DSmgtSoeuapb7x1lu/dbp/B7rAw3idLPuUb1la1bkkuWViGlVCvKRYvZeoUE9Fb/ 4gnqaYrRqkp1jNkecYViHKlCF6Y/LwiMzqQl3zdZ9Sr6Rd7rdpo+fslg1lIqo2CkBxMRAfsV FQ9//V3JRDA3f0IACgOPj2PPUU/0EC+IQrIO1TAoKVUeamIopkO9YCoCMO1e7E6MZU/ivbkB 5RuKDbsaqFQDaoCNhVrCZAoQewlSTgPkdOAkSGw7+A381naIV6SNTgfbUa69r31nOxVpR+2T ZEo0ZaIoKr4fCKhzv68Zw1KsOaFeU5UUSumgtJlgXMkIG6tlWJJien55tmXOdlh6bg9Jjjpu qR89/I29qdHuWgtmll6jT3SubNpyz7pasvmhzdd+fn288eqv7R/9q41inHs61LO50L2x3eNs 3dAzdC95btW3H7/nqnY9y/N+l81lYsy8eeiW4xv99e077x1b86Ub+pIj133mK31Hn762PrN8 e3P71t5oWv7Ng1+RCWUuS78ht1bR38tEDS1AJ+krKvQxENO3IH2L+ZaqBtONs6SOzqG/Xpg0 NkwntBtl0tVV0cMy4Zh1IXrQEF6ky9JPL0fGa4wfXEqmz8pkzixAz/7fJfbxS4kLS/TYwsSH JXoBSCCq6NeW/dVkJS5DX7R+0VZv+4ZM9j0L0G//PeQ4vBA5G126Cj3qmlmkRfr/ndy9C9JB 9489gqdZop0SveC1XpY6q2gzpjur6LhCv/MV/kK68/8F+Zv8TYH1/zEKGoJ/G9oWXhvxRF6J vBm9MXo0ll+kRVqkRVqkRVqkRVqkRVqkRVqkRVqkRVqkRVqkRVqkRfr3kFRPRgRh+icCkTcZ CEJLvkbQBD/zHj7GpWMbYcfHoZl38XG9dNw+sxkfr5p5Cx8PzDyJj9fPPEPQ6NGZn+Dj+Zl/ wMcfzLxO0NRqwoyP6wgDPl4x8yw+TswM4eMm6Xo//nyOoGf+Fz5un3kZHw/MvI2P18+8Q3Ao AffxZ8LxvHT8PrwefzK+plbP/BM+TuAjj8f5z/jYhr+Fx+OE6/XScTuhI3j8yg/w8QpiPT5O wGuoTfjagb/3f+Bj28wFfNyO5+XA3/5/iPsa8Kiqa+29z5n/mYQhIoaUxikoBKQhIipPiBgw /hGEKVYI4ZpkyCRkID/D/IQECRxTpEGoTnutpVxrkbZ8avtZtZXafl47EW5iLdcHEZUitRQV WwoaLWIem8v53rXOmZ8AWvrd2+eb5X5nn73X3mvvd++1zj4knvwJGNM/Evlo9RtgFUaVj7Yq sEb/AFiL/Fi0PQ7Mg/5YWCesBBtjYZewBiMcKxX9LaAXIxwrC2BrrCzU3wQW6UlgF+c3c/k2 6gFz3Afs5Vb9lAc/74oJsPUNYB5mNIFnOgFj/ldgJeeXMNbob4sJsPgbIFmcAIsngIXofwJs UclmLknovxcTMLvpwCr9eiDNbgLPa4LarP9aTAQbp4FRxhjYm4ixvQ3sxawnYhU+Avaj5ynM SSlG+HtRij7fBVZhPGUY7dPAidgVZRjn94FLGGu4tgm9laHnt0QZs1SGMR8EFuh/ABJLZWDp PWAcfJbJdsYuLt/E+c2suYXzCeoTHB4CPsMlSf3fgL36I8B+/ceiDEy+JWZhVMeBE/VXgKVi DLBSfxW4hDGorwA26QeAUb0FGNPvFbMwkj8Dqf9Z6PlpYK/+LLBff0rMwg4fCVxK+mBjJrAW eexxtKrESr0LDGJdKnlvV6LP46ISHJ4SlWBsH7AKTFZiFTxA4qcSa+ERi9FDCFiqx4BBrMJi XpHFYOwA0Ku/BizAvBaDsTeARdQKLFF+M5cnwMZiuY3L+wlhUQFWnfkbcKkoAdaIHGAt55v1 B4ARfTf8o1RMAgbB1RIe+RKM/JRYIv1iJjAkFgD7xKViCRgIARfRGqNPB7CWsVn0ANeLQlHN u7cazJ8EVmIfVoNzwhrwUw0rlI9il1bDCjQxo8PALv11YFI/BuzFileDcyDiiUvUgJ8PgaVg pgY9fASMMsaoHK3+DOzF/qxBq/dEDdYItSr5Zg3WiPIRtA2inzpgHmwFMcL/AJbCC4IYZx9w CWMNmA9Cxoog+Ke/AezV6S/5Fuj0N4QLdforvn6d/n5wXKe/UtzO2MXlmzi/mTW3cD6h018Y fobzSZ3+xnKvTn+BuU+nv7vcr/9ABLFSxcBF+n3AxfoaYJV+NZBWLYhVGw2s5Xyz/m1gBKNq wlxeBZbCm5o4Qjah1WERRfl2IK1CFHN8D1gK34xiju8ClzDWYH2jEKeIYo73Ab36d4EF+mPA Qn0b0K8/BIzrLwPbGbsw8ijmSPnNrLmF8wnMJYo5Ur4f8SGK8WCNMaMHgIv1XwCr9KuAS8XV wFrGZv1BYAT+G8OYfwAkn41hzISl+qPASs4vYaR1iWG0vwR64ZsxjPZZYKH+DNCvvwSM63uA 7Yw02hhGS/nNrLmF8wmMJ4bRUj4J34lhzL8VMYy5CLhIDwKr9GnApSIXWMsY0R+VCuLDKeA2 /SQQbYG9+kfAPi7p1w9JBbvuTTkCmh8AE/pp4Db9E2CS872MffobwH7KQ/+49GJeHwC7gIVo +z5wm/4xkFoVcqtCtPojsF//qyyk6CGL0Oog0Ku/CizQfwss1P8TiPsp0K/vAXbprwE3c21C fxeYFDnAXmED9guXLMLcu4FVegdwqWgB1ogxwFrOR/TfAOHd0g+Lh4Be8OCHxZPAQozZj1hx EbALbPhhi8q3YbR+RIxLgEvF7UDEH2At55vFrbKa+axmPquZz2rms5r5rGY+q5nPO9HDaGAt MMT5EOebMZ7fA736PmCB/iKwUH8e2KX/H+BmLkmgt2ZYOQ18Rj8mmzGjn8k4W4+z9Thbj7P1 OFuPs/U4W29nzXbWbGfNdtZsZ8121mxnzS7UfgLs1QeBfVidLtR+LLvA8JtyE++KTbwrNvGu 2MTru4nXdxPvik28KzbxrtgMVl1yC+b4OtCrHwUW6O8AC7GOW7C+lO/S/wDczHnc8YFJrMUW rK8bSOu7Bdb9QOxq4FKxFFiDk8cWcEj5CPZJAmM7Cdym/xmYxNoleFQJjOo4sB/jT2BU78pt GM97QC9jAfS3YTzHgV3YddswEirZpr8tt8HWzcAajGQbbFE+ovfKJHo4CqQeknR6ARYyFkEz yfNKoreTwM1cngBXSdzdXMCk8AB7GfsJMbsAsEqvAi6lMwEswt9gkfIR/RXZC4t/BnrRWy8s vg8sZCyCF/TCIuXJYi8sUj7BuA2n21622AuLDiBZ7GU+e2ERK80We9liL1vshcXXZB8svgn0 6vuBBfoBYKH+ErAL3tQHK1SSwL7qgxUb8BmMrQ+9XQWsZYzoL8h+9PNHoBf7th/9/AlYCN76 MXIX0M/lXVy+mZF2ez9z1c8j7+eR9/NO6MfIW4FVeidwKZ1seOT9sEj5iP4qPNZCZ26cCkYD g/pdwKgeB8b0FeodWNnX1Dtwh0XEpBM+sJbzMf0l3K0twgPM0w8BJzKWiouAiOTAJYxBfTmw SX8fGNVDwJgeVquwAw8C/bBbBSsHgEn9Z8Be/TlgP+VhdwWwRr8OWMv5iH4/ZmI5MwjMg+ZS 2P0ZsFRfB6zk/BLGoBihLgWfK4FevRlYoLcBCxn9Ou5P8k7hAIb008A42FiKuwlhF+tv4vxm 1t/C+YT+NeAznE/q7wJ7Gfv0V4D94GopOC8FVmHMdJL5KnCiflil88xOIDFTw8zgbCOWAqNi BjAmXGoNRvsy0Ks/AizQfwAs1B8D+vUngF36r4CbuTwBizWwNQdYpc/GihIntcxJLXNSy5zU Mie1zEktc1LLnNQyJ7XMSS1zUsuc1DIntcxJLXNSy5zUMie1zEktc1LLnNQyJ7XMSS1zUsuc 1DIntcxJLXNSy5w0g5NfAkv1N1WK54RexkJGv/57leI5YUL/nRqh+yMwydiHPRah50R1HUVL YEhcj+fcLyvjBP3ftPQJMqr89JvLVyr/PnuuajHzqrhMzTPzliwdK54CrzHztqxyu2hX55t5 h5iMGiPvFD51j5l3KdvT+m6xSH3HzHvEZEupmc9RtlpSOrmi2TZEz+f8mWZvMvNS2O3bzLwi 7I7jZl4VeY4PzbwlS8cqPE7VzNuyyu1ipnOEmXeIi+1tZt4pvM65Zt4l/Wl9t7jCWW3mPeJi 5z1mPkfOc6Z0csU1rmMYibQ4TZ6NvMGzkTd4NvIGz0bekqVj8GzkbVnlBs9G3uDZyBs8G3mD ZyNv8GzkDZ6NvMGzkTd4fkz4xDScqa8E+sRt/BfnI6INvtcmGuF7PnEDchERZgygJIRcqyhG zWzRDPGJhShbjjN4DK3oqgHfDdBuBwaheQPaNUNnGcpC0AixXgCpBX0FWbcVV1GUtXKd0T6E EfiQAtALoYdOXK1GLgZbpBNHjzGUN+CKxhxH6yDqWzEa6qXN7DUGjRbTJmn4MMc2tklWojyX W3mujSihOcZR3sAtIlzSzKOOmfOoR80U7rmFS5q5xwA4MspTVlrQTzMzFjZH2YqSFrZq9Enz jGWNgCyGeS4G3ym2jbGTpTYw4MP8DcZpVC3QDcB+jK9oxrH0ehicGVZ8PPZWc15tzO0y1syM OHtGxFoHtzNmvRLXxbwfsldzIvfWwj10Mg9xc+Wz+aYVM+bfwOOn+RvrEuHdQN+GRVprH/oI p2djjHG5qRPF1Rqz9xhmYaxQe3qVArxHAihtGTav1G6ux0gCbL/etF/MO3Y5rxXVnOsDpefM epG5c0LmHrsavVwLD/rsnR5jm0HeiWRlZXoNUtycz/eWm/s6nNamnWuseCv0G3jvzINGvShi TidBJ8j93cxt27j/GCSMeUyFrGYpZp8abq/Y7H0q8p28A5fzqMPooROlxFgjz5h26vBeU+Xk rcbsV6b7W8JzMHZJJ69ulEcY430cZb8zWvt4DuQDDbyCIbbRwGu4jNum2LpR3IF5zzbbRrJq DP8JMicZn1jNturZZ85n17gm3XqsYJw5DKb3WJDrw7xDOrP2VZhn2mruLKOvBkbylLPnTfWG RxahFa0U7YZlaUvnG1XrOT1fOEeZ3lNR0WfGtRiPu35YfDl37qlocva4ZmYxQDMx5mJE2dR9 IpKO2EGOWa0cuwKfOVOD58AwTg2PbzPRmJWRj/POi3PLIPs/zaYh3Q9pNrPXfN4K/U/5RcYn pvJoyAeMyF/MaxUWHY/5ppVcOc13W6g+0hZta4z5bmiLhNsigViorbXYN7u52bcwtLwpFvUt bIg2RNobgsU3BJpDyyIhXyjqC/ha2oINkVZfNNAa9aE+1OhrDLSEmjt9q0OxJl80vizW3OCL tMVbg6HW5VFfG1RjDS1o2Rr01bdFWhsi0WLfrTFfY0MgFo80RH2RhkCzLxSDjfroFF+0JYAR 1AfCyFOTlnhzLBRGl63xloYINKMNMe4g6gtH2jBuGjZ6b25uW+1rwsB9oZZwoD7mC7X6YjQP jAxNfM2hVthqa/QtCy3njg1DsYaOGBqHVjYU+8xpToz6WgKtnb76OCZvjDvWBPsNq32RAOYS CWHaaBho8cXDZAY9LkdJNLQG6rE2TKidphTwrQ5EWgxbRHN9UyCCgTVEihc2LI83ByLpFShN mV4EcjAd39XF104bRnosEgg2tAQiK2kGNJrM6i0H12Eqrm/DxFtDDdHiefH6okB0ki/Y4Ls5 0tYWa4rFwqVTp65evbq4JdWuGOpTY53htuWRQLipc2p9rLGtNRY1VSnfGID5laS3pC0OSjp9 8WgDjGNAVO0LYAUaIi2hWKwh6FvWycO68Y55s1Eb4QusTzBurMTqplB9U1ZbfIda65vjQTQF Y8FQNNwMA8RVOBKCQj20Glpjxb6U7bZWLGRRaJKvoWUZNcp01ZpSPu+IWJ22IpYlGouE6o39 krZO2yTV10weQFEIVrBlyScitLGDbatbm9sC2UYx5oAxUiw8pguOKROPheMx0N4eqm8gnaaG 5vBZE7qQteCVmBpsaAxg8xcHouGO9HMTveFrozjfR0IDJ29xkbDruhiBM77xtCFkEdIM4+eM n/OxqB97PBI6St2F6ufkkL669UL1R4wgfcu+C9X3eknf5rhQ/ZEjSd9efqH6F10EfXwLevqy sD49fd7COFLkiDxRIPJxrhwrposJuMNPFPNxql6K2NqESB0XZaJbzBL3iwrxkKjE88tisQt3 2t2iWrwiasRbiMB/geagiEqriMk8qciJcoScJr3yelkg58pCuVgWyWXSL9tktVwr75SbZEg+ KJvlj1DytIzLX8t2+ZLskq+h5ojcLE/KLfJTmVCscpvilc8oY2VSmSh7lWmyT7lB9ivz1bnK UvUOpUldpITVxUqXWqX0qEuV+9Qa5UG1VnlYbVZ2qhFllxpTnlPXKC+o65QX1fXKG+p3lGPq CeV99aTyN/V91aF+oF6sDqjj1A/VqepHapn6V/VW9ZS6SP1Yrceah4fzpsb+G7w9Bd6eB2+/ BW+/A2/HwNtfRRO6jcoc+pkCeJsK3krB2y24uh28BcBbM3hbA96+Dt6+Dd52oOQp8PZr8Paf 4I3+pfdt8PY+ePub3KI4wNtF4K0QvF0B3q4Bb7PB20Lwdid4WwHeOsCbBt6+Ad62greHwdtO 8PYEeNsF3vrA217wth+8HQRvfwJvg+oJVagn1RzwVgDeJoK36eBtNnibD96Wgrcm8BYHT93D ebOdzuLtEvB2OXi7CrzNBm8LwNud4G0leOsEb18Hb98Gbz8Ab0+BtxfB2+vgjX5u91+iRrpF UI4Bb3gOkleDt3ngrR68tYG3deDtXvD2XfD2I/D2c/C2G7ztB29HwNuHsk0RMq6MkO3KONml FMtNSqncrNwK3qrAWxC8hcHbOvB2L3h7ELw9Bt6eAW97wNur4O0weDsO3k6Dt/9Sa1SbWquO UJvVfDWiTlZjaom6Rr1GXYe9tB68fEetA28h8LYavN0D3v4VvD0C3n4K3v4dvP0WvP0OvL0H 3j4ezpvrL1m8jQFvReDtWvB2E3i7g36GDt7oDNQN3r4J3raDt5+Ct+fB2xvgbQC86aJaFoC3 SeBtBni7GbwtAm9t4K0HvD0A3n4I3p6kn/mAt73g7TB4+wt4+5sMKU7ZrBSAt8ngrRS83Qbe loC3BvAWA29fA2/3g7d/A2+PgbdnwFsveDsA3o6Atw/Amw6PcqiL1dFqFXxtqToJvE0DbzPB WwV4WwTe/gW8LQNvTeDtLvB2H3j7DnjbCd6eAW97wNur4O0oePtQ/atFqKcsI9SPLYUIZ18e ztuI/CzevgDergBvM+n3J8DbUvC2ErxtBG+PgLenwFsveHsFvP0RGkNisbxELMH+qpYV4O2r 4C0I3nDalPeDt8fB23+At/3g7W3wNiALFSmLlFzpVy6V1cpUeadSDt4WgLcAeIuAt6+Bt63g 7Ufg7Wnw9gJ42w/e/gDeToC3v8mk6pC96sWyT50s+9Vr1bnqzeodYGuRGgBvYeS6wNsG8PYN 8PYgePs+eHsavD0L3p4Hb3vA20EwdgLysXrSYlXft1ysfmC5XB2wXK1+aLlR/chyB3hrAG9x 8HYPePv2cN4u+t9ZvH0RvBWDt0rw1gTeOsHbveDtf4G3PeDtNfB2DLx9IiqkQ1TKy8HbHPB2 O3iLgbdvgrcd4O1n4G0feDspFcUlRyj50ou9VKDMAG9zwVsVeFsB3u4Cb98Ab98Hbz8Hb33g 7SB4+wC8/ZfcpLrlZpV+cvRlmVBnym3qrfIZdQl4Ww7e1oG3b4O3H4C3JHjbD97gp9g9Verf 1KUWRa2xeNRay2i12eJTI5Zr1JilTF1juUFdZ5mrrrfUqt+xxNQTlnXg7X7wth28PQXeXgBv fwBvA+pfrVI9Zc1TP7aOF8I6nc4dDjv+83qLiirWdnc7rNJhP5JIDPT09AzQhS3co+HTE3bY pMMx0LMBH9RYUDOgafhPG3ahsdqMCk17aEPFDL5AgyFq5ZDSYdHMj0MVDovP+CTZTk9ie3J7 ItFDvVlNrQGHQzpcu3f/CJ/vfpd769jAnw5uw6OEntOeVWPjOXBVooe7s9UltHKfN1HnsAqH bdA0mxqc0R2R0N1dUVFU5PU63MLh3uDb4JtbPrf8KxCf5tNsVmmzDzg6enrYth2j6yEbNou0 WcM02jCXO0gFSqwf7hnUtA6HBZMtKR8opw+UbLaORKJOCxsMo6cnX6QmBkHCmLpL1R2qT6Qp omloGnG0PTGMSZtD2ly7frMJHzZp9GVax4dGZbMbYwXvdGEM0OGwqdJmOWL0glnYwlqyxHvE bhF2izHYEu6GtLc22azCZu3p8ft9PptT2Jw9Wo92B6L3OIhRhxp/jyOjhrlmBio0Fbcstbxc cyjCppbToQ4XNiltqkYXmsRHJS0Haam0Dfzbt6vgzur3b3dbhdPqcHi9PupY06QqLJYj0iYs tiGgbhtyKTBGVfQpL+dLytBH01QV/W3fvp23ABPD1OCibjtTPGjWwIavPH0RdjhMtZISvz8x iM3Be4j3plkzo5y3gnExyEOkZTbshNM1YSbde+Rz/A070k6+o2mm7/zz/M1+fn9zSoe7V+vV dkAegNAqO+BdzhkV3fjARNq5yO8cmZoy9X/E7zyf43dOq3TatWzHsxmOxxWOtOdRRV1igCos wgnPO5/rpTr7DN+zZHzPaZFO+J7pfE4pnWla/1veR4HjyeRZ3sexovz87mf7HPezZdzPlnK/ 7KH+A/7nNP3Pafqf88L8z63AWsr/4Hd8nXJAwwOdhgdim2Q8EBcZD+SalAcaF6YH4iLjgbjI eCD5TNoDqSbtgYadcLom5YFOp3A6HWIUhOibLdbzwjtt0umgfgaxMwdxT3E6yubwZOaU0ZVz cAPt9G7U0d4Z1AwXzFwNasa9yOmkdvd1d5vtqNEZguF7hzan1Wt+jrD1DYZX9mygPm0pxUGn Szo9SXweKX+k/FssWyBwP6erbM7d9IEp6oCHznvYSXVijrg7LXNwypFaRq0HwYXHTrd4ptlp F077mdSQ0mNnx2fSqOfZIIxoI/ocwumWzhzy2XtNr71SI6+1W6WdVq8DW9dlky4HGj67B1b3 PEtVxqmiJ8xVFosltgVVW2J2m7TTfXxI09a6LMJlTbtuOTTt9rW0lBoUOob1iWkwsab7ah5V d2b8Fx7sskoX+brJrktKV2YZNLtT2j0/E3s52BnCAzH7Tg1qg2HWLN/zLJFMl+bYMQu7RdpN j9YoT9GpjpaWFjo1kxLuj7vDhIkmclf4q90l7O6K8oryyRrJSJxdjWpU+v09rixV7G6XVFyp sI15WxShWMjNnArdvcvZu8s1u5R2zJTcW8PpXrGQJiZPdRaQYrslkUhYrAKZW25J5NiE22ax DPNyabEekXZhtZ8BnrGfyVGly+rLcnMfl1DG+FDPFvSMjhPm7jJ9na9MX/cNmnVsrDxzZexD 7FF7flHRLbf0DDkcKf+CvzvMXuDwhsez5hAPGWNO2wun6wyfh9O7nMIFp8+4/XrsY/YUu3Q5 2SHIvYdcDlzOmm1Mb/YsunQNdbOP3Y1a2ndDKV8f4o2Vdn2Nlbnt/Xffbbaldjq3Pmvb8Qb3 pv2fe96QuitvoEt7WnfI5ZaunGRdsg4BdPs3fd+Eu93rI7eDn7vcs8yppD6z4encH03LiAdu 13n1rhcimSYAIWHDhm6eE/lnnZf4dtmFy5GOCd70nIygw6yeGxUcggacu8GXuptnRQbDnSxr sf3dNukmL84ODXYzNHCd5fyxwW0RbooN6eBgR906clANZ6q1w7v9u9HBbZVuptoMD24p3Vnr 9E+KDzTVDo67A/+M+OCWijsVH/7hAOFOBQi33QgQlPm8AOEQVocOPOPQc1XpzgoQFBi4KBMh zBDh5hDB29R8dCMCrYrL4UsHCbOWTfrKh9KXHWDTvAnkp+MEX67FyLNqy8rNXWBcpiNFedpu x4Z0bYe5UI4Bt0u4XfR/yJB8CVKurdfQVblW7rZLt+ktHC/cDlwXBoz5lgcK6do1uNGIGN0b B3kzUsQwQ0bmmkFzO6Xbfamo08oF1kncb/Sj1WmXCq7K7EM9a0+evUfZI7yZaMKj7E4fJ7rJ aiacYBQ50j0imZ/M3160vShxS+IWitD3OO5xdDvY6lhRPyxWzMb1WGHOnc9A7Equz1D9IsJK WtkIKzwEUIzJlThofdx24c4KLN6zZpvpbpbg5SDy8Z/2JV4QWhgPhCfSjWHf6DWkiGa03Vvu LTf/vQCRBqvqsUuP04gJdJ7Z8+ywhy2uVfApvYlqbyo1H6so2qDWKjzWGZlwQ3vAkYk33WvP 6ry72wj1aVJyVN2VHXJ8SY9NejhEpVbII6Une0E1h1s6cn+Z7PNtyBJ+FEsZGfZc5s7UcOjh 69RsMDF+HjNjj2aehinCI8DTOaC8fNCY2gzu1TAAGvB45jjv41kqBBnPkhR0EIPc2erwMo9U POlT7LAoRE/n1nLzKQTPJFKhh1BxVhzypOKQJxWHPByHcu3CY1eUVCQyA5F1eCAaoUoPBaJy 0zxyPi7jXCoScSjy2CkU8YY1+ExR6naW+BPm/jzD1x0bQKaFolHmGuFIUbChKRJ4Ro26rKJi g44QxPVGPFK4nq6NgJTp/4w5C0wjbb/CgMx4aAUtgx638LhzRa74AsuV2pVaXXI9DgV0LvA4 pMc11NfXt2eob/fu3X1DHicKLhVhrU4ks6QOJZcKOK7Hc0bsxpN+MuvTq+3WzgjezWfoeohL z2QKzhh63PxSLVxu9N1vNq9LhpOXalyZ6VPPNpD0KNgRwwrgW7b89GdrmCeyu2/v3oMDBw/u 7evbTdYdWS3OeHKlx3tk7JGxA2X7phxsPtj84ry9e/ds6d+y27Pb43FLT86lYpVJS0rqkquS mLZBEvPDfeV6PltbE0dECbM4JPrEbpY+QXnjqldjXsoak8kjHWNzbba9HR6H8Dj1zGzyz+Ii 8wlo1wteT8McCa2nsbK0xp4R0jOy19Zr272xfkv9lsa9jXuvOTi9qqwjvyS/hJ/M1vbZbOv6 +l5uz3HIHBd1evjYbvocO2w8uzaypcYyrlfxmbmc65fPpAdHDLyvD+u5rCzHJnNsZXV1dYN1 5sdD9euxmfrWJtehxbqzTezenaPIHEsyiTif+ngteo61pESIksznSI5d5jiptg/rOXBw794+ s2HWx+mRzhGHj7xX0jdM+Ok2bc941m3kfGOZJ6vu2GHaRlSQnh/myo8CB4+kTNBDb8ceWijP lg468Nky053BfZt2QA496NK/gdULkmsgYyHOXPxHO6w+f/nW4NbpT5YN5Nfl1+GRwunY3dhY ll/W2Ljbc/62+ZASkaMoOVl7H8xZValYMYIkDqXSiRz/rJsLcDdyWolfQRTTrcnK+jmGvhW8 OsY17t2712oXOY7Gxsa9PSPtItdus3k8Huw8Yp80k9IirbYBSf9mpGv4OoMvrwUrblSbnltX V8KFnDM/VG/F3nDspQ/7jrkAqTXwuGZ0HEztdZ0L1vaBfAwiv6QuU2Ars6G0by17U64oFKNB zATRKG6CL+maTZCw9jpakLWmNhUUYhhJdlnToo7ebeYU02Nq5IGZGpyvv55GMSjM3yxwiR1K lVDrOyPNYtTySMNKUdociLWKeaiRty+c48MKCV3nnxnZRA4eYowrKUCquJjLjRIFDzcjMIHR Qr3V779FXLZwwW0+UfLVhZU+nFQMHfrdDq+4hK9UWBiZ7h3HNBxcxphXiH3iIlEgvlAfjobF DxkfZ3yScRfjc4wvrGyItIoXGV9mPMB4iPEI4zHGE/SrR+IjQmljLGAsZpzDuIhxRcvKlpVy HeNGxvsYH2R8mHEn4xPp39D4eygvEB1gUgUHNjAMHwIv///KFKxDzj/8TRuZfgeYfmu1W3xL 7BBPixfEfnFUfCQV4eSZOszZnhD0+/cq2o1CPJD0czdZanz3bDS+vzeY1Qb77f0dw66lZ2j4 de6E4dcj84ZfX7Rt+PXlZ4ZfF51VP7lg+PX0EuFUsq9PZdXbhLy5bPj1vHvx7cKeLhJ++n8W 0KYbVJUofrFe+aHyhtiufk/9njhgiVkeEa9ZX7X1SNV1uysgf+n6Oh5nXvR4PTcqN3iWeh5W OnOCOSuUf89Zn7NF2ZOr5DqU/bmf5H6i/E5I7TRxY3s9Z9d5ZR/kUM47WXLclH3nkVO549JS BCmFVEBWsGw9W3L25e7I/bn3QVO2Z8njJHQePo+4RvrTcu/IB9Jy2pC8seeRYsj0Uduy5IeG cM1ZMurpUS+m5eWLj0COkYy2nE/yikfnjS665N4seYDlhfPKvks+TUn+qPyCtFSYMve84mdZ ZH4PF81E0utjOZAWo/Vb+QNjJo8Jjnl4zKMkZ/c+5onzidH7mGfHHDXlVEbIyphP2ZZG6Yvz xpemZd74hWkJmrICoo1fcdk0SPnlxZdXjF8BLL78hQkvTnyd5VRRNSQ8aQJkyqSjkwaRjk46 M/nFKx4mmXT0iueuOH7F8SmWKblTRk35FeRA8SyIv7h66kOmPH+ldtWEq/40/VvXTIfMujb/ 2uprO2Y8bcpzM/pmHCidDJlRunHm4etsLInrXmAZmnXNrJ+Ysuu6IVz/ZNYAXw1cr1yvzPrJ 9VPK7yt/bnbxjVWQt25uui5haON7wNC6dRbp3Tpv7ri5JXNnzX20cgKLv3IFS0flxsqHgB2V L0GOzFszT5v31m1hyIPz66Dln//y/JcrXwIephzk6PwT8z9doLHsXLCX5a0FJ5DeWnDab1lw GvUn/NX+w/6jX4lBvrXQB72dC04bNQvXLDi98J2F79/hX9RXVXVn3p1j75yw3LK8evnB5Z+m vpumQJ5u9baOC3eEu8PJ8NHwifDpVZZV01ZVrGpcFV61ZlXPqgdX/WTVrlV7Vu2PhCPfijwa +SgqonnRW6LLos9FX49Njy2LPRRfFO+JPx8/1W5rn9J+U/tP2o+trlj9acfYjps66joiHQ91 PNFxsHNc57907uo82PnpGs+a0WtmrJmzJrhm55qDd02+q+Kumru23vX4XYfvOr22fO2atc91 2brKuyJdT3b1dQ2tK1jXtG7nuhPrS9d3rH9C839GrNp1djwaHm209oxQHNG2Z8SIIJ/he3PP 9rjhfmLs9PNGnVTkyZLhsUPrywhFB+1ARoy4QDHU+3h+3yUPIA4fmjWAqMkxmL8Rb0f6EV+3 5u7wPpizLx0zoTvy9Pggtc3Zlbs1EzsNlhCdKzj+Glrjcnek2KNSisWse4jqWd9kEP3uynkH kXwHWhzi3vZhdA/i+xBL5u5w/Ky7QkXWfSBzJ9hB4z4n+j9+TvR3mTH/Xo73HOW5H7TOrUB+ ayoSYj0eNdcLscmIP0Z8M9cRMRERkFYtmI6OqRVFjMufqx2lFpk1Hr9QO6odRW+kdQp1/jFH xy88d08gDh7IiqjnibPZcfXcmGpG7j7eTUYUnZeKnxTXUQKr2okxj6JkYb7/munzXx5tMe5j /I171iWfXnwEuyovdfdJ3VXyxo62ZO5Axq6kextrW0gDbV8YnUc1VEJaVJ43NmdfaqfmF+SN xR0wj9pT3ijN3Eez76Q0Fr5rmvfNrDtnHno4+z75wLC74z7zzjgqNXrUf2pYJ/uV/ouP5Fdg PMPYJ9aIY6xUlsemODY8kdg0dsr4IPieS6tJTOT7R23j9X6U1ibLq0vHPIG5pu6wB4xetRP5 mnbCELJA3+MX0qpQzthp9K2duLz4smlGMu5wl03ju1KW0B3OuLvx/fH/UfiemiXnavCdNkvM O25azm1Bd9p/TPhefMGSvmN/hpzNFEn6Pv4Zwnf2CxY+bVygnM0On1Gy5Fz++OySJbTvjZX+ x+Tcnv/+6C5MDJ7p7JK74zrb3HHXDeUcolMPS4JLbHTS4avE3HF0BjLrIDhBzaBTk1FKsZ9y JHw6quKTFZ2hBmYN8PkIpyPkXrguwacTLX2KIdm5QJt/eIFGJxi+2mmec4z8TpyCjlIJnWio 3XxT+MQT47MRdLl2J+GYJ6C9k05TiBYT5h/mc1eHKX4umUCnLr7yzz9Mccmsg+DkVoKzGp3Q qN1GzkH4nBbm8xx0+aSWPq9V+q9XmJEh4uIrMYOJ62w8H4zYGGnlS9w3WdrIfXG/wz3x3BXN 3gcTXzeuhI3ec6fepj9H77ijN9zR2+zU58W1gt4CtI/f3Ua5E/weJslvoVPorXL8Tjm3+LE+ JPboQ7JOXCQDYqFcJsbIevElGRQj5Up+v910ej8bv5FN8vvXLND1QHckdD3QdXF/7/Ib15yS 3t1SJ8aj/g7UfxH149HX5ejrS/Q+NH4DmpveX0ZvLFPXYhxd+i8w3lL1bf076juiRH1XTFPf E1eof9ZfUY/jaZd638dvJ7PQe8PorWH0hjB+P1iHGCHmCi8SvSdsJhK9KawBqRGJ3hdGbwuL I7UjrUbqQOoUHrFG3y/uQlqL1IW0DulraL8B6R6kjUhfR+pB2oR0L9JmpC1IvxRzxK+QBpE/ g6SLSVIgSSS/mCm/grQQ6XakryKFxAJ6Rxm9oYzeT0ZvJ6N3k9GbyejNRerdwqd+TRRavq/v t2xHegRpv5hkeRXpANJrSK8jvYF0EOl3SIeQ3kQ6jPR7Mcnq1V+xHtH3W/8iPNYTyJ9EGtD3 26xirm0Svq8Sk2zX4LtZf8XWgtSK1IYU19+ztSOBGxu4sYEb2xokcGP7qZhpexLpF0ifiJn2 yeJS+xVItWKSvQ5pGdIqpAhSJ5KGdDcSOLInkL6J9H2kR8Qc+4/xfRLpfaQBpA+RPkL6BAkc OuqRgkgNSHFxqVOImc5R4v/ydu/xcdXlvsdXZtIkTSbc70VLoKCgiCCIihdQqQWlbi8golsj ihpURJCLugstQRC5VEWgiIhKQUBb1NitiIQCrZSUQNImacjUhjadJpmupEmamUwL+DvvNTvy cnvOeZ3zzzl/fJzbujzP9/s8z2+tWJezy7W7rfykteTdcPlZafur2hZV26LajlJtp6m2a1Tb x1Tb+artDNV2avJEs+TpZcmzy5InlyXPLUueUZY8oSzdGu5PD6izXJROb1ODw9GnynW2tfyc sr1f7YrPRMf90/HnOf7ljn+645+cPEcseYpY8gyx5AliyTPDkieGOd5fHO+caA9H2eEoOxxl L0d5naNc5CjHOcpxjvIGR0meaLgpebpX8myv5BlIybO8ypk+493D0UGO8bhjPO4Yr6/4bPiz 4xznOJ91nBMd52OO856KpvC8Yx1XsST8yZ6POl6l410usi865r4ia3a0G9NbwqTo2tJDunU4 Ojadn+7YvR31GEdtctSTHfV0R53jiK93tPXJc3d03lmyPDuqm54wr5gkyWS5M2oOcXQtvovr cD2+hxvwfSRPe7wJbaEUrcWzaMdzeB4d6MQ6rEcXutGLv4UQbUI/XsRmbMFAWBttRQ4TIRvt 1OeTKKCIKZRMt11+342X8DJewd/FEkJcEaGiPBUH0uepsE+HHenPeG0MOyrXhbhyPbrQjR5s QC9eQB+y2Ii/YSiUKoeRx3bEGMEodmAM45jATkxCLJV/RwhrZ+wT1lafGkrVp+NMfBDzw2D1 x72ejfP8/il8Bp8NcXUjzsdX/PYNr5fgm95fgSvxLZ//w+tCr4twnffXgw/Vi73+wOsPcav3 P8ZtuB13OP49vv+l90u9/7X3D3v/KHhUzaNqHlXzqDobQvVG8KiaR9U8qn7RPpuxBTyqHg7Z 6jy2yyXGSOioHsUOv4059jgmMOkz76qLXqd85lHN5/EFXMCvVHRLtF955UpHt6jds5OnOfF3 hk/LfDrTpzNU+ar089EbogrfFqP3q8ysysyqzKzKzKrMrMrMqsysysyqzKzKzNp6UKWVVFpJ pZVUWkmllVRaSRXFKqaoYooqpqhiis6XPM8rm/73aEb6czhfBX0+DKiarKrJqpqsqsmqmqyq yaqarKrJqpqsqsmqmqyqyXKyyMkiJ4tczHIxy7ki17Jcy3KryKkip7JcyXIjS/US1UtUL1G9 RPUSVWOqxhQtUrRI0SIVs1QsUjFLxSwVs+WO7YuqaXmaTq6x9j5m7V2R7rDWdlqFrDZlffMy 7JTh5rK+/+FT8vzZQ+l7jSNsiM61TjZYJxuskw3WyQbrZIN1ssE62WCdbLBONlgnG5zprdbK OdbKOXq2S8926dkuPbtZzxb0bEHPFvRsQc8WrKf76Nmcns3p2ZyezelZfkcftG6eqE8369N+ fbpZn/anz4+OSn8+eVpsdK11dLZ1dLZ1dJa1s8Ha2WDtbLB2Nlg7G6ydDdbOBmtng7WzwdrZ YO1ssHY26MWcXszpxZxe7NJ7BT3Xpee69FzOGtdgjWuwvjVY3xqsaw16JWdta7C2zdErOetb g/rvUv9d6r9L/Xep/83qf7P6L6j/gvVvH+vfPuo/p+a71HxBzeesgQ3WvwbrX4P1ryGp9zBB 6wnXZ7eE73Jgnnm+2Ty/jBPzOHGfX29S7aen17mS6gp/T3dH55fdy9q6z1a9VsxbwlU+nW/f dfZd79tT7XuLfZ+275n27bLfJ6Oq6T76hC27bdllyzPL11dJzfyqfKQL/P4evz/n9x6/n+JI N/j1t470Xkdqc6Q3l7d/oXyduKn8n8WotmLPaHbFefgqvoav42J8A5fgm/i+lX7v5NmPydMe k2c9Js91LF8b/Tw6MP1odFL6Cf5viY6wan/MVeI+Vu5DXCUekR4yGYZFkPfd9ugk6/kl4Ql7 HOCa8vBkTbf/V6MzrGDnJU9Pi85If6Z89XVGtIfIZolslshmiWyWyGaJbJbIZolslshmiWyW Pfez50X23M+eF5X3rLdnvT3r7Vlvz3p71tuz3p719qy3Z709k+caH2/P5MnGx5f3zNgzY8+M PTP2zNgzY8+MPTP2zNgzM73nidN7niiTT0XHeHdMWeOW8jXCVPLkxuS5WPgIPoqP4eNRrWu3 Wtduta7dal271c5M/nvayuTpi8nzAaevNFaVPdocdVW8PmypOBrH4A14I47Fm3Ac3ozjcQLe ghNxEt6Kk/E2vB3vwCl4J96Fd+M9OBWn4b14H96P0zEXH8A8nIEz8UF8CGdhPj6Mn+Au/BQ/ wz34OX6BX+JeLMV9uB+/wgN4EA/h1/gNlmE5HsZv8Tv8Hi34A1a4Wlvp9YnQV/EknsIqrMZf ff906K5Yg2fQhrV4NmyraMdzeN4VxHnuVj4TOipXu5L4K57GGjyDNqzFs2gP3ZXP4fnQPWPv sGXGftgfB+BAHISDw5aqxbgTNKj6WdhWdX/YUfUrPIAH8RD+4PunvLrarFrtfUforlpv+17v i2FL9WvwWszGYWgIO6oPxxGYgyNxVOiufh1eH/qqj4ZaqFYL1XyvPsHnt/jtlLCt+p1ePxp2 1KTClpo0KjEDVahGDWaiFnXIoB57YE/sBfnW7IN9Ie8aedfIu0beNfKukXfNIZiFQyH+GvHX iL9G/DUNOBxHYA6OxFFiOiFsq3kL3h66a96BU3x3KubiA/is7c73+kW/fcl2X0YTLsRlfluA q3A1FmKx7++1/a9s/0Doq3nQ54cw4btC2DKzAnKduW/onimPmfuHbTMPU0PfKT9FlDoV1Kmg TgV1KqhTQZ0Ke1RQp4I6FZQpP2t0b+yDfbEf9scBOBAH4WAkTyNNnkU6G4ehAYfjCMzBkTgK r0uesOsu+2gcgzfgjTgWb8JxeDOOxwl4C07ESXgrTsbb8Ha8A6fgnXgX3o334FSchvfifXg/ TsdcfADzcAbOxAfxIZyF+fgwkueofgQfxcfwcZwt7nPwCZyLTyJ57ulVuBoLsQjXoBnX4ru4 Dtfje0ieyZo8kfWH+BFuxY9xG27HHUieP3oXfoqf4R78HL/AL3EvluI+3A8rYMUDeBAP4df4 DZZhOczaCrO24nf4PVrwh+R5sMnzWPEknsIqrE6eeoo1eAZtWIt/nSJnh88lT421DuyZPMU1 eRJq8gTX5ImxlSZepYlXaeJVmniVJl6liVdp4lWaeJUmXqWJV2niVZp4lcvdozyM3+J3+D1a 8AeswJ/CSOUj+DMexV/wGFrxOFbiCTyJp7AK7VGm8jk8H2Vm7B3VztgvqpuxPw7AgTgIB0d1 VTeFkaqbQ1y12PvbvV8SBqvutCbxoDzNfu43uVTd5zcxV4m5SsxVpnTVw2Fr1W/xe7+1IJly /2n7P/ruEb//GY/6/BeIs0qc5en3tM9tflvr9VnfteM5PI+OKFO13rnd21W5t6vq8d2GMFWe lH1icz9XNWhf9yxVsfeurqtcXVftgHuWKvcsVe5ZqnZiEgUU5TYVtlbvEUaq98Re2BsHhanq g3EIZuFQvCaqrX4tZuMwHBVlql+H1+NoHO+7E7y+BVbZaqvrf03dKFOTiupq0qjEDFQh+Zfe NZiJWtQhg3rsgT2xF/bGPtgX+0W1NfvjAByIg3AwDsEsHApx1oizRpw14qxpwOE4AnNwJF4X Rmre4B7tjTgWb/LZlULN8d7/YxKf6P1bcTLehrfL4x34kPdnwX1uzYft929hVc1H8FF8MkzV fFacX7Tdv05p97s17ndrrsACMVyFq7HQ9jc4t/4vT+3bvS5x3DvxE9yFXzneA/jHFP+173hY U7DvS2FqZhS2zqxI/qdMIZ5Jz5m1Xvf2/b5RpjzZrVAzD/TdQTgY5vHMQ5O/SyadPn1dtSB5 wnL5Gu3JV7+/KHmmcfnvKMn11mg0IzUvfDp9VnjK1Wlt8rctv41Eb0y9OeRTJ+JkvAfzQmfq jLA29UGc5ar87LDJ1cVGVxcba88Na2vPw/UhX/s93IDv40bchJvhXq52MX6AH+JHuBU/xm24 HXdgCe7ET3AXfoq78TPcg5/jF/gl7sXSkM+8IeSjtEiLqXPdE1/iHvoU8RfEX0i9I+TEX0i9 z+sNYXPq++5dPhUda34da8u1tR8LudqP4xx8Gp8Pm2svxFdxES7GN3F9KMitILeC3ApyK8it ILeC3ApyK8itILeC3ApyK8itILeC3ApyK8itILeC3ApyK8itILeC3ApyK8itILeC3ApyK8it UHdm2Fz3QXwIZ2E+Pox/w0fCZrkXeHhy2MChZ1NlH8Oa8l8OZ8v9AXk/kPpUWJ76Ar6GG8JK GiRP++6T+wNyf0DuD8j9AbmvlPtKua+U+0q5r5T7ytorw/Lab+E7WITvhuXiWimuleJaKa6V 4loprpXiWimuldFpHGjiQJPYBjjQJL4pFTSpgibF2S+SXpH0ps/++2T63L8XrC71nDkuefo9 d46bvsdfpbomVdek6HpF1yu6XtH1iq5XdL2caeJME2eaONPEmSbONHGmiTNNnGniTBNnmjjT xJkmzjRxpokzTZxp4kwTZ5o408SZJs40caaJM02caeJME2eaONPEmSbONFGglwK9FOilQC8F einQS4FeCvRypil6HxUaqdDIi2eo0MiPZ1LzotfIfr7s50//vfXG6fvpY6hwQPJs8+T/zSJ5 uvn0X4k/yatnePUMr57h1TPUmE+N+dSYT4351JhPjfnUaKRGIzUaqdFIjUZqNFKjkRqN1Gik RiM1GqnRSI1GajRSo5EajdRopEYjNRqp0UiNRmo0UqORGo3UaKRGIzUaqdFIjUZqNFJjPjXm U2M+NeZTYz415lNjPjXmU6MxqlYLkzLOyPiHMr5cxvvI8CoZXhEdTKNV9FlFmx7a9CTPKU+e y+3XW+W/Sv6r5L9K/qvk3yP/Hvn3yL9H/j3y7xFHjzh6xNEjjh5x9IijRxw94ujRK03hV/8y 7yajY1MfMePORZM5d6EZ9xV8FY4t4hdfnXULzIyrw9q674R83X9gAa7C1ViIRbgGzbgW38V1 MBvrzMY6s7HObKwzG+vMxjqzsc5srDMb68zGOnOxzlysMxfrzMU6c7HOXKwzF+vMxT1mohZ1 Zl4y2fPl2At6PKfHc3o8R7fkPv0ov67Tuzm9m9O7Ob2b07s5sRfEXhB7QewFsRfEXhB7QewF sRfEXhB7QewFsRfEXhB7QewFsRfEXhB7QewFsRfEXhB7QewFsRfEXhB7QewFsRfEXhB7QewF sScz69zwArWfpfATr86sJKP+6AQZtfh9i9+nuPEyN17mxsu27bdtjW3rdEqtTN+kU2pl+6bp vwH9lUMvc+hlWbbIskWWLbJskWWLLFtk2SLLFlm2yLJFli2ybJFliyxbZNkiyxZZtsiyRZYt smyRZYssW2TZIssWWbbIskWWLbJskWWLLFtk2SLLFlm2RCfJpJk3a3izJtUUHcqfNTL4vA7Y pQOKMrlWJgdO/2XmwOQvMzK5I/lrFu/W8G4N79bwbg3v1siqWVbNsmqWVbOsmmXVLKtmWTXL qllWzbJqllWzrJpl1SyrZlk1y6pZVs2yapZVs6yaZdUsq2ZZNcuqWVbNsmqWVbOsmmXVLKtm WTXLqlkfn1vu47fJ4vnp/85prqhvFfXvozr5tsu3Xa7t8tpfTvv75Tb5tMunXT7t8mmXT3tU lbqMr5eHXakrwrbUteri5jCaui35S7tvd6euDcWown/uio62RTF1pYr4Fq4N3anroprU9fa+ KQylbk+eXR5eSt0ZXqpzfVvn+rbuNXgtZuMwNOBwfME2F+CL+BK+jCZciK/gq/gaLsLXcTG+ gUtwKb6Jy3A5rsCV+Ba+HV4q57NbpAOpBWFQLltTPw47Uu70ovNSl6j2S3GZb6+U5bdwdehI LcQiXINro/1T14WHU4tt94PwYuqH+BFuxZLwiPweqUuFZ+vSqMQMVKEaNZiJWtQhg3rsgT2x F/bGPtgX+2F/HIADcRAOxiGYFUZpOErDURqO0nCUhqM0HKXhaN07QkfdKXgn3oV34z04Fafh vXgf3o/TMRcfwDycgS/I4wJ8EV/Cl9GEC/EVfBVfw0X4Oi7GN3AJLsU3cRkuxxW4Et/Ct8Mj UaXK2UTF9VTcnLo9jKula8OEOpmK/o0LJS6UOLCbA0mFbbbiFK04RVsUqVyicskKU7TCFK0w RStM0QpTtMIUqV+ifon6JeqXqF+ifon6JeqXqF+ifon6JeqXqF+ifon6JeqXqF+ifon6JeqX qF+ifon6JeqXqF+i/m7q76b+burvpv5u6u+m/m7q77bKFa1yRatc0SpXtMoVrXJFq1zRKlek bom6JeqWqFuibom6JeqWqFuibom6JeqWqFuibom6JeqWqFuibom6JeqWqFuibom6JeqW9Nzl qjvpxQU0vUp1XxvtQe0Bam+h9o7oYhq30rhVpQ/Zcg2tB2g9kPq2zwvCsL0mVH6s8mOVH6v8 mA+v8KGVD618GE/dEp7WARt0wAYdsEEHbNBLz5oNf+VRN4+6edTKo1YetfKolUetPGrlUSuP WnnUyqNWHrXyqJVHrTxq5VErj1p51MqjVh618qiVR608auVRK49aedTKo1YetfKolUetPGrl USuPBng0wKMBHg3waIBHAzwa4NGADol1SKxDYh0S65BYh8Q6JNYhsQ6JdUisQ2IdEuuQWIfE OiTWITGPW3ncyuNWHrfyuJXHrTxu5XErj7t53M3jbh5387ibx9087uZxN4+7edzN424ed/O4 m8fdPO7mcTePu3nczeNuHnfzuJvH3Tzujpo4mONgjoM7+f0kF3dwro9z2zk3yrlRzo1ybpT/ Gf7/nnsx9+LUjb67mdOLwzIODnFwiINDHBzi4AgHx9XJY1zs52I/F2MuxlyMuRhzMeZizMUc F3NczHExx8UcF3NczHExx8UcF3NczHExx8UcF3NczHExx8UcF3NczHExx8UcF3NczHExx8Uc l0a5NMqlUS6NcmmUS6NcGuXSKJdGuTTKpVEujXJplEujXBrl0iiXYi7FXIq5FHMp5lLMpZhL MZf6udTPpX4u9XOpn0v9XOrnUj+X+rnUz6V+LvVzqZ9L/Vzq51I/l/q51M+lfi71c6mfS/1c 6o/ezKUil4rlbvwvFya5MM6FcQ4UOZDcN41Td5y649Qdp+44dcepW6RukbpF6hapW6RukbpF 6hapW6RukbpF6hapW6RukbpF6hapW6RukbpF6hapW6RukbpF6hapW6TOOHXGqTNOnXHqjFNn nDrj1BmPjjEZXjYZXtb9sfW8NnWjLG6SRTl672/HEuv9ndbtWa7qDsVr8FrMxmFowOH4gm0u wBfxJXwZriBpPUXrKVpP0XqK1lO0nqL1FK2naD1F6ylaT9F6itZTtJ6i9RStp2g9FX2Z1kO0 HhJxLOJYF+R1QV4X5HVBvqz/PzqA7v9T5buCTyV/2fjfV/sQP4b4McSPIX4M8WOIH0P8GOLH ED+G+DHEjyF+DPFjiB9D/BjixxA/hvgxxI8hfgzxY4gfQ/wY4scQBWMKxhSMKRhTMKZgTMGY grFuyOuGvG7I64a8bsjrhrxuyOuGvG7I64a8bsjrhrxuyOuGvG7I64b8/0U35DmU51CeQ3kO 5TmU51CeQ3kO5TmU51CeQ3kO5TmU51CeQ3kO5TmU51CeQ3kO5TmU51C+vMaPlf9byLfyKuZV bNrEpk2O9jHtE41jGsc0jmkc0zimcUzjmMYxjWMaxzSOaRzTOKZxTOOYxjGNYxrHNI5pHNM4 pnFM45jGMY2THGM5xnKM5RjLMZZjLMdYjrEcYznGcozlGMsxlmMsx1iOcV1SC5fhclwB9SbH WI5xtJdZXPjvPaPSbix3etFMLf6fesS1++WuUd2Z6raMbqvSbZt12v46rTaa/+pEucxqvABX uS+/1rluCGMqe8zWJb05ZnWetNebKFyk8OQ/XTWNqe4x1T2musdU95jqHvv/NG3GVN+Y6htT fWOqb0z1jam+MdU39v/0qii5WylR6ulX71smo/T0dyUuvRSdTds22rbxb4R/I7RN7mz6ODGD voP0HSzPv8U+/9g9wm2ulJb47s4wSNdBug7SdZCug3QdpOsgXdvo2kbXNrq20bWNrm10baNr G13b6NpG1za6ttG1ja5tdG2jaxtd2+jaRtc2urbRtY2ubXRto2sbXdvU1IiaGlFTI2pqRE2N qKkRNTWipkboPkj3QboP0n2Q7oN0H6T7IN0H6T5I90G6D9J9kO6DdB+k+yDdB+k+SPdBug/S fZDug3QfpPsg3Qfrkjwvw+W4AlfiW/h2GCxrvGu6E0rRvqkV0QGpJ1xxPqkunwoLU0+HB1I7 XWcUwuLUrtCRNjnTx7p7PS48nD4x5F7918rnRHulP1H+/+RL/k3hUCYbnuPYUsddjid1wFOh K7VKpa/G0865xuvakE095063y9m6vfZgKJqZGtapBde4RVdCU9gdxtNReDFdjRoc7O7/uDCQ Pj7sTJ+At+CkUEyfErZkGkOcuSC0Z74CMyLzda8Xh2zmGzATMt/xusDrVXANnWmGFTNzM3Rl ZrHfb/Wd2Ze5w+cl+KljLA27Mg86/sP4bdiZ+R1+77sWnx/xKqdMh+86sQ4bfO5F1vuNeNF2 I+HFzE5MhRfr9wuj9fvjALg7rHd3WD/H9xeG9nrX9PXiqr8+TNbfHHbW34Y7cW8Yjc6cVrWP TyWqbqDqCFVHqPoyVbdStZeqG6i6k6obqLqBmkVqTlBzgpITlJyg5AQVd1GxQMUCFQsUHKFg HwU3UHADBfsouIGCvRTspWAfBXv/RcE+Co5QcISCIxTspWAfBfsoOELBEQpuoN4I9UaoV6Be gXIjFCtQrECxAqUKlCpQaoRSE5SaoNQEpSYoNUGpCUpNUGqCUhOU2jCtVB+lRihVoFSBUgVK TUSHpx4K30mtCL+lVKsafIlC91Nle2pT+JI6uyw1HO5R3eekJl1p7wrvVmd/TafDqnRVuCWd CRep9u70fqEhPTv6YvrI8E2Vf3j6TeG9VLtX9c9Vc3el3x2uSp8WPjX9r7P6058IP0+fGy5M N4XHkn+/JKs/m0lPWCWewtPhb864jR+bnDHnDMOOOuaIWxxxh146RS+9yx3hQxx7InTaK+mX Z8s9MhS91t7r7PmMPbeKLSe2OkfoKvfDiaHLnk+EZ+y1zV7/aY997bHZ+frL/euuutzDs/Xp sT4fFzbZ60VRropeo7J2lvdcpbJWY42KWWvv51RVl6vIbq89Yavq2Ko6tqqMrSpjs8rYrCo2 q4qdqmKnqtipIkoqoqQiSipis0ooqYSSStjKua2c28m1ZPIPRXuIp0rkS53vIef9k1wfwZqw m64b6ZnLXBmKjj/h+BOOP5G50+efhaLjTESV9poU+SX22JLUvSvhh8ySFXJ5KnT4NpvqNEcS DTeFPN06HXeD426IznXWxbZeqKcGytXyp7DA2RfYc5wSuymx2xEGKBEoMTndV5OUmEz1huWO 2KKSOlKx6qnFfuGC9AHcOBAH4YhwaXoOjgzb06/n89E4lnt0T7/H76eV/+3y8aI5Xu8NUHeS upN6b4DCkxQOFA56b4AKCygdKLGYEospsVj/DVB7N7V3U3s3tYP+G9B/A1TfTfXd1FpA+UmK LcgsM4mW49FwaWaV12fRjufwAvrwN7/1e93sGFvCpfVR+Gv9jLC8vgrVaPD5KFxoQi0Ki/Xg ADd3198ettTfgSX4Ce4Oy6M6FTmhGrdw+i2mzyumzyumzytcP1mnv6LTX9Hpr+jqV6JD+ZF4 WaT9GO3H7FVlRo2bUeNm1LjcJ+U+KfdJeY/Je0zeY3Idk+uY+TJuvoybLeNmy7jZMq6+x82W cbFOinPMrBg3K8bNivGKWmdcpAJu5/5K7v+I+z9KPcbRVjwRnk6tsiquxtPhXlXwUmqd77vU Vm+4LPVC+EuqD1lsxN+wKVyf6ve6BQOOudVrDoMYihaplpZU3vvtiFXeiNdR7AiXpsYw7v0E doYms6nD5O41uXt18Dlm1HOpl/z2Ml4Jj6X+7jVYhSuQQjK/KlXbDO+rzKnasDBd530mfK08 z/b0uhf2xj7YL5yiWuep1nmqdZ619br0IeGK9Cy/HYrZ0SfTDV4PxxFm3hwcGT6dPsrn1+H1 Ph+NY7x/I44N7zMjP2eyLOPaIq4t4toi1X6WeXlz+q22ORlvC9ek3+71HTglXJ1+p9d34d3h 33XFvPSp3p8WLtEZ50z/i9llOuSK9HnRQenPoCk8b77+JtMUOjIX4uLwki55SYf8SIe8pEoW qZJFqmRRZpHfr8H3cAO+j5uiAzI34xYstv1tvrsdd/i8BHc6zl0+/8zrPeFrmV/gXiwN12Xu C1dYza7OPOTzr/EbLAtzddVcK9zVKnCRClzk+uA6q9zVmT+EazIr8J+2e8R3j9ruL94/hlbf r/L5ad+vcdw2363Fs75rx3PocKxOrMN622+wbS9e8FsfTG/VvUjXzs1sCn/RuXOtolfr3nm6 d25mwHdqMKMGM9ugDjNDGA4rM+owow4zMdRgZgfGMG4CTKDofSk8ltmF3d6/AjWXUXOmwsJ6 dVev7urT4bH6Sq8zwmWmxGWmxGX1NT7PND1qoQbrM2FlfT328H5P7OX7vbEP9vX9fqHXSt9r pe+tP9DxDrLNwTgEs3AoXmPb2X4/DA3Of7jvTFjTaGH91aFDhy+qvz46oJ7X9byu53X9jbgJ N/vt1nCFzl9kUs01qeaaVHNNgUWm1dz6uxznbnHf45j3Ov5Sn+/D/fhVuDRqMCUuMSV+V16Z nyyv56tNgkEdv1hn/7vOXqFrH9a1z1hzCzr2cR07oCs7dWObLnxMF67XdafrrM/opId1zM06 ZrWOGdQlt+mS9bqgVfXfp/o/rPpXqv7kf6nwVhX/fHS+efWgSH5jxVqXetgqtcJM+JPvHsGT 1rmn/LYq9JiePVaulWbWiJVrhTVwRLTDVq8VVq8V5tdSka82p4ZF/pxZtErUvebNFvNmi8gH zesuke8ws7vM7C7zZJXol5kFy8yCZaJ8SZQfTa55rF7rMp8zaS8IK6xgK6xg66xgK/TmiN4c sYKt058P6s8R/fmg/nxQfz5oBVuXudZ+38WNuCn0mOo9pnqP3hyxmq2zmq0z4XtM+B69+aDV bIXefFAvLVP3y9T5MjU9bD3psp50qdtha0qXWh1Wp6vU5VJ1uVRdLlWLw2pti1rbota2qK1h tTWsrraoqy3qapW1qEtNrbLCrVBTD1rh1lk5etTHUvUxrD62uIJ8TB204glXaE+HP1F6q9Wh Uy281zTfaJpvVA9rqfoiVTuo2qEm/mhyb6LsGpN6I2XXUHaN2tiuNraZxutN4/Wm8Xo18kY1 MmXK9pmyfWrlBXWSM1nbTdZ2k7VdzXSbpi+Yor0m53oTsdNE7KT6VqpvpfZWE7DTBOw0ATtN wE4TsJOyW029TlOv06TrNNF6TbE+U6zPFOs1xdpNsXYTrNcEe8EEe8G0esG06jOd+kynPtOp z3RqN53aTad20+kFU6nPVOqbnkrtplGfadRrGq3nzhqTZaPJspFLazi0xnTZZLpsMkE2mRYb TYuNJsNGk2GjybCRUx2c6uBUh6mwyQTYyKkOTnXo/I2cWqPzO3V8p47v1PGdOr5Tx3fq+Hbd 3q7b+3R7n27v0+3tur1Pt2/kYocu36jLN+ryjbp8o3viIVfHyXX1ieHl6CRdltxnfUVHLdFR S3TUk3xeqGt28fV+vrbwtUW35Pk6wNflPF3O0+U6oqQLSrxYyIuFOqDEj4UqvqTKl6jyJap8 CS8WqvKSKi+p8iWqfIlq3kWv5XRarpp30Wo5rQZoNaCqd9FrQCXvok8LfVro00KfAdW8SzXv olELjVros1z1llTvEpW7S84tcnwq3Kxip2TwmE87xV4ID6nNTdEhMtvpU05mwzIbltmYrNrN gbzM2mXWLrqdomsXXbvodoquXVQ7RbRTRMMiGhbRsGh2imanaIZFMyyadlEk97LD0WxnKjjT C86Uc6acMw3RMLlH7XC2SWfrcLYOZys4W4ezdThbwdk6aDFBiwlnLdBiwpkLzpxz5pwz52gx 4ewFZy84e87Zc87e4ezJ/WHOPcIm83JneF7WzzvzpDNuNMseMXE3mLjJ/cEfyxO3ylaT0/dQ +en/DdNx6XOjE8rKveiXjX55sfwpubd7qazjjOm9JnyKHb/H8cddDfe6po0pvFuetZSIMMM1 aRWq0eDzUbg7jDnGprIznbbOWkWSGCejoxxjtV/+RL8Jx/qzLbb94/6+vN5E5ks1alAb/iyr j8jm83ScoOMmOm6iY3J/vYl+E2L4sxhWi2G1GFbT8r/fd8/Cof90/91g+zl68Sivd9v+Ht8l 99wVch6NDhTfuJjGxbRdTNun/4KzQ/TD4tohrh3i2CGOHWLY4dzjzj3u3OPOu915tzvvdufb 7nzbnWuH84w7x/ZojqM/Kvu/ynzNP03ZLjovc6ZiearWlv+lyHenvXxB9k3Jv+j5x/SR8Rpn fdRZH3XWR/+XkyeZNA22S6bMUV6TiXG3bf91Yswsr6I7XQfscm9dxdezw8XT/7rjeWf+ZPlf jJ4g7k22/CPX2t0X9Ij/cSo9/E8TJFkZeil1N6+TdXcbte6m1t3yedxRb3S05Vxsd+3WQ8G7 KXg3J9upeLeO6NURvRxtl9/juqJXjpvkuEmOm7ja7hqsxzVYj+utnn+ZHL1cbudy+6uTo8Ex 5oS75f64vDdxub08PWZRPUv1bPmvEQVTZFd4StQjlM+KeETEyd9wRqidpXZWlCMiHKFylspZ KmepnKVylspZCmedaYTCWepmqZulbpa6WV1VMHV3W/1UjworhMejlFVwtyulXVHa1cjTPo37 NBg1+DTqHqbk+mTU9cmolXLKSjllpZya/hth3jXLmOv4khUvb6XLW+mmrHRTrtdLVru8a/SS 64pR1+Qlq9uU1W3K6jblurvkurtkZZuysk257hi1suVde4xaaaasNFNWl6loprV8l0h+au0e tWYn13XbnHWUg/dy8N7yVJlptZ9M72eSHBtiGQzbKk6fFO1pwrjniY53nt6o0nG2Ok7yN9dS koGMM+W/IOST7f8HcWcCHUWV9+1bdaurqqurwxbCKiD7ogKKOKIYxsm4AsooDgICDiiCCYIC QkLAHVc22UEWRYjgCBIHZXNj3JUtHWgagmEJkE6oKIY1oe/7dBsdHZ3Pmfedc77kPNZ26+73 /n+/HOmmJ5JZT5erM9yP/1WWFLx3UNTmKt76clpfTuvLEy3vi1YYoPJ/0vJyWl6eaPV2jjtg J+yFfUDraFk5LSunZeWiCaVtpX9P0r+76d/dP3XmlF1KKUX07UlKKKKEoh/d+NrEX/yK6NuT 9O1u+vbkzxz6bq7Dib8CJpw6fbub0ovo290/detCo+UnRXMZ5CxZLUYteaglD7XkUad11Gkd vXUSxVSMYor/de04/VSCMvIYgUpGYBUjsAofWRMfGf+/I+OqpxjVU0y91qFuilE3xaibYtRN MWqmGDVTTH3WoWSKUTEedVqHoihGURSjKIpRE8XCojZvUvJ3lHiGEr+jtLOU9gWlfSGa8fQA /XaUOu6hjntIearqb9j/GKHLUXZXMa9/Tz8sU0fpw3P04bkfR2kt93K5Xs9xI0rrE44/HbXd XIfhh9ErIE0h6Q+qPT8bxRR6rZBeK6TXCumpQnqqkHp/XfU3qUJ6pJAeKaQ3CumNQnqjkN4o pDcK6Y1CeqKQniikFwrphUJ6oZBeKBT1aWcBbSygjQW0sYw2hmhjHm3Mo415KNX4rMujPXmo yiiqMkpbClCW8RmYR1vyaEseSjJKO/JoRx7tKKANBbQhjzbk0Ya8xL+ibCYHimZirhii5ol7 4F54SC0RmWq6yIIJkA0T4ZCaKw5DEZwgzVk1TZyDCqiE82qa1lpt19pAW2gHF8HFcAm0hw7Q ES6Fy6ATXA6d4Qr4HVwJXeAquBq6wjWQCt3g93At/AHS4I9wHVwPN8CNcBPcDN2hB/SEW2CY qKO9r97TPlBvax/CFvg7fASfqM3ap/AZfA5fqM3GYjXdWAJL4Suut8I2oK1GDJSa5quu5vlq qrk+VLYPle1DZfvqQF2oB4Vquq+UNMfhGzXdbAOdIV3NMzNgBDwAY9QScyzQ7+ZUtd3crjab OB6rpdpstYLW6m2rDVwKl3F9NfRVc61+MEBNs+bAMijk+gAcBMbMKlZLrCiU8ayc61Nqmq2r 7bYEA3xgAkrRRinafnAgAC4EIQmqQXWoATWhFlypNttdYCDn93J8hOMKjjnqbfuk2u4nL38t 9PFdoqbaKmoBu5+oDSlQB1pBa2gDbaEd3AzdoQf0hFvgVugFf4Lb4A64E4aohczchczchczc iWK0ekmMgbHwMIyDTJXDbM5hNucwm3OYzTnGs2qr8Rw8Dy/AFJgK02A6zIAXYSbMgtmwmPeW wFKVw6gv9O1WW337oAC+hkLuH+F4FEp5fhy+4d55tdU0wQI/OFAX6kELaAn0g0k/MDtyzE4c O3O8iuP1cBcMgIEwCNLVQmbOQmbOQmbOQmbORGbORJP2mrSXGZRjPxDvGzFdbRcz4EWYCbNg NiyHFZADr8FK+By+gC/hK9gK22A77ICdkAchyIcwHFJr2RPWsiesZU/4THwH5XASTsFpOKtW s0+sZp9YzT6xmn1itXFMbTeKIQolUAq4E8ODMvgGvoUTgGMxyiH+XgyUWs16W2uxF1isfYu1 brHWLda51VN9Zt3OsTf0JU0/GKBWW/dzPRrGwMMwDibAUzAZWG8WfWTRRxZ9ZNFHrKfV1ssc l3FczXEj0A8W/WDRDxb9wFpby1pby1pby1pby1r7jLX2mVUCpVDGu+Xcpz9Yd6u1S4Qhaggf mPHv1Yl/sQX4If7p3QFwE9+VXUMkQReRIq6CISqLOZ7FHM9ijo9hjg9njg9njg9njg9njg8X 48khU2UwzzOY5xnM8wzmeYZ4XFQTT8CT8BRMhqfhGXgWnoPnYb1oJDbAIZXJiGYyopmM6ExG NIcRzWFEcxjRHEY0R8Q/QfqsymZUsxnVbEY1m1HN1uarfG0BLIRFsBiWwFJ4GV6BZfAqLIcV kAOvwUpYBa/DX+ENWA1r4E1YC7nwlsrXO4hqekeRonfimAo3qCz9RvWQfjP04nqYelQfrtL1 +yFdpaPZbpb91Gh0281yIMfR6nM5Ru2Q24VP7hDJMg/Vm48r3yUceUjlyMNokSLRWh7heDT+ 2UAcS0RNY7SoYYyBsfAwjIPxkAlZMAGyYSJMgsUqg/0ig/0iw9gpqhl5EIJ82AW7IQx7IAJ7 YR8UAP3JbM9mtmez12T5aqh8Zn0me0yGr0Q47C9Z7C9Z7C8ZvgpRw5TA3DJrQi1oBm1UhtmW Y0e4TKSwp2SYV3CerrLYP7LYP7LYP7LYP8awf4xh/xjO/jHcZC6ZmcBcMuepfHN+4l/Q51sX QCNoDE2gI/RUOay0TFZaJist2xolqlkPwiPwKEyHOdxfzHGpaMRqyrZWcV5I+gNwEJhzrJyZ rJyZrJwcVk6OdVz4LQ/KSF/Oc+YfKyjbOi2q2ckq364NKVAH6kI9qA8NoCFQV5u62tTVpq72 hdAUmkFzaAGDyWsI3APZXE+ESSrfr6l8p496yOkL2SrdmQSsG4d147BuHNaNw7pxWDfOCzAF psI0oL3ODHgRZsIsmA1zYC7Mg/mwABbCS7AI6B9nCSyFl+EVWCaqBbJgAmTDRJgE9G2Avg08 BqzvAOs7wPoOsL4D1DNAPQPUM0A9A9QzQD0D1DNAPQPUM0A9A9QxQB0D1DFAHQPUMUAdA9Qx QB3ddqJakh8cCLA/6HIbK+UQu1H8LP7ZI3X0h9nN3MS3C5hggQ1+cOJfmZT44qT4J9i78S8a QQFEUAARFEAEBRBBAURQABEUQAQFEEEBRFAAERRAhJ2vFjtfLZRAFCUQRQlEUQJRlEAUJRBF CURRAlGUQBQlEEUJRNklh7JLDmWXHCruU54YBsPhfkiHDBgBD8BIGAUPwkNqGDvqSHbUkeyo I9lRR7KjjmQ3TWM3TWM3TWM3TWM3TWM3ddhNHXZTh93UYTd12E0ddlOH3dRhN3XYTR3i7j7i 7j7i7j7i7j7i7j7i7j7i7j4R/3tHDrwGK2G9qMfOW4/46xF/PeKvR/z1iL8e8dcj/nrEX4/4 6xF/PeKvR/z1iL8eu/UodutR7NajxFG87DEohiiUQCkcBw/K4Bv4Fk6oOezsy9nZl7OzL2dn X87OvpxdfTy7+nh29fHs6uPZ1cej6cNo+jCaPoymD6Ppw2j6MJo+jKYPo+nDaPowmj6Mpg+j 6cNo+jCaPoymD6Ppw2j6MJo+jKYPo+nDaPowmj6Mpg+j6cNo+jCaPoymD6Ppw2j6MJo+jKYP o+nDaPowmj6Mpg+j6cNo+jCaPoymD2u3ihStF/wJboPbYb4KEYlCRKIQkShEJAoRiUJEohCR KEQkChGJQkSiEJEoRCQKEYlCRKIQkShEJAoRiUJEohCRKEQkChGJQkSiEJEoRCQKEYlCeIlc vMQmvMQmvMQmvMQmvMQmvEQuXiIXL5GLl8jFS+RqXwpH+wq2wjbhEMVcophLFHP1LvF/o8rx DxxvUJOIZj2JZj0T0ayfKtWHwDCi20+imp6hSolsXYlsw4lsXYlsw/HiU+VD6q9yo/pQviuS 5AdEv234+R349DxRhygXJcpJuRt//32k8xHpmic+YzLK/RIiz2jhEuVcopxLlHOJci5RziXK uUQ5lyjnEuVcopxLlHNR0lGUdBQlHUVJR1HSUZR0FCUdRUlHUdJRlHQUJR1FSUdR0lFjjvKM uTAP5sMCWAgvwSJYrNKInGlEzjR8Vy6+KxfflUsUdYiiDlHUIYo6RFGHKOoQRR2iqEMUdYii DlHUIYo66EwPnemhMz10pofO9NCZHjrTQ2d66EwPnemhMz10pofO9IyTqtQ4BafhDJyFc1AB lcCaIDKPJzKPJzIPJTKHiMyj8H9h/F8Y/xfG/4Xxf2H8XxiXEMElRHAJUVxChAie5jusPJxC BKcQIZIPJZIP9VEnH3UioqcR0V1cQ8QX41opzxSggQ5SuER6F0cRwVFEcBQRHEWEyO8S+V2c RQRnETEbkvYCaMa9Fly3BPZaXEYEZZCGMnDNDjxnDqIOauE6IiiENBSCi/OI4DwiOI8IziOC 84jgPCIoh6Eoh6Eoh6Eoh6Em+6jJPmqyj5oPwWgYo4ahJoahJkaiJkaiItLws2GURAglETIX JT6RKcVcA28lPpUpxfyI43aVi8oImYwlvjdsnhYpKI4QiiOE4gihOEJ44Vy8cC5eeBNeeBMK JIQf3oQfzrWuEg6eOBdf4OELPHyBhy/w8AX7UCnL8QUevsBDrYxCrYyy+qtS6y4YoMbjDzwr nXPWlDUCHoCRMIo8HwTahXfYh3fw8A4e3sFD4TgoHAcP4eEhPOtZ0j+X+FRBD9Xj4Cc8/ISH n/DwEx4qaDwqyEEF1cNXeCih8SghB2/h4S08vIWHt/DwFh7ewkMhjUIhjUIhjUIhjbIOk3cR HAH2eou9HtU0B9U0B9W0HNW0HLU0HrU0CrW0HLU0HrXk4PXDeP0wXj+M1w/j9cN4/TBeP4zX D+P1w3j9MF4/jNcP4/XDeP0wXj+M1w/j9cN4/TCqK4TqCqG6QqiuEKorhOoKobpCqK4QqiuE 6gqhukKorhCqK4TqCqG6QqiuEKorhOoK2ZdSp8vgSpVrd4GB5D2Y6yFwD9zLvaEc74NhMBwe UFEUWgiFFkKhhexHeGcq91eQNkdtsl/jfCWcVGG/ECkouJCftvlrqVx/beE4t6lDzu1wB/RR PVF2PZ3+nI9Tpc54yIIflN6jnD8Jk4WL4nNRfC6Kz0XxuSg+F8XnovhcFJ+L4nNRfC6Kz0Xx uSg+F8XnovhcFJ+L4nNRfC6Kz0XxuSg+F8XnovhcFJ+L4nNRfC6Kz0XxuSg+9/+j4nN/pvhq iynqam2A6KENErdpd4tx2l/EH7XB4mptiPizfoPoow8Td8je6lrZR/1eblDL5buqhzyoPkMb Jkt2OHlETZfH1CeyWDSQUfxWiTolGospsS1ildop/q52kvs1VZ8G25nc25F7O3Lvpg1Tp4it RZSCm8OV9VZdKKUrpYyRm9RGuRnejZXK99XfiHG75YfqI7lFTaH0Jyj5jCxSRym9C6VPpXRJ 6YsofYuw5Va1TG6nTjh5uVMNlnlqvQzx1i61l6hYgE5dpT6mbh+T8k5i51ZSzyF1ltwZi5F6 KalvJI7+jTce5o35ic92bE9ts4nmFxC9b9R7EMmHqWH6CCH1lejkLeov+idqrr5fXK6fJCIn i2qyvXpVbhIuUbo9LXiTkj7Bj0q5E6+Zr94iSvvIPUaLQkTqrKpILas8qaRlR2UxrYpyv0Qd 1/4sDLVe+MAEC2zwgwMBcCEISVBNbRTVoYvaK66Cx9Ua8QQ8CU/BZHganoFn4Tl4HqbQh+vV DrFB7dB0tVeTYIAPTLDABj84EIAgVIcaUBNqQTLUhhSoA3WhHjSCxtAELoSm0AyaQwtoCa3g VlWg9YI/wW1wO2TDRJgEj8Cj8Bg8Dk/Ak/AUTIanYZrao02HGfAizIRZMBvmqD16B7VG7wSp 0Eu9oz+jIvqzKsIs782olDLPKpljaxiJUubYLcyxSnkqdkyeZkWcUZY8Gzstz8X2ygplysrY UXlepcoY95WqZ/hixwxTXWtYyjLs2GnDH9trOMo0ArGjhqtSjSD3k0g3Wq03xsBYeBjGwXjI hCyYANkwESbBy2qv8Qosg1dhOayAHHgNVsIqeB3+Cm/AalgDb8JayIW34G/wjiow1sMG2Aib YDO8C+/B+/ABfAhb4O+wU60x8iAE+bALdkMY9kAE9sI+KFBrfBVqvSmB+Wv61EazJsda0Aza Qke4TO01r+D4vCowZ8Ncrmmn+SrntMekPSbtMWmPuZp7a2At5MLbsJ77G2AjbALqblJ383PO v4AvOf8KtsI22AW71R4zwrOjUALfwgn4DsrhJJxWBVYSVIPqUAPqqj1WPagPDaAhdFJ7rStg lFpjPQiPwKMwHRbDUrXDWsXxtFpjt1IFdju1176EYweOPeEWzu9Ue+zBPB8C98Az3J/L/Xkw HxbAKqhQe/xCFfhrcGR9+VlX/vrQUO11BquIMxzSYQSMhNHAendY7w7r3WG9O6x3h/XuvABT YCpMA+rrzIAXYSbMgtkwB+bCPJgPC2AhvASLgDY6S2ApvAyvwDK1JnCTigRuhu7QA3rCLXAr 9IIs9U5gAmTDRJgEj8Cj8Bg8Dk/Ak/AUTIan4Rl4Fp6D5+EFmAJTYRrMgBdhJsyC2TAH5sI8 9Y7bTq1J8qt3khwIqHeEQaxYw84flfniEvblSjFLZKoFIgsmQDZMhLMqgn+O4J8j+OcI/jmC f/bwzx7+2cM/e/hnD//s4Z89/LOHf/bwzx7+2cM/e/hnD//s4Z89/LOHf/bwzx7+2cM/e/hn D//s4Z89/LOHf/bwzx7+2cM/e/hnD//s4Z89/LOHf/bwzx7+2cM/e/hnD//s4Z89/LMX/xQu 7WPq+YkqxbOW4llL8ayleNZSfOhcfOhcfGcevjMP35mnL1PHEv9/5Pf/19EB/bQ6QDQLE8UW yG2iMfGykAj2PB5uAR5uAR5uAR6uFA9XioeL+6cI/imCf4rgmTw8k4dn8vBMHp7JwzN5eKQF +KAF+JQFeJIFeIgFeAgPj1CKN/DwAaX4gFKrrYpY7RKfx1mK9o9r+Qg6O4K2jqCFI2jgCPrX Q/966F8P/euhfz30r4f+9dC/HvrXQ/966F8P/euhfz30r4f+9dC/HvrXQ/966NVS9GopetVD o5baY8j7Ec5XxD81TXnoTQ+9WepPZj31UXPRmHPRlHloyjw3Wx1zJ8IkdSyYrA4Ea0MKNIYm 8Cj3X1EHhE5UeZ24jo6TG8SVcqO4S74nOsn3RV369235IUpqi2glt4qe9HVPfL0PxXAN3r6m DIlL6fevUQ6N0DkHuXtItEUv9EQvtJTHxHXk+2HV37LbUdIHahXpX0yUuYZnw1EVG0US9z7j alv8cyl/+Vm62jCR+uufp0t9OrI6rqbU7sTDG6nD93c6Ei1Pc/daouVGomU08RnFJfFvo+Ru Q66uSfxNsQ5pW1CH+HcRHBEXk+ISrraJVFqYzLNGtDX+qW991FdytOhC/T80uqLXdO58ytUX pCY2oQnLuCrgKl0EuTrH1aeilTBEqvCBCRbY4AcHAuBCEJIosbeoLfui8QZAOm3aiA58H535 gdphjBapxhgYCw/DOBgPmZAFEyAbJsIkkYqXT8Wzp+LZU/HoqXj0VDx5Kv47Fe+dit9OTXz/ RRB1W05JBbTiiHyPkYx/m8kHah3qtoS2j6ZPNlCvzaSitbQ9KGpq20UzbYfoQM8MoB/+IPuS qp/oJwckPmOun0xXH8Q/lUiOVQflbNFZzhFXUI7HSLdAybxhXCkuNbqIDvRWP9GINxpRTidG c7RoQknH4+UnSgpWfa/JJ7I/b99F+kEc7+Y4mhm2Xe1BI5eij88m5s8uYfOWFGb8m1BInULK FFL6SemRokykiEPsomgoUYRuepCS4mM6VuWhu0sZ9WrsuDsS+YUYwXzeIs+4IvbVVJV4+Eo8 fCUeuRKPXIlHrsQjV+J9KymztzoW/xdP5NiWlWIlcstX5aLOz8rsz541CDJo22iU+Db1LbUr ox0eM642ZZ/krY8oN0C5Z36z3ADlHox/Nwu51aRcHzmeJMdSciwnRz+5fVvVikrWWW/uxj8v sD9KfhA8yJPRoh5v+qmxyZuneLOSN4PUJRbvNd6sYFUcEteLw1AEZ5nZ56ACKuE8u0NvnEsf 1UH2Z7e4SwyUgzjezTED7/Mg9RmrXpETmBezxe+YD1fT49spsUtibHaqlxKlhdQu1lwyLudc 1Ry51CBvIwZKtPLVFNdbfaEfDBCtrDmwDAq5PgAHgXpaZdwr53iKusU//7GMmp2lzWepWVva fZaataXd9Wl3fMewaa9DW4/K3aJ6YtZt4o0PeeMwb9TnjcO8UZ83fkfq6tT5SGLm7VQV1PsM bx5OvBVKfC9BX8rrx0wewHEgxzHsigdFU3a8MvYYh52xHjtjDfa7TYlv1ImPX4RUkjtljENv zvok1kb80/BS5EPMqoeJd0eo9zFKLFZeYr4V8t5h3nPI3SZnnScRUU8MUd+Ke+BeeIjR7814 9qVeA2AMMzOe+hCz5Ag9fZQ6FeMvo+RSQpzsKur4qqtvfaVwXH1rpkMGjIAHYAyMJd+kqu8E CpNzhJwj8iFaNYY9/yDjeIhZdJgVlGgt+/Ax+qhYfZnw4nWoXwX1q6B+FVWtj/9NeT+57CcX nVzaUsfq5HKaXGLkEv+keZscDsS/j4j6VVC/CupXQf0qqF8F9augfhXiYjFEdBf3wL2QKdJE FkyAbJgo0iixGiVexJ7lo4d7sWf56OVe7Fkr6Om19PRm5uknzNMbmafd5Uo1nTZ9QYRo+X1t iFvx2hxDTVwpujBHuxhdVdhYLNKMJbBUpPmqi+6+Qo6lHI/DNyLNbAOdIV10NzNgBDwA8frZ 1OpU1bzRq+aNnhireA8Wq6OJv0a8Qb2XV6VKqUqVQr09Ul6a+AtEscpjZqTHtuAFj+P9CvF6 x/F2hUbrWBFzLT3mcbeMO2VGa3UNuabH9stT9HMFb1eyN5xXWw2fOo0vPGMEVDkpt5LyusS7 H/B0B3d2cMdJvOvJc5RXQa+cV/l4zJjhFybvxkiVj5eMkTKVfSk9doRSYrjUcmpWKs9yrKDU Smbm929WUmoMd1pOjUsNm6NDLQLc/z6nSlpwklmXjq89LTRyKSOXGLkocjiWKNsUGm+X8XaM txVvHquqQ5t4P8WmUYeDvN2Mt/fy9il5jhUbr30l8/g8My6GTlDqPHU5SG7NyG0vuZ0y/CqU aFWAcXZFdZxylJzPU6e/xqOo0snxDPUokDGh89YZyi4wgpy3VhfGU8S2keIo5cV7KkKKo+QZ 76UIeXxD7/7TeDH6VePE278xPom0iXEh7W+MB238P44D++l/2P/sMv/lfqeN/6K/E09+tZ9F kpEs/EZt6ldXOEZ9cmvAOw3RDBdw3ohnjXnWlGfNuW7Bs5Y8a0U8MIwUSmjA0yYcWzAmrpHM FR7CqEP59SmhASXF82rE/cbcv5D7zbnfgvvkwyjEU8dLblCVIl5SPK+a1EvnaZGRwp06UFc0 on41SVlEno2on079dN4qMprw/EJoyv3mpGnBvZact4p/Kzm5FFDXeAt1ox51rS98VbnE3y6g /vEW6kYznjXn2fdv67Q3GWoz91Koc13yrU9bGjD6DSnrgni7eN6Y50143pTnzbnXgucted6K 9tEKxqY2+aZwtw7UVbuoQ4zeOWg0ZCwvoM2NSNOYNE14fiE0JU0z0jQnTUvStCKyxcfJTfRr XZFMPeI9doZ6JFOPAPVwE33blOvmiR48Qx2SqUMgPipCJtpev6qfv699vPdkot3fv1FWVWtd VPvfzglWrUf//dO8YLW3F8H/dG7wVgdh/av5wdMWotZ/a46Q20W0+n85T3i7tajxf50r5HJl vEX/nfnCSHyeGMf/1ZxJxIbgfzpvErt6a3kqVsxOOogdpyG7Wg95LlbGrvZHWRmLsvsMYVdr wq7WxfDFitlRB7EbNWRX62H4Y2Xsan80ArEoO9MQdrUm7GpdjOTYKXrkYnqkDT3SxqjLdT11 ET2SRK060ist6ZUWRiPuNyZdE9JcCE25bka65qRrQbqWpGvFrPHj3Fw8V6qMf6/PFlELtZuM 0m2OqvgdWuEj1F61xHcLbdAGiKu0QeI67W7xnPYXjoNx7r3VQnkHXuTPagPKY2Him+ra/D9S fZRIFf8OpN2Juz9crfnxSsfJv6u9r9YkzuLfbneQs2q45IuFEF3wpG3F7/ntIG4Wt4mO4g7x Z+7eiZa7Wtwnnhc3iSlipXhAbBDvcvU+v9PF52KXmCHC/C4WBbiTJeIoOb6mNdAaiJ1aI+1i kad113qIQ9ot2u2iSOur9Rcl2kBtoPC0u7UhokxL10aI77Qx2lxxSpvPb31tIb8NtEX8NtRe 01ZqF2jva9u0xnoH/VKtvd5Jv0K7VO+id9E669foqdoV+h/0NO1K/Tr9Ou0q/Qb9Zu1qvYfe Q+um99Jv036v36H30dL0fno/7Xp9oD5Qu0Efot+j3agP1YdqN+vD9BFad/1Bfaz2J32cPln7 s/6M/oI2VJ+qz9bS9bn6PG20vkx/Uxur5+ofaU/on+i7tDl6WD+krdCL9RItVy/Tv9HW6Sf0 09o7+lm9QntXV1JoH0hdSm2LtGRQ+0hWkzW1L2WyTNa2yxRZX9shL5RNtV2yuWyhhWUr2UaL yIvkxVqBbC/ba1/LjvJSrVB2kp21g7KLvEorkl3lNdpR2U1204rltfJaLSrTZJpWInvIW7RS ebvso5XJvnKwVi7TZYYWkw/Kh3UhJ8gJuiknyom6JWfLObot35Bv6I58S76lB+Tb8m3dlevl Fj0ot8rdel15UJboTeUpqfSLDJ+RpHc2ko3Wejejq9FV722MNibrdxjPGn/ThxvvGO/qs42v jG36S8ZOo0hfYhwzlP6Wz/E5+pc+1+fqX/mq+2rqW315vj36Dt8+X6Ee9h3yHdILfEd8R/T9 vmO+Yv1rX4nvG/2A74TvhH7Ud9J3Wj/mO+s7q5f4KnwVeqnvvOnTj5uWmaSfMqub1fWYWdOs rSuzrtlISvNC8zLpmJebl8sLzCvM62Uj8xazt2xv3mU+JjubT5hPyf7mM+ZzcqA51Zwq/2JO N2fIweYsc5a8x5xjLpT3mkvMJTLdfMV8RWaYr5qvyhHmKjNXPmCuMzfJceZ75odykvmx+Yl8 3PzMzJdPmrvNsJxhRsyInGnuN7+Ws8yjZlTOMb81K+UCS1i6XGFZVhO50mppdZJ/t660uso8 q5vVTYatP1jXyz3WTVZPud/qZfWSh6zbrdvlYesO6w5ZZPW1Bsoj1mBriCy1hlnDpGfdb42T ZVamNVGetx6xHjV06ylrsmFYz1rPGaY11Zpr2NZ8a75R01poLTRqWYusxUaytcxaZqRYq6yN Rh1ri/WZ0draYe0y2lt7rRPG5Va5dc7oYVVayrjdbmm3NPrYre22xp32JXZ7o7/dye5kDLCv tLsYA+2r7a7G3XY3u5sx2L7BvskYYne3uxtD7Z72LcZ99m12b2O4fad9p5FhD7aHGiPsB+xR xkN2pp1pjLWz7WzjYfsR+zFjnD3ZfsbIsp+znzcm2lPtqcYj9gx7hvGoPdteYDxmr7BzjKft VfYq41n7DfsN4zn7hP2d8bx90j5pTLHP2GeMqX42PmOa3/Abxgy/5XeMF/2uv44xx1/PX894 xd/A38hY5m/ib2LkOLc5fY3XnEHOIONNZ4gzxFjr3OcMM3Kd+537jb85Gc4IY50z0hlpvOOM dcYa651MJ9PY4ExwJhkbncnO68Z7zvvOp0aRk+/sMzxnv1NknHLOBuobsUCzwDRfk8CMwFLf lMC6wLu+RYFtgRO+Fa7l1vV94bZz/+grcPu49/nOuPe7I02/+6A72qzmjnXHmTXdTDfTrO1O cJ80U9yn3SlmE3eaO81s5c5wZ5qt3dnuErOd+7L7stnZXea+bl7hrnbfMru5b7sbzevcze5m 82b3Pfc9s7v7gfup2cP90t1p9nZDbsjs7+5yw+ZdbsT92hzkHnC/Me91v3PPmGPdc26lOcGN BYU5KagHdfOxoBE0zceDdjBoPhWsHkwxnw/WDdY1XwzWDzY0ZwYbBZubc4Itgy3NRcFJwUnm 4uCjwSfNJcGngy+YrwanB180VwVnBWebbwTnBeeZa4ILggvMN4MvBZeaa4OvBFeYbyfpSUnm pqSaSXXMz5IaJF1gbks6nXTO3Cl0B/0uhHttjVtFa9FE/Jd+1AZ1SB0RHdQxzvf+aoqYWqBW 81umnuXqVtWPdz7i7FjV82Mqyn8PVF2d+sX78adRVc7vP55Zv1LOdzDzN+ubBZt/dmc/JaTE S/mXPzgv0u1RFZy7RPL+Isj1oZ/X8YfW/EqZX6pC5amvyOEgrT36W3X8N35scp1dlfthVao+ UkVVVyd+UXoJFKivVZ46o24SfvqurbjwJ89jv1WYOsnYlZPDP2pO/6NYvn/6qnpVuPDjGP7T 28ehSEXIYz+XPnRWS3ENZ40TT/+utqpdzB/mDr7918tfqV5Wizg+DanqEjVGjebsJ/34Q+s5 K/3F2zH1sTrKDPpYfUE9GId47/38rR/TfvkbXSHwqUIkJc6mVN3xyPurH+bmT2dF1Z1yWn6C vt+rvkPvV+NWJ0bhx9JVSWKESn5I/Yv3S1Uxa8z7ocfjfxlNHPf9NM1v1bsqXeRnV6N+dvXp v5cHPx0T6atmmtrN+Nlq92+UfPona7uj+N1vpH5d5cRXtPr4367Tz98/Ep8d8Tn7iyf5/8bb tEw9lThb98/rWf3l33ifOaLeSuxb++Pj9p/+qNcSu+lr9Osvf/6Huu+Ak6LKvr71qutVdffr ycAEZsgZcUgDkgQEVFBBDLgoUQUD4yBiQodgRERB/Au4IkjQVVF0DShh0VXMriIooJJBCSIC kiTVd+7tnnFGhjDA6n41v3f79a2XuvvVeedWOOOdUAu/+HMFNU9wXpTQws4Tn1Ul1I4hrL/4 pGq/KnYZI8dp3xqeQP8/Rtcy/wDm0a+l7sEcc28NpK7SS8GKtzb6F9tfoYQ6tfBXAX+1io3y udjrl9G/Y9SvX2L92LeLWbIb6LT7aAMGfv7s7wCCrZFjimf1PvE/Lruz/Hf9Bf7XvKIfpf7B IvmHKQ3434068xES863E2jDvSCwurHOgSH4sVp54Op96Iz8r5luPb++ro6+qBf3LjH4S9YNA n0ExJGf/a/4rZPtvHbX+H2ehA/bUH/5HYvs/9j/C9/9p7N2R+L2/SH4UaqfRhcRM6OyY71/+ HLTw8lH731Cy/zB+McZH/2L/Iv8av3Os9JQj6t8DFHvWf9lf5H9dxK2oB91Lo5F7lMbwMzP0 EmbuLHoL7HAeLaAGclYhh96npdSEvqUfqBNttCy6wupt9aZbENF3pcEcy9NtHMXT7eoGlUt3 Ih5fTvnqe7WehqpNahM9qLaon2gkx+Y0Su1Re2m0OqAO0KMcm9MYjs3pMcTmYXrcrmBXoIn2 VXYPetLubfehpwKzA7OJo1qfJjtJThJ9rt/Ub9J/9L/0AvpCf69X0CLta58Wc0xHSzimo+Vu F/diWskxHa1GTNeN1nBMR+s4pqNNHNPRFo7p6CeO6eg3junoMGK6hy1CNPeYpd3H3YlWkGM6 K55jOiuBYzor0Z3uzrCSOaazynBMZ1VHTLfTOgPRnG919mzPsa70PC9k9fSMF2f18RK9ZOsa r4xXzurvpXvlrRu8LK+iletV8apZA71W3tnWLYjarrVuRXQ20roD0dnD1hCOv6y7OCay7uaY yMoP3xUea43gSMeaYBJMqjXPvGReshaa9Wa79QHHGtYSjjWsbznWsFZwrGGt5ljDWsOxhrWe Yw1rM8ca1naONawdHGtYuzjWsA5wHGEd5DjCOsRxhFJxwbiwcuPKxJVTobh9cfsVX1NYJjPG khmjMGPGI6KYQH/HnH6KZsDzLP5ceo5exCo1E/NJy3zSmE/zcdT9C7MqJLMqhFn1Cfyf0tcU pm/wpzDLloJVf0srwK5W0jocY+sx5yrRRtqBI34n/irTr7SXqtA+/FWl3+gQVaPDmJGJMiMz ZUbaMiONzEiDGTmAElQu5qWReZmEebmSyqpVahUlq9VqLZVT69Q6SlXrMV/Ly3zNkPmaKvO1 jMzXdJmvycpXPiXboP+UglmrYLFRGcxdF3n8+JRmBzGPU2QeZ2AeX0XV7R6YzTUwm3sj3wdz uobM6UzM6ZVkBVYFfiAV+DGwkXRgU2AbhQO/BHZRVmB3YA/FB/YGDlKFwCHM/moy+yvJ7M+U 2Z8psz9TZn8mZv85lOK2c9tR2G3vtqeA2wHHg4PjoSM8ndxO8FzgXkCue6F7IXnuRThOquA4 6YK6F+NoCcrREuYzIBRxu+GYicMxcyVVcq9ye1C829PtSdXcXjiKEuUoSpSjyMJRdCNqDXAH oszN7iB4bnFvIeUOdm9FL7e5t6Hl23GkhXGk3YVad7t3w5/v5qP8UBx7ETn2LD6fgjIj3YfQ 7yj3Yewd446BZ6w7FrUecx9Dmcfd8fBMcCdgJBPdifDg+KQQH59oZ7I7GbWmuFPgn+5ORzsz 3BkoOdOdCc9L7izUfcV9Bd/Dq+4b+GbedOdgnHPdufhO5rnzMKr33Q8w2g/dT9DmVy5mpvuN iznpLnO/Q2vfu6uporvGXY/vZIO7CX1tdrdQZfcndyu+yZ/dbVTV/cX9BT1ud3dizLvcXSi5 292NvXvcPfDvdfdiJPvc39D+fnc/Wj7gHkDLB92DlOwecg+h98PuYdT1XZ//v6rnUCajCSzQ BBZoAgs0gQWawAJNYIEmsEATWKAJWUCTB2FHeiNJMaZQgDGFLMYUMsCUu2HzQ8MogZGFbCDL UjLhZeHlFAl/G95JCYwyZDPKUBpQZj0lmw1mA6WYH8wPFDE/mh+prNloNmLvJrOJUs1ms5nK my3mZ+S3mW0o/4v5BWW2m+0o86v5FfldZjelmz1mD8rsNftQZr/Zj70HzEEKm8PGp9QIh9bJ jF+wgUgA1oloSgKKeVQuEoyEqEwkHAmjpIlEqDxwLRmelEhZSmd0o7JAt3TYjEh5lMmKVKCU SMVIRbRTKVIZ+SqRKihfNVIVeWAf/MA+eJ6OTEYvUyLPoNbUyFS0PD0yA20+G/kHlWE0JJvR kBIYDSkBiPXPGBqOxZ8taOgADSci/xRw0BYc1EDBl5CfRW/DziHMNqDhu8i/Bwy06QPgoA0c /AaIuRT4asv5e09w0BYcLCM4WFZwMCQ4WE5wMFVwME1wMF1w0FjxVjxFrO5Wd9gBVi5snjUI drA1GHaUNYoiQMmLSQlKBoGS18AySoYFJYOCknGCiSlqq9pKiYKDSYKDyeqQOkTxgoAJdsAO UBKwz0M+ZIco0e5ud6fy9pVyJxtjX6ZgXwW7p90T/l5ydxvjYKbgYAW7r301ZRTi4EaygYC7 yAP2HaSQoF66oF5ZPmuL47ON2wZHb1u3LdmCcZ57LjAuAIzrhDyjmy3opgXdUt3Obmd4GN1s 9xL3EthL3ctQkjEuIOhWVtAtJOiWDnTrTcbt6/aFvdq9GuWvda+F7e/2h2Wk8wTpQjGkG+wO hudWIJ0WjPPcO907UXeIOwTlC5BuGPJRjLvHvRd5RjpPkM4WpAu5o93RqPWI+yg8jHqeoJ6J od44dxz8jH2eYF+6oJ4tqBdwnwbq2THUe8Z9Bvmp7lQg2jR3GsozDtqCg+lFcNAWHPSAg3OR j2LffPffyL/vLoJl7POAfd8hz6hXRlCvrKBeSFCvnKBeqqBemqBeuqCecX91f0Utxr6ygn2p gn3pMew7CIyzBeOMZ3kW2VG0Ct0RupOCobtCd8Hmh/IpHBoGbAqHRoRGwHN/6H4KCk6p8Ljw k6QEcVLMz8CaBLPD7KQkwZcEQZYUIMte5PeZ3ygemHIYxzljSmLEjtgUDzRxKU5wJElwJAUI koQ8I0hypFykHMowdqREMiOZ8FeIYUcltMDYkSTYkSDYkSjYkQTseBptTolMQa3pkekoPwOo kSSooUg12M5nXpv8eE4OdaQrjsbz///Y/E3+Zk6xd2tKirv4PI+c6ytt2xv4DJdE3u/K++8L +hS7KBZ9buX4U2LR7/x1/sbiZ3SO32/BGTp/YOlHeHo3vxMiT349aux9RI1NiLQ/OvnzMoXt bP3jO3+H2JgfseIufLPr/G1IhWf2ikSiKUVqf4dSy4nPe5RDLnaGsSC6/pO2UOFoivZr6G/i +6mkswv+liPPzfk7/bX+t9hzxFWIk90KzpIXf8fHT2xWFzlfgLHbhfmtR/uV/dVHntU8XVvJ V3COW2uGP1VeD8rZ8I858fkh/wXkPomVKZhZfATv9r8s8Jeqnw0yR9f9/p7Pgvkri5R4RM4H 8bny1ZLbgNEURajY93uiv6+ctV53/HKl3zDTirTr7/EPIu3nc13+oWLljnVd6n9s+5OP+RPY /EmnULlLCe2to5qYg1mn0Oqxt5ok2Mp4Kpha4gZsOOFriKe+VvyhvWKjKnrsnWD91/wF/qux 6wMp/hR/gXjX8+pedPU+Kf6wHNi4RvjDRuEmgma8Jvlr8DozVmqbXG/7FOkD/G0sfuZakCyN Cs7NLsRa8In/FdIkeDv6S/zPxP91lEXIFe2/lX6kR4x8c7F3sob6/yziucGf7uf6D/FZfn9Q obc5fG/zcXfkVUfia65HXgvd4r+Lz/Ld6TtSC+YDr2NAsAJe+AnFrs8WHQNwufDaCF9jOU7L /zldYzzZDd9SRF4f4+vNR+wd7C8sVjb6uhKr23qeISfR3zc864VvyffEOaxva2LfGqx/vf+F /N57yS5hDYtQ9hFtbsNx8HPs6pIN5Ci46rQ3uvfU17ffr0MXv15ZwFKYe8m6vQF/247gnquF e5ZwtONoPs3YVdL2BzxbcsT+g3/0xPw3l+yn0lxHL/Xm9ytlheg9FiP9++X1F0GA1zkh97w/ O5qTfQX8TK534peacxKje81/G4j5ZuzdQv9F4vuD3uI8EpATKLYQKFHAgn8B+n4Ww4no9bO4 I9r8yH/TfyfWZgq/i/mLoYPvl360Ug9Hqf9t4buC2GUt5wriyigTF0T7hOdH9B6R2PGzUxC5 h99F3r1DfDVvINLtyI31J2Ktuz3WSpF7W/ANzPOHnMRo+/j5/jQ/F7n3cFRP8/sLPjyC1Wga vud3/En+dVhbf+FrgPLJ5vqz/GeiPcdWjXT/vT+0udFfiqgyeuQ2LszFeKf/WzSdOGMu1vYu Od4L7woqvkrJOl0Y+QrzXSP3PRS946Je8TtW/qyt+FVcuYPp5+OPRD7REfdf/Rlb8UiWv1XM 4V+Ph5/y65y2SLc0W1H+gaOBo6xleD3Kle7CkltOfbz+0/7d/n3+BMl/ifk+le+Uia1DUb64 238DacGp9SMtZUfvZDmlNtb7P2IllPURv+mPmIeFnDv6q/vbwTm2l8QAS93XSXDuIrU/i/6q GAvj4H9i71bHjp/YqP+a47mkze/nX+vP92eTknf5/m1A695RRuC/5e/Du9H+zf5ZfhXgaCP/ dv/6U+gryh8rntJ4Y5gUjWkL7zecWnzv6dz8GaehDZ69S6OoDn57xK8v+9f5i39fhf/aDaP5 HsecnPPEHOZIsTBSiTJd7P0I6Sj3qv7ZG8b7aNEjF/xq7l85nqNvONoGM3eK3unq3wJ29DWO vui+d8R+78/xr/QfQm6MvyLqO8m+Pjr18Zayx11F7/P6390KOe7OU7+7sqR73U/nFmWH4N8/ YNU7DWcsjneP8jHrnuCM8l+Rc/s/nXxPRba009LKCW3gQqfMXP3HTsdIjtNHDOnAbk/5vPxp +pWO18t6MNv/8pFy+jawnl2n7ZtJOoVxnI7j/U+8HnEysxG8Z120ZuzJjoLzIl/IdYYvjln5 pljZV0vf75+9ncwzEEe0cdSrIceoI2fr+UxRNBKOntEpvBYcOlZ8LOd20yiXdOn7lfon8ZSX v1HWjt+fJSs4J3eisV2Yzi19r3/pVvZkK5b+yhPxXQ18Xbowsvfnif0Z+HzcqxH/axt4/+6j PzNRpNy+//5YTmw7MYQ82VW9xGeljtuX3EHw+7ODcsWicGaFSqxUUJbPVZWnK3HM/QVbce4e RQ1ET8fBWbkS8xec7/N3nMa21lLsjHKJTxzVkqec+Ar6lyXsPV7b/BzV2oKaBTk5w7825ino s7n09YdxFXn34O9tFoyFn9c6YlT8VFZ9vkpzMlG7P8l/zp9b+BxYLMeMIHZO88vCcdQ/YrzP lb6/YvVP4k4hf7Fclfi08L3cAwS+qU/4St8JPL13lL5LfDb5OHV+lLNWvJILFsi7hTj2osgQ Oha/lBUlnlqd2POaJdQ/mfsflvDzlpL2RN+LjZ01PzY6xD5L+eL3G2F+7fC/kjSJyoGTbo5d TVoTPaZlrt1Q+pEe53NEr7AVidb93v7t/j/8yaIbUHhPj9/Jf62ULS/8cxgzj/Ho/fiHS7qq HL2i+AffjuNfxTnZTe6RiSGzvxN8Yif40XL/u9+RyN8KH18zbupfLu9fxwxY6vfwP+D3/jv+ //kf8hlz2fd4sbZXFvhLNaLOfq4/wu8Yeyc5zMD+kn/On+4PwjyYBLY2Fysvl5jtv+m/EVu1 +ex8WcqWa853+APEF70fcTJ49dP8e7BKQuFdQMXOBfm/FTzNX6rxPum/gFjt77F3X0jfkwTn v5DvgK++vurv8v8tBaJP7cfuMIjN4sal7/Wv2v4rT2Mf2cvaAsSKXnf+q7aTuU6FX/pnKnLW oVAh4UTWnmTi+3cukXx5aoTYs6LU/QGs4wdZTTKoof8NjlD+W+mv8s/C8dKfjB9d12NxKo7O aExVLvb+tdiVCkWFT0yL/6VjfA65t8IfgnUudgbSb+P3Qurk96NkP7oGF2ho5CO195v7l/mx Jxv8j/0VcrcEH7FbsCatjcWvdaimrJx1pNSxz26UPK6p/nTYFwrfz+VYrtidFZfGMldSV2pK DUQnpprsKfrZQ4cX++HDe2WlnO/f6L/Oa5g/1L+Xc2h1VLFuo/eA3XgS4x3g5+Hz58kbD7kB gpv3ykr9FX7LjYejT9K/JaogBZt8s/4tsTZOIMYrse/Nxy9zRJ2tckcA8wSZTTKbF+J9QHab Y/IdrhVPLTB6RUuOo2PXPaZjdw+dbymrDF0j6nR3iDrdSFGnG2V1t3rQWOt663r6P9Gle8K6 1RpFE63R1gSaxep0NJfV6Wgeq9PRfFano39Z/7a+pHdUtqpPX6hGKocWsTodLVFnq7Ppa1an o2/U+aoTLVOD1C30nbpD3Ukr1Fj1OK1SM9QMWqf+oWbRejVbvUU/qTlqDv2s5qsFtE0tVB/Q DvWJ+oR+Vf9RX9AutUh9RXvUErWE9qmlain9Zhs7QvvtBDuJDrLCHPmiMEeiMOfYVe2qlisK c56oyoXtHDvHioiqXJyoyiWIqlyS6Mkl293tK60Uu6fdyyrLz8pZqaz6ZqWz6ptVL/BWYIHV nVXfrL6s9GZdy0pvVj8nwUm0+jspTpp1Peu9WXnOCmetdRvrvVl3s96blc96b9ZQ1nuzhrPe m/WAs9s5YD3IGm/Wo6zxZk1gjTdrCmu8Wc+wxps1gzXerJms8WYtYI036x3WeLMW6R76AWsZ q7spi9XdVIDV3ZTD6m7KZXU35eln9HQVx7puKol13VQy67qp8qzrpqqwrpuqoT/Ry1UtVnRT Z7Gim2qmN+qfVAtWdFNtWNFNXciKbqoLK7qpG1jRTd3Jz8epoZ7ylBrmac9Vw72wF1b3ePFe grrXS/FS1P1eqpemHvAyvUw10qvkVVYPseKaepgV19RoVlxTY7z6Xn31GOuuqXGsu6YeZ901 9YTX2mujJrDumnqSddfUJNZdU0+z7pqawrpraprXz+uvprPumnrWG+wNVs+z+pp6gdXX1Ius vqZmeg95D6lZ3mhvtHrFG+ONVa+y+pp6jdXX1OusvqbmsPqamue97i1Q8713vSXqY2+pt0yt 8L71vlervJXeRrXW2+z9qrayKpvay6psap/nBy31G6uyqYOsyqYOsSqbbQXTgll2hPXY7ORg 5WBNOyVYJ1jPzgg2CDawKwQbBxvbFYNNgs3tSsGWwbZ29WC7YDu7brBD8Dz7jGDHYCc7O3hh sLPdINgteIXdOHhTcJDdJFQxVNVuwepudhtWd7PPZ7U2uyOrtdkDWa3NvpPV2uwRrNZmPxS+ NHy1PZOf2rPnsVqb/b5xTbz9Oeu02d+YK8119nbWabMPs05bIMA6bQGXddoCIdZpC4RZpy1Q hnXaAuVZpy2QyTptgYqs0xaoY2aYmYG6rNMWaMQ6bYFmrNMWOJt12gKtWact0IZ12gLns05b oAvrtAUuZp22wKVmrVkX6M4qa4GrWGUt0INV1gJ9WWUtcB2rrAVuZJW1QG6civMCN8WZuLjA rXFJcSmBO1hZLXBX3N64vYGh8RRvBYaRstYB9eIQ8cVTAlmUiD+bkrAOBygVa7eDVb0a/NXx 51INrIIe1QVKBoGHzckAD/n/PLSS/4DBiBkniBkPxLwctbrhLxG42QMt9qSrqTVdAwxtAwwd BOZwC/7a0mC6g8rQnfgrS0NoKHoeBoRNBcIaSrMiVhylyxPCGVYCMPcMYG4NeGpaNSnbqmXV hr+OVQf5usDiNMHi+sDizrBdgMjtRS80zeoBXG4guNxAcLkhcPlu+POtB6mRNdIaiTYfAlJn AKnHUI411nqCmljjgdr1BbXrC2rXF9TOBmq/gPyLwO5sYPcHWA8+tD6k5tZH1mfUwvocaN5S 0FwBzRvBNgama8H0BMF0JZieIJieIph+jmD6mYLpTQXTywPTX6AK6kX1ImWqmeplqqRmAeUr C8pXFpSvCJSfD/svYH2WYH1VwfpMYP1/YL8A4lcE4i+C/Qq4nyW4nyW4XwW4b6iaHQH6Vxf0 rynoXwPon0q17TQ7jerY6XY6teOVAHmsBFQLK0EN2Jp2LdTCekB1eT1ArWZ2M9jmdnPsbWm3 hG1lt0IZrA2wWBvg4Wetz5Vnrc+T56vPleerz5NnqjtgnRhGrQLDAw+ShdViLMUHHguMp7MC EwITKTnwZGAyNQtMCUylcoFpgZcpLTAr8CalY0V5ixqwmig14nWFWvC6QobXFdgEJ4HaOIlO ItXn1YUaYHX5mmznG+cbqugsdZZSvLPMWUYBZ7nzLTlYdVbAs9JZCc8qZxW5zmpnNXnOGmcN lXHWOmspzGsSRXhNQslNziZKdDY7mykJK9NPZDlbnZ/R4zbnF0p2tjvbqRyvVehxt7ObUp09 zh5q6ex19mJs+5x9GM9vzm/I73f2I3/AOUCtnEPOIbR8WCtK1rYOUCvtaIcsrHAuYbHQHkV0 UIcoXod1mGxttKFUHdERaqnjdBzKYBXk/+quk1E3RZdB3VSdhvLpOoOSdHmdiZazdBaxAmol 2Mq6MlqooqugfFVdFeWr6ZooX0vXonK6tq4Nfx1dhwK6rq5LcfoMXQ/tn6nPRN1snY3W6uv6 KNNAN0DdhrohGV5x0VcT3QT+proZSjbXzdFCC92aHN1Gt0fJDroDufpcfS7G3FlfjM/VVV+G 9nvo3ui9j+6LXq7W/dBOf30jtdYDdB610QP1YPR4q76N2urbNdBD36mHUFl9l74Lo71bD8Vn GaaHo50RegRauEffgxbu1fdSWN+n70Mv9+v7UeYB/QB6AQOgDGYAlA0G8Bg10uP0OGrIPIDS wAMmYO9EPZHS9ZMaOKCf0k9RCz1JT8K3/Yx+BnaqnkYNWAMW5cEV0MJMPRP2JY1ZqmfpWaj7 in6V2ut/6n+i5df069g7W89G3bf0W/C/reei5Dw9HyXf0e9i77/1e5QDhvEh/B/pj6geeMYn KP+p/hSez/RnKPm5/hIlF+lFGM9XejHKLNFLMMKv9TcY81K9lM7Qy/QyaqKX6+WoC46CWqv0 KrS8Wq9GrY16I1rbpLeg/E/6J5TfoXejzB69B9/GXr0XY9unD1Ia8xhqCB4TQT7OTaRGbpKb TBluiluOctxUtzw1cTPdilQfLKcGtXBrurXofLe2W4eau3XduvCc4Z5JLd1sNxst1Hfro2QD twHKNHQbYm8jF7EjuNFZ1Nht5jZDX83d5ijfwm2BvS3dluiLNQUs5kzUgDkTLDgTLDgTLDgT LDgTLDgTLDgTLDgTpTNnogzmTLDgTHQGcybkwZmoBXMmSmOtWqrntfHaoBaYEzxgTigD5gQL 5kQ5zJyoCZgTIgGvv9efWoI/5VG8N9C7GWXAolAXLAp+sCiUHO4NRzsjvBHI3+PdAz8YFcYD RoXyY7wx1Mgb641FLfAqagheNR6eCR5mnTfRewr5f3j/QF/Pe8/T+cy04AHTohAzLVgwLVgw LVgwLdjN3g4629vp7UQvv3q/oh2wLspm1oW87/n8v7eCRO2DVtCiNGZglAEG5sJ6QY8aB7FR djAUDCFvgnGw8UGsv8GEYALlBBODSfAkB5OpRTAlmEINg2WCZahlsGywHPxpwTRqFEwPptMZ wYxgBvLlg+XRS2YwE3uzglnwgNshD26HkYDbwYLbwYLbwYLbwYLbwYLbwYLbwYLbwYLbwYLb wYLbUYi5HZ0NbncJJYQuDV1KOnRZ6DLkLw9djny3UDfkrwh1pxRmfvA8GJpBKvRs6CXkwf+Q B/9DGfA/lPktbJEKq3A6ncMskJpGtRuYBZJiFggLFgh7pbmSMs1V5iqqaHqYHpRoepqeVMH0 Mr2oiultelNl08f0Idv0Ndci38/0Q/n+pj/KXGeuQ5kbzY3IDzC5VNXcZG5CmTwzEGUGmUHY e4sZTFlglrfDf4e5A37wS9i7zd2w+WYolTfDzHCqZEaYe1DyXnMvSt5n7kePI83D8Iw2j6Jl cFD0Ms6Mg33c/B/KjDcTMOaJZiLaedL8HfmnzFMoP8lMQv5p8zTanGwmY+8UM4VqmGfMM1SL mSvVBHOdQXXMs+ZZameeMy8g/6J5EWVmmpnY+4p5BfZV80+qa14zr2Hv6+YN7H3LvE21zRwz F555Zh484Luw4Luw/zbvUTXzvlmIMh+YD6m6+ch8hJIfm4/Ry+fmS3gWmcVoE2wY7S81S2GX meUo8535HntXmBVoZ6VZhfxqs5oagSWvRWvrzDqqwVyZssCV76HykXsj91HlyP0RfEvgzSOp buShCL6ryOjIaKoQeSTyCDyPRcZRncjjkcepHfNpeMCnqS7zaUphPk2K+TQs+DQs+DSlMJ+m BmB2rYVPdxA+rYRJR3lzAWNmfhwn/DiO/oa/OGHG5wkz7ijMOEmY8QXCjMsKMy4nzDhVmHFa Ef0eR/R7PNHvcUS/xxH9npDo9zii3+OIfk9E9Hsc0e9xRL/HEf2eeNHvcUS/J170exzR7zlf 9Hs6iX5Psuj3XCj6PReJfk9n0e/pIvo96WDqYfDmiBURjp5Gja10Kx0cmpl6UzD1ztRMuPgl 1mXW3+BnLt7c6mf1A8O+1boV9jZrCHjz3WDkTcDIR1JLcPGHkH/YehjlmZE3ASOfQK3BxSdR G7DwN2DftN6kttZs6x3sZRbeTVj4OcLC2wkLbw8Wnk22sHC7CP+2wb/PEf59Pvh3J2HhrDAU EIWhRFEYShSFoTKiMJQoHP1i4ehnqYfUKGrFyv50aYypMy+vo15Rr1At9TZ4eRVh5NWEkddQ n6nPwL+Zi1dSi9Vi+L8B/64kqkWZ6lu1Eox8tVoNywpGdUXVrbbaoH6AZ6PaCMvablmibFRV /ay2Ic/6RtXVDrUTeVY5qqkOqIPIs9ZRBXVY+ZQlikeVbctWyLPuUXXbsR3kWf2osqgfVbXD dhieeLD/esL7GwjvbyS8v6udYZeHn9l/PbsK2P+ZdnWw/3rC/rPt2nZt5OvadWHr2w2pISKB Jsg3tZvSGfZZiAfqSTxQ326BeKCefbZ9NtrneKCeRAKXSSRwuUQCl0kkcLnEAB3A/sdTHHj/ ZEoSxp8qjD9DGH/TwGww/uZg/AupZeCDwOfUVnh/uyKaTI5oMsWLJlOyaDJ1kUigo0QCbUSf qZPEA80QDywhLTGA63yLGEBLDOBKDBAn7N8V9p/qbHA2gOX/6GyEh3m/FsZfThh/R2H8ScL4 U4Xxpzm7nF2wzOk7CKd3hdMnCafvIJxeaQ1O7wqbd4XNpwlr7yB83RWmniRMPU3YeQfh5a7w 8lTh5R3AxRH36npg5Fq4eJJw8Q4xFt5IN0L5HJ2D8szFOwgLj3JuV3i2K9z6POHWHYVbJwm3 vkC4dVnh1uWEW6cKt04T9pymR+vR4JSP6EfAJpk9NxPG3EKP1+PhZ8bcWBhzGz1ZTwaPZK6c o6eBK7cQrpwhXLmlfk6/CB4/Eyw5Q1jyJcKPW+o39BuoxSw5R1jyJWDJb6PuHHDlDOHKTYUr t9Tv64Vo4QP9AcozV84RlpwhLLmpsOSWwpLb6cVgyS2EJbcRlpwjLLmlsOTWwpLbC0turFfq ldjL/DjKjBvrrXo7PMyPmwo/bib8+BJ9WB8GQ2Vm3EKYcUsw43LIMyduLZy4jVvJrUZthRm3 E2bcTZjxOcKD2wgP7iY8uJ3w4Ay3idsElhlwe2HA7dyz3bPRJiuKxYuWmCNaYvGiIhYvKmKO qIiFREXsIlERc0RFzHG7ul3RO2uJOaIlFi8qYp1ERSxZVMS6iIpYuqiIpYuKmCMqYo6oiDmi IhYvKmLJRVTE4kVFLCQqYvGiIpYuKmKOqIjFi4qYU0RFzBEVsXhREXNERSxZVMTSRUXMERWx eFERSy+iIuaIili8qIh1ERUxR/TDnCL6YY7oh0VEPyxe9MMc0Q/rUkQ/zBH9sHjRD3NEPyxe 9MMc0Q9zRD8sXvTDHNEPO1/0wzqJfliy6IddKPphF4l+WGfRD+si+mHpoh/miH5YJ9EPu0j0 w7oU0Q9zRD8sXfTDHMQwydQMEUs1aiPxSVuvhlcDsUFNrya4fh2vDjX16npnIN6o59WDP9vL jsUtOV4DryG1l+glx8vxmsJyDNPOa+41Rzscw7T1Onjnwp7ndUJrF3gXosxF3kXU2OuMSKal 18Xrigihm9cNezmeae318nphPH29vqgVVWLkCKcdIpwb0BdHOHHezd4gtHOLdwtq3erdSud4 t3u3w5PvDcOn4DinmcQ2GaLcmCMRTgvvUe9RWI5z2kuc08J7wgNKSJyTIxFOS2+KNwWe6d50 9M7RTjuJdrp5L3gvohbHPC29l72XUeYV71XY1xH5hL1V3nrYHxDzhCXmOVdinrbeLm8XWuaY p5l3wDuAT8cxT1hinksk5mkjMU8LiXZyJNppJtFOTjCCCKcFIpxEai0RTjuJcM6RCKc9Ipyy iILKBVNRMg0RTlOJbTIknmmLeKYGeqmNeCaMeKYRbE6wGWxLxDBhiWHCiGE6w3L0EpboJSzR y7mIXi6NRSwcq1yBOKS7RCxXha6C5+rQ1dQqdEPoBtgBoQGwN4Vugh0YGgg7ODQYlrXoEkWL LlG06MqIFl0Z0aJLFC26RIl8bIltLg5nhCvTWeGO4YupVfia8BC6VJTqAhLtBBDh1EEUwTFM HYlhaplrEcNUMtebG8DUOW6pJBFLHUQsecgPNDcjcrjN3AYPxypVzF3mLnjyzTBEKRyfVJP4 pI7EJ7UQn4yC52FEKbUkSqlhxpgxKM/xSR3zhBmPvRMQn9RAfPIkWuP4pJrEJ9HIpIpEJvXM VDMVdrqZDsuRSSOJTLqaFxCZ1Edk8hL8L5tZlC2RSX2JTBpKZNIIkcnr8Lxh3qQzzGwzGyXn mDnwc3xyppmP+KSeWWAWYO9CRCbZEpM0kpikq/nUfIa9n5sv4OfIpKFZYpagJMckjcy35jv4 v0dM0hAxyUq0tgqRSZZEJtlmjVmDfjk+aSDxyZlmvQHHE3XAuqJHWttsMVvhYaXAymab2Y48 6wVWF73AyqIXWFf0AiuLXmAF0SPNMofMIVjWDqxrfAMGKAqCVUHMwQBFR7CCaJNmiZpgpmiT ZommYHXRFKwr2qS1I3GRePhZX7B6JDmSDA+rDNYUlcEKkdRIOvay1mBd0RqsLlqDNUVrsGqk cqQy9rLiYHVRHKwsioNVIzdEbqBKEolVQyQ2QiIxzIfIg5EHEaGNRPRVTaKvhhJ3dUXc9QTy 4yMTKVuir4aRv0f+jjwrF1YX5cJMUS6sK8qFNUW5sLooFwbIythZfjjIr7FH0Wqi3t2ReiP1 QxqANAjpjsJXa+CLeB2KdB/SKKSxSOORJiFNQ3oeaRbSG0hzkd5F+hDpc6TFSMuRVpEa/qkk 6r1Bkhq+CGkp8luQtiPtQTpI1EcheUhxSClI6UgVo2PoU/0or3WjbfVpEEtcpylSK9lHfdoh dYyOV+pMi37GPl2QLke6KuqPvarhKyRZA19Fmo38ukJfNG1C2hbLL0XaFcvvj6YRFEsaySAl IaUiZUXLjqgq5alPX6Trot9Tn5sKv/No2dpSjvoMRhqCNBzpgdhnGB3tb0R27LOOQ5qINDm2 f0Zsf04stYAPv2Mf/jzzkd4r/CzRzzwbaT7Se0gfI32B9DXSd0hrkH6MvW4t8lpQfifSvtjr d7F6+4rsP0zUN4AUQkpAKotU/vdX/v36VkaqecKvakTb338r/mx968V+69Km9OJJ5veoaD8y r9Kj5aTfoqkRUrPfXwvbiLarRpwHf2ukDrH5h319L/j9tW9XpCsCiT3X5HbMX9T7vjwSq8Ua 2FF5SbBj81Jhx+dlwU7Kqwo7La92/iKuNeyq3s/nZQ/r2/PH3C75S3tuzb08f0XvWXk5YlsU 5t/Ia5u/gvcOu67nztyr8tf1npt3Xv66aD5m9+X2zd/U+928i8ReCvuh5D+U/Od53WEX5/WG XZ7XD3ZV3oD8TVxr2E2w1yF/OPem/G29N+QNgt2Sdwfs9ryh+dvYP2xwr0Du4Pxdvffk3Qd7 MG/UsCG9QrlD8vf3UXljxY4XOwnW69MONi5vGmxK3vOw6XmzYCvmvZG/n2sNG96net7coZN6 JeQOH4pvNu/dodSrbO4DQzXbYQ/0Kp87eqjp0yDvQ9imeZ8PNewZNjrqj9nKueOGJvWqmTtx aGqfVnmLC227vOVDU9k/bFzM1sudPDSrT8e8VWI3wHb5f+x9f1Ab2Z3nayELDcMwDMMwLEMI wxCGEEIIcQjHEkIIQwhhCEsIyxIHZKlbSOpW02q1WkKIlpCEhjgcxbCsw/ocx+flOBdxXITy OYRzHOLzsayXIpTD+liXz0W8FCE+inCEsJxDkfu+J4nxjyQzf+x/d/Wt70ePp9ev34/P+36/ 79ENJN3c+RDwROc2oL5zD9DUeXCEvKDyjp6UBK33XPtx65iSfdItJCjZpLa8SI5PSI4izvGO tZdaJ5TCkyEhjWBmNI3zvRPtFdZJpfjkgJCjFOO0d7K9QsiHdLX1qlJ2clgoIlhylB4VygHP CVWAY0It4ITQADgpNJP0CaUMX+u92l5nvaZUtjdabyg1J68K+iO8Jui9107eEExKTXuLdV6p b2+zLpI28ASlo/S84IaW0NZlpenkouA7wmUhpDS1W6x3lVbzbJePYIjgAOBc1zDgQtco4O2u c4ArXWOA97smlFZ8VZ/bvNY12edrF6yriq5dtq4rRvPDrquA213XCOL0XtcNxYi/7Qu1e6yb isZ80DWvaCwq62bfQBjb/dYdhbNouxYJLgMmkHQCSSd33QVM61oFzOxaB8zp2lQ4fFXfMOA+ pPuth4poye/aASzq2gcs6YIcnN832j7IqxWXpdyNscod13eufYSPUxRLrTsRoyVE0imADe50 wGZ3FuAJdy6g3l0AaHIfVxR8Vd+YhXeX9k20n2l/oAQtkrtCCbaf5xOVUxh7s9vH+RRlyOJ2 VwP63HXKEM7pmwznR/ASn66cbp/is5SzlpC78QgH3C2wdiC/72oEp/lc5YJl2N1GkD5Kj7ot gOfcAuCYWwaccHsAJ91+wKvu/r5rlmvuQa++/TpfoFy03HCP9N0gtV2O5My7zwAuYsQ5ffPt N/njyhXLsvs8wfFoGuf3Lbbf4kuVGctd9yVlBqf7li2r7qm+u+1LfIUya1mHkQd0Tx+lN93X AXfcNwH33bcAD91Lyiyrdt8BjHPfU2bxtX2r7Xf4amWu/R5fpyywie4HT2GKe0NZaH/ANyq3 2zf4FmWFTXdvEdw9Sme5Hykr7Vt8m3Kfze1GR1jQrVHut+/ytLJ28q4wQHAYcJWk14VRwE3h HOCOMAa4L0wAHgqTyhq+yntDrxaueufbH/EW5aEO8YKyrY8TrgEmEkwhmC7cULbxt95FnYaX lT2dRpjHiNP6LGHRm6CL5z3KgT5XWCZ496l0gbAKeFxYBywVNgErhB3lAF/lXdYl8X6vSpfK 93u1+mphH7BOOARstKkBW2xxXq0ugx/0JujbCNK2RO9dXTY/4k3WW2wpBNMJZnmTddm2XEgL tgJA2XYc0GMrxflQflXvt1VATr+t2ruuy+PPeNP0g7Y6wBFbozdNV8ifV25j9G7qz9havDu6 Yn4cyp+3tUENxTYaI+SshvMjWMZf8mbqKvkpaNu4zQJ4ieCUTYCRwfn7+mmbDN6TpHU1/LQ3 R3/d5iHoP8Kbtn7AW7ZBwCXbCOAd2xnAe7bzgA9s495D/Ybtkk8N9Vz35usybFOAlfxNwHr+ FrRzyzYNuIuR5Kzqmvglb5H+ke36k4jzfbBttd305hg0tlu+RF0rf8dbYoi3LXlLcNqXomu1 QY5Ox98j/Qrjg2jakGTbAEy1bQFm2HYBs22PAPNEBFgoaqDv+Np9nZF/4C3XcfyGt8pQLMY/ hWVikrdKJ/Jb3lqdi9/1NhgqhWGMYuoR1ogZ3gadwj/yNhvqxWzAJoKtYh6gTiz0peOYxJdl MIrFEJ9AbODLNXBiWc+GQRQrAV1iTdiD+wqwH/QdNyhivZJhCIpNSgb2RL5SwymxFXslUQcI vsZXYRgSjUqx4bTIgX+B9eKrNpwVRWUN89ZXZ7ggupQDw0VRAbwsBsMc8zXi+fW1GK6Ip7w5 uhpxCBDGwddmmBFP4zERzwKGezorXgCcEy96G4jHWWePd8eD98GWf5Mt7U5SOLaiOxWwujsj Yp93sJXr22frurOVC+3T3XmA2M4cso3dhdjmdBcDgiUJqdmW7jKwHm3dlcoKYf6qYUG87KMN t8UrPothRZzxCYb74qxPNqyJcz33DA/FhZ4Hhm3xts8DZVagzJ543+c3HIhrvn5aJT70DdJa cds3QieIez1b7XXigVJJJ9tVvjN0ml3rO9/eYk9Q6ulMe7JvvD3Xnua71F5gz1Qy6Bx7jnee zrfn+6boInuRbzocb9Al9hLfdbrcXt6zhCMK3026yl7lu0XX2mvxLNgbop6dbrA3EzwB2Axt W6JP2PW+O7TebvLdo0123veA5u2Sb4OW7G7fFu22+3y74Zj2pMoegiguHEeRKIX22QcgdiVx Ix2yDwMO2EchisPceHRSbwekh+1jvYgetU/0auhz9sneeHoMl2xX26/27NIT9mu9SeHITXfW fqNniZ60z8MaJzEqfdW+2LNxMs2+3POIvma/C3c32VdhHG7Y1wHn7ZtKNr1o34EYbMK+D+1Z th8C3pXUvkHdnhQH9a9Kib2p9LqU4lvCI9CbQW9K6WFu92bTO1IW1LMv5SrF9KFU0JvHqKXj vYXhCJOJk0p7i5lEqaK3DK+L3komRaqGKB1i9d6aMDLpUl04Au+tfwybCLaSu+gIGpksqbFn g8mVWnq2mAKprWcXR9S9HHNcoiNpkaALr69eJTKSEA/3Bgmewq3qHWJKJUvvUDhN8DRTIQlK ElMtyRAPQ1Tce5apkzzhGLj3wmN4ESJVSclmGiU/YAtGHLX2Xg4j0yb1hyPV3isMLQ0qhYxF GgGEfMgRpDPhqNVX8R72zuBV3ztLcC6MjCydh1gUItLeBcYjjUPkCXFp723GL11S6pl+aQpQ kKYh5lyUrkNsiedlJYzMoHSz974+S7oFqxtb5gRmRFoC75kl3YH0Gele75ouQ3qAPYK00fuQ OS9teXeYcWm3d5u5JD3q3WOmHKj3gJl2aPyqiG0n1lvX6oj3a5nrjiSwxi5Hqj8hbAmZm44M fzJzy5HtT2OWbNX+TOaOI8+fE44B9BZHIfgC4mWYe9huh30088BR7M9nNhxl/iJmC3tbZtdR CV4PrJa/RL/kqPGXMI+EZX+5fsRR700zIkeTPy3il8cdrd4Eo8ahw7GEw6isGeMdHPbpDlE5 MCY5XN5kY6pDgfvecwSx/3KADTRmOIYgP9tx2ptsKHScjXoKY57jgr/KWOi4CG2DWKI3yVjs uOxbwr3z1xrLHFfClta7bKx0zEA9NY5Z8ALgc/0Nxnp+yt+M/ZT/hLHJMefXG1sdC36TUee4 7efxuPklUo/baHSs+H1GznEf9jhgw/2hcLSD0dcWxmhUw8v+AYzhHP8wwVHcBv85gmNG0bHm VRldjoderVHB0QiOTHxtxqBjO5wGfwcIV4Ev8E9gq+ufMJ5y7IXjCv9kBKEXvkbjkOMA/AVJ k35NGE/LKm+m8ayshYgC4gr/VeMFOSEcRUCrjtA/qh+Xk735xotyGuBlOTPs8aEeQP814xU5 J+zl/TeMM3K+t8g4KxcBQj7kzMklYS/vn38MF7Gf8i8THCV417ggl4PvBg/uXzXelqvAU4Mf 968bV+Rab63xvtwAuCY3gxerl094m8mYbxLciYzMQ1nvLTFuyyZvlXFP5r0NxgNZUtY6VLLb v8/S3TWhONbSXR+sZ4XuJkC5u1UZYj3dOsXI+ruNiobt7+ZCiVBGhG8Hu12hFHakW4Fvz3QH Q+ns+e5ToSx2vHsIdkPnu08rp9hL3WdDue0j3RcUhZ3qvhgqYKe7L4eOs9e7r4RKwWPOKBfY m92zgX72VvdcqIJd6l4IVYd3B+23um8rM+yd7pVQHXvPPRVqZB903w+1sBvda7CP2+h+eBSH b3Vvh9rY3e49SD/qPghMccijCtGcxqMNWbh4T0JI4JI8ySGZS/WkhTxchicz5A/vQC21nhzY c4V3OmRPwWV78kP94V0elwc5IlfoKYI9F/j60KBlzFMSGmRzPeWhEa7YUxU6w5V5akMWSz4u 2T7oaVBcXKWnOXQ+vM8yz3pORPez4T0mV0P2lbWWdbzj8+iP7j7hMQGSvRJX7+FhxxTe4xzC HnOWa+re7i2zlHskqL/V4w6NczqPD/ZZMAKhS5zRE4rEKsMc5xlQLnCiZ1hZ4Vye0dAUp3jO habD+0Eu6BkLXedOeSZCN3GcE7rFDXkmYU8NO+vQEsE73GnPVfAasIMGfwEYuofRS/bUoQf4 LqGNMHJnPdegRxdgzyVyFz03FBfe/4a2uMue+Uh6l+AjHC+9gyIjCbvXdzQRhFa9E89d8Sy+ Ex9OE0ziZjzLymlu1nMXdq+wh30nlZvzrIZ3rO9kPIbZlnnPOozYgmcT8DZGvMf0tYSRW/Hs hPeV7+Rx9z37yhVuzXMICPmQ87BHHd5jvlP4GBbjKO6dMoKVYeS2e+Jg5wj7x3dquL2eRNgn wi7ynXruoCdFuW1V9aQDanuylBVrQk9uqA3PyztNBFvbB3sKQlvW5J7jyow1radUWbBm9lRA yZyeaqW1Qyv7/Idk70D8EbFdsGfpSJBDAXVHsjwQiNNp5OHepI40eRT7DvlcILEjEyOkxwIp HTnyRCAdcPII8+WrgayOIvlaILejBK7Shvd0HeXyjUBBR5U8HzjeUSsvBko7GuTlQEVHGraf BPc7muW7vdvYWgaqCdbp/fKqN7njhLweaOzQy5uBFl2xvONd7TDJ+4G2Dl4+DNAELdhOBoTI 3gowIHdITnXAE95ndbidcQF/h8+ZGOjvCDlTAoMdA870wEjHsDMLcNSZGziDbWbgPMHxjnPO gsAlwONeVceYszQw1THhrAhMhX1Kx6SzOjDdcdVZF7jecc3ZGLjZccPZErjVMe9s6y0jVlTb seikFWPHstMSWOq46xQCdzpWnXLgno5zerxVHetOv7e8Y9PZr1wJeyiMgQc6BbwhpJ2Dfnc4 cmMSnSOBjY4d55nAlg45zwd2O/ad44FHHYfOS/7DjnznVCDLpHZOBwpMcc7rQWRKdN4Makwp zlvBeFO6c0kZMmXJo8Gkx2sz5TrvBFNNBc57wQzTceeDYLap1LkRzDNVOLeChaZq526w2FTn fBQsMzW6ULDS1OLSBGtMba74YL2JdiUBWlypwaQICq4MZc0ku7KDTSaPKy/gN/ldhcFWU7+r OKgzDbrKgkbTiKsyyJnOuGqCoum8qz7owvMbVEzjOlcwaLrkagqeMqW7wOabply64FB47kzT LmPwtOm6i/MNmm66xOBZ0y2XC3DJpQQvmO7ApRdN91yn/Mm6GhfssEwPXKcBN1xng5dNW64L wSumXddFwEfO0uCMGbku9943a1xXFI053jUTnDUnuWaDc+ZU15zCmTNcC8EFc7brdvC2Oc+1 ElwxF/JLvWXmYtf9QKm5zLUWvA8lH0LJStd2cC18F3ONay/40FzvOvAtmZu6VMFtncaUq+yZ W7u0wT1dWVeCN9Os60oOHpiNXWl9KjPXldmnNYsmT59W19QF3tns6srvg1iuq8jbbFa6SvqS zcGu8r4086muqr5M81BXbV9OR1FXQ+82xr788K7ffLqrua/IfLbrRF8Jjl76ynGU0leFT1H6 asMrjpxgDEROKp5cHdcjZwXkZKCvwXyhSx/Ixf69rxnvwftOYDb26cOnQ8Q+7JsvyqNQP4nE zJe7TN7ljpwu3rscOb0h5yrmK7zQZ+rY6ZL6+PCu3zzT5e6T8Fz7GpEKvUptU/8bIeq31B5S UY+o3yE19XsVhTSqYyoNek71vCoePa9KVL2EXlC9okpBL6rSVK+hl1RZqjfQy6pc1UfRK6rv qL6DXo2pifkSSj1WfeyLKO2YeMyO0o/99NhPUUYCCPpwQmbC2ygzoSHhBKpPaE/oQ19PeDfh J8ifMJ+wiX6QsJWwh+5Aa/4Cqcl/P0hAL6Ln0EuoCT2PmpEefQXR6FvoBPr3aBAF0RD6OQqh f0K/QLfQv1Bx6H9Q8dQL6PfUi9QrFEXhd5y0+LlJ6lWqleqg0ikzFaLyqH5qhKqhRqnvUF+j /gv1M+rrMd+P+T4lqyW1g3KqfWo/1aXuV3+L8qjfVb9L+dTfVv8t1av+rvrvqKD6snqS+qb6 qvpH1ID6J+qfUEPq/67+e+pd8j7miPq2+ufUt9X31avU36rX1b+izqp/rf41dV79W/W/Uv8R P0VHjR17+djL1H8+9vNjh9RFzTFNNrWseVPzJrWr+aimgPqt5jOaUup3+A0P6veaL2iqVGpN teZtlUbzFc0JVYLmpIZWpWuMGlGVqXFoFNXHNd/UDKo+oxnSnFV9VvNdzbiqFr85oWrUXNb8 o+qrmkXNosqmWdKsqETNPc09VbdmVbOq8mh+qXmo6sHPY6l6Nb/R7KpCmj3Noao/FsW+oHo3 Nin2FdV3Y1+NfUP1d7E5sZ9WTcZ+PpZTzcbaY4dVm7F/E/s3MfGx3449G/NC7PdiL8e8jP+v asyrsT+MnY5Jj52J/WlMBn4eKCYn9p9iV2KOx96NXY8pif1V7L/GvKXN0U7FNGl/89zrMb9I +F3C79T4fTkO9QPGowz8tnHlZES1oPkoh9PX7HOmqpov3akq5HhO4tw1q5yPC1VxDUPcVe4a d6NqhpvnFrll7i63yq3XxdVlcQN1Mjf8Vu1bJm6UO8eNcRPcZF3WW1XAKjVwfJtw/LeIon5P /R6pgNGJKAa++xB5EhWpvqf6HqJU31d9H76bVP0Axah+rPoxOkaeRNWofqb6GdKSN8GeU/1c tYziyDOo8eTp0xdUv1D9AiWQ505fVP1a9WtYHfjJ0qQYKoY6+q/Bx2I0KIW8OZYakxKTgv4s JjUmFaWRJ0Vfi8mNyUUfIm+FZcSUxZShTPIO2OsxFTGfR1nkrZhs8szGR6D98VQSGTmMiL2J POxN9ha7xN5h77EP2A12i91lH3GI3eU0XDyXxKUSzeCyuTx2iyvkirkyrpKr4eq5Jq6V03FG juNEzsUpXJA7xQ1xp7mz3AWiF7nL3BVuhpvl5rgF7ja38rhYm7n73Br3kNs+kj3uwKqyah+T BGuyNc2aCbk5T8gJaw6UzbcWWUu4g6hYy61V1lpALA1WPbdtNUFZ3qq3Sla31WcNWQegzhzr sHXUes46Bv2nnuMiVgO/s/4SGZNUkBiUDqJGOehNdAzlg8SiT4BoUSnIc6gMJA6VgzyPqtBb 5OnyL4PVwe9dvoj+CrWiRNQGkgR2h0YvIxNIMrIjibxx6SbvWnrJE+UBlAb26F30Gvo2yIfQ fwDJQP8JjaMPo++BvI4ug2ShH4G8gf4rSDb6MchH0H9DN6F9t0ByyX/D/ihaQf+M8tD/BMlH /wLycfRLkAK0g34Dbd9H/wd9Eh2CfIpSUbHoOBUHtq+UPD/+52D7ElEZeX68nMqgXkefo96g 3kBfIO97VoE1bCBvdLaiauoblA59kdJTevRl8ix5HXm7822KozhUT3VSnegrlIOSUQPVQ/lR I9jOEGoB6/lN9FfUt6gB9HVqiBpC3yBvd7aBJZ1G7dQMNYMM1Cz1U0RTc9TfIyP1D9Q/IBP1 j9QCMhP+smAFchGnzdPmoU7ydJ6g/aS2CNnIE3l2bam2FEnacm05cpA3iWTy/J1Tq9OeRF1a g9aAumFu19Ee4X4x/ssSliugM6CzoHOgCxG9HdEV0PvoLy0zllnLnGXBctuyYrlvWbM8tGxb 9gAPWBWrBUlgk9k0NpPNYfPZIraELWer2Fq2gW1mT7B61sTyrMS6WR8bYgfYYXaUPceOgUyw k+xV9hp7g51nF9ll9i67yq6zm+wOu88ecv2cmovjErkULp3L4nK5Au44V8pVgFRzdVwj1wLS xtGchRM4mfNwfpBBboQ7g/+D6DH9MTM4wW8ktJG/r/DWvxm/3wZ5kbA8kbD8JcLylwnLkwnL XyEsTyEsTyUsTyMsf42wPJ2wPIOw/MOE5ZmE5VmE5W8QlmcTln+EsDyHsPxNwvKPogWQPML1 jxGu5xOuFxCuf4JwvZBw/ZOE658iXP80cF2Figm/P0P4/e+oD1EZwHvM7DLC7M8SZpeT9yM+ R9hcQdj8ecLmSsLmLwCbe2ANeCkvrAH8lsQXCZtrCJtrqb+m/hrWA+Z0HXk/4m3C5nrC5gZq AXjcSC1Si+ir2q9pv4aatK3aVvQ1rVlrxu9rJ/oST8E8xcPYP48oWxvwrgi0BLQctCqSVwva ANoMegLnqV+yHLcVs7f/tJIyK+KypdRWZqmwVbL3n1ScZ6m21bBroA/Fu1gtdbZ6dvtPKy5j abQ1WVpsrezee4p/trTZdOyBTcepxFULbTNy2j+tpEyCuG6x2Dgu2cZZBJtIVLa5uDTQTJEn 6Rxxk8sXdywem2Lx24Jc0XtKfi4R9y39tlNc+ftolXjI1drVlkHbENER22nLGdtZriGsOI37 xjW/p6Sv520XuBO2C/iT6LjtIqd/f8XlLJdsly1Ttiuc6Um1TNtmovU+rpbrtlmOf08tN21z H0SFNvmM5ZZtwbJku/0H9Y5tBatAy+exWu7Z7n8gfWBbs2zYHj6jW7ZtrILFPmjZte19EBUE edzyyHaAlUWiiqhG1GIVZPkS/uzkHROsTtSz8WICmyQmP62CR55iU8W091PBL0+TOjLETKLZ Yg6bJ+Y/oYVi0TNaLJY8oWVi+QfWSrGKrRFrn9F6sYFtEpuf0VbxxBOK+/0BlJPscaxRNLGc yP9Bhe84tz2R89lTSDlRlD6QukQ3q4i+ZxTXFwIdsKezQTH0QZQbtmexp8SBIx0Sh48Ufz8K es6eS9Jj9gJuwn6cPS2OkvY+pdykvZSkz4rn3k+5q/YK7pq9+ok6LohjT+hFceIZxdfesNex l8VJbt7eSD4X7S1/qD1/VK+IV9kZ8dozOiveYOfE+Wd0QVx8XLlle1vUtj9ui6O28sjG3bXT RzZo1W553I4c8eTxeY3OS3SM1u3C0dhu2uXH20RsST/YFFj7wmDYBggj4fVL1tUZMY34DeC7 cB50XL4e5bNwCT7hPvh7bsfu4fbtfu7Q3m9V2wexf7HG2UdwPu6bNdF+xppiP4/tqzXdPo7t pDXLfsmaa5/CPsBaYJ/Gtp30GfhuPW6/HrXP1lL7TWuF/Rbut7XavoTHwlpnv4NtJ66TaKP9 nrXF/sDaZt+w0vYtq8W+axXsj6yyhPD4Eh+ExxLG0OoBPxnxZ1Y/+J/IOFv7oZ5BSYPrIN+N SPHWM1IS9jtHvvaxOTqqE2vEp0R9AW4T9o3W81Iqadu4lBGdZ1Ie236Ye+KXweeRvl2SsnGe dQp8eGlYsb/G4/uE1oX9MvZXxB/DfaK+GH8SBf6Qvj3lY8m9QK3TNgUr9rFRvxpV63XbENYj H4l9ZsQ3Pu4rn/CRET8ZVetN8IMwx8T3gT+03rLNYCW8xX7ueliPbBaodUnKI593pELrPamY 5IP9sD6QyqwbUqV1S6qx7kr1JB+vYexL8LqFdYTXk/WR1MQjqRXbIl4j6ci6iK6DiF0k3IJ6 sJ3j48E2RdYImS+wW/j6qA18Zm09ta6O7Eu0/VAHtpt8kmTEc86nStzR9bg8rDc+QxL5bMmF 283nSQpfKAWJDcf9gT7wxdIpvkwaIte9n/2JtIuvjNjx6BoPPVYm0mbS16fs8VF/sB2O6h+7 1x+xp3xN5LNenMR9OtKn7eTjthLbx6iNfNwmQllSDy6Dv4Mx4JvsdcKUfFOYlm9hxbENnm8S 11yXl0ge2Cz+tiNBuCnficYvwi35Hh+UZokdg7hDWJIfkJgCbBp/WXrIK9JMNCYQ7sgbxKZh /4/jBmzr7slb2EcLD+RdYUN+xM9KB8KWEwm7To3wyBlvQ84km8aZaot3ZpCYLGIvybU4NovE TSTmicYouK5IHfg7W5IzG9tL3K6j2C4ah+2+Z4OJRmOYSOyB68LxmC3VmYfjHVuGszB6PSkP /SE/w3iRdQJ9s2U7i0kejhujGokTn9CnY8FI7PeERsb16bjuSHEsFtWn47pojPYHYjNbXljf NzbDsdfj8ReOuaJx12MxFm4ruRaXiYzJM2sL1h/fKp1+Zl3ppLPRGIs3Shd4TrqIbVG0HC9K lzGveZd0hfApagdwGbzmgH/k85Q0xw9JCyR9WrrNn5VWsD6+3vgL0n1sI/iL0hrh5xVp+5k4 BpSfkfaIAh+xknWI7dacQ0U+Fxza6BrEa4JfcSTz9x1pR+sP26A1RyaxNQ8dOfy2I5/fcxRh 3xNV3F+8xyLrD/rMHzhKOlWOclI32I9OraOK9DNSvjPBUduZ7GjoTHM0d2Y6TmBb1Jnj0Hfm O0ydRQ6+s8QhYf9HfCC2TxATdJY73J1VDh+2x521jhDZs4Av7GxwDHQ2O4Y7TzhG8Xh16h3n Ok2OMbxP6JQck3icOt2Oq7h8p89xrTPkuNE54JjHMSC2/1Hb3DnsWOwcdSwThfqwn8Hc7jzn uIvHvXPMsdo54VjHPOucdGwSGwbz2HnVsUO+u+bYJ3XccBxiW945L6s7F+W4zmU5sfOunNK5 Kqd3rstZnZtybueOXIDHt3NfPk7sGO7/oVyKPwW1XIH5IMTJ1UKiXCekyI1CutxyxB+IwXH8 IWTJbUKuTAsFsoXkR2yucFwWhFJZJvMH60SokD1CtewX6uT+I65G9wFRHwVpoVEexGWEFnkE 5yEVohJCCUMI/f/foPw/9BuUTbTz3u8B6D3EMWlMJpPD5DNFTAlT3qRmqphapgGwmTlB74WF ycTK6BkTfRAWhmckxs34mBAzwAwzo8w5ZoyZYCabBpmrzLWm68wNZp5ZZBIiMkx0mbnLJEdk lVlnNpkdZp85NKqNccZEY4ox3ZhlzDUWGI8bS40VxmpGFRUoUWdsNLYY2xhtWIy00WIUoJxM WohbhEvi7/D94A74nP+FCeD2l/5NzkHfhrXxFZCXyDloEjkHfZmcg75CzkFTkAlZ0KuIA0kj p6GvkdPQD5HT0A+T09BMchr6OjkNfYOchmaT09CPkNPQN8lpaC45Df0oOQ3NI6ehHyOnofmw 5hZQAVoE+SQ5DS0ip6GfIqehnyanocXol+hX6DPof4GUkjPRPydnop8lZ6KfI2eiFeRM9PPk TPQLVAaVgarImehb5Ey0mpyJfpGcidaQM9EvkTPRWnIm+mVyJlpH9VBeVE/1Ur3oL8iZaCM5 E/0qORP9GjkNbYaV/kP0l9SPqB+hVnIm+nVyJvoNcibarj6l/hbSkb80qFdPq3+EaFjXc8io 3lD/Cplg/e7BWFLIhZT3uGqAHhvuGO4ZHhg2DFsgu4ZHMPAaOp5OolPpDCJGmqNF2kUrIEH6 FD1En6bP0hfoi/RlItl0Hl1IF9NlRCoJ1tD1gE10K63Dgnmj+hjw5uMR3iSR+2PGqGCO3gT2 YK6oYfyLgD2YKxrClVhgylvAIXxm/hywoxU4hPnxPOFHPDknfwH6xQKTMBsSgQvvAp8wD5KA BePAJ8yAZPQDkFcIA1IIA16F+b8JvMXn4X8Gc/7PwDA866+RWU8nZ+Afgpl/iDLIHGdSiTDH r5PZzSLz+gaZ0WyqndKhj5AZfRNmVEC5lAwzmkdOuT9GDcAs5pNZ/DiZxQJypv0J6ofUNCpE lLZYW/bYfOSpXzLkPS20m/YZCg3FUaFzDGURqXxa6JChxlAfFnrA0GRoooch5ymhR+lzhlYQ HYgRCz1GPjmDGBV6wuB6VuhJUoPLoEQkGBb6quGU4RR9DXDoWaFvGE4bzh7JBVw2Ihcjcvlp MV82XzFcMcxExbhtmI3I3NNinjEsRO9lnjXcBrkAOU8Jc9ywZ1gBwfe7j8WUSyfA5xq5ggiz 9WzthjlTNalhLjqyhodhMc8Ztg3b5ouAe8+KeQH6d3Ak9bTqSLRh+QMjNU8v0gl08pEs02lE 7r43ElGhV+lMOicqZMbX6fynZBN0hy4iUgKyH8k/ZNSA5Uc9qjcoTBxd9awwiXQtk0I30M1Y mHT6RFiYLJqHHD2tZ3Jp/WP1HAlTYHhIm46Ep6WohEffcB9mBPjNlBLu1jAVTDXmGFOHR4Jp xPxgWiDVRnqbz9CMhbTIQvoargkz5TaZpQXzivk+YcMaGf2HZKQ3GQHWTiGMX7GhjJENFxkP jHIC44f29TODwGUdMwJ8dzFnaBVzHrg8pO9nxukSuO8g8CQIZS8xU8y04YC5ztxkbkGLMf+H mCXSSx3M2LwhyNyBEvXMPeYB1IVXLekRKRleK3h2g4YmZgPavwV93oX8U1CuGFbdKeYRpAqZ NiMylBk1xnhjkjHVmGHMJmu5KSzGPGMhXq/GYmMZSKWxBlbr/2XvXKCjrK49PvM9JhFhREwR ItKYIiIvMSAF5IJa5JF5gBSUIpWYhJnJiDRFiohcREQaKSJQoIiAlFKMMSAiImBApLyklFcR UJFSpEgBIwJFpBDu3r/zBSKlq3bddde6a927Zu3/7Oyzzz7n7LPPPud8MwwDzYqNRWO9aE1a ivXNGxPL0TUZE8uiOTA2ODYsNjI2Jm9abJy3/nQFFscmxgZKrAWJt3QpnZafnd8mNjM/PTY3 VhxbmN8vtkTmV2ZrwITYitjq2HrxXNP8TtKnaflbYptjO0R7j7z25WfFVhCBOkrmSvXkJRGj XoodFDqS30nW8MTYaZEPiZ2LW7F98dS4tB1Pi6fHM+IN403F18l4lsZ7vE28Q7xTPDveQ2Nc PMucx+8f0EiirU28X2xgPFdeifig/A76krIh8az4cBlBdv79UjIqv198rMapYG58fHxyfHp8 dqxBfF7ekXhJfiK+SOJxkI4tvjReJm3mSoQO0fEVHM9bUnA6kS+ZYXXBOZmffTKeThIvE5NW MlWyQHEyKJlifWxa/FgyLa9O3orcTfEeyfRkhq5riRnxVrJhsmkyK1acbJPsIBGqmeO0ZDP1 TnHBioIVRiNvYmJbspPY0nxHBKNpsoxEsNjakczOm5bskbcweX/e+nxL9FZIf44n+wm3JN4v mZu3ekC7eFaiXTKRHJQcQhb0MllyeAGZNd6mYEfBjuSo5FjJcwdNrkuOT06mNWkpOT3vSHK2 ZjPB48nZyXnJkuSiRO2kZPR4P5O5yF2pBUeSZcnx+f2Sa7Qn8TUyTxo7/eIb41s0fsxrwATp 9/r4Ts1J8Y9kjvfn95DZOSRx1VTyQdP4MfH1vPiJ/A7xM/GKvGjCSUjeyTuYqJmonbspd1Oi nszgPImb43nDEpmJRonmiVaJdom78nNj+9TveUvy2yQ6J8J5xxM9E31iBxMPyeoZJwkmmT9I 2t8n++OhxF2ygoOSs3KlpDAxNDEiPz0xOlGUmJCYkjcyPzUxIzEnMT9vR6I0sTixLD+YWCVW g4m1iU15e8TyvsQ26VNQ+rIrsTdxIHE4UZ44JX3cLLZT846L5tkCX0Egb1xBdck2tWQtRSVu 6kidphIrbQrqS/weK2iQtzDRKH4sfmzAhPj+vH2xHQWNC1oUNBA/WAWtC9oX3BPbXNC1IFrQ q6BvQU5BrKBrfra8D4ydLhhcMEy0RyYmxLcUjCkYlz+kYGLBtIKZBXMTEwqKB+Rzmmr2/zfM /0M3zISvkG811Nb/TSan2Od/2PKl5cyTV4m8FslrqbzKcsr6yitnTc6a/nv678nZKK8tOVuQ 7ZTXR/JS2X55HZKX1OtT3qc855i8TuToHdYKRoPdpY2a3Gh83Ggs7jI2Z16Hu4zLLSbAmTeF W0wqt5iruLlczc2lOmfeIGfeazjz1uTOci23let8/pr5NQcxJr53mNPK588Jy3s7ee/pXNt1 fk7nb0PZ2fJeKrT4n9AyQ9n9DHVd9S1prdCmK9A2Q9lD5H3Xt6PsUfK+16MDHh021G2fec+e LjRb+HKhU/9I2SXyfvZfU/ZSoTKx6/MoIFT9m8TYLqNutS6jOv8G1RdqcAVqfAW7Si0uo9bf jqLi927the75J9TVUHSXoW7Rb0m9hPpegXIMRWXeusW+HUVlbrsN9GiwR8MMRQ+b98h+ed8h NFJozD9SVGKg27h/TdFTno2JHk0TmnkZzb0CFV9GC/8NWiK04gq0Wmj9FWjzZbTj21H2IXnf k8P6uCJJWfYxoROe3sFvSUeEjl+B9ng2K+T99LejkCPv5y5RtnWJLurU9N5rC9WTstRLbVWl UKbXfvBfU6iRUPNv1s9Ou4zSr0Bat5W8Z8h7O+/9riv3559RdkOhplegLKE2V6AO36RQ5yr5 u2q+rcyXXh4LhXMu5pdQz5xv5o/KOKk6r56/L/qoTxXfPvTNPl3MKVVzQOUa9taW7hmVMd+9 zmUxfdqUh/KFkkKFJkfo/hIaYeQ6ptBooSKTX3N0viRPhqYIzTB7QGiOl9/PmngPiU8q83NI 9rTQYjPe0DLPD2JT86XahNSuzGdI8mJIfBeSPoTU7mHPv54/tS77ZOUedqCKn8VO2GdsaFlY 9otwda9fl8/TZXN0cU+pnKciszeGa5m+hetUqX/WjIW/F3t7n/wdru/JSqvQsivQ5fvytivQ rir7a5U99iKVV6HL9teL++V/Z5+sn/PNvbBxzqU9sMp+dzFnCYXv8d5l3wpHvTUm+SMse1JY 9qCw7D/hmCeXNaz7B+u2s1lPYdlnwoNNLgoP89aFtw4q86LGltrRPEd+qlwjRSZvaf2LOfDy tXXZuqrMLxfXVpHX/zHenI+7VB99WW9h2ZvC00y/w7InhXUP2uflJB2D7EHhhV69f5WDLs/j V9Kp7PMV8vHFstRL9E9z3b/KpxnfpH/Ik1VzZVaVHFklH6Kb4em0MT7QHN1d4qd7Y0N6ttH5 1jNN9xaeTGIl0kl4zWPe+aW7nI3Cp708JnPaXWNrjMlnEfW9+ss7E3Tv6uUy3f+neXlO40/2 6O5ir7vYi0h/u0vcdBd73SXOuqtNibHuI738WZkvF3pns8pz0+BLeRRbng36OMbkS/p1eR6+ LAdfPMNU5mEdp9rSMomp7hOr1B/njae18RdnLhlb92merH0V6noFuvwsmHMF8vx6+bnuIo2s Qpef6yrPaP+ds9mSnG+ev1bnXDp3VT1j5Xh1V1TxyeVrS9ZfeHPOP6yr8I6ci2essK7rfSYX XcxXB01ch4948VQpV53TXvzpu+SViLfuIrLGIkFDVddbJM3kiEi6ic9IwyucY4QiTT3KMkQe VPttvPcOl9agromI7HWRHlXWn+hF7jfrLSJ7dCRXKGH2nkoiH5UYP+mYI4OEhni2ZRyR4d44 Pf2I3OkiY4XGC03OIRdFpgvJHS4yT6jE7H9K5Ek5E0QWCS01+ThSZuJU98LIGqGNQls8f+0U +sjcEyKHjJ8ix4x+RPaOyBmhCnMG1PxfmZujsgdEqxlSe+wzEtvRmsbvUTmDRuuZOItmGj/q PEYbeWXNPRutTC6PyhkxKufDqOYeOY9F5RwWlXNVVM5T0Xzj32jSy2My/mih9z7UxENUzkJR OQNFZY+ITrgUP5q79TwQlbNQVM5C0Tme3Mu5UTkPREuNfV0nUfFRVM4A0VVVYrXyHlC5Rwkf XWt0opuMTL+NUWNNjXX//22M/0vPypzGzlr9RNXa5Hvd50vJEGoo1FQoS6iNUIcq752EsoV6 CN0v1E8oVyghNEhoiNBwoVFCY4XGC00Wmi40W2ieUIlHi4SWCpUJrRHaKLRFaKfQR0L7hQ55 bR77J+8nhM54pPoVPl+qY+Sp1YRqen075r3LGFJrC9UTyjTyi++NhJqbvqa2ujTm1HZCdwl1 FgobO6k9TXupfYQeEsr35EmhQqGhxm7qCKHRQkVCE4SmCM0QmiM0X6jUe19c5b1Sf5nQKu99 jldvVZXytUKbhLYJ7RLaK3Tg0rv6J/WwUPm/8V7pi1PGj/8uMQdVqYchtc987fd0D19GZ81/ O1/5Xlm/0u5VAaHq3nyL/Kpal96vqiNU3/d6qGsoGuoV6hvKCcWggaHBoWGhkaExoXGhiaFp oZmhuaHi0MLQktCK0OrQ+tDm0A557QntCx0MHQkdD50OnQtb4dRwMJwWTocywg35u6m8ssJt hDqEO4Wzwz3C94cmhvuFisO54UR4EDQkPDw8Kjw2PD48OTw9PDs8L1wSXiR/Lw2XhdeEN4a3 hHeGPwrvDx8KHwufCJ8JV0ScSLVIzUjtSL1IZqRRpHmkVaRd5K5I50hYy0XeM9In8lAkP5KM FEaGRkZERkNFkQmRKVekGZE5kfmhgZFS77VYXlfil8lrVWRtZJPw27zXrshe6IC8DsurPHIq cjbqiwag6tFasifUveIvLvi8X1xI5RcXqvGLC9X5xYUgv7hQk19cqMUvLqTxiwu1+cWF6/mt hbrBjODtvhuCLYOdfM2CecGEr2NwYPCnvnuDQ4JP+ELBkcGnfPcFxwSf9f0wOCn4jq93cGVw lW9UcGPwqG80v74w/39xz/z+Wv5Cvq+yQv83+cwsjySzZHbwqJNH2VV4JVk1mfd7vOr18/hc jxIeSdbNlKybKVk3U7Ju5lhPd7ynr7LJVf6e7r3P9mhelTZLvL8X+Zpkb5LXtuxd2XuzD8jr MHggu1xep7LPhnyhQKi6eWVvCtUK1QnVDzUQaWOR1w+1CLXOPhBqH7pH1iSrMvuUrMtoKEfm 6hp+acPHb2xY/MaGHcwKZvmc4L3Bzj432C0Y8aXwexvVg/2DuTIPBcFHfDcGBwcf82UEhwf/ 05cZHB18xtcwWBYs8zUKvht813dr8FjwmK/x/7B1f8WDzg8E+0p0+Cuuhq8Gfzv87fAtna6C rdwhyHOR/wp+vGCW+wZ8V3hT93b4HtS9TbA58lbOIOxo3Szs93NaKroP6nef3OHCpzn3KLo/ E1yMzsva7nn48yvpw2jkj8C3hG8J38r01sPh4E/REZvn/+w0EdzvjagJpQ/SK0bqtGVcBfQ8 oby9Bz6VUh+1XkXyKHVDSK6B70jdx7F2DT3pCLrotEYnJtgCvgV8ltMOeRK+NRaQgy0pzaL0 +86diu4j9KQdmsq3tE+gY/wwHmtlWNO5uM0pRm6wDdgTnXxsLsWmeMO6T1u0mrk5gs+6srqt ofAdwT3uYMGRquO3wKno00/Lp2jH0Jzq5gnOx+a1KvHvVt5/ktJJ6N+L/gvwaVg7Ce5H/6zz e5FbzjrBns5ObUV5/xdIYs5uwfaq4zut6M8GvwZXKto2mt2w01v1/Z9ioRh+AaVd0L+AfmP4 Q+Aa8C30jzo/Ec2w+zvhz2jcWgH3XeErVO7PdTcJHnAkEqx01fEddZ8W/Jui/5AnEbSzsJMO 1qPuAHASeL1zgdKHhd+qaO2FLwO3gVOdfjpHgaPgUrAELALLFVPqSFutzAyi+WxAf0MlF74j WMPDErAI1LrXo7mW0kVI9iAZiWSOmXflBZeCJWARWA6qfjc0R1DLZ9B9UaMCfio9nw+/Apzv SUrAIrAc7CRjWe0WEUUJRVrfDZ6k7iQPl4IlYBGoFibhjRdUx54OvkCfT4L7sbNf++w/6m4W PAUedWeBhWB/kEhwj4mF65mvM2juB494+DQxsEZjA0kFFiqwUIGFCqLiAKUHkBzwJCsEbcZy k7uWmNkMFoL9we2KRMJ+E2PKS6Spte3wR+VMr30QidXOQxmLtUGj1KqHpB6SeqzuempZcB24 gsgslTEON/GJ5YngJK+urovHiPnr9X/ilrZmgYVgf3AdeAxUm3upuxdvbMPaNvip8C97qN7b RD/vS1FrNQyaSIOfb9B9h5ktZB619CT80cB/qIcNaq98SOROq5iOfBszuw3JYtZIQzCDLHQ7 +e3ZQCPBp5B/Ri46BT9ZdxD/X8hpNUw+VE1/NTcueB3ZbAx4Pd5YiE5T1sIH8PeBxV4OlP3F j30rRTGwXWc/8Av1hksudXLUJ4FlygeaKm8fJraLiZMsoncztZa5i7Wus5BeaWnS5POAZs4m irI2d7KmdrKOdHXcDD+J0r94Y3yM/sSo+xr6r+FnMox7WP2jKLla0cxXs4Dsj9ZQ9GvAr0V/ pJc9SsgDRbo7sAZjyKeC14I308pu8EJKV53NlFLa1dJ7dZZl5Sqf5qHavMPLybOFr0NMbkeS AX4UuEHnl3z7MvH8AHl7iWZRdwcxuU013UbEXqpKZO40htM0n/s3m1Usd2XZEZiXHephyQMr iLEVrEqD61gvK8B17CCaq9O1rvjzXWo9zQp6mjjUVn6mvbK7aandzWQVR84q/htZ4/dQa1ng K/KD6rfR3kokq+SQrnSJ8A90Z6HnWV7+eRpNbWUeOAlcE7hF+cDzrNzuusuwcvdSWuahWaHK 9wo0ofQYkmP0Xz3cOrBdcx29naW7of8P7Inp9PY88jfw+Y3wGYzlgJ6UrB6O2t/iBAUP6+nR qqso8/U0WUVnbQZjnK1rzb6dffBWRTvDEYn1PpZfQvMklv8E/yf4LtjfrJ4XVMvZ9HmQom8R /BHwAbeaT88Vav9OZqoxFraY/VfPUXJOeJjspxE+jtPLESfJKDTevkfpDHq+nbZWYi1dR+r8 Ub3h4hPnK+Z3qO7vdm21Zn+gvHMnfGfGW84oviJXfMVKTKefZHurTHtot2LsV3m91Z5kwjd1 5Ozq38Co33bkNOi/i75tpC7RbrVzBuoap1YvPQNbvezPBac494rlDszjEidf49N6SfidWPvM Q7X2MnbuwGaW4wh+qihRd6NPT2XiATsFP7xCrcHgRGLgsKPeW4iFRuCvsBOF/xljn4Wf72GM SWp9Bu4FC9RjcsrSUYzWU6vwV2lUsAc9irVc+tkLOwF3mmYALxp1dO/Qn7OBBoruSfADcCXy TDBbc4I5c6qm1QJs5+5mH1G+szmFYmc7uAE7G7CzATsfox9DP6YSqxBJeyRRc2pV3ndaeyL4 AbgSeSa86tcwJ1taWWmQc1Q37HTTulZv+N6GVzuCK5FngjciqUf8cN7A5qdYOwUWgwvAUkd3 wC7Y7ILNLtjsgs0u2OyCl7qoZbuxatqN8cAaLKyBfwv+LR2FeHU2/Vd804xXeenbbOzMptZJ LKikDf38ysNNrCztQ0/3Nlarzs7Tjp42V3u3A21lnbOLNcvtQDV95iR/kLN9XW4BXcH3sVYX +6fBXWApdfuAnam7DPln4GZHojSQqeMKlCg6SdVxtrjLZaXTVmCwq/tUP3xViAe+Rj+oXg2U sK5vp7fbiZNPwYnePWU3s7OemNzNrO3GM8SnrjLxQEOdKfd6wZnciSw066O5HX4Mrbc38cZc vKoS22ambOTd0P8U/AosBtdzki8OHKIVlVzQeZH5Vf6Qh8w1/DITOSqRSMhmBrOZcblH+8bY f5R7ZdS9WjEg99bzW3Ulnt/qyizbL3FS2qQ+cdrqvuMMUN5+A/wl8mI9jzkvkxXRl7Oxnou+ S90Q56JH0HxP75vOBs3SNvdHu7fel52alL5Jrd8qptyAvDYWzoGl6OcQJyN1Luy31Lf2Pvgu YEtFJ0PnyMkkNorQf5eI+lDRnYdOS6IiXTXt55jZz+GTlN5KaR2ipRMWzF21FOxKWx05FbzM DthZPWZ/yg5SRG5cy66xXs8n9hxOpBPYg+ZyPhyB5FlONeXYWQXuBD8AP8TOQXAL+Dh704fs s8sU3ffgR4LLya6n2YN+ruc3pwmnuA89filYAhaB5VqqNy/3CP7vhmZ1sG3gR4LmRsYN0V7u YQlYBKqFN9AcRq23VCKokh4qcR8iKvpx1n0cDIGFnAwHc/7szJ2UE6zTkPh5h7bQtIs0lzpI BHUUh7F8s4dLwRKwCBRr7q16Jw28S8xscGtLrauxNgfMA7mfOmmM/Qn4pR4uBUvAIkp1XE+o r5yVyqfcGHgR7KP2qeV4qP7hjmCXqh/sjpz6Rng4CywE+4PEkp7cAtWY9x+j2Vlzo3uzu0H4 L9z3BF9EvsvDQrA/uA68TeON0vVI1iN5Ts+69uu6Qv3/yVm6Pvgf4OOcLTO4B7Xl7NqUU/EE IupxInaCngOtzlh+E/4Jbq9L6NsnyD9RO06I/u9TiXODh7PAQrA/qOvrFu2V8129wwZeMTGv K8I6iLWrwTmcEEaxjtI4P/yU+J9J6YcezgILwf7gOnTEn85N2or7nj5XFFSd5dRaDp+GB07j pY/cEtZCfS01yI31kN5YncMqcVdqT5yl8F/AO8SJg/4I9yizYFBvr1v19ire0KjY4oyibxqx Pvjl9Hw5pSaLdgCvdtMEfTpfbt3AfcLPVbl7E5H8CfiEl0s185SRSyehMw79V1lxn7OOriaj tiEDz4B/RzOwxJXUclczL+uxye3VnozlR7HWBH6p3n/lhqulhWiWKaau1AhP9XHb+hWWeWaS YrL977ndFLFCj7CC3mJ13AFyO7YXYOEVrPmcZ6VWGXbe1r45PKdyuBHLXOgeOoC78GPKi4Vy cCfruhzcyWotB3fS2zeFf54Wl+Glc3oGsF8iO20AHfr2jt6Rnd+AQxRtnpzYmwJjdb9jFU+C fwv9l6n7PCu9SCWBhGaDwCPI30N/P9gbnBM4rZjSV3c6dH6rkZNyA3xtsCXWzqE/hT5X093B qaXPqZzb3HTiR3lL++Ye09l3arF2Rpj7JvFQ6m7UOFG586l3p9YnliXccdqyrrvoHpHSlbn7 gJm6U/lANbeGlJ5hz1quN2KJXs0JnbQ0pSs7yxxdTZKvVoDryEsrQN1Ds3mO1AT5PuT7kH+B /CDyD5H3w9ontGJuXiPYGXeCy7Vdd7+OKMDzWHsxN+657HHTVd/6nd6vJcv1x8Nf0WfNS231 rh2owaovZ3WvUhRPbibP3EZPFLdQejXnoqv15CP58DxrYRYZQ0tHgkVe9tBau8kb7+q9W3Rm IJ9B/8lXgaeEX0qf73VuEPy1opOB/xcx0o+ZnaHoPOBpqqQ+96D3dYzOtXpHtnmqbJtb2x5u bRvJyU/ih3rMezPuZS8SLXVcyUWBVGp9xQnhdb2Pu0lHbhbOBHLsIOoOou54+GJty/o+LeYy Ly9z689nRD/nhruTFeEgeV5v5U4T+vkg+sdpkV65Y+BH6N3c/gm80XkUC63BH+t5Sc6NuiqX O9frvkAPPyPOzW36biKhC2O/zS6TcfVVO4Eh4HBFZ46zgMypK+IHyrvD3GH0Sv3ZCx3zecdK spmrpfZjuou5fuzUxP/L6eFv9d5tfwT/hd7W7dvhu+ht3X6NsVyjPXFZQc4DTl2RzKb/o+wv BJ+yJRKcI/opT+A3nAkf1tu6jE77c4Pe2e1x2HzMQ/VhDfABvae7y8Ef6T3C/ruOPVAbD2Rz Bz9ArRy9p9vfgV9F6Sn681d6uBj5l3yWkaGeCTSi9Q5gf8Y7EGztnS11V61Lrc16c7f+qDd3 ++f4py7PD/fTw4fBbGbnOeYxpLMm0StoLUBSj37O4BYzCexoeG4ok1hrk7jpTNJblZTKTcS9 hRP1ajSfAd9ynyUfKh8EQwaxEMJCCAtd0CznrtdEJU4TJLuRzHBkxv3UtRqAY7kv/5D78g+5 hbXlfvei3pUkEkTfSqD5IS3W5vzZDGvNtK7TCf5pg0ieVmuCK5Fngjeys4tn3O2MLunIrdCe ic222Dej6wA+qXdP6T+jwGYTbDZhpOWMtFx95TyglgOd3B3gMxpFWFhkEP/kwnfFDx0DYXyl 2J37+0d6f5dRhPXZl7OddsOsoI+xcBJrYd2ttFeSeRRfcm4WfMgZLfJhZFTuy3K/1tLnwHpI OjhjhC90tG/NkJBvnRuZi8/BLxXtTYruFkWnGfi01nWb08p3sNkNbAfOw1qR8RUWvgAb4eEn wEc146VsUA+kRvHnGe59j/CU/lHlUwLseg9rqXsLHt6EZif4AcqnbFBrqVE9mbgV3AfbMi4T G22Y5U7My0z4NCy0R+c1fT5g56j/nXRmYRGxcZPuYvYhHZ29AL4m/Eh09oHNqJUJpjGbtbWu O1dn3J2HvCWarzDLzylvfY6kbaA1OEXjDc26OpsSJ8+SAxW3YbMU/mb6nIYPn1S5aJ6ht2dY oXxSf+FVn99nX3gffoF+lg1mXXgF/lawSD8l90pfBeeiPxzeYB1wEnJTdyH8QqyVgp8g+QR+ Dzoit+67oE9Em4HPgkPBjuAecKSi31L0nUKSBfoU7Rj8VHA+eK3H66cGu6l7Eskk8F5qvQCf Rul+8CwSWrF6IvkC3thvT+unwQ8p/RpciTUbnW5gb+Sferz2oRjJAiRd4C9QqzH8IXAN+BZ4 FM0w/Bn4AHwFWAc8UNFYT4b0B33f31RiG8/UA9NV4mfU/gfArcj3wpeB29Ax3ruv4m6x0MrM hfJWR3A2OMfMAnwW6AOngvMr9HS62vhfJf7XwZOU/gHL083o4K83nkenAp2bzFiQ7KdXh+C3 e2O5m3GlSt3h1B2hEh/+8T+FZlZFlFHMoOcz6O0M+qY4CclJ8CiSmxR9hq8HpoMHabEhmAHe Dn5GWyYCJ8P/BUyvuEewF/x1zOwYE5MqtxbCN63Q2/cH8O2QExVWimKASAs8rugsx8J59UDg UeXdTcz1fOOZCy/pp43o/8LEBtYm04ev0PkaX92nq1LWVB3iX3GimeXzJ3TFMdKhHlpghuD1 YEdwJKUjsTZSJeJPlXdGngX6PMzQfQF+qoeqGcXbuz3PZzALs0Hl71W5/QKlp6h1Bz00EX6K EeF//0dmRhjpyyae4fPRWYKXdpjsob5yduIxs37T4OvhmTXor6m4S59KwQ/Fzs/gZynarGK7 GxF4Br9NopTZ9N+I/Kj60H+OPgfwXjojSsVLFYoSV4bXMeIr/y9AE4cPe5hB3dnYUf2t2NxB 6asg/vQdZ9RHwFngHy5cJ3ieMVZD8gb8jfAZzFoP+C30/DCldZWXjFEskrsofQycQelsPEC0 27fDm5Werh6zbkVuVsT74EtYHoCFAVje5XlJeZPZNrOu17JaP2MWyCp+B8/fiR2TCbeAf73Q Uj0Jv8nkQDTHofk9kwNpZTtyVp8zirWzAf6rC12kn2YfmUu2+UB95dwJ3xl5OXa+gicTWleB TcBMs2bR2QC+7WWnOwTZKfwb0VliVjRIBrCm4KUO6OwETd4gbi32BfGq3Cls1r7/FXAwaHJF I/BX4M+QD4G/B0wSgU8gf9XbCzSeR3u8esDsHf3QJ4dYuWZPYTYD+L8OOAncCpaB5HP/G8zX Bfh3wLPU3WbmCx5P+r+Aj4FRvHQavgalK+G7gb0rTmsPkX+KzYngArDUW7+mLY38DUT+aVZE b7AL8jXwbdB/GmvsO/51tF5BbLAz+snkdl00VxIt8P7TZONd8KXI+8CbvMrsB0qIqJrgM2QY zieB+lgzGak3vX3rwkz9jAkLFyp+wXgF/evBs+ThnmSSBeBDaJ4lD1dnLGafSvPyagaxrZmh PZL2eK89WeU08hr4YaWHmnttNLt5qBaKKV3gYQb7zkB8mEE/NS9lULoZfIu6PXjGeIpn+PV4 0lgv8KZoVve+XaPfTmnDd3LO82z5Vv2Wo3+rolXC57/ruHvyhMr/F0e/mbOaGxmftlidAlfr SucTnC3KW+/Bn3D2cFflMy89n/v6Wg11XvSJhN3YKdDWnd/oGUN5q9z5UqNR0T7hzPfp8yXR 9O1V9Ceo1VXRLeGZRgBs7ozQtYmFYkfOvXY/LJzT0kAvavUEW/H9hDNgqpOuM24/qR6z16qO 8tYo/Rcu1kBFu9DehzXR9G1U9GeaWkh2KDrHFGUUinPt53UU2OmkTxWs9cYOpX0U3dFYOAPu A8eBi219ntNY0Sqz9Xafofd66wySWm5f+qnfIquuEt8O5X17FUVf+Y2q77bHTga1Wtj6/b2G 9nSdfXsufSvVZ9rUWgy2Q9JI9d1V1Dro9URL+yCZbQ/XbIO8g4f6PSLHszZXvUTflirv309/ bMuv6J7SX72BtyxLJf5VlOo3kFv6D/CNWf1WWw9rnGAzfepilVkvaNa1fq49t36r61p5a6w1 VnCkpZ9uW6rvnwT2VLQfQWeqxXcdrYmCt9nPCb4B39R+BTvC+0+iSV3rXuq+AH8d1k5qlPr/ ROtnret0LVsaFX2sOvSzpsa/xaf8VkAkd1vX6Fq2btG1rPr+KHifou9viraNha5Y623V1Zxp bcWm8qetT3XXgC9FM4yFCup+F/4Q+J5fPbyEPhzxf080m/v1CafkRZGc8+unzOf9p3QvsFpo XrVG8am9/rLsUf9+7Y+i/26rtkqsZbpz+f+iey5YD2yuKNYEfZ/CTwRr+fehuU9XOvxe/3Dd TbC51T9PcIr/Y92PtCe+z7DwN+2Jdc7n02+hO8cVA2nwf4avwbfTr4b/PvLXkYgd59cBsen0 BTuBxxTtw+ACRbc68nOKlgM+j6QROj9WDOxGszEYpjQTPhe+D5qHkCB3ximm1Ie/hdJ3wVNI aMX+PfwA+FFgDySjwWGKfnprdaD0ffj99CeAziSwhNJ18G/Afw52B3+EnBHZ56lrrG0GnwEL wA/QbAXPuOy/0+JP4dfSn13gESS/wVo+tdqguQn5TfAL4Wfhk2Xwj4Mvg7dS69cpsvsEbjCz o7xzDLxg5kh5tzqSc/B3mTlCMtnMlPL2j8FcsBBrD5n5olaKmTV4fBL4wswa+gvAQ5RmKqbU R/IufbsNzfFg0viH1n9AD1cbn6hE9kTljcfwszMXbE+LeNv/JaV40irDAlHnTgHXoz8H3AFG QEbtmEibRT9Hon8zFvC5G6QPxI/VkNi7Cv2D6LwG3xFNE2P3gEHF1Ne0bup36KeNThcsvA2m Ib+BUTfCM5vQn0opa8TZSa0GtIVv7Slm3eHD3dTFt8448BbsvIlOC+zjT+tu6i5BzipzTawm aMusxPom9rDzB3g0reeodRSdX4ImQvCePdhEMu3ehK8WKvq/RPISbZk4vAO8E7yPutvgW2Ih C/wM/Br5WNrKg/8hdhiXS+tuazQnYGc6PJ63yA/OPHAo2Bsd0+IfQRMh71D6CMi82HVp8Scg nk9B4pykxeHITU5jDTpmdbNy3WuQ1ALJDDZRYWPNMpmKrGIdR5+6zhDwVbAYucmN8PZWJBvg 99E6cWWzdqwT1CLqXLOazIhWolMN/ZlIzLyvQt4TTAfps03ODBRh0/SKqHA+BllTDrHhp+eB p6j1JPpn4VmJzghwD3Lm1Mb/bj/k5CiHrOUQDxZZ3YmBK9A/RcyMIn5MvioByUUu68h+BonJ nOXUNXPKvNvMVIBYsh8EWWv2RJDoTdmimEpUuOxfLtEewNspjD1AqYO+TY6y24LdtXWfT+8g zq8r9NOivmAn8JiifRhcoOhWR35O0XLA55E0QufHioHdaDYGw5RmwufC90HzEBLkzjjFlPrw t1D6LngKCa3Yv4cfAD8K7IFkNDhM0U9vrQ6Uvg+/n/4E0JkEllC6Dv4N+M/B7uCPkDMi+zx1 jbXN4DNgAfgBmq3gGZf9d1r8Kfxa+rMLPILkN1jLp1YbNDchvwl+IfwsfLIM/nHwZfBW6t5A 3Qvo3AU/mdJC+IeQp4CMJfAFeBul48Ek+ANqrabdevTQ9JzxOnPB9tRl1P4vKWVEVhl1mX13 Crge/TngDjACmh6aGTfjGgnejAXG7gaxyTxaDYmBq9A/iM5r8B3RNHN9D0itVEpTv0M/bXS6 YOFtMI3SqfBEprMTnQZYxjM2/bffpLQFdvCMdTfyJciJXtfEQAJrJsJNrP4BOTrWc0iOUvpL kNmx8IM9GHwJa2Ye7wDvBO+jdBt8S2plgZ+BXyMfi808+B9ih567tOK2RnMCdqbD4yuLleXM A4eCvdExLf4RNHP6DqWPgHjSrkuLPwHxXgoS5yQtDkdusgHR65h1Qcy71yCpBbKmbObRxppl 1jjr0TqOPnWdIeCrYDFyk1Xg7a1INsDvo3UiwSbCrRPUIk5cE/NmRCvRqYb+TCRmZlch7wmm g/TZJtsEirBpesW8Ox+DrAKH2ffT88BT1HoS/bPwrB1nBLgHOXNq43+3H3JWt0MkWGRCJwau QIeodkwmKYc3M8Vs2vg/QITYD4LEvD0RJPZSthD/zLVLPneJ1QA+TGFEAUod9G3yg91W0fex 9aFPn4pskdIG5jmGPUEkXbl3x/Rpgz2XJwndKJ2t/zbWztDvp9nTeZZiqcT6K/IJKtcvWPj0 X1uopJ+iu0PRaY78FHULKT2sGBgMHwO7Yq3caNJuH+9pRgOfPqPQu+FsJM96Tzya82/r9ClK Ns9PzvI8JI1nI6XI52ldaxuSGKXT4C0slINDwWLGXl3RGoUHeukTEms9Ty1awbey39a6quO7 wPOK67znJ4K+P6uOm4WdntTqxBOSdirxX+fMFHlt79lIKc9ASnkeIlgx+YI+p+pxYYvmXvg+ ere1tinvvxe+L6Wd4FfC70FzBHwqfDtKf0etI0hqGWtIDlToTb8pOrWo1QLMpXSXQUrT4c9S +iIWGiD/LfLW8I0pDcDH4X9u+qC8/0PTB0qHKV/R88JpiYSGSBb76gp+BD9befsa7vIXFO0O 4AkkZ+Gno/knRXeHouNHboGllP4Xe98BnkXRtX1mZveZJ7v7DCEkIYRiCL0ICYRIkyYgTQRE ehFCNxQhBESaCFJEQSnSmzQBEREBadKbNJHee+9NCOTJd+Zk5SV5/X99X7/vu/7rv95rr9xn 2s7OuefsObPl2Xg1sgeUvkUYRe2B2nxGWJBwMNUm0hjGUro1pefTEa9Tmz6U3k618dSPRf1v JJztjlyPpBOVrKSSNYQjCElTUY1qFZUM9K+m/8Kue17n13cCI6jnLu4YdPkJPUeinEY4Qfsu JhxNvdEdD36BSurrNkZev35XrTzVVvTPQ/RDLSwPpDbRuoTfSR0z9TxLj8GTnUrW6jQbTeX1 /N9p+9Ttjc1Ue0jXou56dhzquR6Vh1Gfo2j8WVOScJyDaLQPaWzH9F5mN9LlEpXPIKvrr/di sXSsPpSOpH6i/M/oCcIzzSfhCI24mtJ4hkqyUZtLlA7SKF6jUcXQrG2lY/WmntvRCM9o9BjE bf5UC0l5W1udbsODdIn+/g56SDrLjECtiyeM2l/SabMqtXGopEmqHRLb2egoDjETpBljH5PW jfz63mw8jXA+pS1/Q21jfn23MxNhbTr6VmKjCqVb65bsAe0VRelH1HIr9TCa0iOp/BCxsYvK 81LJfar9nEqOUW+fU0l5anlbI3ocmq9UO6Tx1yJdztIYzpAlpFryWK01XgWcIpZo3gkH0kw9 oPZ+6qEIHas01UaR/Zyh8pIa0b/reanuttF4gWxgP/W8L5V/lw098sqkyxniKpTKfYSNqGW8 e9xndF48I9u7R5aQ2lLzlkOn0bbvkSXrNi0IR1NJQ2oZTscKp5Z7aK+t1GYS4Uqqre2ev8VQ Fw+NeRnpuJvKsxH+ROPpkNqS9O2SqrVuiVZEd63Jojwuq7PIqokNzQzrQD2PJz+wjtjb6B5L 91OMZio01VPRXrdor43U0k/WHkUtl5FlBuu0JxIykKWtphnX45+Seka754jurRnNUW7Cd2iE N1yPl4VijT7KLvecnYC1S1LPZd0besvxNKpitFeqX9U9D6a7xLegDdlVGx3TU+piugFZ3TVq Q35ApJ5HI2nf2vxnsvzVNJtax/WpvpFaDqDy+sT8WI3ol1aTr9BeJXVG5hN6qTaCtK5E+p4i /IzwGfVcmearAmEkYQ23jfZy/d151J5tjPaZaA+r6WyaR1bxjJ7kPiNbfUb2/IzmQqcfE28D 3SiWhUq01pNI07KpUYx8zi2anTUaJVmRpCgjrlDLNoQU4+COtkNcA58kH3iPfKD2MPVpnKXJ SqPIhveRVZMvwpazqKVu/y2Vx1PLapSuSeWzaeSHKL2Iyqv6DxB2o7Pvnl6T66P4J6Sco/mq p89WmtM3SK/I1Ljm30TP60P0aGnkg0iXCGpZz09rHto3G+TAPsPdmcV08je6ZwD6zhsY+nc6 7p1GjWBRuaXLAXSJv6l+y9rfRL8J76ffg/gtSkdTOprSxfV72v4Y/S49lnej8gWUbqnfH9Nv 5mN6C6VvUfqGTutf8eC+q/RXbqg8Rr8NiP0spG+zPKTv26zRqH9HAKB/5+4P1r/m8Afr34P4 l3ri9Vdu5If6Kzc6nbxWp/2DPKP0V27kHd2/54JGeZvSx3X/8gqln1I6tU1dwuLUshVhG/3d Gz225DOpY/Z8Se1nUTp1r2s05gdUnpvKAzXKCqRdEcLbpO9gql1GKKn8FWpZiY51g8p3Up/F qKQ0MZNakkS1Tan9CDriTmIpiXAAHb0itSxE++qWUZSOonQxz3Yqf0zpQtRPanleGkkDSheg dGPq57BGr6Q0fcnH66XaplQynHr7UX8Dh3p4hXqIpnQ0pYvr38tj+18oHUoYQntVoTEXozG3 plmeSpo+pFoam2culbQk3EL4gGozIxaV31J6CfW5jtIjqc33hGOofBml91P6vh6h/goHjlbb YXF6Li+SUyhNvOkn6f7o5Kt6PMk0F/rJO5bc07XJazWTqSX+AYQRhLQX9RCdvJla0r7JpHXy VEpfoD43UfoQpW9RLVlU8lEquUz96DdwACw2zHsNRNz73eMhuH33tu9C//hWCV1gKeCV31v1 KkUAXlmkpEAIOOCBbJALgqAIlIBSUAFqQENojn3UhQ/gQ4iDjtAVesJQt70PJGSH3JAJikIs 9lIRakIjaIFHrQd9YRB6jk7QDRJhGP2PwdR9FHjRZ+SBYIiCV6AMVELv3BhaAoe3oB98BG3h XXgPesFwCAVRvU6dalCj3ptvREDr+vVqRsAE6iUzfTP0JfTNebHHaCgLr8Hr8AY0gXdAQEGo D/1hMLSDeOgOvWEE7RMAEZAPdKR7FSpDbSgEn1B5GAQiDzkhHPJjv8WhJJSDKlAN3oSm0ArH XRjehgEwBNpDZ+gB78NIdwQZwYZIyAoFsIcYKA9VoTrUgWbQGkx4GRrAQPgYOkAXSIA++lum ccV6xIkGhC0I2xF2IUwk7B/XKj5BfEw4mnAS4WzCxYQr41r1aCs2Em4n3EN4gPAY4Zm4uM7d xCXCBxoNThhImIOwMGHpNvEd2xtVCWsR1mvTpWtnoxFhC8I2hJ0IuxEmEvZt171VnDGIcCTh eMIZhAsIlxGuw45bGdsJ9xAeIDwW36VnZ+MM4SXCG4T3CB8T+jWaRnzXuHjTIgwkDCPMgZXd zdyEBQmjCGMJyxJWIqzWVfdTm7A+YRPCdwjbEcYTdu/avU0Xszdhf8LB3XT5CMLRhOMJpxDO IpxPuLgHzpG5jHAV4UbC7YR7CA/16NilnXmC8BzhFcJbhA8Ik3p0juvmAUKLMJgwB2F+wmI9 ekRFe8oSViasRVifsBlhG8RinnjCBMK+hIMJRxKORSzumUI4m3AR4TLCNYSbEWM8uwj3Ex4h PEV4gfBaj56te3juED4ifKZRckIvoerRs1sPGUwYThhBmJewMGGxBGRSliQsR1iZsAZhHcIG hHo1ztH3BP8LUuB5nhWy/VspRh8O/b+jiR7DRC8qwfvfljMol5pm6PXSo+8vokA/Z9M3l/9O iqH3/mMM+svIaUY49qpzdLdHxwe9SvzLmPEvY/Z/wsC/jBE0UkGSvYBagxfL1J+iwEgVCmH/ YiozpTjGp8h/SeaC3P+SzAN5/wXJMJL+Of45Jwwj+J9jhr+E0bjaSMCoPxZmwzLYDAfgAjxg BgtmuVkMq8zqszYsgQ1mY9lstoxtZgfYBfaAGzwHr8X78BF8El/AV/Gd/Bi/xpOEJcJFQVFa 1BBNRCfRR4wQk8QCPAf1sbypNitqp8u3TpcfmS7/2Qt5I129B0/zIyDZC3krJm3emZV2f/Uo bf/BTdLmQyBt/yHB6fJ507Wvli7fLF0+nT4hx9LmQ/Ony9dJl++ddvzZZqStz74mbT5P4XT5 Ii/k8fzLE5WufhDlOfqHoFQN89VJlflTNTfQ5kLRV+V1S/e58pgrL7jyzh+1LhjjynKurObK +mlHUXBEWi0LxabNF/GnbV+0Udp8dLpZKFYsXT4mXX5fuvz+dPkb6fK30uaLB71gZZiIDU6X j03bPrZkunz6+hrp8rXS5WunncVSNRAVMhPHxkE7NoW8bWvcAM/UscDMQDMjxYog8DjV1Van mtqs1quNWOJhN9lNbHeH3QHG7rF7wNlD9hCEqqgqgqFeU69h3NT2wEUVoeeL8yAegiX6F0RK j0f4cM8imA/Fq5HuMAW2whlIYsE4Bi+OKtipC9yp5tRDrO68hai1C0SfHIFXC1F4zVNWXQHB A3FMV0luVXilxUMwf53kVnUIOOaOIG5VxxC3o67aQsMhUp3Bsa7H2rMkt6pzKDdi/jzJrS+0 vOC2vOi2vOS2vOy2/H28NWm8tWi8b9B4f6+pTTVvUk2dF2vUThrhLhrhHhrh7zX7qGY/1Ryg Gg6S44anmc31m9uBPBBZDUFWhVPVeR1ZX6/WgwfHtBGZEqAjPhN0hwn/8uP+g1CrQZjNwDLA ABbOssNA+n+Wg1kT1gyGsHjWGYbR/7Acwd5jCfAJG8FGwCg2gU2E0ewuuwtfsEfsEYxhT9lT GKtNA8ZxD/fAeO5wB77kGXlGmMBDeShM5Fl5VpjEc/FcMJkX4AVgCo/idWAqT+A9YR3vxXvB evT+fWAD78f7w0Y+mA+GzXwoHwpb+Fg+FrbyL/mXsI3P5odhu/Ch1TwTMSIG/KKSqAwporqo zriYKqYyYSQYM5lhxplxrJjZ1mzLipvtzfYsxuxodmQlzB5mDxZr9jR7slfMXmYvVtL81TOM lbLeslqx29ZQmzG/E+hU4e87TZ1p/FtfG18nft83wDeSJymuvMKrcqqcIoPKpXKJQJVH5REZ VT6VTwSpAqqAyKQKqUIiWL2sXhYhqqgqKkJVtIoWmVWMihFhKlbFiiyqpCopwlVpVVpkVWVV WZFNlVPlRHZVQVUQOVQlVUm8pCqryiJCVVPVRE7VQrUQkfpfCotcqp1qJ3KrDqqDyKM6q84i r+qquop86j31nsiveqqeooDqpXqJgup99b4opAaoAaKw+lB9KF5WQ9QQUUQNU8NEUTVCjRBR 6lP1qYhWo9QoUUx9ob4QxdVYNVbEqPFqvCihJqgJIlZNUpPEK2qKmiJKqmlqmiilZqgZorSa pWaJMmq2mi3KqrlqrnhVzVfzRTm1QC0Q5dUitUhUUIvVYlFRfae+E5XU9+p78Zr6Qf0gKqsV aoWoon5UP4qqarVaLV5X69Q6UU1tUBtEdbVJbRI11Ba1RdRU29Q2UUvtUDvEG+pn9bOorXar 3eJNtVftFXXUL+oXUVf9qn4V9dRBdVC8pQ6rw6K+OqqOirfVcXVcNFCn1WnRUN1UN0UjdUfd EY3VPXVPNFEP1APRVD1Sv4lmaLytyH8BeS7GklgSerEUloLew+R4HUDnmUnnmYfOM8nDeTh4 eSSPhACen+cHS1RD72abrc3W4JhtzDbgM9uZ7UCZHcwOkMHsbnaHQDPBTICMZqKZCEEqQkVA JhWpIvEcz61yQ4jKq/JCqMqv8kNmVVAVhDBVWBWGLKqIKgLhKkpF0Xfqi0M2VUKVgOzqFfUK 5FClVCl4SZVRZSBCvapehZyqvCqP3kr731zkf3Or19XrkEc1V80hr4pTcZBPtVVtIb9qr9pD ARWv4qGg6qK6QCHVTXWDwipBJcDLKlElQhHVW/WGoqq/6g9RaqAaCNFqsBoMxdRQNRSKq+Fq OMSokWoklFCfqc8gVn2uPodX1Bg1BkqqcWoclFJfqi+htJqoJkIZNVlNRn89VU2FV9V0NR3K qZlqJpRXX6mvoIKao+ZARTVPzYNK6mv1NbymFqqFUFl9o76BKmqJWgJV1VK1FF5Xy9QyqKaW q+VQXa1UK6GGWqVWQU21Vq2FWuT/3iD/Vxt952Z4E33nVqijtqP3rKt2oretp3aht31L7UFv W1/tQy/7ttqPXraBOoBetqE6hDGjkTqCMaOxOoYxo4k6pU5BU/pGfDN1W92G5uquugst1H11 H1qqh+oh3fdKvb5iEEO+tgDalsmas+ZY3Ja1BWasMFYA9yR7kkF4y3nLoR/+77E+9IH/sb7/ WJ9rfeFkfQX1aot19Bz/j439x8b+m2yMmZ1wPR/IInmMqGo0gmxQGipBDagHTfB6oROu3/vg ynIEfAGTYBYsgKWwCjbCTtgPx+AcXIN7uLIH5mFOQG8QAT0CEgLeJ9kzoA/JxIAPSPYK6Icy AVP9SSYEDCDZM2AgycSAD0n2CvgIZU9sN5hkQsAQkj0DPiaZGDCUZK+A4SgTsd0IkgkBn5Ds GTCSZGLApyR7BYxC2QvbjSaZEPA5yZ4BX5BMDBhDsldAX+BYOwixZ8AwxMSAzxB7/Q1GxpHm PQLGu8x86TIzwWVmosvMJJeZyS4jU1xGprqMTHcZmeEyMtNlZJbLyFcuI3NcRua6jMxzGZnv MvK1y8hCl5FFLiPfuIwsdhn51mVkLOrfI2AaMTKbGFnwNxn5zmVkqcvI9y4jy1xGfnAZWeEy stK1lR9dZla5zKx2mVnjMrPWZWady8hPLiMbXEY2uoxschnZ7DKyxWVkm8vIdpeRHS4jO11G fnYZWUKMLCdLWU+MbP2bjOx2GdnjMrLXZWSfy8gvLiO/uowccBk56DJyyGXksMvIUZeRYy4j x11bOeEyc9Jl5pTLzGmXmTMuM2ddRs67jFxwGbnoMnLJZeSyy8guYmQ/MXKELOXc32TkqsvI NZeR6y4jN1xGbrqM3HYZueMyctdl5J7LyH2XkYcuI49cRn5zGXnsMvLEZeSpy8gzl5FklxG/ ayspqcxYkMqMxVKZsXgqM5ZwmblCjNwiRh4QI0naUvT/adTjprtpjaAA28+ni1riTdFOtBed xLuih+gpeon3RT8xTAwXI8QnYqT4FK+Cz4nz4oK4KC6Jy+KKuCquievihrgpbonb4o64K+6J ++KBeOiL1f9Hie1j+/AA0/Svc0VNURO4qC1qgxBtRFswRAfRETyiu+gOXpEgEiBAJIpEXAn0 Fr3BFn1FX3BEf/ER+MRkMRkyiVViNwT7SvhK0F2GcLCMHMZLRoSR04g0chm5jTxGXiOf1gxH 9JDurqeuV7K59yYK6TrcJ/XeNRPxz1vkd1sU1vemRDzWgBFs6C+A5Tfyg/3CfqnHDTZCjFAj sxFmZDHC9bfvsO0/jsshN2QwgoxMhml4DGl4jQDDMmzDMXyGMjIYgYa+32WgbgNwkHofbrxq lAPHqGhUBIV1sRAm5or5YpH4VmwWW8RWsU1sFzvETvGz2CV2/xHj+m6ZmCPmYI/z9O+axUKx EPleLNCPInOb8HjnxPXnvc/BVguxdpVYLdaItWKd+EmsFxvERrHpj+aYep8r5mLv88V8/Uam WIS9fyvQO+MId2PvWg/dexEI/sNe/0AP4uycy5ne7y9aF+2nrQH3M7vwZfARDIYh8DEMhWEw HM/rT2Ak/XfRUTAaPsezfAyMhXEwHr6ECTARz/nJMAWmwjSYDjNgJnqAr2A2zIG5MA/mw9fo DxbCIvgGFsO3sAS+Q+/wPSyDH2A5rICV8CP6itWwBtbCOvgJ1sMG9BybYDNsga2wDbbDDvQj P8Mu2A17YC/sg1/Qq/wKB+AgHILDcASOoo85DifgJJyC03AGzqLHOQ8X4CJcgstwBa6i/7kO N+Am3ILbcAfuoje6Dw/gITyC3+AxPIEkeArPIBn8kIJmzHhdXo+/xevzt3kD3pA34o15E96U N+PNeQvekr/DW/HWPI634W15O96ed+AdeSf+Lo/nnXkX3pV34+/xGfwIP8qP8eP8BD/JT/HT /Aw/y8/x8/wCv8gv8cv8Cr/Kr/Hr/Iaw+E1+S9j8Nr/D7/J7/D5/wB/yR/w3/pg/4Un8KX/G k7mfp6AL0m/bC2EIU3iEFF4RIOqKeuItUV80E83FO6KV6CzeE4PFEPGxGCrGiIliilgivhPf i2VipfhR7BF7xT7xi9gvfhUHxEFxSBwWR8RRcUwcFyfESXFKnBZnxFmjjFFW/99W44Bx0Dhk HDaOGEeNY8Zx44Rx0jhlnDbOGGeNc8Z544Jx0bhkXDauGFeNa8Z144Zx07hl3DbuGHeNe8Z9 44Hx0Hhk/GY8Np4YScZT45mRbPiNFNNnBsmKspJ8TVaWVWRV+bqsJqvLGrKmrCXfkLXlm7KO rCvrybdkffm2bCAbykaysWwim8pmsrlsIVvKd2Qr2VrG4dYWt/a4dZSd5LsyXnaWXWRX2U2+ J7vLHjJB9pSJspfsLd+XfXDrK/vJ/nKAHCg/lIPkR3KwHCI/lkPlMDlcjpCfyJHyU/mZHCVH y8/lF3KMHCvHyfHySzlBTpST5GQ5RU6V0+R0OUPOlLPkV3K2XCgXyW/kYvmtXCK/k0vl93KZ /EEu1//7Vf4oV8nVco1cK9fJn+R6uUFulJvkZrlFbpXb5Ha5Q+6UP8tdcrfcI/fKffIXuV/+ Kg/Ig/KQPCyPyKPymDwuT8iT8pQ8Lc/Is/KcPC8vyIvykrwsr8ir8pq8Lm/Im/KWvC3vyLvy nnwsn8gk+VQ+k8nSL1O84GVyjpwr58n58mu5QN6XD+RD+Uj+ZvW23rf6WB9Yfa1+Vn9rgDXQ +tAaZH1kDbaGWB/bH9h97X52f3uAPdD+0B5kf2QPtj+2h9rD7OH2CPsTe6T9qf2ZPcoebU+y J9tT7Kn2NHu6PcOeac+yv7Jn23PsufY8e779tb3AXmh/Yy+2v7WX2N/ZS+3v7WX2D/ZP9np7 g73R3mRvtrfYW+2d9s/2bnuPvdfeZ/9i77d/tQ/YB+1D9hH7rH3evmhftq/a1+3b9l37vv3A fmg/sn+zH9tP7CT7qf3M9tspDjjM4Y5wDMd0PM5554Jz0bnkXHauOFeda85154Zz07nl3Hbu OHede85954Hz0Hnk/OY8dp44Sc5T55mT7PidFB/4mI/7hM/wmT6PT/q8vgCf5bN9js/nU74M vkBfRl+QL5Mv2BfiC/Vl9oX5svjCfVl92XzZfTl8L/kifDl9kb5cvty+PL68vsm+Kb6pvmm+ 6b4Zvpm+Wb6vfLN9c3xzffN88+npM93bp3vsA/h0jh6U7pzPFDUwvh8Ub2B8PyyaiKZwVLQQ LeE4RdOTopvoBqcw4n0Ip8UX4gs4LyaICXCBIvtFiluXKG5dprh1heLWVbFcrIBrFCFuGKWM 0gzoDjw3LdNiUWagGcii6R57Mc9ZzyV2RUbJGHaL7rfft4Zakzm35lg/8czWDusxL0Z33VvT /fa5GO3vQQCEQSTG/Nq4ApqEEWAdemc8hD0EuNpBqUWU0s9oAiEUstnbMH/Y3o541N6BeNze 9bztYUxtAC+uJ8IgB64ACqY+PbKP6nL7OOLP9knE3fZpxL32Tb2nCtE9qlDdo8qse6S+kqnX 35/RBGBui7IQtyk7TU0GqgmkmoxpasKoJgvVhFMNhwCctSicu5Jc/7ekMrwMcF6VVwXBq/Pq YPA3+ZtgWmOsMeCxVlgrQFp3rDvYHzfn81/+h2Js2gj7/3d8/d+JsDqG/tW4+T8ZM4NkG9lO dpAfYATSkbMKxsxaFM3qYmT6jOJkI4yROjqmxsa2fzEq9v2TePjP0XAixsF/RMAXo8v/a9Hw ebTDuDgB4/eLUbEirj702iN15aHXHXVw5fHEXXc8xVVHY1xxTKM1x3RccSSh1TZAS22p7fL3 2Mk7p42bTqCT0QlyMjnBTogT6mR2wpwsTriT1cnmZHdyOC85EU5OJ9LJ5eR28jh5nXxOfqeA U/APo+2QP463KkBZyv5LUXfRP8ddlUEFqoz/FH232dvtHRSDd/1hFD6Mcfiofdw+aZ/+PR6r UJWZYvLN/2NUTv7nuKzCVBYV/m9F5zSx2Un+X4jOtRlnIXgpG87yQzCrw+pDLnrmnp+1YG2h EGvP2kNx1pF1hBj2LusMJVhX1gdKsr5sHFRmk9hUaMF+YHuhNe/OE6AfT+T9YCAfwD+EYfwj PhQ+4cP5pzCaj+JfwDh6ej6Rj+fo7ekaf5pwRBBMF8EiGOaKUFEQ5onCoiisEdGiMqyniH+A Iv5Buno7ZMwy9sI1M6OZkYWZj8xHLIv52HzMws0kM4ll9SBdLJtnuOdTlt0zyjOGRXrGeSaw fJ5JnqmskGe6ZwEr6lnkWcbKeJZ7trLKnu2efextzyHPIdbCc9RznLX0nPScZq1xbZDM2npS cG0wSMbKMmylfFWWZ+u8BbwF2QZvYW9Rtskb7Y1m27yx3li23VvKW4rt0M/P2E5vBW8F9rO3 krcS2+Wt6q3Kdnure6uzPd5a3lpsr7e+tz7b523obch+8TbxNmH7vS29cexXb0dvR3YkAC/7 2VGrtRXHjlltrQ7shNXJSmBnrEQrkV3HODuZ3cA4+xN7iHH2MfPb3G7Kpd3c7sNbOdOdc3yA 71PfJL4p9f0WvBpdTE9cmrN2bsnyF0oYlAaPu/bIi2uaGKyfg5vGxbgqmENS59a6ubWYO4mb fsumECuEVlOEFcFwV5KVxD5fZ69jcKnJaoLBJrAJ9JbNdmhlhptZzWxmdjOH+ZIZYeY0I81c Zm4zj5nXzGfmNwuYBc1CZmHzZbOIWdSMMqPNYmZx9is7wA6yQ+wwO8KOsmPsODvBTrJT7DQ7 w86yc+w8u8AuskvsMrvCrrJr7Dq7YQjDEI/Eb+KxeCKSxFPxTCQLv0j5O2UGqmJwutNg0K8V MtK9nzDcBGTDzUDm8qGmhUG/l1YUNy+yWhrXiWVxs6AcbjZUhirgQE3cFDTELQM0hia4PmyB WxC0wS0TdMAtGHpAAoTA+9AHMsMA3LLg2ckhnGVggZAVz9FwyM5ysByQg96OeQnP1zoQgedr E8hJT3Uj6UzNxeJZPOSm92XysJ4sEfKyfqwfntPD2XAowD5hI6EgG81GQ2E8gyfBy3gG/wBF 2Hq2AYqyrWwbRLNdbBcUp/tNMXTmxdKaugbddWpBd53eeX4vbLN7L+xlZCo7j+bRuGKM5bH6 t2G8Mq4Ya/AauGKsx+vhirEhbwgmrnvaggdXPO/iinGYNQK81khrNNjWXGseBFpfW4sgyDpk HYZQ66h1AsKs09Z5XEv3tftDTowegyG3jgxQACPDTCik/TgURT9+CKLRe5+EEujBT0Ms+vDz 8Ar68YtQEq+tLkMp9OVXoTT68+tQBn36TZwj/f5XGd7suS47XV2KoC450uhSipfCtlojwevg tYxBGpmkkQfXd01Akl5eXL29BwGkl0V6+UivINIr2FpsLUGNllrLISvpGEE6RlqXrauQ17pu 3Ua9tKZFSNNo0jSWNC2J8W8OXh/Mw6uM8qR1FdL6dYxLj6AmRqVkvDLRGlXnndynr/pXjm1I o6JaR1aPznt4XgJ0L5OzDqzC8zLO6rPCmAt+3g7PgD/goiwvi1xoRgyaY5N48RAvknjxEi8B uO5tDhaxY9OsO8SRz2psNQaFV+b9IQNefX2Bcz/WmgzZ8BpsOeS2Vlo/QSxeid2GctZd6zG0 xTXEUOiMq4XR0AdXB4tgEMb+H2AcxvqjMJXmfiXN/Y8Ywc/CKrKA1WQBa8gC1pIFrCML+Iks YD1G9tuwAaP7XdiIET4ZNmE898AeXOOEwSFc1+SEU7iWKQiXcFViwy1cXWSEuxjjw/EKAD0h XiG9B6CvIKGSvssAdfV7W/CW/YFTBfbgPtnZRHrLUfxjRqA18RpFVlfnhRmJ+seMQH0o97yM QwV6eh78vB0HYU2xZuOR11vb0dqe2Np+sZSus1PHk5NGEuUeneNRwv8dz4p7hpAfAvJDjPyQ ID9kkB8yyQ95yA9J8kNe8kMB5Ics8kM2+SGH/JAiP5SB/FAg+aEg8kOZyA8Fkx8KIT+UmfyQ /l3xRtTA4dXEKmTiz57DcGaxIBxlJCvIirHSrBKrwerh6FqzTqwbS8S1yyA2jH3GxuJRZ7C5 bBFbylaydWwz28n2ITcnkIcr7BZ7wJLQ+Xu4w4N4GM/Bc/OCyG4sK4ja50cuXibZBKOfls1Z KZItWGmSLVkZku+wsiRbsVdJtmblSMax8iTb4JmnZVtWkWQ7VplkR1aVZDxGVC27sjdJTjIz a2ksN8NIrjCzaKmeem0tzUxeR0vPbK+P5FqvIrnOm4FksjeQpN+bkWSKN0hLXL1kIlk+A6Pj dGIF0BNkwDjPMVcYsQlGe712QH+AWqINoo7RiO+wYoitWHHE1gzXEahbCcQ2LBaxLXsFsR2r pN/9YK8hvsuqIMbjeoGjVtUQu7HqiO+xGojdWS3ESewNxCmsNuJkMxg46huCuMLUdz6eenFi UFO0atTTQFzrxfUG6ujRbzN5JaLf60VM8QYAR91w9eMtDwXwrGqG8TYe42xfGAwjYSxMgdmw CJbBGoxju+AAnMAr/xt4brvP89CSwtDWc6MtRbFYVhatqRqrjR6yCerdDrVYgGxNQoYWkmzO FpFswb4h2ZItJvkO+5Zka7aEZBz7jmQrtpRkG/Y9ybZsGcl23uxaoo45tEQtXyK51htBcp03 J8lkbyRJvzcXyRRvbi1R4zwky7NpNH/TaeZm0MzNpJmbRTP3Fc3ZbJqzOTSLc2nm5tHMzaeZ +1rPhzeYGA8hxkOJ8czEeBgxnoUYDyfGsxLj2YhxBkYGoLe6BfkKoDOdZdA/0dBf8q1N79Tn h2IYi907USyUbC0z2UiYPrbuhWV5nuqgLUn7XvQn48lWCPUTMhaIHgpYCF7TMPJEnPyLjmlh MJy9zRqyxqwRa8A6WI0w+jRJvS/Me/L+fBgfJyaJr8VS9UwlK79KQf861ZpmTbdmWDOtWdZX 1mz0tRusjdYma7O1xdpqbbO2q98UV0IZylQeJZXXemIlWU+tZ1ay5f+v9s4ErKat/+N77TNU 55x2w6k0z0pp2KdBoaTSQFQ6KSpDs9KkUejiUOhKLmlQ0iBCE0WoJHSJzEMZMiSkSDJEhv7r rES87vve933+93+f//O8z3rqrLX2OfvsvX6//f19fnvvsxdjkAllj/kbczNzCzONuZWZzsxg ZjKzmIeY1czDzCPMo8waZi2zjnmMeYt5h3mXeZ/ZzuxgPmZ2MruYz5g9zF5mH0uAJcgSYjFY TBaLJcwiWCKssSwdli5Lj6XPIlkclgHLkGXEMmaNY5mwTFnjWRNYE1lmLHPWJJYFazLLkmXF smZNYdkQLEKYIAhxgk1IEO+I98QAIUfIE/xrkBoo68NQpkeD5OAAY1owHgKjdjTM6Fh4Aszo hNHdzwTK30RQViaKzr2KUfZT9mPi9HJ6BcamV9OrMUl6P70fchvMVbBR/FwF8s1dxiNMi5+x QJpZB2P3BJizH8SsYbZ9E5sOM+7b2AwUux1R7HZCsdsZxe6ZKHa7oNjNRbHbFcXuWSh2u6HY 7Y5i92zmZxi157BEYaT2QZE6AUXqlYQkjNSr4X4exTz+jEX/Mwv+JXYathADjSaGRlMIjaM4 Gkc5NI7qaM910Z6PQ3s+E+25K2IU96HMj4Zm+oP1aRj/vK4VpjjS/3/04j/2xyHfgWsQQ56C IU+hIAvTkT0JZE8RZE9RZE8xZE9xZE82sqcEsqcksqcUsucoZE9pZE8ZZE9ZaLdRmNyXrWfS iBFbT0De/HLE8o955KcY8lOA/BRHfkr58lkWTWTEZ6UhlXxVgeEjHSkHOgqQJ9OQJwsgTxYc ymLBS/AWfPhCA2K4FC6Hq+FalKk0X5o/LZAWRIuixdDiCBVCjRhNaBJaxFhCl9AnOIQRMY4w JSYQZsQkYjJhRUwh7Il5hB8RQCwkQolwYjERQ8QR8cQKYhWRSKwjkokUIpXYTKQR6UQmsY3I IXKJPKKA2EnsIoqJvUQJUUbsJyqJg0Q1cYSoIY4RDcRJopE4TTQR54jzxEXiMnGVuE60EDeJ 28Q94jnRS/QRr4m3/72r/L/3XP4v3XOJY6KQ+QNobOIDjPkWf+qecngkgmD6nRF3AAvy75X5 clfNP71H5ut9NHAduDk+72vOPtTjABVoOOfFwWusHzK6MW4K32EN+5zwmbgbPgf3wv2gVkVA 1UvgX9P6WeFfxxpZ4Fq+L6b/WPhXvUYW/jWynxbrH4ot/wrad8XpHwv/atrIAvflDwqMB98V uM/flzk/KzB+fFfgKH1f5qHyre33QwmEJfgPSsTPCvPz9wVGre+LzA9F9fvyZf+Gthet4b/n Jv7g3ATA7sL4aQZjvT2kbFf0HJThp5/wn4SSjG3C0mH2U4AVY2Uw/zmKHcd+hxnQFawVjh+J rvX+u/9N/6P/Tv/J/5+e/xg6O8KCL+n8vAez5OcCMNZJoeyBf40DAC2YR+Mw2m+F9XSQAeuZ gD97dy7MvHBwELzgPwEWvIT5Sh+aA+MNeAvr/eA9ipkfYP0j+Azrgzh/BhIcp0Kfo+F0WBfA +U9NZeIw/8aF0XweojjMsXFxXALWJXEpWB/Fn58DxlU5WJfHVWBdFYeZG67On/kDxlgtWNfG tWF9LD4W1nVwHYw/o4kurOvh/Jl4svFsWM/Bc2B9O74d1nMpdugprlMxCmUajc1/ThwN7i9N lmbDf7IhzQ6j0Oxp3vzndNOCYD2YPyswjNVxsL6E/8QoWiItEdaTaMcx/gzHDbB+QhAqsyAO s0hcUENoEQaEQoQg6QmFCu/BgPBeYZj1Cu8TboD1E8KNsP47JFVAKELOoECaHEQZHlRlEVxk 9NBvnJFlcMznyy9zvzEIQAwCEIOAEb8gBYhBAGIQgBgEIAYB6HcfADEIQAwCEIMAxCAAMQhA DAIQgwxtIY5IBCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgE IBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBI BCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGA SAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIR gEgEIBIZfj7I16eFyM6DrxKoF5N1I3myLnQh7ST7pH5hIIDn8WStYZcFDgCHSQrRaWMJCi5L w0hvOmMsHVABzwQH1DwuOZPUGdEjX6C4Uh5dzjHDnDAfLAoLhyLqj0XDP/7lnUmkyoiVUSXG DLLtch2stqUqBHYwl4cbFQsHXMvjSeqSPGoeyaOsy6PgAMcZ3jLNW9BmB5DCXzcS0ODmxKOt o8yi0tn4LC6HTYrxG4Jshrt31MKgsMDo8DCOKEnwOwXYAi7+fqHhYX4cRVKe38NgS84I8o0M jwoPiFa2Do+MCI/0jg6Cn1AjVfjLKWzZkcv9/JW5QYFhcK3KztaWpOIoYQ6HQ3JIA9LQwMDY AzYNSc7XJrlq9V+ybcIkk7+cyabOcHJ2GX475Q/eTvKA6sgx488exYNyA/sZOA8ArMfzWIKY +sMk+v2AQfuDo+rwjiqWQW/kpAS9tS2O+ft3W+v3++dyHhhwbMpaGtTXqLToHVzzy4DxVa58 y6GZik4XAo50V7PwT1pepcVr355VrbpeLxjzJjki1bflRbLi01RrdT+Pq2sTNoVOLIk97z4u obNW1K0ks3f9XD2/38s1hOYp+kq+NK+XSs1ah58kqxuYC5REIptvVBcbiydl5zMZj7d4bhxw zWl4JTPfKkV8h4LFpmpN9moZA57Cq5trr6kcMCs4JODUor63J+VN5c2B9+Oddj/tK5/j8vqO Zba+WIRvW9fdvS9DVaiiXMOaA06ND7gHLP3twkze1j7NlrL8bZGeJ3kSp8ADopAHFOCIyJBs OJYKo6kskkEXhE5NowlQKKQCv5OAsC0h50K8EtOuPr7+pNgq82vps48UcsOQARVE+BOuUWFU W0kq8dtqVGlSaqXEObHOs1eqpGaDJhM9QympI9O3MZRIN/4blKhO5AzSIW9qnl2SzcLo6IgJ +vq+kSF6ocNW1PMND9WPWBTE79WPiAz3i/GNjtKHRoaOCN0QeuB80lTXkKNrAF1QD76J9Bje ZgCojuR0ctpwm8STJn35iri4uJ99hX/kP1139A+HHYXvOUWe40JKHbODxB+GJ+PZQXEnQ/wi x6y7aW4TqiO97NoYfXb7nGC5E0yj6uRPXUfSnglwHge/jqFe3X1r3gR6ruinPcJ1OTOtwwcD 03IeXFzeq15h3Lx6bs+t4+Hjph73YLi/jXqQ++qh4PSJk/Sbr5zvcVKN6Kcq4bscsg+neq0j xqWFGAoc3lM6M+/SiTsbVcXrTt7jtbjl97f1Fim7i4pu7ylJig5ZnN3Q23ciYt7u26EzTGZn zYiffMlorsfossBuOUdbesUGLaVC0dQiwx1q198dtE243+ObuclhEq1Yv0K6cs7OckvuRkGa qK520wT6dHm9PZyZbn4l25pLMjK1kjM2re3afghq1FGoUQXDGkWTSUdaKvejRsX9JTqgghwN HvjS35a7BoX663KjvUMjvikUaWJgbEAaGXDG8xXKAOrTcJNcVfl/oVCa5OihpmKYdVDEQv9I 5SlcG2UbruOE8TYmprqm44ysdEnD8VM4o0m1oT2S/+kecf0jY4N8/f+lol09N5FbsGNK4dJ9 M9wWc5Pj9pps+QVM+rQPL+TuGby8X7UR2/QkJqxHunMVwW5s9caOKeXFTqQKUxupecUfrbn0 fCr1CHNzJu5j+uKaoXj/WPNlL0pt3BO3Ku9o8TXK8bHdeKzs/s3c8W/3zPp08UncY2P2C6/O evstTrLWArNNk1ckSoR0NV1yWMoLO3dVcoGgxPq0Yk+LCU0Wygmh+rNlE84mm9aePDF+Yavu bFm159qigh7KG3hFzy9n2GxObD5psvqecObyxquH7mdxW5cIvnmkpiLgk+QRHCTzKeI912hV /2iOTNLaX4/P2vZp73RjyU+eT7c27eNmas3XKXowWsSvsa9CM2ZY0YTgiNBGiFe82pN84WOz dBZKa/nwAm+8ejDO1OM7sVIzenfTxTaC8Xzyh9gPlWMrThpXipCuQ2IFpYqEUpVnk2T9b4nV 0GK+FZERoVciqZo9QqqgUJH2I6TK7M9J1U/XHP0zBRf8mXrZnYhd5clpC79qltW3NOSXDLaz Dm2UnOjhKfkHN7x2u1hXoVLlF+ot39rT2f1mc491gfSUkwMDL0oPea3ICHU4aP1B03uJoOvy /e/LMxlV0af2duo6n0r4nOCYn3VDc0x1Weu9/amrVTdeeBX/0VsitL67eU3FvcIaT1p1l+sb H4UQzV2+DgMP8wdq7iWm+wdxKw4tzvTTCKhrfOnlU/vba/McBytM+KIpTULD4442zWFFcJZp a1tUVsGFDc7quTu731gkL2l2zZo7OmCnJX1M+dRTVS5pz+7iq/0+z7g26FDwUWvl7R6LfWbP DdedrVddcMlrIrWCUZUZarZ7gtO2y0BKzCfZMhbSFa0WqtfOYfUy1JBF6sX5Ub3mI1lgCG3W WL+lT8cPyEhRoC04MuSo7zqFvpqKo0uOHTqO1b8dxy7h4VAkoO2CAoJ8vaP9lS1joheGRwZF xyOVIklTQ44BFCVDA6hSBl+aBvzm34l4/0pqDkTO8ZIh/eoVti1QVrbKiuWGTJK7Ed587mXX os8ZUqL3702IXi1brZ9n8Gzw7gkrR7XrkdhtY3fG+rNlylNf9y4smeGQUlQX77A4207g1qfR 97bHrLu4N2rKipZVt1/V9Y3b2eRlc6e81Pz+mIUZsruLIqPcXo5K6/hknBaZdyN2vmKczepE U6lLUZ60o4EuKUUHgvRvyTA/b47Wao/Vd22TIOe8u5Li8+lc03xbjvMRTXbHZPJipJboGNXT Jo7meQbmm87nm9ITvRzdeGO0aQbVDi1Ovk+u6Pq8tDF/UiKIvbXNz73suUGD27l077Q+24sm Zqa5VXFeRaNyU86JpbqZNZQIzadcHZaaeXBEPEgR/qHH5oMQjaTAlxHa81MOYiJw4lMTSCLF 6UJfsghJQKWhFcNw8LUP56/l02WO41WN5K0PMhdMLOaE7zKrbdUlZb6+SQKnshQZGBeLgZmH NWb5nbgRJbwFk900Mx6NZn/UfsDgbp3TsZN0HhK3qaQdaZNnnWeZZPHnxe3r4kjo2nxVQsLm OkLY7ElbcsoIYTP9d4SNf8BYD631H+kLB9ic8ZNWaNiWd4dP3m9wMLib0A8rntrfPT/m+fSJ ui3WpczP557qcgrVmpc7Z65UmVtirj/9aEGxW87DiJrDVe/iD06N7J/UZbni7APWqKBzRTnK ugNM51Nu53UfTrtSG/GkWLiAUuR2/3Cyg3vfVqucl69e9DxMUjIyO+y2rZerlqi9kye/pT1N QKGv3fHdhvyzneyi3xzPyF1JjdyqvTg0W/adfC/3RmCz6qCXwvmCDXWaB+J93aYUzDz//mnh bLe2bNxmiv7817fKrvEMwj7u3Mru6A56sqdA59iZsaKE/8as228KBsQ1hPxN014uVZpWc/mB W+elJenSXk3GUvPbtihM3ah7rNRoinyPqKQsNrfN2FPlQuZpoZ5EYoNTKMF2NF+uZZ8TeflV yNmGZxGF7pvdE9JS8uTsKR79FwsDGdFF457r6o868zjSRPx1+H6zQN57lwMphlL+ikRym+hd v9fhF2yvXR31NP4UterqB517Ssm5JYwPbM3JpR3vH+xZYVsjsMDOf8FkxwqrZ47PK2PjWxlG QqHyKzlK7YRr26P8D4/sREv9MgedpfSW19NUlrZvtdQMOrkldWtTSmu2SpmwV05vQVnSwtWs YN2a2EWYQnppn9Syt1Kr1Y+suxhcbMfR33bn4WLzFuwXH7vLF9Y1HZYeICJTGgrNy/HJwYNB 2entosWiVSbOgjdOmpM8ugDU7xfD+i210Ajpt/zfod+kCWlEQsU2NiT5lAkhk980JPnNvw9/ /5V678gP2X/vtv1m7eWL9GQe1LU/bMyaqeZceqFN2lFdpOfy7svTS6NJZbFugeuuWyWnpslZ bS7L9CI1bmGLOpfVPVsvINJPUGEq26x0zlB97fa+14HyOh+XPVmn0PXEsTC/QY17NmXA5qLQ pXnllyqsqAXvd4VsCWwZc8eWW5F06dEYWz3NkiSnWS6sDorOh+BNm8iwta/mkNsHfrmRUdmp kvHLuyvsV4LV3FCXKptNO+yxaXYBYppaAcUZHVfpq6YVvF+zW8xOQoi3Y83zWUs+g20KzoKJ mChp+7z6rpptzSld1x3likssOXHN2fcmrt6S740fVBDe/7E/+wC4oOrgOviedvKEMnNYvffB Edn9z9T7p2D4nXqLjlRv/jzU5KrMIfFdtYlclfJz+c333en9l7snTzS+VCp/Wl5R6fSo2a8F 2Hr+/29U/0+hLBxr0Yzkk16UKePanlaVxt2+ED9zBtivF73YM5TF3nfh2LLUw3rXxAs2hPoc dsfPOSqznbPalk5ud68pn71N/oECSCqpWdL366VnE0FP+7FUBu1Min17L1eyzWnf5o4nKcHX VzY8Tuuj6ydSnv6mra4a8eHtx44lWXrC/QLtEbXSjts3LmJEbj2cPz4nULdxJtHl42Uhlfmr skW7gKzB+2bOtFiO+dhI5pmuCPPBRAb73gmG98belsOjuh1/XdFoPHZeYX13bQLTatk1bqRK D3m2Zom/lycYxZAgrtySyHxjdiRgdqWu/pP3iUnNM906t0ekhZSMn37tbXz9XumlPlovCrK1 jOhxsj5N5oqhSrxe5mmdmovWlY/eP0s4+HBncbTxYcfGxWriGrFMM5cNiz1srSVqKysrZgSe 2WE1uDJeZWWuJBnQaSU+T/ZMrqrKJeunY5/WvLZv1rnWarByuoa2vfp8jy63F7vuZm0/OyG8 bpVmNF2sJ1alPpvXoOl6aH+w+fr8WO+qsHz2rvq9dr3i4Z+SDUIOfL4388wGtaaAuu0Ka8X9 cHPd8jmphztUHh2sOOtbtcSVds1Sz7kkraJoyb7KvPQY2Zub17JjVPUNigXD8jw3jK7Pe7Hm rMqNbkWnpm09U+/3A//w9cyEM0FnHod17c64wNEaJBo9vVpnyOW3DujnWujNklrUxC78xOFR M0gedQsOALlq7d/Iy9+dqP12mjdv1Sk+pX1xWyEKhzXyHDL83m8tJocgRy6V5DPg8AepHKhF 4Fq/rts0xtvJVxIbG8Vy5T0zs2tJvxEfYXHcSNc87ZVjsBlYEOaLRWLh6DR0ABaNKWOuWDwW AVuBsN8b1hZi8fkaK9X/8BiNjo8ID4z0jlgYr/xDLKHyAMbu77DR8T1UWVVFa/NRHbi9Uog5 P46dsczOuyxkhcAa+vmo2/oDD8Puv0g8dGTXiymmR6XXMd582DM/5ZXr+biF2WNMDcX35ex9 LvxW6dF6P8YzmZUVk6+MMTc8IP2q/fyWpLLSKfv2tIcZH2DXCZdkHLniHqeyebuFTvWxE03Y G8X9tTdv9zQYUX0tNwSc7lVq+GC1pqPcy0Xk6XGPU5cTf8tvVzxjmtVznWzb5LoksLIcn/V4 0r7PUQOWWZ7h3b7E0rAudr+k5Ow3MyKuzpTtkir+3DiZlyUc86Jz8d106QHJc+/wl78mbdjl fmj6tjcB8yzmHcd1e3rd83yNOlKvm4RF9F9rnL5mXD4PVyB5+Ajj0jk8nAG76MgZE/+24P/d +TiBL66YN5eUHumHzG8XPAD8xq9LaBwR/qky0phjAnPScYYQYn50w36OgmHR2jTl40p7jJ4K uIc+N6m/+IM28x3E5uCdgJvvn8e2KsgFBFstmt5wWploal1zd9G73ZTdXactdI6cqGFvnnvn Tvk5uUmFGcYOzzalLJl7w/hhd4tmbZ22B3k/kbH384eAw+VLXgrOzltnmZSsanCUe5B5prLs SuoZh1q1iNy2Qop9xXVF6+XKj29Jph+dKtgWH6Atx33cMS0wam3mhV31Pgsqb016JHSn7HN0 DkW4eMuyWNo7h46ytzff3E8fjOl6lV6VV6c+HzwsO7v0Yvz58t8zB9WTz6vtwUgHMvNZU3S9 je0Vd1kBt7Fy3S7mCb8yxxdGFTlN3ZMc1mqVmEDqftxs/SyY8JE5+mbDLI2mm+Mjb/cYcjaJ CPjNa4k6h2H/A36SKgUNCmVuZHN0cmVhbQ0KZW5kb2JqDQo3OTYgMCBvYmoNClsgM1sgMjI2 IDU3OV0gIDE3WyA1NDQgNTMzXSAgMjRbIDYxNV0gIDI4WyA0ODhdICAzOFsgNDU5IDYzMV0g IDQ0WyA2MjNdICA0N1sgMjUyXSAgNThbIDMxOV0gIDYwWyA1MjBdICA2MlsgNDIwXSAgNjhb IDg1NV0gIDc1WyA2NjJdICA4N1sgNTE3XSAgODlbIDY3MyA1NDNdICA5NFsgNDU5XSAgMTAw WyA0ODddICAxMDRbIDY0Ml0gIDExNVsgNTY3IDg5MF0gIDI1OFsgNDc5XSAgMjcxWyA1MjUg NDIzXSAgMjgyWyA1MjVdICAyODZbIDQ5OF0gIDI5NlsgMzA1XSAgMzM2WyA0NzFdICAzNDZb IDUyNV0gIDM0OVsgMjMwXSAgMzYxWyAyMzldICAzNjRbIDQ1NV0gIDM2N1sgMjMwXSAgMzcz WyA3OTkgNTI1XSAgMzgxWyA1MjddICAzOTNbIDUyNV0gIDM5NVsgNTI1IDM0OV0gIDQwMFsg MzkxXSAgNDEwWyAzMzVdICA0MzdbIDUyNV0gIDQ0OFsgNDUyIDcxNV0gIDQ1NFsgNDMzIDQ1 M10gIDg1M1sgMjUwIDI2OCAyNjggMjUyXSAgODU5WyAyNTBdICA4NjJbIDQxOCA0MThdICA4 NzZbIDM4Nl0gIDg4MlsgMzA2XSAgODg0WyA0OThdICA4OTBbIDQ5OF0gIDg5NFsgMzAzIDMw M10gIDEwMDRbIDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwN10gXSAN CmVuZG9iag0KNzk3IDAgb2JqDQpbIDIyNiAwIDAgMCAwIDAgMCAwIDMwMyAzMDMgMCAwIDI1 MCAzMDYgMjUyIDM4NiA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg MjY4IDI2OCAwIDAgMCAwIDAgNTc5IDU0NCA1MzMgNjE1IDQ4OCA0NTkgNjMxIDYyMyAyNTIg MzE5IDUyMCA0MjAgODU1IDAgNjYyIDUxNyA2NzMgNTQzIDQ1OSA0ODcgNjQyIDU2NyA4OTAg MCAwIDAgMCAwIDAgMCA0OTggMCA0NzkgNTI1IDQyMyA1MjUgNDk4IDMwNSA0NzEgNTI1IDIz MCAyMzkgNDU1IDIzMCA3OTkgNTI1IDUyNyA1MjUgNTI1IDM0OSAzOTEgMzM1IDUyNSA0NTIg NzE1IDQzMyA0NTNdIA0KZW5kb2JqDQo3OTggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggMjM0Pj4NCnN0cmVhbQ0KeJxdkE1qxDAMhfc+hZbTxeDEXbSLYGinFLLoD017 AMdWUkNjG8VZ5PaVPcMUKrDhofeJJ8lT/9QHn0G+U7QDZph8cIRr3MgijDj7INoGnLf5oupv F5OEZHjY14xLH6Youg7kBzfXTDscHlwc8UbIN3JIPsxw+DoNrIctpR9cMGRohNbgcOJBLya9 mgVBVuzYO+77vB+Z+XN87glBVd2ew9jocE3GIpkwo+gaLg3dM5cWGNy/vjpT42S/DRX3/R27 VaOULuqxraq9rezFVaaUZa8R7UbE6epFaqwSyAe8Hi3FVKjyfgGKUHHfDQplbmRzdHJlYW0N CmVuZG9iag0KNzk5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwNDg1 L0xlbmd0aDEgMTc2MzA4Pj4NCnN0cmVhbQ0KeJzsnQlgFEW+/39V3XMfmQm5EzI9GTJKBgjk gBBiMjkBI3IkYKIEEiASkCMQQFSQuIpgPFCfsoCueKyKJ5NDHIIurLCuIpeKeKxCBLwXQZ8H cqTfr3oCkrfJkpGdl79/6lPUt+7uX1dX11QlmQYIAISjiFCdVzR8qBClCwO6Og0zFw3Nyy+4 45e7hwPZ9SgAfW3oqJFFN417bi2Qt6cAPB81tGhszv6c8tFAF9cCRK+6vKi4YGbCNDW2j8Cj xl5RXDSsd4j5NoD4FgBT2ciixCRL0uLVAOQ4lpePyr2i+PRNmbl4/CpMDxyXN6Jk1P3TfwRI dgNYH5g8s6L6mYGXHwWydBG2eW3ygnnSYzHvfwNkdTWAuvja6qkzd9xQugbIMqyvnjW1oqYa IkCHxyvB41mmzrjh2r3qh2cBWbsNQPdw1ZSZC78+9fZ2gLy9QNzrqiorpuyfU3wMj72Inb8K M4KTTSmYbsJ0r6qZ8xbmRFIso3g8x/IZsydXrHnz4V+APFMOENU0s2JhdfAsownrf4D1pVkV MysLb3QsBLItBEDfq3p2zTw5AVaiPWmsvHpuZXX8vhGbgdztATD8BVjfqyLXuD+eFT8xKONH bbQWGI8fuiSBhW8+/+amE+tPT7WA1ohJnVKfgaEms/VKyLXAifUnbrTA2ZI2xOtYjqkUYoEq GRQskAjjsOR5PC9DEJaTe0EFWtUaVTIeINoXCm/DtTRYq6IGtUgZYgskyFtgYa5iAVI8IlcC N9ilONW7raNJsiaTNLiByLKMR3eqNrErBVHdZhIdDGdCD30fJsDvBPWzsCpQxxZroOC3tKPP wtL/tC3dAd0JM7vbhq4g1sinutsGDofD4XA4nP8ryDq5ubtt6Cqq6N+PrRwOh9OdEJCbtegt wOdNDofD4XA4HA6Hw+FwOJzfP6ZSDSHwnLrrLeZ3nO1ol/LjeH638P/YHM5ZyPmr/IaqnPNA CO9NDofD4XA4FwcCCIShEgRCcQ0UofqnYQsc18qgBa3cCjrQyadBD3pUAxhQjWBENYEJ1axo EJhRLRCEakU9BcFgRe0Bwagh0AM1FPUkhEEIajiEokagnoBICMd4FERiPBqiUGMU7QnRqLEQ I/8CNkUl6IlqBxtqHEioDtTj0AvsqPEQh+pE/RkuAQfqpdALtTc4URMUdcEl8k/QBy5F7ato P0hATQQXan/oizoA9UdIgn6oyZCImgL95R8gVdGBMAB1ECSjpkGK/N8wWNF0SEUdomgGDES9 DAahZkIaahYMlr8HN6SjZsMQ1BzIQM1F/Q7y4DLUfMhELYAs+RgMBTfqMMhGHQ45qJcrWgi5 qFdAHuoIKJCPwpWKjoShqKNgGOpoGC5/C2MULYLLUYuhUD4CY2EE6jhFr4IrUUtgpPxPKIVR qFejHoFrYDTGx0MRahkUo05QdCKMlb+BchiHWgFXoU5C/RomQynqFLgatRKuQb0WxstfwVRF q6AMdRpMkL+E6VCO8esUnQEVqDNhEubPgsmosxWthinyFzAHKlHnwlTUGkXnQZX8OW7rp6Eu gOmo16N+BgvhOtQbYCbqjTAL9SZFF8Fs1MVQjXozzJEPwxJFa6EG9RaYh/oHmC8fglthAept ii6F6+WDcDssRF0GN6AuhxtR74Cb5E+hDhah3gmLMecu1E/hbrgZ9R5YgroCbkG9F7UF7oM/ oN4Pt6L+F9wmH4AHFH0QlqKuhGWof4TlWLoK9QCshjtQ10CdvB8egjtRH4a7UP+k6CNwD+pa WIH6KNyL+hjqJ/A43If6BNyP+mf4L9Qn4QH5Y3gKHpT/AU/DStR18EfUZxR9FlahPgerUZ+H h1BfUPRFeBh1PfwJ1QOPoNajfgQNsBa1ER5FbYLH5Q/hJXhC/gA2KPoy/BnVC0+iboSnUJsV 3QTrUF+BZ+T34VV4FvUvim6G51C3wPOof4UXUF+DF1G3wnp5H2wDD+rfoF5+D15X9O/QgPoG NMp74U1oQt0OL6G+BRtQd8DLqDvBi7oLNqLuVnQPNKO+Da+gvgOvyu/Cu6jvwF74C+p7sBl1 H2yR34b3Ff0AXkP9ELaifgTbUP+h6MfwN9RP4HXU/fB3eQ8cULQF3pR3w6ewHfUgvIV6SNHD sAP1M9iJ+jnsQv0C9si74EtFv4K3Ub+Gd+Sd8A28i/pPRY/AXtRvYZ+8A47C+6jHFP0OPkD9 Hj5E/W/4CPUHRX+Ej+W34Cf4BPVn2I96HHU7/AIHUE9AC+pJ+BT1lKKn4ZD8JrTCYVQZPkPl c3rg5/Tvfudz+jddntO/6mRO/+pf5vQvO5nTv/iXOf3zLszph8/O6XPbzemHOpnTDylz+qF/ mdMPKnP6wXPm9IPKnH5QmdMPnjOnf/ovc3qLMqe3KHN6y+9wTv+wm+b0vXxO53P6725O/72v 03+/c3pn63Q+p/M5veM5/Y3/D+Z0wBkXTOMNYVoQgIpd/1GOtuPs9r+P9uN4frfgv/nmXAC0 61U1gbPiooMYwrrbBA6Hw+FwOJxAY4zQsV98+7EX0nWc3X4dGsi9FV/xci4AP/ZWnfwYgfMb oMaI7jaBw+FwOBwOJ9CYovS4rRFUXW9h6Dj7QvdWXbeA7604F4DQ9ap8b/Wfg5qiutsEDofD 4XA4nEATFGvAjZDqwvdW7dehfhzP7xZ8xcu5APzYW+kDZ8VFBw2K7W4TOBwOh8PhcAKNRTKy vZUf32EydZzd/k8F/d9bdd2CTv4okcPpCnxv1S1Qi9TdJnA4HA6Hw+EEGmucCTdC//G9VSD/ Fwe+t+JcAH78uWonv6Ll/AaoNa67TeBwOBwOh8MJND2cZtxbqf34DlNQx9nt16H+7626bgFf 8XIuAD/2VsbAWXHRQXs4u9sEDofD4XA4nEATmmDBjZA/eytrx9ntdzz+v2+i6y34ipdzAfix t+rkV7Sc34AQmtDdJnA4HA6Hw+EEmoj+wbit0frxd3Y9Os42t0v5/76JrrfgK17OBeDHVwE7 +RUt5zcgRPTvbhM4HA6Hw+FwAk30wBD238L78a398I6z269D/f9OVNdb8BUv5wLw489VO/kV Lec3IEQP7G4TOBwOh8PhcAJNz/Qw3FvpLnxvZWmX8v8Na11vYTlvDQ6nU/zYW3XyK1rOb0Ds md7dJnA4HA6Hw+EEGskdATow+PF+iOiOs9v/jN//9010vUWw38fmcM7ix1cBQwJnxUWHKLm7 2wQOh8PhcDicQGPPiWR7Kz/eD9HJ3qr9jsf/vVXXLeB7K84F4MfeKjRwVlx0iPac7jaBw+Fw OBwOJ9DEXx4DejD48X4IW8fZ7deh/r/Lr+sW8BUv5wLw4zUrEYGz4qJDFX95d5vA4XA4HA6H E2gSiiXcCJn9eD+Eo+Ps9l/DMndc6d/QdQs6+cIXh9MV/HjNSie/ouX8BlQJxd1tAofD4XA4 HE6g6TfeASYwW7reIr7j7Kh2Kf/f5dd1C6LOX4XD6Qw/XrPSM3BWXHSo+43vbhM4HA6Hw+Fw Ak3SFCeYweLHd5h6d5wd0y7l/9uru25BzPmrcDid4cfeSgqYERcf6qQp3W0Ch8PhcDgcTqAZ OKM3BIHVj7dN9+04O7Zdyv/3TXTdgtjzV+FwOsOP16zEBc6Kiw7NwBndbQKHw+FwOBxOoEmf 1wcs0MOP90MkdpwttUv5/z8Ddf1919J5a3A4neLHa1Y6+fNXzm9Akz6vu03gcDgcDofDCTS5 tyfhRijMjzeiDeo4u/06NMxvQ7r+hgq+4uVcAH68ZsUVOCsuOrS5t3e3CRwOh8PhcDiBpnBl GoRCuB9vRLus4+yEdqlIvw3p+hsqEs5fhcPpDEvXq/YPlA0XIbrCld1tAofD4XA4HE6gKXoq E8Ih0o83ouV3nN2vXcr/90103YJ+56/C4XSGH69ZSQ2cFRcd+qKnutsEDofD4XA4nEAz3psP URBl73qLwo6zk9ulOvkPhv8NUpdrJp+/CofTGX58FXBI4Ky46DCO93a3CRwOh8PhcDiBZsob hRADMb263qKo4+y0dik/9mptdPJfEp/3TByOX/jx2hZ3wIy4+DBNeaO7TeBwOBwOh8P5P0Bo 8zFAlPQMTGGMzAURRgH7gopFKY+DETAF5qrdUg8pTpaB7aDa5ciHfO6Up+WRlsq2o7WDqOFs NqEUgP7vCuhFVddt799x9tB2qbFdP94ZlnW9ar2/x/6P96o7d2xxtjsr87KMIemD0walpiQn Deif2K9vH1dC70svccb3csTZJVtsz5joqMiI8LDQkB7BVkuQ2WQ06HVajVolCpRAn3xHQbnk cZZ7RKdj2LC+LO2owIyKczLKPRJmFbSv45HKlWpS+5purHnt/6rp9tV0n61JLFIGZPTtI+U7 JM/OPIfkJVePLsH43XmOUslzRImPUOL3KnETxu12bCDlR1TlSR5SLuV7ChZU1eWX5+Hh6g36 XEdupb5vH6jXGzBqwJgn3FFdT8IziRKh4fnp9RS0JjTKE+XIy/dEOvKYBR4hPr9iimfU6JL8 vGi7vbRvHw/JneyY5AFHjifIpVSBXOU0HnWuR6OcRprGrgbulOr7bKm7y2uBSeUu4xTHlIrx JR6hopSdw+rC8+Z5wm88HPFrEg8enFuy7NzSaKEuP2KaxJJ1dcskz6OjS84ttTMtLcVjYFsa X1BeV4Cnvgs7sbBIwrPRpaUlHrIUTymxK2FX5bu+Skc+yymfLnl0jhxHVd30crw1UXUeGHOD vSEqyr1RboGofKmuuMRh92RFO0or8mLqQ6BuzA2NkW4psn1J3z71FquvY+vNQW0Ro+ncSOXZ MiWmVGexwjFne5YwixzDcUB4pMkSWlLiwGtKY1KZBnWT07AaUkqwlWcK3pFpHl1ueZ0lneWz 9h5VvMUh1f0IOAIcR/7ZPqeiLUcdb/kRWJSNk7NDDcvPxD0ulychgQ0RTS7eU7QxU0mn9u2z wEsdjmqLhAF2H4zCvq0oTU/E7rfb2Q2+0+uGSZjw1I4u8aUlmBTdAO5EV6mHlrOSLWdKQsey ktozJWeblztwJDcpj3SoR+s8+y/IEtYjvyrdQ8L+TXGlr7ywyFE4+uoSKb+uvK1vC4vbpXzl aWfL2mKeHrklQjRti9FoQSnFQTn+bGWWKDF6xHj8p1YG9RSvRoujUskhUoHHUj7Mp6V6u72L jbzyMdZKCX5t1mamJ93VPj2kXbqdecY6AQ0WnbSw+Oq6On27MhxqvhMObwtwxENxiV3K9cBY fDLj8Z9X3pLGfGm0x41dlssq4PjzZbUl21WMbouXImx09u1TgBNdXV2BQyqoK6+r8Mq1kxyS xVG3kb5GX6urzi8/M3C8cvOd0Z6Cu0qxr6pIOj4UFHLqHWT56Ho3WV50dclGC4C0vLikgRKa W55TWt8Ly0o2Sji5K7mU5bJMlpBYAgoJXmQD1Sr1oze6AWqVUlHJUNKTvQSUPO2ZPAKTvdSX ZzmTRzFP9OW5lTwGm2Nyi0vOHT3KI1naF2AjFAuXNjojbHteEXpDC3oq9G5w9bRtFC4RejYM sbm9gqMxODQpKLuvIOE5ExWVUGejX49+M3oRJgqxmG9BXYK+Fv169JvR70GPawVUViqhn41+ LfoWViL0FGIaJJsl+xIhEttG4jUECeFwFL2MXgAbaiL6kegnol+Bfi16tVKP5cxGvwT9ZvTH lBK3EN5wfzLaHt5wpxI0Tp+RpCQrfMnxZUqy8apSXzhitC/MG+6rlu6rNiDFl90vxxde0scX Bscn1bJQb0rakh0mhOFFhqHh1aiEboMgQsAGjwqh4EFPBXVbjlsIbuzlTFq7WRCBCFQguDiw yVsE0mCyJmXrqUyPQjDY6Lf0iK+EHmk0W5PWZl9OD8J69JvRC/Qguk/pp7CEtrA+R81Cvxb9 ZvS70R9Fr6Yt6A6g20/3QxD9BBLRZ6GfiH4t+s3oj6LX0E9QLfRjNj8pyuJZ6Cn9GNVC/4GX 9Q/UIPoRxj6iH6Fp7zYMGpy0UYm4Etsitvi2SHh0WyQ4LMlL32n4pTeOKCfeaRxRm4Q4yIRk Ia4hfoDNK0Q0ZEyzeemhRsllezS7P90LHvRsQbkXz7wXJPSj0Jejr0avxtg+jO2DWvT3on8U vQc9jjJUC3qJbke/A/0+6I/ejX4Uei3d04Cn8dLdDc4cW3YY3UX/DuHY4zvpG0q4g76uhG/R vynhmxjGYridvt4Qa4NsA5YDtrFgaMEwEctV9K+NvYJtcraVbsa+s6Emos9CPxL9RPQr0Kvp ZhrXMMUWjAfZBNu1gDUb4CslfAoe14J7us3tzMUBKDFxpl+GMZS10londTtXrsYkE+c992OM ifO2uzDGxHnjLRhj4pyxAGNMnFOmY4yJ8+qJGGPiHFmMMRQvfeTlXpfYBo28jkjZQfR67KXr sZeux166HkR6PXPwi8hse6ghIQF7bI3b1TvBVttMal8htWNI7eOktpLU3kxqbyG1GaR2Aql1 kdoYUhtLat2kdhNJw66oJe6mdsnB7ghSu53UvkBqa0itk9TGk9pepFYig9xeam8YnqwE+UrQ mM0eOgwvy8TZJ4jasUftOObtOCdsRt2NXlZSbqwkxfkqR8ayMK4xIcuX7peeNDt7GN2KDbfi bdgKB9CLeIO24jDaigfZigcIQs1CPxH9FvRH0cvo1Vg7Dg1foWgQaiL6LPQT0S9BfxS9WjHn KHoKs9tMXK8Ylthm9EiWolvRxaGzU7u7pyXG4rIME1bEkKBYMjJWjqWDIIy9NjDYqrV6iWnD z6bjP5tAl62j99AV0BNvxL1t4YqGX3ravGRVg3OTLTuU/BFiRRx1ZDA4STyGaVCjpFMhRsvC FIihz2GY1BAzDpsFNTj72JqJmbXaYPsl5rDtqxgvxeiXMZts70tekTTY3sOc5zbY9sbcYXsz 0avFnFecXoJBs6RU3RiTZnthu1L1FixY02C7mQUbbItjhtqui1EKKn0FE2ow5Q6yjXFebRuG x8uLmWRz1+AxN9iyYibYMny1UlmbDbb+aILLF01AY3vHKCd1xCoHHDvIS6rcfTQrNSWakZqB miRNH41dY9P01ERrQrTBWovWrDVq9VqtVq0VtVQL2hCv3OJ2sZ1oiNrCArXIVFTiFsqUbVrZ pEe0FC4HTw+hkBYW5ZBCz5bJUDhJ8vxU5PASPa5WVI4c4gkuhMLiHE+aq9Crkcd4BrkKPZpR 15TUE3JPKeZ66HL8lC4u8RKZZS2NZvuCjUCIdend0Sy8dOndpaUQEbYgKyIrONM6uCCvAylv U9evRLSL9/SsLCwq8Tzbs9STxCJyz9JCz3+xjcNG8j05lp+3kXzHgtKSjUIm+T5/DMsXMvNK Swu9ZJxSDyTyHdbDEfOdUk+LH8ysHkjaWF+9Nb568dge6/ViAdbT6SBeqRev0yn1RMLq1df0 ys+r79VLqRMuQY1SpyZcOrfO9nisEx+v1Amrhe1Kne1htayOJ1OpEhODVWJjlCokCmKUKjEk Sqky7tcqiW1V7jhb5Q7lTAL5tU6Mr46p5UwdUwvWcXWVyhyXizQOKZ08nm26yh35lejLPXcu qIrw1E6SpPrJpW27MWf5pMlVLKyo9JQ6KvM8kx15Uv2Q8R0Uj2fFQxx59TA+v7ikfry7Mq9h iHtIvqMir7Rx6KiUQe3OdcfZc6WM6uBgo9jBUti5hg7qoHgQKx7KzjWInWsQO9dQ91DlXKCM 8VEl9VrIKcU1vhI2UoMex2t5tL00J8xSnakM3iH2iJujm3G1sg4MuOUx4vbZhJ4V9c3um82K 8JliRWa2s24rirh5iD26maxrK7JgttWRA65582vmQ0T+tDzfvxoEs+bNZx3uU1dNZ2BZPm6S 82rmARR6EooKPVm4mq3XaDC3nF2SJ/1MnsGQj2t7X2Y/zExnmYJwtiLLy2B5Ol1bxX+9//Pb wlz2FNTSTY3EHUvmQU2p4IktLKY4FRS3bWGacS3FPh5qSvECa4iL1Jw5RpvZLhf40sCu+Yyf N78t1tYX89pCX0tsUnOmS87COst1tsfm4QFB1QyR6KNUT0Ok6IQIAPkL9F+ysHWa/CUrZyH9 Gic6b5sHWAcvkGnwAmyG18gxbLUeNwJNwJZAefAwLIIHYBl+rF2NOXfAGHQqzH+ARMpNkAiP 4QfbY7AT614FN0MzhJEI+StYAkuFd7HVUjBBHGTDKJgNd5Mr5PkwHg6It8IguAJmQTWplUvk e+T75T/Dk7BReEM+DQaIgsnodsrfqj6QP4a+2OJBWA0HyP26l8CNZ6nFmn+CubBGKBOJPFU+ gRbY4Xq0QYQRsJNsoS48eiV8QSLIIiEXj/KE7JG3Ya0YKIMqWAPNJJUMpXbVeHmEvBPC8BwL 8airoQE2oPPCq/ARMaqOyX+Wj0Ek9IHheD1NsItsEVpP39KahT2mwl7qDYOxZDb8Bf4Oe4iD /JXOVhlVSSq36kZ5L4TAABiL1j6NLT8nP9Ob0S0RXhcL5BwwY7/cx3ob/gafkiiSSEaScbQ3 nU0fEeaCFs84AN0UmIb9vQqPvh+H0QZqpLuFJ8TnxJPqnq0tshnviBMegj/BX4kJr1QiNeQP ZB85RHPpRPoQPSg8ID4jvqOpwKueADPhbngOfibBJI2MJteQKrKILCP3kdVkJ9lDvqTZtJhe R48KVcIc4VUxB12RWCPeqrpddaf6y9aS1m2tb7f+LCfJt8NoHA+3oPUPwiN4ZRthN3yI7gAc JCpiIGZ0ErGTseQmdDeTu8njZB15hjThWfaQg+Qr/Ej6kZyk+ElL1TQaFz9sCeSgc3GF+QB9 mO5Gt4f+k/4ihAtxgktIFTKEUmE2WrVMuBfdS8KnYpS4W5Sxn5NUK1VrVetUz6leUx1TGzV/ wM/4HaeeOJ1wen8rtC5vXdna0NokfwqheA/x0wM3XBlofQW66Xi/V+KIWw/vEiP2XRRJIJnk CuyZiWQ6mUMWYk/eRtaQJxXbXySvYC+9T46izSYao9jcj6bSHDoS3QRaSefgYux+2kT30ROC RjAIQUKokCAMFcqESmGecIOwUvAIO4RPhIPCT8IpdLKoF21inOgUXeJQcaI4X3xE/EL8QjVe 9ZbqM7VePVN9u9qr/g5XNZmaUZrRmjLNCs0GzV5tOY7OrfASvHzuz4hJi3CLkC+8BPfQZDES tzC7cDxPhCnCCIojla4jy+li0kR7qRaqh9Ah5Eo4Jjqxr1+na+lPdIgwghSSIphOB/iOpg4R n8UgQ9wKR8RX8Np24ZEXqo3kZnpUbYQGXCMNxnP+TegvuoS34CPhANGIj8E/RD0JJ0fo08Io HAWvipmqErALD8OLwhyyGF6i+QD6k9q7cBxfSZ7FeaGYJJHjgozL4CtxFA0SDsGtcB39AI7g c7wc/kimiFPhHkgmi+ALeAqfit6qWeoEdSh5k04T62gP0gRUfAavbjDpRQRVCNxGyoQ16qP0 Q5gPu0U97BeeR+t30xeFEeIx1RhShU/AYrgd5si3wA2qEvEdMhUEMg7ixRac3RYJSaIdwyU4 q4zHOW0DPt3NOA9kCyMwJwJHzhU4LsbiDLEG3SqcJ0QcQdPwGb8KZ7Fd0KQupl6YqjITnHUA xLdax8DV8lOwWp4Ks+T7oS/OB8vkRXjEdfAZrIB1ZGnrTVCNW8kP8dm+QlVAd6sK5L60jn5I i+jK9vcXezueRMDX6F7ERKZqE9SJ70MRZMl3ye/h6L4UZ9jVMAkXrIfxKr/FMwwTtkBy65W0 Xi4QqvF6D8Bo+WnZRvRQJc+AkfAKPKlRQYXGhffYQ97B670JKukYeZ5Q2ToN+2EF9oIbe2s+ zj934GpYmfBU7HdJGgC71W6NR8GVM5yShC2n3Co4CZK4hf3Ox4PWrsBPGRXoYHG9mv2gqYGC ykvXuw3aDLVely5mqNMJSTx8+jBknf48K7o+Ril1YikFtd7wlqBLV6WJGZCG9YQMSiVCyFt6 veEW+2OrcOV7peWHsowRliOWw3iIw5ZvIStrhOX057jybVThwoRYMiwZpaUD+vcQrMlWQUhN Dv1i0IGUJ3aTGYKO5LduOvVz6wM7dzJbJwiN9HrFVgPM34gfkccb4+JTVF75uDvO2TvFoNZj J+HeSaVSG77VabWCQEGjzdAH6Wp1VIcrBXeoKShFt58IYgYlbpM1hUQa5zwdwUx0ZYw4nWE5 7SrLOJ0BWRnMqNMZKMQaPHgw8wP6E5erBzNPSFb03qSdfT8ZsLO/0EjCjx1r/cqnbDuyCp/K ILTTIoS7jdoEgylnLFW0nrL+3Qha+Se3wWikY7Vmk5WOpV752yYWwUv51n0pixmDWbEqyCjo gFCtzmAGrY7qDWqLhY41WEwmVK98YgOrZbCAV/68iZVg5HhTUJASOdXEakEiLjV2KoIdv2WL Zc+eLdbg8MEul3JBLoj23XS3TSMZDOqxakUFRUVFVYpqvfL3bgeLUaNSQ200YtzMVGdkqldU wywwmZQGx902FnOqiFHSB6cEKaIyCkDMBtBqCdWzC2dHUyLKQTbRcRCMm7txbhMoJwLlRHDm sEDYtfyQ+AOanpWRlZHhu5gy39Wcs1qLdi8BGqQNodFacYHxduMb2JXG4cbhQUJvMd7Ux1wi XCMuMC00LzNpDVSlHWwaaB5JC4U8jVs7wpRj1q+iq4WVmpXadcLTGnUwDTKb+6toiEpFtUaT qb9Ki1GtcUzQGOImlGq1Or3BYDKZzRZ2n8qDa4NpcDNdByYyoEElab1kgDvMqMOHwpAzVo89 hSq5jUsMxNCMF2wmBqxFvRgEEbzUn5pYPRZhwwRjUlC1hVi8dNzLkqpcVasS8BFc12gdUhrh isTHCx+wiNMuV4blSFSk5Qimos5JHi6DiKysDGVIn3FRliNHlqn6uZYt3rasXwQLBvTHhbUB F9axuLB+FYzySRyl+4DK+9LS0kpxQ23EskuxbCOY5OP1Zj3LVRbXJnnvBvtgcx/7YJMXo4MG m5MGKdGX+mJu38G+m1I6d04ZzCkjZbiBdrmScTYKCx84iNitDiuuxKyr8GPhmv5hkan4ga7a 1DpufWuJqvnk9/cNG/WQcOpEgfjWyVSx5aTEZoEC+UvhAD5dVuhJNrsX6aloijelmPJMqtSQ 1JiraLF+TEhRzFQ6RVWpmxxSHrPFtlf1Xo9PIj/r8VnI0fBvIj/r2WKTbWE2mysqIywjqjCq 2navTdOP9jL1C0unqaZCmm8qCBkec5V+nGmq6TP1F2EnyA9mCwkVzAZLEETHGDRW0IfGCIYI 36DMGcsiL7MbFZHMbt/3Lyu3L94adKYCRn5oYhWC2GN0CSsOirdY9liJxeq2lltrraLNbTDQ sTY3e2itwexhtmIjt5U9zVa12YwaoZSxIxjYk2E1WyxqlvY9OtYzjwiLuMvZ2azzgrXs9DiZ YCrYzM4b3EtjYSmNhZVs1uzWHNDIGtGmydKM1AiaWGaFJoLNK5pYdj6N8hRqjOzImijlEY+M TRnlmzQVyua4XCOOYOT0OXudsjk4/DDEKTXjMHtWj+DTit7KJlMcbGWEjQd7qtoR53SmpgQP TE4KC8cPABISlpw0MDXF6YhTC2mV25a8N3/63lvLVyY2npaen7/gyXU3LXzs9kfuOvnEWiLU jc6m5hMFNHjH9r++/tGObWzuXYpD5HUxE0fHfveIxB7EIhKHmCLm4vL4WnGeqNZZtTqtztTD qjOBoCWGGLWGqEGvu/ReLdHGST1IDxpnVTrKqnSdVek6azy7r1vcluSBKcfYD5wk2AMt+HnK +vzMxOu2srsEIus7ULN+VGZhdpOA3cqwoKCz05lWmcuuDB66LcJl+enXTnNlsE48bCn7YS5+ 3GZlHbHip8/gwcqnEFjeXGZWntSyuaQs2ZocOhB7LVzDukqjDrUufTxzWtY1EzJzcoZMCIkV nY/NGZb+9CVDs8rnnt6LNs8ke2gVrgANYNuIS6kit1mn3iFBf3yk5huveprZUXYEEo/gJ3EK uxuhIezezHywatqDD06repDumvbAA9Mwjr0snyLbxdn0GlxfxLqDSCrQKBX7tVKk2HgjGxiH yyyfQ+IIPJSQag8VxRqy/b77WLtmXBmtI+9iu4hXgdKj+Nn2Dd6wY/UqkmjBC8YWxJ5qJ+ta g8m3JP7Ftjaq6PO3UUWfWKuq+LUNgc7afPbreaC1mRT82kbbhTZa+LlZe04bSxfaWOBos8XX hv1Buc9dh/vJADg6yx8nLO7c4Z4n8K5/ANwV3HHHHXfd4q4NiKvljrv/B90asUncxR133HHH HXfccccdd9xxxx133HHH3e/ZAUA6/Qv4vpkOMF1RFiegV1IsTsEMX8OZb7BPgB1tcfGcOuxv ME+0xdVgJgltcQ1MOltHC/2V/+KexXVQR9La4ib6LHnt7DeuU8UZbXECKvGxtjgFzf/w9jXg UV3V2uucM+dkwpwEmiJQys8UYxoopCFQSiMfUoyICGmaxjEzzZfmP5MQksnkzE9mhmQm5iJy A8WIWBERuTHSXETMjRgxUooUAWulpEVaEAtF/kRKKaWUInPfvc+ZMK2t3/f43edjnnfv9+y9 9tprr7X2Pud0ktR0yuASPWg6YnBTnIxMqumCwRVKkAWDJ9D0IRkzjTE1GTyRviCbDZ4kfEVe wn4j3yRhLlXZwrkMPkLp5Vzh7Xs5T+DtL3Fu5vwk54mGD3Wu+1Dnug91rvtQ56Y4Gd2HOtd9 qHPdhzrXfahz3Yc6133I+LA4+y3ctsucq3HtyZzf5nwEsy1B13k3eErCOM5Hxsl/iuvR+ai4 9nv42AzO7+Uyus7xcTIT43gql5/D+RTOF3E+jfNCxs1x9pvj5lLj2tXYWp4lK2XBI+wndK1U QE6qRL2EGqge0KiZXLzl87hyg7OyFO01XCIDPY9SHT5WykdbNcZr1MSvKlFXQtqLsgKSj4LX YCyTreEypYDG9VVAZhlqNy1FWwNV/Uu2fFQy+0NzMouqyQPO5skmG7euyRhtpYegYTo8YaV0 aKqhcvQ2oJ9Zo9HkOF1LYNs/WlUwxHK4XT5I12NGKz0GDVVcI+udxm1pQEbW8HlzeY8TLcyy JpqKtjy+LjfvqeF+egKlB/IVhtVW2PoIzUbs7BjpwTXzXzNqD/c786zT8HMVt1XjbQ0oK3i7 i8/XzOPA9FrR4uY2MclyY0ylcV3KNbn47MsgpfE+NqqM69CMaNUZ66wfskIfEbPDHSfr4h6u gMXlfA7dHz5uN/PIx69Bv2ay5ZjNwz1SwTPxo55gI+o4S4f8ZNQsy8oMuz9ed/3/w9rvaK8Y ir2b74NYLGO5+nEriM3+j3Z9Ni5GbCX6WjQ+X2wXMP36WivQ4uMrb+A7659lQumHol7Jo9Ng lPqqdO7BlYuXVm6tdyibdT1Msg4S/yyHMp61ZmVOn24tcFZalzTUN2jNrkrr5xvcrgZ3qVbT UJ9hfbSuzppfU+3Umqz5lU2Vbm9lRcaj7prSOmtNk7XUqrlLKyqXlbqXWhuqPllLrDFbH5lf We2pK3Vn2yrdTei2PpQxPdOavqSm3N3Q1FClTeZSSwqGVBWwIsdd6qupr7Y+VlVVU15pnWbN byirqbfm1pQ7G+pKm6Za80o1d015Tan1iVJPfQVUW6c/MjvL3uCxLitttnqaKq2aEzZXNdRr Vq3BWlHT5KpDR2l9hdXlrkFjOXoqUZc2WV2V7mU1mlZZYS1rxrBKax3mrGcq0MF0uHmry91Q 4SnXrLDD54QhcTOgrqkvr/NUwF/WmBEN9XXN1vSaydbKZWXQHSdd/09n5+IVbPXuyia2SubV OxOw4UO6PstXlF6DWbTKZSwE7hrMWtHgq69rKK34sBNK9aVXuq1YUQOmQunRXB7NWlHpZW6G jLOyzvVhD2XgfGzg+46dvPXIcHZyNgtJyKpaXF/gp3Cs/wnkmb5T2I6okDZIP5N+LT0H/FLa JW2L01XKT6rY9Smuu/JDc1V+SBvXZ5pgmm76sumLpv+F8hFIl2InsD2m3wmcwg7hh3gcYzuf 3S3c/MRmOvRnQ4reT5/0/3KWiD0F3UVCNKr/VaMl4nOTxEdMaUTzXpd34dqqJ3TsXxT/6HPR 24/mL87PzDT+vCZ7ElNRXRFuQFseHvo6SBBXi98lSdwgbgD/nvg98I3iRvDvi5vAfyBeAX9b vAH+vgQLpBQphSTpbmkB+BelL4MvllrAW6VWEqWwdA38XekW+N+l2+BR9psPJmJPhSbNpIF7 TM3gAVMAPGj6Jnin6Vvg60zrwL9t+jb4ejmLBHmGPJMk+SH5YfDZ8mfB5yg5JChfUDCvslhZ Ap6rPAFewH68WbEpXwUvVArB7cqT4EWKBu5RPOBexQfuV/6NRGWF8nXwlco3wFcldJGQ8KOE H5GU0J3wc/Cd5kdJNM83h0gyLzdjdeZW80bw75svg79lvgb+biJmSbQn+khK9FvwNGoZZkki yZJsSQefbJkBPtPyY/Ctlp+C77A8D77Xsg/8BcvvwF+0/J5Ey0sWPFNbLlr+hvbLlnfAr1mu g79neQ/8hgWet7xvuQn+AYInqYL6Gzyh7VN/C35AvQr+jnqNRPXdpBEkJN2VdA9JSWOTCtkv +xoxF+k+7nnd57q3DT9jjflYUYEZfjMXmjHK7DAXg5eay1FWmV0oveZmlAF4g/khgrLN3IaW r5m/Bt5uXgH+dfM3wFeZ/x18LXzFvHTV8IkIbzwAPtXyINaSacnk6/0r+CXLJb6WF1DuV/dj Rb/FutgqRqEcnTQaaxmTNAb8HrYuYz3DaL0wQHKpu7SMrOXN7jqaW+2uXEq5zsoyNxXXlWr1 2P3DSPhKfo6VRmJnReEDE1kMhvcY7hviu4m9yyTFXQt4H0geuhaw86BpccFCK40yJES8GQw3 uITeEXTX0kp3PTl5Wc9LjZcBdkOiMC9X8nItL9fzsoeXL/Hy9LKly5bSdV7eZqWg8DKZl6N4 OYFo6M3to6Vo/EJ3rBbYX4SA7TJ7U4O9w7B6lb8dwlpKobvhl09hRaPxTsR+Y+xeGkfj2Z97 4P/nnY8b93FtItZv+lA9HPo/qZ6Mp+AinId1OPVC1E4dtI42Uhdtoz4aoH14Z3uFTtAZukTX 6JZgElRhrJAuzBJyhMVCgVAkuIVOYYOwRegReoVdwl7hkHAEmvGGKazA7HgbTcmEjajHO2Ep aivp9X1n9L0wqV2vZ93W64cP6/UjGXqdreeF8MXrer3wpF5/aa9eP24lE/vV+cd7SGF/Wu6p EClIIKH0jD5/+SZmDQkV7G/OJaDepLdX9Ot1ZYZeV4/icqaajJr5NbaaWuPqWM2lWqodqV/V Hq29WHt7aYp+tTS8dN3SrUsH9PF1LXq9rFav63O4lLlhQkNWw8KG4gatYVXD5oadvDXJtdG1 w7XPdcx1qZEaRzamN85pzGusaPQ3dujWutnfp2B1sa7NXaXXTfP0WuvTa89FXc5XbNRVPNsE 3xoShru4h2rohKAgblnCPKFYcAltwouiKM4U3WJIXCWuAzaJXWKveEC8iK2TLFmBRZJL8koH pCO4R4w1FZrcppWmLaZtcpa8WTogH1KsSq3iUrqVE1JygpIwEiPwSZifUJhQnFCR0JNwxpxt 3mbebz5svpk4LjErcV5iVeK6xOvDZg7rtSy21Fs6LOstmy09ljNqipqj2tR16tEkShqWlJk0 P8mVtCGpK6k36ZWk68nm5KxkLbkzuT/5UPKx5NPDTcMnDZ86fBGyPTX6ND0cPU5zoseFt6NP C+8DH0SfFgUgMXpcHAYMR79AI6NO7A+JyzvpESA72odxTrKj3wEUATtxLdHw6Hi6C2DaEzCm L26Mk48pQttO9JrQe5yG375BdwGp6DFxex4BsnW7sKO5DPSNwAimdzwwget3Uhb6csAXAAuB xdCcj/orqG2oC1E7MK4ISIKWHENLDrT0QUsf15IDLET7YmjLR81Gs5HMThWjnsao4xj1NEYd x6jjGNWHUX0YxUYcx4jjGMG8cBknQmxVIzAPW9l4jJwQDcbNlWNYmkNP4LoAdSFk7IBIX2Ke pM9wTz7NZ91Ji9lJA8m7AHGoXaCfQ1biPrZx/x8nWZwWLRFnAYuBx6MDYkF0APtheHQixkzE E1IX4pyDOOcgzjni2OhW8X4qJBmtx9F6HK0s8rsR+d0kofWFoSuTkBV9UxwXfU1MjR4UO6Jv 0jAhI/qm8CAwHZiB3hHAaMAKTALSgAcgmShMjb4qTIM2OfoqsssJrU5odYqjMB98Cp3sLxJh LhoJ2dWQXQ3tC6B5ATQvgOU9sMYJG52w0Qk9q8Wk6CYxBfzuaJ84BvVY1PeiHg9YowuwsjJx cnQBidD7MmZ7GSc8y2Jk6v+VPQqTZpKG1DdiUjQcrc9j/NOw8Rw8cA52noOd5yD5PLxwDl44 J94DTASsQBowGXggeu4f9A7NPhSHVz8UB8XIqZvIp5vxXiARMdmEWGyi+4ydwuOMnJuInJuI OY7DyuOwcqKQCUwHZvA8GPiIN4/Dm8dh+UQR48WR0Vx4IhdereVeHY96As4FK/o+Hc2Dd54W P4O2+2lATIfcZLRPiebifhuzdAT8DmuN7H/6E2L6USs+HNNR4B8f12YeV5Z/vfB+LzT2QmMv 7O+F11+DVC883gupXni8F88EsOt/PK9SoMmH+fugzYdI9ECjDzb4MPo4rO/B6OOwZxM0HIcG llk90OCDbT5o8ME2H6LXg8zHvqKkf8imj8ukSR/JJjbqFEadwqhTGMWieArSpyB9CtIvI2J/ wIhTGHEKUfoDRp3ivjuIUQcx6iBGHcSog5jrIEYexMiDGHkQIw7iFIjte7bnLZ84LjYmTR+H WQ7iuWV4VEFGKvRs1Ec9QG90ECfXzmgJL314atsJj8+lHPHR6AXxCzRNXBgdFL8E/mXU7BRb Eu0Wc3GSPQ7+VbQ5aLRYh3oZZOrBfTSNksVstDANC/nICxjZhZEvY+QF8TH0PY5rnIXQcEG0 A5XAMtjyKYwcEOdCYh7XMCB+gWsZgJYBaPFBywCf/zHYoWtZDQ0DYjHkqoA6cGZLA9AI3hy9 gKfOj1k3ZvJhJh9mGcQsq8UFsG8h6i9DK9PoAC8CiiHzFFAGXglUAdWAE221qJeh9qD2An6g GfoVcQl8kctXuksshT+duF4G34h8vqWwapjhoUHdQ+hfAn8XAMynTyGfnNwrF8hseCHmy0F4 4QL35ePg8B/uNPHe1ufexf4WAK6e5DOPpkRjxAVdP8BsWqr3wlcXELvRZOGxi0WAzbsE9WPw iT7XIPwxyOMFD+O5fvjt5ThZluNkGcTJMgjvrh7y7DxI3fFu3Fp5Ngwa2dDFtTp4DEuw7m6s u1v0oa0Zd8vhQ/bwjIRUTNNi8CU8E1Yb99ZdPJ/Y6krgRawIbxqxJ6Bno92wrduIPMuxAXEe JHWtg9DYxfNKt6ULke+GLasR9W6xAqhEWxW3rUSsQc0iv5RHfzU80S02AR7AC/iB5uhqSoN3 rsA7V4a8o1vRBSsuGF7qMjw0wLM8l+8J3c9PAiz//jdkdM/4xBL0l3KrusRy8ArUlWivQl0N sJysQV0LLAVvQO0C3EAT4AdYfpoNrw7wmRdD45KhCO+CxgFK4HbFdp5u1y4jIweRxQv53mf5 7IhlNjtB2M7BWxtOlLg8GjC8vAuxGzSygMVvhpFXJcY50IXs43FB7sei/RhG6Vk3gKiOZrbx fc72tWpEstvI1a64PbLa0M2yqsuI3gW8WZXyM0I/rxqxkuGI9stc5im0lAClPL+ZPN+nbL1i Pc/3AX6iaICPWzBIIzAaOwxg588dDexEe5nbyTy2dGhOXVMjtGvG2TQsdjZB06Bhx6ChYRCj mQ2DXFLEmEG+RxONGQfj7B2IO/kGmZ1Y65Nxe1tDhCxD454asvKOhfwEN05NzITzCfGFjmn8 rChlvo87M+oM3cwekbcyb0p8BqaZnTjmOBv19cQ832B4n0m8bPTu+mgvX7WJR90Zd0INi+1p 7nuWF9zvOGN1jxmrgeQISM6A5AzqwXiHcRbeGTGaj9CjdA57Rh/JfOAzMixhyGPx1sdsSxyK fsyfd6Id8+UgVvCRXnjpKeNqGfdeHXZAI9+VPDbM27H4G3fXhiF7Yh6NWR7rZTOJQ+tNGLrj 3Tl5SnDylPA7fiJ/U/g/vSWI9BD/b09EI/ERKJXYN7+T8ZHoQXxMNAMfGVIP4Zn4YXwS6BHK xvvNHHyG0ZfwsdBX8FHJTg688xXhM5x+jneoEbQPnxThAWEa3S08KDxIo/A+P4NGC28Lb9M9 wrvCezRWeF94n8YLHwgf0ASR/dGUiaIsynSfmCAOo0miKiZRmjhcHE7p4mhxNE0W7xHvoSni veI4ekCcKN6HzE0VUylTTBPTaLo4WZxMWeID4gM0Q8wQM2imOFOE7WK2+Cg9LOaIC+hz4kJx Ic0XF4l59HnxCdyLF4k2sZAWiw7k/2NihVhFXxWdiIpDrBVd9KTYJDbh6dMr+qlcXCGuoCpx pbiSqsUOsYOcJCgVSg/7lptO0kwi10ZgCwnuE6i3AtvBT6PuA3YBewzsB140cISo0Yn6GHAS OIMx51FfBK4A14FbkBEBM5AMjATGAlYgDZiKMZdRZwGzeZ/gvsb7BfdN1HOBHGARkAfYSGhC 2BuLgDIiTzewDeglwdOPejewTyh1bXFnu01NLa497vyqYneF66LbxXHL7W00uzeDb2ssalJ5 XdakNl5yh4CVrq3uea7tQJ97XnWme17jS00FLsW9wLXLvWBI5pi7EG3z0DZP11+9trHLXdzY 4y527Xfn8/4XUZ9EfWfeUBwvdl1BDTSKGJcM2evALfdmXG9utLq7uV2sPubehjl24/rwUH3d fZTjlvsEx0X3aeB8Y5r7RONUYLb7NHAe40835jUpHDnumzEeW3tVcdMEhsZA0xSOFU2z4Lf8 xg73BraGxh2wcwvs29lEjQNNc5gvYj5ovNTkAErY2g0fQx76GazumzH/xQB/LWY+jPmN63rl jj7XEaz/TJzf9rgLedz2w4Zj1euH2j/aH+dH+MTFgPgWx/m6LT72nyDjbRyJdSe71wDrwNex eIBv4O0xjNXjw+IUDx4zsx432NRr1P1G/Pph676Pxq8xC3Fi8ZqLGM01YsWwo6mdwwqf56Fm QHvTqiaFwZBZyxHfzuK7CJiKfNli5DViDN16ftv0Gu0n0J4Sy3teO3l9E9djUK9BnRJrb6xH foSRGwzxXLvDkUOpyJ9Mjg7485i7trETvnsG4NfV6xs3IafuxGol3y9FLAZN82PgOREDy43X Df4GcDY+92L7EPuO9V1qqsK1F3Ud4G686r7ceKPJ33jbqPU49ML/h/i67uyTy8A1lvfw50L4 LZf1c2x0z+R7kuWBaMT4AGKyF/vAqF17mlp4/vOc5PsglrOFmI/Vk5iNejvq2NkQn7NGDrJ8 RIxcLOd4Thl7X7vBdABXsMevuM9rt7HfjwHX9WuPCevIu3Ot54dnEkdcrsTWxXPBrMedX5vZ NfTHrsWmFAbEdJYnHWvnZ0JTS2OHJ4OtxTMT9mGferJRn2TrYueHexKHGHd+wXbcXSz8m1Pi 35ma+belifw7zWT+beYI/j3mSP4N5r38u8v7+LeWn+bfGKbx7/syoOU34lsi7ifSRGkiidJ9 0n0kSfdLk8kkPSA9QAnSNGkatD8oPUiJ0nRpOg2TZkgzyCI9JM0iVYpI/0bJ0telf6e7pdXS 0zRG+qb0TbpX+pb0bRonfUf6Dk2Uvit9l6zS96Tv0X3S96Uf0CTph9J/0GekH0k/pnTpWelZ ekD6T+k/aar0E+knNE36qfRTypB+Jv2MHpT+S/ovypR+Lv2cpku/kH5BWdIvpV/SDOlX0q9o pvRr6df0kPSc9BzNkp6XnqeHpRekF2i2dFB6mR6RBqVXab70R+k1+oJ0XDpOC6U/SafoS9Kb 0puUK/1F+gs9Jp2TzlGedEH6Gz0uvSW9QzY5XZ5KT8pz5BwqkRfIC6hGXigvolp5sbyYlsm5 ci7Vy3lyHjXI+XI+ueQCuYAaZZtsI7dcKBdSk+yQHaTJRXIReeRiuZi8colcQj65TC4jv1wh V1CzXCU7KSDXynW0XK6XXRSW3bJGX5O9sp9WyAE5RN+QW+QW6pDDcphWy21yG62R2+V2elpe Ia+gtfJKeSV9U14lr6JOuUPuoG/Ja+Q1tE5eK6+lb8udcietl9fJ6+g78np5PT0j40PflTfI G2iDvFHeSN+TN8mbaKO8Wd5M35e3yFtok9wld9EP5G65mzbLW+Wt9EO5R+6hLfI2eRv9h7xd 3k5d8g55B/1I7pV7qVvuk/vox/JO+Ve0Vf61/Bxtl5+Xf0M/k1+Qf0t98kH5d/QL+ffyH2iX /LL8Mv1aHpQHabf8qvwqPSf/Uf4j7ZFfk1+j5+Xj8nHaK/9J/hP9Rv6z/GfaJ5+ST9EL8pvy m7Rf/ov8F/qtfE4+RwfkC/IFOij/Vf4rHZL/Jv+Nfie/Jb9FL8pvy2/T7+V35HfoJfld+V36 g/ye/B4dlt+X36eX5Q/kD+iI/Hc5SoOKoEh0VJGVBHpNSVQsdEJJUpLoz8pwZTi9odyl3EWn lLuVu+m08inlU/SmMloZTWeUe5R76S/KeGUSnVdSlVS6rKQpafSWkq6k0xVlijKF3lamKlPp qpKhZNA7SqaSSdeULGUWvavMVmbTTSVb+Sx9oMxVPk9/V4qUIkFSipViwaSUKCWCrJQpZYKC p8ZqIUGpUWoEi7JUqRNUxa00CcmWREuiMMLyM0u/cJeKx1/hHtWkmoSxqqIqwr2qWTUL49Rh 6jBhvIp/wgQ1WU0WJqoj1BGCVU1RU4T71JHqSGGSOkodJXxaHaOOEVLVsepY4TPqOHWckKZO UK3C/eokNVWYoqapacI0NV1NFzLUKeoU4UF1qjpVyFQz1AxhupqpzhGy1LnqPOFz6nw1T5iv 5qv5wuNqgVog5Ks21SY8oRaqhUKB6lAdwlfUIrVIsKnFarHwVbVELREK1TK1TLCrFWqF4FCr VKfwpFqr1grFap1aJzyl1qv1QgkJ4myx5c7zcyWeRyvLSKjGc3Qlnokr68G3oNaAABA2sALo MNBJVJWO+hlgE9CFMXj2ruwBdgA7gQFgL3AAeAl4BXgdeAM4C1zCmO2orwI3eJ9Q3cf7hWo8 t1fexhwmYBgwAhiFdjzHV40DJhHVVgF1gJuEWj/qFqCd7qXZtIDy8GbEfnrHT23UQetpM95V +2g3HaAjdILO0hW6KZiEZGGMMEmYKSwQ8khy7HxykmPgyXTH3idxcjtWOU46NjrOgIUdbzg6 HWfBvI5DjjbHYbA6x4sOv+MIWJljp8PpeAms0NHvKHYcAst1bHEUOLaC5Ti6HIsceFtxZDvW OBY41oFlOtY65jjWg6U5NjmmOjrBxjlCjkmONWApjirHGEcdmBl6kx31YKMc+Q6ToxBMdRTY bzocYKJjrv2KI4dE+w3HPPtZxwKwy44p9hOOTLAzjqn2I44ssL3oPeAYB9bvmGPf7ZhAJvtJ xyJI5EHCZj8GHSaUi9Cah1ab/aKjCNKr7Cfta+1Yv3OH/Q37CufO/7F7osx/3oj4TxrpP9OT yH+eZjT/aZh7SEBU2vBmrCJeU4nKkEdlyKMy5FEZ8qgMeVSGPCp7wwByqeySAeRS+UrUsLIM +VOO/ClH/pQjf8pHAcidcuROOXK3PANA/pdnA/OABcBiIB8ojGsvBiqAWsAFeIEQ0EZUjXfK arxPVuN9shrvkdVnaKo93Z4BzASyq5PtC+yL7aPs4+yT7IfsFfZ59lp7vr3Q7rJ77cX2EMo2 +0p81tjX2TfYN6Ol274Nn157P/hu+77qRdV51TbG2E+Rwf9YoXhNfJdE8T3EwsRjofBYJPBY qIjFI4jIZ4cichci8jiNUZ5AXMbxuIxXHIqDJiIu28hq2Y7ofMbygeXvdL8lihhN+f84k0Dz SOOxziDzP48TzgtzoVYYKAwXrijsKOwsfKaK/XSKWXxHfAfkunidBDlbziZRyVfySULu2cmk PIkMlC0/sfyEFMtty21K+JfGCCmX70Y/qcJuwpnjhK3OZGAkMJbEMHLNaQXSAOSsM8u4ng3M BXKM60UG8gwZG1A0BMGpkRgxkYhzUYwM4zU5y8BHgO+Pwy60jQLG6WBtSFExMkkfz5FuIMOQ nwlgpZF5wIIh+Ts24ex31gM4950BroPZzMcY85IT9wHnCi4nRhYbbR3/AnD/cD4TB9xDnF3c H2JZmMSnVgyBnD16Wxmbewe3jdvHr3d+IvT+AVaLf7Kt8u1p3awt9ARau23rm/tbt2m5nuTW Xq2geXdrv5bbvA+9DrTs1kpQ7tOqmg+1HtLqNH/rYd7Sr7mbD7ce1fzNR1tPaCXNJyDD5E9j 7O7W81oL+GWu7ZpWgFnOawvBb0LyNCQLms+HybbVvymsaO2e5LDKW1K0Vc2XW7u1tc3XwmO0 9c2HUW70OFFu8QTCE2z7m2+GU7Wt3svhKdrGAIUzte2QmaD1+arCs7RdKOdoe3jLfv+l8Hzt xYASXqgdCahoOYZyjG1/IAWjNgbGhHO1k4EJ4Vm2M4HUcIF2JjAl7EB7CiQvBjLDJdoVjK0C TwG/GJgVrrMdC8wJu7XrgflhQrkQ9sNvYb92K5Db2u8RAwWt+zzmgKP1NHgJ1rg+sJ2tIq7c HujjHKUnj7ew1W1E+y6s6x9Kjy2wJ+zwFAX2Y71VgRfDW1AeaT1kux44Fp7gKQuchJ5PKLU9 gTPhrbxkkii1LbzcjrGpnuRAVbhFcwTqYK0zcDG83VOP9j7NHxpWutszMuAOk2dswI/SHGiB TCBwPfyiJxy4FT7i0SC5y9YeFFvPLy0JtEPGyj2gj0oL5IbbjZapgVXhVZ4slGs9swNrUc4N rA+v9+RwnfHlosBGeG9RYAsvGV/hv4p82+7bEz6m7dK2hk96OoLmsOrpDCaHSzzPYJY+rGhX +AzPt16+rj2IxdZwim6hlhu4gqxj7fs9m4IjW0/YrgfHhi96soJW+HBV8+7wFdsx+P+6pyuY Fr5lOxKcCu/1MO7ZwbjtSPPuiKjdCmYhP1nsjnl2BmdHzJ6BwKxIsmcvLO/1HECed/O90+95 KTg3MtIzEMxB7yvBRa39iNSZiOh5PZiHsW8EbeH5nrPBIqyoz7aKceTqMW2/pxN8Efy5D/K7 wmOWrmfccylYBnuuBp3YU9uD9YjpraAI22xBLTLWM5LzG4EXI1Z4PjeSZrsVDITPeG4390em ek3BcCTLOwxR6AZfEZntHcF0ekcFO8KpOtf2BDuRCWzsXO+44DMYq/NJjNvWBze19nrTg12l h70ZwZ7W8ywfImnemWxF3mxo2AarysDnBXcM8QXBnTgZmK9SsSJw5B64dzHj3nzOC7GiE95i 6MnxVkAPj0skR3MEByKLvLXBDrS7uLXe4N7wBG8oOABrtwcPgLc1jwuv8q4MvtR6yDM7+Err Ie/KwIucv845dod3jaezdDfOhPZInndd8I2IzbsheDZS5N0M/WXadltfxOntxkkygZ1gkWQu Wc9miWjakeClSA729XmcWkcCmZEcjxmWnPbO5LHIMfjV8BjvNk9ypMzb6/OXTsIuQLbbbgW2 RwKam+UDfH4j7PD2G36+Cst365ztQd3/fJ9O8O5j89r2BFKw6kPB2+Ej3sMhE9Z+FDKbEdOr pSs9Nv/I8HzvoeV1YcV7Yrk7XAXu57yF8zvtR0MhREoLZJau1ByhEcicY6FRyJyS0Das6Fiw J5zqO+Lb09btO9Z8rW3b0hJ2F/CdXN7e1uu9HOpu62dnbNtujzXU3drvO7N8FeLIue06O3t9 F5evbdvnu7J8fXi+77qvve0QvNfSdpid/G1HcbqqbSc8OeCnMXZjeI/vVvPptvNon9V22duP k/8a2rcgB7YFB9qu+cXlW8MbvUfh7c1+M9oNDvtnhTcuLWkRkdVHAn2Rs76LLWbMu7ElGZmf 0zISJ0YZO8e8I1rGYl17GLetD43DLsZc7PwMTUI2nkDm7Paexr2p19MZSm896j0dykBWnw/N hOcvh7LD7d5roXmt27w3QwvgpdxQdiQNfluMnNweysepshCSqeyuEQnbVoUKeUtxZC4kKyIr fBSqRSafDrkiHT4l5I10spMq8oxP9Ze1HvKlhEJh1VscamN3KG86LO/0KZFNvjGhlZAsCQ6E b/kmBCjShRnXIFL+0LrW077U0Abc6daHNmNPLQy1ISu2hbojPVo7u6viHpQaLvFNwdml+jI9 Z5HJJm1jZAcy+QROoa1aSWQn45EBzL4Y3ljbfD6y1zcr1Bs54CkLbYu8BG/0R16BnlmR13Fy 9kfewImBk1Dbw+z0tbRY28divdRu9Xe0pLWn+TtbprZP9T/TktWe5d/UMrt9tr+rZW77XH+P 5m/L9u9oyWnP8e9sWdS+yD/QkteeZ9sfuhxO9e9tsbXb/AcCF9uLsK834QkB92uspbClCHwL 2+/+ZMSu3/9SS9nXHJrDtz2yiOVP5Abi64wsYvEF39tS316m7WnRcD7sbwm0O/2vtIRh1euw qt7/BqzS/GdbRsbOENv2lhXhW+yO0B7A2LHhdpyouNtirg7kVSf4HuQVOMur8B7IdIbb9fzx HuWc3x99F3G32uJd2ZIcXhXjgT1t+7z9LPe8xS3PsNOAcW07eCr0bGq95r/U0tUe9lgZ17a2 dIVneRe39MTyE2OHuOZu6Wxf4TV5b7Z3aFt8eyJO/9XlE9o7/WnBHe3P+G+07EAObMcJM9J/ G08+fb6tuA+msti1b2Kxa+9iu0NfReSs93Jz/9fWsp3LvafvjpPh1GZTy07kzC2sdKNvQrAn clbbGOqPXPLNQSwuaQvxBJXqm49MuIrzZ1ZE9OFpMHIDeyfEcj60m5f7IJMbOhS57ZsfOtRm YvIoC1AO86wIHS4dAflsROdY6CgrsfvG+BwBahthuxI60XqT5RLa+VysbBul9WkXcXqU+FqG yiptYds4vdR2eTrbJiHzT0e6fHWh823pvMzg5Uy+X5zcfud/k/c1UFGlV4LfexT1w59lQZBG JEWJNKFpmrBQASTIoV6MvKoixIWqghjaJsQQYghtkL8FpAswrmtcYojpGKeXsR1jeoxxGOIS xhjadljC8RhC265LjEHbsBxjPMRhGA8xsPfe917xqhrbTmYmZ8+Z8517v1v33e9+97vf/e73 vUcVT4o06JFBj3va5vfdbGpuW8T8jJHZ1NHOvAVN3Q3FgDuaEl+Ka7jVrvVuJWxB3GltOujW v+KCyLTiSME/rQ332sO8DrCk1Lu9qbdhZ1Ve01FY0bCm2k0vLTYdb+r1ehruNvW+tAievN4Z 79a3x4A/wRuvtDaVtseDhrn2xM5dTdtgpbc2ngI7W3G+OhcQeysbjv+XN7zVmIe91U29IONq rMSZBTsrwJJJ6L1WOpWBthTZnvqmE+3pMFI4nXobm067jkLvwH/pQFNxu9Xb5lpoa3tFaOp2 nX7FtbcKdsnEprPteV7v3oj2Qu+BpsH2bd7DTdr29FeONA23F4P3RtpLvX2AK7zHGirad0KW ONq+a988ZEhv592m0Tavt5/2iEXXlZb5LtYcAaf3RcgSE7Cuo/a2ek81x7ZMdGlhp2vtCsMT eJfpS3hH0N9YCVf78TzfFYN0VzzRiXurkMYdsyvFtQAytch/JaphBOhqzGxd6Q03Wha7GNLA J3rvJbwHaTbjaX+v0NbWZYW1w7zVjUboa37vFNqDa6Qrr+k02FDYnIT85lQffxvxi4kuRdpb 23i4ZfwlC94veLfuNYP8bHMGyFQ0PoA9ax7HAvsU0F07iYYMjBoaBpvveyeas4He1ZzvOti1 m/i7kN+1h+hmktnaLLQd6OpoFtvPdp5tFtoHiR4GWmwf6epuLmkfBZwEe/Q87acjsMu0dR1s mIQ99ybReURfJLqX6Nq9Ue1XYE+fgdx4Uk03XgcfJjW7MJIb+8Hmo8072rVdx4neRvQJkJ+E HFu1t6brtOtg+2RXYnMN0GeR3zXYXNek7Tr9HnqY5EeaI9pvwLxnuCa7RiH+b3RdadjlutI1 qaJvEH0Laa8FbM7tugtRmu6NJroUaczJCt11D88ncIa0tIe9MgX7WhucARraw7rmGsfxThDO MLc6d7kGm1/rWoB1dKvrMZwHbqL83k6YI3+azgl7OzuPQ5xcxDPP3k7a0S5288383s5uPdJd V4iOcC00aeFUk9F+tzuqubX9Xueu5s72OciKt9oXXplp3t/+uNPa09jT1uNtadtn7Cxsadxn 7CmAleWFaISMBDGDd5FzmLE7K5quwGoSJdwS0nGh+40WY8el7nMt0a17us+3xHWMdV9osXRc 7b4k3SO3JLcWd4/hnWb3VbyL7L7WktZxDU4F0h0u3dvKd7WqO1b5XpXuUlsyO6b871Wlu9GW 3I7p7qmWgo6Z7umWrR33u2daHB0Pu++3bO941P2wxdPxCFqRnpbKjqXOmJbqfZruR9hv9xL1 m4799mjku2m8d07He+eeELSkx0iWpK9Y0hMtjULKkHin3BOH98g9cdK48M4dNNP9NeYlbAtx Poo7SI8Fd5CeZOT0pOEa7Iluqd1b05MpaztOdtbvC+nJbfHui/a2SU8npCcGLQeaRnq2NpTC OWeo5fC+uB6H/CyC7vpb+vZZera3HNuX3OORnzmQ3+SnCnT/3jKwb2tPrfzUQno+INHS8wpo 1bWtpX9fmvdiy6l9mV0nWmr35fZUtpzZV9BTjf+tgn51yFS/OuTpV4cafaHew4Lpl4Zx9EvD BPqlYaK+Ud/GXtDv0/83ZqVfEdroV4QloR8JTWelofdC77Md9MvHF+l3jp+DPjJYIvs4Y0xg n2WxrIq9wjLpPU6lrJd9g5WxfvbXzM1OQSlnZ9g5VsF+zIbZi2yUvcNeYtPsN+xl9n/ZfdbE Ftgya+d4LoV9jTvIHWLnuKPcO+zvuV9xd9k/aWo1X2Z/0JzUfI8tay5o3uSCNFc0b3MGzazm t9xazUJwEPeh4MTgTdxG7UHtBW6TdkT7JufRvqV9i6vQjml/wX1G+791Wu7zOoNuHfct3QZd PHdSl6Dbx50y7DPs54MN/9VwhA83fNtwjF9n+CvDGX694YeGcf45w9uGKf6Thl8ZFvhPGf4Q EsV/Ef/SxHeFRoSu4btDTaHr+P2hvw6d5Q+F1Ye9xh8N++dwnv/H8PXh6/m3wzeEb+SvhaeE p/C/DH8+/Hl6u3Upq6UnpfH4ey3bUYDjACcATrNY23HbCdtp21nboG3YNgLUqO2KbdJ2w3bL dtd2zzYH9YLtscALeiFCiBJiBbOQhL/9o7llepvexni9qBfpN5ImPpVPZYzP5rMZx+fyuYzn t/BbWBBfyNuYhr7PpeWdvJPp+DK+jOl5N1/BDPyL/IssnK/iP8ci6PtcRv7L/JfZWn4vvxd0 NvGtLJK+z7UO/J3IYrS/0P4Cn/ezG+wWjcyEv4i0VbMqW7Wt1lZva7S12by2A7bDtj7bMVu/ 7ZTtjG3ANmS7aLtsG7dN2K7bbtru2GahfmCbty0KTNAKYYJJiBHihUQhRUgXrEKeUChsA55J KBZKhQphp7BL2C3sEZoFOMzbFlcKyWCZExaomHzlsVwOCr3C0U/wwnEAJpwQTsO1s0ANCsPC iHBPGBWuwKdJ4YZwS7iLv6/T/Q14M9ovzvF/KGSyeojaXNYCMV9IcW6H+D7HnBDhP2bFEN/v sE/Rm9RKyEef1m3UbWLbdc/qnmVluud0zzGX7nldGnPr0nXprFxn1VlZhS5Xl8s+o8vT5bEd uk/qtrHP6j6j28Fe1FXqKmG9cOw4rCT0sgVfkQYxw2xnAQYBhgFGWJ5t2jZju297aHtkWxI0 tkdCiGAUooU4wWJ7KCQLaUKmkCsUCFsFB+DtAB6hUqgWaoV6KI1Cm+AVDgiHhT7Ax4R+4RTw zgBvQBgS2mxTtqvCRdtVKGNAXwN81XbOdt52wXYJf4uof1m/l35tGuLnrRYomeznULLYu1Cs sOp/wz7GZqFk60p0JSxHV6YrY7m6al0128y4sPlw+m84LAXfAVcaARDFONcc1LEAZqAXAB4H ZZTqXXcJIlz3CJCOcs2VxroW6LPZ9bg0yc0TP9WtL81wRxAfryNPkVPaKXS2O8qnG/nYFgF1 KTTqVuh8dywBXsca+1GuKSC4zXRdaYc09oe1AiL0J8rjwb5LoHaBjVgH6lvNJrVtanhS20DA se5wJ5FfatypvrErdqEteB39o/hVXAWqoE81YDsFcCwKKLahz7Ad6qyDPhXfKH2r5xB1yGMs CHFn+PmxRK7xuiKv1HitwZ3t862iG+tW2QakO935VO93Cz6/K7XSN37G+VRqxUb0F44Jx3DI Lb6nvTI2pT7iLil91e0qfc29w89O9VgCbRUD/KDUsSrbcDyK/wJjoUpFq2NWL49B8R/yFB0n 3VV+fSh1xBPGr4w3ImD8ymeMH6SVdtCXSyvxAmufzBvumtJz7rrSR+5zpUvu80/0y2p16we8 /jS5P6WfKtm/ip9jA+br/erWlc+uMGncT6p9fgnwtcsk+elptW/exVVq9TjUsY/1eXeDL29c cLeWXnJ3Eq3USk5W1ueYe7/v2lX3IeoX417J19fcR0qn3K/6fKZfiQ2qp92v+caI8jPuk6X3 Qeah+w3fOpfblGncF8pC3JdIjxKTUJcZ3WOooyzafdUXr0ot57qyZPd0WZz7GvkwxTPkSvdc dFk9l115nnHM665CzwTxtnmuu4o9N0muFHIi5svAOQYfumJAfyAf1n9Zv2c7xX3FSh++Od/p uYNj8Pn6abFXFbC2A2MqMF8F5iXZR2iTa5dnVskhrt2eB649nnlXs2fR5yulz8B8rMTNavtT AL/M4p4iPyOkuWfKMt331ftUWa77YVmB+1HZVveSny5lnwUoc3g0Zds9IUR7PEbacxVQ9FR6 oqmu9sSV1XosZfWeZBr/E6Cs0ZOGoMRdWZsnk2qvJ1e9l5Yd8BSUHfZsVe89ZX0eB9XHQAf4 keZXvbcnSXFQdsrjwfHSGM94KssGPNXUbshTq/ZX2UVPfdllT2PZuKetbMLjLbvuOVB203O4 7I6nr2zWc6zsgae/bN5zqmzRc+Y9uXC1vU/ZU9R5+El1YHwF6lP4uI9VqeJttbzfuop+JScq 5wNlnShrXq+KJZTDWIyX9+f8ldqVKM23UvvgaeN8Qq71i2V1raybiIB1FLj/qXIpjUdV+/b9 gJzkVz/J3pIAfwb059srA/fVwLpOle/UtTInSr5Olfz9lYavtCrrzdVRznAduLrLta6D5WEu 5hkg6C03IfjO4Yo+RTfad7Q8xreGsR/1+VhZf8rZWG5P+Rv2Cdfx8njfukc+rDtcf2p9rhPl iauevWW9rtPlKX7rMCBHKbnIdbY83e9MhNcwJw6WW0v15XmlEeWFruHybUSnlheXJpWXluaX V7hGynfSZ7heKpTvoutwzXWlvJn4IEO1rINoc/lukhkt34N38fqv6/87Y6Efpf9c9bvQ3zH8 j6xJf9nnK8FBbJmeo7xIz1Fe0o5o3+L66AnKq/QE5QQ9QZmkJyi36QnKu4Z9IVF8IT0XuUHP Rf4PPRf5JT0XuU3PRX6Lz0WCYvG5SFAyPhcJ+gg+FwlKx+ciQR+FO9qT7I2VpwdWnm2z5lsF q2gtsbqsO6yp1iprjbXO2gC4FWje2mndbz1kPWJ91aq3ZlhfgysnrW9YI6icAzhvNQO+AOWS dcx61XrNGpHptU5Zp60z1vvWKCgPrY+sSx/TWGOpmK1J0AuWDNKIn2IJskE2w4qvCOX05fj9 yYB721aYkXa2D+5qz0LJofvcXPYLNgl3stegfJz7GTfO8jUTmrdZAT6vgpYc87BK1XjNzCJb kAH9SSPPkMeujLxVNeZDMGIc7zkY5xtQzoNUlfUC2YhP/tbRLxIZRE8S8JKh8HAvjf9vNxWK hqWxF1gw+yjLgPvrLJbNDGCTwMLZVigRbBuUNUyEYmQOKGtZMfsUWPpptp1FQcx5WDT9l81Y 1ghlPeuAEsc6oWxgV6DEw9jfZh/mIrgIlkDfDu1YGWvR1aCMoqt5c0XXiqaKpvMPF80U3c8a 3zJSdL/oYdGjoqWia6Km6KEYIhqzPKIx764YLcbl14oW4CXnO6yJeffyHotpYmZWv5iL2Kq1 snyHWCBuzerPr80btTLRUTST3/ZCtbi96GrRVdFTNE1ajaDfV8R60ENlS2ne46xxsRG1KMXK pJI1K1ZCy7Z8hz0GdQF9QDz8QnV+LdDTBNNitVgL7TUwnmvYC5W+oodgnxHtBiumthzNr4VW h0Vv0YyYBtLHxP6ia/kOhKxZ0PNQPCWeKZqyJhZNiQPiUNF03j3U4IMlKyMAeTEENIeIF0n7 ZXE8y5M3Khph1AjQmwwT4nXUq/RCGhUAGxDEm1DfB60AYp/YiAU9Id4RZ7eMiLmbwUYxE+Qe iPNg4aKdKdrEELsW+/frG8AeZjeJ0eB9GC1YCZQCyKGWIEV2/SkwbT/uZ78f2I9njWf120/Y T9vP2gd941XBanzk2YdXLPcbBfDtIzjLEqAN2IfP/mt598Rke3x+G+BEiMo20jpVdM2ekjVr T7db8+vteUUz9kL7Nntx1njRfYpTZi8tWrJXgNRO+678PtFr301zuGjfY29GT9o77N0QO5kQ uTCH9oP2XogOj/2oWOCsdzY625xe5wHnYWef85izP6vAWSC2Fc04T9FsQg/OM84BBPtB5ykx V2qB15xDL1RS7Pi8KXlO7MubxBlfmVNRA7HVB+tuFmAeY8t50XmZdI87J/Lr8+ay6ilWj4n1 2AJ9k3fPmphVAMXjeMNxTqGpFDjOQ+ykQX0B4BKMn2X1YdlydstZx5jjquOaY8oxbU10zIB/ Chz3HQ8dj7aMbhl1LIle8U5W/8frHHy+w6nZnOwMcRodNc5oZxz1UG9NdFpgdV50JkOsQx/O tI/z+QX2PbSeoGdnpjPX3gu+q/h4Xd4VZ4Fzq9MhLjq3Fy05PThLzkoxE0eSNwczOGq/Yp+0 3xA9MCpYgfZbAHftN+wwMvHYZq/PX8fsc/YF+2Mcff7hvMeK34vuO3ipFjMdekeEI8oRi6tI 4W3uB92LDjOCIym9w5HqyCh6ZNX6gNa2vduRDX0WruQF37xoILch0Lp35AMIDjG9A2PHUeJw UQzJNEXRDUhgOxxV9j2OGnuho87R4Gh1dDr2K9ENGdUBsoeklek4Atm1DQFnU8odDt7xquM1 x8m80aIZiP6HWX0vTmC2dV6HebjuvOmsdtY674hbMR+CjQ9h7lPthfnHxGTIzo9hTEwsyOqX sjHOj3NWPOa04MyLBdB7svOBc965KKYVs2JtcVixSSx4odJ+sDimOL44UfQUpxSnF1uL84oL i7dlFRQXF5cWVxSnFD3M74PZMmLOhZwN2al4Z/Eu9AnaXdwsZUqMYJjV0eLdxXtoL/z8f6AT VA2rp2fm+D/lWVoj4wCi0vZAaYbSAWUnlG4oB9OupPVCOQolBcpxKAehnIByGgryzkIZhDIM pRTKCJTRtFH875b6F/U76b94foJ9EvxaBAs7iDnhdKBl/xm8Fwp+/iyLZFzYbNhDsoj+1pUz yLi8PKiHoS4Mysg5m/OYYFAGpIcBRuTPowBXZP4kwA2ZPyLzRgLaKfQtuVb4kzJcUdGjKvqu DFfk+obqmgL35OujKl2Dcq2AejxKrdgYqG81m9S2qeFJbQMBxzon97mgGrti14h8/VaAvYEQ 2P+ICgZVoNh2V253Re5T8c2kiq/M4YhqjI8D/KjUkyp5pYZrubzKt+prig1Q5+rlOkJlw2BA 34PyfCq12vZRqc6NWqX9cI7fGHNjAcwASf52+o0l0NZAPwTWgX0GzoUa1DGrjEHx390VHbmp 79PXauMPtCGwvqWaB6V/hRdYyzK5GQDZAJ0A+9/HL/+/1Ip/lfpJ8/WU2jfup9SBPlb89LTa b30F1pOr2K/oz8/xrZ1cAUCUaVElp4rl3BKVjEvST3Ev5+vcHQBVKp+pYwPnvybHbx3m1gE0 ALSq/K7EyiGAIzm+tehbk6/KtryW459rhnN8uS73HMBJid58GKAP4BhAfw7l9c2nZN4ZgAG5 b8yJC6vMoTKGQD70tTlZGpu6D+X65iFpDH458GmxFphv3y9frZaXRiWbNl9c4W++DDAOMKHy 1ZPykDLW1fanAH7uG7KfEc4DXMjx26dyLwGMAVwN0HV3BXKvAUzJ9LQ0Nz5Q9MzI9X2AhwCP 5PE/AXKXJFDibrNGrkNy/PbSzUaA6By/PL05Tq4tsh+TVWNXAHy1OU0aL45xcyZArtyuwN9f m7cCOAC2A3gAKgGqAWoB6gEaAdoAvB8gPtR7yvvl5Q8ab0qtrK0n7T1PqtW5Ub3WA2tlzp9U 33gCPK3/p+Xe1fwXuH5W2/+fVqty0ar1nzI/ar1P2DNX7X+1elLVv8rvbmWecA1cl9bB5psA dwAOyDArge+8qrRXdGMsP8hZWcOjOf7nY2X9KWdjuT3mb9wnNs+v2EBrL1paf2p9mxdzVj97 y3rzWI7/OgzIUUouytPm+J+JJqV1nBe2Mr48kyouZLm8mIA4kf2dl7jiS9+8qdcAysTnPMbv PdFbFth/nHtNrhf/Cz8L4yLwxSYpIwCjAFcAJgFuANwCuAtwT/48B7AA8Fj6/Bwvg16SeS4C IEoFsSoZM0ASQCpAhtw+GyBf5gt/BogAJSpwAeyQ7agCqJH6Iqh7H2hgBSnNKR0p3SkHU3qf aU05+kwDlpReVTmuUM8cSTmRcvqZQ/L1EwBnnylJGUwZfDYRMdYyNSx9AskTJIdtR1JOp4ym jILEFVXBdzCY3vtNX3qziIbeKfIhendINL075Bl6a0gcvS9kA33H10zf8X2e3hHyUXo7SCa9 FySL3gtipTeCZNMbQXLoXSBb/uL9cZyJk741O8yeY+xZiKVnFwLgsQyFUp0McZMMsZUcoQKI q2SIq2SzDLwMSXKduqKLZGHuk7MlIH7hCuA1y9hT4blne589GlCOv4fz/vxVCr5NkL7JzejN MdI7Y4Lpm9wh9E3ucHpnTAy9JyaO3hCzgd4NY6Z3wFjo7S9J9MaXZHrLy0fo/S4p/256OXaW Da78DWhDH3NumtowhGXT9AbPpplN9zc93HSfPj/CmmBpw1CSJilElhpKMiIfS1I08pIsUIxS 2TSFRdGYFAcaffoIL0maFD0bPKQhBGROYTvkSz1vGMInhzz6WMv38z+BtP4m/48snv9f/Azb qG3SNjEbZk8mhP44dIR9gt5YEwNgkt8Fk+Brr4H2J6H9KX6YBfMXQFcstYkDiWjCsj/WpzEO Ad/6hBjfZsSyWb5KIoaZYiZjJtfHW+osDevj1yeuT1lfDCVmfXrMrfVWgLz1heu3kY5X8Ru4 /Pf470HfP+B/AJwf8j9kPD/AD7Ag/kf8j8CyfwBrgmFMY0xPowkBy37CQkN/CvYZYcUd4Mbo 2d12thYiuZOxD7sksOxfodVgObQ6H4CzPGROi8MyZL5ruWhOt1zG+plqy0CC3jL+4WTLBNLK 59gUy3WUsWy33ESexWO5g3zzLcssyURYbloqLQ+wRlkES7VlntqArKXWsmip38gUoLbpGwsR UCeBZ6MWoNQHYJsCYBv0vzFRtnHecnhjikRvtFpyN+ZBf5eprz7SEybbNSTb9EBlz3XSXbux wnJsY3psysZ4S//GbZZTG4uV8T/jADsaN4ZZ2jaaaFxeGK9CH9gYQ/OI7wRj9AYtzlBh+Czj DS8adjKtodpQzfSGXYYvMIPhi4YvslDDVwxfYWGGPYavsnBDo6GJrfnAMcxxZ+idZGGsEc4t LAGyYcJ5GS4AXJIBslrCVYBrAFMSbNgF9YxUqyHh/godP7UC8JmzRBPtNGebs+MnYqLj4xIG 1gG1rmRdSfw8lIsbooBaXFdips8JjpjoD++Kj1t3HkpJwpBZMFclHIAr4/HjKANSizHR685D i/MxcTHRMdEJFxMOA3c2JtosxN8xu9bVxE+Yd/iAdJoPIcQPxC8imIV12WYhYcIH2StFsjH+ gWSjuQTatSb0I50wlHDKnJTggKtxkn1om2xXNvQugmYRLQLtsj2gG+2ZN+8HOy+DFeNod/yE NH6Qq0noM1eZa6A3aBs/C5qATjgGnxrM+F6VMP7rPORo/tv8t5mB/w7/HRZiKDeUQwRUGioh Aj5n+BxEQK2hjkUYXja8zCLprWdRofOh82xd6ELoAouh95o98yflOHyjWQlAHWU5C/3GpIK+ y5AnZz4LybXSNw44tlUll8F24dt5fHIcZKPvQkTzkI+of+otnnrD9+nqKdIZRbqGIl1Lka6j SDdQpIdQpIdCpDeycNKEY2A0hmAawyay56hs9xnqeyPxvGQ1x0ZUvKuy3Wq5YbKaY/UyD/97 1r/G9+j1mCeOWkuaGGniSBNPmoJIk5504JuWg99rA/USSvojnugLnt75hd6Q5iGRxtgs+6Le x+PZDnkW1XK7ZF9sk3l/ziw9bd6fZPdRNqSyW+INs5Oq2JN4dfIsqnlH5FlUeP9Wc/hBZuFf M8ur+YJj59kVOhXE4n8fj9ruA2eUCCU2qiTKFbUDcBV82kG8GsISLcJVMaoOSlVUA31GWpRL JxQxar8MokqjHopIoOhTNKn11FGNV1qp/xrpM47F8JLhJRhzvQGizLDXgBHwgfcmNkAzKP9l M7IS4BRzRp6AUkj4tK8+4SunI8/66EEogE0DpsOmeiwqyRHTAIHyWdJ0luoVDWd9miQ9jZFh EsfkAbhsqjZdjhyOHEZsuoxRbvi8oebPHaHpAcA8c5rmTAumx5F8pD4yIjIKMNaxkebIJKJT IzMA85HZkfnAM0cKkSLQJZEuKlUgGRtZAyVbLthG79NYF9lAODayFWRQm17W1CnrqTItwDXk 6Kk1gkBXdtAIqwwNf8L+wcP5/zplV2kdJuH/z+cyuGx2CT6/6sdN5tIoC3v9uPFcIuXy3X7c KC6WdcJnlx83hDPS7ywL/LiM07JS+Jyi4vJsgc7ZUT7eytievsJN/An+dZD4G/4UZLbv89+H k/UZ/gy0PMefA98M8UNMB755k+n5y+AhA/9zfgLyzyT/Ngvn3+HfYWv4G/wNZuSn+Cm2lp/m p0Hnu/y7kHOGQ4ch5/wETuUfglP5TyE28Gz/DcJfJ/yd99DfUNFHVHSfiv6WTMPYOTMH4+WU 95Q+S7wYLh4+zfnxjBz2ftOPp+ci4NOYHw89zMFMq3jsEVuCT/1+vDnwOgd7kZo3yx7QbqTm TbMZ+FTtx5N+Z1rix5ug2Mrz44357QUSb4SNqub6WbpHw3lllJM5ysmYjXfTjufnVUPte7x6 RMX/JtFVKrpS5fmvqzz/jRValvmWqu23VDol+kt+sybROBYLfasT7yOl0SSvSIP90j0o4gHA ISwYTnshPq5fvglbYixcw5zhLFwbHgZgCo8JjweMdSJ8TglPhxITbgWcF14I/G1QTMAvDi8F CSy75TqR2qlLPMiZoK02fA/oaIYaZcLkq3kAHeEVdE1qjVBBJT18J+Cd4btU54YPej8TwZXS CPfAuJkpBMCoArj/MIHfTBYAiBBTmsxHuf4AOCXXZ2R6ACATIBegQPpsPMqcId1rp9eWAJ5Z e3/tw7WPoNxfu2TShHRjMYWsXcLauG3ttMm4dsZkNEWbjCD9EIspxGQxWUjOKBWplaLRlIwa AZM+UxrqQk0rekyZoFezdjpUBDouNDVkd8hxUxzg7pDd/2Ynng+6m92hbBFG3yVmoekAVoA8 uUYoBNgm18XyNZQrlaEC/NkRmgTjOBiaEZodmh8qQBFDS0IOhnRgAVqkWgCpDChJoa7QHfQZ CtQlIIvXd0hFbrWisU6tD3XJmhQ92aFJIJmEukKaQ3pDekOrQmug7gjp/TPvT/6syF0Da9MI +dkIkWmECDVC5Bohco0QuUaIXCNErjFTlnMAwGnQ6AGAU5IR8qaxFqBevtYIAFFrLJABPmd0 MKdufE1SxFHAqWuyoeRDyV4zvUbUjWNZU7JGoDp/TdIaF8i41uxY46LPWOrW1Kypoesuqcit /DVmgxTpQ12kaUVPNnwSAfKBrtLv0Q3o7qypAjyuG/iLRy6+j3dRdQLA+x3tUv0f7yrlKTsG ynM0e5iDx5azlZwc1K3tBXpGi3M7oztI2IN83QXGaTqCb0JmfqDFXWwx6Brjgm9q4S5ZE4t8 Q1rQLON0cRoHcO5o90OMVAYzbLuMO9wMYpCA/M+JtAvMLNUjjTioGzlB3X+cQhnEmg7k8BdI chEx9AFY83niP0Cs2710AvjNy7CbB21HzKUu1+JJQXsPse404QTilBLuJYz239Tidy/ntOWI dRMk2YM7lHYa8FEt3sll6PTE300yiPsJs2C8P2V4FeTLiUPPEYIHiYNtmeYO0RHEv0nyrxEm DXJf1wmjtxep1SKOiC3iKIC+hleX8glnEqa73yWYt+VI1Lz0K9Jv0PyUejwPnvmBTgD8OuE+ Lcw0/ybhB4SnkB+0HumgEeJMEP1zwinEeU7zFmCBcJGEkc8tET2BmLtH9JuEGwnnSjKkJ4z0 bEH+8u/53wPHHAyj0xzWwHk5OFUDu7rmd0hrfkr8JsTBn9G8AfQS0lwr4qBiuvpd4jiD/wGO bSaS5Ah/mTRcIp0ewuHEaSU9f00yIYQjEetE0vYuYUn/iaATOHbC/yMIoj3oneAB9Axy+O3B 40Df1WwE/D+Rw6Vq8Bz6AuIgK9FJKK81yRr+FvBbyOf3aTYA/dkgsIf7Z00W0D+hVt9EHPxV oncRPk747xBrK0nPY8TaaeqxDvkaLfHvkeR2omOoLzPR3SS5WZNMFuJK+T3ioEnEGuLwLxPd GXQD34JOkpUkM074DGK2nnNhFBE2ENZzsBKXH/A/ov/Mko5rlsP7oJtB69FyvM/hpnn0wxLi oPWwLjk+HWn+NaJ7grZhPBD9gPCvkcO/TngCOdwG4j9CDFkFf8G0iHTQLsIpdHVCE4vjlfQg zZ8m+guEp0hynOjXCXsIP8dBtuSLyZ7nCOeStRqi8Z1iMCLNOcRE35Y4aAP0jjJbCHuIP0dt 54nza8TLc5oM8KojuA7wOVz7QV+iGdlL1u4i+ptEn0AMMnUU8yCpuYqYf51apRAnFq8GzZJM g8wZpEgeRC+RZBhxuhAHf5XobJI/QthFGkaIrsWrunUkc4TwR0jDN0nbEmWqZbItDDG7TTrf IptbpbgiP39B85+A1lGMRQa/CDIfo1Y50hgJb0O8fAdP+PxrlOejl39P2RvzvxlpbgNdfR2v 8h6i3yF6gPBBkt8t81F+njjphAXCpqUdyt0dXMU9ZZLkk0hDErW6R7iJZJYIf4KwdO/4FmF8 WwOsI3yiCDP9RcCHSc+DpfM4dpK5SXtKPdLB1AvIo2Q35me4l4Z5h5VAuxtizYeJ3ku4lSRr NN8Fyc/gLsC5+Byk+e3gpR/xnYR/RPgueeM24LsUV+E8ZCGeo9W0nfCrFHV2zW9xv9e8C5y/ Qs1BZtLvIXoWMTdPnAvE6Sa8HbEmlvhJxDlP+OeEv4Q4OJlkvk10FNHniG4mnZeI4yD5VwnX I2aLGnyqOUb4a4i5GKL7EYNVSN8mfJE4caStlyzRyxqQQ5r5dKJTCV8hPET8PsK7CXcSv5La Mrl3pMlOdpPwG4TnZBnERwkfIlyHeHkn0dWE81BPUCZppvniTlJfEzTSa+SHrZK2ZdrBIcbx PPNj9MbyORwX4QeIgY+ZZBAxnEOQc56uXiAsEL+X8DRijYNkthM2Ew4jPEvyr5PMHdI5Rq3m CccQbiOZgyRfTzKPNZCruQzNL4D+p+BaopcAm4ONGPkYP1ww0lxUcDzg0OAwpDV4jrytxWcp N4LxTHJPG0beEwE/jzsOW695ATDtd2wL0Qbc3ZZ/QzImTSfJJxFG/r8gBtpBOIpwNp1z0gl/ iE5ELxG2EL4MrYYwtoHGd3Ksoz3UExyEHsMzJLtNZ61+wrelkxjazCcFUwYIHkOMpzs+Cc+r XKU2lfA8YuJcQknuEvEvEX+eOPPEmSfOpeBqxHjW5eYRgw2STC/JjxFf0jZGenpJBnv3kEyq pJ9keonuJc29yGGLNJYxwot00l6UrEX/8FtoLFs0/4IYWwFGDanUV6+kn+w5SbhUpvFqKUrC bkI5lux5nWx7HUcEdCrlfBoL9gVnhnqij6M9kMMgftincfbpLy/3GP4SljErYbTWwP6W8F7M Y8s/hLbfp7waCdkUNCzR7kC4lziLiLlUicbzPJxmz+NVpLlUCUsndmqVSvcCvXR678VzL2DM tEnI5z0kM086K0mmEu9ZgukJWXAU6gFcS7m0AluR5Dz1conoY4QvUY/HCM+TzkqycI6uNkmY WjXR1V9SX78k+2+T5G1JJ57AuUrJTvLPosSRr+IZfoxajSEfruYTnU8jDcP1/sfTyJF6Jz2p OONsjloxega2lTBb/hngqOVJwPHEiSJO/PIf4Pw/ghxoj/g8Yp6es/F6soqeesIYkZNOdKq0 e9JVel7J9xGekHZqutomjUjaW4n+IWLwOKzlZRti6AvpWMSgDfttJPwy4TrEkK9+hjOClsO8 hBBNuz9azleTzBDhXpmWbMaMcYjwDOFJwv2Eb1OPNUTfZHSXgTsm+xpH9626Kso25EPKhEzK KvStnueRs/wAOZAZcDXF6PBbK5PkeYarBrITZSRtDHk+lmaHopoyQy/OHb8F1yyszV7M1dL9 snxXK60U9NVx8p4g+/AonleJDie8hfBd8vY9og9KJxDCHpSH88b/Y+/Lo6o4tvXrdJ3qc4QG B1ARUREnVMSDogIqoiAijkE0RolBQBRFQEQkhiigoFHUOMSoQUQc4nWOc+KsibM4RJzHOMQR xxiHCL+qr9pzvffm3nffH79311vrJStff2fX7l3Vu/bep6q7ORGtPfTZnEP0e92GJZDgLR5D b6nPbfC+BBqeA78USF6D/wW4Fzr1gcsh8QC3A7YD3oT8Hvh24GRgiUAahtYDwHRgD/TyGDp+ kIQClwAXAkvRWgyMhyQcIw/HjIeLCDF0Be8B3kPEBr9qGfnie60JvFpdj0BxvesRq39g3dUB 1jYAA/Q7zHOQ70LTD/KjwAPAhXKFCc3K+GbvALQFdgL6YJ0wHlwFYgVFagEr6KsX8S0cCs1N At92KUPNLJsEzAMOBXoCNwHFqpXp8hSgqLqk9CH4j8CxwhrWuuTtS7RyXnqW8W/ztxfFt3Pp I9WW40OBPMJXAI8gbmuCy7sBL4DjMEKpI96JiNM5xkOfgf+A+H8Avg/yu+BFwEVAUakIdn/E iPELD5Q9EPaJI3p5Ak6MkUBci5FfY+kvJj4jb2+a/MTIxXc3l+AeiBoAfATcAUwGitUdEfp8 VFg/sNeQDwemAwOBmfj+LQDu4d8CfczeHA8INN4QqPoKVIBGAhwJ+QqBpqkCDdBXIDFDx1TD jPst0L+P1t7AVQIp5Ow6OCwYiyE5BMuXwNuBM2BFSALAx0A/BViKvjSgK1qfQvND8HJAabk/ 9NFKbSF5g1ZPSG5Bchd8Jbgd9MsD04AK8BGuIh+YAMksYDys9QJi5MZYoLxqR+ARSHKBkUB3 YDgwAohrNA7DSOTYWuPqtgDRapbj34DWRPDd6NcFPBSIkdNfYM0HknECbTBH5TBf5hgg5DQP 9qfBTmPIgyEfi3OXwc4ZYA4k8D/DXCiPca4TWpfCQme0boQFyJk3eAF4X+BtoAVyREhZfxGH HHkcKuOA6YjMgeIekeFbtbyITxH57IBA4w2Bqq9ABWjEvUHjSMhXCDRNFWiAvgIJj/C5iPC5 iO25ImKlBcFNNaRlwY33pTXBld7QWSWQQp9hFU1h31gMySH0ewm8HTgDVoQkAHwM9FOApRih BnRF61NofgheDigt94c+WqktJG/Q6gnJLUjugq8Et4N+eWAaUAGieij5wARIZgHjYa0XECM3 xgLlVTsCj0CSC4wEugPDgRFAXKNxGEYix9YaV7cFiFazHP8GtCaC70a/LuChQIycosoZfSAZ J2cTs3YJWIw5IgINcjZXCLQBlsOMm2OAOJfmwcI09NUYciL1wYOhMxZ9LUO/Z4A5kGC+GOZO wX1skxNal8JaZ7RuhAXImTc47nWzvsDbQAvkiKuy/mIvXNa7jMd5WVd8q64s7cbxBnCEQOoi 0ABUCNAX8t7A/QIJ9A2QGKFDp0Eu9UehtRGwDzAD8sfgsKAMBd7EuQngC8EVoBmSAvC24H7A cZDkAL8Efgo0AqXN1UDIDdngb9FaFZKnkDwHLwaHNcUEbAM0AEdDpwewFSSdgS1hrSGwFiTN gfJ6bYCDIAkGWoCOQE+gK7AFNL8GLoC1i0BctZFB5zxat4BfQ6s9+FLgRLQ+AZfztUsgk/OC OTI2A7aDZhEsHABWhrwO5DhL+Rk4DBgI/AG4AzppOCsXkjDwuuAX0Crl88FPiJUPj6sIxJXA VUBfINZFRMqfCeRRFIF4E5K54L9Bx73shbjvinXjZsTqS6we8TaOUQVixU7x3g9bAckkrBJv Q4JdMI0AT0DrMqAzrO0HbseTrFictbR0jNhZQJKEve01WPAHeguJCXs0gxtQ7gv6QtMevcg3 TE6J8Zuwp2Ny/e8k92vYFwcJZG0EGlXgOshf4jnRRnk/tjRErNgFKtliVPS4vG+JvoYAA2S/ sHAOrXfkfhA+DBdIV+FaTkNzjdgTUbln9IYfUAF4xonWGxj5RsxCCUbYDxLIVYyf+4S3soMC jV2BeWIXrExGj0tg3xv9FkJfQ+8abKZKC+IuLv8S2o2d9W5ctcBKwO3ADGAq0KLLT8PPAmdD shw8A36LB5bgzgOeLVK88WXU72yXTsCuvxD9FmJ2xLn79ZEnYbcoLZwWuwNguEDuSdmLkBzV 9U+jmp2GTRnVSdAsBC/EFQm5GT65JjSNbeX+BRZigAuAB2U06vFfiNiIwCzLGUzCtcPniKWN mJc0zHgF8Cmw8KPcXULfT96TgQUnXHUyInAIPJ+Ms4JltMio0HOkHOc54iwV9xlYrmhVz8By lLBjfAD7F9DjVIwqV2A5xJ75qUAT7kuoW3ULYzAjHE3YNasDBGcE8uXw22FpE33ly10z7vPc E2icIOMHI9yNawkQb34zeQ8k0XCJy2tAZy6uxQk8AnP6Gld6CZJCSOagr5uQhMGHY4FDgc7A rmjdDM3leF5wBpaNsACfsGOI/AxZzTA2ZDqtg1GNwFPUycDFeK7qCl6MJ61u4G+AqWgNA5og WQ4codbgWBvPZ2tDUh+8Eix8CUmQQHIfeF3qgF+CtVj5bBdowZPfJUAHWHgO+VXgbP25s1hj FOMps6tA5gibs/WVm9DZrq/HgsRdCKxv3XQMEt7GGsNVtyOwM57dD0GPRlizYGwT0G880Cwk xq6Qb8YIPSBfDsvPpTdg2R/YCIh1mlIVrfOBrXDWZMgD2CPxjQP5TnFnScFaiGD9o/SFvAV6 bIhekiGJh/fKwDOgeQFoJ65CkU/GKa7lpJxfvFPRGHawyqVNob8dvtoP3h2tIeAu4Fiv8pkS Np+Bfya9CssNMB4nyeUTeYz8FHq8CayEK10PnXTwElgoQb8X5FsBkNyF/nrwq/K65PN9VibG qUfdFDEesVunvoLTCbDsAc2X0JkF3hd9LZZ+VsWbRAFoHYPW7pi7o2i1g4VrkkP+Cncn7oMP kDEvOB0GNEG+VyJm4TH4RfA5wNsy5lmWGL/gbAVwhoxncd+P3oGOC3y7Hb3nQ+KovwuRjqzh aMBui9sE19+yiBbRqMek0EyF37LR2gu9rIHkBBC7FSUIOALxfx+5gz0UjZBzjavIxLmZ4I/A H0mOcyl6vIuRPAd+iX0Bot2E8auhAk2IT3YQ41kt0PwdWr+CvA0QOyaaJH0COxiJCd5Qh8Db 2CMY0mUlQe/1MZIoaRkWcjH+XFkf1DT4Jw1xMgXVSfAw1YdbmAcdXyYqdrZ4MsVrTonYxwkd ckNwPu94uwAYDMTdKsUTrZcQG9fhk63CjrJQr2/iOdEzdbSwr1fCmqhgQj6XiTd8fkNfv6CG rAOOxXWNxvgPwz/2kKPeMgJsAsnX0CmET44LNDoLZK8huQKJLdAHkurAUTJK2TPOH0JyB/gE ml3FnTEehwEYTxr6DUAtDUDvHE34dmBp6P0OdLoK5DqCO8O3k4HbhT6vFWk4V2AMsIlAWoic vQM8zvBdw2R2I56B2wUa60LnCritQHUJQ7QING1BhFTFtffGGIpgfxST48SomMwy0XswWjfD 5ivwV/AnqqJRgR9WQ34YV+Ei9XG9fzCZs2l4q0GM8ATszALvC69WF2j0wWj7oPU0ziqQ32vy +0IfbQBmPw1cyDuhrz9ktZT2dU+KHseD+8HmH5i1h9BpLHo0TYedS+g3BZFzBjbHo6+d6P0K EHlnzAM2xGy2gv5RcHcZRZJD57K0A5wJTXiMZYEj2rlXHTH7QtISEuSgugZ8JGzGgNsA96H1 I5zVBz5vDvwF17UA+eICSUPgZWAn1IEAcAO4PSwjB5XBwLewsFvakZkF7oqzXoDPxVnB8rtA oCkb1lDnTfFyPLJKQ3MGJA/AUY25t0UrvhFM+FZiO2G5kDVAPDfAt1UvzFcDRG8DRHsD5N1M cZ8KPeJbUg0H7wjuhL6KMPJdwAewX4DR7pdc2gHuRl+DoemDjJsMjNfjPwCzI/J6nLBg00/w cjMFN3sDFfSLVUQ5T2QT3qljWImZFsNCT8SqM/gKvT4INOiRz9FmJPTxXp9xkB7bAlUmYywA 2SF4F8g7oZdmgquo3moUPByNaD8onjjQy+w0x2T4ZKTRn3Nb43IR4cbJXBOrTcMBwXlGTBb3 2YARAg0DMCNtxFnGkcJLPGJ9xP09o9gLJAuJoVj0YkQ9N8rvF1T7t9315ymZHMuDl9efpODZ dBmedJSNB8YDe+Le0X3wXPFUQuiXvSg7DclM8W0u7CgjBNIq4JOB2yHxBS8WaHADHoWkL1rD gK6QzAbXwEuAqcDlkB8HXwycB7QA6wODYLmclLw9L77dcHVp4NdhIRat7YSE72KE/gBgKeRX wa+JVkWOoVhwY3PwE2j1ADrB8mvIzXhC3QDcHb1EgMdD8zms+ckRwlpX6GyGBNdOLklNSOyg Pxk2r+HdXZMcs7x2IVHCgNvxXPs2LOxD63o5C+I5uGEA8EtIBus+EdZcYbmjfKqOc7vAWgmw HWyuBS8G2kk/Q98NkgzYmYBzz0oPyNlE63rsyBygnw75S8j34KqTpLelHbRSYHdIOksuZ0H3 mLBzUUSj4aRAPuOCv4K+C1o/gn44RhWCXkLApZcaQycUo70vrwjXOAdyL/RSqayuQLT66T0K eWNY3iqQzRBofCNaOa8r6gMkznIkMubF2whKfWALGf/gFrylUAPWauC9hesCaRW0NgZ3LZsh fI69LYU8H7hcekYiJBlAP9kKdAHOBq6H5hF4wF/GrRwPsAQYBbwKzUoyciCJx9jOAu/Luzew 86GMaujsB57AuRdwXaHAAcBHuMZb0NkCy9MhvwYcIjMaPBpx0hKaqdIakML/r+CT43KcwME4 qxTcDJ6Mvs5gZm+Ls8zegpuQp2o4MABz11u0mlCj1AZ4E/4B5rEmrmsMRtULUREDTVQtVdo3 Qv5YjvxtKjJL4F45ZpnpuF9EcVcqFzZzkcX5Ik54PayLuK2LalZXVB5ZYYC+qEXZsOOH+oAa RW5AEqxnn9ApJ+uYQBor6xvkpcCLwJOwGVTaiCMB94RmGka7UOYUfPgMdy99gXjCrszF9f4m rxrvlkQab/LxpBq7C45o34P9SCTuTu/B073GhOjvCNiQfMMKwgYmD4wirtGfJseT8MHJg4aR AUMGRSWTofEDUxJImrDbOyzIldTk3xxl4v/xR8oRW1KROBA78YnLzET81ZpGypNKxJHY88/i TVPRQqzMIP4aQ+cKUQkVdruGh7iK32JBu1FvY6QCqRwdPTyJZABzgLnAOcB84PKY+LjBZH1s XMJAshW4My4hLoX8CDwcNzIxnpwAnuGKA8kl4C/xidHx5A6wZPigmDjyHPg6mTcbCBD3wonR ihRM3JwSo1P/RvJXZiC4Zy3ffdHR9j00v4d276EJKO3YvIeajhVJXeJBvEkbEkS6knASQWJI PEkh6fiFgNkkjywhqngtgUySYzZUkkdVvr9mMIvfdBa/sF1XP84m4i8/DTbdCf4CxmYjxmuw KdKPl+SxQk15dFjPz+PHqsHy6DRE2nHazfvi9p1O6J9v6lch3ifCG0T4VROFj7qbeJPB5IdP /8O/R8WGiogyuCneNNjYl7gQP9KBhJIw0o9EkaEkmYwhWdxzX5K5pIAsJ+vIZrKT7CdF5Ay5 Qm6SB+Q5+YN/dWimzYSaVplWm7bguMa0Fce1pu9xXGf6gR9Xc7YNx9Wm7TiuMe3Aca1pJ47r TLuIwo+7+ac1XHsPjqtNe3FcY9qH41rTjziuM/3EtdeY9vNPa7n2ARxXmw7iuMZ0CMe1psM4 rjMd4dprTUf5p3Vc+xiOq01FOK4xHcdxrekEjutMJ7n2ur/ziPhl8jSS8W955BSufJXpZ90z p3XPFOueOaN75izvZ5XpnO6f87pfLuh+uaj75ZLukcu6R67oHrmqe+Sa7pHr8Mgvukdu6B65 qXvklu6R27pHfoVH7ugeuat75J7ukfu6Rx7oHnn4X3hkDskny8iaf+qREt0jj3SPPNY98kT3 yFPdI8/gkee6R37TI+aF7pnfdc+81D3zChHzWvfPG90/f+h+eav7pVT3SJn0CC808IjZID1i VqRHzFR4xGyUHjEz6RGzKj1iNkmPmM3SI+Zy/w2P/EiOktPkEvfIPfKUvDYoBhuzjfSI2VZ6 xKxJj5jtpEfM9tIj5vLCI+YK0iPmitIj5krSI2YH6RGzo/SIubLwiLmK9Ii5qvSI2UlGjLma 9IzZWXrGXF1EjNlF+sdcQ/dPTd0/tXS/1BNXanbV/VJb94ub7pc6ul/qSr/8tz3ywOqR+rpH Gugecdc90lD3SCPdI43hEQ/dI010j3jqHmmqe8Sie8QLHmmme6S57hFv3SMtdI+01D3SCh7x 0T3iq3vET/dIaz1i2uieaYuI8dc90073TIDumfbSM+K3NcW48Q00k38TaCRBvDzGvw1cSH1i 4f4KIt1JX+1nXukDzR8YZ2qndTZLKwYL47IzOpulneWsI/TO6WyWdh5M6F3Q2Sz8vkpd4kl8 +Hx0JX1IJK/qKWQsmaRdtPZ0ydrTZWtPV6w9XbX2dM3a03VrT7+860m7z1kncyCXPdDZLO0h WEcuK9HZvxrRDeuIblpHdMs6otvWEf1qHdEd64juWkd0zzqiR9YRPbaO6Il1RE+tI+K5b/A0 ePIFjLPizNeDdZQ6+C7mKzc7b6wCUoj4tSj1b2aLr35oJ6Iov4OFWFlnKwu1si5gDL+B58TX inVx5lOc9QxnPIf2b9B8IaJFecrPENEym1T7R1+R+Xxds4ZsJad4/rzkmaMZqhhcDY0M3gZ/ Q4hBvO9stN3Lbc0D22dlP75jyjHO5oIVWdlxKzthZSfBxKpUU04JrtzgOAdtP1u1TltZMRjl 3rMnjsoZnCFGMlURo/gKOmff06miiDHNUX4ilGvOUc5ZLZ23sgtWdtHKLlnZZSu7YmVXrewa mImvm52IK589T9KStFH42kBZwPs7hF4XKAe41gKFrxSUfP75MKT5ykEuzVeuW239ovvCpExT vuTxUqAs45rLlVXERlmjrCHllXXKd6SCskHZSCopm5Uf+IqfYmXsyKNG/IqLWPdV0H9RcRFv WKms5DY3cn2q7FB28LUijzxlNv5SXPxenohD/q0j/h/pfOXL66wyX5lPaih5Sh6pyW3sIrXw l9/t8JffAfjlO6pOVHMUsVugFN1TG2oj7kNRDfa4Br2r1qAi8g1qLbW2GKEhgqyk92gt6k4b U0/ajLakWXQCzaaT6GQ6jU6ns+lXdB7Np4V0Gf0LXUlX07X0O7qJfk930D30J3qYFtGTtJie p5fpdXqL23pAH9LH9ClzZx6sLWvH2rNAFsSCWWcWyrqzMNaH9WMDWBQbzIaxRDaSjWafsbEs g2WxCSyHTWKTWS6bxr5kM9lsNofNZfNZHstnBWwJW85WsXVsI9vCfmDb2C62jx1gR9hxdpKd ZufYRXaV3WB32AP2mD1nL9kbVqZS1aTaquXViqqDWlV1Vmvy63ZVa6tual21vuquNlI9VE/V ojZXW6g+amu1ndpeDVQj1Eh1kDrSdr3tRtvNmqKpmo1mr1XSqmjOWi2tjlZfc9caaR6al9ZC 89XaaAFaR62z1k3rqYVrfbUILVKL0cSvVnxLzVQsOWrRWnweGtAGROFebsznoQltwuuDF/Ui jLagLYhKM2kmMdHxdDwxc+9nk3J0Ip1IbOgX9AtiS6fSqUTjszGd2NFZfAbt+ax8RcrzmZlH KtAFdAGpSBfRRaQSXUqXEgc+U38hjny2VpLKfMZWkyp81taSqnzmviNOfPY2kWp8Br8nznwW d5DqfCb3EBc+mz+RGvQQPURq0mP0GKnFZ/YkceWzW0xq8xk+T9z4LF8mdfhMX+fV7Ba9RerR u/QuqU/v0/ukAZ/5h8SdPqKPSEP6hD4hjXgUuJPGPBI8iAdrw9qQJsyf+RNPFsACSFPWgXUg Fh4dQcSLR0gwacZCWAhpziMllHjzaOlOWvCICSMtedT0Ia145PQjPjx6BhBfHkFRxI/FsljS mg3lO5o2LIElkLYsmSUTf5bKUkk7NoaNIQE8usaS9jzCMkgHHmVZJJBH2gQSxKMth3TkETeJ BPOom0w68cjLJSE8+qaRzjwCvyShPApnki48EmeTrjwa55BuPCLnku48KueTHjwy80hPHp35 5AMeoQUkjEfpEtKLR+pyEs6jdRXpzSN2HenDo3Yj+ZBtZptJXxG95CMev7tIfx7D+0gEj+MD 5GMey0fIAB7Px8knPKZPkkj2M/uZDGRn2VkSxeP7IonmMX6VxPA4v0EGsV/ZrySW3Wf3yWD2 iD0iQ9gz9ozEsd/Z72Qoj/83ZBgrY2UknucBJcN5LphIAs8HW5LIc6I8SeJ5UZGM4LnhQJJ5 flQlI9VqajWSotZQa5BRPFfcSCrPlLpkDM+W+uQznjHuJJ1nTSPyuSr+om0szx5PMo5nkIVk qM3UZiRT9Va9SRbPJh8yXvVT/cgE1V/1J9lqgBpActQOagcykWdYBJnEsyySfKHGqDFkspqs JpMptt/ZfkdybTfYbiBTbTfZbiLTePYpZDrPQJV8ybPQhszgmWhPZvJsrERm8YysQmbzrHQm X2k1tZpkjuamuZGveYbWJ3N5lrqTeTxTG5H5PFs9yDeaRbOQPM1b8yYLNB/Nh+Tz7G1DFvIM DiAFWpAWRBZpIVoIKdS6al3JYp7RPckSntXhZCnP7L5kGc/uCPItz/BIspxneQz5ixbPc30F z/YHZCStTRtSC/Wmz+gUOoN+Tb+hC+li+i3dQLfQbXQXKuZReoKepufoRXqN3qC/8nr5gDWk z1hD1phOYV1ZTxbO+rIIFsli2BAWz5JYCktj6ayQLWMr2Bq2nsfS96wx28n2sv3sMCuip/nx DLvALrPr7Ba7x0rYU/aCvWalqqKqqo1qR39lXdXK1E2trsarLVk4ZwPUKHUwu267VTNqZk3T KmiOmpPmorlqdTVPrbnWSmuttdMCtU5aF62HFqb10fppA7QoLVZL4NeajJpGUNMMqGYKqhlF NTOiajHUKxWVyoRKZUalKodKZYNKZYuKpKEi2aEi2aMilUdFqoCKVBEVqRIqkgMqkiMqUmVU pCqoSFVRkZxQkaqhIjmjIlVHLXJBLaqBWlQTtagW6owr6kxt1Bk31Jk6qDN1UWfqoc7UR51p gDrjjjrTEHWmEepMY9QZD9SZJqgAnqgATVEBLKgAXqgAzVABmqMCeKMCtEAFaIUK4IMK4IsK 4IcK0BoVoA0qQFtUAH9UgHaoAAGoAO1RATqgAgSiAgShAnREBQhGBeiEChCCCtAZFSAUFaAL KkBXVIBuqADdUQF6oAL05Llfi3yAXA5DFvdCFocjc3sjc/sgcz9E5vZFtn6EbO2HbO2PbI1A tn6MbB2AbP0E2RqJbB2IbI1CbkYjN2OQm4OQm7HIzcHIzSHIzTjk5lDk5jDkZjxyczhyMwG5 mYjcTEJujkBuJr+Xm01p83+Zm0focfozPctz8ypyk8eQnpuN/u3c3MoasR1sD/uJHWLH6M/8 WMzO67l5lz1kT9hv7BV7qxpUppaz5mZtnpvDkJu1kZuxPDe3/GluNtNaan6av9ZBC9ZCte7/ l5v/l5v/i3PTYBD/R2oXMoAU8G/RjWQnOYjd7W3yGPdJsG8mjfg+iu/f6G88lrPo7xwn0Fcc J9E3HKepk4jC2qppHNupYzi2V9M5Bv6JhRew8BIWXsPCH7DwBSx8CgufwcLnsMD3f+pYoQE2 zsoyrCzTyrKsbLyVTbCybDDsqLVngmvP30l4tblGCHvLSonC6wLfJ/LaoBKV1wcbYuZ5HYu/ ew3FHaT6xBtWKtge5dnMz6T33jEeF2K3f4x/esZ3b5ehZ0/H8dznbfJI72GHKHYUBHsDAz/z qtgT4hmFGTveX/ludJW4B6IUyJ0jKbYtb2v/D08uxJjEsyk34sG9G6DfLziCvexR677/pvj1 Q7BbVnb7HVNHC+1/uTfGExs8kdPwpIm7SnlMqxsHG4cY4/QndwapRUhV8XcWjpCSqgMsWVX7 qeUa5YTk/G5nMCkFWVW7cFEnxWDwsrWUU1lje6o4M2IZqNo0Vg1GQ1YrxWAs6GX5wOLxnsSl sGaGC2mDf3uQKDKSJJJ4Moik8P/8xb+W2u8ZMzp6Zqu5l1YW/TjHMub+mhptXTwrfzGtIKuS lyXLGGnJol0LqGJQFBvPlRUv9SyLWHBk97uza/ChJHk1tjRUaW+jrYNbYGLSp8lxg4ekuLpH N3T18vVt5dotLjo5cWRibIprYGJykqdXTYuLVK78ty2JyQNT4hITvGpbaol26uD01/awxMQU 1/ajUoYkJselfGqpWdXO0sri04z/09zL0qxfVTuvZvxjCy7k//SzfApfcSOqg9K7l5eDpaL4 YHaw+XDgyCFxCYNTeDcVLPZCaHIwhQ2KGZ6YEPNuYDb/bGB1LLXlwJzfb48Z5NorbnACt+ra M7C9JcvgZrGzTqDBwAjNMpQnXG6jZBkMZMunn5/5eENH3+Xeq7wuvKrXovPo3W9q5R/oOOLR yeA7p3P3DesaFvV8nrKv27nO8U3r+g/aVVRni23IlnGjLnfcsWK6fc+f6jV+WvCrXZ1aJ9vX fR0173i1jktnhdaad2xDU7d9oU3SE89Xrtk617eC7+UdDZ/Htm5iaFZW2iBk2aZ4w8S8Nz+s jx6X9SqiIHNC9rR1T7fOXnzcZ1nP7KoNJna/bHlB2j7f/6pt5s6ch/G+33p6v9joudbm86gZ abF5c0fa5ax9+uMz1+97VJoafcTjfLOO1Uq2hc5p3bOXU1HsB5+uWD3xYB//hVk9JyWw71rs +azujrDYtvO6H208tnnChE7qyfwToTlKQg5Zsnvi1V6K+FXgxZmvLZm/Wxy4O2vUM2oWG9XM Q5cxE6WWzEIhNRgz51syv86o0P9E0qO45Pw6H4x1XN9tWtmRRcn/8/GWVZ7sIVPatJlU8aT/ i+gHVwMs5cUYHQyGMiOzUH6w1BACe2MVo+PRGkWpJKn/2icXfuw+/4Mgz8VB0Y8ttqK5vNHI 0yjnvdShIiI+W7lmbGj9p0Xbu6cU9m2Q0mjUhpy3K7vOTiPd7h6+73Qp7if7wvRnSuD+wxOP vux1dO/CHX0SH0cH/SWIlMw5OL/YZavtwmp2s89eqLm64eePHi4buWr6Fd9pbecO3e4z/NSk tXXeXr17Jq7cjEk7Sq+Tbd7Pfk9/VaGSJ7vfcM6sDsPcR2zxmX7NZHfo4yHHdmS0Hxa7fNuW bdO8Dz+lFdLH/HbqWoern5Vev76q9MXVYrsNSWdm3uix2acwvcnpthe9baNaKQszh9b54kVE 9PR1/bb5no3M7T3BuflvrecWZGmFn0zZ4LFl0dIjKy+4bt5lqZbt6mjXaHvY8/bXBlhuzHSP m7gn6Zdn364syuiQnGrPa8wYXmOi9Boz0LD+G9TCyu/nEeN15j+Y1bzgePFC04yXmRbNvfSC 08L60ZI5/v/L2OwQODx0jd169Ax7p07/ifp/WXuWjkhxOnIxr+nrJ9HVMhZPKzuYNF5b1KnR 69f91hV1K7+j9YXax1jx5+ntNs1Lred3qaCH663knwNH3C6Ld3y1cML6ehN3OG76eGerLzx/ WpkdOSI7s8H3zemr1WdmKSWbe1dUjozPfrEnO3pgtQLHvAUL84KjW52r2ObDAyGuvar8frRv 6Yvdzoc3B8fb3fFjRctcbkx6fHnF3qTx/U8+fdpu6/klCxaThBWZx0r8jKt3h870cLh2t31q uQxD/GDXjV7r/IedCjCPL06yTLX8ujP3RNOS0zntnPst3T0k+84X6TNoaMJHga4heZNKD3Xc cqer0WAbVVT4wGVWvbcnvrPf/3JzXefP3qSfieh+cvBdvfa8tGT+9ue1569ZfD759BEt6pPL i1MWfmI/t/3y/g6B9TF9NcqLrOeJbMpA3ahRx+hkqZLx52kfJBRqGdtaWlt8C1oVtMhpPiQl JcmvadPo5HjP4e/m0DM6cXjTpGFxQto0KTkxZlR0ysimgb144HlykSXk3QgNBmMbi5/F591n i5LjoRscPXr0nxkclPyepZS/SyhUn8jIBufSLZ0rdWrfqs2AURtvFpKWFUPWefT9Zm76w8WV Fs0tcdrw9Yvh085ZnF1W145uHzzr7Fpn9y5ft/w8IDzyaNT2u3/EffvJuJ8mLsvR0v/yy0ef X5xUPDqNLat7OOZl9w+2BLlPc/YIN7sn/1TLqa3HcdIg0eHk0oFPz0T57SDdWdN5gz+/FR3Y rrW2c4ppzPW0gF1X04omuhZWW7Q98vHCVWERqY5vq6exs9GjhmW+nRi8evVHYbs+27W22pKZ 65/aeoy1VLjo1WXnhH7jfv+mUtrdK2MjV9rt96r5Inm+/+DjPiU+Rb7VR15sfd776vhTeceu T7niXBpj/mTtC8+tzeqlxtV7Vjy1RZ19F+sF8eqzgFefbFl9Kgy1nddjN6m3suLFjrX6jhlc +Pc16D+z1mlp8fVqafGyeHu3EqXHl3/8D6x1wuOGDxqZMnB40r+71rnUKuHN2oMdQkc4HSwK 8e+1+/VKxx88mm2r1CPs4PiH/s3Pd/aa6b55Rsy1Wj0n/LC3y8lx7OWjUTunHFhevCYuKTat QeydzVseZX9/rGTF20pLbD9ya9j0eMD5PsbqqZuGxwwPDb94+cmVXQvHH8i4Oq6r0mr2b7vz zX1qDul07Pzu1Iimn2+uZ9zYp/9Ql+iyjPQ2JcXGet18R6eYPt4bcS6nlceoQ/b3avqWS08t XRCfMObaA//pX+ePsP+kUQ+nqMhm+afGd2/sFjGk45QrTSdU6Ln+1SbnqfEl9b5xeHmkwtls ++dZqSNb7v9qTOHRSPUBW5fTfMvL2f0ntJ/QN3t2wrpaHiFHE/MCrw29M67+tGGy3mQZ3LlH 6v5ZxTH/71jtVFDL6TuLygaxhCHvFcrEO93bff2998ouOdO3591b1bp94P4TlmrWExwVo1bT hvQio/guJJC0/9uV0D8so/6kQM3uVtFrb3rPbRWnLRpoMtjnJnWc+mhk+I525ViTsq0f9Mp2 eeg7Y8viPrZXcje3rn7yzapvD2357oPa1RPNcWOH0UK34IfxG4enu20N/nnCs6nld5omt9xz f+zdpI87Lpx56mjR5Wm7r+9qdCz9waE1zYonfn8k+seWJ51q70q90nr+huoj82tPOrdxY6Xw 3Od5eweFznevnxc5uXzrAw6D0kK2HV893q/Huqi+Vyx37/rWuPHF0wu+ma8caufGZESrxjlP 5yuBTT8LnvRDmXJ+0KvQKxdoyqwNLEE7uuCS+8D0kCdV8yrW9lFcJv6/rWE7Os1ox1OHY8G2 e1d23nuRZt77RWnanDMbykMCra4VuWxS/gYsoFYBC6hJsOYR6yIDcPOIY+CaRxgFAaiMsjAw NzIFFk2GhqagMsoYwjUEcQ0aN9OjeaRuoArhyuU5ZxZkpBYpuAS7KrgG+1lZmLoY6xobmDrr mjo5uxmqGihD/CSD6ifdYJCnFIJTi8oyk1MJFm8fWHQ3TTsg1ZiuulEtabOw9zmDXQeELP40 ppqwHzHbpJLxjZ3lAPv0L9s/Vssl6bjd9F4SaLL9cs7bKOstzQvdbQU59EyzXZ8dsulhSmNa KZH52uutus47m/LoJVcKZnqHtwhcWK/7o1P22SvNLc/Pz2NLWl4Ucsj62Hn7HQ83RAjkPF16 /fChUvO9X1ofNr7QuCH98dO6j02Lr11nXjRftOW37a/VD7cZnVjAlPL52X8ptUKO4C5Rpk/N 6mWeTYXL3681qjh2PUfMXyl1epKvm/5/5fWtb5YV7GU+feuGEetR7QkO2+Zd1WnL2X5a2Ki2 91jdOnF9oz9pu2U3uIb+WPtLN705XXNyy6WohcrIzSlEgfBi+rfv73s+Pst8HJnh931GV9Xd 2XooLSWsJQYlLaWS4oLkRKq0lGAmlWAvrFHaf2wHsJVWvPbl8RNt9i01XXKblbVFPuzT+5nL jnP06m8+a194ta2mXP7ua/FNe2se/5z5icvVY63I7kydT3bpSSGf3tWrC06yfHPuZrtfx/cE d+VqdVEHjvn7eQ1Zmm6YbuOZw3C5e1VF4tGtHY5z7czuRCxRn211ay9brMiyTfw+B/tsuj8l zfyR9vbqZxmNDUa3Txly7vmtlOHm8+tysdJzzT4lht9h+9nWNS4Q3WXyU6NP3iuJdWHn10b3 l7wTOa5HWPfLZXNmrjzgURPaZB/PYOE8h+2M/Q39/f7FnLZ/d8V9Of7G/FBK4gLfK7YFZ6I3 CDcevLLYUGpvyrVpl6rstaLdgjltzjL/tI9kONMZnGjYxDIbWGJNZ2JkNGhsH8AuG0pHEjHU taDxGKh2gkYbJ7MhD/I4GtBeBI/bkM8AWVYUWGrANbIYApP6icvbnR+abus6f+zDjq4PRxY+ qN/oZZCGpIXHMMIgbIFOgxaDL0MmQzJDEUM+eCgujaGEQQFYHeYDRQrAZCJQJBPIyluo1qCC M6WWVBbkpxclFmRUKqCVTCxNjAy9vim/+h3PtwpUlz07zTttgefv545T9xtwv/oU4zrzVbR7 d17lh4sTRK807eAzm2aZfrCd95eLw/KcOWsLZFIjJ969tLHm+ZydJmsYfx1c6/PRUujfgp23 bkhMClLU0opPzE/NeJucOf1j+F7Gr5dvKr/Y03T1yA/t//8ygm/12X47Zrqt89qc5asPfVAU qb3HtffIusMvatd4FiyYvOylofQu0SXHw2a0XfG61juloTdHgSf1Jtf+GmmuylrnoFnKEZfz pTMX3GcuCLRm/HloudbPKT631/Ep9SX9Dut6JVJpdOC30oTaH5M44kXmXWZVWRWj4Xdi3do0 Dv2LqVNXp+3sPr7x8q2M6q8burpDFzYxyRs0MUkjYonNsImJByjEQffkiF5FolTc7NDkuCDW QAI5LXIjBn4ZgXbCZVgN+cHjD8ZGhobmRmYGxlEYSVE0a+JJ3aUTal5/KK04LLYv98zp5z/R yidQEjkjmH1CWH1foaNZhFzc+hPpl+fw72F1Z058/mNBwF5G3z96hrzcjKYzH14qfR3xImLz nKaQ1WVRFpMC97y/eq5g8e3Z5YW3Hj6t2Px7ZsnCHrn4TRNvvVzKts+12HGPaZmTiY20oOXL 8OcfVPfYMc7mY5qkrGx29KLy+6V+R0L7n9XYeH5e0PX14gJR5rOzPvU4aOneDL3efWBCKUfu maMblJc8KhP/+PQ8+7IS3ZyaaIaLU48fCnv7dGm6bvvyS0LBOn1/bCPKk4NtZbZritb9Fi67 xvp0zYd4q2sPzScoXDzBdLntwVaj5uQTL//d13AQbf7C9zh2d8xCjzMnr622MLQusAhzNlpz cYnOL2sGBgDj8YDpDQplbmRzdHJlYW0NCmVuZG9iag0KODAwIDAgb2JqDQpbIDEzNVsgMzUw XSAgMTc3WyA1NTZdIF0gDQplbmRvYmoNCjgwMSAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAg MCAzMTIgMzEyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA4NzQgMCA2NzYgMCAwIDU2MyA0NzMgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA0OTQgNTM3IDQxOCAwIDUwMyAwIDAgMCAyNDYgMCA0ODAg MCAwIDUzNyA1MzggNTM3IDAgMzU1IDM5OSAzNDddIA0KZW5kb2JqDQo4MDIgMCBvYmoNCjw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODA0MzUvTGVuZ3RoMSAxNzIwOTI+Pg0Kc3Ry ZWFtDQp4nOycCWBTVdb4z30vS5ulSdomXdI2SdOme7q3lK2hdC+lhTbSAoWWAhYRqUDZFEQd 0angvow6Ci7jMqikAbEII4ziMuM6isuAOqi4oHTEfQZs8537TlIKLuP4Ocv//+XenPd799zl 3XvueffdlwaAAYARDzJoLG+qqfrI9en9IFzyNEDssoqy8uaH7DUagF9hWtlUUTZpYuL5d78O cH00gOipKq+o/ODxLwCEC1En/rWqsaHpcCu7AWBzHLCb36pqcpeJ8rQTIIz+BqDyQENTdt43 qke2AzAsD+2dizq6c64avxkgpR/rV3cuX2bNrimsAajxAChC5nefuej2j8ruB8jA4qERZ3Ys 7YZosOP1Q1ChP/PsVfN9g4142oD1o3/bNa9j7tE9+e9h+zNRWdSFCu1GxV5MX4fppK5Fy1a6 dSEXYodHASSvXThvyTlpb6Y9ALAe+wSvn724s+OJVx47C6BrLkDC5EUdK7vNPlMc1sf2wXpO x6J5b1U2Xgxw6QYA7czuxUuX+cywHuC6D3l+95J53U8dW+YEKIhEo/4auG3l/VNfMTz4xGzd 2C8hhncbYNfH5z/L+cyB7StOHBjcGHpU+QSWDQUBKGA9BQwB26fafOLA8fWhR6WWRgTxJq7R OaAB5JJCAD1kQzuAphOvKxWR1Qq7MTdEfpM8H5tMIIovwiMChICgUwqiTCYKskMg+Fxwv4+u C1DfZLWCFU82Ux+UtwkOK7BNUqN75WF8pNh62MnesBfg/3xQDMHG78uTL4DGn9qu7MJT2xWf htKf2lYwBMPPHcTPoeqfrSOrg7ViK1T/yLJ1p6SVUPvPXu//l8C+hoU/ta74Gqz9MeX43Hxv Xv2Pm7Pvakt4/dR2xVyo+TFtCE9C1D9zzWAIhmAIhmAIhv+GINwC7/+n+/BzBmEtLETp+Fde Q7wIVv0r2w+GYAiGYAiGYAiGYAiGYAiGYAiGYAiGYAiGYAiGYAiGYPgvDqJf4vy/DtuNKTwT 7gUZbJb0etRo8EwLiZAG9dAATTAPFsBC6IZlsNnnk+ppwQqpUu5U6JByz4ElUi7zfYmXOMP3 te8bqeQXTLqSr9N/xWh/T0z+szjpd2NYRawVb4TpMIsJTMf0LJYlsOVsDfsl28CuYjeDgh2V yn16+u/aMC34fwUnwA8HNuJKJ02yVrzgx5rvH4RyFPrlCY7jB7oxPEJ/ug3lbOlMGjGSxvz/ ThB/1tb+y33RVTl7VtvMGdNbW9zNTVOnNDZMrp9UV1tTXVVZUT6xbIKrdPy4sWNGl4wqLirM dmZlpjqSk+yJluhIg16nVatCQ5QKuUwUGGRW2CvbrR5Hu0fmsFdXZ/G0vQMVHSMU7R4rqipP LeOxtkvFrKeWdGHJ+aeVdFFJ13BJpreOhbFZmdYKu9XzXLnd2s+mT2nB843l9larZ0A6r5fO ZQ4pocWEzYY1rBXRXeVWD2u3Vngql3f1VrSXY3t9atVE+8R5qqxM6FOp8VSNZ55Ue3cfSx3P pBMhtWJ0nwAhWn5Zj5hc0THX0zilpaLcbLO1SjqYKLXlUUz0KKW2rAt4n+Fya1/m3t4N/XqY 056hmWuf2zGzxSN2YKVesaK391KPIcOTZi/3pK0+HI1DnufJtJdXeDLs2Fjd1OELMI88WW+3 9n4J2Hn7wNFTNR1+jSJZ/yXwUz7EYTNhfuAcsG/YQxyfzcb7cnm/C+ZgwrNuSgulrTDH7AVX dkarR2jnOXsDOUY3z1kXyBmu3m638amqaPd/lndFe9bNsWZlovWlTzJ+MN/qER3tczq7ODvm 9drLy8luzS0eVzmeuDr8Y63oy8nG8h3tOIgF3AxTWjzZ9m5PpL2MCqDCyudgQVOLVMVfzRM5 0QPtnf5anuyKct4va0Vvezl1kLdln9KyE/J9h/oKrOZt+VAArbwfHtNEnBRHRW/L3PkeS7t5 LvrnfGuL2eZxtaL5Wu0t81r5LNn1nrRDeDmbdEWpFo7ttNKBwnzkyuQQa4tgFlv5bKHCWokH e9lYzNDjdElJPqNlY60tzAyBYngVfwl+dko7mBCTJ1bzLJFXnVhttrXaKPxAl8z+PsmTPSEj 2tKjYrhPdJ3v7RqV5h1Ks1bMKx/RwVMalfs76G/tu/spcFv4L4w1Qvh0VgeyxGS8c1EnYDOS is9itNUDjdYW+zx7qx19yNXYwsfGbS3Nb12TvW7K9BZptv1e0nxKivJHUcoDNswOJISJ6IOV GebAtErpKik9nKw+LbsmkG3tDbHXNfXyxu3+BsGKdxAOWuGo6bh8VHgB3pqVuLrZKzvsVr21 srej37duTm+fy9XbXdHeNZq3Ya+Z22tvahlrlvo6tWWNeTW/VDjUsbrmsqxMXHvK+uzssil9 LnZZ0/SWnXoA62XNLV6BCRPby1r7kjCvZSeu/i5JK3AtV/KElSd4S1MxESKVN+90AayTcmWS Qkp39jOQdCEBHYPOfoF0+oBOQJ2MdC5JxwNOUnQXmhiX2wrrXD4957d29ba38psLTDiV+GEe Zh8PHsE+vo8JCo1HZZ9X5lHby7i+lOtLSa/geiU6BjMxNA5fk3rb7bhOoUO1gJmRK4q8SWu/ z9fcYnvOPNBqQ1ebiTK9xROagWu/PLkWy1VxaUd1lWddZwfvB7hbeF1lck1nK7ptoEEsUuMJ xRZC/S1giUqpDndHrNSJc4MTKNVfhwnPulZPawa/aMuCVsmd9R6oto/Gaac25Q5+oezW3nB7 nnRv4q2gSr6UIxT7Bk0tpDFjEi/WSkZSarDnnXbM6my3orVl0NmErk5rqcpMmnm4JMoc8yRR mf2ZwIclJqu1Kk+oExvEDz9XO/ktKU9WtrZS56XUpf4CeG29R409cowwpb8CWgezanhf8HMp dpUX/T1vZko/TLWvxJWFd1pqSYnZHm1yTQcu/lRfjRr7qEDlEL5GqP1t7COtko9cg3YXk5v7 fffYV9lGhKxMO384cMcE8050bGjtPV3hmZGRlRlyulYrqXt7Q7TfXYHsFaIdJiqhL1TsF/7u TYi39At/8yZkIL72JmQiviJ8SfiC8j6n1GeETwnHCJ8Q/kolBwhHSfkx4SPCEcKHhA8I7xPe Ixz2JoQi3qXUO4S3vfHhiEPe+BjEX7zx2Yi3CG8S3iAcpCIHKPVnwuuE1wivEl4h7Ce8THiJ 8CfCi4QXCM9TJ54jPEt4hvBHuuwfqOTThKcITxKeIOwjPE54jPB7wl7CHmrzUcLvSLmbsIvw CGEnoZ/wMGEH4SHCdsI2gpfQ543LQ3gIW71x+YgHCQ8Q7idsIfzWG5eLuI9wL9W7h3A34TeE uwh3Eu6g6rcTNhM2EW4j3Er4NTV9C+Fmqn4T4VeEGwk3EK6netcRriVcQ7iacBXhSsIV1PRG qr6BcDmhl/BLwmVU4VLCesIlhF8QLiZc5DUXIC4krCNcQFhLWEM4n3AeYTVhFWElYQVhOaGH sIywlLCEcC6hm7DYG1uIOIewiHA2YSHhLMICQhfhTMJ8wjzCXEInYQ6hg9BOmE2YRWgjzCTM IEwntHpjihEthGmEMwhuQjOhiTCVMIXQSGggTCbUEyYR6gi1hBpCNaGKUEmoIJQTJhLKCBMI LkIpYTxhHGEsYQxhNKHEG12CGEUoJhQRCgkFhHxCHiGXkCNBZN5oJ6aySekkZBEyCRmEdEIa IZWQQnAQkr1RYxBJBLs3ijt0ojdqNMJGSivBQkggxBPiCGZCLCGGEE2IIpgIRrpCJF0hgpTh BANBT9ARwghagoagJqgIodRmCEFJSgVBTpARRIJAYASQwHyEIcIg4RvCCcJxwt8JfyN8LV2W fSWNiH1Jyi8InxM+I3xKOEb4hPBXwgDhKOFjwkeEI4QPCR/Q9d73muyI9wiHvSZ0MPYu4R2v aRTibcIhr2ki4i9eUzniLcKbhDe8pgrEQa+pEnGA8GfC69T0a4RXqbFXqLH9hJcJL1Fjf6J6 LxJeIDxPeI7wLOEZqvdHavoPhKep808RnqTrPeE1lSH2UYXH6UKPUa9/T43tJewhPEr4HWE3 YRfhEWp6JzXdT00/TE3vIDxE2E4X2kbwEvrosh7CVsKD1PQDhPsJWwi/JdznNeK6y+71Gicg 7iHc7TXWI37jNU5G3OU1NiDu9BqnIu7wGl2I26nIZiqyiYrcRkVupbxfU8lbKHUzlbyJ8Cuq cCPhBq+xEXE9Vb+OcC3hGurS1VTyKip5JeEKr3EKYiOV3EC4nNDrjWxB/NIb2Yq4zBs5E3Gp N7INsd4bWYu4xBs5A/ELyruYSl5ERS50bUUe01VYPgmrthzSTLY8hvJ7lL0oe9RnWLwofSge lK0oD6I8gHI/yhaU36Lch3Ivyj0od6P8BuUulDtR7kC5HWUzyiaU21RdlptRbkL5FcqNKDeg XI9yHcq1KNegXI1yVWiX5UqUK1A2omxAmRAqfCMchzPAIpxAdoGFXeCN4LfjWm84d61lhKVe A3etJYRzCd2ExYRzCIsIZxMWEs4ijCWM8eo5RhNKCKMIxYQiQiGhgJBPyPPquJ/mEnII4QQD QU/QEcIIWi9OSj/TENQEFSGUEEJQerV8qhWuGci/ogygHEX5GOUjlCM4nX9BeQvlTZQ3UA6i HED5M07L6yivoTyK8juU3Si7UB5BuRWn4tco/WwdWXq118BdfhUZZyVhBWE5oYcwkVBGdphA cBFKCeMJ42jIRkIkIYJjpyiKgtdluetRUYDtKPtQRBGoL+cRmmjWp1LPphAaCQ2EyYR6wiRC HaGWUEOoJlQRKgkVhHJCIsFGnbcSLIQEQjwhjmAmxBJiCNE0zCiCyXULchDlG5QTKMdR/o4T /DeUr1G+QvkS5QuUz3FWP0P5FOUDlPdR3kM5jPIuyjsob+PsPofyLMozKH9E+QPK0yhPoTyJ 8gTKPpTHUfpRHsYZ34HyEMp2lG0ot/DZFwbJxmsI5xMWeA24FWJdhDPJLPMJ8whzCZ2EOYQO QjthNmEWoY0wkzCDMJ3QSmghTCOcQXATmgnZBCeZOouQScggpBPSCKmEFIKDkExzk0SwE+QE GUEkCARGdyS47kD6UIZQPkTDvoryCsp+lJdRXkL5E8qLKC+gPI+G3olyiZhs+YXotFzMnJaL qte5L9yyzn1B9Rr32i1r3Oo1Y9bUrRHVa8yI89ZsWXNwjeL86tXu87asdstWR64WVKuqV7hX blnhVq9gmuXVPe7mnsM9X/SIkT3NPXN7lvVc17MfFcq7erb37OsR+317XeE9o8ZUruu5qkeI xHwBepiOq2096rDKZdVL3Eu3LHHLlhQsEcZ8sYQdWsKEnCWscUn7EgFLbVuSlFrJSxcuMcVW 6pfkLHEtEc+tXuzu3rLY3bB48eILFm9avGex/ILFVy4WtuKZ4Focqq08p3qR+y+LGOwWfKBH 2Sv4vKJq8S5hCBh8Igy5fGwhGuAsNMQC55nuri1nuuc757rnbZnr7nTOcXc4292znW3uWVva 3DOd090ztkx3tzpb3NOw/BnOZrd7S7O7yTnFPXXLFHeDc7J7MurrnXXuSVvq3LXOanfNlmp3 YzWrcla6K8QiCz5BIAE/3QnrEo4lyNTt8d3xQnf8ofhj8WJ33LE44QIz08VeEHtlrKjDg0CH GEvMlTGbYrbGyHXSiajpDl8XLnQb1hmEHIPL8KLhkEEGhs0GQXelbpNuq05s0M3WfaLz6WRb dWxr2J6wF8LEhrDZYYvDRF0YT4t6V5gzt1KntWhdVdlacWy2tlTboBWv1DKX1plX6dImpVSW aho0szXiJg1zaRxplZ+ofCrBpcKMT0J9oYIvlIHIrIwB0yPEED5HzGipRH/cZmJyhluLvuam jIy6fqVvap0npHGGh13mSW7iR9eU6R7FZR5wT5/R0sfYFa19TJjY7InkXxxL6Us2boSy+DpP fFOLZ3N8a51nHZ64+IkPTyC+zwRlrRmzlvYsXbosY2kGHlBmLUXNsh78SGB4RPYs4znLlgIW yfiewEss5eiRCi3tmd2DbWAGqpdKap6aJRX5vjb+reF7R/LvCOw/efH/2yF69iwA5W0AQ9eO +Av7hRh/DVvgIXgEfg9/hJfhc6aCdrgE9sC78BF8BifwNlUyI4tjaT/b3/Vh6GL5ItCKe0HB /4cG33HfkaH7fEcA5GEjNNdiKkrmOKnxhfsGTtcNXTvUP/S8Qg16qa5eeAa1x9iA77hQytO+ Ip4WLuXnUo1jytuGtg5tOqU73bAEemAlrILVcB6sgbVwAVwM6+FSuAx+iba4AM8vhw2wEa6A K+EquBqugWvhOrgeboAb4VdwE9wMt6Adb4XbYJM/j6dvw3iDlMtz7oC74T64H3kn3AW/gXvg Xkz/Fq1/PzyIOtJQ+gHUbIbbUXs3ankprtuK0QN94IVtsB3njNKBVD/shR3wMHInzuYu2A2/ g0dxHvfizD4m6bgmkP7+knR8HPbBE/AkPAVPwx/QM56BZ+E5eB5e+Ek5TwxreOpF+BO8hL62 H16BV+E1+DMchLfgL3AI3kGvO/qt/NexxAEs86a/1NtY6j04giUHsCSVozJvSLkfSi3sx7qH 4DALgS+ZACfAh2d89m6QZugmaR757PHZuUuyM5+PrZjmM3TP8Nw8gDZ+AOeTp/j5zf7ZeBDL 9qEFA/b7bqs9758dsvduLMNtwXOe89viKf9M8HYeHa77jJTnleo9NtzqSYvSCF8ZYZ03Rtjw PXhfsgxZj3JPWo+XOIxluJV5G6fa9h2sS9bndbl+ZB2edwDTR3B1OIqW5vxYmomP4YPh8w/8 +QPwV/gEvpSOx+BTXE8+hy8w/RVqjmHq29rTNV9j/Bv8HY7jDH4DgyNSg6flDMIQzjEwxgQm wtDJs5NaSWS4xVDgmhbCQpmKaZiWhUm/7lGelqMezjF8K0fzHXmhkiacRbBIXC+jWDSLZWZc N+NZArMwG0sckRcznGPFHDtLYsn+PJNUM2a4rgVLRI0om8Zy2Ao8ZjAny8bzXFbAClkxK0FN FqbzMD0a83IklkEjzIGz4bj8Q+FZbD8SV5U+/v++DS0VD+KKKYISSqAeJkPzbtCyW3FZHc2e 2V5eHpKlfBSTAljZMxCC5rvVFSETtGZzqb1QsUGcYqgpVW4QmqF08K03n8TDc+El2c+x7DcH Xh3QDz5pKMke2D+Qm8MMNoMkkWGCUqlQ2BOdQmGKoyg/P2+8UFjgsCeGCZKuoKh4vJiflyCI kQHNeIGnmXjwmwaxYjBJWGUb05QrZxnJUZaIkBDRkqBNzrfq6urtRamxclmIQpSHKFOKyuzu FbWJz6uiU+LiU6JVyPg45OBj8rDjn8nDTkyTlZ/YLXxY0jI+SbFKqxbkoSG3piYYk3LjxtVp dVp5mDkqNk4ZYghTpVd3DN4UmxylUkUlx8Yl87aSB8fg3n+j77jiXLTdWPgz33y6W1xqbU5O VHa2yhkdHdsvzN2elKvRqPDkYUgqmhKjUUfvYlngAqfv2Ha9XZiU2+875rLysyg9P2rpGJWd k+tUWFKnWNzhbrkboksxhEeV8Kd3bP1AXl5eKcveP5BnyNfzg6FkXHZ+viE/N8f80M97ldyc 1uTANBjsLEzkZynMbhhWFvAZTBCiWD7DaeOnRsW56vic5KScOI0w9EtZuCUnMTHHEi4O3SCo E7JRH68uyrrfWZZj1bBoGUvUWtJGJfeZU2K0SSq9SqHAgyz+xGGtQSXK1Xq1LO7Eu8P6C/OL dPaS9G8GRZY+OkkXhrX4bzwbfUfkMfJkiIAUOJdmYg9ECo/hAz0BjyqI8X24Xa1jk2LwLd0V qmuyR/OUnb+6u+Rn4MhxvBmlAxmMnNW880fXQAux0xxVXuAUuDsbIxME7t3ymMbbjtx049s3 1CFvvvbtG+uHjlrr17V3XNRos05a18Ep3HD7UF9bwx3Ht9x6wjNr8h1f75h/z4oJNavvnHHW fStLq8//DY4SvU1Wj95WBOVwK41yu95pSFPtEp7EkRYLt3jTSg3SXyqd+n5///X9LHmbyxU1 LqAY18/SdrhsU6ICU84HgrfsQEYJjj5vPxrAEF5Sgkbo+2mtjPCZFNEp2k91FlueKSpBNPJV IEGMijKZWIEjxeHAUtxUsvqQhNF56XnxGtkyY2quK32qNiEvxZGfoMmysYb8MvPkNdOcNtes sfH5WakRi3SqoQdGl0XmZy1fP6p5VFyiWqeSydQGDbPlTsqPHYoY9psbM1Nkorpo2or6CQub x0eEpZbUOH0OuzjX1RIuVwxdbc4t578FLvUdETegH9XALrLvTpgg3PhQUl5SnsbM/4IMGie/ tYpBxbJ2GIoxmsYGTDK2n2W5NBPM8rQmk+QsJv61zwhnQasOZBhKSrKz9QP6AX4Dh/ME97fd 4PyZmj3pj7KAP9IK61T40wqjfz78PqoQN0y66MHOiUtbxsSqZaE6VVh+4+KanEmFcTn1c7rm 1OdU9Gxqdc5sHB+plAuiUqtW51TOLM5wZRizG+Z2zZ2cw34x/+YzC0yWxNhcpyU9Vm1LtUWl j3dkluZm5IxzL5vStrHNGRadEBkWZY+NT43VxNnMxuSC+AzKX4qeXYV2Xy6+BvngYmlkeW9o VEG/MGM7pKTA6H6hwqU3iFHs8ygW1a8pYN8UsAL+PU6oRssmFRQ4J6T3s2iX+VAiE9ckbkwU XImNie2Joi7RkihoZImJsvh+3yFXmAbNFx+tZ/Xxx5213JddoZgYd9ilqZdBdHbgnuaOPHtW W1vb7DZ+L2RntJ070HYu3h37StDGefzecOn+w72R7jL+GHU4Cgv9j1M+v/mF/tXHr5FJS7KS 5tqUn1dULC6PzEjPSjMUbzyjasW0nHGrtq+YZkiZkFPaOSlfrzaoFaq4ylmLxyy4vj3z6/Zx ZxTFVJUWtjotYXqlUh9WNaYsuebs6slL65KK0kvTI+MS48JiHVGWpHh7QkSae/3MA+FJ+bZR rqICvi6v9R2Rgbwb0mEc3OCfV5WtaJfQDkbIEH7hCgWjqqjQJpPnBNw9p5/VubSOWnOlflKJ 5O8l/Otul7w+4O+laBN8SvH7xz8ZO35qGyMW7xTjyVWKbhujgfYhgeVcaTCZpDUKCuZcOSNr clVFkjomPcGSFqPS4PMuOSdek1heXp3a2TstdeiEIX1ifkxOflFCYUdhbnlWJDu64tH11QbH 6LQOaZVS6dRyu0qvVijUetVQBD4hwxrWb+spOWtqblhiUerQ6+VVeY3zcU2q9n0k2sRXoTCw 5nvjIOVRYRmEQTSzgAWS/KNO4l/oR9TKHmHVkIveqFaz+txMafiZ/K8CrlAa/mDG/oyBUjwO cI/Ok1af/21LtOYrRjwFcZVR0CKjCDwHpU2dTZQro0fXTnOeuens4okr75qTWj+x0BQqFyP1 BkdBdd6crtj8+vyCulEObahGKfPE2qN1UbZYvWvN9mXrH183HhcSky7aHjM6G13vxmuqz6lN tjgsKnM697c6XEeelS8CB+5kr/dbS20u2SXwf3qRLSxxqSJsleqSFLMsLD3gLHiv1rhCo2sL pPEVYGq7K6xePok/1fx3IHpKqbQzoFs/9Ke2MXI3NfKexUfisNOJDsfIvUOx+KwqOi3Bmhqj rrhx5vyNran5c66ZXbd6rFpyuTjN8aLOotyqDGN4WnlBbG5+kTUx4F6dtVPRozq5240bw94N +NpgQXl17tR5haPOasrTJRancrvVot124PqbAQVMTnbbFhFhy+S/YskokPVzy9nEzIhMwZz5 uIwvdVFaVg8yvUyY1ChrlwmbZR6ZIJPFZaNFtulYPafLimWyDztqo7+CMH2YYBDDQqM1rD40 GguE/t0VF3CijP24vA34V7q2c2e1ZQzMauN7kTfxAZktWfzfe21pWVDYbSP81niqdwvGlCJp npTijrSkwbfNY9omlM2tydGFakJEQRaiHT19WdmKbSvHjF9+31ndm+bnfCHOmJ1TlR0jsOPO zJK2CYkRURHKcFuMyWLShUVHGcaufmTNij2XVJb1bJ5lPWtV0rimbJyXhb7jbKN8Mi6WNqgI 7GtNwh6IAyOuoSqwsPMecsXoa8jVXkVfO7mD/XbeKbv5wEAi+H3qwNcudEO2OrCSBRgxvtk9 Zpy7eWyiSqeSy/EgrkbfQk/SqVjOpNGjaiaNKcFVaq3vuLgLV/oCmBPoZy72MBE0eDSBXdix LSvLhG9CD7vCXGBKVMtTa+IqDZOoc6V8E4MLOvaR7yH1g3mH+bSrv6vYyO0lM3x70Wa0auPy o2TMZBJ3qePzUtPybeHKoddOHx0LCYm05TqS8y0anW7oBHNq1DaVLlQuC9Vr2atDqYExn1yp v/mUdWrCJa1alxgx9PpQVmS8f/wv4R2UBxfS+PvSI/hjLgHUwmwvJOBO+tg2XEalHbWGdtT1 LrUrqzY9JqkmJjDA8BJpvcigh1uJNI/6f6rmqXMsrb/Kb1vJWFREq81LmrjcpOTcOE1EUokj Z05hwDKq2DSLNT1KVXtT04w19YnDs88GJ9QWxldOHNw67A/nB87ObGwce2ZvB/ptNT73ZWiN 097HeqT3sZ5T38di8e2qdvjtKm7kU/p73sd+sMaPeB+Tycau7j9vhWfZqHGrHz5vpWfpqKFB Y15T6ajmIrMpt3l8SXNRLDuyZPdltWVr+5cv+d2ltRPW9l9YtniqM61hcRUyK23yYr67Gbpe xv9H5JG7G1uRKrC7ueSHdjc1+ob/9e7mH7UxcnfzHS7wfbsbfMDMSpkwbqx12Bdi0iwJuMtJ qZvclD2H726OG9Im5sXk8t1Ne0FuRaaRDazYs75aZ3FahmYGbhXZWwHHWJA6Li2yfr13RcmC qbk6vrs5MLEmb8p8um+EXdLOv9t/3zh0/UK7SwOxOpVFla0StaKKL+x4B6j6WZNL5cqodeiM 1hqj5Pe4IEhjns2fGPv8d4zqH5cfYRsa/ffYRyHswtVcFRIZkxBuTM/CG+W0G8Q+ftSoOG2C NVotlwliXZIzVqUMURqSxmYO7v/2LbI4b4JDJypDVRpjOo6+xndE+AxHXwNHTr5vOoffN8td uH7KnMx5uFitYqoPDMUuvhAUW4sFUXpJ1I1lY/l3O2bpRfEwf0msNen5WwiYmF5m+mzYKdA+ /jfFNulVcXZbhn6gDT+nvIa6rP/iq/2Et1Phs5KuK5ryZlTnmDSyEE2oOsPlLkosTIlMHlc/ pX5cct6sS5vTG1yZESEyUVRqQkIdJXU5iXlWvWN8w5SG8Q6WMGnZ5BRdVLQxKzPeblTGJMSG xabGJmRY4xIzXdNLXQsnpWvCjTqd0RJlToxUGqONYbH2SEu6Nc6W6WrFWYryHRWukPXBaLiW Zulhg0E7Jg3sWfyXylHarMCdmYX75m326nhtQKHlG+mo6lz+2xyX0m8cvDmfk5a2/MG8fXkG 2uLshKyf0git9jL/93P8MU6vgAEf9j8J+XcwpsBWRrhCHW7PLo6rO6c6cWFEJHfLs9Tx9BR4 jDtqZMTjzjGR1hiDUqFWyFdnZkfgA9/RsHIq+0N2cXxqlOopvMXlcrzFn1JFpcYXZw+11dQo Q5VKYxKuiu/7PhVA3oVLYBpYduNupR+suFu5Yodanmyu11dCaembz/vX9cAXiuLJzchp3/m+ zVQxGXijxahYrMZSmJpaYNHKtbaitLRiq1ZrLU5LK7Jp2b2BNUfcoI3UKpTaCO2JhrRRiTpd 4qi09BK7Tmcv4d/vLBzaJMTJrwI7JO6BWHYcn0d69ndQgCgs22a0qC+B0myWPfjqwKu8cwo0 XXiUKZJ26ilOkffK/+W0ENV8xrSpClNWalyqWScWNRbGmosaCgVNdJo1yRktylseH+o4cHCo 80l9lD5EplQru15+7eC53Qdf279AHqIUlWEm7E8H9icc+2ODpJ24D1/qDTfKd2G3dLh5O7HN GKuiDvFv0qUe8W/NuMkcjoLiovDCAiHFQXaKMoUL4bGFDUWizpwal5ZlUjRNO8MtF2Oyki2p sWqx62wh9tyDr73chR2RhWCX9rFNBw+wTY9rTWHYmRD5S0NNOHerxLnCAfmKwNwZBQWowSYo dqTJzY4qfRXO3XN5Un+oM9JUDU/e8MNGlHplMgqPhxoTY832SNx7mzOt1kyzaujs0Eh7rDnR GMKiGFdOyBWvCHxNx/YEHGtowqk6o1H66+xt/x2RzTklvvJDUVhPUSwLxp8jypzfG1+Uz/92 VAj++Px/MirtPxjv/HYMST8l3vrdMbRUio9SVF397ahODcZgDMZ/WVz+b4qPahT/ZHQHYzAG YzAGYzAGYzAGYzAGYzAGYzAGYzAGYzAGYzAGYzD+X4vS35P5//m9H4822AtyUMB0qPMd5f/L Nz+yBN87eFzje4MJ7GbfANOxq3xf4fFm39+Yngm+L/C4BjUJqPmMnY2aD/6HuDMBj6q6G/e5 M5NZs4EDJJHiCC4BISCipBARXFBZIwIFbWVCEkgkG5PJkMGwqIhLqaWUWqQuqKmitIjWLmqX KBAJsqSCMVHgC0FBLFDAIVDg437vOffOJAH8l/6f73m+nOe9c+6955zfds7vnImPhGuyvoNr mv4J1x76Jq7z9FquS/V/cl1J+5Aa7Uk12pNqtCX03cE1Wd/HNY1xltD3INd5qr6U61JaHtRW 0vIQ12T9K65p6kkP3q6kpXy+Uv8am/pZeorov8Cep65WZW2iupN1i3Ba+4jov/6fYbWZdZtI saaZ9TjqA826nfoos+4QIet0s+4UfRjVqLuEz9po1t2WVTFZHjHZesqsx4s+tnFmPcGywlZp 1hNFkSM59u/4D3RUmXVNOBxrzbpF2Fydov9iv+jmPGfWbSLe5TLrcdS7mHU79SvNukMMdfUz 607RxfGoWXeJZFeBWXdr2TFZHnGdq9Ksx4surlfMeoI2xvUns54obvLY5F9LsLlMPxt1w89G 3fCzUTf8bNQNPxt1w89G3fCzUTf8bNQNPxt1w89G3fCzUTf8bNQNPxt1w89G3fDz68InBooB 4nquPjFWFIpcERClohxmiCDPbqMWEGXqmsOTQmolIoM3I0QRxScm8GymKOBdubrL5zOf1iGu ebS8jX5FtJnOs0JaFKp2OVDMWHmqbQl35TwrUe+M/oVo4IMc2hUyQpi7OdSCyJJtKhgxyPN8 7qTOFfTO430J2shRSs1Rg7QoNmXKFj5sLFUypZRyZcvdytYZPJE2VvA8X/UIqCdFSuugaUcu b/qqkYvVkyI1Yg4+Mp5HpRQzTpHyWJmpZQlPipVUY0xpZ7CdBlJimbLF8HfU24buUlIpHvBh v+FxqVUxbXOQH1R30uJgLB6GzwwpPqV7iWlXqfLtdNWyTeP2FkmvVap+htWzuM9Q86F9NK9V oxWrEcLKDxVm5Nv7W0bMsD9f6S/tN+ISULNBfhoSZax9jFEWs8bQcabZppy7ueboQawwIhSK RSlHzZEcnhZ3sCs6m3PRJEfJzzXlZ1xk1g+5wE6fuJV3RYw22Zw1heb8upERBrN6OrbvF2v/ 3bM/qPTIU7NT6jQrFpeovy62Hmeac70s1lrOZmMWlNA+X82nMbTIFenKz71pk6fGu1P1LVXj ByllWNqfMkeVDLXOOsrLMEfvTz2sZuVMpXUZI4R5Kr04Q3lCzt6Oo0afyxVsWD8rNt5UZYMx c8Iq4uVKw6Ca2+VqLRq9fcoGuS7yVVQLlYx8Fdfpqm/UW3eISdg9wuwbaPfGWFN5yidt62SO kpWr1tHF5Br3sm0uEaxQPsyLzbs89V6ubMOC6FwrU5aWmLPNGCtfXeXqOd9u+d5Ypen0kpGS s2F6TNLFtCq5YORL91Hb6NFM6TNzXVDpndsh51xoezTDnK/X0HYekJYYthiZN7p3BGJZPE/l sRKVz3K+01LDzzkdfGpkgVLzalhl1CvUzKtQPfNUTpDW5MfGkS2L1Kr5f0Xof2tdtK2J/kob uQaM3SBDxapMVL7uGzjg+oG+sYW5gdLy0hlB322lgbLSQE6wsLQkwzeiqMg3oXBmQbDcNyG/ PD8Qys/LuC2nqHB6oNBXWO7L8RWX5uUHSnzlOSXlPt4XzvDNyCkuLAr75hQGC3zlFdODRfm+ QGlFSV5hycxyXylNg/nF9CzJ8+WWBkryA+UZvruDvhn5OcGKQH65L5CfU+QrDCIjt7yvr7w4 Bw1yc8qoyy7FFUXBwjKGLKkozg/Qsjw/qAYo95UFStFbqs3oRUWlc3wFKO4rLC7LyQ36Ckt8 QWkHmtHFV1RYgqzSGb7phTPVwIagYH5lkM6Fs/IzfKaZ15b7inNKwr7cCow39A4WID9/ji+Q gy2BQsymY06xr6JMimHEmTwpL5xL82ApBoWkSTm+OTmBYkOWdHNuQU4AxfIDGTHXD4nK9N1a WpQ3GddgjO/GjMEDzef95PMO7g8GcvLyi3MCs6QtUq+2OM7E62XycW4pLigpzC/PGFORm55T 3tuXl++7M1BaGiwIBsuG9O8/Z86cjOJovwya9w+Gy0pnBnLKCsL9c4MzSkuC5WZTWZ+Rg/hZ st3U0gqcE/ZVlOcjHIXka18OscgPFBcGg/l5vulhpdYdk8aM4G1A3RCpvAojJnMKCnML2vXl s7Akt6gij674Lq+wvKwIAdJrZYFCGuTSKr8kmOGLyi4tIaTphb19+cXTZae2oUqijS+qkWou JyUBKg8GCnONmROTLidMdKyhSoH0QqQweeXqCMgpnlc6p6SoNKe9UHTOMTRlCmAuPpaVimBZ RRC3hwpz82WbgvyisvMMupRYqEj0z8ufkcMyyMgpL6uM/lUrPUUsvvDfslLfV6ycz90iSTh0 navF/CYitHQ+i4SIfce5+M/t1l/Gx8u/SaUtv9T2CQmyvRJ0Se2TklT7okttn5ys2jdeavtO nWR76+2X2v6yy2h/u/r7a06+F8n28ttoF/Nvp3Xh+3hP8YDor1lElpYk7tSSxUQtTUzTeogi 7UdijlYkHtNCYpk2TzyvPSlWa0vE77WlokZbKT7mu9Rn1vniS+sC8a31l4wgNHdHWVriv5E1 CVl+ZJUgK4ysx5H1C2StQtYaZP0JWeuRtQ1ZXyDrILL+hSy+E2qdOsqyXNFOVjdkXY2sG5A1 AlljkfVDZBUgaw6yHkXWMmS9hKzfIutdZG1C1k5kNSPrCLL+27pAS0TWFWp+dZBlvbOdrFRk DUTWCGRlI+uHyCpCViWynkDWcmS9gqzfIetvyPoYWZ8jaz+yjltHManna8nI6oWsm5B1S0dZ tsXtZF2OrJuQNRJZk5GVi6wgsh5G1jJkvYisN5FVg6ytyPocWd8g66S2UrMh6zJkXYWsTGSN QdakjrLivmgn63vIGoKsHyCrAFkhZD2BrGeQtRpZf0DWR8hqQtYBZJ3Qlmh2banmRVZPZA1E 1u3ImoqsEmRVymXk5Nu2+4OF+ygnF366cPfCOorTIZzOqlr1U+W0C6fj1JYtpxq3bNnijBNO e9mmmqOVKSvK7HHCbj+aUtnYWKme19QcbeTnqN0m7HFlNfyUqecpsgmNVPuyxlM1NZUui3BZ a2pEjfoxe9OVAYxRZYdGswM/ciDz6dGaGrtV2G3Nqqspq7lsQLPDpjts/qN+fgY4LZrTphog wm0VTpvPP1zeDvf71O1CavwMr1lotWrOuFWrVjldmtNzoSc0p6vNE9q/94TLLlwOBNGOlu1c oV7Ex8dXyRdVdruwOyq3nK2pqeroC1eccOGLqDNkMzXUFrMHP5XO2NNTpgeOnu8Mp0044/ym N1wWzWV4Q0rxkLSj7pD+UPemP5RDpAY42uXRXAnN/Bxr/rv/C8pm/zaKy6m53Fkz1sufGVku u+ZySlWUU1xxmsuBU5rLMvGKwy4cjsol0uIqt11zO6Nu2XLKEac5pPdqajaVqVdRx2ypctg1 hxM7z9ZsqHRbNLct5poa2VL6dovyzRbV0hhwS7SXdI+77Tn+qXHYNIfpIFW3Kw8NaJaexkWn lN2ZUlRcTcxJ8TZuB/j9xgN8GG8TvKeifnhhi0MZOSHd8Zo7sbnsKD9N62TZPmD7gFqK26W5 PcPEArFv4Qdm2bdwgRgm3A7N7Tp7rrb2LFrW1ioHVJ7dUHOqKn7J2UrDrLP442yVx6F5XFKD XbSuPbdL+s1RKa06Vane2fkJqXchwwVncdzZqvMcJ5tK79fU4rrGLbUOh+ZwqSFrjXqVGqLK HXt+bpf0loySXK8xzx2t8Q84qjxnx3PSdZWZHovmiXpOSky0cY+HYr7zD0i0CU+cqpneU+7z KPd5EjRPUnNmc+bRyqMqT2xdsXXF9hUfpXyU4nFrnvhbxIKFe2vafvbWLFh4i/A4NY9burD2 7Nna2vXrPXYslD5sruwunSjXKvdLmFRni+IdWnybF7FNrWTZumbD2Ur1NuZHHGks+nO152o+ PFclrWvnyRrZus2V+FK13nVuv3JmtKvypsd4Uxt1pzNOc+LOZjPnSRVOyfxx6qg7TrijDsWj 8RZLvD1mMKKTbFp8O5cqTybZRHw7n0adGq+cGp+oxXdq7t7c/WjW0azGosYiuRg+WvLRkvXx 6+PjPVp8whViQQ3D+duKv2ZBzRUi3qXFe84JXaxX5Zw4K2pVTU5f5aqs+R/i5axE++KzlS6H 5sLexfb50nEJTi3Bbfj5ANnhwLldKj1kVn3Jsy+rMtV7Kz9DF6j3C4YayWT+gfV6zd4Fw+It mNnO1zWygwrcR9t2nTq1a9tH61WHPfo+lX7Wx7oz2PyseHkXE61yKeko6vAapQtBZ4YwQTxy /kVdjs8TLJaENp9LHZJtWoK9ndOVr9XDdl5X7+PitASn2rGME6BbvGyZIqy54UCR8M4M5M8S Q4pygiViDG+0eyfc6pN/b5UTszz52UWC8Jp3mnCIRPZ7+dx4YuEkkCS6Uqx3Z2ffJa6aMH6s TwyYOGG0jzxitJFn8GT178Lq1N2iU2x0Vp3ozHnIuIsT8eIykSYuzy0rLxPV6vqGuq5T1z+o 65/V9cNZfPEWm9R1m7ruVNfP1bVZXfer6yH5BVEcl1fNrq5p6pqhrreq62R1fbB4VvEsbb66 LlbXp9X1GXV9QV1fVde1sZP0v7tql3h14kkrPmBHoi7/68H/3TMLcUj4jz8TRQ+RISao3zI+ IpaJl8Xb4kPxiWgRxzkPupSlTtPaQ0L+NxT5t4O96i9dy28CQ4zPJ3Yan8+vbNeH+XYgrcO9 FhfseG9/oeO966mO9/GdO973CHW8v/K89z2Xdbzvu1q4LO3u+xW1e2/nEP5Ox/s7LHy6mdPp Iht7EunzCK4aYMkWCyzVls/EKuvz1ufFTlvQ9pL4NG6H/QnN6r7XnaO9637co2mb4pPj77Dc Fn9//AuWcEJewoOWvyQsSFhi2ZBoSXRaPkk8mXjS0iS0h7Olb+w7EtZdtGym7EzY0658aZbN FylHErvHSk/KIMowSp4qy84vCZsTn0tcm7zULCvblWpVTl+sdLJ1GhUrizo9HStHjdK560VK OiXDu7xdecEo6s15xfsb74exsqnL55RmVc5drHRO7xrftWe3RWZ5ql1ZrsqHFy313U5HS4o3 JS1WbjfLqIuWbFUmm58dy0LzKtvVqrIzVozee1KOpvZJzUt9IXW1LOePnrr2YsUYPfVPqS1m ibQVKSX1tJK1UPK9Mb0yYmV4r5GxMsUsD1CCvR646hrKoKt7Xp3Z6wGuPa/+wzV/vnazKl+n j6Pk9U6j+Ho39D4EDb2P9/nzdctk6d1w3brr9lBO9bX0dfZdS9mUMZBye8a4/kvN8vb1wRvS btg1aPFN6ZSBg+MHjxtclPmqWdZlvpe5aUgPSt8hoaFbslplubnq5rWqfD2sx7DlZnnh5q+5 Xz6sUd01DvuGsvwW7/DQ8OoRXe8YTqm9M/vmKqM1n41Gq7uvke3uHjTKjVOvGbV0dKIqmaMn qBIZYxmTMqbn6Ai1bMqMsWKsfWze2NaxreO6j9tPu8zxE8dPHJPNdbqsUQrGB8YvzLar0jd7 nCr+7BLwZ1dmP5JdyftAduM9993jv+f4PccnJE94gXZ9eafeTDiVXXnv9HuLJm37we1TGn60 9Ecrf1Q985GZjQWTCyqjnwVvFLxROKDk6ZJVZa2zxexhs/2zH5wdnP3I7HWzP5z95ewjs08F 7AFvoE9gUODWQHbgSHly+TXlZeXzy5eW15Y3B4cEJwbfDjZXpFXsrDgdGhCaEaoMrQy9Mydt zsQ5b1cWVD5V+U7ltsrmsDvcPTwyvDS8ee5Vc0fOLZg7d+6iua/OXTf3k4e8D418aMVDbz/E V8eqlKpRVXlVa6u+ntdnXnDe2nnN83vMHzT/wflPzG9Y4F1w34LVC/Yv7L7wr9+Rtdadn5k6 5p2FX7YVmVEeTmwrRi75jtU36vw113GlGHP9ovknmoPalY5Z5OFBbUXmh4dvbStGZpDZNLk6 pbbbcjLyzmGN5E+VjdUnmbfTKDLtssTnkpcmbI5mz05PJ+zsdLTXFNk3YV3isrYsaniJPD1M ZWKjVffE56Lek09VVpZtd8r3qr3pQcZdl7CHnP4cPXaq0Taj3VI+d6rStk98ed7+MKzdjtC2 Jzwn9b5gH6g+fx8g99vMvL8omvHVOPROHEZ9WTQXEo/VZrzITkYGMjKcGUeyIjlQRm1KLD9G I0qWSxkl27dFuNdIxpHvIzzPTm3h/oLZQA7c2S6bXiTHts+pF+ZTM2vXqnlkZNDh0dwpczpP RspxuR+Zkn1T+viJXc4ZO5n6ZNfqdpq96lzXePYhc+eJ7iidu3Y517b7GPNR7m+yfZdzsgW9 P+waL9/IJ2ov44l817lrwuboPE1J430zEhij2yJ1p5637ajt91Spk9o/oztobA9lz4y/yJ65 /II9s97YKdkjvVFbeH/a0ENpsmh0ZpfPU25Htw7RkF48f+VGPW6sSOlbY8b0moL3R8nYSr+k ZHuXq8ivlpFqt7ozUtd27hrba3eaoy405oOMizG/Utde3fOqawyMXe2qa9RO1K7IXc3Y0dSe +P9Z1D7arlzYQu2u7Yq5y8bKhT3U7vofFbX/XnKJ7dLfUc73lCyxvfs7itrNL7moE8YllvO9 o84l7cqF/lPnlXZFznQj0v9ZuXDkf6/dpRXDz/K8kvhcVuso981fJ+yUJx1VquSTrFZ5upF3 N1eNcstzj/FOFk5NfeVJyXiq9qJvjKJORMPVaUqemxqHNaozkTw3NdKjSp1H7LFziyx9s+3j p2fb5ZlF3fU1TzZGvS/nngL5RJ1u6Cc/ZZHt6WFXo/nV277ymrqW1n3l+alr/OjE8dPlWUue s1TJVE8S5TlL3WWOny4zkfmOItOEPJGpE5pFnc0osj095AmOlvI01nY+G5057Bvlj6+lJ+45 bvghq1VZg76GnmOy5cjqvGeRYxnjdlyHF8az/Sy4drNxJ+xajb7NOlb/jXWSSLVOEUnWgH7A +lfRW1h48zF3jap2yDpJPyA0rv8SFq47rFP0HXw3X6O3ig16q+YXvbQcMUmbzmeuSNfyRA9t luhBy3toOc1apNcJjXG+EjbaJtG2B22TaOtW4x2i1THh0h4Qabzvx/tpvO/P+36MNZCx0un9 mtLHQ+1t9O1hrdI/sM7TX0TfG6z79JesX4p+1q/EQOsB3h3UG63f8G03qm2LsFG7gloPtFnD SDtEpUgSN4pkGCKuFEMhj/HzYQaU67tFEK0qIARzoBLCfMOdq28UD0EVzIP58KhIFYvgMVgM j8MT8CQ8BT+GJfAu38Dfg1PUz4EuUjUBGmSLTO0emAD3wkQoFOO1WtENi6dZJ4ss6/0i3joN ikSJdQGWPix6WR8VPWwv6httq+Al+ESk2nbATvgUGuAzaIQm+By+gF2wW6TGJeuNcc36xrh/ CFvcIeqH4ai+0R4nbrT35vMGcaX9Jj6L9EZ7MZRAKVTou+0hwDd2fGPHN/a5gG/sb4pM+zr4 I5wUmY4+opvjOpgmUh1+mA6zIQBhWAgPAz5yLIWfwYvwkkh3rOHzMByBo3AMjsNJwIfOXMiD fKgQ3VxCZLq8opuau0eY125VO0jUT4kuzNrNzNrNzLZezLbRzLZHmG33MdumMduymW130bqG +XKrdTJz5Qf6G8ybScybJxghaP2rvtK6j3n2lXBb9+t/sx4Uo9U8O0Cr/aJTbFU8ILLajT+N 8csZfxLjj6D1dHPsDfS6mbFXMfYac7xskdhuFDejDGaUEkbJYpQsc00MRssDjHQvI/2MUbIZ 4W/K0j+qWgpj/IUx/sIY6do0/T3GyWKcQsYZzTj3Mc5IrVD/hLGytBX67+n5PuN1ZrwwmpUz ZhqahRltmbVFP4Z2G6xfs7IOMue+MVdsQrsV249RB5qrX67YT+m5m5U3Vn+e+esxMoz8nS7P m8Sz4lH9kFgEj8FieByegCfhKfgxLIHN+hnxMWyBrbANtkM9/B0+gR2wEz6FRtitnxN74L+g GfZCC+zT68WX8BUc1z8T3+p7RQROQCuchFP6p+JfrOnTcAbOwn/DOXTR9UOaAE1lxf3W+/Sj 1h/qrdYH+PTrrbZP9EO2HbATPoUG+AwaoQk+hy9gF+yGr/UztoPwDfwDDsFhOAL/hKNwDI7D txABdLGdA50121mvdwzXzzjugFEwGsbpex0T+ZwE9/H+fnhA3+iYph9y+GE6zOLdbD4DEKQ+ ByohzH0Vnwv5fBgWU38ciIPjp3wu5fNn8HPqy+EX8Az8kvFf5PnL1Kupr6H+JvX3gRg5iJGD GDmIkeML/ZxjFxAjBzFyECNHMzruhRYgRo6D+meOb+Af2HIIDuufOo7APxn7KGMfg+MQoS2x c7Ty/CT3xMiZC3mQT7ws4mnhJVKnhVU8rTfFdq847t7lbgl385jljdbtoqfQeNoqbmdmNjAz G5iZDczMBmZmAzOzgZnZwMxsYGY2MDMbaL2HmXaGmXaGmXaGmXaGmXaGmXaGWXSIGdPKjGll xrQyY1qRtxV5zdYfsRJyYLr+lTVX/4pZ08CsaWDWNDBrGpg1DcyaBmZNA7OmgVnTwKxpYNY0 MGsaiGQrkWwlkq1EsYEoNhC5VqLWQNQaiFYrkWolUg1EpYFoNOD1M3j9DF4/g9fP4PUzePUQ Xj2ER1vxaCsebcWLDXixFS824MUGvNigVuxW4cCXmaxkO3vv8+y9K6z14krr30VnK7uN8u8B 0797lX+f5O773N2Gfyvl2UJMYZ/0sk962Se97JNe9kkv+6SXfdLLPulln/SyT3qR1I+9Mo29 Mo01u4c1u4c1u4c1u5s1e4I1e4I1e4I1e4I1e4L9NIk128SabWLNNrFmm1izxJtsO1mks04P s04PsU4Ps04PWaeLvtZcKBJ55j56Bfuol73Ty97pZe/0snd62Tu97J1e9k4ve6eXvdPL3ull 7/Syd3pZi02sxSbWYhNrcQ9r7wRrbg9rbg9rrok9zsse52V/87K/ednXvKyVJvY2L3tbGmul if3Ny/zfw/zfw/zfw/zfw/zfzfzfzfw/wfw/wf6XxP6XxPxvYs7vYc6fYM43sQd62f+87H9e 9j8vkZqiH5azHhtZ25zSniZ7T2LvmqzvIav/ivdPEI/f8/ZV5vxA6yfUWZXWT9nHZAw/o/Vu WjWSqZ/W53MXpm8TfeXTPHMf3ErffvTdRr+Rwk7LV2k5j5YttPwvWj6oTlly5ryhRrqf92N5 v433co7cykhLePsSI6Uz0gZG6qvaH1KnxX3q2sr+l8RZ8D4ogmIohTKYDQEIwlOiv+ik1ai1 /hyjL5PSVWRXwftikPUDaOGcu0+M5KyYxP7t5ayYav2az4OcrL7h2T84mVnpuY0eXTlZpsqd nf5FIot97D7OXfeLbOsD6gzGLo1m6WiWjmbpaJaOZulolo5m6WiWjmbpaMbsQ8b9nNge4HOa KFE9vfT00tNLTy89vfT00tNLTy89vfT00nMgPUfQcyA9R6ieSfRMomcSPZPomUTPJHom0TOJ nkn0TDJ7jjZ7yjPK/URsGutK+vg9dVI4jbda5P/bxF5+D0yAe2GicHGCc3GCc3GCc3GCc7nk /w9lw8Od6fMgHh6jzuMyRl+KnVq6vk/rDX3gOugL/SAD+sMAuB4Gwg0wCG6Em2AwZML3YQgM hSy4GYbBLTAcRsCtcBvcDnfASLgT7oK7YRSMhjEwFsbBeFipt2i/gufgBXgRVsFL8DK8AtXw a3gVXoPV8Dq8AWvgN/BbWAtvwjp4C96G38E78Hv9WzzSon2g79Y+hPWwATZCLc8/0hu0TVAH m+Fj2MJ5Yitsg+2s2/uYuQ/oO2wb9W9ttfARbII62AwfwxbYym6wDbbrDXGd9JY4r74vrgt0 hW6QAqn6PvtP4Vm9xY4P7C/oh+yv6t/aX4PV8Dq8Ae/wfD2fG2Aj9Xq9wb6D9pxb7K36Psf3 9BZHD7gCfHCl/q2jJ/SCq+BquIad41pIJ2/1hj60uw6uh4Hc38C7oew2WXxO0L91WvR9TivY IA7s4AAnuMANHoiHBEiEJEiGTtAZLgOv3uLsAl2hG6RAKqTB5dAd0N+J/k70d6K/80roCb3g KrgarkGngZwbboDvs/MNgaE8Gw4j4U6YhrzpfM7g3UzaFUAhPAgVjDEP5sMCWEjbn/L8Fdq/ RvvV+m7n69y/Acd5dkLf59L0Fhe2ui7TG1zY4eqiH3L5mEOVmoXZYgUbxIEdHOAEF7jBAwmQ rB/QOkFnuAy80AW6QjdIgVRIY4b10A9rV4AProSe0AuugqvhGrgW0sk1vaEPXAd9oR9kQH8Y ANfDQLgBBsGNcBMMhkz4PgyBoZAFN8MwuAWGg8xnt8JtcDvcASPhTrgL7oZRMBrGwFgYB+Mh Wz+o3QMT4F6YCJOwbzL8AKbAVJiHLfNhASyEh+EReBQWwWOwGB6HJ4BvHdpS/bT2M1gGP4fl 8At4Bn4JK8mZv4Ln4AV4EVbBS/AyvALV8Gt4FV6D1fA6sBtqa+A38FtYC2/COngL3obfwTtQ Qy7/AD6E9bABNsJHsAnqYDN8DFv0I2SRI2SRI2SRI2Tpx8nSpewDqWT+LPaBVLJ/Fln7MxsZ z0bGs5HxbGQ8GxnPRsazkfFsZDwbGc9GxrOR8WxkPNta/bDtTVgHb8Hb8Dt4B34Pf4J34T14 H/4Mf4G/wt+gBj6AD2E9bICtIsm2DbaLpLhOwh3nFYlxXaArdIMUSBWJ9iX6YftPyEI/pf4M 9RX6Afuzwm0nBmSzI/ZVvMMW+695h852dLajs50sbX9TP2hfB+hrR1+y3BH7H2j/R569y/v3 AH3t6GtHTzt6kv2O2D+izWbefcz9FtgK22A71Isk+w5k8w3Pzjc8ewPPPtNPkymP2D9HN77V 2Q/Q9x/UD1HnjG3njG3/J/DNxX6M9sfhW4jACWjFtpP6QUeiftiRBMnQCVL0045USIPLoTt8 T7gdPeAK8ME1nAqvhXToDdfzbCCfN8AgMu9gGKofcWSJJKdFJDqtYIM4sIMDnOACN3ggHhIg EZIgGTpBZ7gMvMLt7AJdoRukQCqkweXQHdDTiZ5O9HSip/NK6Am94Cq4GsgzzuugLxmxH2RQ H0DmvJ76QP0ImfiIcxD1m2AwZMrMjB1DYAz1sTBOP+AcT7+p+mnnNHSbwbuZ9CuAQngQ+Kbr 5FzpnAPzkDsfFsBC2j+JPNY8mfqI8xk+VzDWs7ASfgWvMd5qeJ33b8AankVod4K+Z/TTLqEf dGnC7XKSufGhy81nJ55fJpLI5kdc7EqubjxLgVT9sCsNusvfSMrVbZ6lnmRVtqhz2d9izxfx /FH1GxR5xjom4ix36ZOtY+VvpoRb/lZLvetrGaDvtwyCwfoByy183qXvtNytb7SMhrF6PSM1 cqLYz4liv3uKvtF9HzxO/Ql4Ep6CH8MS+Ak8DT+FpfAzWAY/h+XwC3gGfgkr4FlYCb+C5+B5 eAFehFXwErwMr0C1vj/+On2/sKJpq2UK34al/kPRP4L+EcsQvRH9I5bb+HxS32t5St9L3vKR s3y03Oi+V290T4TJ8EPI1fe6H4QiKIEyCMLjegTbItgWwbYItkWwLYJtEWyLYFsE2yLYFsG2 CLZFsC2CbRFsi2BbBNsi2BbBtgi2RbAtgm0RbItgWwTbItgWwbYItkWwLeIZpe/1jIYxMBbG wXjIhnv0vdgeIYaD9c+IUKNFxVF/X/0u4gpsX4Pdayz36+9b8qAYntTr8EGd/DaC7WuwfQ22 r8H2Ndheh+112F6H7XXYXoftde5K/X13GB6Ch+Ex/X30qkOvOvSqQ6869KpDrzr0qkOvOjGC CISIQAjd9hOBEPqdZgYdYwYdQ8/P0aQFTVqsk86dRN8k89tMP/PbTD/zd4SNzK5jzK5jaNeC di1o14J2LWjXgnYtRCZEZEJEJkRkQkQmRGRCRCZEZEJEJkRkQkQmRGRCRCZEZEJEJkRkQkQm RGRCRCZEZEJEJkRkQkQmRGRCRCZEZEJEJkRkQkQmRGRCeKAFD7TggRY80IIHWvBACx5owQMt RCYkbsMLfrzgJxbb8YKfeGy33CXSsH4q1k8lWhl8e33J/A59g7mv9jf31f7m92I/sdpOrLYT q+3EajvemIo3puKNqXhjKt6Yijem4g0/3vDjDT/e8OMNP97w4w0/3vDjDT/e8OMNP97w4w0/ 3vDjDT/e8OMNP97w4w0/3vDjDT/e8OMNP97w4w0/3vDjDT/e8OMNP97w442peGMq3piKN6bi jal4YyremIo3puINv3AwF45hcW8sno/F87C4CxaWYuH9IhUfvYV/3sI39fimHj8k4QP534/e wP63sP8t7H8L+9/C/nrsr8f+euyvx/567K9Hj3r0qEePevSoR4969KhHj3r0qGetFOLpjvnu uOhnuYdZOoVcV0iee5AcNwuKoET/VP3mIprr5pEzFugbPQ/p+z1VMA/mwwJYCA/DI/AoLILH YDGQGz3kRg+50UNu9JAbPeRGD7nRQ270kBs95EYPedFDXvSQFz3kRQ950UNe9JAXPeTFRBe4 wUPO09Rvv6TuEdZ4E2u8iTXehN88+M2jVk+l3sTabWLtNrF2m1i7TegeQfcIukfQPYLuEXSP oHsE3SPoHkH3CLpH0D2C7hF0j6B7BN0j6B5B9wi6R9A9gu4RdI+gewTdI+geQfcIukfQPYLu EXSPoHsE3SPoLnPWFH0X3m7Ew+/Hcpa0aJcYiEXVvP+K96eJRivRaCUarbT9nLYDaJvFSnFj aTorxY216cyjn8jcT4RaiVArVlZjZTVWVmNlNVZWY2U1VlZjZTVWVmNlNVZWY2U1VlZjZTVW VmNlNVZWY2U1VlZjZTVWVmNlNVZWY2U1VlZjZTVWVmNlNVZWY2U1VlZjZTVWVosbsSRMbLYS m62WQtGV+GzFgnxWwCFWwD4s+QmWdMeSPljSHUv6YMnTWLKO2G0ldluJ3VZit5XYbcWqMFaF sSqMVWGsCmNVGKvCWBXGqjBWhbEqjFVhrApjVRirwlgVxqowVoWxKoxVYawKY1UYq8JYFcaq MFaFsSqMVWGsCmNVGKvCWBXGqjDreIpax5lY8QlWvGP+91h5rnhVeLC3DnvrsLUOu7pgUxfe vIk9ddhThz112FOHPXXCbqkgxiFm8Bz9oGURvX/C/vAL+Tt2nv7LskhvFRrXk6I3LU5aKnkW Vs+3WxYLl+VxenOWtzwjki0reP6s/i/P5f9D3L3HSV3f9x7/7cywC8OukyjeEi+xGKNprfGa RnOpaRuSJiaaNinHNCY9QSNq1Ch4jVeId0FUUIPXiqhg1RqxZUkgK4oocVxZdhkShl0umZl1 hxl+u8Mia+R7njMhHpvTPnr6eJxHzx+vx1z2N7/f7/t+f27fkV1xAA7EQTgYH8Eh+CNMwpk4 C9/H2ZiMc3AuzsMPcD4uwIX4IS7CxZiCqXB/Yy+FexrrnsZeEXY21rPTnRYSV4WqtRQTd4dK 4h73f3riInXtYkz17mVWeTmuCasT1+I6XI/p0YGJG8LSxEzH3RHyiVm4E3fh3rDS+laOTahl SaQwCs1owWiMQRpj0Yo27IEMPoAPYk/shXHYG/tgX+yH/fEhfDjENIxpGNMwpmFMw5iGMQ3j sSeG1WNPwqfxGXwWn8Of42R8Hn+Bv8Rf4QuYgC/iS5hkHWfiLHwfZ2MyzsG5OA8/wPm4ABfi h7gIF2MKpuISXIrLcDmuCCujlMjZSMU+KvYn5oR3xNL08JY42RGdyoUaF2rvi6RuHaei41Qc UaFyLVGf0r4XKjpMRYep6DAVHaaiw1SoX6N+jfo16teoX6N+jfo16teoX6N+jfo16teoX6N+ jfo16teoX6N+jfo16teoX6N+jfo16teoX/tPI/iv3ceX8RWcgq/iazgVp2GSc5yJs/B9nI3J OAfn4jz8AOfjAlyIH4I21K1Rt0bdGnVr1K1Rt0bdGnVr0Wjq9orwYRFeTlwthqdH46i9idqb qB1HF9K4g8YdIr3gyCytC7QuJK6QqVdx4mqfvCZsE/nbRP42kb/NWZr5sIoPq/hQTcxQMe8I m2XAZhmwWQZslktr1IZXedTNo24ereLRKh6t4tEqHq3i0SoedfCog0cdPOrgUQePOnjUwaMO HnXwqINHHTzq4FEHjzp41MGjDh518KiDRx086uBRB486eNTBow4edfCowKMCjwo8KvCowKMC jwo8KsiQbTJkmwzZJkO2yZBtMmSbDNkmQ7bJkG0yZJsM2SZDtsmQbTJkmwzZJkO28XgVj1fx eBWPV/F4FY9X8XgVj1fxuJvH3Tzu5nE3j7t53M3jbh5387ibx9087uZxN4+7edzN424ed/O4 m8fdPO7mcTePu3nczePuaDIHyxwsc7DG7yVcrHFuPeeqnIs5F3Mu5lzd/335v5h7Ze6VE7d6 73ZOzwxPc3ArB7dycCsHt3JwGweHxEkXF0tcLHGxzMUyF8tcLHOxzMUyF8tcLHOxzMUyF8tc LHOxzMUyF8tcLHOxzMUyF8tcLHOxzMUyF8tcLHOxzMUyF8tcLHOxzMUyF8tcirkUcynmUsyl mEsxl2IuxVyKuRRzKeZSzKWYSzGXYi7FXCpzqcylMpfKXCpzqcylMpfKXCpxqcSlEpdKXCpx qcSlEpdKXCpxqcSlEpdKXCpxqcSlEpdKXCpxqcSlEpdKXCpxqcSlUvQJLg1zabiRjdOjDBdi LgxxYYgDwxyo75uGqDtE3SHqDlF3iLpD1B2m7jB1h6k7TN1h6g5Td5i6w9Qdpu4wdYepO0zd YeoOU3eYusPUHabuMHWHqTtM3WHqDlN3mLrD1B2mzhB1hqgzRJ0h6gxRZ4g6Q9QZij6uMoyo DCOq8Bb9PJ241Spua8SPu/d8Du718/vCiIwbkXEjMm5Exo3IuBEZNyLjRmTcCK1HaD1C6xFa j9B6hNYjtB6h9QitR2g9QusRWo/QeoTWI7QeofUIrUdoPULrEVqP0HqE1iO0HonOpnUfrfvc cdkd1+tXURYUZUFRFhQb+v8+A2aK8jtUw1m4E3fBBJ+of7PxH0d7Hz/6+NHHjz5+9PGjjx99 /OjjRx8/+vjRx48+fvTxo48fffzo40cfP/r40cePPn708aOPH3386ONHHwXLFCxTsEzBMgXL FCxTsEzBejYUZUNRNhRlQ1E2FGVDUTYUZUNRNhRlQ1E2FGVDUTYUZUNRNhRlQ/H/IhsKHCpw qMChAocKHCpwqMChAocKHCpwqMChAocKHCpwqMChAocKHCpwqMChAocKHCpwqNDo8VVT6cbo hPeq190qjlmS9mXa//dUlEk4E2fh+zgbk8FzayxbY9kay9ZYtsayNZatsWyNZWssj63HwlRc gksh3qyxbI1lM+4lVvS/c6Ys42vqbT3Th9XU4f8sR8zul5ixp4vjG8TrrZ7fZlaaafc9J9oz +irlKpSrNKbyq3C1o6Z7vFndvwX2fXKz3p1jnzqiMd3O9vzeMEjhQdFdFd1V0V0V3VXRXRXd VcpXKF+hfIXyFcpXKF+hfIXyFcpXKF+hfIXyFcpXKF+hfIXyFcpXKF+hfIXyFcpXKF+hfIXy FcpXRF9V9FVFX1X0VUVfVfRVRV9V9FU5M8iZQc4McmaQM4OcGeTMIGcGOTPImUHODHJmkDOD nBnkzCBnBjkzyJlBzgxyZpAzg5wZ5MxgY7eyg1Kr3tu3xFGysa+xk+bSO9E3aNtD2x7+VflX 1Uu3++l6Toylb4m+pUb9m8mlu1WU2Sale02w94V+upboWqJria4lupbS9d6QCD107aFrD117 6NpD1x669tC1h649dO2haw9de+jaQ9ceuvbQtYeuPXTtoWsPXXvo2kPXHrr20LWHrj1iqiqm qmKqKqaqYqoqpqpiqiqmqnQv0b1E9xLdS3Qv0b1E9xLdS3Tvp3s/3fvp3k/3frr3072f7v10 76d7P9376d5P936699O9n+79dO+nez/d++neT/d+uvfTvb+hcV33ARq/He2ZWCSSO8LLiRfF 5fIwJfFKeDQxFH6V2B5uSewMbybbwqbkkWEgeVR4Inlc6Hvv3yl/M/pQ8u+izO5/r7yJW/O4 8bQMe1H0LzfDvsSJl/GKTFvJmVWeZ82iazjZ7bEHpWjvRL8utt3nhn1+B0ZcLQq9yRaMht7o 6sXk0d4/Bsfi+LAteVLY3PrdUG49M7zaei7Uh9YLPFKjlRqt6kHrlR6vCqXWq3ENpnnvNu/d jhmw32m9y3t34x7PRU/r/c4xLwy3Pun8z+DZMND6z3jOez/1erFHa2rt9N6bWI21Xufwa8/X o89xW0Nv6xB2hN62caHUtjf2wcH4CA71/jnh1bbrPHdfbTeG/rbbw0DbbNyHR00sf71b1Y08 eoeqa6map2qequ9SdT1Vi1RdS9VBqq6l6lpqVqhZpmaZkmVKlilZpuIOKsZUjKkYU7BKwY0U XEvBtRTcSMG1FCxSsEjBjRQs/oGCGymYp2CegnkKFim4kYIbKZinYJ6Ca6lXpV6VejH1YspV KRZTLKZYTKmYUjGlqpQqU6pMqTKlypQqU6pMqTKlypQqU2rtbqU2UipPqZhSMaViSpWjQxIL wuTEovAUpVaIwd9S6GmqlBIbwkXi7NpEf5gvsicnaqFdZJ8uzvLJZMglm8PcZGu4qRHp48JR yYOjc5IfDTeK+s8n/zR8j2ovivyviLklyc+GR5Mnh0m7v5HK7/5XyeckJ4dlsmBJ1OrqPXzq cfVfutoWXmRdbZOzl51xyNl6nC2WQyfJoZOjPdz3sE+t9qmdPlXPj2H3e4xP53ZnYMl9bXVf BzhDjzMUnKE7amusdLnJ6ZXwrE8c6xMbXW+9T3VZ0Ts+udGnDt79qZxP9UYHiqiqT1VE0pBI GhJFA6KoJor6XXu7KOoXRf2iol9U9IuIfhFRExE10VATDVXRUBUNVZEwJBKGRMKQSKiJgCER MCQC+jnWz7Eqt4bU+FJ0qHtps9555roFrvuv7mExVoa3G/+Gd6IIuCxUnL/g/AXnL7Te5/WD oeI8hSjlUzvd+Vk+0V13Vt1YEF7jea93u72bTYiuhn4b1ItxtPtG6Hbe7miiq85w9LVyqeAT z7r6Va5+lU/uoMR2Smx3hrWJVfbmWddZQ5Fujz3IhYXOuEgErU6URUMa48JlST01qacm9dTk +DAteSg+yuPDvT4CR5qvjuP75zw/OdTczZfczZfkXIG6O6m7U84VKLyz9cJoXOsPYVKjwlWt V3p+VZhBiRmUmCHvCtTeTu3t1N7eOtPP7/Le3bjH63txn8/d71wPevwnyj2NJWFa60sef4nX kcU6/Ap5P+v1uBGbwrS2KLzYNiosbGtGCw7x+jCcE3ZyYIbcK3Bze9scjtyDe/ETPBAW6sgd jUjcxOkvqDq7VJ1dqs4urv+FDN8lw3fJ8F2yeVd0AD9i2pdpX6B9wafa3l+brD229tjaY+su WHfBuutrLVhr4b268u/UFPcau8/C+2tEU9oVp4qAH3O/nfvTuD8t8XOOLkWHbH0p2ifxMl5R Q1aJ09Xer9ePnK64zu77V/g11iOPDeHGRK/HTdgs/rZ4/A2KKEXXiZbnEm95PoCyc2z1WEHV dbch9nwQQ+EyNalLxS6q2EXZO7lemxLveO+3eDesSezyGGR1ExKo162UaBvleXN4RkROSY5t ZP01sr4vmQl3Jz+AD2JPjAsni9bTRevpovV0PfWp5IfCw8kP+9kBODj6dvIQj3+E8eEUkXyK SL46eZjXH8PhYaKInpj8uOd/giPD19XGKarK61xbwLUFXFsg2k9VJ9uTJzjmk/iz8NPkpzye iJPCvOSnPX4Gnw0zZMXpyT/3/ORwrcw4Sz3dqJ7W/2X2FcnTo4OSZ2ByeKP+HXnr5LC69Rxc GO0hS/aQIdNkyB6iZKoomSpKprZe5+fX4ybcjFtwW7RP6+2YgZmOn+29ObjH63txn/PM9fpB jw+Fu1sfwaOYF55qfSw8rIvNa13g9UI8hX8KE2XVRJ1tnghcIAIXmAue0t3mtT4fftq6CC84 brH3loRTWn/m+c+x1Psv+ZzYal3pvK95bxV+6b3XkUWnc72J1ehy/FrH5rDOz36FX3t/PfLO uyF0ydyJuuc82Xu67D2ldbP3xGCrGGwtQBy2ltAfulvFYas4bC1DDLZWsQ2xdQ9i2PO3w5rW nRjx/F2IuVYxpypMaRN3beKuLRnWtKU8jvJeM1ow2usxqkcaYrCtNXS3tWEPzzP4gPc/iD2x l/fHhaIOX9Thi237Ot9+jtkfH8KHcQAOdOzBfv4RHOIaf+Q9FVY1mtJ2TVgtw6e23Rjt08br Nl638brtVtyG28OCtrvCwzJ/gUo1UaWaqFJNVAUWqFYT2+Y6zwPO85BzPur887x+DPPxeJjW mCTOViV+qiq8apLoVRF+rhL8WsbfLLMvltkLZe1TsrZDv63J2H+RsVtk5VrZ+JIsfFYWrpZ1 X5JZZ8qkR2XMrTLmpzJmoyy5VZaskgVLRf/c3b/j9ILof6Hx37QvCm9E/1O9mu9O5utYKxPP 6NGLwip161F161F3Va+e/6p6Llc9l+tcT+7u4R16YMndbtG9OnSvDvXrSXf+sjpVcOfZegdz 10X1Zot6s8Wdb1Cv8+58WM3Oq9n53R3ucbXgSbXgSXe53V1eUP8tDd1rZes/mHHPDB06WIcO tlIH63hvRrjE68vCo7tnhfnyc778nK+DrWy172j9MW7FbWG5qr5cVV/emB3u8vO7cY/X9+I+ 57jfeR/0uCQ8Ke6fFOdPiumCfpLXT/LitqCn5MVqYXf3elJcPikunxSLBbG2RaxtEWtbxFZB bBXE1RZxtaXR3Q41Sf6uw3WIqfk63EqdY7n4eFJ8FMTHlmiqLrFCl1ghHpaJhccoXdUdVoiF r6nmXap5vYq/TNU8VVdTdbWYeE7l7qVsp0rdRdlOynaKjbhRofcJa1TjNarxGjFyjBjZqcqu U2XX7Z7XOlXWJSrrEpV1iZh5QzV9UxVdqXKuURFXqIgrqF6lepXaVRVwhQq4QgVcoQKuUAFX ULaq6q1Q9VaodCtUtJWq2DpVbJ0qtlIVW6KKLVHBVqpgb6pgb6pWb6pW61SndarTOtVpneq0 RHVaojotUZ3eVJXWqUrrVKUlqtIS1WidarRSNVrDnU6VpUtl6eJSJ4c6VZde1aVXBelVLbpU i3pl6FIZulSGLk6t5tRqTq1WFXpVgC5OrebUapnfxalOmb9Cxq+Q8Stk/AoZv0LGr5DxS2T7 Etm+Travk+3rZPsS2b5OttezfLUs75LlXbK8S5Z32QeXTMb1mfq4MBIdL8tqMuq7Mmq2jJot o17h8zxZs4Ov8/k6n6/zZUuRrxW+LuTpQp4ulBE1WVDjxTxezJMB9Ul5noivifLZony2KJ/N i3mivCbK65PybFE+WzTvoNdCOi0UzTtotZBWFVpVRPUOelVE8g76zKfPfPrMp09FNO8QzTto NJ9G8+mzUPTWRO9skbvDmudb4/Jwg4jdbgXPeDXk3reHB8VmLvqQlVW9WmdlvVbWa2UFq3pN HSha2WtW9pq7q+/OXnN3r7m7qrt7zV1V3VHVHfW6o1531Otuqu6m6m563U2vu3nNXVTdRW90 sCsNNfYlw662AyOmxHfNyVFjeoldrcvV6t1qyNXqMdPlakOuVu9KQ7QYctUhWgy58pArr3Pl da68jhZDrj7k6kOuvs7V17l6l6sPufo6e4QN4X4rf8Oq33Dl2BULatk/qrhrVdy1atoDKu6q qNlRw7v3T/Hu31g6MjkxGh8dLsuLsrzoiF5HbPn97tqRvVYybCVZWV7XLWslWavIyoCiDCha TdZKslYybCXDVjEsA4oyoCgDijKgKAOK/2bnu69jDvTe73fA4z0/NGRFc7G+2xXNRdFcFM1F 0VxsePtrd/Z2w9tRXg02vlPZiRGVpLn+20imqhNMVSeY1XPWUA5b/ays1m9VO7eqnVvUzi1q Z702blUXt6qDW5xtQyNu1jTOlGwoGEeHOcciP1nM3QHnanfEtvd0MUPQZIAeA/QYcI323f/G 8nIuD9BngC4DXB6gzQB3B9xDu3tY5B4WuYdFnB74N5p82OsD8HtNDnH8oV4f5vEBxz/U+M6k HDVZfRzt6/4Gdve59e5pfT1z3dMmd/8b97XJfW1yH5vcxyb3sMm1B1x7wLXr113vuutdd73r rXe99a61yXXq11gfHersj1t9u5UveV8PqO/1212p0qj56ca/1Llrd6Stb0y2F6mPu2ujFS9x 1cdd9XFXffzfrYv1OniI4+o18DCP9Xr2gGP/sJ6NcTf/4g42NL5taG78Xuw5rvyGK7+x+/eE VkTHuO+cI5dzLWvXUnD/K6m0jErtVKrf+z+L6LpSz/O6PhVUqPU8tZ63npXO+oiztXMxa7Ks d+LnKfg8J+tR/rwoL4ryIkez1rdStBetMWeNOWvMcTVrQiyYEAumwXqHbqd0O6XbRX2Ry1ku Z6neTvV2a19J+eetfaV157ic5UB79GGqd1K905pftYKqdf/CXdeV73THFXdccXcVandSu9Nd VtxhhcqdVO6kcieVO6ncSeVOCne6UoXCndTtpG4ndTup2ym/toc7abOaHv0iTEeQT0fp2ceH t6OkWen1xrdrx4cN0SFebW98azlejTsUR4dBfXxQHx90xLAePmCiqu7+lnFAHx7Qhwf14cHd 3zIONL5lXKLu/e6bxkG9d1DvHXzfN42D+u6gqWhI3x0wGQ3pg4P64KDeNxiNMWnscCf3myzi xje4x4WSq9Z/I+EJDj7R+NZ2tFkkTo5zz0c2vh/c3Pi+4nif/kb0V+rfQVHKOTY3znFUeKf+ vavV8s/xmxy7kQrjrOj4sKOhx1LPKtHensV/8E1jJXm6yfeMsNGKK1Zced83g5X/4JvByvt3 8NFHXKn+bfBWum6h65Y/+Ea45CpbabrVFba6wtb3fXO71VW20nQrTbfQdOsffHu7laZb3/v2 Nu+YPq83qYTv+0Y2arLqWnRosq3h+GNmuCEz3JAZbsg9veCeXqDUDnNc1RxXdfRg47u+z/n5 yY3f8ltE+UXq8EfU4fq/py6axapmsar7esHMVTVzVc1cVTNX1YxVNWNV3c8L5quq2WrIPb1g zqmac6rmnKoZpxq1uJvnXLnW+Iax7uDJrvyN0OFqHdF4P91Itw3ucb17XO/I+jfqb9Gvn379 9OunXx/9dtS/p6LhBhruoOEOGvbTsJ+GG2i4g4Yb3Ot6Gm6gYT8N+2nYT8MNNNxAw34a9rvn 9TTc4X7X07Cfhv007I/2oVov1Xqp1kupPKXy7nu9+85RqpcieYrkqZGnRp4aeWrkqZGnRp4S eUr0UiFPhTwV8lTIRx+yzpI1lqyx1FDjKGc+Wkc+Bsfiz+TLs+rUP+N5zxdhSSiZdwetJWst WWvJmm8HrSNrHVnrKFlDyRqy1pC1hmzjdzjr/9p4/+jeaJJKcCbOwsXhieiKcEd0JX6Eq3A1 NofHoi34DQYdszPMjEbwDn6Ld8PMpsNDV9MR+Dj+GH+CI/GnOAqfwNE4BsfiOByPE/BJ/Bk+ hRNxEj6Nz+Cz+Bz+HCfj8/gL/CX+Cl/ABHwRX8Jf48v4Ck7BV/E1TI4OavpFeLWpI7zU9CKW 4yW8jFewEq/iNawKL6UeCnekHsYjeN3rLN6AtaZ2IYSZoz4Q5o/aMzw2alzoGrU39sG+2A/7 oy/cMarsmK3YFu5oPgIn4Lwwv/kHOB8XYGp4ovkS0L15Zuhq7gwvNQ+HrpbDwkstH8PhOALH 4Fh8GqeHx1q+hTPCzJZ7MA99Xm/EJvCspT880fIWqn5W83o4zBydCF2jk9DfR49CM8yvo82v o/Xv0fr36LFoRRv2QAZ6+mg9fbSePnovfCq8NPpEfMfzszxe6/Fxj09ge+ga41xj9govRd+O 9hRxe2Ec9sY+2Bcfw+E4Ah/HH+PL+ApOwVfxNZyK0/B1/A2+if+BSeEpkfuUyH1K5N4STbFH mIpLcCkuwxXhadH8tGh+WjQ/LZqfTt0SsqlbcRtkRWoGZuIOzMKduAt3Q8ak5uAhn3sYj4Sn uf7UqLUhO0p2jcqjF33eL3gsouznW7HNe++GbHMzzNXNY5DGftgfH8VhoEMzHUTH083HeTzB 40keJ+DbOAPfwXdxXnhK5Dwlcp4SOU+JnFtEzi3N1ttsvSLo6dEX1LWJZpmp7sRduBuzMQfm rag+bz2BJ7EAr2EVfonXkcUb6MSbWI0urEE3ctgcFqkJi9SERWpCV2TPE9XA+0jsRvY+6sQy dWKZOrFMnVimTixLlUJXqh9vYQBl2DOlKjCHpsyhKfNlyjlTzplyzlT9c7sQwjL5tqhFLWiR +y1yvUWut8jzFnne8rf4Bk53zLdwRljWcq7XUzAVl+Iy/Ag34EbItxYatdCohUYtNJJPy1r+ 0eM8j894XAI6tNChhQ4tdJBri+TaIrm2SK4tkmtdcq2rxZparEnOLZNzi1roIe+WNf1plDKN jEIzWjAaY5DGWLSiDfW/OX1idGR0EiaFuWJ8rhifK8bnivGHxfjDYvxhMf6wGH84ujzaU5xP F+fTxfl0cT5dnE//L/wtqWOidmwOczg6h6NzOLqQo0s5upSjSzm6lKNLo7ejD3J1BldncHUG V2dwdcZ/1+/FJz4R7Z84OjoycZzHz+GLYW7iS2FO4ss4LdovMTksSJwTrk+ci/PC9Wa285Pf CjeZ285PfsfjFDuZqfp0Z5RJvhmNS3ahW5ftiQ5Kbg7Lklu8/k10eLLQ+KsO45NveRyIMqkp 0UGpqbgEl+IyXI4rcCV+hKtwNa5p/B2t6erFdPVi+n/172iJ9hmifYZon6HWzG38Tv6eYY4a M33UQLSn+jJXfZmrvkwf9U50UHMSYqt5T+yF8TgiTG/+uMejcWx0pJoyvfmTnp8X5qofc9WP uerHXPVjrvoxV/14WP14uFksNV8BsfTe7/p3hU3/x+/t138X/6thqUybI9PmyLQZ7/0drt// Da763966x/u/+/tbx8imGY2/wdXn+I3YBDEncxbKnIUyZ6nMWdqyNfpgSwVVx9f8XPzJoBn1 v9P1/+x39N//t77e97v29d+jT08Mc9LWlb4qXJ++BvImLW/S8iYtb9LyJi1v0rdjBmbiDlhv +k7chbsxG3NwD+7FffgJ5uJ+PIAHQZ/0w3gE/4hHMS/af+yV0X5jf4SrcDWuwbW4DtdjGqbj x7gBN+Im3IxbcCtuw+2YgZm4A3fiLtyN2ZiDe3Av7ov2a/3jaP89xkT77ZHG2Gg/0+IbsmBz 46+YvNH4yycHJS5VzTKqWUY1y6hmmcb/MWEM6v9fsrFoRRv2wJ6m270wDntjH+yLj8EEbQLI mwDyJoC8yjde5RtvEiiaBIomgaJJoGgSKJoEiiaBokmgaBIomgSKJoGiKjlFlZyiSk6JzrbT moxzcC7Oww9wPi6o/1t1/BAX4eJw+b9bUa8IE1TTCarpBNV0gmo6QTVNq6Zp1TStmqZV07Rq mlZN06ppWjVNq6Zpfbeg7xb03YK+W9B3C/puQd8t6LsFfbeg7xb03YLKO17lHa//xvpvrP/G +m+s/8b6b6z/xvpvrP/G+m+s/8b6b6z/xqr1LNV6lmo9KyqGclRCP97CAMrYigqq2IYYg+E5 lX2xyr5YZV+ssi9W2Rer6tNU9Wmq+jRVfZqqPs1MnzPT58z0OTN9zkyfM9PnzPQ5M33OTJ8z 0+fM9Dkzfc5MnzPT58z0OTN9zkyfM9PnzPQ5M33OTJ8z0+fM9Dkzfc5MnzPT58z0OTN9zkyf M9PnzPQ5M33OTJ8z0+fM9Dkzfc5MnzPT58z0OTN9runUaP+m0/B1/A3+Fj8JWZ0oqxNldaKs TpTVibI6UVYnyupEWZ0oqxNldaKsTpTVibI6UVYnyupEWZ0oqxNldaKsTpTVibI6UVYnyupE WZ0oay/Rbi+xzF5imb3EMnuJZfYSy+wl2u0l2u0l2u0l2u0l2pt+GaWbXkcWb0RpXSyji+2h i2US9js6WSZhT6ObLdbNJulmkxrd7FuhnJiEyeGe93e1xA8af91lgs52js42QWer/5WkZ5IX h8eTS3SxpVFbsiPcmHwjPKvLZXS5tC5X1OXSybVhk063cPffLjqo8Xcu3/L+QDRKl8vochld LqPLZXS5jC6X0eUyulxGl8vochldLqPLZUzSRZN00SRdNEkXTdJFk3TRJF00SRdN0kWTdNEk XTRJF03SxdQ9IU7di/vwE8zF/XgAD+KhMEHnnKBzTrDvarfvarfvatdF07poWhdN66JpXTSt i6Z10bQumtZF07poWhdN66Jpc2ZszozNmbE5MzZnxubM2JwZmzNjc2ZszozNmbE5MzZnxqnt oZwaxg68jZ0YwTv4LeSEzjxNZ56mM0/RmbM68yz7v5z9X87+L2f/l7P/y9n/5ewS8nYJebuE ol1CXgefMGpLiO0U8nYKeZ18ik4+ZZR7GuWedPQJOnrGriE/apfXIcTNEZqQQDLK6PQZO4q8 HUXejiJvR5HX+TM6f8bOIm9nkW8+wLEHYrz3Pur1YVBr7TLyJoMJJoNM8yf8/GiPx0bj7Try JoQJJoSMnUfeziNv55G388jbeeTtPPImhykmhykmhykmhynN6mizOtqsjjZfjCmYGi43TVz+ 3jShhtrP5kwSWZNEtvnBKN38TLR/87N43vN/8fiyx87QbsrINvPSvjfXXP+LnAeGrIkja+LI mjiy9sLt9sLt9sLL7IWXmUCy9sPL7IfbW06K0vbE7fYFsX1BbF8Q2xfE9gUFU8pi+4LYviA2 rcwyrcxq+ftQbvk2zgjT7A/ilvM8l1Mt5+MCXIgfOudFsC57h4K9Q2zvENs7xCactAknbQ8R 20PELbc4/tbGXzaMTT1p+4nYfiK2n4jtJ2JT0DRTUNoUNN6+IjYJTTMJpe0tYnuL2N4itreI 7S1ie4vYhDTLhDTLhDTLhDSrZYtz/wYFqPUtar2p6TlT03OmpsWmpsWmpWmmpVmmpcWmpWmm pbS9fs5eP2evn7PXz9nr5+z1c/b6OXv9nL1+zl4/Z6+fs9fP2evn7PVz9vo5e/2cvX7OXj9n 6sqaurKmrqypK2vqypq6sqaurKkra+rKmrqypq6sqStr6sqaurKmrqypK2vqypq6sqOPcU/H 4lOhffSJ+I5zf8/rSTgTZ3nv+x7PxmScgwtC0YSWNaFlTWjZ0df6zEzvP+7YJ8Ky0U96vgDb Q25MFO1vgsuOsbYxe4X2MXtH6fTfhK60fWH6m5gYJpnsJqX/3vPLQjl9Oa7E7ye96zz/MW6M Mia+jIkvY+LLmPgyJr6MiS9j4suY+DImvoyJL2Piy5j4Mia+jIkvY+LLmPgyJr6MiS9j4suY +DImvoyJL2Piy5j4Mia+jIkvY+LLmPgyJr7M/8eJL/NvJr69oxnhC01nRKc3fRf/EF3W9D+j f2j6XnRq06RoUuKL0ecTk6NPJ78RvpmcGE5Ltof25NIwKbkpdJkNxyW3NP7G6yPJUsgm++2l 3rLfGgjD0cHRjF2laGHYEr0Utjj7Z3b/RdpTnf1kZz9591+SHa7/rWhX2d9V0q7yGVeZ4Cp3 JH8WXkv+HEtDOvkLjx1hc/JFZ18eHnL1R1z5neRvGlf/mqvf7+ppV1/k6l3R6GTWEZ3uyU4+ udq9d4VXk2u816MjrnVEq3tb5d5WOfK7emfW0Y84+iZH7+3ohY7+pj66zCeu9olp0SH1vy/p bh/Wzf9E956cOEUnnxxuS5xf/7ed0SGJ5WFq4pXwSGJDdFJiu/3oOPPzUeGF5M9036XRJ6xg pSu124+mk6sbe9GsLp1x9nesqE+nvml3p07v3pOmrSxO9ltV4y8NhmrT30WpMD8ahWa0YDTG IF3/7Wy0og17IGNn/wGcGLLRSZgWbo6m48e4ATfiJtyMW3ArbsOM8ItocXg+ag/PNyXMP0mk MArNaMFojEEaY9GGD0CfbNoTe0EtaVJLmtSSJrWkSS1pUkua1I4mtaNJ7WhSO5rUjia1o0nt aFI7mg7Dx3Bq6Go6DV+H3G6S201X4Wpcg2txHa7HNEzHj3EDbsRNuCO82jQLd+Iu3I3ZmIN7 wquJT4SbE8fhcziNezeHbOIWziwNX+dKWZwNi7FnOVH+3d989Hp414vJHWFc8u1d+eTOXV3J kV0Lku/syiV/u2tx8t0wNrnL+2FXOTVq14up5jAu1bIrnxq9qys1ZteCVHpXLjV21+JUaxib avP+Ho6bEuanpuISXIrLcDmuwJX4Ea7C1bgGZtuU2TZltk2ZbVNm25TZNmW2TZltU2bblNk2 ZbZNmW1TZtuU2TZltk2ZbVNm25TZNmW2TS3Cv4au1GK0Ywl+hp9jKZbhF+jAi1iOl7A63Jzq whp0owdrkcM6/Aq/xnrkw82j3gnzm5MQv82jwsLmPT3uhfH4OI7GseaCT3q8LXQ1z8G9Xltn 82OeW0+z9TRbT7P1ND/jvf9F3ZfAV1Fk/Z6q6tvV997umxDCEsCwL+qHM2QYfaPiNurMiIqM yyAoooArbhAQkUUcHUGRTQUURBDEGeMgoyICsg2K4BI2WUTCkgAhGJYGEpZA6v2rbhPCEiAB ed/r+zvd1dW1nK469a9zqrvPnQL6BPQpaBpoOuJngGaCvgSBdxu8298i/B3oe4R/AGWCFoNW glapRfYaXMsF/QLyQbtBe0B7QQWgfWq5jIESQImgSqDqapFMAdUA1QTVAjWHnnIZ6Gk1UHYF PQ/qDxoGehc0Xn0mM3DcpwY6jdVy52LMcZfg+FscbwW1QvhutcjpiOudQJ1BkEdnFOLfAr0N Gg3KABWpRWFSy8OVcMT4CmNchTFHhzE/RzqCHgV1AT0BegqUDsJ4j2C8RzDeIxjvEYz3CMZ7 5DXQYNAQ0FAQ+I0MB70OegP0JmgEaCRoFOgt0Nug0aAxoHdAY0G4x8g40HjQe6AJoIlqYPQm lRltCboZdAsI9xptBboN1Br0nBof7Q3qA+oL6gd6HtQf9ALo76AXQS+B/gF6GTQANBD0CuhV 0CDQa6DBoCGgoaDhoNdBb4DeBI0AjQSNAr2lxrsXq4GxsBofi4CiajxZQP8pQP5csQJz2SrM Y29SL+Dnc6DeoD6gvqADwNKDoCLQIdBhYFUT5cN+9mE/+7CffdjPPuxnH/azD/vZh/3sw372 YT/7sJ992M8+7Gcf9rMP+9mH/ezDfvZhP/uwn33Yzz7sZx/2sw/72Yf97MN+9mE/+7CffdjP PuxnH/azD/vZh/3sw372YT/7sJ992M8+7Gcf9rMP+9nX/sDYApUFmzUfNms+bNZ82Kz5sFnz YYe+Dzv0fdidWbA7s2B3ZvGJKhsz2iTMZFt5odrO96nt5sumebA7F2M2WqKyMINNgg2XARsu AzZcBmy4fNhw+bDhtP2UCfspE/ZTJmwmHzaTD5vJh83kw2byYTP5sJEyYAdlwE7JgE2SARsi AzaEDxtBexD1YQfkww7IlxepLHmx8QaqPYFqXT4TenYmdOtM6MKZ0IEzof/60H996L8+9F8f +q8P/deH/utD//Wh//rQf33ovz70Xx/6rw/914f+60P/9aH/+tB/feir+dBX86Gv+tBRtYfO LOihPnTQfOidPvRNH/pmfjhZZUHHfB865vvQKbOgU2a5fVS22xfUT2V7yWq7VwVUFVQbVAfU H/ETzNtNm9QkzOvQMcUM+p2YSR3FHGog5lINtO/34r9URcynxiKTWqKtWxq7fhldC9s+QfxI aWj3fL2KDT0nG7E51BT6Qkuzhq2/Z8iD1hJfy05DTfPUdKSfbuqcgmt9SaC+JohbrlNSlN1G EdYa9FfQ7aA7QI9QGqy3CKw3bblFYKVFwvpfVy3wk4rRcaXxiYz5EDzEY1IxW+YitglmywzM lsuNPghrHDXnQBPKo2vNmqJOmwYe9P8hbAHHcf/Jxqu01on0cxPjf66NWirS0TbzIEMtKAF5 26hlOFuL1LOgC85VBTjLxlkX5JurDuBsGTUmC6WHQDZIghxQGBQBRUEuyAPFUOOdVEm0Vd+I 9qAuaMWZaiVKWo+SlljplGZ1B/UAPQPqCXoW1Av0HKg3qA+oL6gfpcGWT4PNngabPQ02ehps 9DTY5Gmwv9Nge6fB3gYvhtcZ0Olmoq1mqY1iDkbRXPUTapwJ7XYH7j2dLoZMVMJVX8sC7j2Z ktgSuoAtpYbBe2mdRVukintqvlh7ahZdzDdd34ke0G9H0IViJGiGykNP14Mm84n1B7rIupwa orXaUQw5YqjnN+jNdPTALLUDNX1navJQwy+oIVPcg/rvhQbaAcf7cUxHLUvUWujI+dCPDxn5 WUkh5IqQrf+NBalTkDIFKVOQ0keKAqpKOUBR6FC0Oe69z9TYA0fgBHo9BMRdjfL2AnULkMPX ZWqNOJSkCmHDF8KGL4SNXAgbuRA2ciFs5ELYvoWo807caxuUko6ey0QuXZpeMa12TJ33oPwO oMeJmboXo+WXIH4p6luGdl4OyVkBzXwlRc+o3mhQbzZKS8BdFKHEbJSYjxJ9lGgHq28hM3/E kNoXbQwfWeAjS3Q1fVwfHEuhPTfHeSlEzih4KUJubaH4dAnl0GW0CbQZdIAa0UFQEegQ6DA1 QskdjLV0D8bZvXSn6IDj/Tg+DkumK0ruoeaL3ujJEZD0kRix0HrQRg1M3yxTn5jaflSrMOaS YeUcgoykQUbSLJRtFYMUNQol0WWyLagdqD01kiNBE0EbcL4RlA0Cn3In4vbiWAjewuCsEBw1 BTdNca/JQe9gdsUI0H28CjKjJW0O+J+DlslF6mS0Ti5yJCNHGlKHwed2tMwe8OqD1/26XU2u TCOf6CPIcn2M3ULIc33RHUiYTdXi+jrkNRe9o7/TylPzzT/56D7LQqoIYgrAxxEPccHbMaIb ZOQZjP+tkIc8tL8d+LTPRR5gG+5gCyhPZVEKdQInnUEPgrqZfzAoBD+Z4CUTqZNN6hzUaKw4 XMsDIpp1V8yLLSg1lKhyQ/mg7SrX7gJ6HPQE6ElQd1APlBsL/hdBe+LMQslZohvuqDvuNBv9 lqO24U4PxO9U7QPXRahlkbG9q4E/H/z54M8vGSVtUVJ7UDfw1h39ko2cOeBd29Fxa1Pf3Qb9 H0jgzwd/PvjzwZ8P/nzw59v6mUpTguVOnUEPgnrh/DlQb1AfUF+UHP/XpAuBUbHAD71GnGuB USPRylPRyl9BLmdALq+EXN4oPoS8ZoOzHNyb4QbzVC76bKvKgkxeBpm8zGqhVlvvUlNrHGg8 NQ0l0o2hDTjm47gdtIua2hfqZ5+gLnSj/TjoCdCTIM2fE/SRlplQIDMh01dbjET4ZvUhA3xP ClKlBKlSwLePlGmGN93/tuhS/IHYr3bC1suypNoJWy7LalK8EDx3Kd6A2ELEFFpN1P+g1C7F q0QheqoIuQ+hpMMq2wqpA1ZEFVnQR5AyGymbmbyTcXU1YlajtAKTN1McBE7ovIchDQp5wiRN Xhc2WAzHJiqVkpByIWopglXqg7N8od8KL0Kth9RB5FyKnIWotQjWqA+O8y1oRSjlADg4iJKW oiTwW7wRPdUFdmy8lAKUUoRSijXPpu547gLkLkLuYsN7nIcQVUXOLuAhW+xDm+3H8QDaD1py cOerxWGM6WK1GSUdAC/Zlk0pKC0bpRVaYczy8RbB/VPY8tRmlHwAPL2mZ83ibJSo2yBXFGPO keb+cy0P4SaKTIqPTY8cNKnivRI2qXTPLEPrHtdf0CeCfkLu0/SPSWv6BWlP0x+UeLb9QG55 2x9SfI7bHTJeRnubKydtZ4pZyeRYVVBqdYpYNUA1kacW8l+AMLRVqzau1UO4AaghrjXCtcZa q7SqooyauFoHx4a6DaxknMFmsKohTQ1z1TdlpSK+NsJ1EW5gUvu6HLJN6uqm1gKTop6ppYCS wFcIV/OtqoipBqpOqeAvASnzUWYq+EO5oNo4r4PrdUH1EN8AaRoirhHCjVFHDKXkgld9hyEr BbXXIBGUonPngn99hyGrPq41wLV47hAlgocIcm83d1od5dZAqppovVqIj9cfQQnbTQvUw/UG iGuI640Qr+vGXaD8KrhaVe2yqul7hcQZHtCXtVDvBYhLRZraiKuDNHV1GyCN4QVpGiFNYyCd 7qcE067VKTnopyLwkQw+YuAjwbRtPZzH+6kIPCSDh5juFdN6oSDX3mO41/cdz7G3hOuEisoE Ru2PCB0nFxjttckrr2wgV32M0jLkA1c5VT5XMoLSqiCmgnKC3C5VOltZQSlV9R2dG3lBT0w0 /VghmTF35JVXblDnfmizhcVLgYVNgTgWUK2ZOFg8G6hWUxwqng/0+YMoLi4CqiVaoeKlwMam QCMLqNbMChfPBqrVtKLF84FMf7C84iKgGsZg8U9okRpoEQ8t4lnVixeiRapYNYq3gKsGaBUL rcKtVKSrjXR1kKYuqB7S1Ue6BkjXEOkaIV1jSE0YlloCbKwbhf4XoflGq0+GlpsKrSJNr9tD 20sx/2Q0g7WnK1gHupHdT6+yB3DsiFz6f4fuUl+Lv0EbaqPGmH/Hu/AUqb42qY7849KYkrMp JWecebCAmxLR5XQ1XQSb+1r6LbWk26kZ3UV/Q+zd0NuupIdpEN1Eg+lDepJm0GyczcVvGH1L K2k4rYbN8S7lsgT6N6vJatJKlsqa0ip2M7sFsa3YHZTH2rJ7aCe7j91Hu9n9rBPtYV3YE7SP dWej6CB7G79UNga/2mwsfnXYv9iHrC6byxaz+vy3PI39jjfnl7FL+eX8cnY5v4pfza7gf+TX sxb8Rn4ju5r/mbdk1/Bb+C3set6a385u4HfxNuzPvB1vx1ry+/h97GbeiXdmt/CH+EOsFX+E P8Fu4115D3YX78lfZu34QP4ae4wP4SPYU3wUf4v15BP5f1gv/in/mg3g3/CVbDRfzXNYBt/K f2HT+E6+i83ku/k+Nosf4EVsPleC2ALBhWALhRQe+1YkiCS2VCSLZLZCVBU12EpRV9RjP4sG oiHLEo3FhWy9+B/RlGWL34jfsE2imUhjm0VzcSnLFZeLK9g20UJcxfLFNeIatkNcJ65jO8X1 4nq2S9wiWjFf3CHasL2irejIDogu4nFU3VU8w0Oit+jNo6Kv6MtdMUKM5J6YLCbzBPGZ+Iwn imliGq8kpov5PElkilX8ApEtfuGNRaFQvJkVsmL8CivZasJvsFpYLXhbK916mbezXrGm8iet L6zZfLT1g7WYv2ctszbz962tluLTQ5FQhC8NuSGXLwslhpL48tDy0E98ZWhtaAPPCuWEcnh2 aEtoC88JbQ3l8U2hX0K7+JbQ7tBunh8qCO3j20MHQgf4rlBRqIj7ocN2iO+2pR3jRXainSiE nWRXEZZd3U4Vjl3X/p1IsH9v/17Usy+z/yTq263sO0Vz+177BXGF/aL9D3G/PdB+VXSyh9hD xEP2MHu4eNh+035TPGqPtMeIx+xx9jjxtD3BniC62u/b74tudob9qUi3P7e/FH3sOfZ/xYv2 AnuBGGAvspeIgfZye4UYZq+yV4s37DX2GjHCXmevFyPtXHubeMv27UPiHUmSi39JKeuIj2Qj 2VwskJfLFmKFvEZeI36Sf5R/EmvkTfJWsV62lq3FJnmHvENslnfJv4ktsq28T2yVHWUnsUM+ Ih8Ru+RjsqfwZS/ZVyj5vOxvWfIf8lXLlkPkKMuVb8u3rapyjBxjVZNj5btWdTlBTrRqyAw5 06ol58tFVlO5VO62msu9ALm7nEZOI+sBp4lzkdXRucT5jfWg09xpbj3s/MG53HrEudJpYT3m /Nm5yXrcudm52XrKudVpZT3t3O7caXVz7nbutno4HZ2HrGecJ52nrd5OL6eX1c/p4/Sxnnee d16w+jsvOwOtF51XnUHWy84QZ4g10BnuDLdecUY4o61XnQ+cf1rDnAwnw3rdmexMtt5wdjt7 rDedAqfAGunsd/Zbo8IAM+utsBW2rNFhGZbWmDA2651wQjjRGhuuHK5ijQunhFOsCeGa4VrW xHBqONWaFLk90tb6INIh0sH6ONIp0smaEnk48oj1n8hjkcesTyOPR56wPos8FXnK+jzSI9LD mhbpFellfRHpHelnTY+8HPnImhWZG1lo5URWRNZa+ZF1kc3W3siBaA3rULR+dGgoNTo8Oj40 KPp5dHZoTHRxdHfofVe61UOL3IvdG0I/u23ch0OF7mPuU7Z0u7rptuf2cHvaiW4vt5dd2e3t vmQnuwPcwXaqO9Qdajd0h7tv2I3cEe44+0L3Pfc9u7k70f3I/r37sfuZfZU7zZ1pX+/OcmfZ f3HnuHPsm9x57kK7pfu9u8y+3f3R/dFu6650V9vt3DXueru9u9HdZXdy97j77XT3oHvI7uUW e2T38bjH7ec9y7Pt/l7Y8+wXvUSvqj3Qq+5Vt4d6Nbxa9jAv1Wtgv+E18hrZo71+Xj97jNff e8l+xxvgvWa/5w3zXrf/6b3pjbAzvLe8t+x/e6O90fZk7x1vvP2xN8H7wP4sxmMxe3osKVbN XhCrGbvA/j62L3bQXkw8/AJmFIrOSPySGlNtOiebWqfWU1NYVqSWnvR6kRqsJuNXqHri7D7V WX2kpiKUba5mq1zsNwZpC0/Ira/mKh+/o9eST0i1E/TiaTkdAPpPqfPVKL2KrqHMLaIOau7U HoT1O7J/okY4zyopYWtJKPsk9S1Va1We+g6/bLUL2vrZbtVQ5jhTco7KV4uO1K7yT6g537Ra vspC699PNdFiF2rOg6tFp6tIFagdarfaqjaXRFVG7A5z7TP0XoL6HKFNJ82LVGo7ai9UeaRb LZXq0zVx7nFlpVoJaVmvQ2XUPVaN0XepuoNuVdep/uplhNaXXP+l9F0el7cIbb0Odc9TX+Pu ffRUKLjy03EpF5y2DfZSIGlqqNn7aidKD6SwVMscSV+AFtut9qsVSHeTudsr0PIBl2qb2oZ9 XpB2/wm5d6LNtmgZCcZFIdUwx+Vl320ZfGcdc/ZYqfCXZ1YCtkuO1ogeW04hteI0teoRuC04 uYianzLtJPW2lhMtQ+Xf1GZ9h5CutSdc2XjavLtAfzehj47vQY1Op8mdA5phEGnN0ZF/phuk usDsl5/kYsIZlbAbtKG89QZ55wbHqRXI+47ZL9D3f463y09b99Z4v6oDwNId5Sz91K16GehO U8fG+D7+C66ebHa8EL/a+F14DIeTzH5x/HeK3M1OmnuL2W9Xe4Fde8tiFdc0qm1TP+txqPPE MTw+5wHtvlLfqm/KzF1qVlUDqS4Q+RZqhfC/TMxyzFNfqtVl5i41b6nhmAdS6AZYnhhBJuZn jIWvjqJzWXXrGRRypHM3h9UaxKvpahrm2DJx6SjWB1sC2q8t4p81V2epL9RcNTtIu/2E3KVm drRUgpmH9Kxys4n5CrXPUDPKrLsMvaBYawTfqbtVa/WYujNIewKSqYFo14XqB7X+GJzh1J7+ DgudYK8P0V+d0Efk0mSaRk1oJmz3NGO7X0rzYbtfRj/Bdm8JK51RG9aBdaBusJ7/SunabqYe 2mKmZ/ij/HF6FrbvaurDf+brqC/P5jn0AuzgrfQi38Z/oZe0NUwv80K+jwbyIl5Er2prmAZp a5gGwxqO0lChfRK9Ke4R99II0UHcT6Osz63P6W3YkYpGh5JCSbTInmpPpW/tWfZs+s7+2V5L P9jKVrRY20+0RNtPtELeJlvTGm0/0VptP1GWtp9ovbafaLO2nyhX20+0VdtPVKjtJyrS9hMd hv00jAn5uhzFbG1FMVdbUczTVhSLaSuKJWoriiVpK4rV11YUu0hbUexmRzgh1sZxnAhr57hO jLV3KjmV2f1OFaca6+TUcGqxh5xUpw571KnvNGSPO1c5V7OnYDl1Zl1hIQ1g3WEhvcqe0TYQ 66ltEfastkVYr+hz0aGsr7Yw2BtuoludfeF+5H7E5rk57i72X63jsyVax2crtY7PftI6Plur dXyWpXV8tkHr+Gyz1vFZvtbx2Xat47NdWsdn+7T+zvZr/Z0d0Po7K46FY1EuYlVi1bgd2x87 yMOQmxVGbpiRGw65GQFNfiS9Df1mNE1EzPv4SZpEH5JDGZAq20iVDan6ksI0C7IVMbIVgWwt Qvy39CNFUeoK5F2JnwdpW0sxyqJsjLEcSF4dyiUfo2Y3fnVpD+2jerQfv/p0gA5TAyqGXFYy clnLyKUwcukauXQhl10okT8O6XSNdCZBOrOoKl8HGa0MGc2majwHklrTSGoNI6nVjKRWMZKa YiS1MldcUWVBkNdkyCvHHhtVgdRKhNHtVF2EIcHJRoJrQILvoYbiXshxI8hxB4TvhzQ3MtJc C9KcRcxaZ20mbm2xcsm2tlo7KGrttPbSBVaBVUgJ1j7rEKVahyH3DYzc1zFyX8vIfS0j97WM 3NeC3P+RkuX18nqKyhvkDWTJGzESQhgJNyGmpWyJmJvlzSTlLfIWcuStGCH1MEJuQ97WGCdh M06iGCd3kSf/htESw2hpR3XkPfJeSpDtZXtqIO/D+Klkxk8lM34Yxs9jyNVFPoU0T8uuiOkm uxGX6bI7aukhe6DkZzDGohhjzyFXb9kb8X1kH6Tvi1HnmVHHMOpeRpoBciDqfQUjMAEjcAhi hsqhyDVMDkOa1+UIxIyUI8HJKDkKMRiZFNEjk/TIHItc78p3ET9BTkA5E+VEpMyQGYj5SE5G 3o/lx2iHKfIztMxUOR18zpAz0CYz5UxwNV9+DW4XyEUoc6mETMoVEtIoV8k1KO1nuZ5qyw0y B22ySW5FXXlyG9WVv8h8tOR2uYPqy51yJ2rcJXeD571yL1IWyAJcLZSFiN8n94GT/fIAyj8o D6LkIlmEkg/JQ1RZHpaHUXuxLEZeJRVFNY5QLY0j2ANHsAeOYA8cwR44gj1wBHvgCPbAEeyB I8SAIy9jP8AZQFyjCVkaTYhpNCEXaNIb+z6RfpSoMYUEMGUludFV0dXkRX+K7qZEjS8kNL5Q deBLDlV2N7mbKNnd7G4mz93ibqGqbq6bi6tb3a1Uzc1z86imu83djvAOdwfS73R3Is0udxfS 7HH3ILzXLaAUt9AtRJp97n6kOegexNUi9xBF3WJXUTUPw58qa+TC3vIs7EOeTUnArwhV8aJe FGlcz6OawLLKiEn2qlKKRjSqCkSrgX1NrxbSpHq1Kdmr49VBCXW9egjX9+ojfQOvAcLAO8QD 7xDzjjcW5b/rjUOu8d54lDzBm4gy3/c+oCoaAckgICVqBKREoNS/AwQcip8oQcBRCI8G9gmD fSEg30cIT6YvsJ9OMwwCzkX4v8A9QV8D+wSwbwWwciWtQng1ftJgnzDYl2ywr4rBvrDBvqoG +6oZ7KtusC/FYF+UJbAEcllb1hb7LgxIx55kXbFPZ+nYv8JeAfa15q2JG2R0gIydsNfIGDHI 6Bhk9AwaVub5XP9vhEbASgYBk/hhfphiBvsShCUsqgTUcxCOiAgliraiLdUU7UQ7usCgXi2D eqmivWiP+PvEfYjXCFjLIGCqeEB0pBolCJhLAti3lyRQ7xCFDd6lGLyroldFMT6vk9eRMLgm gWgtsddYJgyWhQyWVZOtZCvEaCwT8nZ5O/Z3yDuRUqNYFYNiYYNiKUCxDhjbD8gHsO8oOyJl Z9kZ+4fkQ9hrRJMG0cIBoqXLdMR0B6KFDJZJ+ax81iBaL6TXiCaBaP0QjmPZC/LvCGtEkwbR hEG0sBwkByHXa3IwYjS6SYNu0QDdhsvhJAzGSYNxKQbdhHwHuCYCXBsnxyE8Xo4nW74n30NK jXTCIF1KKaQTBukkkG4GwhrdpPxSzkN4vlyCvUY3CXRbg7DGtWSDa1UMroUNrlU1uFbN4Fp1 g2spBteico/cg1wa3aoYdKtm0C0lQLdDQDFhUCzqMIeRiONRpGfkWXIiz0Wew75PpA9FIv2A PpFI/0h/xLwUeYkcg0Q8Ojz6FnGDKZXd7UCTBNd3gacGQRIMdlQGduxDeL97gGJAjWKMZI0a iZ7wBMWAF5I8gxeVDF5UBlIkIayRIsmr5lVDGo0Rlb0LvAsQXxsYkQSMqIsSNEZUMhiRYDAi 0WBEJWDEOyjzXe9d5JrgTUD6iUCHSgYdOPGmbfRqZrODV74Ii+SOsvT4/82b2q2yNZmwf+zK TUmaQrX5lGuUZZWtV2TXgRaZs3VH4rT1YlYHi/QKWXy9CFz4x65glm0PBteXBccHy8/ZudpU OzXGHHefUepslamtvTNdRyuznPxjw3qdtWStbDesvmyVpVtTrSpJdbT3gpVr0+baG0AqJejU Ju6Ete9fdYsEnJSuNYGuMnEbju99tePE9S5Izw9qkdpXEdk8/aaWBMecQJJ3lbq25wj3houT 9Kdae/KxdE44K3fJapwaaY6FagkkYzFosnpDLQv6vYR/s7K4BDK0sELjPZ9KPYWIPzcpdXWQ 2gUcyQ9adKvmpFTmI9JQcAb17KeTPu042w09eZT7vWirHSC9arTvmFTbTsz5v20rWfPKOzNZ OVtEOmXZJ1ttLjv1AjVVfaWmaJxCOL6yuTxYo8wrSbXlKLaVo+yf9fplgH3bzBMgHwiin4pM jpeP8/k4fqMJ4WPWM1UGaXxKO3JXQN3lQKmrqa5aFX8SoHJUpjkOPrLCd3Zb6adb8adH6t8l 5++oR9VA1UHNQfiektjrVBc13cw0x7X6yVAKdzBDzYGMl7l2WkG+dxukCbjXnJgWLz1r+aVX xtWaU5a28NxyV54NaBQ8f1Ppx135Sr1UEi6ZwSARGi82YWY95T2VUZtGTN0Xpm2MfG4L2gl7 1d3UI83z4ONn6mTzllbpsrQGsA5zVkSXFOgGB4Jr/una/Ax4PYqUpZ6CHcHGuD4CjM81dR0j eWa85Z4wv+dX9LlSRbe4VlrqvEztp/QTzFKxM88tP6VKvrMcic1zHjUgeKZYiBG9RT8hVFNU RvxJ4THzux9I2efqkwrw9SX0gmlBeCEw2jzP1eNTywB0jOzgmUqhQdbVgXYRR1HvuLLmGOyZ anB+TvwZiPr2mBSHy89hkHMZlXraHiDnMoNBc0wYWGhwc15cCuJPJOOjI7hyg7renM1SD6Il HwW9oF7D8VMT+9UxtX2KVk9Xf60An0+qMRq7cf8bEWqHUH9YCGPUh5gDh6rWari2GBCrbYaP 1YT4mFEPmczJR56nBmUtx2iH5k9NTDhuZQXal36qZ94f0fJRgXdAjNSUPNmOz8VBOIsC2+eo HUfH6mZ1jn/v4dffSuuQ+pmc2q5n/VPmOE6/Pz/bMc81zZN1tf3Umphp5fNrpVHp9oT87Dd6 VMGp7QODMRXgs+znz+Uo47y2jxqrXlSDVQ8TzoY1Okm9FVzJVz+a43Yg8fajmluFarlOjT1L Pn+G7ZUZrMRsUivV96XeITN6NSyexWpPyfsDFavlNGs2p8ybo3VvHItB30M/D2YD876BfrfH aPxlvbN1/jagdgelfRpXN2fP4LwbLBVjOesWUEVqmhqmLscckgkMH1exnlOjzKH+WXEa79f5 wVlgxcZXAqiUNXX2Wzne6yqrhF2mBTUO50FfPaGXcX2NtvrOta1S3g2aVR64iNuj2yCnu0pd M7MM5Ph7jLBvT5r9vG3gM6P0uyvApfn/77g52aY6q3s0Qmp7BvvBOJ+ifjDhwOKDHExTt6lB pO2vDRWTsfPdD5COA+e3xvJtR1Bf/XLi+6PlKOVXXQMLNMp8zFk7z26dr6JrB/r5xBmm/Ni8 bXz8W2Ll3eqeZf4z3jDHn8Vanxp27jgpo4YA39WOs+n5czm3lVlHljp4vtcsyr+pL4zNcLbt 0ficMPOrbWf7ZQNmmgo8rTFrySWrX+Yd4SNjK1L2KDM6cn1qS7ICNeZXBLV17x+114K1wDN7 e9w17yj//7ClVCSTXsOvQK5lpWcW/R0H5qnCX+cp5K+xQX/de/oZSx2qQMnLK/KGvtH88445 O9KW4VPk0hKcQi0ho+d509ZoSTjP2AEbT41AZj38PK/blObyrMrZGNDXJ1y6MPiWILnUdwfl KXkx2m3xkVp0yNCRbyGO1HeFqekYfkqdvXy0tIAmxY+lNv3NQzN9VDPi72uUk89JyDcpCJuQ WfueEdzDEQ6aHcfnpPLXVJJ3w8m/ZDxNrp9K37ku4cSnL2VuFVppQC9tOX2qE3LlBePdPPM3 z4OOvE8ROcUXKPo+Uujaiox3teV0K8AnzbUmoPhTDb26vYOCpxunyBVfLU05dvyp1Wqr+drz QqqFo3k2itnHaB1Gmu4uP3+n5H2e2ZfY/KqX6qDGq5Hm6fDRMdNOvWeORSe+d3GSLwR9tf3X Wc03b4TEn1Wtho6zHNbpaujXJV/GmCc2eiX/GnWXOf9WdUWqR9VC3NE09VSwrnnMMy0zj3RW t1aAmy4otVUQNiHz3fBINVXNVW+q+9RXRiJSzJPtZUcsKvW4jqOG+umQ6qaeNHGFaPP1ahzu Zaqaov4VPME5Zg3LzA1D1OsV4HOiWlCymrdAjcf+w0AfyVGfqNcRtytIGi5l+ccRsEH56zvf 2/l4ImOkKv6+wgnyfh5qz6rQ87g8KrUCE0jf6cupBEqiG024AfT6+lRP3z9Glv6Hn/9DTYBH 2aBcjL5cjJybgRMJ6ncmfbSktj7qxiAYf/L8Vcn3nDL+9kuQ7osyeI8j3kjgvZlxVD/VWj0N eonqqStMkgDfzRfYLdR16iF1L0KzNIG/cepDtci8exOvrQ41ohiO5ttySHzGadvhRJ6mxCk4 m4F7KvUcI3i7Jg2aZm3S/8V35Dvy2aXSVC3erVz1R7UJuDRHPYkyRqnBuK8Z6rXSrUJHvud+ IY4P5eTzWchL/BvhEEJPqkfUa0aGVps3Pr045peyhMyX5/E3A85YDzi2xm0nftN4Brn8YOwa C9c8u9lDtrmUcIr5XedIoSvR/5y+Po3fobaB36EX6C+MsyrUyfgU6ml8Cg0wPoVeYW3ZvTSU PcIeoTeMN6E3WXf2Co1ig9hImqx9CtEM7VOIZmqfQvSl9ilEs9g8tpjm8N/yZpTJm/NLaYn2 KUTL+dX8avpR+xSiFfwvvCWt4l15N1rDe/JnaS0fyl+ndXwin0jZ/AM+mXL453wa/cKn8+m0 nX/JZ9MO/hX/mny+iC+iPfwHnkl7+RK+lAr5cr6c9vOVfCUdEK7w6KBIFEl0SPsFImX8ApHx CxQSDUQDJo1fIMf4AoqKS8WlzDO+gGLGF1Ci8QWUZLwAVRZtRTuWLNqL+1hV/e0Fq6599bAa 2lcPu8SaZs1mbbWvHvaA9s/DOmv/POzBUGKoEnsolBxKYY9oLz3sSe2lh/XQXnrYc9pLD+ut vfSwPtpLD+unvfSwl0IFoSL2D+2Zh72mPfOwEdozDxurPfOwd7VnHjZBe+ZhH2rPPGyW9szD ZmvPPGyx9szDVmrPPOyQ9szDlPbMw7n2zMOF9szDQ9ozD7ftcfYE7mqfPDxR++ThlbRPHl5D ++ThdbVPHt5Q++Thjezl9mp+ifbGw5trbzz893au/Qu/THvj4Vdqbzz8z9obD2+pvfHwztob D0/XX2Pwng53OH/WsR3JezlRJ8p7OwlOIu/jJDvJvJ9T3UnhzzsXOBfwF5y6Tj3+d+0/h7+k /efwf2j/OXyg08xpxl/VXnT4IO1Fh7+mvejwIc61zrV8mPalw4drXzr8Te1Lh4/QvnT4KO1L h492HnQe4mO0Lx0+1kl30vl47VGHv6c96vAJ2qMOn+gMdAbyD5xBziD+T2eIM5T/S3vU4Rna ow7/SHvU4Z9ojzr8M+1Lh0/VvnT4NO1Lh3+hfenw6dqXDp+pfenwL7UvHT5L+9Lhs7UvHT43 nBKuxedrLzr8G+1Fhy/UXnT4Eu0Vhy/VXnH4Pu0VR5D2iiMc7RVHJEbviHYUafpLDnGd9ooj bnKlmyBu1/5wxD1uO/dh8Yz2hyNe0v5wxKvaH44YrP3hiGHaH44Yrv3hiDHaH46YoP3hiIna H474QPvDEZ+4E90M8an2hyNman84Yp72hyMWaH844hvtD0cs1P5wxBLtD0es0v5wxGrtD0f8 7G50s8VG7c1G5GhvNmKT9mYj8rQ3G7FTe7MRu7U3G7E3xmOOKIi5sZg4FEuKJQulPdhYPLYv ts8KJVACs2zibB4QKgYkSqBEYphbK5HA7FoNsdWpJpC3FjVEfCP8JDWmi8mh/wGihZHjCsx9 V1ILzKlXAd1cg26uQTcP6HYXcv0NvwRg3L0ouz11RI5OAd51RT3d8GtB6dSTKtOz+CVTL+pL Vagf0LAq0PD/UnL+cU3d9/7/JCQnAQ8UqSIiMkqpRUREZJQiRbSOOsesc855nZMAIYQQkhCS EEJITkJ+aZmjzFHqnHXOeR2zlDHGmPM657WWa73OL3XWea31ev0657zOeZ1z1rH7+ryDjO37 13c+3q98+j6f8zknJ+H9eb55jJfI5sjiZQkshf46bK4sEfUxFfXxeWSyZdlssWyhLAf5RbJF GOeibs6hupmHuvkqdD2qZzk5ss2RfRU1dAnV0CVUQ/NRQ93Id8jCbKksIotgze2oqnNRVb/O CmTdsm+yZbJeVNg8qrB5VGHzqMIuRoX9Psb9qLOLUWffZatlp2Sn2Auy92Tvs2LZGVTeF6ny ylF5C6GfRv0VqP4mUP2VU/1NoPqbRPW3jOpvLtXfQqq/81B/v8/S5f3yfpYm/4H8bZYhH0BF foYq8jNUkT+FinwU+i+oy/OpLj9LdTkNdfnfoWdRnT+F6nwO+n9Qo+dTjZ5PNToTNVpkWTHx qNTPUaV+nir1AlTqFLYwZm7MXJYTkxqTylbwqo0xqjbLRtV+HpodsxBnoXazRbx246ySmBLo 8pjlOPpSzEvQspgyzEEdh6KOI8P/zm4V/Z3dy/S3davob+tepr+nW4ma7mUlCkkRZjJU9m4W r3hd0cs+rXhD0cdmKt5U7GVFircU32GzFfsVb7M5igHFj1kKqv9P2BLu18aW8j2AFfM9gMXx PQCaqExkpcqZypksj+8EbAl2gvMsRvkr5a/Yp5QXlBdYvPJD5YdMobyo/DVTYoe4jMxHyo+Q uaK8wlTKj5UfM7XyqvIqe5rvHGwG3zkw56byJntK+Vvlb1ki9o/fMZnytvK/ca07yt+zmcq7 yrtsNt9RcK0/Kv/IkpUPlA/Yi8o/Kf+Eu3qofIg7+bPyzxg/Uj7C+BPlJ6xE+RflX7DyhCBn M4UYQcFKBKWgZDLsQyqGMi6o2QwhVohj8cIMYQaLEURBZMlCvBDPXhQShATMwV7FnsJe9TTO nSXMxrkpwlzMTxXmsUQhTZiPldOFdJz7jPAMNFPIxArPCs9ifpaQhfnPCdmYv1BYyGYLOUIO 8ouERUwh5Aq5TBQWC3lYf4mwBOfmC/lYbamwFHMKhAKcu0xYxuL4vohrvSC8gHyxUIKZy4Xl WKFUKGdKYaXwGcysECqYSnhFeAX3/KrwBbyvDcKXsP5XBQ2uXi3U4Cq1gg7r1AuNbLlgFMys VLAINlzRLjjYS0KrgLohtAkuNktoF9pxt27Bg/fiFSSs4xN8WMEv+LFCQAhg/aAQxNGQEML6 2JvZXL43s8XYm19nS4UeoYfl8x2azcEO/QaO9gl9LEV4U8DPvvAt4VusWNgj7MFz3ifsg35H 2M+WcGc9zMcujhV+IPwAeljAN1MYEAZw7jvCICsXfij8ECsPCT/C0RFhBOf+RPgJ8qPCEcz8 mXAUM38uHMfRXwgnWAHf+5H/N+HfMPO0cBrj94X3MeeM8EvMOSecw518IHyAuzov/Ar3eUG4 wFKFD4UP2TLhonARZ4EVMP+KcAWrfSx8jPm/EX6DdW4KtzD/d8LvMP8Pwh8x54HwAE/gT8Kf cD8PhcdsDucJlg+eiMc4QTWTLVUlqZ5mc1WzVHNYgSpFlcaWqearMlgeaON5VqzKVi1kq1U5 qkXsBVWuKheZxaol7EVVviofKyxVLcXMAlUB5ixTLcPRQlUh8iWqElxluWo5ZpaqSpF/SfUS rsL/hlTGqYUt4dQCBbVAQS1QUAsU1AIFtUBBLVBQC0vh1MLmcmqBglpYKqcWjEEtrJhTC5vD qQXzQS0Yg1pwFNQCBbWwAk4tbBmoRYf59ep69iLYxczi1RZ1M+aAYHAuCAZ5EAxmSmoJ6/jU Poz9aj/yoBncCWgG87+u/jpbqu5Wd+MsMA3LB9P0IvOGGt8udZ/6Wxj/s/qfca1D6kNsNacc ZO6p72GF/1H/D+aAddhizjpsbiz/xUd5rCxWxuZw4kEGxAPF/9hiEA/2x9jE2ERWAO55mhXH zoqdxfJjZ8fOZi9yP0G2NDY1NpWlxs6LnYdxWmwa1gEVsaWgoi+yhLiNcRuZEPeluC9hvClu E8ZfjvsyxpvjtrAkzkzIhOMOMHnc9+IOYwxywhjkhDkgJ8z58wwZk8+Qz0hlZZyfWGH0L2E5 PzE55yco+An6FfErLE3cKm5lnxK/Kn6VPSVuE7exdLFKrGKZokbUsGfEarGaxYg1Yh3GOlGH +fViPeboRT3mNIqNGBvFJvasaBJNmGMWLZhjFa042iLa2HwwWSvyTtGJPMgM6hbd0A7Rw+aJ XlFiGaJP9GNmp9iJmQExiCtGxNeQ6RJ3YmXQG67SI/ZAvyHuwpxe8Q3cc5/Yh3XeFHdj/C3x W5i/R9yD8bfFb2PNveJeHH1LfIstEPeJ+1g2Zz72PJjvAMsRvyd+j60QD4rfx7hf7MecH4g/ wNF3xHegg+IP2SJxSBzC0R+Jwzj6E3GULRR/Kh5B5mfiz5ABKUJBitBfiCdYlviv4knMeVc8 xZ4T3xPfw8wxcQxXOSP+Eplz4jjWBEdi/QviBeiH4kXMuST+B45eFi9jnY/EKxh/LH7MloIv /xOrXROvsQWcMtl8UKafzYvvjA+wZ+KD8XhKIM4IWxS/PR7PKr4rvoulx38t/mvIvB7fw3Li vxH/DbaCkygyIFG2iJMoS+IkyuScRKEgUUYkypI4ibIlYKJcItGXiUTlxKBR4oyy5oxpZBnP /gn/4okpP0NM+co0pvwsMeUsYsrZxJTJxJQp01wPlOR6IJDrgZJcD5STji/c9UBJrgdKcj2I I9cDJbkeKMn1QEmuByK5HijJ9UAk1wMluR6sJteDCnI9SCTXgzXkerCWXA8+R64HleR6MAeM OwPEGS+LJ7qdC7rFP1ZIjFsExn0VNMkp9lXZl2T/hDyn2BdlOpmOfRr8aoc6ZC5WInODZT8N lo2w5aDY7Ri/JnsN8znLfhos+wZ7CRS7h5WBX4ehP5b9mK2Qjch+jqOcX79I/FpO/LqS+HUV +DWfKYhfFUSuTxG5KkCu+IRArp9lT8s/B359mnwZoo41CeTLkEC+DEnky5BAdPt5otsX5Nvl O1gpdx1m64lx04hoF8nfkb/DFspHQbTPEss+Ryz7vPx9+fsgV06xz8jH5ePI/wrk+gx5PcyT /1r+EVj2Y/nHUO77kEMuONny6/L/i8xv5L+Bci+c+eQHkSn/b/kdjLkrRJb8D/J7GHNviAXy T+SPMeYOEenyCflf2XzyiciIkcXIMeZuEVkxyhglxtwzIoM8IzJjZsTMQOYpcPNiIualRMzL iJjXxcyLSUOec/PimGfBzXkxC8DNi4mbl8TkxORgnBuDTgoMvYwVgKFfwLg4ppjlxrwIkl5M JJ0fUwqSXhyzImYF1uckvZgY+gvE0BuIob9ADL2B6PllcHMvuPkNsPJMYuVkYuW5xMpFihGw 8otg5ZNsueJdxRm2goh55TQnCyU5WYjkZJFIThaVxNCvEEOXkatFBZF0MXGziohZRcQcT6ys IlZOVl5XXgcH31D+BhnOx7OJj1+ZxsfJxMcpyvvK+1BOwC8TAaumEfDLRMByQQABq4h9VcS+ KcS4LxPdqqZxbQqx7MtEsSqi2GSi2JdBrotx9G/M+jLR6gyhUCjEzCKhCDM5s75MtBplUxXx qIoY9DPEoK9MY9DPEoPOIgadTQyaTAyaQqyZInQJXSDXrwlfY4XEmsXElyVCr9CLPOfLVOLL MmGvsJetIrIsFPaDLEuILOcSWS4XDgr9bAX4cgAZzpSvEk0uF4aFYZzFmbKQmPJVMOUozv0p yHIukWURkeVy4V+Fk1jhXeFdzH9PeA/zOVnOJbIsIrJcTmS5UhgXxrEC58sy4stC4svlxJcv EV+uIr5MFT4SPsJRTpZPmPK2cBcZTpZFRJbFRJavChPCBCshpiwhplwOppyDMafJl4gmy1TP qJ5jK4gpVxJTfpGYspwIsowI8otEkCuJIOeqXlC9AOUEuYoIcqVqhWoF1uR+KyL5rSjJb0Uk vxWR/FaU07yj1pLfipL8VpSqDaoNuDp3XVGS64pIrisV5LqSSK4rleS6ModcV+aQ64qSXFeU 5LqiJNcVkVxXEqe5rojkuqIm1xWRXFfmkOuKklxXRHJdUU5zXVGS64pIritKcl1JJNeVOeS6 oiTXFZFcV+ZMc11RkuuKSK4rleS6oiTXFeU01xUlua7EkeuKSK4rSnJdqZzmuqIk1xWRXFeU 5LoikuuKklxXlOS6IpLripJcV1aT60oFua4kkuvKGnJdWUuuK58j15VKcl2ZQ64rSnJdqSDX lbXkulI5zXVFSa4rc8h1RYkeABQL4n+OlRHfr1A/r36eLQflZ7MS9SL1IlakzlUvZoUg/jzk 89X5k9xfqC5QL2OriP4L1UXqYijvAVaql6uXY51ydTm0Qv0KdI36c1itUv15zFmnXoee4VX0 A8vVX1Z/GXneD7ykrlJX4U5q1DWYH/Wm4h3CSnQIBlwl2iE0q61YoUXdgrPsajsrV7eqW5Hp UHtx/7xPKKbeYC55WRVSh1Ci3qneCeV9wirqE0rU31SjPlCfUEgdwnL1W+q3kPmu+ru4Ou8W VlK38EX199X9OIv3DMvVb6vfxpx31INQ3j+sUN9X38cKvH8oVn+i/oS9RP3Dq9Q/lFH/UBKr jlWzQuofimPjYuMwjkf/UBI7M3Ym5vMuYiV1EeXURayKTY5NRo8xJzYFM+eilyiiLmJubEZs BluBLmIje4o6h6fQM2xmT8dtQefwdNzWuK3I1MbVstI4Q5wBaowzQk1xJqglzgK1xdmg3GEn gRx2EshhJ4kcdpLIYSeBHHYSqANRUI/x+RnzZmSyF2asnfEFVjpDO8PF1k86gfGuIwadxiKm oF5iEfUSC8U66iUaRANIl/cPz1DnsAidgxlji9gMgneIDmR4z/Cs2C62I9MhekHzvE94jvqE RdQnLESfsAOZ19AtLKRu4Xnx6+LXMZ/3CYvEb4q9OPoG+oTn0Se8idV4n/Ac9QnPUIfwLHUI i8XviN+Bflf8LpR3CMuoQ1gnfh8dQj46hMPIvy0OsCXUIeRTh1BAHcIydAg/QmZY/DHLFUfE Ecz8qfhT5HmfkCceRZ+wWDwmHsPRk+gQllBvsIx6g3XiafF9HD0jnkWedwgF4gfiB5jJe4Nl 4q/FS8j/B3qDAvQGH2G1K+gQ5lOHsES8Kl7FdXmfsJT6hDzxv0SwFnke5ZCPWrZ4S7yNDPc/ yhDviHcx5i5IWeSClEEuSDnkgpRBLkjp5KM2X/yL+Bcod0TKEf8qgsTIFykTgAwSI3ekdPJU m08eSfPi1fFqjLlTUhY5JeWQs1p2fEL8U8hz16Ss+Kfjn0aGeyctIO+k9PiU+FQc5Q5KOeSg lEUOSgvIQSkzHv9wlPsoZZGPUgb5KGXGG+IN6H94R/QcOiIfS0NHhO9DfDg+zJ5HR9SFPO+C Cqj/WYf+55sY98b3sSXUBRXE747fjTH3Y8oiP6Z55MeUQ35MC8iPKSvq1sZk8+6lSXgVY3aw jxnTbEFoEDqEEWFFOKdeZc0H8eqZzAUQOxDdiF7EHsR+xCHEAGIYcQRxHHEKcQYxjrjI5H4T BdNcoZD7bQgXxtcRtxB3EQ8QjxmrliPUiITotatnIVIRGdNeF0z779zoWtUFiGJEGWL1tNe1 iPWITZPn8NetiBqEHoH7qrZNvcr9EoWs+TBiCOPQVC4aXYieybEL0Tc53jsZByajHzGIGEEc RZyYnDtG81k1v2f+GkJ0IXrovqJzz9I8Vt2H2Is4gOhHDCJGJq93HuOjiBMIPvcsgucuTR6/ NBlXkeNxA+9nFHFs6r2w6tuIe4iHiAnGahSIOERi9LnXJCPSJl8z//Y6NT87+h3grzQ/Mfrf U8fzEIWIEkQ5ogJR+bdX/vnVbEBsnva6DaGd9mpAWKZe5f4b0fuucUTfW417ch3//1/Q93p6 BKLB7+Pv1tvwDxFB7Jx8jfw/68j9/N52IXZHP5uafYiD014PI4YUM6tKTBVem+aK+TFXi5xU Db1uSYDessyC3rWkQh9YMqCPLQu8Nn6WdL9absmVHlWVmyq9rqoK0wavVK22FJAWT40TLGVe iR/1sapK02ZvqHqWZbU3FB1P6gbTNm9XdaplLen6fxhnWDZBF1i2QnMtNdACi97bxc/yCVWb TVpvT9U2k8HbV11sMUHLLDboaovL28fzPrFKa7J491avtUjQ9ZaQL6nKYHJ4D1RvsnSR9pD2 Qbda9kJrLAegeks/1GQZhNosI1CXyeFLqZYsR33pVRaT29tfHbKc8PZXOUx+72B1l8nvy6py myLekeoeyxi0z3IWutcU8eVUH6D8Xq5VftNO79GqiGmX90R1v+X8lA5aLnlP8Lwvf1J3mnZ7 x6pHcJTr1anxUcsN6AnLbeiY5R70rOXhlJ63TPiKqi81K3ylVbtM+7xnq682x3nP0mrnJzM3 mhOht7nyjG9V1W7TQe+l6nt45lzXPhnzvG9N1T7TYe/V6ofNyd6rfOxbVz3RnIbxQdOQ90aN ojmTNHtqHNecB01sLoQmN5dA05rLoZnNFTSuhGabhnwbqw6bRr23q4ZMx7z3avKaN/i2/J0W Nm/2bakaNZ30Pqw6Zjrtnagpad5Gqp0alzcbvBNVJ03nJEVNRbNlSiubHZKi6rTpghRnGHTd Ib1P+gg60s6gR9sF6Il2ETrWngQ9254ixfGzAusM59vTw4eqzpkuS4lVF0zXpGTDpfYs6NX2 HFI+vtGeLyXzo+GBqsumm95Bw+32Iu9gdDyp10x3pDTDvfZS0lX/MH7YvgY60b5OSmtUtG+E xrVvkdL4WeHhqpum+1Jm1R3TIym7MbFdA01u10HT2o1SNs+Hj1TdNzMprzGz3QrNbneGj1c9 MgtSYWNeu4c0QLoDWtjeDS1p74WWt++BVrTvh1a2H5IK+VnhU40b2gdC1zRMs0YqadzcPiyV aASzKJVzDZ/RiOYkqaJxW/sRqLb9uFTBM+HxaH5Sk8wpUqUmxZwubWg0tJ+aUkv7GWkDz4cv Tmq6OUva3OhoHye9ODV2t1+B+tuvQyPtt6A72+9Cd7U/gO5ufxy+0rjPLQ9f12SZc6RtjQfd amkbraadzBx2JzxRngnf0uSY8yVD4xA+O6h71pMxz4fvavLNRfx9uVNx/xiHxxtH3RkYF5lL JUvjMfcC0typ8Ul3AfS0uxh6zl0GveBeDb3sXgu95l4vWfi54QeaUvMqyaFZZV4juRtvujdN 6R3S++6tkhvPdh2e8BrzRsnf+MhdQ6p/MjYyt0nyV900b5EyjYLbNqWi2yVlataZNVKkZkOz m9Q/Nd7cHIFua94J1Tbvghqad0MtzfukCD/Lp6lxNB/06TQbzTppp2aL2SjtqnE3H4b6SSOk O5uHpF38qM+o0Zit0m6NpnmUKx/X7Go+Jh3W6MxOb0/N7uaTpKf/Ybyv+Rz0YPMF6OHmy9Ch 5mveHn6Wz6oxmj3SPo3VHJAO1ow234Qea74DPdl8H3q6+ZF0UOM075AO15wjvWBlPqfGY+6W hmouWwVSkTRJGtJ4rCkYX7OmQ29as6B3rDk8b+72eWruW/OReWQt8gU0AXOvNFrLrKVQwbpK GtXsMO+RjtWK5j2+HbVJ1jXSMU23eb80VJtiXQdNt27EOsj4PKTd0aOaXvMh6aRmj3lAOlyb Zd0ypTlWDZ4M8r7e2nyrzrcnOtbsNw9Lp2uLrEZS65SWWp3QVVYPdI01AF1n3QHdaO2GbrH2 +vbXaqx7fIewzhHpXK3Oul86h/Fx6CHzKdyh0XqIdAB3hQzuc8B8RrpQa7UO/73yvG+g1mk9 4huu9ViPS4WaYfO4dLk2YD0lXeZj3xHNsPUMxkfMF+kdjZP+bZxjvQLdYb0O7bbegvZa70L3 WB/gM9plfYz3jnPxfo+br3gvaU6Zr0vXave3yKf0EOlAi1q6pjljviXd1Iyb7/LvQEsC6awn WjvckorvwEXzA+lO7ZGWjCk93rIAeqol13e89oypwneqdrylAHzC2eBM7cWWYm9X7ZWWMuj1 ltWTO/g43wd9F2tvtaz1jtXebVnvHaOd6Ertg5ZNfFdq2eq9UfvYdNp3XStvqfFOaNUteu8E /bzc0ia0mPCzw7+3d7WzWmzeHm1qiwua0SJNfsce8M/X91i7oCUkndbsb+mC4jn45drclh7+ TFr6oPROtQUte6HFLQekg3zHCT82Jrkl7D6o/BG5McUdktKM6e4uaJa7J1qfI2pe5SIJxhx3 n7TZmO/eK23mdSYyy1jkPsBrjrsfikoSSTWWugdRPVa5RyQ//+b7PNqyln6pUru6ZdCv1q5t GfEnaNe3HPVe1W5qOeGVtFtbxrwhbU3LWf8szDmPOfqWS/5Uranlqi9Ja2u5Ie3Sulpu+zO0 Uss9b5821PLQe1vb1TLhX6DtsSn8udo+W5x3ULvXlugv0B6wJfuLtf22NO+YdtCW6S/Tjtiy /au1R215/rVR3tCesBX612vHbCX+TZwofOu0Z23l/q3a87YK/inYKv010Z1de8m2AXrVthl6 w7bNr9fetmn9Ju09m8Fv0z60Wfwu7YTN4ZfqFDa3P1QXZ/P7u6JMW73JFsGnT+wUpZS6RNtO /xQ32nZ5++qSbbuxU+O74e+rHrPt8/fVpdkO+vfWZdoO+w/UZduG/La6PJpZaBv1nqgrsR3z 99eV205iXGE77bXVVdrOQTfYLni76jbbLkO32a55D9RpbTehBtsd71idxXYf6rA98p6tc9sZ 1G8XcD8RuwjdaU/yD1avtad499btsqf7R+p227PAHngC/qN1++w5k99tTd1Bez7WOWwv8k7U DdlL/SfqRu2r/GN1xzhh1p20r/GfrTttX+c/z38u/Jfqztk3gtLB6v6rpDfqLti3RAncf5v0 HulD0gl+lU5FVOsu2zXenrprdh3e+027Efd2x2TpjKu7b7dOjhNJk/nPV2da3SP+JDkPd2aS ZnPu7czTMbuzM4/GhaQlOsHu8R7VifYAeBhU3FmuS7LviDJwZwVpJemG6hv2bu9ZXYq9F5rO lVNr52bSbbos+54oqXZqdTn2/d5Lunz7ISjyyBTZB6LU2mkgtZA6+E99p5vUH1VdqX3Ye1u3 yjTaGdGtsR/x3tOtMx3r3KnbaD/ufajbYj8F1djPeCd0Ovs42BKfS+cu0t06o/2iP6FWZ0dV 1Fnt1zv36Zz2W50HkUFV1HnsD3DnAfvjzsO6HQ5555Cu26GWjul6HQmdo7o9jlmdx5BP7Typ 2+/I6DytO+RYgKpO1Vs34MjtPKcbdhSgGo87ijsvRCuh7oijrPOy7rhjdec13SnH2s6bujOO 9Z13dOPEAJcdm7AXRHcZqtvRPVp30bEVOz522877uit8t9Vdd9Rgp0PV6nxUu8ah73yku+Uw BZjursMmjeoeOFyd16L7cm2WQ8J7eewIcZZwdEmRermjh+/pjj5vT73asffJbluf4DjA9y9H v3S6fpZjEJlUxwg0w3H0yU5Rv8BxIiDU5zrGMC5wnA2I9cWO84Ek/u4CKfVljkuTldZav9px FeusddyQDtavd9wOpNdvctwLZOHJPAzk1G91TATy62taFYGien1rXKCUP7fAKlpnTS1rTZRG 602tyYF1vIYHNk7SDjSwhVTzhGrM1oCOlDgnYCV18nsIeEgD9bbWNGlf/drWTNyJi9NIvWTe 4ZfXh1qzo+PADtJuvhcEennVDfTWd9ETBl0E9pDuJ354UN/Tmof9AuPAIdLe+r7WQulk/d7W EhAFuCIwUH+gtTxKEX4518AwaXdtVmuFdA5HK6H9rRsmd/wHXANH6gdbN0d3+cDx+pHWbdKF +qOtWijyyJxoNUR3+cAp0jOk43yfClwk7Sa9Uj/WasHejR28U1t/ttWBnRr7eOB6/flWt3Sz /lKrX7pZc7I1gu/Gkdad0h165rdI79JzGK6/2rpLulx/o3W3dK3+dus+7OlEofX3Wg9KhcY1 7qORDOM694nAY+NG91hkgXGL+2xwzKhxn4/kGnXuS95Bo9F9lebcwByr+za41+m+FykwetwP I8XGgHsiUmbc0aGIrDZ2d8Rhhd6OxMha456O5Mh64/6ONKnceKgjM7LJONCRHdlqHO7Iw755 pKMwUmM83lHivW081VEe0Ue7A+OZjgqpwjjeURkxGc+4M8LjxosdGyI245WOzXxX7dgWcU1y +PUOLakBeqvDEpGMdzsckZDxQYc70mV83OGP9DTJOyKRviZ1x87I3qaEjl2RA9EOtDGvYzd6 rminQz1F06yOfZH+aJfXlNpxEJrRcRgdAd/rBxsjHUORQaPQMRoZaVrQcSwSasrtOBnpakyk mQUdp0NDTcUd5yJHo32WYbADPW9TWcdl9LP3Oq5JaU2rO26ir8zruCMVNq3tuP/k6k3rOx7h HqhLatrkYeiYovez1SNAazxi5ERjpidJymvSe1IiY00mT7q3hz+ByNkmmycryirh4SaXJwer SZ58yd8U8hRFzjd1eUojl6L9YFOPZ1XkalOfZ03kBuecyO2mvZ512NfQWUfukT5sOuDZGO2X IxNcO7O5+rK4blfwq2yna21PNIoePP+mfg964aZBj07K4/3v9uSmEY9xcpxGmsl5afuTJ4nu dXseaSG/q+0lTUc91u0lNC4nrWg64XFKlU1jHg+6V/Sw2yubznoC0Y51e1Q3k6Kv9OzAEzvv 6X6ivMf0Pea6Xdt0ydMb7Su3G5quevZIhqYbnv1Q5JG57TkU7TFxda7lpNRpbqeecbuD1N10 zzOAzhH943Z/00PPMPpEdJHbI00TniNSuUnhOQ6N85wC4wmeM1Im/1y27yTdVXXfM759tynR c1GqMCV7rkhuU5rnuuQ3ZXpuSXH1D1sPSxHdjtYhVK2J1lEwqhNV8bBe0Xqs87I+rvVk4IE+ sfW0r1ef3HrO59SntaJ3m9LLgcf6zNZrQTn0JukdaHbr/aBan9f6KJigL2w9B2Knnk63w8mw colTCM7SlzvFYKq+wpkUzNAd4vWTK65S6UwJLtBvsOYHc/WboQU1953o4PTbnFnBYr3WmRMs 0xuc+cHVeouzKLhW73CWSie5BtfzOhncNNlbkerdzlXeh3q/eTi4VR9xrgnW6Hc61wX1+l3O jUGTfrdzS9Cm3+fUQHc7dUGX/qDTGJRIQ/rDTmuwC+qEDjk9/kFowD/Ia2mwRz/q3BHs0x9z dgf36k86e4MH9Kede4L9+nPO/cFBXkWDI/oLzkPBo/rLzgHJor/mHA6e0N90HvFe0t9xHkcN XOs8FRzT33eeCZ6N7lBcg+c1Fx0ngpc0F53jwatRcqs77bwYvKF/5LwSvN3AnNeD96p2Om95 xxoE593gwwbR+SCobkhyPg5ONKS0yf2bGtLb1CFFQ1ZbQiiuIadtViixIb8tNZQ8fbWGoraM UBp0QSizobQtN5TdsKqtIJTXsKatOFTYsK6tLFTSsLFtdai8YUvb2lBFg6ZtfaiyQde2KbSh wdi2NbS5wdpWE9oG1Ye0Dc42U8jQ4GmzhSwNgTaXT9ewo00KORq620Ihd0NvW1fIP6l72npC kei3peZ+W19oZ8P+tr2hXQ2H2g6EdjcMtPWH9jUMtw2GDjYcaRsJHW443nY0NIR1TmCdU21j odGGM21nQ8caxtvOh042XGy75DvUcKXtauh0/UTbDel0w/W229BbbfdC5xrutj30XoVOQB+4 FKELDY9dcaHLBrkrMXTNoHYlh24aElxpoTuGWa7M0H1Dqis79MiQ4cqTDIYFrsIwM+S6SqQL hgJXefChodhVERYMZa5K/6BhtWsD7o2uYljr2hwWDetd28JJmo0ubThFo3EZpN2GTS5LOF3T 63KEszR7XO5wDtQvnTNsdUXC+dCd4XzNgGtXuMhQ49otZWouuvaFSw1618HwKoPJdTi8xmBz DYXXGVyu0fDGhv2uY3hK0PCWaNdvkFwnwxpDyHU6TL+3CROrhK2GLrMn7Iz+xHHG8OVM/qbi 7386jkR/VxD9zUCwx9DjOhf28P09HOA9eHjH5HeSfjvEf7fg6zX0uS6Eu6MkZtjrugw94Lrm s07+9oZ+r6JXmI3hXv7TEd4T7foN/a6b4f3UdT5gcjZHdlf2B8Zkf5Thv2SPZJ8wheyvchkT 5Eq5wGLlM+QimyFPlM9k8fLZ8mT2lDxVPo/NlGfKn2VPy7PlC9ls+bfl32ZzYtbEfJalKCuU r7BUpVXZwtKUv1D+gqUn4B/7VEJGwudZRsL6hK1sXUJVQpB9JeH1hJ8zf8JYwm32w4Q7CQ/Y BdzNF5iC/n41gT3FYtlMtpHNYJtYDXuVadlrbCv7GtvJAqybfcBC7FfsP9lp9l+yOPahTJTF s7/KnpLNlslkqbJsmZr//xdlc2RbZPWyNFmDLCTLkUVku2RrZH2yb8u+JPux7Jeyr8S8HfO2 zKGwKeyyVoWk8MvaFBHFazK34nXF6zJJ8YbiTZlP8Zbiu7KAYkAxKNuuGFH8VNal+Lni57Ju xbuK92Sv01//7VKMKz6QvaG4orgqe1NxQ/Fb2R7F7xW/l+1T/FHxv+x9DXAU15Xu7fmTkOWx LMsYsKzwI2RZxgLLQiYykTEWBGMxmhkpMiaCYFDN9Pz0j0Yzo9EIY0KIliUUDxMWa1keYXks 4REWE4rFmMWEEIIJoQiLtTxCsQTzCMGYhwnBmABR3jlf90iDwDGp3Vf1qpI69Z0+c/vc0/fn nHNvt3pGn0n/yG+zSevsD9kfkr5v/8DeLW1w2B2FUpfjccfj0lXHE45S6VPHs45K6SZ/U0H6 o+NFR7XF5pjomGJxOGodjRan4zVHkyXf4XNELIMdMcdcy1OOv3UssTzrWOpYZfmK43uO9ZbJ /D0Ai9ex2fFzS53jsOOwpdlxxHHcEnGcdJy0tDtOO05b5jh+47hgeZ3fl7J80/E7x1VLh+Oa o9uyMENk3G95MyM342HL9zIeyRhm+R8ZRRmjLVsyXsgIW/ZktGQss1zM+LuMv7Pyuz6rrPdn /CBjs/Uh/n9w1kcy3snYYc3P2JnxY2sBv69jLcr494zj1vKMExnnrGMyPsr4zDohsyhzq7U+ 83f9hlg/dN503rTxN77CYiHxbFHA3wh+4TLhlhDjywhFokhd+1JQ3aBuVre9tEndqe5R96uH 1KPqcS3TE9WcWp42yLNdG6wVaSO0Mm2MVlVzY0rBV9e6dqmnpgj1rHpBvaxeU29plikFLy8m r7KRj1+Gj38qJOmP0h+FhTw6R1jp3GN4I1RYfmD5gZAs/2z5Zzq3xfJDYbW8Z3lP2PFGqMPy C8svRCa+y9TP8oGlS2ThXdBsvAV6v+VDy4fCifc/H7B8Yvkk9d+/rJJV6vlvh3arQ/THd58G WPtb+4uB1gHWAWIQ3th81FpsLRaP4XtNBdax1rFiML7FNMQ6zvqCGIrveBTinY3h1P5sKRcj x1yo+YL2D+pQtVgtVcvVSnWcOlGtUb3qVOIz1CY1qOqEuDpHna8upHNL1OXqSnWNul7dpG5V d6i71X3qQfWIekw9qZ4hfl69pF6lc1fVG5rQaFem0X5Lo92uRrum22iPRnshjfY9PeTS6rVp 2sw08mlhLaIltLmk20v7tUPEF2iLtKXaCm1VD63VNmibtW2gnWTvKJVVaMdJOqWdJemCdpls VmjXtFu6RVtE/Zf6hc2swd8rfxBjMoDIKvKJbKJIPC7sYgRRhhhJlCkqifqJsURZooroPlEt JuD7gy9T1jG+OfiqmIZvDs4ge01EDwmZKE+0iKh4WLSJpHhEvEE0UHyLaBDlozfFo+ItosfE PxAViH8S68WXxA+IhojNREPFu0TDxL8SFYr3iIaLn4h91L6DRMX4/51PiOPil6JE/AfRCPG/ iZ4SvyEqFVfE76jt18XvxdOim+gZySJliHIpi3JfJd7jfo5yX44Yi/e4q6QCaYh4XhomDRMv 4huL1ZQN3WIC/s/dRGm6NFN8VZolzRIv453uGnw/cYoUlsLCJWmSJmqlmBQXbul1ab7wUu7s EFMpe/6teFX6jrRYfF1aKi0V0/H9xBmUSXeIb0g7pZ1itrRH+rFokvZL7wuf9DPpZ0KWfi4d EgH4b4iyQLEIZ5ZklggNb8/pmU9nlolmvDHXklmZWSmimVWZVSKG78vE8X5ca+bMzNdEW+bs zNmineb2nLgG36/g37tRcgkDCAWEQkKJiVEmKghjxSvKAKVAKVRKlFFKhTJWGa9MUlxKvTJN man4lDBRhJBQ5ioLlEXKUmWFskpZq2xQNivblJ3KHmW/ckg5qhxXTilnlQvKZeWacku1EGWq TjVPHaQOVovUEWqZOkatUvar1epk1a02qKfVRnWWKquqGlWT6jy1Q12sLlM7iVar69SN6hai 7eouda96QD2sdqkniM6pF9Ur/H/R7LPsAVoEpztnkMdayD//q/x7CtED8PIcePmD8PKH4OV5 8PKH4eX94eUD4OWD4OWPwsvz4eUF8PIvwcsHw8uHwsuHwcsL4eXD4eVF8PLH4eVPiENEJfD1 J+HrI+DrpfD1kfD1UfD1p+Hrz8DXR5OvW0QF/PtZ+PeXpcekAvJ79uyx8OyvwLOr8D2F5+HN 4+DNL8Cbx8ObXyRvfp1i4A3pDYoB/rbCV+HNk+DNk6XvSt+leGCfrsH3FKbAm13wZrd0iPzY Kx2WDou6zK9lfk3UZ07LnCa+lhnIDPA3jnPm5Syiecqmsb9PSNGtQoQXEZYSVhBWUdkOOq4l bCBsJmyjst22B8OLoyvUwj8N6JTES8PLoqvCndG16qjbwWXh1dENagVhbLycEV4X3ayO/9Ng nfDG6LbwluhOdVIv+HN4e3SP6iLUxyvDu6L71Wl/GtCZGR8X3hs9pPqih8IHokeBw9HjapgQ iU+EnIjXqHPj3nBX9FT4RPSsuqAX+LwoPjV8OnpBXfoFWBGfARvnopeBi9Fr4SvRW+oqAyyH r8cs6tpe8OdwdyxT3RDL5CNDscWc6uYvBuspWbE8JSc2SN12O5T+scFKfqxI3Xk7lKGxEeqe XijFsbJ7Qcvy5CGlNDZGKY9V3RWVsWpGy8rkUYYyLjb5njAx5lZqYg2fh5Y1yeOKN9Z4L4is azupTI3NAmbEZKAppjJa1idP8THSlcxu2ZQ8qwRjUUWPJfsisqXtvBKPzfsitGxNXmjZkbys zIl1APNji5WFsWW3YUms8w4sj62+DStj6+4Za2IblfWxLXdgU2y7sjW26w70Hesdsb33AnV/ vEnZHTug7IsdvivonHooHlSPxnXoHYx13ROOxE7c1XfY3nHCqXhcORY7fS9Qz8bnKCdj53pw JnaxB3z+AuFyfD7ka/GF6q34EuV87Ara2weaJb4c8qXY9S+ClhlfqTnja26zcTXWfRtuxG19 oeXF12uD4ptUEc/SBse34lgU33G39nweVEc8R82O978DufF8dUB86B0oiBenQxsR353K7bfl YjNXpnKcVhbfl8pB2pj4wfQ80uMn6fOampfUGFXFj/SMbXX8WHqbkEt2U04hf2zZZ/hly0Ez hjmujhCOJa+xv7ecJJxJ3kr5c8t5OtJ1tMnxk5o7fkZriJ/XGuOXtFnxq7y+aHL8Bpejb7RG aGqr4LVEi7Y6tGRrtjavNVfraB2gLW4t0Ja1FnJu5z5rna0l2urWUZyftXWtFdrG1rHaltbx yMuU03kstO2tkzh3artaXWxX29tarx1onaYdbp2pdbX6tBOtYe10a0Q715rAGslrEK8JPIYX 46Xalda5vI5p12n9SY1zd6tLt7UuYBt8Ts9qXaTntC7F2pNaa9PmqMcmw1xTUmsBt4vXRr1/ 6wo9v3WVPrR1bc88sz7NHc+9Xty6QS9t3ayXt27TK1t3omwcreHLDPB6zev2bVhnrMv6xOg2 rMd0ndRazEeA/Ad967PG8pGh10RPMXh9TK2rKeje6GVGzxrJa6a5NqavlelrZGqdTEGfSusg rYVY+2g91GfEBjPgt7zODTWgN7XuYb/Ug637db31EOR461F9Tutx+CzlD31+6yl9YetZnFvS egHH5a2X9ZWt1zhu9TWttzie0K/1CYu+KZGpb004ERepODDzIudSfUcij/Ocvptykxkj+r7E IM5bXD+VA++IrT5x1ZNfzNhiG5w39YPxq/qRxGBuY0990ud4048livSTiRH6mUSZfj4xRr+U qOJ2c07iPuhXE9X6jYSxNnxRDjLb1SzMPJ7KS8fTdMw2o6998nFPfzgPp/B51/qcfNrsMI/Z 8SyeixTuyJPpuZLzYypHpuVD1oUd1uHcRGPQnBvf1HKp3cJz3HK1PZP72XKj3RkV7XlRR/sg LkfO0pMbotntg7F/Ib9j3WhuexH2G7TviA5oH4E9BeW0aEF7GfZp5p4gWtg+JlrSXsXrf3RU ezXnumhFO3JhdGy7m8ExGh3f3hCd1N4YdbXP4jwcrW+Xo9PaVezJKF9GZ7ZHUdfXnuzZM/Ge x9yjwJZpg89Fw+3zWrzJRWhXam+X2ht4e3MwkNrDmHsPtgUbkfaOyKA2L+qk6rM+52j+zH7B Y8B9S7QvRhnvG1Mw94m34V72gty21J4ubV/XA97PpdB3X5fao91lbxada+AL92a890rff/Ge K7XvSt9jcVu5LuukxsSMreYBCTeOBYmG5sJEI3yV9zypuCpJzGoelZCBioTaPDYRbR6fSDZP SsxrdiU6gPrE4uZpiWXp/t48M9EJ+BKrOb6aw4l1zZHExuZEYkvz3MT2u8Yb3R80L0jsal6U 2Nu8NHGgeUXicCremlclunrktYkTwIbEaQZib3PiXPO2xEUcdyaupGKweU/ievP+RHfzoTZb T/xRXDUfbctCe4635XDOaj7V1p/XnhR4T9l8ti2/+ULbUPT5cltx87W2Us5dnD+ab7WV85qS 0o9Y2iojmW3jIs62iZG8thr2x8jgtqmRorYZkRFtTZGytiDvCyJj2nS2w+MXqWqLR6rb5mBv S/Mfmdw2P+JuWwg0tC3hMeexizS2LY/MalsZkdvWRNS29Zy7I9G2TdBPtm2NzGvbEelo2817 wMjitn2p3BxZ1nYwtS5FOtuORFa3HeP7kcjGtjN8TxHZ3nYpsqvtamRv243IgaTgcYwcTjr4 foTX7siJZC7biJxODuB5jpxLFnBcRS4mCyNXkiWR68lRke5kRYstObYlKzme13c+15KTnMQx Bz1qd0v/pKslP1nfMjQ5jdveUpyc2VKa9PGct5Qnwy2VyQj3q2VcMtEyMTm3pSa5ADnBzLmc J1umJpfyWtkyI7mipSm5qiWYXMv5riWe3NwyJ7mNfZfHi+WW+cmd8GfyhZaFyT0tS5L7eRyF RUjODudSIf76F5S/oL+gXBRXev8OEKgR4YAeiAfmBOYHFgaWBJYHVgbWBNYHNhHfGtgRqDEp DuwO7At4TToYOBI4FjgZOBM437ArcClwNXAjKIKOhnPB7GDuK/2DAxpOBwsCTQaRBiFYGCwJ BA1qOPBKTnBUsKJhe3BscHxwUtAVrA9OC84M+oLhYCSYCM4NLghMTRFpLAouDa4IrgrMMCi4 NrghuJn0tqF93CLW5HN8RboCP+e/fyP59kv/Jc9Bp1Bs1BI9iOeguXgO+hCegz6M56D9hSyC 4hERJhqEp6GP4mnoY3ga+iU8DR2Mp6FD8DR0GJ6GFuJp6HA8DX0cT0OL8TT0CTwNLcHT0Cfx NHQExdwhUSoOEz2Np6FleBr6DJ6GjsbT0ArxG/GReFZ8TFSJZ6LP4ZnoV/BM9Hk8Ex2HZ6Iv 4Jnoi1KBVCCq8Ux0Ap6JTsQz0a/imegkPBN9Cc9EJ+OZ6Mt4JlojvS69IVzSN6VvCg+eiXrx TLQOz0S/hqehDRTp74hXpHeld8U0PBP9Op6JTscz0W/YFtm+I2bit/Jm2XbY3hVNFNf7hc92 3vaRkCl+rwmev4SY2+urcp4ok/PkQfJguUgeQVQmj5Gr5Gp5suyWG+RG0DK5U14tr5M3Em2R t8u75L3yAfmw3CWfAM2SZVmVo6g/Qk6Cz5M7iM8iWszEfmN5kvzmKdNvcnF99hgLzdHj5D3s KzYa/zLyHvYVB3wlgzxlAvkQPzPvR94xjXyI/eM++Ec2npPfT/0KkSexN+SQL7xJ/sR+kEte sJ78iT0gT/yQ6GF4QH94wCM0//vIb/l5+ECa81+Sh/GsP4pZz8cz8Mdo5i+IAszxYCmH5ngI Znco5nUYZrRQ+oY0UwzHjD5OM6qLYilOM1qCp9xPSotpFkdgFp8yf0eSn2mPlN6RdohRQsqs yBzbOx/+BtuD/oa+JM+XF/ob/bP8iw2Sl/gb5eVMfrkvySv9qj9qkLzGn/Qn5fVU0ofkTf7V /nlEHUSGza04LvN3pkjeQTp3kLzbv44sbPRvMWm7QfI+8IPEd91J8hH/Xv+BHurw7U9Rj+WO vqTtCS3xH/Z3pUjb7z9h0um+pB2iVp0zSDvqv+i/KGdRSR/Sjmun/Fe0s/7rRN1M2gX1iL9b tslZKdIuyzl9iUZnoX9dYKy/S+5vkO+oQdo1OV/O1y7I+b3tTGvxLd9SeWiK/Nfl4hSRRcN2 qXysD52Uz9B1ynvovFzJ5Ft6Z6/lS/5B8rgeYr3+8sQ+dJVwQ64BeWVvQBjlAUcgm45TDetM gdzAAHnGnRQokJsChXIQ/jIvUMI9ZgqMClQExvpuBcYHJgVcvXbSLNb7jqb5ky7HA9MMkucY FJjJ/h3wwXfVQDgQYV8IJNhnAnPZPwIL5GOBRejtxMDSwAq0aAWsr5Ljcpw9RbdgPNbpmbqT R1XP49HXB/FIB9YGNgQ2B7YFdgb2+BsD+6neIbJ9NHDcHw2cCpwNXPB3BC5T+1YHrgVuBS3B zKAzmBccFBwcLAqO8K/27QmWBccEq4LVwclBd7Ah2EgtVqmVu4KzEGUdQTmoBqPBZLDaHw3O C3aQLY5a9AiaqxEn1KPgYn8yuCzYGVztbwiuI9v7SW8WxdL24EaSGoNbgtuJ7wruDR4IHg52 BU8glpMGBU8Hz3FvgxeDV4LXg90hG0UrU2coK5QT6g8fpyuF8v3bQ0M5GkPFhNJQeagyNC40 MVTj3xvy+g+EprIVjrzQjFCT4alyeSgY0kPx0BzZG5rvj4YWhpbITXJ+aHloJY3ynNCa0PrQ ptBW8teJNAOVoR2h3aF95HPe0EGiI3JN6Bg8sFQuNeYKejPYY3iuQicJZ0LnQ5fk0tBVOhMP 3aBF3RHODufK5eEBwdXhgnBhuMTfFR4VruAa4bHh8eFJRC74eGVgEUrrw9PCM2Vv2BcOhyNE ifBc8mGmyvCC8KLwUmp1k39eeEV4lZwfXst+Gt4Q3hzeFt4Z3hPeHz4UpqgNH/d3hk+RP+rc t/DZ8IXw5cB48tC4XBq+FthDY7M9MJ4i7oQ+mHLXDPWIXqSP8J/Ty8ifu/3X9TGUKXL0qsBZ vZpiucu3X5+sHlGPcFz7q3W3XKw36I36rODkQIGWTaO9jr2Sshnnp+t8WdIiDfp0QFcpU3G+ gwcbmpxhMC/V/ot61LdUT5KPz6PyYtLronyVr3ONw/pifRm1sVNfra/TN+pb9O3Ighf1XZwB 9b36AbraYX2Z3gU6QXnOZuS64HYdV2MP1jt9R/VznM30c2SZNS/qV/Trerd/r77YyFzIXTm6 haiTxnQotyR0PnxL4Z94y1ScSh5lqA3KIGWQbwP5yhplsFLEOck/SxkRjCplcqUyRqkKzVeq 5YnKZMWtNCiN8lRlliLTGVWJhs4rSWWe0sERqyxWlimd/nmhlcpqZZ2yUdmibFc6lV3KXuWA cljpUk4EhHKacE65qFxRrivdqi04Qs1Sc/wblROh8/5dan/SbvSfDi3EGbyT44/yWzmhrYEN /GaOf3XPuzkz1Cb/aTWIt3PMd3P83fxujtIVOGu+n7PEv/eu7+icVy8pXepVirXrgWx+SyeQ rTnIT73kry6a+S1yXMul3Fjs29/75k6AVgutQs7RBoRyzLd2zLd15CatXi0139QpwLs6vW/m pN7I2RmOYDf11F/vMP+C7jBloeOthv7Ehe+skPxlIs93muic79z0xumNvotEnb5OyFd8V6af nn7ad52o29fNZX4bUZY/i8sa5zbO9ecQ9ff3n1E+o9yfTzTUP5SuY3G6nLV0jRzc0Qjc0Vhw L2PFnteGexk77mIc2PNm4C4mE3cx/XDnch/uXLKx53Viz/sA9rw5uGd5EHcrDwkppylHRZ/w 3qGvSUi+hXSkexTfEtuDk7t98+8FNat881+2EbI+BzkGajYbeLn/PSKfMPQuKDZQs5+OpfeG mqN0LDdRaWKcAd8M41hzgXCZ5ImEmjtRc4uO3i/GlEzTxlQTbL+pD4J3gd4H8T8Dcwjz74KF hCV3wfI+WHlv8DrouIaw/nOwyYA328DLW+8ROwi7Px/eXDruuzd42HcOmjhi4pgB7wDj6KH5 8RaQfJJw5k542M/OfzG8hYQSki+ZuEq4cTtqxF3g6IPsPwM0FjUD7gLqT03hneg71jUl94Yp Y+g4ilDxOaBzU6oI1abe2HvE+Lv7DmywTTcdJ90bpjTQ0QUsxLE+DSmdWeZRJqgkT+u9Vjqm RE155hdjSpIwr48NXx+E78SUDsJikiOUd5qM45TOu7fnc5EgzL0LFhAW3QVLb8eU1b25+7Z8 m8qXqTy2rje/TNl4e/7o8ZP0eU3NS2qMtqSN7fbb29STU9J9MxXDqdhiW6bPe+v7+DXP5y7C XsIBwmHf/FpuA60vU04Y5dwnXiOmnPZhLfFRjp1ykXCFcJ1A/XfxulVj9NdFa5WL1yqaFxfV dVEdF+cB3czpNA6uYiNfukoNuy5aT3x03kXrh4tyiotsudjWVHN8U+NJdXmddHHuZ5uVvePM tlxxwwafc1Eud8032nXHPPWZo571xJwntsVro4vyvovmybU8rb7XmDv+7KKxd1Eed1HcuTaZ OrY05NwFfdfl4rug1Ne7vqatsT2YmIa+a2xqvfzPrJNzfLevhQt9vWtg2nrnOmb4pYvyv+uM KZPPuS6ZPkv+5qJc7rphfK4V5pFydW22Ebe1uUY8cb9qKf/WUv6tLTTjIhUHZl7kXFpbYua5 +t4Yqa0w8hfX78mBfWOrT1z15BcztmrNXMz+XzveaGNP/ZlGvNVS/Vq+Dl27lvJf7Uyj3chL 1IdaslcbNut9Uf7pk8fvqpNq813ycQ+mpeHzrvUF+ZTn4Tb0zZPpuXJBWo5Mz4mjzLpzzXMl Ro72zjTm2Osz+uml63lJz5swyjlnech3vFQP+5c5hq6XroH9Bu07vJzrzpj5bKnpm+aewLuC QDmB13/vWjPPbTDsejcb4Bj1biPsJOwx8rCXcpr3kJk/KV96j5p1j/t690xH0vLo5l4b2Eud onbvM9vVNw/3ycE9e5hUHt5s2jjrm+9ebNZJ1T9v5GZ8Xm+MAfp2wSxbk4ZNd8G97AX3+Xr3 dEd8Pfu6HpxMQ999XWqP9p/Zm+X6bt9/Ffh69l23rWW7zboDesckFVu1i8wjx90KX++ex4yr WvKJ2rUmyB9qacxraf5qaf5q95ggH6g9dLu/1x41cdyIr1qa51qap1oa/9rLd483zo211wh0 b+O2EDJ7483tTJPzTAwywLHnHkwoMo8jemPQXUagfOeuSos/6rO72miPe7KRs9xuY+1JgfeU btrPuRuNPrtp3+aWjdzF+cOtGmtKSt9N+zU37cPctA9zdxj+6F5GoP2Um/Y47nXGvsC90bRD 4+emPYl7u5GPef7dtIdw7zVxwBhzHjs31+si0F7CfdrI3e5zpj7tIdy0h3BfN/aA7m5fT272 2HrXJQ/tJzw5xv2IJ9+4p/DQGumhNdJD+wZPpTGOnnHG/Qiv3Z4aw4bHa8yzZ6oRVx66h/TQ euih9c/Dtmmt88wx1necm2/EHMvcbg/Nq4fWPM9yo+0e8j/PGmPOPay3yeiXh3MYxZtnt5ET enIu5TDPQWOt9FCcefie6aSR7zzcnkuG7/J4sey5avgz+4KHxtUrjHHktzHu33v/T//6NsZf 0rMyW4ltH/9F1XJQvC1ExmBCEWEEoYwwhlCVdqw2j5MJbkIDoZEwiyATVEKUkCTMI3QQFhOW EToJqwnrTGwkbCFsJ+wi7CUcIBwmdJnXOkE4TTiXdryY9vkK4TqhW4hMGyEr7ZhD6E/IN/T5 mDmUUEwoJZQTKtOO4wgTCTUEL2GqqT+D0EQIEnRCnDCHMJ+wkLCEsJywkrCGsJ6wibCVsIOw m7CPcJBwhHDM6FfmScIZ83g+7ZjSv2SMKY4nzHpy2vmrhBv4F9+in4NA8dovt/fI49NvAKEg 7VhIKEk7jiJU9B65zf3GEsab9Sf9ecCcpWOyAb7+bfYG9IGLUG8eXXfa6TeNMNMY734+Qjjt GCEkxNueRZ6lnhWeVZ61ng0MR8Kz2bPNs9Ozx7Pfc8hz1HPcc8oR9pz1XPBc9lzz3PJavJlE Tm+ed5B3sLfIO8Jb5h3jrfJWeyd73UCDtxGfZ3llr+qNAknvPG+Hd7HnkHeZI+zt9K72rgM2 erd4t3t3efd6D3gPe7u8J6jeae8570XvFe91b3edrS6rLqeuf11+3dC6Ym+0rrSuvK6yblzd xLqaOm/d1LoZdU11wTqdEOc6dXPq5tctrFtSt7xuZd2auvV1m+q2AjvqdtftAw7WHQGO1Z0E ztSdr7vkSNRdNelGj8TyjXphkoMo23u9PpfKTxpUP6C+gDCgvpCohGhUfUX92Lqr9eMZ9ZPq XbQmDLzrLy4I8xcXMvGLC1n4xYVs/OKCE7+4kGPhX1zIxS8u5OEXF/rjFxcewW8tDHQOdj4t HnU+46wWTzlnO2XxvDPsbBYTnFFnm3jZOdf5hvA4Fzi/Leqcbzr/VXzN+Z5zt5jnPOD8WMzH ry+s//+4ZZKUK+l4X2WneFKIYcdMUKQPO2PivIlLaTKDonvYDVM+w/+43ZALHSayTVCkF1IE FVJ0F5JSYYmhWzjK1OeyirTPY83jeBOTeq9Z6DI+F9aLJz0OomxPrmeAp4Co0FMCGuWp8Iz1 jPdM8rg89aBpnpkenyfsiXgSVDrXs4CkRVSjxIxGIx45Etd6dtJcPYBf2hD4jQ0LfmPD6ixz lgmbc4JzorA7X3JOERn4vY1s5zecs2geAs6QeMwZcbaIwc6k83Ux1Dnf+S1R5Nzl3CWKnT9y /kg84bzovChK/h9bl7q/bnuO+DR7kPh9kLMgl0Muh/wM5KdtLub2eZCjxMvsb0F+DnIQ8pOQ X0atEcRLTWt1sDaXz0K/0VbM3O7lt57sSZLzbIXM7THiW6HzPa77B8h/eA925qM8ZLTKbFsV LLdAnoRyyPbXmDveQvlXUDKb7HzILfzDaftUtLYKPTLqPgmdr6O1o2FzNuQvQw6g5S+idzLq svy09Y8oeQryh7BwH85OQrkCyy+ivBnyA5Cfh04prt6IqzyAqzwP+UXIhn4F9H3ER0EeBbnM VgleAQsoAX8G5c9ilJ61h3CVSuiw/Iy1E7X2QzMKy2shr4F8GPJiyLu4Dd3joF+F8tHgC4iP BH8G8/WMbQL4l1GrCdcNgL8rJEvYvoR4lX0h8W/b6eqWOORHwK3gx+0riXewpvQg+ErUKgMX zK1vQHOt/TvEt9n/gfgQLpHOsizdxNlV0J8O/TWQy8HzYPMj6Ayz/Zx4vu2nxL22Lr4Ky9K/ gb+Pcp/tfxF3saaUCT4DtSyQ32NuLYTmbJQrrC91w8I7kN/D2QacHQT9Cah7Dvz3No3Ka+ys ed2mkuywf8CjweXSLPtB4r+2kedYhrOOuGl/j0qc4B+bJcStL8DOcPAi1A2Dd4IPsT+Os6/x KDG33IR8DPzX4G/ZGnmOMh4DtzB33ALvQslw8Ol0rbnGDELz244/8DxCfsTgqPUIaj2CWo9A ZwvObkHJcZR0oOQf2ROkB1kmbmHOFoh3oWQ45D/AH8g/LU3Qn4O6ZSgRkIX9DDiXFIOvRfla 9GUb5G2GjBZuQwu3oT3bHJQ9rL9Av4bAA4dAfzRadRb8psHty9i7cHYVrK2CtVWwtgrWVvEo kQdSG6y4rtW4Yh5q5aF3H8HaR+jX72m5I24/C34A/G3wWzhLsWYdiHm8Ds0T4JfAr9uPwjeu sc9wCcXRAfC3wW+BH+VZhv6vYfPXRgnXku5Hq0axLG6yDnnUAfC3wW8xt1E2sEiG77EsOWHt Y/tPmHOJuJkxDfofcnvQkuHcI8sttKEIJUUoKUILi9DCIuMs2l9ku0Q9/Ybhyfar7MO4Sifq jkHLg+BDHHHoHAB/G/wWrjuafZv1rXaDYzx/Df4WrL2FETvIkUUZaS28ejd81eDwQMjbDA7L qyDnQT8P857HJTQ7CkYenHtHY6igv4hZ5nT1sxh/LtkE//ky+EvIgQPt3yf+kaOG+BKU/465 BE7R8X3M8v/kaEXJcWhORxTkgZfDThlz6xLIa+0r0HKqZR0N+/8NdcdB/0PIpeDvGv6MzPkO suivEAUZXO64wb7h2MDjZn+M69pCPHqOX7HscLFs3QHPnwh//nfmGTbur2O57TS3Ft61AOPW wu2heHRhzEeCD8SYjwQfiJEfCT4Q4z8SfCDicST4QMzFSHDW/xTtfxOW89H3MHLLNvA8I3c5 nkSmKidewC2RbrIs/RgzW5XxBGcw6FshH0etDiNHoeUdiN8yI8/wWesbiOs3oLMWfAj484jo swbP+BfmdK/OV+Sz0+E505EZ1nAJrU1sfxLOlhtZAnU/yngFHkJRYBkJXmn7JbIT63wFJcNt v0IMfkZ8HOLlioNWXstPuJwi4jNkfooIaTbkH3KGt59DXAjWt9cjD3yCkoHIOe8j1vplUD6U foR4sWH2b/BsUkb6BH7+CSL9E0TuJxynJkcMQu6yITbZjkWx/5b4A8zJwlHUMvIPZ5hL6Mtc brPVZf8R8Voj12F9VNCvWRm0g7K8YfSacw5Zfon7zvYp8wznFRC9eMHMh0fRHuadBnd8F/wq ssca7BY4F93E2WMm5yxR5/gWcshoxCzzFzOGYqX+FXLUrzCStFJL+2yncK3fIn9+xiODs/8C zUchlyBzjrT/DckXbJOJX7aFMHecRUfjuqMhZ4B/F/09DG6xf0o9yrTrWN/ZTjl2KYUYq2pc 5QPwQ9D/OSz83MicuLob/FOeC6kYmXM68vlPIS8Dn22nHaZlKuw3YNYGw85ZlCDzSyfA26G/ iXst3bC1oI/txEtsxzifQOef0KOPuZ3SalhYw323j+ZRshcxt77FPkl5iaxZP2HZ1gq5lVtu 9WCWByJTfWZmKvarh9ia9UvcQloNude56Nd/2E6S/LTtZyRvQUkFWvJb8NfRhhPoVyXketSd YNtKvNrGK/Vylmnd4bE6Cc0i68Mk/x9Yuwm+EeUvwsKztg7ivwV/2U4xbrGhbY/hiu9Af7Pt ffY32LwB3oHyT2GhEtaOQn4N5fvtp9Bm9vxv826NdmWtxFdwJqfyarL/iuMZ0m+2cUwFmdP+ kGtNwPist/8McdcOD2T+U969W4Y5XgF/DrwEPAv8VfA3iRt7XS80y8G9jhGc8ViW/s3kJeBZ 4K+Cs44P+ktgbQlKXCiZaeccm4m6mXx14iXgWeCvgrP+s9CcAc33DI693GzYmY2WK5AVUy4B zwJ/FbwBeWYGjdLz2Ht3w2Y3rL1j2LRtZA+HnQbYaYCdBthpgJ0GjEYDW7NOYE1rLfiraPk5 2DkH+X3I76P9wxwfYDQMbvT0A7QK3J4Nmx+g7nPgXN5upzs+ixP8Ybqn53z4IrIcZQlLLcr/ nrn0PuSAvRrRzXwTSo5B82H0NN+2hfhcli0W5tZJkGeDK1zL+iBzWn24bi5qvQf7F1GicyRa Guxj4MM8hkt5xBzjuKeOfcxt/51r2T7jHbL9Y5YdC7DreBZjmMTYWqA/DnWPI34rcO/j5vtZ GqvZGKXZGKXZGKXZmKnZGCWWf4r2vAZ9K+RhGGeFOY0evNdey17Kd+7UC14L/t62h0ryTb81 PDML3mj4ZAm8K4vv1zCnhSifDZvd4O+YnFe6dzLi0GedQTxr5A8j/i9r5wKuU7U1/rnmXGu9 u22bLm1yy52Q67ZdkyTXCEmOVE5sdipyvybUkVsS5ZYUx1GppKOkQj4kpIsuO6SSSo4UXVyO xLu/OX7zPc+T/X3P/3T+//9znvPbY4055lhzjjnnmGuu9/VG7zz9fKiNTS1K56KZS2tHuRw7 xbj1mOxiTgijSio4v1vee5zfHd3n7B+XE7rZFd3m4tlMMnw4QGSzBj6KfmU03HGpWAbYu93f MaxA3U7C+C4st8jbiXCHvLswB/Fwo7wPCYtS+jK1nhImyqIviYdzcBX2t3EynSjjbl6R7G0O ILeHDYVhRTnPhpXZl6dj/1+M7KfCaAU2DUUOy4ilmUFWOYZ8J6U1KS0ljNvgwZ+gV8EO3Osq yYFmqbzxMO1knzXf8FQwnXPBNnluN9vlROyenZxNMFviGSwnqhPQPCBPCNFx/GyCefAT+Cl+ DsH34ZgwH31feZoVRluQJ8LXOS+f5nT8sjz1hVfx7LchJWuhPLk55qGpRqnbWeImxH8wlhmw WTzOcTMeZsFjnuLBMQ+NeFiD5ePUOiea8Bwanjyj+eyP83ki3Qbvgft5wvyQJ8ltPMcu5QSd lKdKN5fkCfkwd+wBX5FMG5XGZ2mpG41HHu9l8eOYh8b5if4iJ+WEpl8mKul4HX6O0s5Ost7D F/BgUxQ/Fj+W+LxAX16Q+ETNRE6Mih+DY2Vu4GecJ1G9CP+rpO9mNM94ez3l+c1xJ3wRnsPG 5bH4Gsb6fizbRe7EES2MKzhvV8pJ06wTfXiJp3hwfBGeg12kd5RygjbbRWOWU/eIrMrgc56T 74UL4FaeJydzJp3GmfQ+npdm82zAOT04Lk+AehmeSyF/IKdm0zJKytpB31D8hF9L+0OevcMB nugH0NoBtHYArZ0trQpHyNk5fo9aiifGcvSdc7e5Ab7Gc8LL9GgBJ+i5PIm9i/86ntylDnep w13qYP+uRDWcJveKs6MJcCdvNqRWCU80XYnGaSJ2JvqStdCcWe0p87OunJ3dfHOaeGjE3EC+ gx6NY02Nw35v9B0j4ikRLi/n6DAUTdQv3EgLRZ6MXIL2l0BTnNm4CPaKMp23Q3IWjq6OZzvN x6KPllDaVmg2IJ8Qm7AYZ+dt2OSJfZTO2qkAb+Is/AKn4J+EUWl5TovGS624JXdphc+32R+/ wPMavN0PrZy4w3WUPsVqyoQXS+lFvClK683JK1+ydJQj+S2xhRzeTmT9GWfzJqypc6yXpX4V o4nx8Jv4TOsdPulqFWMX+FVa6CIvo3NeztEuX5VmXOpBOV8/yfn6eZGdZT1YmpVeD5ZmvOpB qftULHngIG3gTUXYIy4nexz5agccRw6pKifx8Cs5fYcvCd0+KLNrV/wU81zW+Dbkc/RiKXUP khtfEU38keSK+C70W2B/8sNB6t4IjyUawKmyA4omSsiMSpTFviR8Cp9kVLNSztphezl3hH1h Jjvyn6KlzK6TyM4+7oW+L+evDZz4clhr38Sl2fucPuIk69agnI/e4pnqR7EM7yMPTJGn/cRi 1uMZGce4M6M5XzTxNZHEp5ycat0Ml5zGuz69VJhYLHuQ+UhWnxktp2xH6cU65HWs7ukiu7qe UlqH0gqsLC+PkzaEDeUubm91J7KwBeeyvbzPyRO6FfQiO+lJ9lA5MY2RvkTvyw4b9yC7/syT wHJOMQM5tf0q5/SQd49mmZzQ9TTJ8PGd0uboODlhE9m1LxH4RGR9CL5P6Q1xEThU7iizyI3F IdmRKZ0Ij5NnXqcWb0HNJXJmdxlpDS1fI1kudnM+LMxY1IH9GLUJoeTbt2A+ff+W0SmPDad7 MxfOgNej78kJLk96GnZEUwW5Ubgb/3LuI27BZ0Qjg2hcykl8ipziw3vCH1wLB1CrkzxfRUeY LdvCm8lF0t8N1N1A3U7MlnJE/ns4nfasZ+zKcn58iBF/nV1mJWPdEs2Lco4IOY2Gm7Bvh7eX hdHHyGvJ7THyRM7U3kNzeL+c8cMvWMsXy1Nr2E3aGUXREskYtHMxs2U9z4qTzHanPySRjD+R Wep2IuFUYfhNKOPyFHn+HpGj7yLZ619ht/oSm4FkwrPkyX6UFheax2SXjGZKC+PriMAXtHaf nPrDQnLqNyM4QR+jVV3odQX61VZaFb1DBP6E/iXphdkaulND+IR84hYuMZ/SBifHe/G/B/sB jPIAeQ/g5rnc8UP0VZAfT9mIz1nyHiBWwnCZvA0Iu4s+HkMb5mJfTt4G6J/w3wd2R/8VHrqJ HD2KXM3fhbdzdViV7I/xZ8RqPeRJ2DwHJ0C/HkvwHPsG8TThZ06uJbuS2Ub0FvL+szh36Qxb EbFdZIbzZLMzxGcGbM8cq8tZaT1snJKvgLVgOryJUnf2iR7iGf4HLB+Er0Qrnf/myHXg7BRr wXQoHtpjWZ6T5iTRhJPQlERznBPuTM6Yy+BN8APO8rRHP8OJ7xHeLZyU05lba66WfhrLk9z3 XnniDZfjc7nUDR9APpziFbAWTIfSkp/lnYA7+fZxkaxDH1+VT7TNP/BZC94Gt8jJN6yBtxkp XgFrwXRKb4IuYuFu8Rxvlk/9HJ92Ht6kVtUUJUov4bmDRMPFuSsREz5M38vL+wTXC6eJvpC3 De4uIn+OXJW7VxVNuJq2tRCaE6E7X5th4X/Juohmkdmk9Aylp+CdaO6Vk7VZDe8STdQG+7HE tgI8KXSZ4e+yOyMvh4elVnReGO7BZ47ozTQ8V4Q/kB9mhGsde1PaiAgvg3PFJq26RCCNOEQP c948we65R+TEEPbQ1ZQ+RIQnEb0r4QPMsQV4qC4+016SJ6L4EU6jG8INrnRsam67c7R5MTU/ czhDycyZJrLzk8OI5xBhkRvJ24lwDHd5Uvy458a6MhOYt2VgVdqzlHv1j4o5ZglNF+I5kTE9 AO/CfhL2lZHHMPo3iiauKjMkWoG+ISxFO2eIrI/h4cH4FviLjB0298rox20ofQNNC3yuQnM9 LR9DzLeIPt4cF6bNhYmGfPuiYb7bBZTJfxv5Bfn+AMzKfwa5Jpwu30ZIlT4L+S5B/nhkz1Jw LnpfdzXyarytgl+g+QJ5HzZOrwflyzvPlvABOBpeAg3cB6cKg2JClUSTBZXQTEJeDtfCSl5O yvvqQ9T9Dc0SeCu1liFnw0xsvkOuAsvB7ug/hDvQ5MIuaNJozzE0Gs0beK6KJgcORu/bPJj2 vIrcE5bBvi02h+Gv6Dsjn0GOkWvDb5OSD6txX3oUWNEE3+Pnauyrw2roF2HjW+Lt98CFaAYl m8hc9fEXWV8C98G/+pgj9/cxR1ZwOVyblLW828dcNME8+BulS/C/1vcLuTTyS5QaWN/3BTnw fcFDkVQvRP+V71fyPefhz3jIRd/U9w77rGRFp+mX7EkvetLynrSwJy0RZqL/FbmS0N23J557 ci9hM+7VkXiWxf8JWIa7+HnCnDGzYU361YhaD8NWSfd8Evg214Wvw6IwIUyUEsbzhOF7sJn0 Pf4b+jSRzWupOdyEmTlAPoH1MzMpn1udQp6brOrk08nGjOZhxvEw8Rfe40f5/H5ZZfSuZXKY rDLk0V4+vwu5EHETTqV0avIGWIhIir4b+ixqKWSVkgvJGkSzPMVhUGrdgOYG0QSHiP9vKQ6D hRiddlDkW6XULMPmuxTFWz0if5IeXenXTlLegLVC/0tqtrjI6Df9rDj/m5PHMKPWiCY6i816 0USlWEcdz/O9BSK8MFlUnvaTTWWdnpdndWZg8ITENliHZqLQeZbTExnAdMX/GaK9CMuFzMwq +Pz1vHwiUDcpe01nehETjdjLRL4MvS4MDayW7AgLMT9FcxFx+F5qKeJmrk7NWInhn+EibO6D OWjGpLxJbMsi+8gvTFFstiXdnqItPX2F+Pg5X4v2HyUmP6Vi28zJzHNHeYvOTA4ehe9DTd+3 SgxdC5tB0ZAPTRv8fAzfxRv5P/hUbNRxZnKVZBXHbugXoX9LNOoI+iIwg1GYn1r7Ml698FnR Z0i4Hx5NnqOnTaF8XsMOEmyBq9D7WeHzZHc8f09LnkRfX+ZYyPwJD4l9VD3fxcT4/PmhtMf8 KDEMxyCPoafXU+pz3T99HpD+OkprL8amAvri2HyB3AD576l86FobNEbzM/Q5hH7p5rAHZO/Q Prbkk+BzyK4UPIf+GtgE4k13SronJU0+MZdiuRqyz+qPYF84Hf0cLH0bNqCZC8/Bt1N7k4zO At9mkcMXkCdQaxi80+9uzIqYOVYbxtQ9hLyH0kbIa1JzQGSo/S5cEc2HaFrC27hXGvr98A30 7A5u5/3AtZ+sHiQpvQd9z9Rq7Ym3nnjoSd7oSaloDiP7XbsE9M8bd+DtHej3xOHIPDkE64lY Byy/YI8o5kdcdgddHnkoll/Cg2T+gZBnnvAuyN4aEfmYJyXjx3EwvdiRn8vqbivx8aPm9al+ yY7Qnez0BrwKmyrnj7CP9ITDyOoityPbfws/JGN0Qd8leRUsRHwKEX/R1yKHvEGU3kjJshfU ozQnxWG0thCrSWxeTcW2HRT9bbAMmb8r3nakKHWvgYP4ZOQEn4A8ztvaxxOy49dHrh9/7+o2 QL6MZ+Bn+O5QZz6pbB7lS794n/OtyPpT5P/izO6/3ZHkOxhV+Px0B6fOXnzG2iu+UXIC+u9F 1l4+EbWVnMZnr6XldKCydHMnz4zkzVV2eIec8cO/Oe4SWX8QyvdJXhKaX0I5D+aJpTosDAZS q4Mw2iQMY1g3lLeCHfDWHT8reTfSEj/nxCbuQd3u/r5CvR+2Ccs4njH3QPfUbXKRR6PvJTRD zQHRi6w+Ega1Kd0vjDKxmQJXmYccNR7ahAF9Ef14iLdogb8jPAAnw5eMvE2tJdTzkCtGvZ18 SOTgpHyj2LXQnQhMhmjUTuNOjupzod4oerVT7KN21C3pPYhep5kNsqbMOsn2Zjl6qXVcSqN0 bFbC4+irC51ePGQLo2W06gxsDieLH90r1WZnH4TCcJ/QdIeraKHRgVDe6iiNrLUWTbCJUs5Z wdd8a/oHmcN6puQrPU36peUz5SdFDk5o+Z7eHi3vlmfpiY5TtcvPQTGxDxbAxdAIzSQ8LNcz HNdqmeGVjHz7qJWZIVlUNMFv2CzhjrdSaxlyNszUac7mO2yqaJnt5fTFMrJaPm3sIHKwA66S /4aj7qLTYUnJAHA4nAOt0FTFQ47IerAuL2tKu7mqh4isi+svZO2jfwPLnliWoW7bQJ7ENN4O B8/Ls1NQ3WmqBUednBe41a2LBfLNQyNyUFvXp4WuL+psmCk7ppQGEZypG4tGv+Y8d6JuNVg9 Je93TAjVKbwtgvXxXy34hhi6+OjfggkyLmi+xfNCbBJCdVxqqX9KS/SnSvFvHBoI41uF8v15 p/k78tvIp5DvQJ7vZtSn8QrHCbCFMCokNP+Aq9CUhhlCXRk+jf1t2PQTxkls2sI7KG2NfC/y fVjuhKfRN0O/QZhohTwQ1sDmY+T2sCmad5DnIj8Me6FZQnuKQn/fCPkcreqAZgfcT63zyAdg NTRD4D1o6G/YiLozkUNK34Mn0HRCvgk5wb2mC4N/Ivvo7cXD/dhch34f+gbI25HfJg5Ew7wA d8G61Po0MUg+d/DjInJUCF7qRwe5NMyA1/jRETl824+RyKYfHAZH422iHylqVfLjhTzcjxSW O+Fp9M2EiVZ4roH+Y9rWEHv6Ej7kI4NNX2TjYyIaPYL2lKPlvvQs7E2UNiEPxaYYPEKtPdj7 cSwPL6G1jHVElCI/B3zLH4W+VZ/Rcj+Hf8ZyBG1bj/9c6Odbf2YgbYvvxJJ7md1wKza3wAFo vke2wrQD4jONmRzXpO5gvGGT6IY+m5bU9OuF6H1PrbewyUR/mLpVkPFmfkBuh/wAcjqyn1ET 8LOKUUjSr9ZwAxwIH8Hyz9Rah8wMie+m7349HuK+05Cboz+GJdFIjEPW1OqJPNLPbe7+rI8z rEDdFciMlyZ68RNwKRqfK+b69YKHBozydliMNnfGJgeypqKqyIxL2BU2wcONyH3gtdjkwYOU 3gW9/jJIDtGs5fB52BH/W+AzcBE25EO9jFpHmcPH0TAWmr6EayBrNrway7XwE7gab3WQT2HT A96KhhwbYx+TixI3Y09eDWNk7hKTV8OTkDVifkSmR9EYNOTPEEtDhDUz0HyNzCqLXsFmJfQ5 bQZ6n2lfh4yj8VGdCsmK0TfIC+FFtOoKLJlFhnVhaKFhdwhHUcvPhC/RE4cEGSDqjn4jetag uRKy9uMXafMgyMwJ6UXIyIZEVfte+PFld4jJtKEfL+qGZAbj7/Ua/Aj6WeQzjM+Efj96kLax p4R+X2NWmMLIJSArJfaZuT2z92HmbVHm7X7WOH5CVmVEnM17lJLhw8uhzwOMb8R8Ngtoz1j8 z4HMBDMe+t35K+RfIZ7TyK5ptDl6mVqsuITPac+hZ3RiSsM3qUtuNEOkVUrlN4el4Auy4yTl 070JsIUwKiQ0/4Cr0JSGGUJdGT6N/W3Y9BPGSWzawjsobY18L/J9WO6Ep9E3Q79BmGiFPBDW wOZj5PawKZp3kOciPwx7oVlCe4pCf98I+Ryt6oBmB9xPrfPIB2A1NEPgPWjob9iIujORQ0rf gyfQdEK+CTnBvaYLg38i++jtxcP92FyHfh/6Bsjbkd8mDkTDvAB3wbrUzab0UngNfrA3w+Bo NBMprQSHU6shevyHD8G+0HDfEbAcHrz+LOxN3U3IQ7EpBo/APdj7eJaHl3BHYh7R2siPBW0I H4W+JZ9R6ufSz8i0IVyP51zox70/M4G2xXdiyb3MbrgVm1vgADTfI1thGqOZxoyKa1J3MN6w SXRDgz7tLTSZ1D2Mvgoydc0PyO2QH0BOR/bj+Aj8M5p1yIxLfDe98DP8ED6nITdHfwxL+pUY h6yp1RN5JJbPIlfAfgUy0db0PX4CLkXjVxyrIOyMnAOZgVFVZKIXdoVNqHUjch94LTZ58CCl d0Gvvwyy4jQzP3wedsT/FvgMXIQN2UMvo9ZRYXAcDTHUtDlcA5nh4dVYroWfwNV4q4N8Cpse 8FY0ZKQY+5iVm7gZe7JQGCNzl5gsFJ6EzGTzIzI9isagIduEWBoiqZkn5mtk1kL0CjYroc8A M9D7vPQ6ZFYbH9WpkBwSfYO8EF5Eq67AkhlimL2GFhpyaTiKWn7Ev0RPHBKskag7+o3oWSnm SsgKjV+kzYMgMySkFyEjGxJV7Xvhx5dcGpOXQj9e1A1Zv8bf6zX4EfSzyOcBn2189n6QtpGB Q78LMCtMYeQSkFUQ+8zg7X0kyXXh5ZD1GDJ2EXPVLOBeY6k7BzLKZjz0+9RXyL9CfKaR2dJo T/QytVg1CZ9VnkNP5GNKwzepS3ZSu41R8k5MvrtSNUrnbYz8++4OvBHKNfKp93LeI3Wk9Mko UvIGKdNxEW/StGj0d+hniz6MxdJtQpG8OUF/izD6SBjWRX8SD0MpPSKMhyPnwg74PO4tuftM +bfwJkPemOkn0TyQet8lb/9O8fbsWt6knfVvzNCskFr6AzQa++NwJX3MEOrJ9LQH78S287Yq GznbvCq1xEbliz64OPWWzFF9xTuxLPx0p1Yb3lw1F01wcbhEybuyVbJqKH0S9hImh+bLv8zt li/fFNqYL28me8kbDP2ByEFt5N6UtkF+A3kflhNEDpJ4qE7pm9Tag1zce0PzdXI5GqlbH/ZD nxTL4Cyax7CvSt2nKG2MXIvSGPl25GlYNufun2J5lNKxIie7S3vCzr4XSr7vekZkU4R7VUYe qniziiZEswv7/cI4VDI3aImphU0pZA0PYJmGnIHcRejmkMgrueNLyPOQV2JZEi7n7dBh5Fxs RlO3t9zRrEu1WUrHc993aec+5JOpO8psrI98C/b9khvkzZvo1UdJeYvbAZ8LKJ1M3Ysk/i7j 8V4UzRxGZBD+OyefoQ1i31dkvV1abmqL7OZ0E9kNqdVWNK7uE670ieQ6FytmSPBaUt6OrpZS l7ueob/So1p4+Fql8w5/HTlQ/p1mZX8X+RaEa620/Dn0pYh8Cfr4gfiMxuLfJuc7m7XYzEnK zC+LT0vpVthAWhUs9tGT3gVTYZbY6+rJzdx3l4yOyHojcnWYBusL3b02Im/mXktlHnLHKSpT 1o7cV29UReTNJBE7zh27oz8EtzPKy6i1irYdhK2YXcylqD+apNibA/nyaUK5/B8cT+BzkL+L Hy/W15nUKpPIzEROCOW3v1x2ZRaF02FrmQNxYymN9kobom75ZxmLNXAVK1HqlvUtEdlFRmJ1 Kv87no7msUK5L7EqJ2MXTKVtbdCMlrHTM4nbSuTmyZYSn2QuNrmUTqEXU8T/+R/RHOFzN/GQ AduIRteUT3bCpkT4OJrtyfEye6UvwVHG4iD2abBaUn6FIOLzoCXSNpOZ/Bv3GsqKyJPPCGit ooWXJuVTodx8+SZAGn38O72+SOZVcC1zNVciEP7dj5fcPXjNzy6xjJljrneb2dklhlXJM1/7 vCFr0PVOYnhSSuPVcpcgD5+daVUv4lmcuvVZC8VF705tfOIgjNKlhaYra7OXjJc6KxFwMVnF KFyHpfSoS3Iv/Io71mImi597kg9TV2I+XGLi+AJ1D1D3CDNc5nkZiUlQKsnnOJTenDyFLJ/F hMR8KzarsV/hSUwW8/2lhZTOx0MzejSDezVLfcdjM09W4ucl/30n/OfQ5jRi/idGZKUwmEN8 3lXdXUyKkh/qo5ksVDslGi5is8lj82WtkXNaiR83Rr/RtojdR/gu9sclktEymMXYlSE73Sb2 LtoyE2Lusp+YzyO/hTL/XU4jmzG+vcg2U0Wj+C6Z+hyuJVarWZXVmYezsd/oa3GX/rTnKP1t mcrALYit3OUN5swc3wv8pIne7VAR31SRVdxO7hs/Ir/g5Ga4/Du7t1RLOQNyl0Os7qHMtKr4 XyX3dTP8N+ZnEbJWJntNJrsSOwvz3zJPQrJQH+xPk81m05L9Kou8N4s2i7zI7UhunhONUsxV Lf7NLcT/NZ+dUlmxHbtwEzJYU/Zr8b8Ey5NE4y48TEn1wsmxz+dz/FpL7W7ybwwn63eQZUfY Sawa09O85G6y9C5W3wbiIP+ytYcw+onvpK3Dwzxm+CA0LYnhdPHm1vIa4iZjfQTOZl5NQF+U dTeZWTFeZPVPdrT30UzAPi+1olexZ/mcnyVZhfmQITFXn9OvPn702a9X+FLy6h5WRymy6GQ4 CE2S/bEkTxHN2VM2oSHnR88xQ7KI5Hg+zR/NHC7HjsDTWoLnGbeD81zBvUpJrExearbnkT3W kQMVvfCZPI88IOyDzebkYiWf0Q+lVZJnbsBDF2xWMocHoqmO/bspDmVchjLb8+jpUHq3jl14 OW12muSv+V8zE7rT37ud5bN+x6TW8NRTmX9yk3n4FnUnq/JO3kwf19P+L4XJBuIt/7T8FpZj P2czjPd7R3gjx1vQND57Uuli49iPT+tEo/BwcyTfTe0dn5LfSUNOR26A3AA5O96PZhmaPORp 8r3WeBVyHvJ5SguLnGgkv5CGJtuNnnj4BJuQ30bbK4zPSBsS4iczbitMLJBfSJN/zZdcmlgp v5Am8vk3RE7eHy+WX0hL/CifLCcugWf4JbRvxb+X5dctnPwren79LPEscmvkgfI7adEO+Z00 38f4kNinFRc5kY7lOVrbED99sSlDaQf61RT+Sq9nU7oR+Qz66mjeh/JvpbPSKuGzBXe/k8/E 85A1Nn/B8xqilMcdNXefgfwqdZvLt5E9pf0uhgdFn2aRm+PB67Now23IzZBvx8NX2BehPZD2 ZPn2xPNoz1b5ZTN63STV64Z47ovNzdjPQG4KE9S6CpnfoEvchUx/E13phdwlW9ESfnWtYRxR 2gs55C7HiMk0NA0pdaOTrAcbJgychc238GMs89E3oM3raTNjx7cHzfnjyE1gT7nL+e3ShvO7 kb8UJvvB3miOiOX5tRLhlH4ULARL4KcE8j2wCbXWU+sb5B3oic/5pdzrdfTviJzUeGDEU234 BZsD1KrkP0VX6cH0tKPK5IwbPkhl3j58wF1q4qC+I+9WL8kOdEP31hWVy4v5+aqEylCxKqeq qOKqrmrk4ttKXav+pG51Pq5X96j7VI66Qw1Ro9S0lH1hlVCXqqrqYlVPNXZerladVC/Vx921 u5qg7lf91Z1qqBqtpvPfr/V1rEpzGaeay+j13b52hWqtOqub1J+VVjeoe9Vf1AB1lxqmxqgZ qqQyHbt166Cu7d71uoqqX4/unSqqRXi5hN+jruByenXnsYF7ErhGtVfXqd7qNmXcDt9DTVRT VK4apIarsWomdS5SFdVlzmeWulK1UV3U5epB9KVUUReHSqqMquH8NlRN3VNBW9VBdVU3q76u 3bXVjWqSekDdrgarEWqc28d9C4qpQqqyKqtqOg/Z6iq3U3dU3dQtqp/bS+qonmqymqoGuiw8 Uo2X38nOyRqRY3rCPjAX3g1Hw4k5fQeNNFPhHLgYroCr4Ws5fUcMMFvhTvg+zIP74cGcnMFD zWF4UhhqWBSWh7Vh8/6D7rg9bAc7w+797x4yOOwF+8D+8E44FI6GE3KH980J74ez4AK4DD4H 18JNznHfcCd8H+bB/YPuHjU4PAgPwx/gL/AMTAqjcNCQnEFROiwKS8HyrnB4VBXWgvVhY9gC toYdhoifLrAH7A1vg7lwEBw+ZHj/u6OxcCKcMlT0M+EcuAAugcvhSrh6hBujaC1cD7fCnfB9 uGfEHXfnRp/Dr+EReByehGdHDM4ZGiuYDjNheVgDZo0YUb9B3AK2gZ1hD3gL7O+YFQ+CI+EE OAXOgvMcG8ZL4Aq4Cq6FG+E2x+z4XfgR3AcPwEPw6IhR/UbEP8HT8JwwoWEatCNGDR2RyIRl YEVYHdaGWSNdJBNNYUvYBl4Lu8GeUN7caJd7Mv+Dv8at87Kq3P+VFPAj2/9nRkree8UuL6b9 f7sKufJyoCr8Dxb+gzQuzxXi9/z/X6TAZe//ncX/MDUjop1XuQpS+5Qw/Q+z2B/mpf+DRf8w K9JSw9/gd5Qe/F5n/y2N26lKqlL/oXQJknb7U+X/6G8Vfv75j/+tpqr/B38Dt5P+e/77mARu B//3LPKH2MA9bYx0u/48tUKtVdtUnjqkTgZhkBlUDbKDNkGPoH8wMpgSzAtWBGuDbUFecCg4 qUNdXnfW4/VMvVg/p9frXXq/PqrPmnRTxtQyzc21pre504w3M81i85xbg3KvND9nTZcC1/0K XM8qcD37d9dhgfLYLfN9KhH87jo9+8LrjOUX1renL/Sf2fvC6xLqQv8lMgtcVy9g36HA9S0F rgv0p8T+C69L1ihw3a3A9dgL219u2YXll2688Lpa7QLXdX937dZftfoFyu/nWrv8UNz38LJu /m8N3/PQzbmSLldVT2k/SP3dn/p7KPX3p//NulZ26m/L1N8Oqb89LmxFrZkX9vLyxhde101e aF+v14XXDQqMQlZWgevsAtcfFLj+qMD1DwWuj1943bD472aZExpnFrhufKF946YFrguWX1vg unOB6y4XjmKzax2ti0xOMF/lBkvItv3c/5RbqfPkGxlRMfaK4irO6Gi3Z3Sw2+xmu9Vp4uBY cMzZ/RT8pILgl+AXpYNTwSll7NX2ahXaa+w1bt+U+aBNWyPjpXVxXcJp3L2NlfaYwq5mXXdd 0p1Ghqslars6qM4Gma4Naa5VmRnXK53RIaO7Y8eMGxyld0VdTq7oTgv13ZmnhT2ijC7q2vQd f7dbd9LSJdz19/zdbvco7a72OW63+x13qpAZWkZVtgddWze70q/4u91+7f5uddff8Hf77ywP pSy/TVkeTln+I2X5r/Z2or2dae91tPdfJV0o6UpJt9+X2F208F1a+D4t/FfJB5R8REkeJVol tPufW2aFtPwrk6K6qItqCRdVk9Euo72L+ma7WcWuTVtdpNwpW9ai4fNC9/8arv79rlf3u8si QRE1KSgTXKom899KnhL0Dm5RDwSDgsFqOv995JnBsGCkejCYGcxUDweLgsfUnODn4Gf1SHA6 OK0eDX4LflPzZGqo+TrWsVqgM3SGWqiL6WJqkS6pS6rHdFldVi3WVXQV9biuqWuqJbq+7qae 0CP1KLVJj9Fj1GaX/cerLfpePVFt1VP0FLVNT9PT1Ft6np6ntuuFeqHaoVfovWqnKexmzTmT bbJV0rQ2bVS+6Wg6Bto8YZ4ITDgy/GsQRjlRTpAVDYgGBA2j26Pbg+zojuiOoFE0IhoRNI5G RaOCJtGYaEzQNPo4nh40S78hvW/wY/q0QkGQzCia0VaPy7g540n9YuH+he/UJwpPKjxLn7Xa ppk0W8lWMkVsFVvFFLXVbDVTzF5mLzPFbU1b01xsL7eXm0xbx9YxJWw9W8+UtA1sA3OJzbbZ ppRtbBub0rapbWrK2Oa2uSlrW9gWppxtaVuaS20r28qUt61ta1PBtrFtTEXbwXYwlWwf28dU tv1tf1PF5tpcU9UOtANNNTvYDjbV7RA7xFxmh9lhpoYdZUeZmnaMHWNq2XF2nLncTrKTTG17 n73P1LEP2AdMXTvdTjf17Ew709S3D9mHTAP7sH3YZNlH7COmoZ1n55lsu8AuMI3sIrvINLaL 7WLTxC6xS0xT+6R90jSzy+wy09wut8vNFXaFXWFa2Kft0+ZKu9KuNC3tc/Y5c5VdZVeZVna1 XW2utmvsGtPavmxfNtfYV+wrpo191b5q2trX7eumnd1gN5j2dpPdZDrYLXaL6WjftG+aa+1b 9i3Tye6wO0xn+7Z921xn37HvmC72Pfue6Wp3292mm/3Qfmiutx/bj013+4n9xNxg99q9pof9 1H5qbrSf2c9MT/ul/dL8yR6zx0wv+5P9ydxkf7G/mN72pD1pbran7T/NLW7y9iV/KTJXEJwN zroslh/ku+wRaXcOYJ1FrLOYdZbQZXQZlaYr68rqIl1D11DpMgtVoahf1E9lRP2j/qpwlBvl KhsNjAaqItHwaLgqGo2MRqpi0ehotCpuK9qK6mJb2VZ2a7yqrapK2Oq2uippa9ga6hJby9ZS pWxtW1uVtnVtXVXG1rf1+W+gNFTlbCPbSF1qm9gmqrxtZpupCvYKe4WqaK+0V6pK9ip7lctW kn+rkH+r2va2vapmb7W3quo2x+aoy+wAO0DVsLfb21VNO8gOUrXs3fZudbkdaoeq2nakHanq 2NF2tKprx9qxqp6daCeq+naynawa2Cl2isqy0+w01dDOsDNUtp1lZ6lGdradrRrbuXauamIf tY+qpna+na+a2YV2oWpuH7OPqSvs4/Zxl6+fsE+oK+1Su1S1tH+1f1VX2b/Zv6lW9in7lLra PmOfUa3ts/ZZdY193j6v/pu974CO4mi6re6e2d6dmR0JSQghQGRM1kqAyDnnnHMQILKFEAaD AZGxMZhkMiIHixwEmAwmY3LOOeccBK+mNGCw8f/5S/975x2fPuqatLNTt6tv3e4ZzZYyF5oL obS5xFwCZcxl5jIoa64wV0A5c5W5Csqbq83VUMFca66FiuZ6cz1UIv6rTPxXBblzG1RF7twO 1cydyJ7Vzd3ItjXMvci2Nc1fkW1rmQeQZWubh5Bl65hHkGXrmscwZ9QzT2DOqG+ewpzRwDxn noOG9Psjjcz75n1obD40H0IT87H5GJqaT82nNO+VOL5ikJu4NgvGlsoas8a4OZyFA1PilXjg jgRHAghnEWcR5OG/o+/v6PtPR18gRV9WS22xCMfpv2Ps7xj7D8UYU9uhnvdm6XhuUUapBymh AJSAClADGuB4oR3q956oLIfBKJgIM2ABLIO1sAV2wyE4BZfgFjxCZQ/MwQzXVyBcXV1Rrh5k u7l6ko12fU22u6s32ihc+oZslKsP2W6uvmSjXf3Idnf1R9sNjxtANso1kGw31yCy0a7BZLu7 hqKNxuOGkY1yfUu2m+s7stGu4WS7u0ag7Y7HjSQb5fqBbDfXKLLRrtFku7t6Ace9MVh3cw3B Otr1Pdbd/w1ExpLnXV3jbGR+tJEZbyMzwUZmoo3MJBuRyTYiU2xEptmIxNqITLcRmWEjMtNG ZLaNyBwbkbk2IvNsRObbiPxkIxJnI7LQRmSRjchiG5Ex6H9X11RCZBYhsuDfRGSpjcgyG5Hl NiIrbERW2ojE24istmNljY3MWhuZn21k1tnIrLeR2WAjstFGZLONyBYbka02IttsRH6xEdlh I7LTRmSXjchuG5E9NiJLCJFVFCmbCJHt/yYi+2xEfrUR2W8jcsBG5KCNyGEbkSM2IkdtRI7Z iBy3ETlpI3LKRuS0HStnbGTO2sics5E5byNzwUbmoo3IZRuRKzYiV21ErtmIXLcR2UuIHCJE TlCkXPo3EblpI3LLRuS2jcgdG5G7NiL3bUQe2Ig8tBF5ZCPy2EbkqY3IMxuR5zYiL2xEXtqI vLYReWMjkmAj8taOlXeJyGiQiIzGEpHReCIymrCRuUGI3CNEnhAir6xIsX4D2Lpumk2rB1nY IT5NVBJVRWvRRrQT7UVX0U10Fz1EbzFEDBXDxLfiOzEcR8GXxGVxRVwV18R1cUPcFLfEbXFH 3BX3xH3xQDwUj8Rj8UQ8dYdZv9HHDrAD+AVTrf/NFxVFReCiiqgCQrQS4aCItiICHCJSRIJT RIkocIloEY1K4CvxFeiil+gFhvhG9Ae3mCQmga9YK/aBnzuPOw/NMgSCpgQpqZU0SlolnZJe yaBkVDIpX1ie4RU9pdn1RL2S0p6byGbtw88kzl0z0eHDEZntI7Jbc1OiA+4BxU+x3uObWckM +kefS/xePyWp4q8kUwKU5EqgkkJJicf+9r0cMoCX4qP4KqriUKTiVFyKpuiKobgVU/FSvBVr vktB3/rgRVqf4UphpQgYSnGlOJi4LwwCxBwxT8SJxWKb+EVsFzvETrFL7BZ7xF6x73OIW7Nl YraYjWecK6znrX4SPyHeiwTyKCK3Fb/vkrj94eyz8aifcO9a8bNYJ9aLDWKj2CQ2iy1i6+fa mM4+R8zBs88T1ttC4kQcnn2xQHbGK9yHZ7f8sM6eE/w+e9bP+EGYXbIxsz73F6OLPmdFA35O 7cRXQH8YAANhEAyGITAU+/W38B39cvUIGAk/YC8fDWNgLIyDH2E8TMA+PwkmwxSYCtMgFqYj A8yEWTAb5sBcmAfzkQ9+gjhYCItgMSyBpcgOy2EFrIRVEA+rYQ1yxc+wDtbDBtgIm2AzMsdW 2Aa/wHbYATthF/LIHtgL++BX2A8H4CCyymE4AkfhGByHE3ASOeY0nIGzcA7OwwW4iIxzGa7A VbgG1+EG3ET+uQ134C7cg/vwAB4iGz2GJ/AUnsFzeAEv4RW8hjeQAG/hHYYx49V5DV6T1+K1 eR1el9fj9XkD3pA34o15E96UN+PNeQvekrfi4bw1b8Pb8gjejrfnHXhH3ol35l34lzyWn+An +Sl+mp/hZ/k5fp5f4Bf5JX6ZX+FX+TV+nd/gN/ktfpvfERq/y+8Jnd/nD/hD/og/5k/4U/6M P+cv+Ev+ir/mb3gCf8vfIQVZ/4shhCJU4RBSOIVLVBc1RE1RSzQSjUUz0Vx0FF+KAWKgGCQG i9FigpgsloilYrlYIVaLNeJXsV8cEAfFIXFYHBFHxTFxXJwQJ8UpcVqcEWfFOXFeXBAXlYJK Ies3wZUjylHlmHJcOaGcVE4pp5UzylnlnHJeuaBcVC4pl5UrylXlmnJduaHcVG4pt5U7yl3l nnJfeaA8VB4pj5UnylPlmfJceaG8VF4pr5U3SoLyVnmnulUfWVyWkCVlKVlalpFlZTlZXlaQ FWUlWVlWkVVlNVld1pA1ZS1ZW9aRdWU9WV82kA1lI9lYNpFNZTPZXLaQLbGEY2mDJUK2k+1l B9lRdpKdZRf5pYyUXWWU7CajZXf5lewhe2LpJXvLb2Qf2Vf2kzGyvxwgB8pBcrAcIofKYfJb +Z0cLr+XI+RI+YMcJUfLMXKsHCd/lOPlBDlRTpKT5RQ5VU6TsXK6nCFnylnyJxknF8pFcrFc IpfKZXK5XCFXylXW74rLNXKt/Fmuk+vlBrlRbpKb5Ra5VW6Tv8jtcofcKXfJ3XKP3Cv3yV/l fnlAHpSH5GF5RB6Vx+RxeUKelKfkaXlGnpXn5Hl5QV6Ul+RleUVeldfkdXlD3pS35G15R96V 9+R9+UA+lI/kC/lSvpKv5RuZIN/Kd05wMjlbzpFz5Tw5Xy6Qj+UT+VQ+k8+1r7QeWk/ta62X 1lv7Ruuj9dX6aTFaf22ANlAbpH+t99J769/offS+ej89Ru+vD9AH6YP1IfpQfZj+rf6dPlz/ Xh+hj9Qn6pP0yfoUfao+TY/Vp+sz9Jn6LH22Pkefq8/T5+sL9J/0hfoifbG+RF+qL9OX6yv0 lfpGfZO+Wd+ib9W36b/o2/Xd+h59n/6rvl8/oB/UD+mH9SP6Uf2YfkK/qF/Wr+rX9Zv6bf2+ /lB/rD/Rn+rP9Of6C/2l/kp/rb/R3+rvDDCYwQ1hKIZqOIzLxhXjqnHNuG7cMG4at4zbxh3j rnHPuG88MB4aj4zHxhPjqfHMeG68MF4ar4zXxhsjwXhrvHODm7m5W7gVt+p2uKXb6Xa5Nbfu Ntxut+n2cnu7k7h93L5uP3dSt787mTvAndwd6E7hTulO5Q5yp3ancad1p3Ond2dwZ3Rnck9y T3ZPcU91T3PHuqe7Z7hnume5Z7vnuOe659HdZ5rbpzn2PnwaRwalmfPpogLm96OiMub346KB aAgnRRPRFE5TNj0ruogucA4zXj84L0aJUXBZjBfj4Qpl9quUt65R3rpOeesG5a2bYpWIh1uU Ie4o+ZUCDGgGnquaqjGP6q16sxCaYw91XHRcYzekR+Zm92i+/bE2WJvEuTZb28iTabu0FzyU Zt1b0Hz7HMz2j8AFAZAOc34VVEATMQNsQHbGr9AHAjd30VIcLVn3aLzBH1LqO3D9uL4T65P6 LqxP63s/HHsclzaDE/VEAAShAsiaePdIP2lt109jvUc/i/U+/TzW+/W71ifNpNYZTX/rjGYy 64x0rgQ66/t7NC5c+8XUsN5h6p/s8aI93rQnySd7AmhPctoTSHs4uLDVPNh2+bj1nHlBXhA4 L8PLgODleXlQeFVeFVRttDYaHFq8Fg9Se6A9wPNxdR4/+F/KsZ9m2P+/8+v/Toa1cuhfzZv/ zZzpI1vJ1rKt/BozkJU5S2POrETZrDpmpu8pT9bDHGllx8TcGP4Xs2Kvf5AP/5gNJ2Ae/C0D fpxd/l/Lhh+yHebF8Zi/P86KxVF9WNojUXlYuqMaKo+Xtu54jaqjPiqOqaQ5pqHieIVRWwcj takVl+9zJ+/4ad40vI0kho/ha/gZSQ1/I5kRYCQ3Ao0URkojlRFkpDbSGGmNdEZ6I4OR0chk fGFkNrIYWT+bbQd+Pt+aLlMz9b+UdeP+mHdNL9PbTPKH7LtD36nvohy897NZ+Djm4ZP6af2s fv59Pjb9zWSUk+/+aVZO+GNeNgPM5Gbgv5SdP8nNRsL/QnauwjhLikPZQJYZ/Fg1VgvS0z33 zKwJC4dsrA1rA7lYBIuA3Kw96wh5WGfWE/KxXmwslGIT2RRowlay/dCCR/Io6M2jeW/oy/vw fjCE9+eD4Vs+lA+HkXwEHwVj6e75BD6OI9vTGH+qMIQPTBN+wg/mCH+RFeaK7CIY1okQUQo2 UcY/Qhn/KI3ejikzlP1wS02iJmEB6jP1GUuuvlBfsED1lfqKpXAgXCylY6hjOEvlGOEYzdI5 xjrGsy8cEx1TWDbHNMcCFuyIc6xgBR2rHNtZKcdOxwFW23HMcYw1cZx0nGZNHWcd51kL1AYJ LNzxDrVBjAyTBdlqWVgWZRucWZxZ2WZndmcw2+oMcYawHc4wZxjb6czvzM92WffP2G5nMWcx tsdZwlmC7XWWcZZh+5zlneXZr85Kzkpsv7OWsxY74KzrrMsOOhs4G7BDzqbOluywM8IZwU64 cNjPTmottJbslBautWVntHZaFLugRWvR7Dbm2UnsDubZjewp5tkX7K3O9YZc6o31nry5Mc24 xPu4h7sn8q2Jz7fgaHQR3XFpzFrbW1Z9tIVBAXDY2iMTaprcuH82FqtehKpgNllrbb29th7X zmKxnrLJxrJh1ORk1q8g5mP58JxlWVlMLhVZRVDYeDaenrLZCc3VQDWFmlJNpQapqdU0alo1 nZpezaBmVDOpX6iZ1SxqVjWbml3NoeZUg1WPGqKGqrnYYXaEHWXH2HF2gp1kp9hpdoadZefY eXaBXWSX2GV2hV1l19h1doPdZLfYbXZHEYoinonn4oV4KV6J1+KNSBBvxbt/Z5uCriicZhoU +m+FJDT3E4BFQEosCiL3BXqaHazn0oKxOBHVAqgTC2HRoAgWHUpBaTCgIhYT6mLxgvrQAPVh Eyw+0AqLL7TF4gddIQqSQg/oCcmgD5bk2Ds5BDIv5g0psI8GQioWxIIgiJ6OSY39tRqkwf7a ANLSXd101FPTsw6sA2Sg52Uysm4sGjKx3qw39umhbChkYd+y7yArG8lGQnbswRMhB/bglZCT bWKbIZhtZzsghO1leyEXzTflpp4XRpq6As06NaFZp2Yf5sK22XNhORCpVDyEh6BiDLPeD8lL 8VKoGCvwCqgYa/AaqBjr8rqgou4JBwcqnvaoGIdow8CpfaeNBF2bo80Fb22+Fgc+2jHtOPhr J7UzEKCd1y6jlu6lfwNpMXsMgAxWZoAsmBmmQzaLxyEYefwYhCB7n4U8yODnIQw5/DLkRR6/ CvlwbHUd8iOX34QCyOe3oSBy+l3rv0Xx+gryRh982W37khN9CfrEl/w8Px5reSR4NRzLKOSR Sh45UN81AEl+OVG9fQku8ksjv9zklw/55act0pagR8u0VZCCfExDPqbTrms3IZN2W7uPflme 5iRPQ8jTMPI0H+a/2Tg+mIujjKLkdWnyuizmpWdQEbNSAo5MLI/K83b23ddK2D9bkUfBlo+s BvV7+LAFaC6Ts7as2IdtnNVi2XHN78Nx2AM+g0UhXgixsBBRqI1VwsVBuEjCxUm4uFD3NgaN 0NGp1Q3CyK3V1+qDiSPzb8ALR1+jsO3HaJMgJY7BVkEGbbW2EcJwJHYfimgPtRcQjhpiMHRE tTASeqI6iIMYzP0rYSzm+pMwhdp+NbX9GszgF2EtRcDPFAHrKALWUwRsoAjYSBGwCTP7fdiM 2f0hbMEMnwBbMZ874FfUOAFwDHVNWjiHWiYrXENVosM9VBdJ4CHm+EAcASAT4gjpSwBrBAkl rFkGqG49twU19a+N0vArfiYVm0BPOYrfWgTovyJxtGdFXbWPWsTzW4tALes/ke1tHIrR3XO/ D8dxENpkbRZ+8yZtJ0bbS92KX9xK4+zE60lLV+Kxv53jtwT+K8yKn0xKPATEQ4x4SBAPKcRD KvGQg3hIEg85iYdcxEMa8ZBOPGQQD5nEQ17EQ97EQz7EQ77EQ37EQ0mJh5IRD1lvzNiCHhi8 nFiLSPyj+zCcacwHrzIdy8pCWQFWglVgNfDqWrB2rAuLRu0Sw4aw79kY/NZYNofFsWVsNdvA trHd7ABicwZxuMHusSfsFZK/gxvchwfwIJ6BZ0V0w1hW9D4zYpGDbAPMfpZtzPKTbcIKkG3K CpJtxgqRbc4Kk23BipBtyYqSbYU9z7LhrDjZ1qwU2QhWhmwHzKiW7cyqkp2oJrOsskoNIBuv Jres+dqpW1b1dRqWdcxyusmud5pkNzi9yCY4vcm+dSYh+87pY1lUL75ki3ox+p52LAsygRfm eY5r2bFugNne0g7IB+glxiD6GIJ1MxaKdXOWC+sWDHUE+pYH61YsDOtwlhfr1qyE9ewHK4l1 e1Ya6w6oFzh6VQ7rLqw81l+yClhHskpYT2SVsZ7MqmA9SfUDjv4mxTpetWY+XjuxYdBTjGr0 U8F6vRP1BvrosJ5mckqs3zqdWL9zuoCjb6h+nEUhC/aqRphvO2Ce7QXW/9+PgckwC+JgBazD PLYXjsAZHPnfwb5t38/DSArAWM+AseRhYawQRlM5VgUZsgH63Rq9WIBoTUSEfiLbmMWRbcIW km3KFpFtxhaTbcGWkG3JlpJtzpaRbcWWkw1nK8i2dqayLPoYZFn0MjXZ9c40ZDc405JNcKYj +9aZnuw7ZwbLoscZyRZlU6n9plHLxVLLTaeWm0EtN5PabBa12WxqxTnUcnOp5eZRy8232sPp R4gnJcT9CfFkhHgAIZ6cEA8kxFMQ4ikJcQaKF9BT3YK4AqinMy/rXzSs93hXoWfqM0Mo5mJ7 Jor5U6wloxgJsL7bOgtL/mGprRVJFvcin4yjWKHaukPGvJGhgCVl1q/QW0zEiV+snBYAQ1lt VpfVZ/VYHdZWq4fZp0HivDDvxr/hQ/hYMVHMF8vMN2aC+dZ8h/w6RZuqTdNitenaDG2mNgu5 drO2RduqbdN+0bZrO7Sd5nOTm8JUTNV0mNJ0ai+1V9pr7Y2WoL3V3ulIe/oP+ih9tD5GH6uP 03/Ux+sT9FV6vL5aX6Ov1X/W1+nr9Q36Kf2Mfk6/oF/Sr+jX9Bv6Lf2Ofk9/oD8ypOE0XIZm 6IZhuA3T8DKyGdmNHEZOI9jwGCFGqJHLyG3kMcKMvEY+I79RwChoFDIKG0WMokYxo7hRwihp lDJKm4bpNk3Tx/Q1/cwX5kvzlZnCTGla9yAz0agPaKSnonKoiDmtHe+AWTsKR3QG740jOjc9 /WzS+M2LRmXeNPeaRCwVS8HHsdixBHwd8Y54SOp47niOug3HKpDMGqugvjmnXYUs1ogF1cwQ zN0FcMy+EkriaPskVMIR92moTLm7CuXuqpS7q1Hurk65uwbl7pqUu2tR7q5NubsO5e66lLvr 6W8xa9c3vDFTt6BM3ZsydV8zKWbq/ujnWmjwV1r0X2vB/0o7vW8hjdAEQtNFOPoQjikIxwzk eQ7yPIw8r06e1yKNUjdx5Kdqqpt6YQWw5nVLQNDH8f/7KP7zeEyMHTxDEooUoEgR1MIOak+T 2tOL2tOb2jMJtacPtacvtacftWdSak9/as9k1J4B1J7JqT0Dsd2SQQr76nXV/OjqTdSbdo+1 +jzFKVCcMopTTnEq7M8aqtdHnw1AVfKBBd73dGIO6gUUySpFsqRIdiaOYtlD9oy9ttVAEu7P U/D0PIsor7ZUw9U2aoTaVe2mdjfTmunNjOYXZhYzm5nDDDZDzNxmmJnPLGAWMouYxcwSZimz nNnEbGW2NtuaHc3O5pdmN7O72cPsY/YzB5pDzGHmcHOEOcocY44zx5sTzcnmVDPWnGHOMueY 88wFZpy5yFxqLjdXmvHmGvNnc4O52dxq/mLuMHeZe8x95n7zoHnYPGoeN0+ap83z5l3zgfnI fGI++/uZy7+fufwPPXPJwRs1f2vV13yNOb/oX3qmHHsia+c489ETwE7rWRn7qZr/8RmZD8/R 4Dl4Yd7kw5g9cUtFZKD3Y17Onli/FsHz8Hx4REncVpVX53V4fd6It0Ku6oKs19u6p/W5Yt3H +rjgWT4t+f5YrLteHxfrHtlnS8nflTLWHbRPStU/Futu2scFffmTgvngk4I+f1rqf65g/vik IEqfliZUfltv9bvSBku7PyldPlf0t58WzFqfluS/K+k+LbZ/iddLZ/h7buJP5iYYnMP8WQhz fTlU2bXoPSjv335ivQllGIyEcTj6mQHzYBGOf9bCJtiOI6BDcALx89C93n+2zvcv1VX/lfqz 8x+JsyMGmnHWuAeKW2MBzHX+NHqw7nEwlgXH0RyzvfV+wnHsR1wez6z3W07FkRdnK9l9XH7A HuJ45RGyCcNs+QyXn7OXlDNf4/Ib9haX33Hr94c4V6z3JXIHLkv6BR+d4/ibu7kX/SckjrG5 D7feDpeU++NyMm69cyyQp8DllDwtLqfjOHLjGfgXuJyZZ8HlrPRrQdl4NlzOzrPjcg6eA5dz cutdYZP4JFyezCfj8hQ+BZenirL0Lt/yIEQF1dd6Y6qK/qqB1u9nqWXUsiDUcmpzXG6hRuBy O+uX6DFXd8flr9QBuDxQHYjLg9RN1ruv1c24vMWJzOzkOIrkzkyu9sBcHVyo9Fwd3fOBuRe4 cdTr/sm9GZe3uH/B5e2oVJkZhDpDoJp8RyM8ZGUv7pUx8X+cqWU4tLD/M/c3DcJIgzDSIOyj /yBlpEEYaRBGGoSRBmGkQRhpEEYahJEGYaRBGGkQRhqEkQZJvEJOSoSREmGkRBgpEUZKhJES YaREGCkRRkqEkRJhpEQYKRFGSoSREmGkRBgpEUZKhJESYaREGCkRRkqEkRJhpEQYKRFGSoSR EmGkRBgpEUZKhJESYaREGCkRRkqEkRJhpEQYKRFGSoSREmGkRBgpEUZKhJESYaREGCkRRkqE kRJhpEQYKRFGSoSREmGkRBgpEUZKhJESYaREGCkRRkqEkRJhpEQYKRFGSoSREmGkRBgpEUZK hJESYaREGCkRRkqEkRJhpEQYKRFGSoSREmGkRBgpEUZKhJESef9+kA9vCwlsgtaPtkJgHU9M YA2HK+ugcoOeu5nksTGBJXFTUc5YiO5xOdRspuCBKniaO7RsDqawmLycKbE1PdU92T/aknJG UN+UdDunEFSFFtAVOiOJhkMU/lm3d4p40n50MsVv46ywl2Wa8dCpYw4+b/72jVpztO/B2Jik OTwxSqwnRgyJFZxxrjVPvnc0XXZrj/vDRTIVL6cHXZ2orTh8ee2aIb6eJNaK01er27xr24hO baI6dwrx9pjWRukra4S36ti5U6uQIE9Ka4vmm7RyRMvIzl07t45KU7JzZJfOkc2jIvAT6T1p rf3CN/Dj/a3C09SMaNMJz5qmWsninqBk7pCQEE+IJ9STKzQ0TwNczeUJ+bDq6df/v3Jtbo9u 7dd9lcpVq9V4f7j4k8M9MSzdx5gxFUQM0g1u13gMY3Cv4YbeSTJcHuS40PpduZXJ1vMrK4zQ B5FFeuccfLzK9KVzSwY/D58acjE0pPSi45szDEh7POfKAd+8ynO4Zsrjq6oHVf219Zrb8QZP yNJo4bzBz3anW3F0o7Pb02FdRrQ8fn9Y0M0RJTO0anB4cO+RHQvGRe+rG9b7xjrvOnHjHwxt nLPV9sWZXE2CWiZ9WHij/4gJQ/hWT/xmvVlqr8i9x+Ln5fEZNGm6rl0b3fD7V7Umb36cvGmJ 4T7TUhUdGf+Fb//koTGpHp8cfCTtskIzVsmqxzMsuDf86fKTr17mrzr35qPF9Ws8OVN8UnCS Li3P3jq34GHHtIp3zVw/L6v6y8Way4qHl+2U99m6m5P8i//QPmdDz1YusEPMjGGpEJHkHl/E MlVGxfBoDicGtapKITyprI0mim2/FDXMx0myxm8aujVJv8JHxtVbM7NmJ2rAVF5IzIqCWa2v J7W1nl4J8Pj39duT5MbuQyv867FdeXPm8vdfU2miltpTxzogtVLVU9lTMbZ8bNlBpdtGRXUp EBzcMrJDzo7vWzFny84dg7u0j7C2BneJ7NyqW8uorsHYyBiIGIYYgU09+XLkCskRiiGYEw/y NHh/zYwpVTyVPBXer3v4oCL2V3Tv3v1zXxEe+T+eO+p33U5YkTO7YViHhVUmRfhc7jyMT4ro vrVDq8jMQ04WLt0xe8DXRzIH+16q3y7FFj13/LCEW2vG3JEh19o96aYcnnuqSQHHVO+E+e71 k6uX7PyuzZjJF/f3epBhSZ69/RvfO7Wpc1j5TQ20us+6Xpz6+LKzUsEiwXsP7btXNV2X50pq PqfipNUjGg0xw8Z0yCVXz19YPfbAljPfp/NZv/V8zPE605+ffTA7TV1v7yn34gZFdfhy0uYH j7Z0aTL3dMfKeetNqNyj2IHcjRtkXNTmdooqZRxLvsuSeqb3iNm5pqU/+mJlmd4X7rUcP7Ji EXVe8JKA5fVnLS5e83un6p0j664Cjkopc84PqV6nVdzEvXE/js8y7MeRg29NWYUctRY5asZ7 jlJ9wxK59Pcc1f2/wgNpKdCw4wf8tr9WRMfwHDWjmnfs8htDefKG5gn15A4NyWsxVCjy0/tV T7/l/xsM9YUnY+JqUKeSEV3ahkemKVWzdJrSNasUCMmTv2SO4rnK5M0RmievJySjJ32iRyk/ 61HN8MjoiJbh/5DRJucen3yXK0vLCdy/27whdXtP/3l+cZ83rX6YfUz9amP3M3euLVpdrcqm y4Hr78YnvEgz7Mv8CyJHRU4b5rrqe/+H4nebZ2xffeG9eSVXNi+RfcqjVEsPvYl/+vXMrtG+ y7PNPD2med/a0706nj1xx//dwD7jpg7pAzm/75lhbdspI7bvfjKyR8+Lk+47Gn/zIufWdkkn F/ILvn50zM50KarvmV97UNr4Bo+L++Sf9qD2/CoLMmZr+fqHyEJevTaNizyzeeZm5+5zv+xa uUlrOnuyviBSa6wV651z/IGflg0ZMajvjd4HN9Ruf6Fe9p1hRV9eS7L1QUl14Fci2dXsc7P0 OnxpbDLocPrMwkLJC/ALvVsc+fVZqsLvGc2FiKgfkdez/t+mGZzkXv89p88NnHGo7aC8zaNG fkJW6XO/OFmjTBftbrHX0a+XZ1uyNc9yL0+tRLJCqvIgVcWWHlTynyKrxN1WK1IjYlQSVdX7 iKqQqDzlPqKqQn+Nqj575qjPMbjzc+zV4onqrno9RfuY6zWM8z2+m1e7X64fD8/avevt4nKn vz7VuWfmqjsOxA89cXDOhL0/1IGC+W7Ehwbfe7m//cnx547xpyXq1Wj//aliZ/xjlx/ZmCnp nnIl9h5OWPHqSqmhrb1KmE2eK9PSl2u4Ymjxbac6vAh7UnRLUNLz4yvBtmV3zjVlrOTk1SWO pds5euLUXbMD2rwpOyDoh8aTHkU/X/p9ZKq+0YXCkpTZ/U2Bco8XXy7/LFmu4T9Dy5jJdWfW mbu108iZRcbGv2l1sHHAFp1Vazn3zeODfacOuBya+2zdscVmdvzm1O2cDZwrvB1NQne5bobG fOk/99X2xa3HD315curKpt7pZ3bv+6jyscwQWW3guqueGHUdstes9+yVK1MgsVfI79mrKdGC 5hqVaejoR9lbseT+AtsiJLkn2ScbXR+aKiSHJ1tiP87wWz+u0bkzkgS2XUTriJbNo8LTFO8W 1bZzZERUD2IpjydfrpDQ0JD8uUKRpULt1VBr9f+mxPtHVLMssn6j5J5WG1NNbJYmTYkJ0TU7 FElxrPPePQ9vtX/7o7/3hfMFovoHxgfHht55d25LiSrpj0bC6Tx1taG7F6Up/+RB27jKFYfP Xt+j4peTyspTCRnPT+k2ZP+CrqX6HO93+vH6R2GzdjUqfWbxwsIXMrf9MXDu7MiudR4mG3Ml Ic+YyNhj0U2DupfuPzCf/4GuDdW1bWoMn70sIvhUcv3tqKgsl6KDa53189R/cWh4i4Q9u5qW Cam25gvfK8U8+yOzeGdOtyNvlcKxoYVH7puezzGwUZU6MZmzqqHxFY9XbXn9UI4WD0sXvh7n hGdlpk892PC7TDVv9FxQ4VGZ/XkL5Zu6onuj2cmmDt+TZESdQpvjXE3F4fdU0wQRaeDxsrqe ryWEVI9A8xH3fFYH6SScLNXEBnl8HC57FJGUKSqdGNPBh23cOkvCwZAqhzMNG3txfLOC80I6 zym07kQOT/IPB/lxxQjSoCZ0w5FHSSj+CbmZcTHNitX54serGX3fZL2o1Rxb/8osT7VEcivv KespHVsytvigon+d3D7sjsTQtliJiK3WR8RWzlPGU+ojYsv3zxCb1WFKJp71j+qLM6ifv0if TGUW3+5cbGnoyna3zeBO88o/v920291KBXMcL7lQf7vnZo6Qmen39qo2vm/axnGFgyutnTGv zuTLXX5eveJFj5XlI58XuVW8z+6LRrKIPbMnp8nxSq+2rc6+HJcrHFr3f6o7r6imtjyMJ6G3 GAgEBggQQClSTiiiV3JVVECEAAYBBQsgvSNiAhaINEOVXgRJkKJ0AxoHkIXIGDDSRESlXANI r9ICXJngXEd03Skvs1zzdv57r732Wvt857e//e2H4zdaLEThKLD+jUY6brOQanB7/tPszFCk rI4+zTprDqcQoXqXKJ3MTOFBLjCxq7Hk1jF4wS0sXaorISBV1d87W3JVeg7X48qQ37RHvqTE 1is9IDhZH6FYvmSN59ta92dDjh7RPLf4rrybqOWzcTcVPjzpPnqPovaEvhsGdY7PfL9EWRPZ xee8N2U+WNaktvOD9VgHPk3CvkUXca4/GXksXv1Jmc4R6RmYmCToTL+uHaot4znfTAQ01twb CsdirqgY3w7o/OTV2jjll2+TZHM1JS5Pypjj9Ep7vit/YMGeaXVNcfrHAD2RRd8qfVci68SD OG2EswyU1A8buLDo22bY/Up8nPCMs/rVutqgLCm3lH8drnSwbJj14d51w1qe80bO5w9iKw2m sNPUIEIvvw6ft3QoWpYJteofIa+PGMHKLmRsWiA0rjRwoYKZqYeU3JuSE1Jb4nqzUeVC9rfn KOWRbjcEPdRrgzxByLSyBUTIMuKG4uPodo9iI7RmVt+QP+YN6JqjUWdbdAtNYg0aENeYj6mA HPTYdM9OY8KKYdV6Frw9TRiAyM3D5vfsV34j3HS+8Fv6Z/Ab0AN0ADaxdbWBfVv8Rn8ptYGt 8ufZ3/9E7ztkr6rB98ZJqlc8Nf7yoZ451JxpqWBR1tYvgVXcMdNZ1GlaFgjICU/yvLZKFTuW ImWQVJ5hD+x6B/IcC6mfusmzYwXKyT7KMmRfaCtG5SwsukqrbYSMRiMnRrH55EYFXGvc2tF2 vo6zFR2VBpwUVqFXsusb5T5DXGVkx4iyoYZSaaT5yROCwxxq6x6JiYBP1KdTQM7atZ506hgq /dpqF/wT7yOc94nqo4l3jEEmRi7CSiouxenDr7jDTCis8CJhI1E+4p3w6ZP4z+AspAVvBAgG GE4/GlAwrH2mbnWnQgZ/CH2ZkT24/0Yy2QFSgxSq2ljJfgBukz9utcnianoqJ/CV3iXsFSn6 d/T+U2P4Hb1h2+m99Rd6ICzjH/ANSwTC4v4cv2Snuw7/c3kSYYQyBNkkr6DM9KLtIg9cw/n/ hvr/lZVlrzUsndRkz3FkT/94ddnl920ESzNwlUagv523ILyk7UlIAk2jW4QS6+1Is4G8wMrB LTL7gw8ybWorbLOkPyDBkaW1+IWYjqn94BnmkwR+LnqcMXMOJ9ZvXpI0PBrn8Tq08WPKArdm BMf4LVVFeb/15Y1hfKaG0AoP069OApsT78kfkEoj77vtqt5sCZ1wtD+AyIiRO8DkkdRiMdAm QWjM7gAB+oQfZjOCHz74lN8hfu4NTXwSG3O9WXf32fyGybqrAgYh3bgA1AzQWot3trcDi/OL QrveiWYs6T92saWqa46yIiIZltZjOX4pXqX7TLuXCQ33JYIdVWYp2So63JclHVswMt6yxDmB 52q17YepI6ypqzVDd4sDdWnYZn8FkV1BAvonYv1PGx4WraNSK81c6XcMNkMJqNBcMcBlzEDk rCQ9Vx7VcXh893jtojFDrbtXK9R0l6qx4rnTE9azhQOZOa2/+NaHKQVyC88EoRqyiY1KVg+r PDA3yUEO1T5keGHDfaM5Ed/fSVpeDz4PWtJjFVpc6nOQUSIXIBj1ilMJtGHUSE1lq1M13oqr +5CGRWlKZQG+hJqXdknybVIU/JK8plYxr0+eXezOhrzZ8FZUz6SMeUvWzLHfVsDOvjcFrtLd 6R99JorS29Aqm9BmO/teMyly75pm7gGNkwjPFnj+72giZzpA5EyGgMFAWNRP9MvfBbXfYt68 sGdbLu0P2fJxoAW3Z8jseb9VAmgosL1XbMsDfh3IiWaz6L7xzgUu6s3PaXyY6GJgLGAVNDoK XNg2RBBtDVjlqYYqg8xA7iAnUADI90sM7QIKBMmBrEAEkB+7cmW3O7Cf3EAE8q5QxX/5jQYS /HxdAxz83AhyP+wlnEQwKIRZIl+5ZAX4t+/vo9MmH9UMXpxwOG9M652q4SqJjjyTLe5eqj7Y oXHtVrDw7Epig+pgR9GT6D2Uz3aC8PmCqGTTefgFhFjXakIhGfdReb+FEb8JYzrEI6PnIkCi dagYumZQRxJjhix59RWm8w4sRcHPijs+SGdw6SGeZzxMF4atDDQKRWeLVZJf1L1MMHfhRamI rNEwTb97ptkGdTyVkdtb/jDJaV40I+KwdDotV/uZuW7MvNjddrcYb9xy3377uiZtHVz3Sldi xfJeCNV3j/nflJ+bodzf5pDW0o8d0zEWIL2t0Kr3szdLHsufv1nfWdDzesANti5/SspiwrdP HblEJkKQABGy7eVyo4kQfnYT9xcxRvy0zf+7PI7nDynmnQEktutQ4NuFB5g94z97uNA7tqIy QBetxz6T7tFmm5gfZWiwU7Y/13M0tPfoAukG62lh2+wluR/YvCWQ04qSQDnrYrhZYFBd2TWJ rI0WrqnCcbtfpo9feeww5DM7cLU1h5wn+RIl/ijsuvQbHNoJ+2vVuujy3jBSdUfipxblyihe rs/h+qsbgyoeLeeD31asCV2O7FVl5G90fazR0u7uUZSc9YG8MHThbcKTwvcZe8xOt+/QhqQ1 Dlb4vTuuh0Hw4n6l2YST7g8BwQYmUga9+Cb99dzMk0mU0nvWyZlqg1aGPTlJ9pB7QHG103KY xwtyvP7BQPEZJmOss+hG9bzmw30pf7Vti2fcSuFs9l+694qUeDYL7dYHd6cqxsh4nzG96GwS IoEv39ls3Uw1Opz8akoj0ueSmWClZGYFXtkLBPo7cDtc4A0KZW5kc3RyZWFtDQplbmRvYmoN CjgwMyAwIG9iag0KPDwvVHlwZS9YUmVmL1NpemUgODAzL1dbIDEgNCAyXSAvUm9vdCAxIDAg Ui9JbmZvIDUzIDAgUi9JRFs8OENFMTUyRDhBRDQ0MDM0QTlDMUI2QTQyQTg2QTc5Qzk+PDhD RTE1MkQ4QUQ0NDAzNEE5QzFCNkE0MkE4NkE3OUM5Pl0gL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMTYwNT4+DQpzdHJlYW0NCnicNdgJvJVjAsfx+29DRUJFlkplyVJJQmQvRArZClmy U9mXIlKEVCipyJJshexUQrJnKURpjMnMGMsshtnMTHN7vu/cz/3c7+c55577nnOe9z6/9zk1 NbVfa9ak9mfTmpq1jCikfaFO20Ldnwv1OmBZof6iQoPlhUaDMa3QuAW6YklhfTdu0BDjMafQ pA+mFDYcW2g6o9B8YaHFu4WWnxQ2/6rQan6h9ReFdoMK7UcWOjbD4kKneYXOKwvdJxT2mlXo 2abQq1uhr/v6zS0M8MwGDikMXlU446fC0HGFYTMLV40qDJ9aGP1NYcyawgRHn7i0MGl67Vtb +92jZiW+qKWme00DVPetqv3NybPLqPbGOgjqoj7qoQXW8fBfGa2HddEMm6ARGmJ9NEYTbICm 2BAbYyM0xy7Y1NG/NGqJzdARO2MLbI6tsCW2R2u0wtZog3Zoi23QHtthW+yADtgJO6IzOmFf dPEafm3UFbtib+yFbtgNe2B3dMee2Ac9cCT2c6CvjA7A/jgCfXAQDkQv9MQhOBi9cSgOx2Ho h74YhKM8id8Y9cfROBEDcSyOwfE4DgNwAk7GSbgXpzjQaqPTcCrOwhkYjNNxJs7B2ZiBc3E+ zsMQXIBhGIqLcCEuwcW4DJfiClyOq3AlRmA4rsHVuBYjMQrXYTSuxw0Yg7G4ETfjJozDLRiP WzERE3A7bsMdmITJmII7cRemYSqm4x7cjeoMuc80fm30AO7Hw5iFBzETD+FRPILq1H8MczAb T+BxzMWTeBpP4Vk8g+fxHF7EC5iHl7AA87EQL+NVvIJFeA2L8TrexBt4G2/hXbyDJXgPH+B9 fIQPsQxL8Qk+xqdYjs+wAp9jJVahyktVhGpZs0KnWqFXm9TfGlVUU/wtvsHv8Tv8wV+p0vMd fsD3+BP+iL/gz/grfsTP+Al/x9/wT/wDv+Bf+A/+jTX4r2cmmFHR6GbENPIZ+cw6EOHoZnQz ShmljERGMCOR0cboZgQzShmljOxGMKPF0cZsCutuNjcd3uSIYgQzMhhtjDZGPqONsc5HGyOK EcyIYgQzQhvBjFJGKaOUUcqId8Q7uhndTBe4BIhgRjAjkZHISGQkMhIZiYy0RlojmBHM7AeB jlJGKaON0caIYiQyohg1jFJGIqON0cYIbbQx6pujINex0qa/yfGPEFGMKEYpI4ORyEhkJDJW 70hrlDJKmVOgzJHISGREMaIYUYxgRhSjohHFCGa0MdoYbYw2RhujjdHGaGO0MdoYbYw2Rhuj jdHGaGO0MdoYbYw2RhujjdHGaGNEMRIZUYwaRikjkdHGaGNEMWoYpYwaxrqb28yYFSyiGKWM /kUNI5ERzChlrOXRxmhjBDMSGYmMK524OIko5j7IYAQzEhmJjG5GIiORkcioYSQyahiljBpG KaOGUcqoYZQyahiljBpGKaOGUcqoYZQyEhlRjERGG6ONEcWoYZQyEhltjDbmbfNQLZXvGlUJ 0cZoY4QvahiljFLmI4+rll+ljERGIqONUcqIYpQy2hjBjERGIlNFUSnj4iSCGdetcRUUiYxE ploLqvW6ekXV6SaKUdFoY7Qx2hhtjDZGG6ON+dGrDdZuH2ev+P8WsQ7qoh4aoD6q3eB6WBcN 0RiN0AQb4Eg0xbfYGBuh2uo1RzNsghY4ApuhqlpLbIkt0ApboQ1aoy22Rnu0w7bYBttjO+yA DtgJO6IjdkZndEK1/9sFXbErumE37IHd0R17Ym/shX3QA9XGb18cgP1xIA5CTxyMXjgEvXEo DkMfHI5+6IubUO34vkOVs6NxAo7DsTgGx+MGDMCJGIiTcRKqHd8gnIZTMRin40ycgbNxFs7F OTgf52EILsAwDMVFuBCX4GJchktxBS7HVbgSwzECV2MkrsG1GIXrcD3GYDTG4ka8g5vxPcbh FlTlmoDxuBUT8SZuxyTcgTsxGXdhCqZhKu7GdMzAPah2fPfiAdyPBzETD2EWHsHDeAyPYg5m 4wk8jrl4Ek/jKTyLZ/A8nsOLeAHz8BLmYwFexitYiFexCK/hdbyBxag69hZWoMrZD1iC97Ac n+IDvI8qZx9iGZbiE3yMz/FZbQPmfV1SsODLtdTp2L/QuXwkW6dL+eCzzq69C0uX4JfCstU1 Nf8DgydOtw0KZW5kc3RyZWFtDQplbmRvYmoNCnhyZWYNCjAgODA0DQowMDAwMDAwMDU0IDY1 NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAw MjkzIDAwMDAwIG4NCjAwMDAwMDA1NDcgMDAwMDAgbg0KMDAwMDAwMTAxMyAwMDAwMCBuDQow MDAwMDAxMDY2IDAwMDAwIG4NCjAwMDAwMDEyMzUgMDAwMDAgbg0KMDAwMDAwMTQ3NSAwMDAw MCBuDQowMDAwMDAxNzUxIDAwMDAwIG4NCjAwMDAwMDI5MTcgMDAwMDAgbg0KMDAwMDAwMjk3 MSAwMDAwMCBuDQowMDAwMDAzMDk1IDAwMDAwIG4NCjAwMDAwMDMxMjUgMDAwMDAgbg0KMDAw MDAwMzI3NyAwMDAwMCBuDQowMDAwMDAzMzUxIDAwMDAwIG4NCjAwMDAwMDM1OTQgMDAwMDAg bg0KMDAwMDAwMzcyNyAwMDAwMCBuDQowMDAwMDAzNzU3IDAwMDAwIG4NCjAwMDAwMDM5MTgg MDAwMDAgbg0KMDAwMDAwMzk5MiAwMDAwMCBuDQowMDAwMDA0MjMzIDAwMDAwIG4NCjAwMDAw MDQ1MTEgMDAwMDAgbg0KMDAwMDAwNTgyMyAwMDAwMCBuDQowMDAwMDA2MDkxIDAwMDAwIG4N CjAwMDAwMDY4NjkgMDAwMDAgbg0KMDAwMDAwNzEzNyAwMDAwMCBuDQowMDAwMDA4MTI0IDAw MDAwIG4NCjAwMDAwMDg0MTIgMDAwMDAgbg0KMDAwMDAwOTMxMiAwMDAwMCBuDQowMDAwMDA5 NjAwIDAwMDAwIG4NCjAwMDAwMTIwNTMgMDAwMDAgbg0KMDAwMDAxMjIyOSAwMDAwMCBuDQow MDAwMDEyNDc1IDAwMDAwIG4NCjAwMDAwMTI3NjMgMDAwMDAgbg0KMDAwMDAxNTI0OCAwMDAw MCBuDQowMDAwMDE1NTI2IDAwMDAwIG4NCjAwMDAwMTc5NTMgMDAwMDAgbg0KMDAwMDAxODIz MSAwMDAwMCBuDQowMDAwMDIwNjI0IDAwMDAwIG4NCjAwMDAwMjA5MTMgMDAwMDAgbg0KMDAw MDAyMzM3NCAwMDAwMCBuDQowMDAwMDIzNjYzIDAwMDAwIG4NCjAwMDAwMjYwNzcgMDAwMDAg bg0KMDAwMDAyNjM1NiAwMDAwMCBuDQowMDAwMDI4ODEzIDAwMDAwIG4NCjAwMDAwMjkwOTIg MDAwMDAgbg0KMDAwMDAzMTYxOSAwMDAwMCBuDQowMDAwMDMxODk4IDAwMDAwIG4NCjAwMDAw MzQyODAgMDAwMDAgbg0KMDAwMDAzNDU1OSAwMDAwMCBuDQowMDAwMDM3MDUxIDAwMDAwIG4N CjAwMDAwMzczMzAgMDAwMDAgbg0KMDAwMDAzODMwMCAwMDAwMCBuDQowMDAwMDAwMDU1IDY1 NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUgZg0KMDAwMDAwMDA1NyA2NTUzNSBmDQowMDAwMDAw MDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1MzUgZg0KMDAwMDAwMDA2MCA2NTUzNSBmDQow MDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIgNjU1MzUgZg0KMDAwMDAwMDA2MyA2NTUz NSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUgNjU1MzUgZg0KMDAwMDAwMDA2 NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAwNjggNjU1MzUgZg0KMDAw MDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAwMDAwNzEgNjU1MzUg Zg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAwMDAwMDAwNzQg NjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYNCjAwMDAw MDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1IGYN CjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1 NTM1IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAw MDg1IDY1NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQow MDAwMDAwMDg4IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUz NSBmDQowMDAwMDAwMDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5 MyA2NTUzNSBmDQowMDAwMDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAw MDAwMDA5NiA2NTUzNSBmDQowMDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUg Zg0KMDAwMDAwMDA5OSA2NTUzNSBmDQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEg NjU1MzUgZg0KMDAwMDAwMDEwMiA2NTUzNSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAw MDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEwNSA2NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYN CjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAwMDEwOCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1 NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAwMDAwMDExMSA2NTUzNSBmDQowMDAwMDAw MTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0KMDAwMDAwMDExNCA2NTUzNSBmDQow MDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUgZg0KMDAwMDAwMDExNyA2NTUz NSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1MzUgZg0KMDAwMDAwMDEy MCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIgNjU1MzUgZg0KMDAw MDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAxMjUgNjU1MzUg Zg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAwMDAwMDAxMjgg NjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYNCjAwMDAw MDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMzIDY1NTM1IGYN CjAwMDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAwMTM2IDY1 NTM1IGYNCjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAwMDAw MTM5IDY1NTM1IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQow MDAwMDAwMTQyIDY1NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUz NSBmDQowMDAwMDAwMTQ1IDY1NTM1IGYNCjAwMDAwMDAxNDYgNjU1MzUgZg0KMDAwMDAwMDE0 NyA2NTUzNSBmDQowMDAwMDAwMTQ4IDY1NTM1IGYNCjAwMDAwMDAxNDkgNjU1MzUgZg0KMDAw MDAwMDE1MCA2NTUzNSBmDQowMDAwMDAwMTUxIDY1NTM1IGYNCjAwMDAwMDAxNTIgNjU1MzUg Zg0KMDAwMDAwMDE1MyA2NTUzNSBmDQowMDAwMDAwMTU0IDY1NTM1IGYNCjAwMDAwMDAxNTUg NjU1MzUgZg0KMDAwMDAwMDE1NiA2NTUzNSBmDQowMDAwMDAwMTU3IDY1NTM1IGYNCjAwMDAw MDAxNTggNjU1MzUgZg0KMDAwMDAwMDE1OSA2NTUzNSBmDQowMDAwMDAwMTYwIDY1NTM1IGYN CjAwMDAwMDAxNjEgNjU1MzUgZg0KMDAwMDAwMDE2MiA2NTUzNSBmDQowMDAwMDAwMTYzIDY1 NTM1IGYNCjAwMDAwMDAxNjQgNjU1MzUgZg0KMDAwMDAwMDE2NSA2NTUzNSBmDQowMDAwMDAw MTY2IDY1NTM1IGYNCjAwMDAwMDAxNjcgNjU1MzUgZg0KMDAwMDAwMDE2OCA2NTUzNSBmDQow MDAwMDAwMTY5IDY1NTM1IGYNCjAwMDAwMDAxNzAgNjU1MzUgZg0KMDAwMDAwMDE3MSA2NTUz NSBmDQowMDAwMDAwMTcyIDY1NTM1IGYNCjAwMDAwMDAxNzMgNjU1MzUgZg0KMDAwMDAwMDE3 NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1NTM1IGYNCjAwMDAwMDAxNzYgNjU1MzUgZg0KMDAw MDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4IDY1NTM1IGYNCjAwMDAwMDAxNzkgNjU1MzUg Zg0KMDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAwMTgxIDY1NTM1IGYNCjAwMDAwMDAxODIg NjU1MzUgZg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAwMDAwMTg0IDY1NTM1IGYNCjAwMDAw MDAxODUgNjU1MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQowMDAwMDAwMTg3IDY1NTM1IGYN CjAwMDAwMDAxODggNjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBmDQowMDAwMDAwMTkwIDY1 NTM1IGYNCjAwMDAwMDAxOTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUzNSBmDQowMDAwMDAw MTkzIDY1NTM1IGYNCjAwMDAwMDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2NTUzNSBmDQow MDAwMDAwMTk2IDY1NTM1IGYNCjAwMDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5OCA2NTUz NSBmDQowMDAwMDAwMTk5IDY1NTM1IGYNCjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAwMDIw MSA2NTUzNSBmDQowMDAwMDAwMjAyIDY1NTM1IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAw MDAwMDIwNCA2NTUzNSBmDQowMDAwMDAwMjA1IDY1NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUg Zg0KMDAwMDAwMDIwNyA2NTUzNSBmDQowMDAwMDAwMjA4IDY1NTM1IGYNCjAwMDAwMDAyMDkg NjU1MzUgZg0KMDAwMDAwMDIxMCA2NTUzNSBmDQowMDAwMDAwMjExIDY1NTM1IGYNCjAwMDAw MDAyMTIgNjU1MzUgZg0KMDAwMDAwMDIxMyA2NTUzNSBmDQowMDAwMDAwMjE0IDY1NTM1IGYN CjAwMDAwMDAyMTUgNjU1MzUgZg0KMDAwMDAwMDIxNiA2NTUzNSBmDQowMDAwMDAwMjE3IDY1 NTM1IGYNCjAwMDAwMDAyMTggNjU1MzUgZg0KMDAwMDAwMDIxOSA2NTUzNSBmDQowMDAwMDAw MjIwIDY1NTM1IGYNCjAwMDAwMDAyMjEgNjU1MzUgZg0KMDAwMDAwMDIyMiA2NTUzNSBmDQow MDAwMDAwMjIzIDY1NTM1IGYNCjAwMDAwMDAyMjQgNjU1MzUgZg0KMDAwMDAwMDIyNSA2NTUz NSBmDQowMDAwMDAwMjI2IDY1NTM1IGYNCjAwMDAwMDAyMjcgNjU1MzUgZg0KMDAwMDAwMDIy OCA2NTUzNSBmDQowMDAwMDAwMjI5IDY1NTM1IGYNCjAwMDAwMDAyMzAgNjU1MzUgZg0KMDAw MDAwMDIzMSA2NTUzNSBmDQowMDAwMDAwMjMyIDY1NTM1IGYNCjAwMDAwMDAyMzMgNjU1MzUg Zg0KMDAwMDAwMDIzNCA2NTUzNSBmDQowMDAwMDAwMjM1IDY1NTM1IGYNCjAwMDAwMDAyMzYg NjU1MzUgZg0KMDAwMDAwMDIzNyA2NTUzNSBmDQowMDAwMDAwMjM4IDY1NTM1IGYNCjAwMDAw MDAyMzkgNjU1MzUgZg0KMDAwMDAwMDI0MCA2NTUzNSBmDQowMDAwMDAwMjQxIDY1NTM1IGYN CjAwMDAwMDAyNDIgNjU1MzUgZg0KMDAwMDAwMDI0MyA2NTUzNSBmDQowMDAwMDAwMjQ0IDY1 NTM1IGYNCjAwMDAwMDAyNDUgNjU1MzUgZg0KMDAwMDAwMDI0NiA2NTUzNSBmDQowMDAwMDAw MjQ3IDY1NTM1IGYNCjAwMDAwMDAyNDggNjU1MzUgZg0KMDAwMDAwMDI0OSA2NTUzNSBmDQow MDAwMDAwMjUwIDY1NTM1IGYNCjAwMDAwMDAyNTEgNjU1MzUgZg0KMDAwMDAwMDI1MiA2NTUz NSBmDQowMDAwMDAwMjUzIDY1NTM1IGYNCjAwMDAwMDAyNTQgNjU1MzUgZg0KMDAwMDAwMDI1 NSA2NTUzNSBmDQowMDAwMDAwMjU2IDY1NTM1IGYNCjAwMDAwMDAyNTcgNjU1MzUgZg0KMDAw MDAwMDI1OCA2NTUzNSBmDQowMDAwMDAwMjU5IDY1NTM1IGYNCjAwMDAwMDAyNjAgNjU1MzUg Zg0KMDAwMDAwMDI2MSA2NTUzNSBmDQowMDAwMDAwMjYyIDY1NTM1IGYNCjAwMDAwMDAyNjMg NjU1MzUgZg0KMDAwMDAwMDI2NCA2NTUzNSBmDQowMDAwMDAwMjY1IDY1NTM1IGYNCjAwMDAw MDAyNjYgNjU1MzUgZg0KMDAwMDAwMDI2NyA2NTUzNSBmDQowMDAwMDAwMjY4IDY1NTM1IGYN CjAwMDAwMDAyNjkgNjU1MzUgZg0KMDAwMDAwMDI3MCA2NTUzNSBmDQowMDAwMDAwMjcxIDY1 NTM1IGYNCjAwMDAwMDAyNzIgNjU1MzUgZg0KMDAwMDAwMDI3MyA2NTUzNSBmDQowMDAwMDAw Mjc0IDY1NTM1IGYNCjAwMDAwMDAyNzUgNjU1MzUgZg0KMDAwMDAwMDI3NiA2NTUzNSBmDQow MDAwMDAwMjc3IDY1NTM1IGYNCjAwMDAwMDAyNzggNjU1MzUgZg0KMDAwMDAwMDI3OSA2NTUz NSBmDQowMDAwMDAwMjgwIDY1NTM1IGYNCjAwMDAwMDAyODEgNjU1MzUgZg0KMDAwMDAwMDI4 MiA2NTUzNSBmDQowMDAwMDAwMjgzIDY1NTM1IGYNCjAwMDAwMDAyODQgNjU1MzUgZg0KMDAw MDAwMDI4NSA2NTUzNSBmDQowMDAwMDAwMjg2IDY1NTM1IGYNCjAwMDAwMDAyODcgNjU1MzUg Zg0KMDAwMDAwMDI4OCA2NTUzNSBmDQowMDAwMDAwMjg5IDY1NTM1IGYNCjAwMDAwMDAyOTAg NjU1MzUgZg0KMDAwMDAwMDI5MSA2NTUzNSBmDQowMDAwMDAwMjkyIDY1NTM1IGYNCjAwMDAw MDAyOTMgNjU1MzUgZg0KMDAwMDAwMDI5NCA2NTUzNSBmDQowMDAwMDAwMjk1IDY1NTM1IGYN CjAwMDAwMDAyOTYgNjU1MzUgZg0KMDAwMDAwMDI5NyA2NTUzNSBmDQowMDAwMDAwMjk4IDY1 NTM1IGYNCjAwMDAwMDAyOTkgNjU1MzUgZg0KMDAwMDAwMDMwMCA2NTUzNSBmDQowMDAwMDAw MzAxIDY1NTM1IGYNCjAwMDAwMDAzMDIgNjU1MzUgZg0KMDAwMDAwMDMwMyA2NTUzNSBmDQow MDAwMDAwMzA0IDY1NTM1IGYNCjAwMDAwMDAzMDUgNjU1MzUgZg0KMDAwMDAwMDMwNiA2NTUz NSBmDQowMDAwMDAwMzA3IDY1NTM1IGYNCjAwMDAwMDAzMDggNjU1MzUgZg0KMDAwMDAwMDMw OSA2NTUzNSBmDQowMDAwMDAwMzEwIDY1NTM1IGYNCjAwMDAwMDAzMTEgNjU1MzUgZg0KMDAw MDAwMDMxMiA2NTUzNSBmDQowMDAwMDAwMzEzIDY1NTM1IGYNCjAwMDAwMDAzMTQgNjU1MzUg Zg0KMDAwMDAwMDMxNSA2NTUzNSBmDQowMDAwMDAwMzE2IDY1NTM1IGYNCjAwMDAwMDAzMTcg NjU1MzUgZg0KMDAwMDAwMDMxOCA2NTUzNSBmDQowMDAwMDAwMzE5IDY1NTM1IGYNCjAwMDAw MDAzMjAgNjU1MzUgZg0KMDAwMDAwMDMyMSA2NTUzNSBmDQowMDAwMDAwMzIyIDY1NTM1IGYN CjAwMDAwMDAzMjMgNjU1MzUgZg0KMDAwMDAwMDMyNCA2NTUzNSBmDQowMDAwMDAwMzI1IDY1 NTM1IGYNCjAwMDAwMDAzMjYgNjU1MzUgZg0KMDAwMDAwMDMyNyA2NTUzNSBmDQowMDAwMDAw MzI4IDY1NTM1IGYNCjAwMDAwMDAzMjkgNjU1MzUgZg0KMDAwMDAwMDMzMCA2NTUzNSBmDQow MDAwMDAwMzMxIDY1NTM1IGYNCjAwMDAwMDAzMzIgNjU1MzUgZg0KMDAwMDAwMDMzMyA2NTUz NSBmDQowMDAwMDAwMzM0IDY1NTM1IGYNCjAwMDAwMDAzMzUgNjU1MzUgZg0KMDAwMDAwMDMz NiA2NTUzNSBmDQowMDAwMDAwMzM3IDY1NTM1IGYNCjAwMDAwMDAzMzggNjU1MzUgZg0KMDAw MDAwMDMzOSA2NTUzNSBmDQowMDAwMDAwMzQwIDY1NTM1IGYNCjAwMDAwMDAzNDEgNjU1MzUg Zg0KMDAwMDAwMDM0MiA2NTUzNSBmDQowMDAwMDAwMzQzIDY1NTM1IGYNCjAwMDAwMDAzNDQg NjU1MzUgZg0KMDAwMDAwMDM0NSA2NTUzNSBmDQowMDAwMDAwMzQ2IDY1NTM1IGYNCjAwMDAw MDAzNDcgNjU1MzUgZg0KMDAwMDAwMDM0OCA2NTUzNSBmDQowMDAwMDAwMzQ5IDY1NTM1IGYN CjAwMDAwMDAzNTAgNjU1MzUgZg0KMDAwMDAwMDM1MSA2NTUzNSBmDQowMDAwMDAwMzUyIDY1 NTM1IGYNCjAwMDAwMDAzNTMgNjU1MzUgZg0KMDAwMDAwMDM1NCA2NTUzNSBmDQowMDAwMDAw MzU1IDY1NTM1IGYNCjAwMDAwMDAzNTYgNjU1MzUgZg0KMDAwMDAwMDM1NyA2NTUzNSBmDQow MDAwMDAwMzU4IDY1NTM1IGYNCjAwMDAwMDAzNTkgNjU1MzUgZg0KMDAwMDAwMDM2MCA2NTUz NSBmDQowMDAwMDAwMzYxIDY1NTM1IGYNCjAwMDAwMDAzNjIgNjU1MzUgZg0KMDAwMDAwMDM2 MyA2NTUzNSBmDQowMDAwMDAwMzY0IDY1NTM1IGYNCjAwMDAwMDAzNjUgNjU1MzUgZg0KMDAw MDAwMDM2NiA2NTUzNSBmDQowMDAwMDAwMzY3IDY1NTM1IGYNCjAwMDAwMDAzNjggNjU1MzUg Zg0KMDAwMDAwMDM2OSA2NTUzNSBmDQowMDAwMDAwMzcwIDY1NTM1IGYNCjAwMDAwMDAzNzEg NjU1MzUgZg0KMDAwMDAwMDM3MiA2NTUzNSBmDQowMDAwMDAwMzczIDY1NTM1IGYNCjAwMDAw MDAzNzQgNjU1MzUgZg0KMDAwMDAwMDM3NSA2NTUzNSBmDQowMDAwMDAwMzc2IDY1NTM1IGYN CjAwMDAwMDAzNzcgNjU1MzUgZg0KMDAwMDAwMDM3OCA2NTUzNSBmDQowMDAwMDAwMzc5IDY1 NTM1IGYNCjAwMDAwMDAzODAgNjU1MzUgZg0KMDAwMDAwMDM4MSA2NTUzNSBmDQowMDAwMDAw MzgyIDY1NTM1IGYNCjAwMDAwMDAzODMgNjU1MzUgZg0KMDAwMDAwMDM4NCA2NTUzNSBmDQow MDAwMDAwMzg1IDY1NTM1IGYNCjAwMDAwMDAzODYgNjU1MzUgZg0KMDAwMDAwMDM4NyA2NTUz NSBmDQowMDAwMDAwMzg4IDY1NTM1IGYNCjAwMDAwMDAzODkgNjU1MzUgZg0KMDAwMDAwMDM5 MCA2NTUzNSBmDQowMDAwMDAwMzkxIDY1NTM1IGYNCjAwMDAwMDAzOTIgNjU1MzUgZg0KMDAw MDAwMDM5MyA2NTUzNSBmDQowMDAwMDAwMzk0IDY1NTM1IGYNCjAwMDAwMDAzOTUgNjU1MzUg Zg0KMDAwMDAwMDM5NiA2NTUzNSBmDQowMDAwMDAwMzk3IDY1NTM1IGYNCjAwMDAwMDAzOTgg NjU1MzUgZg0KMDAwMDAwMDM5OSA2NTUzNSBmDQowMDAwMDAwNDAwIDY1NTM1IGYNCjAwMDAw MDA0MDEgNjU1MzUgZg0KMDAwMDAwMDQwMiA2NTUzNSBmDQowMDAwMDAwNDAzIDY1NTM1IGYN CjAwMDAwMDA0MDQgNjU1MzUgZg0KMDAwMDAwMDQwNSA2NTUzNSBmDQowMDAwMDAwNDA2IDY1 NTM1IGYNCjAwMDAwMDA0MDcgNjU1MzUgZg0KMDAwMDAwMDQwOCA2NTUzNSBmDQowMDAwMDAw NDA5IDY1NTM1IGYNCjAwMDAwMDA0MTAgNjU1MzUgZg0KMDAwMDAwMDQxMSA2NTUzNSBmDQow MDAwMDAwNDEyIDY1NTM1IGYNCjAwMDAwMDA0MTMgNjU1MzUgZg0KMDAwMDAwMDQxNCA2NTUz NSBmDQowMDAwMDAwNDE1IDY1NTM1IGYNCjAwMDAwMDA0MTYgNjU1MzUgZg0KMDAwMDAwMDQx NyA2NTUzNSBmDQowMDAwMDAwNDE4IDY1NTM1IGYNCjAwMDAwMDA0MTkgNjU1MzUgZg0KMDAw MDAwMDQyMCA2NTUzNSBmDQowMDAwMDAwNDIxIDY1NTM1IGYNCjAwMDAwMDA0MjIgNjU1MzUg Zg0KMDAwMDAwMDQyMyA2NTUzNSBmDQowMDAwMDAwNDI0IDY1NTM1IGYNCjAwMDAwMDA0MjUg NjU1MzUgZg0KMDAwMDAwMDQyNiA2NTUzNSBmDQowMDAwMDAwNDI3IDY1NTM1IGYNCjAwMDAw MDA0MjggNjU1MzUgZg0KMDAwMDAwMDQyOSA2NTUzNSBmDQowMDAwMDAwNDMwIDY1NTM1IGYN CjAwMDAwMDA0MzEgNjU1MzUgZg0KMDAwMDAwMDQzMiA2NTUzNSBmDQowMDAwMDAwNDMzIDY1 NTM1IGYNCjAwMDAwMDA0MzQgNjU1MzUgZg0KMDAwMDAwMDQzNSA2NTUzNSBmDQowMDAwMDAw NDM2IDY1NTM1IGYNCjAwMDAwMDA0MzcgNjU1MzUgZg0KMDAwMDAwMDQzOCA2NTUzNSBmDQow MDAwMDAwNDM5IDY1NTM1IGYNCjAwMDAwMDA0NDAgNjU1MzUgZg0KMDAwMDAwMDQ0MSA2NTUz NSBmDQowMDAwMDAwNDQyIDY1NTM1IGYNCjAwMDAwMDA0NDMgNjU1MzUgZg0KMDAwMDAwMDQ0 NCA2NTUzNSBmDQowMDAwMDAwNDQ1IDY1NTM1IGYNCjAwMDAwMDA0NDYgNjU1MzUgZg0KMDAw MDAwMDQ0NyA2NTUzNSBmDQowMDAwMDAwNDQ4IDY1NTM1IGYNCjAwMDAwMDA0NDkgNjU1MzUg Zg0KMDAwMDAwMDQ1MCA2NTUzNSBmDQowMDAwMDAwNDUxIDY1NTM1IGYNCjAwMDAwMDA0NTIg NjU1MzUgZg0KMDAwMDAwMDQ1MyA2NTUzNSBmDQowMDAwMDAwNDU0IDY1NTM1IGYNCjAwMDAw MDA0NTUgNjU1MzUgZg0KMDAwMDAwMDQ1NiA2NTUzNSBmDQowMDAwMDAwNDU3IDY1NTM1IGYN CjAwMDAwMDA0NTggNjU1MzUgZg0KMDAwMDAwMDQ1OSA2NTUzNSBmDQowMDAwMDAwNDYwIDY1 NTM1IGYNCjAwMDAwMDA0NjEgNjU1MzUgZg0KMDAwMDAwMDQ2MiA2NTUzNSBmDQowMDAwMDAw NDYzIDY1NTM1IGYNCjAwMDAwMDA0NjQgNjU1MzUgZg0KMDAwMDAwMDQ2NSA2NTUzNSBmDQow MDAwMDAwNDY2IDY1NTM1IGYNCjAwMDAwMDA0NjcgNjU1MzUgZg0KMDAwMDAwMDQ2OCA2NTUz NSBmDQowMDAwMDAwNDY5IDY1NTM1IGYNCjAwMDAwMDA0NzAgNjU1MzUgZg0KMDAwMDAwMDQ3 MSA2NTUzNSBmDQowMDAwMDAwNDcyIDY1NTM1IGYNCjAwMDAwMDA0NzMgNjU1MzUgZg0KMDAw MDAwMDQ3NCA2NTUzNSBmDQowMDAwMDAwNDc1IDY1NTM1IGYNCjAwMDAwMDA0NzYgNjU1MzUg Zg0KMDAwMDAwMDQ3NyA2NTUzNSBmDQowMDAwMDAwNDc4IDY1NTM1IGYNCjAwMDAwMDA0Nzkg NjU1MzUgZg0KMDAwMDAwMDQ4MCA2NTUzNSBmDQowMDAwMDAwNDgxIDY1NTM1IGYNCjAwMDAw MDA0ODIgNjU1MzUgZg0KMDAwMDAwMDQ4MyA2NTUzNSBmDQowMDAwMDAwNDg0IDY1NTM1IGYN CjAwMDAwMDA0ODUgNjU1MzUgZg0KMDAwMDAwMDQ4NiA2NTUzNSBmDQowMDAwMDAwNDg3IDY1 NTM1IGYNCjAwMDAwMDA0ODggNjU1MzUgZg0KMDAwMDAwMDQ4OSA2NTUzNSBmDQowMDAwMDAw NDkwIDY1NTM1IGYNCjAwMDAwMDA0OTEgNjU1MzUgZg0KMDAwMDAwMDQ5MiA2NTUzNSBmDQow MDAwMDAwNDkzIDY1NTM1IGYNCjAwMDAwMDA0OTQgNjU1MzUgZg0KMDAwMDAwMDQ5NSA2NTUz NSBmDQowMDAwMDAwNDk2IDY1NTM1IGYNCjAwMDAwMDA0OTcgNjU1MzUgZg0KMDAwMDAwMDQ5 OCA2NTUzNSBmDQowMDAwMDAwNDk5IDY1NTM1IGYNCjAwMDAwMDA1MDAgNjU1MzUgZg0KMDAw MDAwMDUwMSA2NTUzNSBmDQowMDAwMDAwNTAyIDY1NTM1IGYNCjAwMDAwMDA1MDMgNjU1MzUg Zg0KMDAwMDAwMDUwNCA2NTUzNSBmDQowMDAwMDAwNTA1IDY1NTM1IGYNCjAwMDAwMDA1MDYg NjU1MzUgZg0KMDAwMDAwMDUwNyA2NTUzNSBmDQowMDAwMDAwNTA4IDY1NTM1IGYNCjAwMDAw MDA1MDkgNjU1MzUgZg0KMDAwMDAwMDUxMCA2NTUzNSBmDQowMDAwMDAwNTExIDY1NTM1IGYN CjAwMDAwMDA1MTIgNjU1MzUgZg0KMDAwMDAwMDUxMyA2NTUzNSBmDQowMDAwMDAwNTE0IDY1 NTM1IGYNCjAwMDAwMDA1MTUgNjU1MzUgZg0KMDAwMDAwMDUxNiA2NTUzNSBmDQowMDAwMDAw NTE3IDY1NTM1IGYNCjAwMDAwMDA1MTggNjU1MzUgZg0KMDAwMDAwMDUxOSA2NTUzNSBmDQow MDAwMDAwNTIwIDY1NTM1IGYNCjAwMDAwMDA1MjEgNjU1MzUgZg0KMDAwMDAwMDUyMiA2NTUz NSBmDQowMDAwMDAwNTIzIDY1NTM1IGYNCjAwMDAwMDA1MjQgNjU1MzUgZg0KMDAwMDAwMDUy NSA2NTUzNSBmDQowMDAwMDAwNTI2IDY1NTM1IGYNCjAwMDAwMDA1MjcgNjU1MzUgZg0KMDAw MDAwMDUyOCA2NTUzNSBmDQowMDAwMDAwNTI5IDY1NTM1IGYNCjAwMDAwMDA1MzAgNjU1MzUg Zg0KMDAwMDAwMDUzMSA2NTUzNSBmDQowMDAwMDAwNTMyIDY1NTM1IGYNCjAwMDAwMDA1MzMg NjU1MzUgZg0KMDAwMDAwMDUzNCA2NTUzNSBmDQowMDAwMDAwNTM1IDY1NTM1IGYNCjAwMDAw MDA1MzYgNjU1MzUgZg0KMDAwMDAwMDUzNyA2NTUzNSBmDQowMDAwMDAwNTM4IDY1NTM1IGYN CjAwMDAwMDA1MzkgNjU1MzUgZg0KMDAwMDAwMDU0MCA2NTUzNSBmDQowMDAwMDAwNTQxIDY1 NTM1IGYNCjAwMDAwMDA1NDIgNjU1MzUgZg0KMDAwMDAwMDU0MyA2NTUzNSBmDQowMDAwMDAw NTQ0IDY1NTM1IGYNCjAwMDAwMDA1NDUgNjU1MzUgZg0KMDAwMDAwMDU0NiA2NTUzNSBmDQow MDAwMDAwNTQ3IDY1NTM1IGYNCjAwMDAwMDA1NDggNjU1MzUgZg0KMDAwMDAwMDU0OSA2NTUz NSBmDQowMDAwMDAwNTUwIDY1NTM1IGYNCjAwMDAwMDA1NTEgNjU1MzUgZg0KMDAwMDAwMDU1 MiA2NTUzNSBmDQowMDAwMDAwNTUzIDY1NTM1IGYNCjAwMDAwMDA1NTQgNjU1MzUgZg0KMDAw MDAwMDU1NSA2NTUzNSBmDQowMDAwMDAwNTU2IDY1NTM1IGYNCjAwMDAwMDA1NTcgNjU1MzUg Zg0KMDAwMDAwMDU1OCA2NTUzNSBmDQowMDAwMDAwNTU5IDY1NTM1IGYNCjAwMDAwMDA1NjAg NjU1MzUgZg0KMDAwMDAwMDU2MSA2NTUzNSBmDQowMDAwMDAwNTYyIDY1NTM1IGYNCjAwMDAw MDA1NjMgNjU1MzUgZg0KMDAwMDAwMDU2NCA2NTUzNSBmDQowMDAwMDAwNTY1IDY1NTM1IGYN CjAwMDAwMDA1NjYgNjU1MzUgZg0KMDAwMDAwMDU2NyA2NTUzNSBmDQowMDAwMDAwNTY4IDY1 NTM1IGYNCjAwMDAwMDA1NjkgNjU1MzUgZg0KMDAwMDAwMDU3MCA2NTUzNSBmDQowMDAwMDAw NTcxIDY1NTM1IGYNCjAwMDAwMDA1NzIgNjU1MzUgZg0KMDAwMDAwMDU3MyA2NTUzNSBmDQow MDAwMDAwNTc0IDY1NTM1IGYNCjAwMDAwMDA1NzUgNjU1MzUgZg0KMDAwMDAwMDU3NiA2NTUz NSBmDQowMDAwMDAwNTc3IDY1NTM1IGYNCjAwMDAwMDA1NzggNjU1MzUgZg0KMDAwMDAwMDU3 OSA2NTUzNSBmDQowMDAwMDAwNTgwIDY1NTM1IGYNCjAwMDAwMDA1ODEgNjU1MzUgZg0KMDAw MDAwMDU4MiA2NTUzNSBmDQowMDAwMDAwNTgzIDY1NTM1IGYNCjAwMDAwMDA1ODQgNjU1MzUg Zg0KMDAwMDAwMDU4NSA2NTUzNSBmDQowMDAwMDAwNTg2IDY1NTM1IGYNCjAwMDAwMDA1ODcg NjU1MzUgZg0KMDAwMDAwMDU4OCA2NTUzNSBmDQowMDAwMDAwNTg5IDY1NTM1IGYNCjAwMDAw MDA1OTAgNjU1MzUgZg0KMDAwMDAwMDU5MSA2NTUzNSBmDQowMDAwMDAwNTkyIDY1NTM1IGYN CjAwMDAwMDA1OTMgNjU1MzUgZg0KMDAwMDAwMDU5NCA2NTUzNSBmDQowMDAwMDAwNTk1IDY1 NTM1IGYNCjAwMDAwMDA1OTYgNjU1MzUgZg0KMDAwMDAwMDU5NyA2NTUzNSBmDQowMDAwMDAw NTk4IDY1NTM1IGYNCjAwMDAwMDA1OTkgNjU1MzUgZg0KMDAwMDAwMDYwMCA2NTUzNSBmDQow MDAwMDAwNjAxIDY1NTM1IGYNCjAwMDAwMDA2MDIgNjU1MzUgZg0KMDAwMDAwMDYwMyA2NTUz NSBmDQowMDAwMDAwNjA0IDY1NTM1IGYNCjAwMDAwMDA2MDUgNjU1MzUgZg0KMDAwMDAwMDYw NiA2NTUzNSBmDQowMDAwMDAwNjA3IDY1NTM1IGYNCjAwMDAwMDA2MDggNjU1MzUgZg0KMDAw MDAwMDYwOSA2NTUzNSBmDQowMDAwMDAwNjEwIDY1NTM1IGYNCjAwMDAwMDA2MTEgNjU1MzUg Zg0KMDAwMDAwMDYxMiA2NTUzNSBmDQowMDAwMDAwNjEzIDY1NTM1IGYNCjAwMDAwMDA2MTQg NjU1MzUgZg0KMDAwMDAwMDYxNSA2NTUzNSBmDQowMDAwMDAwNjE2IDY1NTM1IGYNCjAwMDAw MDA2MTcgNjU1MzUgZg0KMDAwMDAwMDYxOCA2NTUzNSBmDQowMDAwMDAwNjE5IDY1NTM1IGYN CjAwMDAwMDA2MjAgNjU1MzUgZg0KMDAwMDAwMDYyMSA2NTUzNSBmDQowMDAwMDAwNjIyIDY1 NTM1IGYNCjAwMDAwMDA2MjMgNjU1MzUgZg0KMDAwMDAwMDYyNCA2NTUzNSBmDQowMDAwMDAw NjI1IDY1NTM1IGYNCjAwMDAwMDA2MjYgNjU1MzUgZg0KMDAwMDAwMDYyNyA2NTUzNSBmDQow MDAwMDAwNjI4IDY1NTM1IGYNCjAwMDAwMDA2MjkgNjU1MzUgZg0KMDAwMDAwMDYzMCA2NTUz NSBmDQowMDAwMDAwNjMxIDY1NTM1IGYNCjAwMDAwMDA2MzIgNjU1MzUgZg0KMDAwMDAwMDYz MyA2NTUzNSBmDQowMDAwMDAwNjM0IDY1NTM1IGYNCjAwMDAwMDA2MzUgNjU1MzUgZg0KMDAw MDAwMDYzNiA2NTUzNSBmDQowMDAwMDAwNjM3IDY1NTM1IGYNCjAwMDAwMDA2MzggNjU1MzUg Zg0KMDAwMDAwMDYzOSA2NTUzNSBmDQowMDAwMDAwNjQwIDY1NTM1IGYNCjAwMDAwMDA2NDEg NjU1MzUgZg0KMDAwMDAwMDY0MiA2NTUzNSBmDQowMDAwMDAwNjQzIDY1NTM1IGYNCjAwMDAw MDA2NDQgNjU1MzUgZg0KMDAwMDAwMDY0NSA2NTUzNSBmDQowMDAwMDAwNjQ2IDY1NTM1IGYN CjAwMDAwMDA2NDcgNjU1MzUgZg0KMDAwMDAwMDY0OCA2NTUzNSBmDQowMDAwMDAwNjQ5IDY1 NTM1IGYNCjAwMDAwMDA2NTAgNjU1MzUgZg0KMDAwMDAwMDY1MSA2NTUzNSBmDQowMDAwMDAw NjUyIDY1NTM1IGYNCjAwMDAwMDA2NTMgNjU1MzUgZg0KMDAwMDAwMDY1NCA2NTUzNSBmDQow MDAwMDAwNjU1IDY1NTM1IGYNCjAwMDAwMDA2NTYgNjU1MzUgZg0KMDAwMDAwMDY1NyA2NTUz NSBmDQowMDAwMDAwNjU4IDY1NTM1IGYNCjAwMDAwMDA2NTkgNjU1MzUgZg0KMDAwMDAwMDY2 MCA2NTUzNSBmDQowMDAwMDAwNjYxIDY1NTM1IGYNCjAwMDAwMDA2NjIgNjU1MzUgZg0KMDAw MDAwMDY2MyA2NTUzNSBmDQowMDAwMDAwNjY0IDY1NTM1IGYNCjAwMDAwMDA2NjUgNjU1MzUg Zg0KMDAwMDAwMDY2NiA2NTUzNSBmDQowMDAwMDAwNjY3IDY1NTM1IGYNCjAwMDAwMDA2Njgg NjU1MzUgZg0KMDAwMDAwMDY2OSA2NTUzNSBmDQowMDAwMDAwNjcwIDY1NTM1IGYNCjAwMDAw MDA2NzEgNjU1MzUgZg0KMDAwMDAwMDY3MiA2NTUzNSBmDQowMDAwMDAwNjczIDY1NTM1IGYN CjAwMDAwMDA2NzQgNjU1MzUgZg0KMDAwMDAwMDY3NSA2NTUzNSBmDQowMDAwMDAwNjc2IDY1 NTM1IGYNCjAwMDAwMDA2NzcgNjU1MzUgZg0KMDAwMDAwMDY3OCA2NTUzNSBmDQowMDAwMDAw Njc5IDY1NTM1IGYNCjAwMDAwMDA2ODAgNjU1MzUgZg0KMDAwMDAwMDY4MSA2NTUzNSBmDQow MDAwMDAwNjgyIDY1NTM1IGYNCjAwMDAwMDA2ODMgNjU1MzUgZg0KMDAwMDAwMDY4NCA2NTUz NSBmDQowMDAwMDAwNjg1IDY1NTM1IGYNCjAwMDAwMDA2ODYgNjU1MzUgZg0KMDAwMDAwMDY4 NyA2NTUzNSBmDQowMDAwMDAwNjg4IDY1NTM1IGYNCjAwMDAwMDA2ODkgNjU1MzUgZg0KMDAw MDAwMDY5MCA2NTUzNSBmDQowMDAwMDAwNjkxIDY1NTM1IGYNCjAwMDAwMDA2OTIgNjU1MzUg Zg0KMDAwMDAwMDY5MyA2NTUzNSBmDQowMDAwMDAwNjk0IDY1NTM1IGYNCjAwMDAwMDA2OTUg NjU1MzUgZg0KMDAwMDAwMDY5NiA2NTUzNSBmDQowMDAwMDAwNjk3IDY1NTM1IGYNCjAwMDAw MDA2OTggNjU1MzUgZg0KMDAwMDAwMDY5OSA2NTUzNSBmDQowMDAwMDAwNzAwIDY1NTM1IGYN CjAwMDAwMDA3MDEgNjU1MzUgZg0KMDAwMDAwMDcwMiA2NTUzNSBmDQowMDAwMDAwNzAzIDY1 NTM1IGYNCjAwMDAwMDA3MDQgNjU1MzUgZg0KMDAwMDAwMDcwNSA2NTUzNSBmDQowMDAwMDAw NzA2IDY1NTM1IGYNCjAwMDAwMDA3MDcgNjU1MzUgZg0KMDAwMDAwMDcwOCA2NTUzNSBmDQow MDAwMDAwNzA5IDY1NTM1IGYNCjAwMDAwMDA3MTAgNjU1MzUgZg0KMDAwMDAwMDcxMSA2NTUz NSBmDQowMDAwMDAwNzEyIDY1NTM1IGYNCjAwMDAwMDA3MTMgNjU1MzUgZg0KMDAwMDAwMDcx NCA2NTUzNSBmDQowMDAwMDAwNzE1IDY1NTM1IGYNCjAwMDAwMDA3MTYgNjU1MzUgZg0KMDAw MDAwMDcxNyA2NTUzNSBmDQowMDAwMDAwNzE4IDY1NTM1IGYNCjAwMDAwMDA3MTkgNjU1MzUg Zg0KMDAwMDAwMDcyMCA2NTUzNSBmDQowMDAwMDAwNzIxIDY1NTM1IGYNCjAwMDAwMDA3MjIg NjU1MzUgZg0KMDAwMDAwMDcyMyA2NTUzNSBmDQowMDAwMDAwNzI0IDY1NTM1IGYNCjAwMDAw MDA3MjUgNjU1MzUgZg0KMDAwMDAwMDcyNiA2NTUzNSBmDQowMDAwMDAwNzI3IDY1NTM1IGYN CjAwMDAwMDA3MjggNjU1MzUgZg0KMDAwMDAwMDcyOSA2NTUzNSBmDQowMDAwMDAwNzMwIDY1 NTM1IGYNCjAwMDAwMDA3MzEgNjU1MzUgZg0KMDAwMDAwMDczMiA2NTUzNSBmDQowMDAwMDAw NzMzIDY1NTM1IGYNCjAwMDAwMDA3MzQgNjU1MzUgZg0KMDAwMDAwMDczNSA2NTUzNSBmDQow MDAwMDAwNzM2IDY1NTM1IGYNCjAwMDAwMDA3MzcgNjU1MzUgZg0KMDAwMDAwMDczOCA2NTUz NSBmDQowMDAwMDAwNzM5IDY1NTM1IGYNCjAwMDAwMDA3NDAgNjU1MzUgZg0KMDAwMDAwMDc0 MSA2NTUzNSBmDQowMDAwMDAwNzQyIDY1NTM1IGYNCjAwMDAwMDA3NDMgNjU1MzUgZg0KMDAw MDAwMDc0NCA2NTUzNSBmDQowMDAwMDAwNzQ1IDY1NTM1IGYNCjAwMDAwMDA3NDYgNjU1MzUg Zg0KMDAwMDAwMDc0NyA2NTUzNSBmDQowMDAwMDAwNzQ4IDY1NTM1IGYNCjAwMDAwMDA3NDkg NjU1MzUgZg0KMDAwMDAwMDc1MCA2NTUzNSBmDQowMDAwMDAwNzUxIDY1NTM1IGYNCjAwMDAw MDA3NTIgNjU1MzUgZg0KMDAwMDAwMDc1MyA2NTUzNSBmDQowMDAwMDAwNzU0IDY1NTM1IGYN CjAwMDAwMDA3NTUgNjU1MzUgZg0KMDAwMDAwMDc1NiA2NTUzNSBmDQowMDAwMDAwNzU3IDY1 NTM1IGYNCjAwMDAwMDA3NTggNjU1MzUgZg0KMDAwMDAwMDc1OSA2NTUzNSBmDQowMDAwMDAw NzYwIDY1NTM1IGYNCjAwMDAwMDA3NjEgNjU1MzUgZg0KMDAwMDAwMDc2MiA2NTUzNSBmDQow MDAwMDAwNzYzIDY1NTM1IGYNCjAwMDAwMDA3NjQgNjU1MzUgZg0KMDAwMDAwMDc2NSA2NTUz NSBmDQowMDAwMDAwNzY2IDY1NTM1IGYNCjAwMDAwMDA3NjcgNjU1MzUgZg0KMDAwMDAwMDc2 OCA2NTUzNSBmDQowMDAwMDAwNzY5IDY1NTM1IGYNCjAwMDAwMDA3NzAgNjU1MzUgZg0KMDAw MDAwMDc3MSA2NTUzNSBmDQowMDAwMDAwNzcyIDY1NTM1IGYNCjAwMDAwMDA3NzMgNjU1MzUg Zg0KMDAwMDAwMDc3NCA2NTUzNSBmDQowMDAwMDAwNzc1IDY1NTM1IGYNCjAwMDAwMDA3NzYg NjU1MzUgZg0KMDAwMDAwMDc3NyA2NTUzNSBmDQowMDAwMDAwNzc4IDY1NTM1IGYNCjAwMDAw MDA3NzkgNjU1MzUgZg0KMDAwMDAwMDc4MCA2NTUzNSBmDQowMDAwMDAwNzgxIDY1NTM1IGYN CjAwMDAwMDA3ODIgNjU1MzUgZg0KMDAwMDAwMDc4MyA2NTUzNSBmDQowMDAwMDAwNzg0IDY1 NTM1IGYNCjAwMDAwMDA3ODUgNjU1MzUgZg0KMDAwMDAwMDc4NiA2NTUzNSBmDQowMDAwMDAw Nzg3IDY1NTM1IGYNCjAwMDAwMDA3ODggNjU1MzUgZg0KMDAwMDAwMDc4OSA2NTUzNSBmDQow MDAwMDAwNzkwIDY1NTM1IGYNCjAwMDAwMDA3OTEgNjU1MzUgZg0KMDAwMDAwMDc5MiA2NTUz NSBmDQowMDAwMDAwNzkzIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA0ODEw MCAwMDAwMCBuDQowMDAwMDQ4NjA3IDAwMDAwIG4NCjAwMDAxNDMxODkgMDAwMDAgbg0KMDAw MDE0MzgxMSAwMDAwMCBuDQowMDAwMTQ0MTQ5IDAwMDAwIG4NCjAwMDAxNDQ0NTkgMDAwMDAg bg0KMDAwMDE4NTAzNyAwMDAwMCBuDQowMDAwMTg1MDgzIDAwMDAwIG4NCjAwMDAxODUzMTUg MDAwMDAgbg0KMDAwMDI2NTg0MyAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDgwNC9Sb290 IDEgMCBSL0luZm8gNTMgMCBSL0lEWzw4Q0UxNTJEOEFENDQwMzRBOUMxQjZBNDJBODZBNzlD OT48OENFMTUyRDhBRDQ0MDM0QTlDMUI2QTQyQTg2QTc5Qzk+XSA+Pg0Kc3RhcnR4cmVmDQoy Njc2NTINCiUlRU9GDQp4cmVmDQowIDANCnRyYWlsZXINCjw8L1NpemUgODA0L1Jvb3QgMSAw IFIvSW5mbyA1MyAwIFIvSURbPDhDRTE1MkQ4QUQ0NDAzNEE5QzFCNkE0MkE4NkE3OUM5Pjw4 Q0UxNTJEOEFENDQwMzRBOUMxQjZBNDJBODZBNzlDOT5dIC9QcmV2IDI2NzY1Mi9YUmVmU3Rt IDI2NTg0Mz4+DQpzdGFydHhyZWYNCjI4Mzg5Mg0KJSVFT0Y= --------------050909070407080102030004-- From harald@alvestrand.no Tue Oct 22 05:24:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9266011E835B for ; Tue, 22 Oct 2013 05:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJnPKL-50mzS for ; Tue, 22 Oct 2013 05:24:24 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A099E11E81A0 for ; Tue, 22 Oct 2013 05:24:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 34C3D39E12D; Tue, 22 Oct 2013 14:24:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUxAr7Q0i3zw; Tue, 22 Oct 2013 14:24:10 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0B18B39E062; Tue, 22 Oct 2013 14:24:10 +0200 (CEST) Message-ID: <52666E6E.5060206@alvestrand.no> Date: Tue, 22 Oct 2013 14:24:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Martin Thomson References: <5265386A.2020005@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:24:30 -0000 On 10/21/2013 06:38 PM, Martin Thomson wrote: > On 21 October 2013 07:21, Harald Alvestrand wrote: >> When receiving browser supports both A and B, we could argue that they >> should be allowed to be different in the name of algorithm agility. But is >> there a real gain in security achieved by it? > Those are interesting cases, but they easily solved by saying > something like "MUST include/implement SHA-256". Until SHA-512 comes along. If I don't support SHA-512, and the certificate says you have to use SHA-512 to verify the certificate, but I have a fingerprint using SHA-256, am I exposed to some attack I'd have been protected against if I understood SHA-512, or not? > > I don't think that the hash used by the certificate is actually > relevant either. Fingerprints are calculated, not observed or > extracted. Well - they are extracted from SDP, and compared, which is a form of observation.... but you may be thinking of something else; I find that sentence hard to parse. From bo.burman@ericsson.com Tue Oct 22 07:20:47 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE4B11E81B3 for ; Tue, 22 Oct 2013 07:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE0UCeX3Z7jq for ; Tue, 22 Oct 2013 07:20:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA211E83D8 for ; Tue, 22 Oct 2013 07:20:41 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-f4-526689b8c894 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 53.52.03802.8B986625; Tue, 22 Oct 2013 16:20:40 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 16:20:40 +0200 From: Bo Burman To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Comments on H.264 and VP8 performance comparisons Thread-Index: Ac7JIe76OhlqjGwCQFaenvACTkQ0VwF2Vc2AAA12J5A= Date: Tue, 22 Oct 2013 14:20:39 +0000 Message-ID: References: <52664A39.5040105@alvestrand.no> In-Reply-To: <52664A39.5040105@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6OzrQgg6trzC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGUse/WOpWCJWcWVJ4YNjIu0uxg5OSQETCSu 71rLBmGLSVy4tx7I5uIQEjjMKDF/xg1mCGcRo8SrWS8ZQarYBDQk5u+4C2aLCARL9D5/D2YL C7hL9N6aCNTNART3kGhbrgBRYiWx995SJhCbRUBVYsftGawgNq+Ar8Srd8fA4kICBRK7/r5m B7E5BXQlehasBxvJKCArcf/7PRYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErShxdfpy Joh6HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGJkz03MzEkv N9rECIyEg1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY Rfb/e8F8aMnTCQl7s/dphwVNnS+qlmfYFeH2922MUcuEvbqVgaUaeg3z78hvVZzb2Sm95KCz Vlp0T+6vqM+zGZ4rytUIHhU+/Jldur5i7rOkqdP0n+nuuWXZ+vOjQVKsaNERrpVPzu0NeP7W MuPSY9/5ga+ickou1352XqxTektg0ofsUq5oJZbijERDLeai4kQALANI9lICAAA= Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:20:47 -0000 Hi all, We understand that there are many people that are interested in a VP8 vs x2= 64 comparison that includes rate controls. We therefore performed a quick study of the VP8 and x264 rate controls to s= ee whether there were any major differences between them in the way they se= lect quantizers. We found that VP8 uses what can be described as QP-togglin= g: By lowering the QP of, say, every 6th frame, you increase the quality of= these markedly. The following frames also benefit from the increased quali= ty (even though they have to make do with less bits than before) since they= can predict from the high-quality frame.=20 However, we found that the rate-control of x264 does not QP-toggle in this = fine granular way, and x264 may therefore be at a disadvantage when compari= ng against VP8. So we ran a test using a modified version of x264 to allow = QP-toggling during rate control. The modification is very simple and a patc= h for the x264 code is found in the bottom of this email. With this change, H.264 baseline (implemented using the modified x264 with = rate control turned on) performs equally to VP8 with rate-control on; the d= ifference is 1.3% in favor of VP8, but if you swap the order of the two cod= ecs in draw_graphs.sh, H.264 baseline wins with 1.6%. This result is thus a= tie between VP8 and H.264 baseline, and this is consistent with our previo= us fixed-QP test, and far from the (at least) 13% advantage for VP8 stated = by Google. The modification is simple and it may well be possible to improve x264 by m= ore sophisticated modifications. But pursuing this track is what we oppose,= we do not want comparisons where the outcome depends on how well you modif= y a particular rate control mechanism - the rate control is codec-agnostic= after all. To avoid this we still maintain our view that codec comparisons= should be done using fixed QP settings, which is also the practice in MPEG= and VCEG. We used the test parameters from Google's test repository https://git.chro= mium.org/git/webm/vpx_codec_comparison.git, the version ada7d7937a54e47fc18= e2e0a1287aea29dc5d1c5. Here are the x264 and comparison script patches: -- diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c index 1a39a49..2cf256f 100644 --- a/encoder/ratecontrol.c +++ b/encoder/ratecontrol.c @@ -1707,7 +1707,18 @@ int x264_ratecontrol_mb_qp( x264_t *h ) { x264_emms(); float qp =3D h->rc->qpm; - if( h->param.rc.i_aq_mode ) + + if (h->sh.i_type !=3D SLICE_TYPE_I){ + if ((h->fenc->i_poc % 12 )=3D=3D 0) + qp -=3D 3.0; + else + qp +=3D 0.0; + =20 + } else { + qp -=3D 5.0; + } + + if( h->param.rc.i_aq_mode) { /* MB-tree currently doesn't adjust quantizers in unreferenced fr= ames. */ float qp_offset =3D h->fdec->b_kept_as_ref ? h->fenc->f_qp_offset[= h->mb.i_mb_xy] : h->fenc->f_qp_offset_aq[h->mb.i_mb_xy]; draw_graphs.sh: change=20 ./visual_metrics.py metrics_template.html "*0.txt" stats/h264 stats/vp8 > = vp8_vs_h264_quality.html to ./visual_metrics.py metrics_template.html "*0.txt" stats/vp8 stats/h264 > = vp8_vs_h264_quality2.html Best Regards, Bo Burman > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Harald Alvestrand > Sent: den 22 oktober 2013 11:50 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons >=20 > On 10/14/2013 11:12 PM, Bo Burman wrote: > > Hi all, > > > > We would like to counter Google's suggestion that our test has only "de= monstrated that it is possible to reduce VP8's > performance" (updated draft on VP8 http://datatracker.ietf.org/doc/draft-= alvestrand-rtcweb-vp8/). > > > > In fact, what we did in our test was mostly undoing some very peculiar > > x264 settings made by Google in their test from April 3. By instead > > using the x264 settings Google themselves proposed in their earlier > > test (from March 12), and removing threading, the difference went down > > from 41% to 16%. (This is without touching the VP8 parameters.) > > > > The last change we made was to remove the rate control from the compari= son, something that is standard practice in > the world of video standardization. This involved changing both the x264 = and VP8 parameters. After that, the difference > went down to -1%. > > > > In summary, the following steps were taken in our comparison: > > > > 1) Downloading the latest software: 41% became 36% > > 2) Removing threading: 26% > > 3) Removing bit padding: 18% > > 4) Removing other differences between Google's March 12 and April 3rd > > tests: 16% > > 5) Removing rate controller: -1% > > > > > Just a quick update on this - I did not manage to get a new draft ready b= efore the deadline, so I'll have to resort to > sending email: >=20 > I applied steps 1), 2) and 3) to the repository mentioned in the draft. > The numbers I got were different, but significant. Below are the > VP8-to-x264 differences I encountered each step of the way. >=20 > - Master branch before October 15: Difference 71.52% > - Updating x264 from 198a7ea (aug 16 2012) to c832fe (March 1 2013): > Difference 71.44% > (I could not go beyond this because yasm 1.2 was required for newer ve= rsions). > - Adding the --thread 1 parameter: Difference 26.11% > - Removing the --nai-hrd=3Dcbr parameter that was suggested by x264 > people: Difference 13.87% > - Removing vbv-maxrate and vbv-init 0.8: Difference 12.74% >=20 > I did not shorten the clips to 10 seconds, nor did I try to control rate = by constant cq instead of a rate controller; if Bo's > numbers are right, this shouldn't matter. >=20 > I did try removing "vbv-bufsize ${rate}", since this was the remaining di= fference I could find for Bo's point 4 "other > differences", but that was actually harmful (difference increased to 19.0= 5%), so I put it back. >=20 > I checked this in to the repository - the commit is here: >=20 > http://git.chromium.org/gitweb/?p=3Dwebm/vpx_codec_comparison.git;a=3Dcom= mitdiff;h=3Dada7d7937a54e47fc18e2e0a1287 > aea29dc5d1c5 >=20 >=20 > This number does not fit the impression the video codec team has from oth= er tests - they think > VP8 can do a lot more than 13% better than baseline - but at the draft de= adline, we had not found the set of VP8 > parameters that showed this for this particular clip set. >=20 > Commentary: I'm surprised at x264's choice of default value for the --thr= ead parameter. Accepting a 26% bitrate hit > seems like a large price to pay for going faster by default. Is there a b= ug here? >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From karl.stahl@intertex.se Tue Oct 22 07:37:34 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C8C11E8494 for ; Tue, 22 Oct 2013 07:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_40=-0.185, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tszmSftO3PdF for ; Tue, 22 Oct 2013 07:37:29 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7223911E83C7 for ; Tue, 22 Oct 2013 07:36:40 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310221636281499; Tue, 22 Oct 2013 16:36:29 +0200 From: "Karl Stahl" To: "'Dan Wing'" , "'Ted Hardie'" , "'Harald Alvestrand'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> In-Reply-To: Date: Tue, 22 Oct 2013 16:36:31 +0200 Message-ID: <02b501cecf34$1a1dc250$4e5946f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B6_01CECF44.DDA69250" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7G4vcMd4grRwnSQw68FakoPtGiLAIMBzEQ Content-Language: sv Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:37:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02B6_01CECF44.DDA69250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This discussion got side tracked from where I started it from, so in the next two mails I am jumping back to the threads where the original = subjects were left. =20 =20 Comment on this discussion:=20 Using a WebRTC browser as a client into an application specific network (e.g. IMS/VoLTE/RCS) is one usage of WebRTC. When building such a = gateway as a Web application, doesn=92t the gateway (the web application) in itself = know the characteristics of the application specific network? I don=92t see = the need to discover that. =20 But such gateway has the other side towards the Internet - That is where = we have the Web and the WebRTC browser.=20 =20 For the Internet side (in general, and of course with browser to browser communication over the Internet also in mind) I raised two questions: 1) How can the browser find a network provided TURN server (both local = on a LAN or provided by a carrier)? 2) Can the WebRTC browser/application convey real-time quality = requirements to the network, by using the payload type (that is what we can still see = in RTP, when both the payload and signaling are hidden from the network as = it is with WebRTC, and diffserv bits are not sufficient and not available through the OSs). =20 These questions are related: There are carriers wanting to support = WebRTC traffic with better Internet access than their data crowded best effort accesses. ICE/STUN/TURN allows a network provider to capture the = real-time traffic in a TURN server, where the network provider can offer a better = path for real-time traffic.=20 =20 Capturing such TURN flow, is a good start for providing better network quality, but it would be even better would if the bandwidth requirements = and maybe some more qualities could be seen by the TURN server, e.g. by signaling them in the RTP payload type. (This is especially true and I = would say required for RSVP type of networks, that has to reserve bandwidth.) =20 Jumping back to the two threads I started which were left at: =20 1) Justin pointing out the bootstrap problem of using reverse DNS to = find a network provided TURN server. (How is the STUN server to use first = found?) I will instead propose an anycast-way, that I think will do everything we = are looking for. =20 2) Harald listing the media types and their various quality needs. There = is actually a good way to signal those needs to the network (without using = the PT, or diffserv bits, which aren=92t sufficient for RSVP type of = networks anyway). The RTP header extension field is also visible to the network, = and a week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that = outlines the use of the extension field for classification of the traffic. =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Dan Wing Skickat: den 12 oktober 2013 02:35 Till: Ted Hardie Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 =20 On Oct 10, 2013, at 9:30 AM, Ted Hardie wrote: On Thu, Oct 10, 2013 at 8:02 AM, wrote: The basic question seems to be: how can the web server or JS client = learn about local policy enforcement elements in the user's network and access them to allocate bandwidth, setup priorisation etc? =20 So, I'm a little confused about why that is the basic question. If the prioritization is done by something like a diffserv code point, it seems like the question is how the flow signals its classification, rather = than to whom it signals that . I would presume that the networks which honor = such markings would be constructed such that some conversant network element = is on path. What it is and where it is kind of aren't the JS app or = browser's issue. What am I missing? =20 * Several operating systems do not allow non-privileged applications to = set DSCP bits at all; Windows, for example. Yes, I know everyone is = supposed to use any other OS, but Linux has also only allowed certain DSCP values to = be set. * When joining a network, the DSCP values for the network cannot be = learned or discovered -- we lack a protocol to do that. The RFCs that define = DSCP values are not standards (they are informational) and many a network = choose their own values. =20 * Setting the correct DSCP value affects only outgoing traffic but has = no influence on the incoming traffic. As you stated in a later post, = incoming DSCP isn't trusted anyway. "Reflexive DSCP Policy" was attempted years = ago to allow the network to assume a host's DSCP settings could be applied = to the other direction, but it was rejected I believe during IETF review = but I couldn't find record why it was actually disposed (document was draft-ietf-ieprep-reflexive-dscp). =20 -d =20 Ted =20 The ALTO WG had a very similar problem and proposed DHCP after DNS = experts dismissed a discovery mechanism based on reverse DNS lookups. The classical solution: avoid the problem by having a webrtc server in = your local network which does policy enforcement/QoS priorisation etc, and interconnects to some other webrtc server with a standardized protocol = like SIP or XMPP. Popular in RTCWEB, less popular elsewhere.. The DHCP way: let the browser learn about the policy enforcement = elements through DHCP, it may communicate them to the server. This has some = problems. There are no widely adopted DHCP APIs, and the policy enforcement = elements may be unwilling to let some random web server access them. DNS magic: derive the address of your local policy enforcement element = by manipulating the result of a reverse DNS lookup of the global IP = address. Manual configuration: Solves only the problem of missing DHCP APIs and introduces the usability nightmare we know too well from SIP clients. 3rd party auth: the user authenticates with a local idP, which not only carries the user's name but also the local policy enforcement urls as attributes. A web server can use the 3rd party auth token to access the local network elements. Haven't thought this through yet. Wolfgang Beck -----Urspr=FCngliche Nachricht----- Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag = von Harald Alvestrand Gesendet: Dienstag, 8. Oktober 2013 13:01 An: rtcweb@ietf.org Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, > >> Also, are you really interested in knowing that it is VP9 vs H.264, >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you >> try to > achieve them. > > Actually, my concern is to get an idea of the maximum bandwidth that > could be required for a WebRTC (ICE) setup media flow. Both voice and > video should be prioritized over data (their individual priority is of > less importance as long as there is sufficient bandwidth for both). You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. > > With diffserv you don't need to know the bandwidth requirement, but > with RSVP reservation (like in cable and mobile networks) you need to > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > H.264 is like 3,5 mbps. Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. > > To add to the complication of codec variants, the video codecs in > question for WebRTC have variable bandwidth, and when there is a poor > connection we see Chrome reducing the video window size to reduce the bandwidth used... > > I think the payload type field at best can reflect a maximum bandwidth > to initially reserve bandwidth for, and thereafter make new > reservations if the bandwidth changes during the call. So could we > change RTP to show maximum bandwidth instead of payload type in that > field outside the encrypted payload :) ... Or maybe that is not a = joke? I think these ruminations only lead to one conclusion: You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_000_02B6_01CECF44.DDA69250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Th= is discussion got side tracked from where I started it from, so in the = next two mails I am jumping back to the threads where the original = subjects were left. =A0

 

Co= mment on this discussion:

Us= ing a WebRTC browser as a client into an application specific network = (e.g. IMS/VoLTE/RCS) is one usage of WebRTC. When building such a = gateway as a Web application, doesn’t the gateway (the web = application) in itself know the characteristics of the application = specific network? I don’t see the need to discover = that.

 

Bu= t such gateway has the other side towards the Internet - That is where = we have the Web and the WebRTC browser.

 

Fo= r the Internet side (in general, and of course with browser to browser = communication over the Internet also in mind)=A0 I raised two = questions:

1)= How can the browser find a network provided TURN server (both local on = a LAN or provided by a carrier)?

2)= Can the WebRTC browser/application convey real-time quality = requirements to the network, by using the payload type (that is what we = can still see in RTP, when both the payload and signaling are hidden = from the network as it is with WebRTC, and diffserv bits are not = sufficient and not available through the OSs).

 

Th= ese questions are related: There are carriers wanting to support WebRTC = traffic with better Internet access than their data crowded best effort = accesses. ICE/STUN/TURN allows a network provider to capture the = real-time traffic in a TURN server, where the network provider can offer = a better path for real-time traffic.

 

Ca= pturing such TURN flow, is a good start for providing better network = quality, but it would be even better would if the bandwidth requirements = and maybe some more qualities could be seen by the TURN server, e.g. by = signaling them in the RTP payload type. (This is especially true and I = would say required for RSVP type of networks, that has to reserve = bandwidth.)

 

Ju= mping back to the two threads I started which were left = at:

 

1)= Justin pointing out the bootstrap problem of using reverse DNS to find = a network provided TURN server. (How is the STUN server to use first = found?) I will instead propose an anycast-way, that I think will do = everything we are looking for.

 

2)= Harald listing the media types and their various quality needs. There = is actually a good way to signal those needs to the network (without = using the PT, or diffserv bits, which aren’t sufficient for RSVP = type of networks anyway). The RTP header extension field is also visible = to the network, and a week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that = outlines the use of the extension field for classification of the = traffic.

 

/K= arl

 

 

Fr=E5n: = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Dan Wing
Skickat: den 12 oktober 2013 = 02:35
Till: Ted Hardie
Kopia: = rtcweb@ietf.org
=C4mne: Re: [rtcweb] Payload Types assignments = was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

 

On = Oct 10, 2013, at 9:30 AM, Ted Hardie <ted.ietf@gmail.com> = wrote:



On = Thu, Oct 10, 2013 at 8:02 AM, <BeckW@telekom.de> = wrote:

The basic question = seems to be: how can the web server or JS client learn about local = policy enforcement elements in the user's network and access them to = allocate bandwidth, setup priorisation = etc?

 

So, I'm a little confused about why that is the basic = question.  If the prioritization is done by something like a = diffserv code point, it seems like the question is how the flow signals = its classification, rather than to whom it signals that .  I would = presume that the networks which honor such markings would be constructed = such that some conversant network element is on path.  What it is = and where it is kind of aren't the JS app or browser's = issue.

What am I = missing?

 

* = Several operating systems do not allow non-privileged applications to = set DSCP bits at all; Windows, for example.  Yes, I know everyone = is supposed to use any other OS, but Linux has also only allowed certain = DSCP values to be set.

* = When joining a network, the DSCP values for the network cannot be = learned or discovered -- we lack a protocol to do that.  The RFCs = that define DSCP values are not standards (they are informational) and = many a network choose their own values. =  

* Setting the = correct DSCP value affects only outgoing traffic but has no influence on = the incoming traffic.  As you stated in a later post, incoming DSCP = isn't trusted anyway.  "Reflexive DSCP Policy" was = attempted years ago to allow the network to assume a host's DSCP = settings could be applied to the other direction, but it was rejected I = believe during IETF review but I couldn't find record why it was = actually disposed (document = was draft-ietf-ieprep-reflexive-dscp).

 

-d

 




Ted


 

The ALTO = WG had a very similar problem and proposed DHCP after DNS experts = dismissed a discovery mechanism based on reverse DNS lookups.

The = classical solution: avoid the problem by having a webrtc server in your = local network which does policy enforcement/QoS priorisation etc, and = interconnects to some other webrtc server with a standardized protocol = like SIP or XMPP. Popular in RTCWEB, less popular elsewhere..

The = DHCP way: let the browser learn about the policy enforcement elements = through DHCP, it may communicate them to the server. This has some = problems. There are no widely adopted DHCP APIs, and the policy = enforcement elements may be unwilling to let some random web server = access them.

DNS magic: derive the address of your local policy = enforcement element by manipulating the result of a reverse DNS lookup = of the global IP address.

Manual configuration: Solves only the = problem of missing DHCP APIs and introduces the usability nightmare we = know too well from SIP clients.

3rd party auth: the user = authenticates with a local idP, which not only carries the user's name = but also the local policy enforcement urls as attributes. A web server = can use the 3rd party auth token to access the local network elements. = Haven't thought this through yet.


Wolfgang = Beck

-----Urspr=FCngliche Nachricht-----
Von: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] Im = Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 = 13:01
An: rtcweb@ietf.org
Betreff: Re: = [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

<= p class=3DMsoNormal>
On 10/08/2013 09:17 AM, Karl Stahl = wrote:
> Hej Magnus,
>
>> Also, are you really = interested in knowing that it is VP9 vs H.264,
>> isn't
> = the questions this is video of this priority that is = important?
>> I think you need to more carefully consider what = are the goals you
>> try to
> achieve = them.
>
> Actually, my concern is to get an idea of the = maximum bandwidth that
> could be required for a WebRTC (ICE) = setup media flow. Both voice and
> video should be prioritized = over data (their individual priority is of
> less importance as = long as there is sufficient bandwidth for both).

You don't know = that without knowing what the application is for.
In, for instance, a = shooter game with voice backchannels, the movement and event information = (data) is MORE time sensitive than the voice data.

>
> = With diffserv you don't need to know the bandwidth requirement, = but
> with RSVP reservation (like in cable and mobile networks) = you need to
> know how much to reserve. Voice is like 100's = kbit/s, video VP8 or
> H.264 is like 3,5 mbps.

Again, = without knowing the application, you don't know that.
The application = could decide to use QCIF or HD, and the bandwidth variation of = screencast (semi-static with sudden, large changes) is completely = different from that of a talking head, which is again completely = different from a high-movement scene.

>
> To add to the = complication of codec variants, the video codecs in
> question for = WebRTC have variable bandwidth, and when there is a poor
> = connection we see Chrome reducing the video window size to reduce the = bandwidth used...
>
> I think the payload type field at best = can reflect a maximum bandwidth
> to initially reserve bandwidth = for, and thereafter make new
> reservations if the bandwidth = changes during the call. So could we
> change RTP to show maximum = bandwidth instead of payload type in that
> field outside the = encrypted payload :) ... Or maybe that is not a joke?

I think = these ruminations only lead to one conclusion:

You can't tell = what the needed bandwidth is up front without asking the = application.
You can't tell what the right priority ranking is = without asking the application.

If you need to know the bandwidth = or the priority up front, the application has to tell you. Anything else = is pure = heuristics.

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

 

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

 

------=_NextPart_000_02B6_01CECF44.DDA69250-- From karl.stahl@intertex.se Tue Oct 22 07:37:43 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4841111E849A for ; Tue, 22 Oct 2013 07:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deFLrWeiRMHw for ; Tue, 22 Oct 2013 07:37:39 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3C111E81B3 for ; Tue, 22 Oct 2013 07:37:12 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310221636561594; Tue, 22 Oct 2013 16:36:56 +0200 From: "Karl Stahl" To: "'Justin Uberti'" , "'Cullen Jennings \(fluffy\)'" References: <523c6d3d.c9d1440a.3b96.7499SMTPIN_ADDED_BROKEN@mx.google.com> <5244104D.4010401@alvestrand.no> <524a139b.e37e700a.694f.ffffae7bSMTPIN_ADDED_BROKEN@mx.google.com> <5252b565.2913980a.7a03.ffff8dd3SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Tue, 22 Oct 2013 16:36:59 +0200 Message-ID: <02ba01cecf34$2ac8ba10$805a2e30$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02BB_01CECF44.EE518A10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7D7g7nxzWXGqX+RBm5EQBzuF+/FQFA9ElA Content-Language: sv Cc: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: [rtcweb] [mmusic] Anycast discovery, Was TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:37:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02BB_01CECF44.EE518A10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See my comments below. The problem of having to know a first STUN server = in order to use DNS discovery, makes the suggestions below less good. =20 Another idea came up; to use anycast to allow a WebRTC browser to find a = network provided TURN server (both local on a LAN or provided by a = carrier). (There are some discussion around using anycast in the STUN = and TURN RFCs.) This anycast-way should work both for a TURN server on a = LAN and a TURN server outside the NAT/Firewall (any router in the chain = can take care of an anycast address) and by the simple method below, = return the available TURN server closest to the client. Finding a TURN = server close to the client (the WebRTC browser) will also minimize = =E2=80=9Cthe turn=E2=80=9D the real-time traffic has to take. =20 =20 The suggestion is to define an anycast IP address for STUN servers and: - The network provider, offering a TURN server on his access, adds a = route in his access router (or NAT/Firewall) so that the anycast address = routes to his TURN/STUN server (a TURN server is an extension of STUN = server, thus included in the same box). - The TURN/STUN server is configured to respond to a binding request = with a =E2=80=9C300 Try alternate server=E2=80=9D, that points out the = same TURN/STUN server (by its real IP address, not the anycast address). =20 The WebRTC browser client would then: - Issue a STUN binding request to the anycast address - Issue another STUN binding request to the ALTERNATE SERVER IP address = in the =E2=80=9C300 Try alternate=E2=80=9D response (as any client = should do).=20 - Interpret the received =E2=80=9C300 Try alternate=E2=80=9D response = now having the same ALTERNATE SERVER IP address as the source IP address = of that response, as an indication to use its TURN server (not the STUN = server) at that address.=20 =20 That is the TURN server to use! =20 The only addition to existing standards is the interpretation above of = the =E2=80=9C300 Try alternate=E2=80=9D response in the STUN RCF 5766 = having the same ALTERNATE SERVER IP address as the source IP address of = the response. It means: Use the TURN server at the specified address. = That should be easy to clarify. (The STUN server at the anycast address, may or may not be the same = TURN/STUN server used in second binding request.)=20 =20 Authentication could simply be that the TURN/STUN server only is = reachable from the IP addresses that the network provider want to = support with the TURN server (easy for the network provider, since he is = handing out those IP addresses). =20 This should be easy to provision for a carrier or a LAN administrator = and trivial to try for the WebRTC browser. =20 An advantage is that the two STUN binding requests directly returns the = TURN server address, whereby the following ICE process should be quick = and easy. This could also be done only once when the browser is started = or get a new IP address and cashed for later calls. =20 /Karl =20 PS If you wonder why not define an anycast address for a TURN server = instead, read this thread from 2008: = = http://www.ietf.org/mail-archive/web/behave/current/msg03582.html. = There, the use of anycast to a TURN server is discussed, but found not = to work. (Here anycast is only used for the first request to the STUN = server, where after the real address to the TURN/STUN server is used.) =20 =20 =20 Fr=C3=A5n: Justin Uberti [ = mailto:juberti@google.com]=20 Skickat: den 8 oktober 2013 08:17 Till: Karl Stahl Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); = = draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; = rtcweb@ietf.org =C3=84mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 =20 =20 On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl < = karl.stahl@intertex.se> wrote: So the WPAD-way of getting a network provider=E2=80=99s TURN server = address for the real (white, global) IP address he has handed out to a = user, the browser would: - Use STUN to find the global IP address (done anyway in ICE) =20 How does this get bootstrapped? That is, how is the STUN server found? [Karl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery. =20 - Do a reverse DNS lookup (instead of the DNS-Based Service Discovery = that is not yet deployed) - Make a URL based on the hostname from the reverse DNS lookup, e.g. = from 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com =20 I was hoping we could do something simpler, such as using the ISP's = configured domain search list, to determine the domain. [Karl] But carriers don=E2=80=99t push out such things, do they? And if = they could do it via DHCP we are back with those problems again. - And there find a list (in JS) of TURN server addresses for the network = provider=E2=80=99s IP addresses Or would an alternative be to add your own IP address to the URL and = get only your specific TURN server address? =20 Doing it at this Web level, I think we also should consider clients = using ICE/TURN, but not having the luxury of a JS engine: Would e.g. a = SIP client be able to parse a =E2=80=9CJS table=E2=80=9D to find his = TURN server address easily? Also, are there long time-outs to be = considered when there is no h ttp://turned.myvzw.com to be found? =20 This method may be easier for a network provider to deploy (I = don=E2=80=99t know, but for local use on a LAN I guess it is). On the = other hand, the DNS-Based Service Discovery method is quick and easy for = a WebRTC browser, so that may be tried as well. =20 Independent of how we find the network provided TURN server, one = advantage with it is the authentication: The network provider simply = sets up the TURN for usage from the IP addresses he has handed out. =20 /Karl =20 Fr=C3=A5n: Justin Uberti [mailto: = juberti@google.com]=20 Skickat: den 3 oktober 2013 20:59 Till: Karl Stahl Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); = = draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; = rtcweb@ietf.org =C3=84mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 WPAD already supports DNS-based discovery (in addition to DHCP). If you = have = host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it = will try to get a PAC file from = wpad.mobileonline.telia.com. =20 Since for all practical purposes, TURN is a "UDP proxy", I think it = should be handled similar to other proxy autoconfig mechanisms. =20 On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl < = karl.stahl@intertex.se> wrote: I happily withdraw my suggestion to use DHCP to find a network provider = offered TURN server in favor of the DNS-Based Service Discovery method = (inserted last below). The major problem with the DHCP usage was that = you then also have to do something similar for: RA - Router = Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and = something for the mobile OTT channel =E2=80=93 wherever DHCP is NOT the = method to give you an IP address. =20 Further: > On Thu, Sep 27, 2013 Justin Uberti wrote: > Agree. I still think that extending PAC files to include TURN = information is the right way to go. > PAC files can already be discovered via DHCP or DNS, there is no need = to reinvent this wheel. =20 >>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < = fluffy@cisco.com> wrote: >>I think we need to give some advise to the browsers vendors on what = they should implement to find turn servers =20 I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file = can be picked up through a URL based on the device name. Similar could = work for finding a TURN server on a LAN, but what about the case with a = network provider offered TURN server? The network provider hands out an = IP address and wants to announce a related TURN server address: = =E2=80=93 Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a = device on a LAN (behind a NAT/firewall)? The device must find such = configuration file based on its public IP address (that he can find = using STUN as in the suggestion below). =20 But generally, finding a TURN-server is a network-thing, ICE (or even = TURN not using ICE), not a Web-thing, so for that reason the DNS-Based = Service Discovery method is at a better level. Such method could also be = used by SIP clients (even a Skype client could implement it to benefit = from a real-time path with better quality, if the network provider = offers such path through his TURN server). =20 The DNS-Based Service Discovery method should be easy to implement in a = WebRTC browser (doing complex ICE things anyway). The question is rather = how easy it is for the network provider to provision. Do they all do = reverse DNS like with found with mobile operators TeliaSonera and Tele2 = in Sweden? Then it should not be too difficult. =20 Or is there yet another better method to announce a TURN server address = with the IP address offered? =20 /Karl =20 =20 Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] = F=C3=B6r Bernard Aboba Skickat: den 29 september 2013 02:41 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C3=84mne: Re: [rtcweb] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On Sep 26, 2013 8:46 PM, "Harald Alvestrand" < = harald@alvestrand.no> wrote: "So far, neither the POSIX standard nor any OS vendor has offered a = generic facility to access information made available in DHCP packets." =20 [BA] The Windows DHCP client API does provide this:=20 = = http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.8= 5).aspx =20 In particular, the SendParams argument to the DhcpRequestParams function = can be used to request a particular parameter (e.g. TURN server = address), which will then be returned in the RecdParams variable. =20 =20 Nevertheless, I still think that using DHCP to configure the TURN server = address in a browser isn't a good idea. For one thing, since DHCP is = effectively unsecured, this mechanism could be used by a rogue DHCP = server to force traffic to a rogue turnserver. Great for surveillance! =20 =20 On Sep 27, 2013 1:27 AM, "Karl Stahl" < = karl.stahl@intertex.se> wrote: Here comes the suggestion I got from my developer that would allow a = network provider to offer his TURN server for the WebRTC browser to use. This = would require NO new DHCP-options or similar, and NO OS changes (I do realize those should be avoided if possible...). The idea is still, that whoever is responsible for giving a device an IP address (the network provider or a LAN administrator) can also announce = a TURN server for the WebRTC browser to use. The suggestion is to use RFC6763 (DNS-Based Service Discovery, see = chapter 11) where the network provider (the owner of the IP address) has set up = a DNS PTR record for the TURN server in the in-addr.arpa domain. If the device got IP 173.164.252.149, then make a query for the PTR = record for: _turn._udp.149.252.164.173.in-addr.arpa. Then the SRV record would return the actual address to the TURN server = (and you may find several for load balancing and failover I guess) If the device is on a LAN, the IP 173.164.252.149 to query would be the = WAN IP you get via STUN in the ICE process. But if the LAN administrator provides a local TURN server, then he also should have blocked STUN in = the firewall, and the browser should query the device's local host address = (as in the ICE procedure) and the local LAN DNS server should answer the = query to give the local TURN server address on the LAN. Shouldn't this work to allow network provider to offer his TURN server "automatically and generally"? And wouldn't this work nicely for mobile devices, whenever the device is = on a "WebRTC-ready access" (actually good for everything using ICE), = whether fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network provider hopefully offers a prioritized pipe there as one usage of this mechanism). Not to slow down every call setup by doing this in the ICE process, I = guess this could be done when starting the browser and when the device gets a = new IP address, to have the TURN server address ready for later use. /Karl =20 =20 ------=_NextPart_000_02BB_01CECF44.EE518A10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Se= e my comments below. The problem of having to know a first STUN server = in order to use DNS discovery, makes the suggestions below less = good.

 

An= other idea came up; to use anycast to allow a WebRTC browser to find a = network provided TURN server (both local on a LAN or provided by a = carrier). (There are some discussion around using anycast in the STUN = and TURN RFCs.) This anycast-way should work both for a TURN server on a = LAN and a TURN server outside the NAT/Firewall (any router in the chain = can take care of an anycast address) and by the simple method below, = return the available TURN server closest to the client. Finding a TURN = server close to the client (the WebRTC browser) will also minimize = =E2=80=9Cthe turn=E2=80=9D the real-time traffic has to take.=C2=A0 =

 

Th= e suggestion is to define an anycast IP address for STUN servers = and:

- = The network provider, offering a TURN server on his access, adds a route = in his access router (or NAT/Firewall) so that the anycast address = routes to his TURN/STUN server (a TURN server is an extension of STUN = server, thus included in the same box).

- = The TURN/STUN server is configured to respond to a binding request with = a =E2=80=9C300 Try alternate server=E2=80=9D, that points out the same = TURN/STUN server (by its real IP address, not the anycast = address).

 

Th= e WebRTC browser client would then:

- = Issue a STUN binding request to the anycast = address

- = Issue another STUN binding request to the ALTERNATE SERVER IP address in = the =E2=80=9C300 Try alternate=E2=80=9D response (as any client should = do).

- = Interpret the received =E2=80=9C300 Try alternate=E2=80=9D response now = having the same ALTERNATE SERVER IP address as the source IP address of = that response, as an indication to use its TURN server (not the STUN = server) at that address.

 

Th= at is the TURN server to use!

 

Th= e only addition to existing standards is the interpretation above of the = =E2=80=9C300 Try alternate=E2=80=9D response in the STUN RCF 5766 having = the same ALTERNATE SERVER IP address as the source IP address of the = response. It means: Use the TURN server at the specified address. That = should be easy to clarify.

(T= he STUN server at the anycast address, may or may not be the same = TURN/STUN server used in second binding request.) =

 

Au= thentication could simply be that the TURN/STUN server only is reachable = from the IP addresses that the network provider want to support with the = TURN server (easy for the network provider, since he is handing out = those IP addresses).

 

Th= is should be easy to provision for a carrier or a LAN administrator and = trivial to try for the WebRTC browser.

 

An= advantage is that the two STUN binding requests directly returns the = TURN server address, whereby the following ICE process should be quick = and easy. This could also be done only once when the browser is started = or get a new IP address and cashed for later = calls.

 

/K= arl

 

PS= If you wonder why not define an anycast address for a TURN server = instead, read this thread from 2008:=C2= =A0 http://www.ietf.org/mail-archive/web/behave/current/msg03582= .html. There, the use of anycast to a TURN server is = discussed, but found not to work. (Here anycast is only used for the = first request to the STUN server, where after the real address to the = TURN/STUN server is used.)

 

 

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com] =
Skickat: den 8 oktober 2013 08:17
Till: Karl = Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings = (fluffy); draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org<= /span>; = rtcweb@ietf.org
=C3=84= mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

 

 

On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl <karl.stahl@intertex.se> = wrote:

So= the WPAD-way of getting a network provider=E2=80=99s TURN server = address for the real (white, global) IP address he has handed out to a = user, the browser would:

- = Use STUN to find the global IP address (done anyway in ICE)

 

How does this get bootstrapped? = That is, how is the STUN server found?

[K= arl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery.

 

- = Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that = is not yet deployed)

- = Make a URL based on the hostname from the reverse DNS lookup, e.g. from = 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com

 

I was hoping we could do something = simpler, such as using the ISP's configured domain search list, to = determine the domain.

 [Karl] But carriers don=E2=80=99t push out such = things, do they? And if they could do it via DHCP we are back with those = problems again.

- = And there find a list (in JS) of TURN server addresses for the network = provider=E2=80=99s IP addresses

&n= bsp;Or would an alternative be to add your own IP address to the URL and = get only your specific TURN server address?

&n= bsp;

Do= ing it at this Web level, I think we also should consider clients using = ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP = client be able to parse a =E2=80=9CJS table=E2=80=9D to find his TURN = server address easily? Also, are there long time-outs to be considered = when there is no h ttp://turned.myvzw.com to be found?

&n= bsp;

Th= is method may be easier for a network provider to deploy (I = don=E2=80=99t know, but for local use on a LAN I guess it is). On the = other hand, the DNS-Based Service Discovery method is quick and easy for = a WebRTC browser, so that may be tried as well.

&n= bsp;

In= dependent of how we find the network provided TURN server, one advantage = with it is the authentication: The network provider simply sets up the = TURN for usage from the IP addresses he has handed out.

&n= bsp;

/K= arl

&n= bsp;

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com] =
Skickat: den 3 oktober 2013 20:59
Till: Karl = Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings = (fluffy); draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org<= /span>; = rtcweb@ietf.org
=C3=84= mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

WPAD already supports DNS-based discovery (in addition to = DHCP). If you have host-95-199-1= 96-65.mobileonline.telia.com as your = endpoint hostname, it will try to get a PAC file from wpad.mobileonline.telia.com.

 

Since for all practical purposes, TURN is a "UDP = proxy", I think it should be handled similar to other proxy = autoconfig mechanisms.

 

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

I happily = withdraw my suggestion to use DHCP to find a network provider offered = TURN server in favor of the DNS-Based Service Discovery method (inserted = last below). The major problem with the DHCP usage was that you then = also have to do something similar for: RA - Router Advertisement - in = IPv6, addition to the IPCP protocol for PPPoE and something for the = mobile OTT channel =E2=80=93 wherever DHCP is NOT the method to give you = an IP address.

 

Further:

> On Thu, = Sep 27, 2013 Justin Uberti wrote:

> Agree. I = still think that extending PAC files to include TURN information is the = right way to go.

> PAC files = can already be discovered via DHCP or DNS, there is no need to reinvent = this wheel.

 

>>On = Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

>>I = think we need to give some advise to the browsers vendors on what they = should implement to find turn servers

 

I Googled a = bit on PAC and WPAD and saw that a HTTP proxy config JS file can be = picked up through a URL based on the device name. Similar could work for = finding a TURN server on a LAN, but what about the case with a network = provider offered TURN server? The network provider hands out an IP = address and wants to announce a related TURN server address: =E2=80=93 = Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a device on a LAN = (behind a NAT/firewall)? The device must find such configuration file = based on its public IP address (that he can find using STUN as in the = suggestion below).

 

But generally, = finding a TURN-server is a network-thing, ICE (or even TURN not using = ICE), not a Web-thing, so for that reason the DNS-Based Service = Discovery method is at a better level. Such method could also be used by = SIP clients (even a Skype client could implement it to benefit from a = real-time path with better quality, if the network provider offers such = path through his TURN server).

 

The DNS-Based = Service Discovery method should be easy to implement in a WebRTC browser = (doing complex ICE things anyway). The question is rather how easy it is = for the network provider to provision. Do they all do reverse DNS like = with found with mobile operators TeliaSonera and Tele2 in Sweden? Then = it should not be too difficult.

 

Or is there = yet another better method to announce a TURN server address with the IP = address offered?

 

/Karl

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&n= bsp;

&n= bsp;

Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Bernard = Aboba
Skickat: den 29 september 2013 02:41
Till: = Harald Alvestrand
Kopia: rtcweb@ietf.org


=C3=84mne: Re: [rtcweb] TURN = server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On Sep 26, = 2013 8:46 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:


"So far, neither the POSIX standard nor any OS = vendor has offered a generic facility to access information made = available in DHCP = packets."

 

[BA] The = Windows DHCP client API does provide this: 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa36= 3351(v=3Dvs.85).aspx

 

In particular, = the SendParams argument to the DhcpRequestParams function can be = used to request a particular parameter (e.g. TURN server address), which = will then be returned in the RecdParams variable.  

 

Nevertheless, = I still think that using DHCP to configure the TURN server address in a = browser isn't a good idea.  For one thing, since DHCP is = effectively unsecured, this mechanism could be used by a rogue DHCP = server to force traffic to a rogue turnserver.   Great for = surveillance!

&n= bsp;

&n= bsp;

On Sep 27, 2013 1:27 AM, "Karl Stahl" = <karl.stahl@intertex.se> = wrote:

Here comes the suggestion I got from my developer that = would allow a network
provider to offer his TURN server for the = WebRTC browser to use. This would
require NO new DHCP-options or = similar, and NO OS changes (I do realize
those should be avoided if = possible...).

The idea is still, that whoever is responsible for = giving a device an IP
address (the network provider or a LAN = administrator) can also announce a
TURN server for the WebRTC browser = to use.

The suggestion is to use RFC6763 (DNS-Based Service = Discovery, see chapter
11) where the network provider (the owner of = the IP address) has set up a
DNS PTR record for the TURN server in = the in-addr.arpa domain.

If the device got IP 173.164.252.149, = then make a query for the PTR = record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the = SRV record would return the actual address to the TURN server = (and
you may find several for load balancing and failover I = guess)

If the device is on a LAN, the IP 173.164.252.149 to query = would be the WAN
IP you get via STUN in the ICE process. But if the = LAN administrator
provides a local TURN server, then he also should = have blocked STUN in the
firewall, and the browser should query the = device's local host address (as
in the ICE procedure) and the local = LAN DNS server should answer the query
to give the local TURN server = address on the LAN.

Shouldn't this work to allow network provider = to offer his TURN server
"automatically and = generally"?

And wouldn't this work nicely for mobile = devices, whenever the device is on
a "WebRTC-ready access" = (actually good for everything using ICE), whether
fixed, WiFi or = 3G/4G OTT, you get also a TURN server (and the network
provider = hopefully offers a prioritized pipe there as one usage of = this
mechanism).

Not to slow down every call setup by doing this in the ICE = process, I guess
this could be done when starting the browser and = when the device gets a new
IP address, to have the TURN server = address ready for later use.

/Karl

 <= /o:p>

 

------=_NextPart_000_02BB_01CECF44.EE518A10-- From karl.stahl@intertex.se Tue Oct 22 07:38:22 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876DE11E84B6 for ; Tue, 22 Oct 2013 07:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_20=-0.74, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuF3cUALfr8Y for ; Tue, 22 Oct 2013 07:38:00 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7570111E83C8 for ; Tue, 22 Oct 2013 07:37:18 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310221637151652; Tue, 22 Oct 2013 16:37:15 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" , , "'Magnus Westerlund'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> In-Reply-To: <5253E5EB.8030608@alvestrand.no> Date: Tue, 22 Oct 2013 16:37:18 +0200 Message-ID: <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C0_01CECF44.F96A44A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7EFbkmQFwvQDChQl+1C3afCRd/RgE7zuMw Content-Language: sv Cc: 'Colin Perkins' Subject: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:38:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02C0_01CECF44.F96A44A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But rather than = asking the application, let's convey the bandwidth and priority requirements to = the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be available = for incoming traffic, which is especially important in RSVP type of = networks, that has to reserve bandwidth for it. =20 =20 There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren=92t sufficient anyway).=20 =20 Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to = encode it though. =20 Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there can be = many header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions". =20 So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. =20 Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. =20 I suggest that two parameters (e.g. two bytes each) are encoded into the = RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Please note the totally different requirements a diffserv and an RSVP network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation networks = (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) =20 /Karl =20 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. =20 This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =20 MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the attribute is = not present in the Allocate request message, the TURN server SHOULD assume = that the data stream is audio with best effort delivery. The format of this attribute is as follows...=20 ... The following stream types are supported in this extension. All other = stream types are reserved for future use. =A7 "0x0001": Audio =A7 "0x0002": Video =A7 "0x0003": Supplemental Video =A7 "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. =A7 "0x0000": Best effort delivery. =A7 "0x0001": Reliable delivery. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, >=20 >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. >=20 > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of = > less importance as long as there is sufficient bandwidth for both). =20 You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. =20 >=20 > With diffserv you don=92t need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. =20 Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. =20 >=20 > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the bandwidth used... >=20 > I think the payload type field at best can reflect a maximum bandwidth = > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a = joke? =20 I think these ruminations only lead to one conclusion: =20 You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. =20 If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_02C0_01CECF44.F96A44A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it. =A0

 

There is actually a good way to show these needs to the = network (without using the PT, or diffserv bits, which aren’t = sufficient anyway).

 

Let's use the RTP header extension field that also is = visible outside the encrypted payload. A week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 = =A0that outlines the usage of the extension field for classification of = traffic! This document does not yet outline what to put in there and how = to encode it though.

 

Today's http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC = Use of RTP: Future Extensions".

 

So, it looks obvious to use the = RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in every = RTP packet so it can be set individually for each stream and could even = be changed during a session (e.g. when limiting the bandwidth based on = RTCP feedback). RFC 5286 also specifies how RTP extension header usage = can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly = specified now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence… on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to 0, = there could instead be a number for special usage that does not fit the = general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let’s put all into these bytes. (E.g. a diffserv network don't = need the bandwidth usage, but RSVP reservation networks (e.g. cable and = 3G/4G OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems = to have done work in this field, defining a proprietary attribute = “MS Service Quality”;

However that = seems to apply to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not = handle the bandwidth requirement for incoming real-time traffic = (required to reserve in RSVP type of networks)

However the = quality attributes conveyed and their encoding may =A0be = considered.

 

This is 2.2.2.19 MS-Service Quality Attribute from =

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).asp= x 

 

MS-Service = Quality Attribute

The MS-Service = Quality attribute is used to convey information about the data stream = that the protocol client is intending to transfer over an allocated = port. The protocol client SHOULD<21> include this attribute as = part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...<= span lang=3DEN-US style=3D'color:black'>

The following = stream types are supported in this extension. All other stream types are = reserved for future use.

=A7 = "0x0001&quo= t;: Audio

=A7 = "0x0002&quo= t;: Video

=A7 = "0x0003&quo= t;: Supplemental Video

=A7 = "0x0004&quo= t;: Data

Service Quality = (2 bytes): The service quality level required by the protocol client for = the stream.

The following = service quality levels are supported in this extension. All other = service quality levels are reserved for future use.

=A7 = "0x0000&quo= t;: Best effort delivery.

=A7 = "0x0001&quo= t;: Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really = interested in knowing that it is VP9 vs H.264,

>> = isn't

> the questions this is video of this priority that is = important?

>> I think you need to more carefully consider what = are the goals you

>> try to

> achieve = them.

> 

> Actually, my concern is to = get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized = over data (their individual priority is of

> less importance as long as = there is sufficient bandwidth for both).

 

You don't know that without = knowing what the application is for.

In, for instance, a shooter game = with voice backchannels, the movement and event information (data) is = MORE time sensitive than the voice data.

 

> 

> With diffserv you = don’t need to know the bandwidth requirement, but =

> = with RSVP reservation (like in cable and mobile networks) you need to =

> = know how much to reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide to = use QCIF or HD, and the bandwidth variation of screencast (semi-static = with sudden, large changes) is completely different from that of a = talking head, which is again completely different from a high-movement = scene.

 

> 

> To add to the complication = of codec variants, the video codecs in

> question for WebRTC have = variable bandwidth, and when there is a poor

> connection we see Chrome = reducing the video window size to reduce the bandwidth = used...

> 

> I think the payload type = field at best can reflect a maximum bandwidth

> to initially reserve = bandwidth for, and thereafter make new

> reservations if the = bandwidth changes during the call. So could we

> change RTP to show maximum = bandwidth instead of payload type in that

> field outside the encrypted = payload :) ... Or maybe that is not a joke?

 

I think these ruminations only = lead to one conclusion:

 

You can't tell what the needed = bandwidth is up front without asking the = application.

You can't tell what the right priority ranking is without = asking the application.

 

If you need to know the = bandwidth or the priority up front, the application has to tell you. = Anything else is pure heuristics.

 

_______________________________________________

rtcweb mailing = list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb

------=_NextPart_000_02C0_01CECF44.F96A44A0-- From harald@alvestrand.no Tue Oct 22 07:49:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6698A11E81AF for ; Tue, 22 Oct 2013 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.232 X-Spam-Level: X-Spam-Status: No, score=-110.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndV1Kdi5cp9S for ; Tue, 22 Oct 2013 07:48:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D116311E81B3 for ; Tue, 22 Oct 2013 07:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6399239E062; Tue, 22 Oct 2013 16:48:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OD6TXYViX6b; Tue, 22 Oct 2013 16:48:51 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BE20939E1B7; Tue, 22 Oct 2013 16:48:51 +0200 (CEST) Message-ID: <52669059.4080700@alvestrand.no> Date: Tue, 22 Oct 2013 16:48:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Bo Burman , "rtcweb@ietf.org" References: <52664A39.5040105@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:49:01 -0000 On 10/22/2013 04:20 PM, Bo Burman wrote: > Hi all, > > We understand that there are many people that are interested in a VP8 vs x264 comparison that includes rate controls. > > We therefore performed a quick study of the VP8 and x264 rate controls to see whether there were any major differences between them in the way they select quantizers. We found that VP8 uses what can be described as QP-toggling: By lowering the QP of, say, every 6th frame, you increase the quality of these markedly. The following frames also benefit from the increased quality (even though they have to make do with less bits than before) since they can predict from the high-quality frame. > > However, we found that the rate-control of x264 does not QP-toggle in this fine granular way, and x264 may therefore be at a disadvantage when comparing against VP8. So we ran a test using a modified version of x264 to allow QP-toggling during rate control. The modification is very simple and a patch for the x264 code is found in the bottom of this email. > > With this change, H.264 baseline (implemented using the modified x264 with rate control turned on) performs equally to VP8 with rate-control on; the difference is 1.3% in favor of VP8, but if you swap the order of the two codecs in draw_graphs.sh, H.264 baseline wins with 1.6%. This result is thus a tie between VP8 and H.264 baseline, and this is consistent with our previous fixed-QP test, and far from the (at least) 13% advantage for VP8 stated by Google. > > The modification is simple and it may well be possible to improve x264 by more sophisticated modifications. But pursuing this track is what we oppose, we do not want comparisons where the outcome depends on how well you modify a particular rate control mechanism - the rate control is codec-agnostic after all. To avoid this we still maintain our view that codec comparisons should be done using fixed QP settings, which is also the practice in MPEG and VCEG. > > We used the test parameters from Google's test repository https://git.chromium.org/git/webm/vpx_codec_comparison.git, the version ada7d7937a54e47fc18e2e0a1287aea29dc5d1c5. Thanks! Can you verify that you did see the same 12.7% difference when you ran the unmodified ada7d checkout? I want to be sure that I haven't missed any external influences on the results. Having a 2.9% difference by swapping the order of arguments seems wrong; I'll pass this on to the guy who wrote that particular script. > > Here are the x264 and comparison script patches: > -- > > diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c > index 1a39a49..2cf256f 100644 > --- a/encoder/ratecontrol.c > +++ b/encoder/ratecontrol.c > @@ -1707,7 +1707,18 @@ int x264_ratecontrol_mb_qp( x264_t *h ) > { > x264_emms(); > float qp = h->rc->qpm; > - if( h->param.rc.i_aq_mode ) > + > + if (h->sh.i_type != SLICE_TYPE_I){ > + if ((h->fenc->i_poc % 12 )== 0) > + qp -= 3.0; > + else > + qp += 0.0; > + > + } else { > + qp -= 5.0; > + } > + > + if( h->param.rc.i_aq_mode) > { > /* MB-tree currently doesn't adjust quantizers in unreferenced frames. */ > float qp_offset = h->fdec->b_kept_as_ref ? h->fenc->f_qp_offset[h->mb.i_mb_xy] : h->fenc->f_qp_offset_aq[h->mb.i_mb_xy]; > > > draw_graphs.sh: > > change > ./visual_metrics.py metrics_template.html "*0.txt" stats/h264 stats/vp8 > vp8_vs_h264_quality.html > to > ./visual_metrics.py metrics_template.html "*0.txt" stats/vp8 stats/h264 > vp8_vs_h264_quality2.html > > Best Regards, > Bo Burman > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: den 22 oktober 2013 11:50 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons >> >> On 10/14/2013 11:12 PM, Bo Burman wrote: >>> Hi all, >>> >>> We would like to counter Google's suggestion that our test has only "demonstrated that it is possible to reduce VP8's >> performance" (updated draft on VP8 http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/). >>> In fact, what we did in our test was mostly undoing some very peculiar >>> x264 settings made by Google in their test from April 3. By instead >>> using the x264 settings Google themselves proposed in their earlier >>> test (from March 12), and removing threading, the difference went down >>> from 41% to 16%. (This is without touching the VP8 parameters.) >>> >>> The last change we made was to remove the rate control from the comparison, something that is standard practice in >> the world of video standardization. This involved changing both the x264 and VP8 parameters. After that, the difference >> went down to -1%. >>> In summary, the following steps were taken in our comparison: >>> >>> 1) Downloading the latest software: 41% became 36% >>> 2) Removing threading: 26% >>> 3) Removing bit padding: 18% >>> 4) Removing other differences between Google's March 12 and April 3rd >>> tests: 16% >>> 5) Removing rate controller: -1% >>> >>> >> Just a quick update on this - I did not manage to get a new draft ready before the deadline, so I'll have to resort to >> sending email: >> >> I applied steps 1), 2) and 3) to the repository mentioned in the draft. >> The numbers I got were different, but significant. Below are the >> VP8-to-x264 differences I encountered each step of the way. >> >> - Master branch before October 15: Difference 71.52% >> - Updating x264 from 198a7ea (aug 16 2012) to c832fe (March 1 2013): >> Difference 71.44% >> (I could not go beyond this because yasm 1.2 was required for newer versions). >> - Adding the --thread 1 parameter: Difference 26.11% >> - Removing the --nai-hrd=cbr parameter that was suggested by x264 >> people: Difference 13.87% >> - Removing vbv-maxrate and vbv-init 0.8: Difference 12.74% >> >> I did not shorten the clips to 10 seconds, nor did I try to control rate by constant cq instead of a rate controller; if Bo's >> numbers are right, this shouldn't matter. >> >> I did try removing "vbv-bufsize ${rate}", since this was the remaining difference I could find for Bo's point 4 "other >> differences", but that was actually harmful (difference increased to 19.05%), so I put it back. >> >> I checked this in to the repository - the commit is here: >> >> http://git.chromium.org/gitweb/?p=webm/vpx_codec_comparison.git;a=commitdiff;h=ada7d7937a54e47fc18e2e0a1287 >> aea29dc5d1c5 >> >> >> This number does not fit the impression the video codec team has from other tests - they think >> VP8 can do a lot more than 13% better than baseline - but at the draft deadline, we had not found the set of VP8 >> parameters that showed this for this particular clip set. >> >> Commentary: I'm surprised at x264's choice of default value for the --thread parameter. Accepting a 26% bitrate hit >> seems like a large price to pay for going faster by default. Is there a bug here? >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Tue Oct 22 08:40:30 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6411E81B5 for ; Tue, 22 Oct 2013 08:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK2F+ANhHwDP for ; Tue, 22 Oct 2013 08:40:23 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 074F811E81B3 for ; Tue, 22 Oct 2013 08:40:22 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so7977809wgg.4 for ; Tue, 22 Oct 2013 08:40:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CdpnVMu8QqY0MvsUFx5E0AnrT6ARtWWEcpGpUks6Lbg=; b=nAs+odkRRCwNWOrDvXrlNPLNSptZvog9eCjl8604BVgmANZQdbHd0Ysqwbsge9Qhlb 5EtJopqIdm6XxPCBw/ytA8zzGLz2MDERXXwMYPuBeKlQVsFB9otuw5zYxHcGfG5i1L/8 uSp5KvtnMm+N8YZ7ncXTANvAq3AegTsf3ncRRoA8EDytk7d9a47Eu/+HMv/8JDWAlnnf ipBYcYuVdagCTShMgcnSEf6iNhnT8RM1MEoBBXmKCcjABFyNXiUl98SnKGVY/n04f/aM vulBhxZpyGprtCWZit/s62f74Y/0VJvywYuvbU0hk80EoRvLJf66uQkcumuX36UQ+JtF 3eDg== X-Gm-Message-State: ALoCoQmRu6FWvyO7LsiA5GiZDG56MPMDpBjyz7+Thy5eYJzQs8cR+hsi3eTRTYm3uRbtgqqM3efk X-Received: by 10.180.210.231 with SMTP id mx7mr15327915wic.5.1382456422033; Tue, 22 Oct 2013 08:40:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Tue, 22 Oct 2013 08:39:41 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <52666E6E.5060206@alvestrand.no> References: <5265386A.2020005@alvestrand.no> <52666E6E.5060206@alvestrand.no> From: Eric Rescorla Date: Tue, 22 Oct 2013 08:39:41 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c25d32f3f0f404e9563784 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:40:30 -0000 --001a11c25d32f3f0f404e9563784 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 22, 2013 at 5:24 AM, Harald Alvestrand wrote: > On 10/21/2013 06:38 PM, Martin Thomson wrote: > >> On 21 October 2013 07:21, Harald Alvestrand wrote: >> >>> When receiving browser supports both A and B, we could argue that they >>> should be allowed to be different in the name of algorithm agility. But >>> is >>> there a real gain in security achieved by it? >>> >> Those are interesting cases, but they easily solved by saying >> something like "MUST include/implement SHA-256". >> > > Until SHA-512 comes along. > > If I don't support SHA-512, and the certificate says you have to use > SHA-512 to verify the certificate, but I have a fingerprint using SHA-256, > am I exposed to some attack I'd have been protected against if I understood > SHA-512, or not? I'm not quite sure I follow. If the certificate isn't being third-party validated, it's irrelevant what digest was used to sign the certificate. -Ekr > I don't think that the hash used by the certificate is actually >> relevant either. Fingerprints are calculated, not observed or >> extracted. >> > > Well - they are extracted from SDP, and compared, which is a form of > observation.... but you may be thinking of something else; I find that > sentence hard to parse. > > --001a11c25d32f3f0f404e9563784 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Oct 22, 2013 at 5:24 AM, Harald Alvestrand <harald@alve= strand.no> wrote:
On 10/21/2013 06:38 PM, Martin Thomson = wrote:
On 21 October 2013 07:21, Harald Alvestrand <harald@alvestrand.no> wrote:
When receiving browser supports both A and B, we could argue that they
should be allowed to be different in the name of algorithm agility. But is<= br> there a real gain in security achieved by it?
Those are interesting cases, but they easily solved by saying
something like "MUST include/implement SHA-256".

Until SHA-512 comes along.

If I don't support SHA-512, and the certificate says you have to use SH= A-512 to verify the certificate, but I have a fingerprint using SHA-256, am= I exposed to some attack I'd have been protected against if I understo= od SHA-512, or not?

I'm not quite sure I follow. If the certificate isn= 't being third-party validated,
it's irrelevant what dige= st was used to sign the certificate.

-Ekr


=A0
I don't think that the hash used by the certificate is actually
relevant either. =A0Fingerprints are calculated, not observed or
extracted.

Well - they are extracted from SDP, and compared, which is a form of observ= ation.... but you may be thinking of something else; I find that sentence h= ard to parse.

--001a11c25d32f3f0f404e9563784-- From bo.burman@ericsson.com Tue Oct 22 09:07:24 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B169811E81D4 for ; Tue, 22 Oct 2013 09:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-2.125, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvvACcniL4CS for ; Tue, 22 Oct 2013 09:07:20 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45811E81C4 for ; Tue, 22 Oct 2013 09:07:09 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-75-5266a2ab8513 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E9.F6.25272.BA2A6625; Tue, 22 Oct 2013 18:07:08 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 18:07:07 +0200 From: Bo Burman To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Comments on H.264 and VP8 performance comparisons Thread-Index: Ac7JIe76OhlqjGwCQFaenvACTkQ0VwF2Vc2AAA12J5D//+fngP//yUPg Date: Tue, 22 Oct 2013 16:07:06 +0000 Message-ID: References: <52664A39.5040105@alvestrand.no> <52669059.4080700@alvestrand.no> In-Reply-To: <52669059.4080700@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6aRWlBBq/38lgc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4tFu6YKJ9xatT+g2M1wy7GDk5JARMJDZu vcoIYYtJXLi3nq2LkYtDSOAoo0TnjclMEM4iRonuE1PZQKrYBDQk5u+4C9YhIhAs0fv8PZgt LOAu0XtrIlANB1DcQ6JtuQJEiZtE16UlYGEWAVWJlslhIGFeAV+Jjy/3sEOMv84osXjlZLDx nAK6EkuePAUbySggK3H/+z0WEJtZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8rhK0osfNsOzNE vY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxchSnFiflphsZ bGIERsLBLb8tdjBe/mtziFGag0VJnPfjW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyF Gv+f/TQuF2m16Up9KnnD5vzBok9mymqJG7mb8zlyrZxeNXKH8nT1MpRIHtZfMCvpvJTqp3d9 OebBEkWia5YUFtxzlbCY49cftfLIkS3pHj76/WfafgZ0/mn3/LLb/JqyjuSWhcIcrz+brnfi 7Ppv//3M48hnnJq3O5klUvK1ZA0s3z9zUmIpzkg01GIuKk4EAKMEketSAgAA Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 16:07:24 -0000 I can confirm we get 12.7% advantage for VP8 with the unmodified ada7d chec= kout. > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: den 22 oktober 2013 16:49 > To: Bo Burman; rtcweb@ietf.org > Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons >=20 > On 10/22/2013 04:20 PM, Bo Burman wrote: > > Hi all, > > > > We understand that there are many people that are interested in a VP8 v= s x264 comparison that includes rate controls. > > > > We therefore performed a quick study of the VP8 and x264 rate controls = to see whether there were any major > differences between them in the way they select quantizers. We found that= VP8 uses what can be described as QP- > toggling: By lowering the QP of, say, every 6th frame, you increase the q= uality of these markedly. The following frames > also benefit from the increased quality (even though they have to make do= with less bits than before) since they can > predict from the high-quality frame. > > > > However, we found that the rate-control of x264 does not QP-toggle in t= his fine granular way, and x264 may therefore > be at a disadvantage when comparing against VP8. So we ran a test using a= modified version of x264 to allow QP-toggling > during rate control. The modification is very simple and a patch for the = x264 code is found in the bottom of this email. > > > > With this change, H.264 baseline (implemented using the modified x264 w= ith rate control turned on) performs equally > to VP8 with rate-control on; the difference is 1.3% in favor of VP8, but = if you swap the order of the two codecs in > draw_graphs.sh, H.264 baseline wins with 1.6%. This result is thus a tie = between VP8 and H.264 baseline, and this is > consistent with our previous fixed-QP test, and far from the (at least) 1= 3% advantage for VP8 stated by Google. > > > > The modification is simple and it may well be possible to improve x264 = by more sophisticated modifications. But > pursuing this track is what we oppose, we do not want comparisons where t= he outcome depends on how well you > modify a particular rate control mechanism - the rate control is codec-a= gnostic after all. To avoid this we still maintain our > view that codec comparisons should be done using fixed QP settings, which= is also the practice in MPEG and VCEG. > > > > We used the test parameters from Google's test repository > https://git.chromium.org/git/webm/vpx_codec_comparison.git, the version > ada7d7937a54e47fc18e2e0a1287aea29dc5d1c5. >=20 > Thanks! >=20 > Can you verify that you did see the same 12.7% difference when you ran th= e unmodified ada7d checkout? I want to be > sure that I haven't missed any external influences on the results. >=20 > Having a 2.9% difference by swapping the order of arguments seems wrong; = I'll pass this on to the guy who wrote that > particular script. >=20 > > > > Here are the x264 and comparison script patches: > > -- > > > > diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c index > > 1a39a49..2cf256f 100644 > > --- a/encoder/ratecontrol.c > > +++ b/encoder/ratecontrol.c > > @@ -1707,7 +1707,18 @@ int x264_ratecontrol_mb_qp( x264_t *h ) { > > x264_emms(); > > float qp =3D h->rc->qpm; > > - if( h->param.rc.i_aq_mode ) > > + > > + if (h->sh.i_type !=3D SLICE_TYPE_I){ > > + if ((h->fenc->i_poc % 12 )=3D=3D 0) > > + qp -=3D 3.0; > > + else > > + qp +=3D 0.0; > > + > > + } else { > > + qp -=3D 5.0; > > + } > > + > > + if( h->param.rc.i_aq_mode) > > { > > /* MB-tree currently doesn't adjust quantizers in unreferenc= ed frames. */ > > float qp_offset =3D h->fdec->b_kept_as_ref ? > > h->fenc->f_qp_offset[h->mb.i_mb_xy] : > > h->fenc->f_qp_offset_aq[h->mb.i_mb_xy]; > > > > > > draw_graphs.sh: > > > > change > > ./visual_metrics.py metrics_template.html "*0.txt" stats/h264 > > stats/vp8 > vp8_vs_h264_quality.html to ./visual_metrics.py > > metrics_template.html "*0.txt" stats/vp8 stats/h264 > > > vp8_vs_h264_quality2.html > > > > Best Regards, > > Bo Burman > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Harald Alvestrand > >> Sent: den 22 oktober 2013 11:50 > >> To: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Comments on H.264 and VP8 performance > >> comparisons > >> > >> On 10/14/2013 11:12 PM, Bo Burman wrote: > >>> Hi all, > >>> > >>> We would like to counter Google's suggestion that our test has only > >>> "demonstrated that it is possible to reduce VP8's > >> performance" (updated draft on VP8 http://datatracker.ietf.org/doc/dra= ft-alvestrand-rtcweb-vp8/). > >>> In fact, what we did in our test was mostly undoing some very > >>> peculiar > >>> x264 settings made by Google in their test from April 3. By instead > >>> using the x264 settings Google themselves proposed in their earlier > >>> test (from March 12), and removing threading, the difference went > >>> down from 41% to 16%. (This is without touching the VP8 parameters.) > >>> > >>> The last change we made was to remove the rate control from the > >>> comparison, something that is standard practice in > >> the world of video standardization. This involved changing both the > >> x264 and VP8 parameters. After that, the difference went down to -1%. > >>> In summary, the following steps were taken in our comparison: > >>> > >>> 1) Downloading the latest software: 41% became 36% > >>> 2) Removing threading: 26% > >>> 3) Removing bit padding: 18% > >>> 4) Removing other differences between Google's March 12 and April > >>> 3rd > >>> tests: 16% > >>> 5) Removing rate controller: -1% > >>> > >>> > >> Just a quick update on this - I did not manage to get a new draft > >> ready before the deadline, so I'll have to resort to sending email: > >> > >> I applied steps 1), 2) and 3) to the repository mentioned in the draft= . > >> The numbers I got were different, but significant. Below are the > >> VP8-to-x264 differences I encountered each step of the way. > >> > >> - Master branch before October 15: Difference 71.52% > >> - Updating x264 from 198a7ea (aug 16 2012) to c832fe (March 1 2013): > >> Difference 71.44% > >> (I could not go beyond this because yasm 1.2 was required for newe= r versions). > >> - Adding the --thread 1 parameter: Difference 26.11% > >> - Removing the --nai-hrd=3Dcbr parameter that was suggested by x264 > >> people: Difference 13.87% > >> - Removing vbv-maxrate and vbv-init 0.8: Difference 12.74% > >> > >> I did not shorten the clips to 10 seconds, nor did I try to control > >> rate by constant cq instead of a rate controller; if Bo's numbers are = right, this shouldn't matter. > >> > >> I did try removing "vbv-bufsize ${rate}", since this was the > >> remaining difference I could find for Bo's point 4 "other differences"= , but that was actually harmful (difference > increased to 19.05%), so I put it back. > >> > >> I checked this in to the repository - the commit is here: > >> > >> http://git.chromium.org/gitweb/?p=3Dwebm/vpx_codec_comparison.git;a=3D= com > >> mitdiff;h=3Dada7d7937a54e47fc18e2e0a1287 > >> aea29dc5d1c5 > >> > >> > >> This number does not fit the impression the video codec team has from > >> other tests - they think > >> VP8 can do a lot more than 13% better than baseline - but at the > >> draft deadline, we had not found the set of VP8 parameters that showed= this for this particular clip set. > >> > >> Commentary: I'm surprised at x264's choice of default value for the > >> --thread parameter. Accepting a 26% bitrate hit seems like a large pri= ce to pay for going faster by default. Is there a > bug here? > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Tue Oct 22 09:14:11 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0E611E840C for ; Tue, 22 Oct 2013 09:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSmVQgxULRft for ; Tue, 22 Oct 2013 09:14:11 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B11FC11E8414 for ; Tue, 22 Oct 2013 09:14:10 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l12so7047107wiv.1 for ; Tue, 22 Oct 2013 09:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kd1KdB4jKisMdLdf36V04W7ZRqsD1X5bZxbaPKtMpVo=; b=mls+3hAmqvb0ZV9PJwpG7hjTHK0IR00zH60BxKRTQOwj3T8y8Nu9GX+JVhGPXrjs6O mXRtL+E/LNobeHHpbU1o36THiXFE81TtFCC+ZhzPCvjk8sztjQbgWfD5Wju0ftE56sRc Rpyc+myRBN0C0vVBEwKokh+5XgYykX02VcDMWHf4XZHf1toKGi3Rfkg5/AX5knrEpmQH nm/mPNfiizdyxAzA6I9sKl2YkBIE7ubrGFkWnId6WSHLmNJfYFZAlCoSQnep7hqkXb0B ZiBLprNqO7JPffbBKyAogvfzM+OWw4HAHTRIsWJhfA3PMgi12xctbd1P5PsMDu7FBx7T Fjxw== MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr15378767wia.22.1382458449680; Tue, 22 Oct 2013 09:14:09 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Tue, 22 Oct 2013 09:14:09 -0700 (PDT) In-Reply-To: References: <5265386A.2020005@alvestrand.no> <52666E6E.5060206@alvestrand.no> Date: Tue, 22 Oct 2013 09:14:09 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP fingerprint hash requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 16:14:11 -0000 On 22 October 2013 08:39, Eric Rescorla wrote: > On Tue, Oct 22, 2013 at 5:24 AM, Harald Alvestrand > wrote: >> If I don't support SHA-512, and the certificate says you have to use >> SHA-512 to verify the certificate, but I have a fingerprint using SHA-256, >> am I exposed to some attack I'd have been protected against if I understood >> SHA-512, or not? > > I'm not quite sure I follow. If the certificate isn't being third-party > validated, > it's irrelevant what digest was used to sign the certificate. What EKR said. It's all in the draft. For 4572, aside from secondary uses, the certificate is primarily used as a container for a public key. The hash forms a binding between the public key (by hashing its container) and the actual session description. Then, all you need is some form of trust in the integrity of the session description. Of course, once we go to webrtc, the integrity of the session description is immediately suspect. RFC 4572 provides close to zero utility for webrtc. Identity providers use a separate binding of the same form to bind an identity assertion to the public key that is independent of the integrity of the signaling channel. From bo.burman@ericsson.com Tue Oct 22 09:26:45 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7BD11E83F3 for ; Tue, 22 Oct 2013 09:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.593 X-Spam-Level: X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[AWL=-1.594, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAJ1pJa3wRN4 for ; Tue, 22 Oct 2013 09:26:40 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3C56611E81D7 for ; Tue, 22 Oct 2013 09:26:39 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-38-5266a73ebb3b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 63.A8.25272.E37A6625; Tue, 22 Oct 2013 18:26:38 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 18:26:37 +0200 From: Bo Burman To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Comments on H.264 and VP8 performance comparisons Thread-Index: Ac7JIe76OhlqjGwCQFaenvACTkQ0VwF2Vc2AAA12J5D//+fngP//xXVg Date: Tue, 22 Oct 2013 16:26:37 +0000 Message-ID: References: <52664A39.5040105@alvestrand.no> <52669059.4080700@alvestrand.no> In-Reply-To: <52669059.4080700@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvja7d8rQgg7MTpC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGW8+97MVjDLo+LA0U1sDYy3LLoYOTkkBEwk Nm/fzQ5hi0lcuLeeDcQWEjjKKLHvsVIXIxeQvYhRYu7R6WAJNgENifk77jKC2CICwRK9z9+D 2cIC7hK9tyYC1XAAxT0k2pYrQJhuEvMbIkEqWARUJSZ+PM0KYvMK+EpM2/qdDWL8dUaJxSsn g43nFNCVWPLkKdhIRgFZifvf77GA2MwC4hK3nsxngrhTQGLJnvPMELaoxMvH/1ghbEWJnWfb mSHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRozi1OCk3 3chgEyMwFg5u+W2xg/HyX5tDjNIcLErivB/fOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YHwSEjWr4mF0U3hLDMf/4IvTLF+e4i6udgr1jptabHnie0TzWxO/V3wTZlc9fHuxTkIh6Jz4 lQth51/k/7mlLxoVYqF79OycqOfKFz4Zv42snjTpCyNrbPO96TnBurc6Jup36p67u0lbkruA yf6Ic/SDGLOVx24tTYs+nzDLo0OyasH+P9Fvu5RYijMSDbWYi4oTAbSUvdFTAgAA Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 16:26:45 -0000 Hi all,=20 On 10/22/2013 04:28 PM, Harald Alvestrand wrote: > Having a 2.9% difference by swapping the order of arguments seems wrong; = I'll pass this on to the guy who wrote that particular script. Actually, this is not so weird at all. With the way of measuring that is do= ne in your script, it makes a huge difference which sequence is the "anchor= " (the first argument) and which is the "test subject" (the second argument= ). The reason is that a 10% bit rate increase is not equivalent to a 10% de= crease when you turn the arguments around. An illustrative example: Assume there are only two sequences, one that VP8 is really good at, so H26= 4 need twice the bit rate to reach the same quality, and one that H.264 is = really good at, so that it only need half the bits to reach the same qualit= y. Then, using the VP8 codec as the anchor you get: Sequence 1: H.264 needs twice the number of bits (+100%)=20 Sequence 2: H.264 needs half the number of bits (-50%)=20 You average these two and you get (100%-50%)/2 =3D 25% more bits on average= for H.264 If you, on the other hand, use H.264 as the anchor (first argument), you ge= t Sequence 1: VP8 needs half the number of bits (-50%)=20 Sequence 2: VP8 needs twice the number of bits (+100%)=20 You average these two and you get (-50% + 100%)/2 =3D 25% more bits on aver= age for VP8 Hence the script is biased towards the first argument in the script. Best Regards Bo Burman > On 10/22/2013 04:20 PM, Bo Burman wrote: > > Hi all, > > > > We understand that there are many people that are interested in a VP8 v= s x264 comparison that includes rate controls. > > > > We therefore performed a quick study of the VP8 and x264 rate controls = to see whether there were any major > differences between them in the way they select quantizers. We found that= VP8 uses what can be described as QP- > toggling: By lowering the QP of, say, every 6th frame, you increase the q= uality of these markedly. The following frames > also benefit from the increased quality (even though they have to make do= with less bits than before) since they can > predict from the high-quality frame. > > > > However, we found that the rate-control of x264 does not QP-toggle in t= his fine granular way, and x264 may therefore > be at a disadvantage when comparing against VP8. So we ran a test using a= modified version of x264 to allow QP-toggling > during rate control. The modification is very simple and a patch for the = x264 code is found in the bottom of this email. > > > > With this change, H.264 baseline (implemented using the modified x264 w= ith rate control turned on) performs equally > to VP8 with rate-control on; the difference is 1.3% in favor of VP8, but = if you swap the order of the two codecs in > draw_graphs.sh, H.264 baseline wins with 1.6%. This result is thus a tie = between VP8 and H.264 baseline, and this is > consistent with our previous fixed-QP test, and far from the (at least) 1= 3% advantage for VP8 stated by Google. > > > > The modification is simple and it may well be possible to improve x264 = by more sophisticated modifications. But > pursuing this track is what we oppose, we do not want comparisons where t= he outcome depends on how well you > modify a particular rate control mechanism - the rate control is codec-a= gnostic after all. To avoid this we still maintain our > view that codec comparisons should be done using fixed QP settings, which= is also the practice in MPEG and VCEG. > > > > We used the test parameters from Google's test repository > https://git.chromium.org/git/webm/vpx_codec_comparison.git, the version > ada7d7937a54e47fc18e2e0a1287aea29dc5d1c5. >=20 > Thanks! >=20 > Can you verify that you did see the same 12.7% difference when you ran th= e unmodified ada7d checkout? I want to be > sure that I haven't missed any external influences on the results. >=20 > Having a 2.9% difference by swapping the order of arguments seems wrong; = I'll pass this on to the guy who wrote that > particular script. >=20 > > > > Here are the x264 and comparison script patches: > > -- > > > > diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c index > > 1a39a49..2cf256f 100644 > > --- a/encoder/ratecontrol.c > > +++ b/encoder/ratecontrol.c > > @@ -1707,7 +1707,18 @@ int x264_ratecontrol_mb_qp( x264_t *h ) { > > x264_emms(); > > float qp =3D h->rc->qpm; > > - if( h->param.rc.i_aq_mode ) > > + > > + if (h->sh.i_type !=3D SLICE_TYPE_I){ > > + if ((h->fenc->i_poc % 12 )=3D=3D 0) > > + qp -=3D 3.0; > > + else > > + qp +=3D 0.0; > > + > > + } else { > > + qp -=3D 5.0; > > + } > > + > > + if( h->param.rc.i_aq_mode) > > { > > /* MB-tree currently doesn't adjust quantizers in unreferenc= ed frames. */ > > float qp_offset =3D h->fdec->b_kept_as_ref ? > > h->fenc->f_qp_offset[h->mb.i_mb_xy] : > > h->fenc->f_qp_offset_aq[h->mb.i_mb_xy]; > > > > > > draw_graphs.sh: > > > > change > > ./visual_metrics.py metrics_template.html "*0.txt" stats/h264 > > stats/vp8 > vp8_vs_h264_quality.html to ./visual_metrics.py > > metrics_template.html "*0.txt" stats/vp8 stats/h264 > > > vp8_vs_h264_quality2.html > > > > Best Regards, > > Bo Burman > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Harald Alvestrand > >> Sent: den 22 oktober 2013 11:50 > >> To: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Comments on H.264 and VP8 performance > >> comparisons > >> > >> On 10/14/2013 11:12 PM, Bo Burman wrote: > >>> Hi all, > >>> > >>> We would like to counter Google's suggestion that our test has only > >>> "demonstrated that it is possible to reduce VP8's > >> performance" (updated draft on VP8 http://datatracker.ietf.org/doc/dra= ft-alvestrand-rtcweb-vp8/). > >>> In fact, what we did in our test was mostly undoing some very > >>> peculiar > >>> x264 settings made by Google in their test from April 3. By instead > >>> using the x264 settings Google themselves proposed in their earlier > >>> test (from March 12), and removing threading, the difference went > >>> down from 41% to 16%. (This is without touching the VP8 parameters.) > >>> > >>> The last change we made was to remove the rate control from the > >>> comparison, something that is standard practice in > >> the world of video standardization. This involved changing both the > >> x264 and VP8 parameters. After that, the difference went down to -1%. > >>> In summary, the following steps were taken in our comparison: > >>> > >>> 1) Downloading the latest software: 41% became 36% > >>> 2) Removing threading: 26% > >>> 3) Removing bit padding: 18% > >>> 4) Removing other differences between Google's March 12 and April > >>> 3rd > >>> tests: 16% > >>> 5) Removing rate controller: -1% > >>> > >>> > >> Just a quick update on this - I did not manage to get a new draft > >> ready before the deadline, so I'll have to resort to sending email: > >> > >> I applied steps 1), 2) and 3) to the repository mentioned in the draft= . > >> The numbers I got were different, but significant. Below are the > >> VP8-to-x264 differences I encountered each step of the way. > >> > >> - Master branch before October 15: Difference 71.52% > >> - Updating x264 from 198a7ea (aug 16 2012) to c832fe (March 1 2013): > >> Difference 71.44% > >> (I could not go beyond this because yasm 1.2 was required for newe= r versions). > >> - Adding the --thread 1 parameter: Difference 26.11% > >> - Removing the --nai-hrd=3Dcbr parameter that was suggested by x264 > >> people: Difference 13.87% > >> - Removing vbv-maxrate and vbv-init 0.8: Difference 12.74% > >> > >> I did not shorten the clips to 10 seconds, nor did I try to control > >> rate by constant cq instead of a rate controller; if Bo's numbers are = right, this shouldn't matter. > >> > >> I did try removing "vbv-bufsize ${rate}", since this was the > >> remaining difference I could find for Bo's point 4 "other differences"= , but that was actually harmful (difference > increased to 19.05%), so I put it back. > >> > >> I checked this in to the repository - the commit is here: > >> > >> http://git.chromium.org/gitweb/?p=3Dwebm/vpx_codec_comparison.git;a=3D= com > >> mitdiff;h=3Dada7d7937a54e47fc18e2e0a1287 > >> aea29dc5d1c5 > >> > >> > >> This number does not fit the impression the video codec team has from > >> other tests - they think > >> VP8 can do a lot more than 13% better than baseline - but at the > >> draft deadline, we had not found the set of VP8 parameters that showed= this for this particular clip set. > >> > >> Commentary: I'm surprised at x264's choice of default value for the > >> --thread parameter. Accepting a 26% bitrate hit seems like a large pri= ce to pay for going faster by default. Is there a > bug here? > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb From kolarov@apple.com Tue Oct 22 16:47:01 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019FC11E82AB for ; Tue, 22 Oct 2013 16:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w2bBv7Hk0Hr for ; Tue, 22 Oct 2013 16:46:46 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 161F411E82AA for ; Tue, 22 Oct 2013 16:46:44 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MV300C1DGN11MQ0@mail-out.apple.com> for rtcweb@ietf.org; Tue, 22 Oct 2013 16:46:26 -0700 (PDT) X-AuditID: 11807166-b7f8c6d000004b57-75-52670e51caf9 Received: from [17.197.34.68] (Unknown_Domain [17.197.34.68]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 75.1C.19287.15E07625; Tue, 22 Oct 2013 16:46:25 -0700 (PDT) From: Krasimir Kolarov In-reply-to: <52665274.9080705@alvestrand.no> Date: Tue, 22 Oct 2013 16:46:29 -0700 Content-transfer-encoding: quoted-printable Message-id: <832B3A68-D7D1-4A1E-8C68-994CED97D6B5@apple.com> References: <52665274.9080705@alvestrand.no> To: Harald Alvestrand , "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1812) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUieFTJRTeQLz3IYM1aG4tjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBk9uy+wFdziqlj0aB9bA+M9ji5GTg4JAROJ CWdXsUDYYhIX7q1n62Lk4hAS6GaSOHdyAytIgllAT2LH9V9gNi+QfeXxdrAGYQEriTOzHrGD 2GwCWhId13rYQGxOAV2Jzx8uM4LYLAKqElPPnmeDmKMtsWzha2aIOTYSc07NAOrlAFqmI9G4 TxokLCIQLLHq9B8WkLCEgKzEp8NmExj5ZiE5YhaSI2YhGbqAkXkVo0BRak5ipYVeYkFBTqpe cn7uJkZQYDUUpu1gbFpudYhRgINRiYf3QUtakBBrYllxZe4hRgkOZiUR3mZfoBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXFerz9AKYH0xJLU7NTUgtQimCwTB6dUA2OsH1eOBNucVakdK31WcJye dS1lJ/uKrysZ32qJsL83jd+UK1M6VVNk54JLxw5tmOp955Mby6bVRwLm2mz54b4jYGf4v3iW bLYPlRlJa5YbFZY8WKP5+8x/pqgvtw15El5FZYtH1bsu15a79MZ2a5DInh8KM3o32v66ujZr ltwephX1WSn3GZcosRRnJBpqMRcVJwIAWSH3vCgCAAA= Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 23:47:01 -0000 To be very clear for the IETF community: As Harald=92s slide deck notes on Slide 2, these subjective test results = were not presented nor discussed at MPEG meetings. Hence they only = reflect the opinion of the VP8 proponents. The only subjective tests that were presented at the meeting compared = VP8 and IVC (the Internet Video Coding proposal considered by Mpeg, = which is different than AVC Constrained Baseline).=20 Those tests raised a lot of controversy during discussions at the = meeting and in fact some of the results had to be excluded because of = significant differences in comparison conditions (rate control, etc.). = This is not unlike recent discussions on this reflector about = comparisons of VP8 and H.264 Constrained Baseline.=20 Krasimir On Oct 22, 2013, at 3:24 AM, Harald Alvestrand = wrote: > In my VP8 advocate draft, I referred to a subjective evaluation test > (test with > actual human viewers) done between VP8 and H.264 Baseline by a neutral > (non-Google) laboratory. >=20 > The attached presentation is the writeup of the results of that test. >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From basilgohar@librevideo.org Tue Oct 22 17:40:42 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1ABE11E80DC for ; Tue, 22 Oct 2013 17:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoCzjoAdvoWE for ; Tue, 22 Oct 2013 17:40:37 -0700 (PDT) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2F11E82C4 for ; Tue, 22 Oct 2013 17:40:34 -0700 (PDT) Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id CBDEE659EA2 for ; Tue, 22 Oct 2013 20:40:33 -0400 (EDT) Message-ID: <52671AF7.5040107@librevideo.org> Date: Tue, 22 Oct 2013 20:40:23 -0400 From: Basil Mohamed Gohar Organization: Libre Video User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52665274.9080705@alvestrand.no> In-Reply-To: <52665274.9080705@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 00:40:43 -0000 On 10/22/2013 06:24 AM, Harald Alvestrand wrote: > In my VP8 advocate draft, I referred to a subjective evaluation test > (test with > actual human viewers) done between VP8 and H.264 Baseline by a neutral > (non-Google) laboratory. > > The attached presentation is the writeup of the results of that test. > Are the sources used in the video comparison test available anywhere? -- Libre Video http://librevideo.org From harald@alvestrand.no Tue Oct 22 23:04:23 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2645211E82E3 for ; Tue, 22 Oct 2013 23:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiLDaATnpRDQ for ; Tue, 22 Oct 2013 23:04:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F11AB11E8162 for ; Tue, 22 Oct 2013 23:04:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD36C39E127; Wed, 23 Oct 2013 08:04:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ6B2JUTbs5H; Wed, 23 Oct 2013 08:04:15 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 184B839E116; Wed, 23 Oct 2013 08:04:15 +0200 (CEST) Message-ID: <526766E5.2010302@alvestrand.no> Date: Wed, 23 Oct 2013 08:04:21 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Krasimir Kolarov , "rtcweb@ietf.org" References: <52665274.9080705@alvestrand.no> <832B3A68-D7D1-4A1E-8C68-994CED97D6B5@apple.com> In-Reply-To: <832B3A68-D7D1-4A1E-8C68-994CED97D6B5@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 06:04:23 -0000 On 10/23/2013 01:46 AM, Krasimir Kolarov wrote: > To be very clear for the IETF community: > > As Harald’s slide deck notes on Slide 2, these subjective test results were not presented nor discussed at MPEG meetings. Hence they only reflect the opinion of the VP8 proponents. Well.... strictly speaking, the results reflect the work of Vittorio Baronici. The methods reflect the methods chosen by MPEG. The presentation was made by a VP8 proponent. > > The only subjective tests that were presented at the meeting compared VP8 and IVC (the Internet Video Coding proposal considered by Mpeg, which is different than AVC Constrained Baseline). > Those tests raised a lot of controversy during discussions at the meeting and in fact some of the results had to be excluded because of significant differences in comparison conditions (rate control, etc.). Krasimir, I think you're mixing up two debates here (easy, since there have been two sets of subjective evaluation tests). The use of rate control was accepted by MPEG, despite protests by some of the members, since this is part of the design of VP8 in a way that it was never part of the design of H.264. No result was ever excluded in the IVC to VP8 comparision. After discussion, we all agreed that the results needed to be presented with a horizontal axis representing actual rate, not target rate; this has been done in the slides I sent out. Two results were dropped from the presentation of the VP8 results, which were not presented as a comparision with AVC High profile, due to issues with achieving very low bitrates. > This is not unlike recent discussions on this reflector about comparisons of VP8 and H.264 Constrained Baseline. Agreed. In both cases, the protestations that rate control is a problem reflect a position that MPEG did not come to consensus on. MPEG accepted the results that were produced using rate control. > > Krasimir > > On Oct 22, 2013, at 3:24 AM, Harald Alvestrand wrote: > >> In my VP8 advocate draft, I referred to a subjective evaluation test >> (test with >> actual human viewers) done between VP8 and H.264 Baseline by a neutral >> (non-Google) laboratory. >> >> The attached presentation is the writeup of the results of that test. >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Wed Oct 23 01:26:25 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9A821E8099 for ; Wed, 23 Oct 2013 01:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM70cj2dztyI for ; Wed, 23 Oct 2013 01:26:19 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B872521E8098 for ; Wed, 23 Oct 2013 01:26:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F289039E128 for ; Wed, 23 Oct 2013 10:26:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crPacbHq49F2 for ; Wed, 23 Oct 2013 10:26:13 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 78BF339E116 for ; Wed, 23 Oct 2013 10:26:13 +0200 (CEST) Message-ID: <5267882B.4060906@alvestrand.no> Date: Wed, 23 Oct 2013 10:26:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <52665274.9080705@alvestrand.no> <52671AF7.5040107@librevideo.org> In-Reply-To: <52671AF7.5040107@librevideo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 08:26:25 -0000 On 10/23/2013 02:40 AM, Basil Mohamed Gohar wrote: > On 10/22/2013 06:24 AM, Harald Alvestrand wrote: >> In my VP8 advocate draft, I referred to a subjective evaluation test >> (test with >> actual human viewers) done between VP8 and H.264 Baseline by a neutral >> (non-Google) laboratory. >> >> The attached presentation is the writeup of the results of that test. >> > Are the sources used in the video comparison test available anywhere? > They are under an MPEG license, so they're freely available to MPEG members for use in developing MPEG standards. If you fall within that category, I can send you the FTP server and password. MPEG doesn't have the tradition of open materials that the IETF has. From harald@alvestrand.no Wed Oct 23 02:26:07 2013 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C969C11E8345 for ; Wed, 23 Oct 2013 02:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.229 X-Spam-Level: X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBKmLRXj4Vz2 for ; Wed, 23 Oct 2013 02:26:03 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 094CC11E8340 for ; Wed, 23 Oct 2013 02:26:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5958D39E127; Wed, 23 Oct 2013 11:26:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6V43aZ888U8; Wed, 23 Oct 2013 11:25:58 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D1F7F39E116; Wed, 23 Oct 2013 11:25:58 +0200 (CEST) Message-ID: <5267962B.2000100@alvestrand.no> Date: Wed, 23 Oct 2013 11:26:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Bo Burman , "rtcweb@ietf.org" References: <52664A39.5040105@alvestrand.no> <52669059.4080700@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030009030409010609090802" Subject: Re: [rtcweb] Comments on H.264 and VP8 performance comparisons X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:26:08 -0000 This is a multi-part message in MIME format. --------------030009030409010609090802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/22/2013 06:26 PM, Bo Burman wrote: > Hi all, > > On 10/22/2013 04:28 PM, Harald Alvestrand wrote: > >> Having a 2.9% difference by swapping the order of arguments seems wrong; I'll pass this on to the guy who wrote that particular script. > Actually, this is not so weird at all. With the way of measuring that is done in your script, it makes a huge difference which sequence is the "anchor" (the first argument) and which is the "test subject" (the second argument). The reason is that a 10% bit rate increase is not equivalent to a 10% decrease when you turn the arguments around. Thanks for that explanation - makes sense! Also makes sense that it wouldn't matter for small differences, or ones where the differences were roughly the same for all the clips - the case we're in, where clips vary widely in relative performance, is a bit special. BTW, I talked to one of the guys who did the June tweaks to x264 parameters yesterday - he explained that he had done a (relatively) constant bitrate encoding for VP8 (mode=cbr), and was trying to achieve roughly the same result for x264; the advice he was given was to use the parameters you saw, with vbv-maxrate ${rate} and vbv-init 0.8 . Both VP8 and x264 seem to gain about a percentage point if they are allowed to do a more variable bitrate, so this is not a huge differentiator. > An illustrative example: > > Assume there are only two sequences, one that VP8 is really good at, so H264 need twice the bit rate to reach the same quality, and one that H.264 is really good at, so that it only need half the bits to reach the same quality. Then, using the VP8 codec as the anchor you get: > > Sequence 1: H.264 needs twice the number of bits (+100%) > Sequence 2: H.264 needs half the number of bits (-50%) > You average these two and you get (100%-50%)/2 = 25% more bits on average for H.264 > > If you, on the other hand, use H.264 as the anchor (first argument), you get > > Sequence 1: VP8 needs half the number of bits (-50%) > Sequence 2: VP8 needs twice the number of bits (+100%) > You average these two and you get (-50% + 100%)/2 = 25% more bits on average for VP8 > > Hence the script is biased towards the first argument in the script. > > Best Regards > Bo Burman > >> On 10/22/2013 04:20 PM, Bo Burman wrote: >>> Hi all, >>> >>> We understand that there are many people that are interested in a VP8 vs x264 comparison that includes rate controls. >>> >>> We therefore performed a quick study of the VP8 and x264 rate controls to see whether there were any major >> differences between them in the way they select quantizers. We found that VP8 uses what can be described as QP- >> toggling: By lowering the QP of, say, every 6th frame, you increase the quality of these markedly. The following frames >> also benefit from the increased quality (even though they have to make do with less bits than before) since they can >> predict from the high-quality frame. >>> However, we found that the rate-control of x264 does not QP-toggle in this fine granular way, and x264 may therefore >> be at a disadvantage when comparing against VP8. So we ran a test using a modified version of x264 to allow QP-toggling >> during rate control. The modification is very simple and a patch for the x264 code is found in the bottom of this email. >>> With this change, H.264 baseline (implemented using the modified x264 with rate control turned on) performs equally >> to VP8 with rate-control on; the difference is 1.3% in favor of VP8, but if you swap the order of the two codecs in >> draw_graphs.sh, H.264 baseline wins with 1.6%. This result is thus a tie between VP8 and H.264 baseline, and this is >> consistent with our previous fixed-QP test, and far from the (at least) 13% advantage for VP8 stated by Google. >>> The modification is simple and it may well be possible to improve x264 by more sophisticated modifications. But >> pursuing this track is what we oppose, we do not want comparisons where the outcome depends on how well you >> modify a particular rate control mechanism - the rate control is codec-agnostic after all. To avoid this we still maintain our >> view that codec comparisons should be done using fixed QP settings, which is also the practice in MPEG and VCEG. >>> We used the test parameters from Google's test repository >> https://git.chromium.org/git/webm/vpx_codec_comparison.git, the version >> ada7d7937a54e47fc18e2e0a1287aea29dc5d1c5. >> >> Thanks! >> >> Can you verify that you did see the same 12.7% difference when you ran the unmodified ada7d checkout? I want to be >> sure that I haven't missed any external influences on the results. >> >> Having a 2.9% difference by swapping the order of arguments seems wrong; I'll pass this on to the guy who wrote that >> particular script. >> >>> Here are the x264 and comparison script patches: >>> -- >>> >>> diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c index >>> 1a39a49..2cf256f 100644 >>> --- a/encoder/ratecontrol.c >>> +++ b/encoder/ratecontrol.c >>> @@ -1707,7 +1707,18 @@ int x264_ratecontrol_mb_qp( x264_t *h ) { >>> x264_emms(); >>> float qp = h->rc->qpm; >>> - if( h->param.rc.i_aq_mode ) >>> + >>> + if (h->sh.i_type != SLICE_TYPE_I){ >>> + if ((h->fenc->i_poc % 12 )== 0) >>> + qp -= 3.0; >>> + else >>> + qp += 0.0; >>> + >>> + } else { >>> + qp -= 5.0; >>> + } >>> + >>> + if( h->param.rc.i_aq_mode) >>> { >>> /* MB-tree currently doesn't adjust quantizers in unreferenced frames. */ >>> float qp_offset = h->fdec->b_kept_as_ref ? >>> h->fenc->f_qp_offset[h->mb.i_mb_xy] : >>> h->fenc->f_qp_offset_aq[h->mb.i_mb_xy]; >>> >>> >>> draw_graphs.sh: >>> >>> change >>> ./visual_metrics.py metrics_template.html "*0.txt" stats/h264 >>> stats/vp8 > vp8_vs_h264_quality.html to ./visual_metrics.py >>> metrics_template.html "*0.txt" stats/vp8 stats/h264 > >>> vp8_vs_h264_quality2.html >>> >>> Best Regards, >>> Bo Burman >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Harald Alvestrand >>>> Sent: den 22 oktober 2013 11:50 >>>> To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Comments on H.264 and VP8 performance >>>> comparisons >>>> >>>> On 10/14/2013 11:12 PM, Bo Burman wrote: >>>>> Hi all, >>>>> >>>>> We would like to counter Google's suggestion that our test has only >>>>> "demonstrated that it is possible to reduce VP8's >>>> performance" (updated draft on VP8 http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/). >>>>> In fact, what we did in our test was mostly undoing some very >>>>> peculiar >>>>> x264 settings made by Google in their test from April 3. By instead >>>>> using the x264 settings Google themselves proposed in their earlier >>>>> test (from March 12), and removing threading, the difference went >>>>> down from 41% to 16%. (This is without touching the VP8 parameters.) >>>>> >>>>> The last change we made was to remove the rate control from the >>>>> comparison, something that is standard practice in >>>> the world of video standardization. This involved changing both the >>>> x264 and VP8 parameters. After that, the difference went down to -1%. >>>>> In summary, the following steps were taken in our comparison: >>>>> >>>>> 1) Downloading the latest software: 41% became 36% >>>>> 2) Removing threading: 26% >>>>> 3) Removing bit padding: 18% >>>>> 4) Removing other differences between Google's March 12 and April >>>>> 3rd >>>>> tests: 16% >>>>> 5) Removing rate controller: -1% >>>>> >>>>> >>>> Just a quick update on this - I did not manage to get a new draft >>>> ready before the deadline, so I'll have to resort to sending email: >>>> >>>> I applied steps 1), 2) and 3) to the repository mentioned in the draft. >>>> The numbers I got were different, but significant. Below are the >>>> VP8-to-x264 differences I encountered each step of the way. >>>> >>>> - Master branch before October 15: Difference 71.52% >>>> - Updating x264 from 198a7ea (aug 16 2012) to c832fe (March 1 2013): >>>> Difference 71.44% >>>> (I could not go beyond this because yasm 1.2 was required for newer versions). >>>> - Adding the --thread 1 parameter: Difference 26.11% >>>> - Removing the --nai-hrd=cbr parameter that was suggested by x264 >>>> people: Difference 13.87% >>>> - Removing vbv-maxrate and vbv-init 0.8: Difference 12.74% >>>> >>>> I did not shorten the clips to 10 seconds, nor did I try to control >>>> rate by constant cq instead of a rate controller; if Bo's numbers are right, this shouldn't matter. >>>> >>>> I did try removing "vbv-bufsize ${rate}", since this was the >>>> remaining difference I could find for Bo's point 4 "other differences", but that was actually harmful (difference >> increased to 19.05%), so I put it back. >>>> I checked this in to the repository - the commit is here: >>>> >>>> http://git.chromium.org/gitweb/?p=webm/vpx_codec_comparison.git;a=com >>>> mitdiff;h=ada7d7937a54e47fc18e2e0a1287 >>>> aea29dc5d1c5 >>>> >>>> >>>> This number does not fit the impression the video codec team has from >>>> other tests - they think >>>> VP8 can do a lot more than 13% better than baseline - but at the >>>> draft deadline, we had not found the set of VP8 parameters that showed this for this particular clip set. >>>> >>>> Commentary: I'm surprised at x264's choice of default value for the >>>> --thread parameter. Accepting a 26% bitrate hit seems like a large price to pay for going faster by default. Is there a >> bug here? >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb --------------030009030409010609090802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/22/2013 06:26 PM, Bo Burman wrote:
Hi all, 

On 10/22/2013 04:28 PM, Harald Alvestrand wrote:


Having a 2.9% difference by swapping the order of arguments seems wrong; I'll pass this on to the guy who wrote that particular script.

Actually, this is not so weird at all. With the way of measuring that is done in your script, it makes a huge difference which sequence is the "anchor" (the first argument) and which is the "test subject" (the second argument). The reason is that a 10% bit rate increase is not equivalent to a 10% decrease when you turn the arguments around.

Thanks for that explanation - makes sense!
Also makes sense that it wouldn't matter for small differences, or ones where the differences were roughly the same for all the clips - the case we're in, where clips vary widely in relative performance, is a bit special.

BTW, I talked to one of the guys who did the June tweaks to x264 parameters yesterday - he explained that he had done a (relatively) constant bitrate encoding for VP8 (mode=cbr), and was trying to achieve roughly the same result for x264; the advice he was given was to use the parameters you saw, with vbv-maxrate ${rate} and vbv-init 0.8 . Both VP8 and x264 seem to gain about a percentage point if they are allowed to do a more variable bitrate, so this is not a huge differentiator.

 An illustrative example:

Assume there are only two sequences, one that VP8 is really good at, so H264 need twice the bit rate to reach the same quality, and one that H.264 is really good at, so that it only need half the bits to reach the same quality. Then, using the VP8 codec as the anchor you get:

Sequence 1: H.264 needs twice the number of bits (+100%) 
Sequence 2: H.264 needs half the number of bits (-50%) 
You average these two and you get (100%-50%)/2 = 25% more bits on average for H.264

If you, on the other hand, use H.264 as the anchor (first argument), you get

Sequence 1: VP8 needs half the number of bits (-50%) 
Sequence 2: VP8 needs twice the number of bits (+100%) 
You average these two and you get (-50% + 100%)/2 = 25% more bits on average for VP8

Hence the script is biased towards the first argument in the script.

Best Regards
Bo Burman


On 10/22/2013 04:20 PM, Bo Burman wrote:

Hi all,

We understand that there are many people that are interested in a VP8 vs x264 comparison that includes rate controls.

We therefore performed a quick study of the VP8 and x264 rate controls to see whether there were any major

differences between them in the way they select quantizers. We found that VP8 uses what can be described as QP-
toggling: By lowering the QP of, say, every 6th frame, you increase the quality of these markedly. The following frames
also benefit from the increased quality (even though they have to make do with less bits than before) since they can
predict from the high-quality frame.

However, we found that the rate-control of x264 does not QP-toggle in this fine granular way, and x264 may therefore

be at a disadvantage when comparing against VP8. So we ran a test using a modified version of x264 to allow QP-toggling
during rate control. The modification is very simple and a patch for the x264 code is found in the bottom of this email.

With this change, H.264 baseline (implemented using the modified x264 with rate control turned on) performs equally

to VP8 with rate-control on; the difference is 1.3% in favor of VP8, but if you swap the order of the two codecs in
draw_graphs.sh, H.264 baseline wins with 1.6%. This result is thus a tie between VP8 and H.264 baseline, and this is
consistent with our previous fixed-QP test, and far from the (at least) 13% advantage for VP8 stated by Google.

The modification is simple and it may well be possible to improve x264 by more sophisticated modifications. But

pursuing this track is what we oppose, we do not want comparisons where the outcome depends on how well you
modify a particular rate control mechanism - the rate control is  codec-agnostic after all. To avoid this we still maintain our
view that codec comparisons should be done using fixed QP settings, which is also the practice in MPEG and VCEG.

We used the test parameters from Google's test repository

https://git.chromium.org/git/webm/vpx_codec_comparison.git, the version
ada7d7937a54e47fc18e2e0a1287aea29dc5d1c5.

Thanks!

Can you verify that you did see the same 12.7% difference when you ran the unmodified ada7d checkout? I want to be
sure that I haven't missed any external influences on the results.

Having a 2.9% difference by swapping the order of arguments seems wrong; I'll pass this on to the guy who wrote that
particular script.


Here are the x264 and comparison script patches:
--

diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c index
1a39a49..2cf256f 100644
--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -1707,7 +1707,18 @@ int x264_ratecontrol_mb_qp( x264_t *h ) {
      x264_emms();
      float qp = h->rc->qpm;
-    if( h->param.rc.i_aq_mode )
+
+       if (h->sh.i_type != SLICE_TYPE_I){
+          if ((h->fenc->i_poc % 12 )== 0)
+              qp -= 3.0;
+          else
+              qp += 0.0;
+
+       } else {
+          qp -= 5.0;
+       }
+
+    if( h->param.rc.i_aq_mode)
      {
           /* MB-tree currently doesn't adjust quantizers in unreferenced frames. */
          float qp_offset = h->fdec->b_kept_as_ref ?
h->fenc->f_qp_offset[h->mb.i_mb_xy] :
h->fenc->f_qp_offset_aq[h->mb.i_mb_xy];


draw_graphs.sh:

change
./visual_metrics.py metrics_template.html "*0.txt" stats/h264
stats/vp8  > vp8_vs_h264_quality.html to ./visual_metrics.py
metrics_template.html "*0.txt" stats/vp8 stats/h264  >
vp8_vs_h264_quality2.html

Best Regards,
Bo Burman


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf Of Harald Alvestrand
Sent: den 22 oktober 2013 11:50
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Comments on H.264 and VP8 performance
comparisons

On 10/14/2013 11:12 PM, Bo Burman wrote:

Hi all,

We would like to counter Google's suggestion that our test has only
"demonstrated that it is possible to reduce VP8's

performance" (updated draft on VP8 http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/).

In fact, what we did in our test was mostly undoing some very
peculiar
x264 settings made by Google in their test from April 3. By instead
using the x264 settings Google themselves proposed in their earlier
test (from March 12), and removing threading, the difference went
down from 41% to 16%. (This is without touching the VP8 parameters.)

The last change we made was to remove the rate control from the
comparison, something that is standard practice in

the world of video standardization. This involved changing both the
x264 and VP8 parameters. After that, the difference went down to -1%.

In summary, the following steps were taken in our comparison:

1) Downloading the latest software: 41% became 36%
2) Removing threading: 26%
3) Removing bit padding: 18%
4) Removing other differences between Google's March 12 and April
3rd
tests: 16%
5) Removing rate controller: -1%



Just a quick update on this - I did not manage to get a new draft
ready before the deadline, so I'll have to resort to sending email:

I applied steps 1), 2) and 3) to the repository mentioned in the draft.
The numbers I got were different, but significant. Below are the
VP8-to-x264 differences I encountered each step of the way.

- Master branch before October 15: Difference 71.52%
- Updating x264 from 198a7ea (aug 16 2012) to c832fe (March 1 2013):
Difference 71.44%
    (I could not go beyond this because yasm 1.2 was required for newer versions).
- Adding the --thread 1 parameter: Difference 26.11%
- Removing the --nai-hrd=cbr parameter that was suggested by x264
people: Difference 13.87%
- Removing vbv-maxrate and vbv-init 0.8: Difference 12.74%

I did not shorten the clips to 10 seconds, nor did I try to control
rate by constant cq instead of a rate controller; if Bo's numbers are right, this shouldn't matter.

I did try removing "vbv-bufsize ${rate}", since this was the
remaining difference I could find for Bo's point 4 "other differences", but that was actually harmful (difference

increased to 19.05%), so I put it back.

I checked this in to the repository - the commit is here:

http://git.chromium.org/gitweb/?p=webm/vpx_codec_comparison.git;a=com
mitdiff;h=ada7d7937a54e47fc18e2e0a1287
aea29dc5d1c5


This number does not fit the impression the video codec team has from
other tests - they think
VP8 can do a lot more than 13% better than baseline - but at the
draft deadline, we had not found the set of VP8 parameters that showed this for this particular clip set.

Commentary: I'm surprised at x264's choice of default value for the
--thread parameter. Accepting a 26% bitrate hit seems like a large price to pay for going faster by default. Is there a

bug here?

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


    

    

  


--------------030009030409010609090802--

From basilgohar@librevideo.org  Wed Oct 23 06:32:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB53511E83F4 for ; Wed, 23 Oct 2013 06:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HANm5mFFKe1G for ; Wed, 23 Oct 2013 06:32:21 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C411E8408 for ; Wed, 23 Oct 2013 06:32:20 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 5102065AD55 for ; Wed, 23 Oct 2013 09:32:19 -0400 (EDT)
Message-ID: <5267CFE0.6040300@librevideo.org>
Date: Wed, 23 Oct 2013 09:32:16 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52665274.9080705@alvestrand.no> <52671AF7.5040107@librevideo.org> <5267882B.4060906@alvestrand.no>
In-Reply-To: <5267882B.4060906@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 13:32:27 -0000

On 10/23/2013 04:26 AM, Harald Alvestrand wrote:
> On 10/23/2013 02:40 AM, Basil Mohamed Gohar wrote:
>> On 10/22/2013 06:24 AM, Harald Alvestrand wrote:
>>> In my VP8 advocate draft, I referred to a subjective evaluation test
>>> (test with
>>> actual human viewers) done between VP8 and H.264 Baseline by a neutral
>>> (non-Google) laboratory.
>>>
>>> The attached presentation is the writeup of the results of that test.
>>>
>> Are the sources used in the video comparison test available anywhere?
>>
> They are under an MPEG license, so they're freely available to MPEG
> members for use in developing MPEG standards. If you fall within that
> category, I can send you the FTP server and password.
> 
> MPEG doesn't have the tradition of open materials that the IETF has.
> 

Well, that's unfortunate.  Thanks for clarifying, though.

It would be nice if, when time permits, a similar test can be made,
using the same criteria (encoding parameters, etc.), but with known
clips (e.g., from derf's collection, which has everything, including
both SD and HD clips).  Publishing the versions and exact encoding
parameters (including command line usage) would be helpful to that aim,
I suppose.

-- 
Libre Video
http://librevideo.org

From harald@alvestrand.no  Wed Oct 23 11:51:15 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1848411E81F5 for ; Wed, 23 Oct 2013 11:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.519
X-Spam-Level: 
X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4945Knh8CoRU for ; Wed, 23 Oct 2013 11:51:09 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1965F11E8204 for ; Wed, 23 Oct 2013 11:51:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DEF139E173 for ; Wed, 23 Oct 2013 20:51:03 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IygTcqDazwf7 for ; Wed, 23 Oct 2013 20:51:02 +0200 (CEST)
Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B5C3D39E116 for ; Wed, 23 Oct 2013 20:51:02 +0200 (CEST)
Message-ID: <52681A96.2020904@alvestrand.no>
Date: Wed, 23 Oct 2013 20:51:02 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 18:51:15 -0000

Just a reminder:
The back-and-forth of numbers doesn't change the core question of this
debate.
Both codecs are capable of high quality video encoding, and performance
numbers are comparable.

The real core question is the IPR issue.

The tradition of the IETF says that allowing only business models that
can sustain royalty agreements and royalty payments is Bad for the Internet.

The dominant video codec, H.264, is a royalty-required codec.

Do we switch now, or do we give up and live with royalties forever?

-- 
Surveillance is pervasive. Go Dark.


From salvatore.loreto@ericsson.com  Wed Oct 23 12:38:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1380211E83B4 for ; Wed, 23 Oct 2013 12:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.043
X-Spam-Level: 
X-Spam-Status: No, score=-106.043 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyEoL6-QxuxC for ; Wed, 23 Oct 2013 12:38:03 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 640BD11E8236 for ; Wed, 23 Oct 2013 12:38:03 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-b2-526825989af5
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F2.41.03802.89528625; Wed, 23 Oct 2013 21:38:00 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.209]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 21:38:00 +0200
From: Salvatore Loreto 
To: Michael Tuexen 
Thread-Topic: [rtcweb] Definition of "webrtc-datachannel" protocol?
Thread-Index: AQHOzuWWPOJYMRVh6EikDnWm089RpZoAMzIAgAJcQQA=
Date: Wed, 23 Oct 2013 19:38:00 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A2E13BD@ESESSMB109.ericsson.se>
References:  <1639895C-DE36-4F2E-8247-3B8A74D2DDE8@lurchi.franken.de>
In-Reply-To: <1639895C-DE36-4F2E-8247-3B8A74D2DDE8@lurchi.franken.de>
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-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje4M1Ywgg89rbSy2ThWyuNi0hNFi 7b92dgdmjwWbSj2WLPnJ5LGhZQdTAHMUl01Kak5mWWqRvl0CV0bL0ndsBa85Kx4tPcLWwDiX o4uRk0NCwETif9MCFghbTOLCvfVsXYxcHEIChxklpl44zAThLGGUWLfzMitIFZuAmcTzh1uY QWwRAVOJg8vngXUzC3hLfFr0gB3EFhZwkpi97isLRI2zRPvvFWwQtpXEgQOPwGpYBFQlvs74 CzaHF6j3Rv99sHohgW5Gic7jKSA2p4CrxLoNkxlBbEag676fWsMEsUtc4taT+UwQVwtILNlz nhnCFpV4+fgfK4StJLHo9meoeh2JBbs/sUHY1hK31z9lh7C1JZYtfA11g6DEyZlPWCYwis9C smIWkvZZSNpnIWmfhaR9ASPrKkb23MTMnPRyo02MwCg7uOW36g7GO+dEDjFKc7AoifN+eOsc JCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxdvLKzOdf3RYFz3PPFGVq1zw5ZfbtyAXCH8Rb Fpwy/qKVx2oYuzyL9+THWVd7Vgt6P+4yMu4xvNDX1P2p9WsJd+9kse4H2palER8irrJF/mxZ VcEYu2OW1OUTbycLHDjxzSKkYELf1SNpnwX5N7kl/Z1w3/XdfQZBqw3nTp1eovKFmdm3/KGx EktxRqKhFnNRcSIA6bnumYACAAA=
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Definition of "webrtc-datachannel" protocol?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 19:38:24 -0000

it can go either in it can go directly in draft-ietf-rtcweb-data-channel
or in the draft-ietf-mmusic-sctp-sdp-05 as=20

at the end is just a matter of registering a
application sub media type for draft-ietf-rtcweb-data-channel


I people don't disagree I will insert in the draft-ietf-mmusic-sctp-sdp=20
and I will submit a new version as soon as the submission re-open

br
Salvatore


On Oct 22, 2013, at 10:35 AM, Michael Tuexen  wrote:

> On Oct 22, 2013, at 7:14 AM, Justin Uberti  wrote:
>=20
>> Maybe I just missed this, but which draft defines the "webrtc-datachanne=
l" string that is placed into the a=3Dsctpmap line?
>>=20
>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 refers to it, b=
ut I can't find where it's actually defined/registered.
> Should it be defined in draft-ietf-mmusic-sctp-sdp-05, since it is used i=
n SDP?
>=20
> Best regards
> Michael
>> _______________________________________________
>> 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 basilgohar@librevideo.org  Wed Oct 23 12:42:47 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F1D11E8358 for ; Wed, 23 Oct 2013 12:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3Ug+a5dnfi3 for ; Wed, 23 Oct 2013 12:42:42 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 11EDC11E8236 for ; Wed, 23 Oct 2013 12:42:42 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 9E1DC65A43C for ; Wed, 23 Oct 2013 15:42:41 -0400 (EDT)
Message-ID: <526826AF.5030308@librevideo.org>
Date: Wed, 23 Oct 2013 15:42:39 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no>
In-Reply-To: <52681A96.2020904@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 19:42:47 -0000

On 10/23/2013 02:51 PM, Harald Alvestrand wrote:
> Just a reminder:
> The back-and-forth of numbers doesn't change the core question of this
> debate.
> Both codecs are capable of high quality video encoding, and performance
> numbers are comparable.
> 
> The real core question is the IPR issue.
> 
> The tradition of the IETF says that allowing only business models that
> can sustain royalty agreements and royalty payments is Bad for the Internet.
> 
> The dominant video codec, H.264, is a royalty-required codec.
> 
> Do we switch now, or do we give up and live with royalties forever?
> 

Harald,

I would like to see some references to the tradition of the IETF that
you've quoted.

For the record, I agree with the sentiment, but I'd like to be able to
back up the claim itself with references or explicit decisions that were
made in that regard.  I'm not trying to be a thorn in your side, just
looking for citations to back up the arguments, both on and off list.

-- 
Libre Video
http://librevideo.org

From cowwoc@bbs.darktech.org  Wed Oct 23 13:55:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D422B11E81E1 for ; Wed, 23 Oct 2013 13:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=-2.917, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdRMrXtbj1Ma for ; Wed, 23 Oct 2013 13:55:22 -0700 (PDT)
Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id E242D11E81D0 for ; Wed, 23 Oct 2013 13:55:21 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so2253479iec.6 for ; Wed, 23 Oct 2013 13:55:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HQopiGApVFjZJ7gcrHXCdJeuHk9CmwkeowJTFA53SVc=; b=IYqLftD7ZI6k5zMeAWikuioNfUH91jD/cyz+9QMG9n/2Q0wBaEnCJAo7F7gZKpgDpR 0ZHuGFZGb+HS4qMVxdux9vm61X0BS8XAPqWzF1BLEul37peRao6Fvr27dmEl8BkeI5BC qxxnwboGxVqluCCPP1icuiDQwuOP9Iy91GQUwFmMMr+VaGQjhd9WyBzNCo6bDBomeZg9 Ten1Q6jwhJ7t7RGkOQNX4qeA7UU5+zGNmliqJtSoWtrNmnqMh9wGNpOpnTvQLb4eQwa9 UhoRGLOnBe2NL9fqsxkBjPUsqsa+35kBZacaHRkoQrWfTPCzMZRlaPbSZwIOFAPX5BMB +9JQ==
X-Gm-Message-State: ALoCoQl9ocCFYRl8DhlXac6e3WHEk0+gm+eyfrn40EOlYxFfHsomlcosehYpiTRqmOQIJ1wakNsS
X-Received: by 10.50.87.36 with SMTP id u4mr2327189igz.40.1382561720783; Wed, 23 Oct 2013 13:55:20 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f5sm8662622igc.4.2013.10.23.13.55.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 13:55:19 -0700 (PDT)
Message-ID: <526837B5.8020507@bbs.darktech.org>
Date: Wed, 23 Oct 2013 16:55:17 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>
In-Reply-To: <526826AF.5030308@librevideo.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 20:55:28 -0000

On 23/10/2013 3:42 PM, Basil Mohamed Gohar wrote:
> On 10/23/2013 02:51 PM, Harald Alvestrand wrote:
>> Just a reminder:
>> The back-and-forth of numbers doesn't change the core question of this
>> debate.
>> Both codecs are capable of high quality video encoding, and performance
>> numbers are comparable.
>>
>> The real core question is the IPR issue.
>>
>> The tradition of the IETF says that allowing only business models that
>> can sustain royalty agreements and royalty payments is Bad for the Internet.
>>
>> The dominant video codec, H.264, is a royalty-required codec.
>>
>> Do we switch now, or do we give up and live with royalties forever?
>>
> Harald,
>
> I would like to see some references to the tradition of the IETF that
> you've quoted.
>
> For the record, I agree with the sentiment, but I'd like to be able to
> back up the claim itself with references or explicit decisions that were
> made in that regard.  I'm not trying to be a thorn in your side, just
> looking for citations to back up the arguments, both on and off list.
>
Harald,

     I think it is premature to imply that VP8 is royalty free. I have 
nothing against the codec (it's great) but it's my understanding that 
Google can't guarantee that someone else won't exercise IPR rights 
against VP8 in the future. The best we can say is that H264 requires 
royalties today and VP8 *might* require royalties in the future. H264 
has a slight advantage in this space in that we have well-understood 
licensing terms.

     I just wanted to put that out there so there are no confusions in 
the future.

Gili

From basilgohar@librevideo.org  Wed Oct 23 14:05:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B4911E81F8 for ; Wed, 23 Oct 2013 14:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA+PuTHTGW9g for ; Wed, 23 Oct 2013 14:05:38 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7AC11E8122 for ; Wed, 23 Oct 2013 14:05:36 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 9161D65A46A for ; Wed, 23 Oct 2013 17:05:35 -0400 (EDT)
Message-ID: <52683A1C.1090506@librevideo.org>
Date: Wed, 23 Oct 2013 17:05:32 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <526837B5.8020507@bbs.darktech.org>
In-Reply-To: <526837B5.8020507@bbs.darktech.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:05:49 -0000

On 10/23/2013 04:55 PM, cowwoc wrote:
> Harald,
> 
>     I think it is premature to imply that VP8 is royalty free. I have
> nothing against the codec (it's great) but it's my understanding that
> Google can't guarantee that someone else won't exercise IPR rights
> against VP8 in the future. The best we can say is that H264 requires
> royalties today and VP8 *might* require royalties in the future. H264
> has a slight advantage in this space in that we have well-understood
> licensing terms.
> 
>     I just wanted to put that out there so there are no confusions in
> the future.
> 
> Gili

Actually, this is exactly the kind of FUD that has stifled the adoption
of VP8 and, before it, Theora and Vorbis, as universally-available
multimedia format.  It serves only to confuse the issue further, as I
will explain below.

For starters, there is no evidence whatsoever that there is a viable IPR
concern with VP8, but there exist baseless allegations.  In fact, what
little doubt that there might have been one was settled by the agreement
signed between Google and MPEG-LA [1] a short while ago, which resulted
in MPEG-LA withdrawing their attempt a forming a patent pool for VP8
altogether.  An attempt, I might add, that had little public activity
save for its initial announcement once VP8 was being concerned for
international standards.  In fact, the extremely generous terms of the
agreement lend credence to the fact that there was little that existing
that would have been enforceable.

Furthermore, the fact that there is an existing licensing structure for
H.264 give exactly zero assurances of protections from IPR claims,
because not all licensors of H.264 technology are a member of the
MPEG-LA patent pool agreement, and there have been numerous patent cases
related to H.264 and other technologies thought to be covered by RAND
and FRAND terms.

Finally, the current patent and IPR landscape, at least in the US, and
widely in other portions of the world, eliminates the possibility of
something *never* being under a patent threat, due to the presence of
patent trolls that actively wait for adoption as well the sheer
magnitude of patents and the very ease with which patent legislation can
be brought up (including for those already "covered" by existing patent
pools, e.g., H.264).

So, in actuality, H.264 holds no advantage over VP8 in this regard, and
the claim that VP8 is a liability to use is not evidenced by any actual
unique tangible threat to date.

[1] http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html

-- 
Libre Video
http://librevideo.org

From xiphmont@gmail.com  Wed Oct 23 14:37:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55A711E821E for ; Wed, 23 Oct 2013 14:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.559
X-Spam-Level: *
X-Spam-Status: No, score=1.559 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MANGLED_EMAIL=2.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A74TQiEWpZmD for ; Wed, 23 Oct 2013 14:37:54 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 505A311E81EB for ; Wed, 23 Oct 2013 14:37:53 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id eh20so1202108lab.11 for ; Wed, 23 Oct 2013 14:37:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rDsEw8iPHKcfIsj5tkR4dzp5W2OsyIKlXPjg/Cv3W4c=; b=G2DuI6qaeTrGtZgYHo8jZpQ9AqcuIDCjCBnk/xnh/+fWwbYAdsQqPbL4X5azvQmC0d VZQMcJy9p4g52DCC6nPeCfvuHD/AJmnhm+UoAoqE0jRhC60BSXV7NGyvxMP722rNmJ8P dBkFhsLIBlV3n8o3cgjgjEcDJxRLqe2R5rfQ5htY+hwJNp3joawL5sk9vK0fnFTqzgoR nGrJ5K51vs11dO4GmDbU9Am1m3hFJNF8b5m/Rc/RjQo7KMELsZ0D4Jvn5u3jBH0JRsP0 y8+UDemJ85HCJQPOQclw/ZJaKXzfo97m36dQIX0+txco4cdS1GAC49erGxLMnAkmmiSl R9Uw==
MIME-Version: 1.0
X-Received: by 10.152.170.233 with SMTP id ap9mr67678lac.51.1382564272015; Wed, 23 Oct 2013 14:37:52 -0700 (PDT)
Received: by 10.112.11.48 with HTTP; Wed, 23 Oct 2013 14:37:51 -0700 (PDT)
In-Reply-To: <526837B5.8020507@bbs.darktech.org>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <526837B5.8020507@bbs.darktech.org>
Date: Wed, 23 Oct 2013 17:37:51 -0400
Message-ID: 
From: Monty Montgomery 
To: cowwoc 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:37:54 -0000

> I think it is premature to imply that VP8 is royalty free.

...and we can't be 100% sure vaccines don't cause autism.  Throw 'em all out!

Seriously, at this point, I've been hearing this exact IPR line for
twenty years as an excuse for not doing the right thing.  'They' were
going to come after Vorbis, 'they' were going to come after Theora,
'they' were going to come after Speex, 'they're' supposedly coming
after Opus, and now 'they're' coming after VP8.  I'm sure we'll repeat
it for VP9, VP10 and Daala.  Fool me once, shame on you.  Fool me
twice, shame on me.  Fool me indefinitely, you have a wonderful future
waiting in sales and marketing.

If you want to contend that using VP8 is riskier because it is going
against the traditional, established industry channels, that's a
defensible argument.  But that isn't about the IPR.   Someone who
wants to litigate rather than compete on merit is going to find a way
to litigate, IPR or no.  That is true of both the VP8 and MPEG
positions.  However, we should not make technical decisions based upon
identifying and standing with the most economically powerful external
faction.

Monty

From silviapfeiffer1@gmail.com  Wed Oct 23 14:46:52 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6696711E81FA for ; Wed, 23 Oct 2013 14:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJlEKex-quPp for ; Wed, 23 Oct 2013 14:46:49 -0700 (PDT)
Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 273D611E82BE for ; Wed, 23 Oct 2013 14:46:26 -0700 (PDT)
Received: by mail-ob0-f175.google.com with SMTP id wm4so1463130obc.6 for ; Wed, 23 Oct 2013 14:46:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jsPG4fBd2zw5Y259FtnCTBO8t4E/x0AqX9Sqbwg/k6U=; b=nXYAsPauYuq6Dahd5MN/TZjZlalsj5shh5DxLyYLCSzgOoXxvE4IfHZfQ/B+kkNY4y pW+hGIVln1vohhW83lIXt21nPwXyp9iYAUE6ED6ZB0DhYm/8HY7AF0cm6CW8PTdCngWO OZ4Ndc7tfJFW48Fr1diCQYVGzZUSbJ7vn0YOt6rlkRaJ/4Rl0LZW6EnHtuqxX9k+mPhV iFVJkcyPC3JggHxqkPVoAvreZdsEcue1wp49/p4m/dYgUHfvbVeYglJXmF7rw3sXbl7M yl2mGNW4HHZh3QicKUdoEuevRSkPdq/bwDyQzPKbNpQQKLh2SI98RLL84tgfI9RiQ2Fa Y52w==
X-Received: by 10.182.233.228 with SMTP id tz4mr3821142obc.56.1382564785598; Wed, 23 Oct 2013 14:46:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.94.40 with HTTP; Wed, 23 Oct 2013 14:46:04 -0700 (PDT)
In-Reply-To: <52683A1C.1090506@librevideo.org>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <526837B5.8020507@bbs.darktech.org> <52683A1C.1090506@librevideo.org>
From: Silvia Pfeiffer 
Date: Thu, 24 Oct 2013 08:46:04 +1100
Message-ID: 
To: Basil Mohamed Gohar 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:46:52 -0000

On Thu, Oct 24, 2013 at 8:05 AM, Basil Mohamed Gohar
 wrote:
> On 10/23/2013 04:55 PM, cowwoc wrote:
>> Harald,
>>
>>     I think it is premature to imply that VP8 is royalty free. I have
>> nothing against the codec (it's great) but it's my understanding that
>> Google can't guarantee that someone else won't exercise IPR rights
>> against VP8 in the future. The best we can say is that H264 requires
>> royalties today and VP8 *might* require royalties in the future. H264
>> has a slight advantage in this space in that we have well-understood
>> licensing terms.
>>
>>     I just wanted to put that out there so there are no confusions in
>> the future.
>>
>> Gili
>
> Actually, this is exactly the kind of FUD that has stifled the adoption
> of VP8 and, before it, Theora and Vorbis, as universally-available
> multimedia format.  It serves only to confuse the issue further, as I
> will explain below.
>
> For starters, there is no evidence whatsoever that there is a viable IPR
> concern with VP8, but there exist baseless allegations.  In fact, what
> little doubt that there might have been one was settled by the agreement
> signed between Google and MPEG-LA [1] a short while ago, which resulted
> in MPEG-LA withdrawing their attempt a forming a patent pool for VP8
> altogether.  An attempt, I might add, that had little public activity
> save for its initial announcement once VP8 was being concerned for
> international standards.  In fact, the extremely generous terms of the
> agreement lend credence to the fact that there was little that existing
> that would have been enforceable.
>
> Furthermore, the fact that there is an existing licensing structure for
> H.264 give exactly zero assurances of protections from IPR claims,
> because not all licensors of H.264 technology are a member of the
> MPEG-LA patent pool agreement, and there have been numerous patent cases
> related to H.264 and other technologies thought to be covered by RAND
> and FRAND terms.
>
> Finally, the current patent and IPR landscape, at least in the US, and
> widely in other portions of the world, eliminates the possibility of
> something *never* being under a patent threat, due to the presence of
> patent trolls that actively wait for adoption as well the sheer
> magnitude of patents and the very ease with which patent legislation can
> be brought up (including for those already "covered" by existing patent
> pools, e.g., H.264).
>
> So, in actuality, H.264 holds no advantage over VP8 in this regard, and
> the claim that VP8 is a liability to use is not evidenced by any actual
> unique tangible threat to date.
>
> [1] http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html


On top of all this, it seems to me that
http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders on a
technology that is made part of an RFC to disclose their IPR and sign
a patent disclosure: http://tools.ietf.org/html/rfc3905 . I think this
process is trivial for VP8, but will require lengthy delays for
sorting out for H.264. In the interest of the Internet Community,
given that both codecs provide comparable quality at comparable
bitrates, we need to choose what is best for the Internet community.
RFC3979 even states this explicitly:

" In all matters of Intellectual Property Rights, the intent is to
   benefit the Internet community and the public at large, while
   respecting the legitimate rights of others."

It seems clear that given that there is no substantial technical
difference between the two, given that the IRP situation is so much
cleaner for VP8, and that the only known IPR holder for VP8 (ever
after challenges) is Google who are providing a perpetual royalty-free
license (http://www.webmproject.org/license/bitstream/), the
preference of the Internet community must clearly lie with VP8.

I would be surprised if the IESG - who has to consider IPR rights when
approving an RFC for publication - wouldn't have to overrule any
decision made by this WG to choose H.264 over VP8.

RFC3979 states:
" 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."


Best Regards,
Silvia.

From stpeter@stpeter.im  Wed Oct 23 14:55:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DE111E81C7 for ; Wed, 23 Oct 2013 14:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.35
X-Spam-Level: 
X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yfNaVDTjjFR for ; Wed, 23 Oct 2013 14:55:27 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 50D9611E81F2 for ; Wed, 23 Oct 2013 14:55:27 -0700 (PDT)
Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 349D840FA9; Wed, 23 Oct 2013 16:02:10 -0600 (MDT)
Message-ID: <526845CC.4020908@stpeter.im>
Date: Wed, 23 Oct 2013 15:55:24 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Silvia Pfeiffer ,  Basil Mohamed Gohar 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<526837B5.8020507@bbs.darktech.org>	<52683A1C.1090506@librevideo.org> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 21:55:31 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/13 3:46 PM, Silvia Pfeiffer wrote:

> On top of all this, it seems to me that 
> http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders on a 
> technology that is made part of an RFC to disclose their IPR and
> sign a patent disclosure:

That's not true. Only those who contribute to the relevant work need
to disclose. You can sit in all the WG sessions, but if you never say
a word you're not a contributor and you have no obligation to file a
disclosure.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSaEXMAAoJEOoGpJErxa2p8wsP/i9nhHbmW9J11HepTMQ+isUL
ix1BtH0fzwIHEy54s9sircLirKtzQua2Rn8qTSVluAcMjm/ORvBiIPLodswlMKiO
WJgzFroWcz4FqOUXdmK/GaRcXo9W3naQ0KDb7Lot00MnF7w8wV5TKW/s/VK5aP6Z
ZqDWm8mvEZhY7eJiRHTblZqihQqnQx78rufXZ90dzFlmtS4nXXn3kvFLGFHXfbww
pmP2azlsvx28khbOlMO2rzoIKZvcp7DI+jNRNO/EUqT9RR9++qzvm1oZ18Q/GYOY
/pLncXvvdQL/12mZLL8bU5rft7AeNpbiAGhmSvbbxLsVGg2t5e9ltQ5sXFcCpiCg
nVAJec91LtGSaAhV8pBEpkQdOVibovZxUud4wruSCr9WH49DoP5CWZcaDkSKzo4j
c/tiUS6iJSttBi2y3cvSD3hyc1lZWkrINluUqp4rdWtueic7wywz0fg0kazh/rtX
fV3Ee5L67ZeqSNb9ngcsOM1rVLQf/h2gtRk3rolIjx+j51YtnM6kVxxEbAYu8BBh
ihvrBwxwgtOzN5Grmn+dRbE8XXfFpc0zmVOjt1CInvNulDnG3sA6Za/o1GxWenrw
HAKIdGcxwGzzMc5AmeC2wLEBVKRmhLjxwjknt9xpMQyaYRuD4vDFWMs8gmFbHbF/
bMVF/f01CN283IYc5O1z
=4GAh
-----END PGP SIGNATURE-----

From silviapfeiffer1@gmail.com  Wed Oct 23 16:33:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EF811E8281 for ; Wed, 23 Oct 2013 16:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa07Q8TXTUlG for ; Wed, 23 Oct 2013 16:33:26 -0700 (PDT)
Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BF22011E8283 for ; Wed, 23 Oct 2013 16:33:25 -0700 (PDT)
Received: by mail-ob0-f175.google.com with SMTP id wm4so1600901obc.34 for ; Wed, 23 Oct 2013 16:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9ni06Lz8+vptEzM+yOFa10H4JkV4yN0q4LasxePw+Hg=; b=s7zPxaEwGoSHv8PDie4brFUN5fkMMWYGph2so+Yi0tHU1S32ybAm9Jea4Kj1dNDaeo rLMhWOYOmmbUmiGpoBtG1QR8cv7YeEnGbZSKMB3QGIydXE6w3oYVTWCxiOcYUW1GYbyo VUM8dLZhAfdxRPmcl9qteBltjC7+My0L/6f4ZNpCYLMuhoL3Ubml+9hXKu/Sc7eUTZuo lkI4XVF6O93I1x/zp3mae4rIjAFkArt3VLh61r4uahO024Mbo9dNgtgnv/2Qap4kB9aI PAAYf6Gn5zXqJ5kZOXuzhhwaj9BUZlYuQjJclRWeuQqcO5TSBjH4Vz89n3xm2Iq6ovzD 3KjA==
X-Received: by 10.60.155.145 with SMTP id vw17mr4125444oeb.50.1382571205237; Wed, 23 Oct 2013 16:33:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.94.40 with HTTP; Wed, 23 Oct 2013 16:32:58 -0700 (PDT)
In-Reply-To: <526845CC.4020908@stpeter.im>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <526837B5.8020507@bbs.darktech.org> <52683A1C.1090506@librevideo.org>  <526845CC.4020908@stpeter.im>
From: Silvia Pfeiffer 
Date: Thu, 24 Oct 2013 10:32:58 +1100
Message-ID: 
To: Peter Saint-Andre 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 23:33:26 -0000

On Thu, Oct 24, 2013 at 8:55 AM, Peter Saint-Andre  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/23/13 3:46 PM, Silvia Pfeiffer wrote:
>
>> On top of all this, it seems to me that
>> http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders on a
>> technology that is made part of an RFC to disclose their IPR and
>> sign a patent disclosure:
>
> That's not true. Only those who contribute to the relevant work need
> to disclose. You can sit in all the WG sessions, but if you never say
> a word you're not a contributor and you have no obligation to file a
> disclosure.

It also talks about known IPR from non-contributing people and that
that has to be disclosed, too.

Regards,
Silvia.

From stpeter@stpeter.im  Wed Oct 23 17:24:15 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7714E11E82A4 for ; Wed, 23 Oct 2013 17:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.237
X-Spam-Level: 
X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y62JGBUSdefN for ; Wed, 23 Oct 2013 17:24:11 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4B11E829E for ; Wed, 23 Oct 2013 17:24:10 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22AD2410A5; Wed, 23 Oct 2013 18:30:54 -0600 (MDT)
Message-ID: <526868A8.5080204@stpeter.im>
Date: Wed, 23 Oct 2013 18:24:08 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Silvia Pfeiffer 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <526837B5.8020507@bbs.darktech.org> <52683A1C.1090506@librevideo.org>  <526845CC.4020908@stpeter.im> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 00:24:15 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/13 5:32 PM, Silvia Pfeiffer wrote:
> On Thu, Oct 24, 2013 at 8:55 AM, Peter Saint-Andre
>  wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 10/23/13 3:46 PM, Silvia Pfeiffer wrote:
>> 
>>> On top of all this, it seems to me that 
>>> http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders on
>>> a technology that is made part of an RFC to disclose their IPR
>>> and sign a patent disclosure:
>> 
>> That's not true. Only those who contribute to the relevant work
>> need to disclose. You can sit in all the WG sessions, but if you
>> never say a word you're not a contributor and you have no
>> obligation to file a disclosure.
> 
> It also talks about known IPR from non-contributing people and
> that that has to be disclosed, too.

Your use of the passive voice here is misleading.

Certainly non-contributors might have IPR. But they have no obligation
to disclose.

I might wish that what you say is true, but it isn't (IMHO). If you
have questions about the IETF's IPR rules, I suggest that you talk
with the responsible Area Director.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSaGioAAoJEOoGpJErxa2p/P4P/RoytigTnfQc2jtolQ0WGpkO
iJ7CQxhOWdDsfx3ds2i5nssBHLckG4mreHJWr1sQEW7Emh6Mph2mnR97oDQyF3W9
LOUnck/k4zxuaDkNo5KXJcWnqrAe7agG9YgubXxrIIHL8wcWaU0BTxj8J5TXIb0N
XlBbkh3OVUUZjjEJYLN5zfOlacbz5cOrSdjuFSZg7+NwIhDTmMZy+MPyZSDEXRGp
BNe/XGcpQiqsQY+BgiLkG7hViHsYueP+X799yqF7Y+uVaoLan4bC7bHMFEQmXPlv
qvXz0Geu1FGpmtDa2r4kZ3w4t2SPvvtKnRcNDafAkHjPjFDh4EwxbtPVushOuTsk
QxBSGFstnrTGXGGXROUoy9ewuOkh4Ugd2ZnqSHLmxL9PFfbltYeJfrT7bg3cQKxr
xGO4bp6QJx/9dfsVX8xUF4n7/opyP036FtnMxeoIDSYx6g1BUwlU1hW8fE/V6Yku
6r30ylyGpMVntIvKxFPwIdn9i1cZacA5aCzTlFUnxLhfye+Uib5v0JpUSa1H1Wzq
0oEYYg5NAY6S6zTL3fHUZHWkYSx+noi8lDMdePs7lPorvneFqdWc9ITMh2kk3qoQ
ctY0YBVrDNpYkBZt4+WUXZerkRtizutEdMOJcE0VUmzpV/xMuts3rLLr+z+g69kL
jYd7y6ExXXlrKCXTQXCX
=GXVb
-----END PGP SIGNATURE-----

From ibc@aliax.net  Wed Oct 23 17:46:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771D11E823D for ; Wed, 23 Oct 2013 17:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC6dDjdrxR0M for ; Wed, 23 Oct 2013 17:45:55 -0700 (PDT)
Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20111E8298 for ; Wed, 23 Oct 2013 17:45:49 -0700 (PDT)
Received: by mail-qe0-f52.google.com with SMTP id w7so1003273qeb.25 for ; Wed, 23 Oct 2013 17:45:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=mL5xHM20c2WzjWei4eBP/KD3jc3E86dqUU1EkPFiAcM=; b=PL09wFwo9t+w9JlF05P9awSdAaH74Cexx5FSdBMRqRBKqHHmPyo8s2WZ8Be3L2xIMt vgWzkLnq52A+6ga5hspXtxgxrYogeO5Dp12IsprojOygL9SqV29fj6H1vSomaJ24lVzw Io8k7xAVAB5DErf0Tq4Bo/mKpYuH3Ok4cDMHKAeIsHiHfhl+Z250sAHMknu12KBdNcSQ Del5EJI45tYNp33bkl/ltd/XSisp63NfAwSKGGQiI2mMm+y55LFsk4Ti/aPMIUkZRRgK 3l2JiRUu20uszEB+GsqFOf1u6VnYkPyth0ZNzF0Joi7frS0+o3YE7fOIq1YRewteZZ2e GjGA==
X-Gm-Message-State: ALoCoQmysV7WgoQdPsc6IkXy2L3aoPlR4uktTP7AaENi6+CLdrz3cNitWkAIrykaDM5qksb46l+e
X-Received: by 10.224.29.208 with SMTP id r16mr637004qac.25.1382575548332; Wed, 23 Oct 2013 17:45:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.71.8 with HTTP; Wed, 23 Oct 2013 17:45:28 -0700 (PDT)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 24 Oct 2013 02:45:28 +0200
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [rtcweb] New SDP O/A required if selected ICE candidate does not match c= line?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 00:46:00 -0000

Hi, RFC 5245 (ICE) says:

-----------------------------
  4.1.4.  Choosing Default Candidates

   A candidate is said to be default if it would be the target of media
   from a non-ICE peer; that target is called the DEFAULT DESTINATION.
   If the default candidates are not selected by the ICE algorithm when
   communicating with an ICE-aware peer, an updated offer/answer will be
   required after ICE processing completes in order to "fix up" the SDP
   so that the default destination for media matches the candidates
   selected by ICE.  If ICE happens to select the default candidates, no
   updated offer/answer is required.
------------------------------

Having to perform a second SDP O/A just to "fix the c=3D line" seems
terriblly annoying and unuseful IMHO. Said that, this is obviously
"violated" by WebRTC browsers, right?

Thanks a lot.



--=20
I=C3=B1aki Baz Castillo


From magnus.westerlund@ericsson.com  Thu Oct 24 00:38:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9011E82FD for ; Thu, 24 Oct 2013 00:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.515
X-Spam-Level: 
X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw1MY3vHn+qI for ; Thu, 24 Oct 2013 00:38:04 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A90F111E82F5 for ; Thu, 24 Oct 2013 00:37:58 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-7b-5268ce5549f6
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.D9.09019.55EC8625; Thu, 24 Oct 2013 09:37:57 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Thu, 24 Oct 2013 09:37:57 +0200
Message-ID: <5268CE7B.2070202@ericsson.com>
Date: Thu, 24 Oct 2013 09:38:35 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvjW7ouYwggzXzDC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsfro0wFq/gqPr1rYmxg7OLpYuTkkBAwkbh9/To7hC0mceHe ejYQW0jgKKPEi5NmXYxcQPZyRol1cyaBFfEKaEt03H3GDGKzCKhK3P7bC9bAJmAhcfNHI5gt KhAscWPZITaIekGJkzOfsIDYIgLqEpcfXgCbIyxgILHo+V3GLkYOoMXiEj2NQSBhZgE9iSlX WxghbHmJ5q2zmSHu0ZZoaOpgncDIPwvJ1FlIWmYhaVnAyLyKkaM4tTgpN93IYBMjMJwObvlt sYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC8+r0j9GybezX/ BZO7W5zTRV6HdR2wSZctCDn19cVcu1zzgjUrWUIzFs3Y+PaRV+TT02+evFDq4HHT02Ff/Pln 3+3Zrg0R/5bat7g4cbqemp6xJCru1SrGP6WuV7mOL74f53/xWrH1em1Gfcf9PRapzIzf9Jqm ck9Z+TMwrlVi0i727Tu/WIoqsRRnJBpqMRcVJwIAmH2cD/UBAAA=
Subject: [rtcweb] RTP Simulcast proposal has been updated
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 07:38:17 -0000

RTCWEB,

My co-authors and I have updated the proposal for how to do Simulcast in
RTP so that it supports Unified Plan for SDP. Thus we can support single
media source per media description with multiple simulcast encodings.
It also support multiple sources per media description for
broadcast/simulcast as well as "legacy" usages where the simulcast
encoding versions are distributed across different media descriptions in
SDP. Thus simulcast within one as well as using multiple RTP sessions
(and thus transports) are supported.

This update also focuses the SRCNAME SDES item proposal to the need of
simulcast. SRCNAME is used to identify the relationship between an SSRC
and the media source and particular encoding carried. To speed up
acquisition we are proposing an generic SDES item RTP Header extension
to enable inclusion of the SRCNAME item in RTP headers at startup.

The proposal consists of three I-Ds and we will discuss the general
signalling and setup/negotiation in MMUSIC and the SRCNAME and the
header extension is requested to be presented in AVTEXT WG.

https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/
https://datatracker.ietf.org/doc/draft-westerlund-avtext-sdes-hdr-ext/
https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/

Feedback much appreciated

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From christer.holmberg@ericsson.com  Thu Oct 24 00:46:19 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBC611E82F9 for ; Thu, 24 Oct 2013 00:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.458
X-Spam-Level: 
X-Spam-Status: No, score=-5.458 tagged_above=-999 required=5 tests=[AWL=0.491,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjaTG4qc4dA9 for ; Thu, 24 Oct 2013 00:46:14 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BF57211E8127 for ; Thu, 24 Oct 2013 00:46:09 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-4d-5268d0403017
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 52.9C.03802.040D8625; Thu, 24 Oct 2013 09:46:08 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 09:46:07 +0200
From: Christer Holmberg 
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] New SDP O/A required if selected ICE candidate does not	match c= line?
Thread-Index: AQHO0FJsqX3+IV6yiUKjiqhtLlH1CJoDeHvQ
Date: Thu, 24 Oct 2013 07:46:07 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EF749@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.20]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvja7DhYwgg77jhhbT99lYrP3Xzu7A 5HGu4T27x5IlP5kCmKK4bFJSczLLUov07RK4Mj7uWc1Y8EGg4sDlDywNjDsEuhg5OSQETCQe vHrOCGGLSVy4t56ti5GLQ0jgMKPE7Wm/oZwljBK/v6wGquLgYBOwkOj+pw3SICKQLPGo4zgr iC0sECfx9ck/Noh4vETDk4mMELaRxJlbE8DiLAKqEnOO/QKzeQV8JQ4294GNFBIIkLi5IBsk zCkQKHGpHWIMI9A930+tYQKxmQXEJW49mc8EcaeAxJI955khbFGJl4//sULYihJXpy9nAhnJ LKApsX6XPkSrosSU7ofsEFsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypG9tzEzJz0cqNN jMAYOLjlt+oOxjvnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsYNf /dmHnwZnOPV0orOXLf/YvCP2xaqGGYyOrTvelrGt7/X7tbJsc5XZq75dF+pntoau2mTkIhQj qBcpFzKPIy03v3CjqsTr2Fk/mqTt+if3cvuJ2RRLSc/cWlX7+Ez11yC3+hOVSVmxiavP/Zc/ Is58LPHCu8dmUSo7V6uJsXz4tHdXQa2mEktxRqKhFnNRcSIAb9qcjU8CAAA=
Subject: Re: [rtcweb] New SDP O/A required if selected ICE candidate does not	match c= line?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 07:46:19 -0000

SGksDQoNCklmIHlvdSB1c2UgQlVORExFLCB5b3UnbGwgbmVlZCBhIHNlY29uZCBTRFAgTy9BIHRv
ICJmaXggdGhlIHBvcnQiIChhc3N1bWluZyB0aGUgZmlyc3QgU0RQIE8vQSBjb250YWlucyB1bmlx
dWUgcG9ydHMgZm9yIGVhY2ggbS0gbGluZSkuIEl0IGRvZXNuJ3QgaGF2ZSB0byBiZSB0aGUgc2Ft
ZSBTRFAgTy9BIHdoaWNoICJmaXhlcyB0aGUgYz1saW5lIiBmb3IgSUNFLCBidXQgaXQgY2FuIGJl
Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIEnDsWFraSBCYXogQ2FzdGlsbG8NClNlbnQ6IDI0LiBsb2tha3V1
dGEgMjAxMyAzOjQ1DQpUbzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBOZXcg
U0RQIE8vQSByZXF1aXJlZCBpZiBzZWxlY3RlZCBJQ0UgY2FuZGlkYXRlIGRvZXMgbm90IG1hdGNo
IGM9IGxpbmU/DQoNCkhpLCBSRkMgNTI0NSAoSUNFKSBzYXlzOg0KDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KICA0LjEuNC4gIENob29zaW5nIERlZmF1bHQgQ2FuZGlkYXRlcw0KDQog
ICBBIGNhbmRpZGF0ZSBpcyBzYWlkIHRvIGJlIGRlZmF1bHQgaWYgaXQgd291bGQgYmUgdGhlIHRh
cmdldCBvZiBtZWRpYQ0KICAgZnJvbSBhIG5vbi1JQ0UgcGVlcjsgdGhhdCB0YXJnZXQgaXMgY2Fs
bGVkIHRoZSBERUZBVUxUIERFU1RJTkFUSU9OLg0KICAgSWYgdGhlIGRlZmF1bHQgY2FuZGlkYXRl
cyBhcmUgbm90IHNlbGVjdGVkIGJ5IHRoZSBJQ0UgYWxnb3JpdGhtIHdoZW4NCiAgIGNvbW11bmlj
YXRpbmcgd2l0aCBhbiBJQ0UtYXdhcmUgcGVlciwgYW4gdXBkYXRlZCBvZmZlci9hbnN3ZXIgd2ls
bCBiZQ0KICAgcmVxdWlyZWQgYWZ0ZXIgSUNFIHByb2Nlc3NpbmcgY29tcGxldGVzIGluIG9yZGVy
IHRvICJmaXggdXAiIHRoZSBTRFANCiAgIHNvIHRoYXQgdGhlIGRlZmF1bHQgZGVzdGluYXRpb24g
Zm9yIG1lZGlhIG1hdGNoZXMgdGhlIGNhbmRpZGF0ZXMNCiAgIHNlbGVjdGVkIGJ5IElDRS4gIElm
IElDRSBoYXBwZW5zIHRvIHNlbGVjdCB0aGUgZGVmYXVsdCBjYW5kaWRhdGVzLCBubw0KICAgdXBk
YXRlZCBvZmZlci9hbnN3ZXIgaXMgcmVxdWlyZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCg0KSGF2aW5nIHRvIHBlcmZvcm0gYSBzZWNvbmQgU0RQIE8vQSBqdXN0IHRvICJmaXgg
dGhlIGM9IGxpbmUiIHNlZW1zIHRlcnJpYmxseSBhbm5veWluZyBhbmQgdW51c2VmdWwgSU1ITy4g
U2FpZCB0aGF0LCB0aGlzIGlzIG9idmlvdXNseSAidmlvbGF0ZWQiIGJ5IFdlYlJUQyBicm93c2Vy
cywgcmlnaHQ/DQoNClRoYW5rcyBhIGxvdC4NCg0KDQoNCi0tDQpJw7Fha2kgQmF6IENhc3RpbGxv
DQo8aWJjQGFsaWF4Lm5ldD4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo=

From Markus.Isomaki@nokia.com  Thu Oct 24 01:36:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AC221E808E for ; Thu, 24 Oct 2013 01:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhKBHVvd5ucC for ; Thu, 24 Oct 2013 01:36:02 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4A11E816D for ; Thu, 24 Oct 2013 01:36:01 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.20]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r9O8XXxc014640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 24 Oct 2013 11:33:35 +0300
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.235]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.03.0136.001; Thu, 24 Oct 2013 08:33:33 +0000
From: 
To: , 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0DI6RcO5ZGLqUUag+6tiIuKaVJoCxtMAgACrWtA=
Date: Thu, 24 Oct 2013 08:33:33 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<526837B5.8020507@bbs.darktech.org> <52683A1C.1090506@librevideo.org>
In-Reply-To: <52683A1C.1090506@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiWc+o8hXFUdLEV0dd3jRi9ZSnsyh2XxM9weacZlWDiXp2iugdu9/GeoD1NA6FKLHcwaKBRAiccUJ0MNT8h9MBXc/rgYtLrRsB5pMO+FxzwPovcKyyYUD6X9TbWJu8NgcZi7McFgkluASQ00lfICVg6apNxFMnyGEEuExlpdykNE18BSUlOpvQLyhfy/vKX6vQk6IExW9utbu+gZQFMDBmthSHLcbECFAcwYBHig4JX1
x-originating-ip: [10.236.14.120]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 08:36:10 -0000

Hi,

Basil Mohamed Gohar wrote:
>=20
> For starters, there is no evidence whatsoever that there is a viable IPR
> concern with VP8, but there exist baseless allegations.  In fact, what li=
ttle
> doubt that there might have been one was settled by the agreement signed
> between Google and MPEG-LA [1] a short while ago, which resulted in
> MPEG-LA withdrawing their attempt a forming a patent pool for VP8
> altogether.  An attempt, I might add, that had little public activity sav=
e for its
> initial announcement once VP8 was being concerned for international
> standards.  In fact, the extremely generous terms of the agreement lend
> credence to the fact that there was little that existing that would have =
been
> enforceable.
>

Please remember that Nokia has submitted an IPR declaration about VP8:
https://datatracker.ietf.org/ipr/2035/
=20
VP8 has been proposed as basis for standardization in MPEG. If that proceed=
s, there will be points in the process where companies need to make IPR dec=
larations (RF, RAND, or neither). In that case we would eventually know mor=
e about VP8 IPR status than what is currently in public.=20

> Furthermore, the fact that there is an existing licensing structure for
> H.264 give exactly zero assurances of protections from IPR claims, becaus=
e
> not all licensors of H.264 technology are a member of the MPEG-LA patent
> pool agreement, and there have been numerous patent cases related to
> H.264 and other technologies thought to be covered by RAND and FRAND
> terms.
>

The H.264 RAND/FRAND commitments do not depend on MPEG-LA membership but st=
em from the MPEG IPR rules and declarations.=20

Markus=20
=20

From bo.burman@ericsson.com  Thu Oct 24 01:49:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE9611E817C for ; Thu, 24 Oct 2013 01:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.541
X-Spam-Level: 
X-Spam-Status: No, score=-5.541 tagged_above=-999 required=5 tests=[AWL=0.708,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDXSJM47Pjqb for ; Thu, 24 Oct 2013 01:49:28 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A89EA11E815F for ; Thu, 24 Oct 2013 01:49:27 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-95-5268df1673e9
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 21.BE.16099.61FD8625; Thu, 24 Oct 2013 10:49:26 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 10:49:26 +0200
From: Bo Burman 
To: Basil Mohamed Gohar , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - subjective evaluation
Thread-Index: AQHOzxEKlOG7izy4cUOGF4TPALArv5oBUUGAgACCLoCAAFV7AIABWRCw
Date: Thu, 24 Oct 2013 08:49:25 +0000
Message-ID: 
References: <52665274.9080705@alvestrand.no> <52671AF7.5040107@librevideo.org>	<5267882B.4060906@alvestrand.no> <5267CFE0.6040300@librevideo.org>
In-Reply-To: <5267CFE0.6040300@librevideo.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvja7Y/Ywgg9l9hhYPPm5mtVj7r53d gcljyZKfTB7Nr68zBTBFcdmkpOZklqUW6dslcGU8PXiDreCjcMWWA3uZGhi7BboYOTkkBEwk mn5/YIKwxSQu3FvP1sXIxSEkcJhRomPjChaQhJDAIkaJK8vKQGw2AQ2J+TvuMoLYIgJREs/a O9hBbGEBK4l7cy6ydjFyAMWtJZatK4QocZM4/G8jK4jNIqAqsfHfJrBdvAK+Enu3T2CE2DWV UWLOuV9sIAlOAT2Jxw1HwOYzCshK3P9+D+wGZgFxiVtP5kMdKiCxZM95ZghbVOLl43+sELai xNXpy5kg6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03 MTMnvdxwEyMwFg5u+a27g/HUOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYKyybDI6KLuFT1XzRmqyk+3plQ+/zI3fezn3T7vxrJlcbywP+HrVFmsaeW12/2GyI631 vpTsvq7lS199KfNjOHyHJ1xzjVOlmaqjvjfrl3/Hwm88SDkYNqXcKq9Ln5FRQUzjyLkp+QKV ok1lS2XOO3Mevhrfdeodm8isPbO5M94Wxm7ZY9t2UomlOCPRUIu5qDgRAPnu825TAgAA
Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 08:49:33 -0000

It is really difficult to at all comment on this since there is far too lit=
tle data available. There is no way to review the settings and parameters u=
sed, and of course no way to repeat the tests, and hopefully our previous i=
nputs related to objective quality evaluation has made it clear to everyone=
 that parameter settings make a huge difference.

It can also be noted that even if the results are assumed to be correct (wh=
ich there is currently no way to verify) the conclusions drawn seem incorre=
ct. E.g., it is stated that "In 7/10 sequences tested VP8 LD was clearly be=
tter than AVC constrained baseline", but when examining the plots the confi=
dence intervals seem to be overlapping.

Without any more information it can only be concluded that this test has ve=
ry little value.

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of Basil Mohamed Gohar
> Sent: den 23 oktober 2013 15:32
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation
>=20
> On 10/23/2013 04:26 AM, Harald Alvestrand wrote:
> > On 10/23/2013 02:40 AM, Basil Mohamed Gohar wrote:
> >> On 10/22/2013 06:24 AM, Harald Alvestrand wrote:
> >>> In my VP8 advocate draft, I referred to a subjective evaluation test
> >>> (test with actual human viewers) done between VP8 and H.264 Baseline
> >>> by a neutral
> >>> (non-Google) laboratory.
> >>>
> >>> The attached presentation is the writeup of the results of that test.
> >>>
> >> Are the sources used in the video comparison test available anywhere?
> >>
> > They are under an MPEG license, so they're freely available to MPEG
> > members for use in developing MPEG standards. If you fall within that
> > category, I can send you the FTP server and password.
> >
> > MPEG doesn't have the tradition of open materials that the IETF has.
> >
>=20
> Well, that's unfortunate.  Thanks for clarifying, though.
>=20
> It would be nice if, when time permits, a similar test can be made, using=
 the same criteria (encoding parameters, etc.),
> but with known clips (e.g., from derf's collection, which has everything,=
 including both SD and HD clips).  Publishing the
> versions and exact encoding parameters (including command line usage) wou=
ld be helpful to that aim, I suppose.
>=20
> --
> Libre Video
> http://librevideo.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From thomas.stach@unify.com  Thu Oct 24 03:09:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AED611E8306 for ; Thu, 24 Oct 2013 03:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaXbds6ahy2K for ; Thu, 24 Oct 2013 03:09:06 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE4C11E830C for ; Thu, 24 Oct 2013 03:09:05 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9602823F053E; Thu, 24 Oct 2013 12:09:03 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 24 Oct 2013 12:09:14 +0200
From: "Stach, Thomas" 
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] New SDP O/A required if selected ICE candidate does not	match c= line?
Thread-Index: AQHO0FJ3OvcjsOJIHkqPZrs7TFyuwpoDn6tw
Date: Thu, 24 Oct 2013 10:09:02 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [rtcweb] New SDP O/A required if selected ICE candidate does not	match c= line?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 10:09:10 -0000

ScOxYWtpLA0KDQppbiB0aGUgcGFzdCBzb21lIHRob3VnaHRzIHdlcmUgYWxyZWFkeSBwcmVzZW50
ZWQgdGhhdCB0aGUgdXBkYXRlZCBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGlzIG5vdCBuZWNl
c3NhcnkgaW4gYWxsIGVudmlyb25tZW50cy4NClNlZSBlLmcuIGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1yb3NlbmJlcmctbW11c2ljLWljZS1ub25zaXAtMDEjc2VjdGlvbi01LjQu
MiBhcyBjaXRlZCBiZWxvdzoNCg0K4oCcSUNFIGRlZmluZXMgY29uZGl0aW9ucyBvbiB3aGljaCBh
biB1cGRhdGVkIG9mZmVyIGlzIHJlcXVpcmVkIHRvIGJlIHNlbnQgYWZ0ZXIgSUNFIGNvbmNsdWRl
cyAtIG5hbWVseSwgaWYgdGhlIGNhbmRpZGF0ZXMgc2VsZWN0ZWQgYnkgSUNFIGFyZSBub3QgYSBt
YXRjaCBmb3IgdGhlIGRlZmF1bHQgY2FuZGlkYXRlcywgYW4gdXBkYXRlZCBleGNoYW5nZSBpcyBz
ZW50Lg0KVGhpcyBmdW5jdGlvbiBvZiBJQ0UgaXMgcHJpbWFyaWx5IGFuIGFydGlmYWN0IG9mIHRo
ZSByZWFsaXRpZXMgb2YgU0lQIGRlcGxveW1lbnRzLiBJdCBpcyBub3QgYXQgYWxsIG5lZWRlZCBm
b3IgY29ycmVjdG5lc3Mgb2YgSUNFIG9wZXJhdGlvbi4gSW4gdGhlIGNhc2Ugb2YgU0lQLCBzaWdu
YWxpbmcgaW50ZXJtZWRpYXJpZXMgdGhhdCBhcmUgaW5zcGVjdGluZyB0aGUgb2ZmZXIvYW5zd2Vy
IGV4Y2hhbmdlcywgYnV0IGFyZSBub3QgSUNFIGF3YXJlLCB3aWxsIGJlIGNvbmZ1c2VkIHVubGVz
cyB0aGVyZSBpcyBhbiB1cGRhdGVkIGV4Y2hhbmdlLiBUaGlzIHNhbWUgY29uc2lkZXJhdGlvbiBh
cHBsaWVzIHRvIHVzaW5nIHByb3RvY29scy4gSWYgdGhlIHVzaW5nIHByb3RvY29sIGhhcyBkZXBs
b3ltZW50cyB3aXRoIGludGVybWVkaWFyaWVzIHRoYXQgaW5zcGVjdCBtZXNzYWdlcywgYW5kIHdp
bGwgYmUgY29uZnVzZWQgaWYgdGhlIGFjdHVhbCBjb25uZWN0aW9ucy9tZWRpYSBhcmUgZXN0YWJs
aXNoZWQgdG8gc29tZXRoaW5nIGRpZmZlcmVudCB0aGFuIGFueSBkZWZhdWx0cyB0aGF0IHdlcmUg
c2lnbmFsZWQsIHRoZSB1cGRhdGVkIGV4Y2hhbmdlIHNob3VsZCBiZSB1c2VkLiBJZiBub3QsIGl0
IGNhbiBiZSBhdm9pZGVkLuKAnQ0KDQpJIHRoaW5rIHRoYXQgaW4gYSBwdXJlIFdlYlJUQyBlbnZp
cm9ubWVudCB0aGUgc2Vjb25kIE8vQSBjYW4gYmUgb21pdHRlZC4gDQoNClJlZ2FyZHMNClRob21h
cyANCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Y3dlYi1ib3Vu
Y2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFs
ZiBPZiBJw7Fha2kgQmF6IENhc3RpbGxvDQo+IFNlbnQ6IERvbm5lcnN0YWcsIDI0LiBPa3RvYmVy
IDIwMTMgMDI6NDUNCj4gVG86IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbcnRjd2ViXSBO
ZXcgU0RQIE8vQSByZXF1aXJlZCBpZiBzZWxlY3RlZCBJQ0UgY2FuZGlkYXRlIGRvZXMNCj4gbm90
IG1hdGNoIGM9IGxpbmU/DQo+IA0KPiBIaSwgUkZDIDUyNDUgKElDRSkgc2F5czoNCj4gDQo+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgNC4xLjQuICBDaG9vc2luZyBEZWZhdWx0
IENhbmRpZGF0ZXMNCj4gDQo+ICAgIEEgY2FuZGlkYXRlIGlzIHNhaWQgdG8gYmUgZGVmYXVsdCBp
ZiBpdCB3b3VsZCBiZSB0aGUgdGFyZ2V0IG9mIG1lZGlhDQo+ICAgIGZyb20gYSBub24tSUNFIHBl
ZXI7IHRoYXQgdGFyZ2V0IGlzIGNhbGxlZCB0aGUgREVGQVVMVCBERVNUSU5BVElPTi4NCj4gICAg
SWYgdGhlIGRlZmF1bHQgY2FuZGlkYXRlcyBhcmUgbm90IHNlbGVjdGVkIGJ5IHRoZSBJQ0UgYWxn
b3JpdGhtIHdoZW4NCj4gICAgY29tbXVuaWNhdGluZyB3aXRoIGFuIElDRS1hd2FyZSBwZWVyLCBh
biB1cGRhdGVkIG9mZmVyL2Fuc3dlciB3aWxsDQo+IGJlDQo+ICAgIHJlcXVpcmVkIGFmdGVyIElD
RSBwcm9jZXNzaW5nIGNvbXBsZXRlcyBpbiBvcmRlciB0byAiZml4IHVwIiB0aGUgU0RQDQo+ICAg
IHNvIHRoYXQgdGhlIGRlZmF1bHQgZGVzdGluYXRpb24gZm9yIG1lZGlhIG1hdGNoZXMgdGhlIGNh
bmRpZGF0ZXMNCj4gICAgc2VsZWN0ZWQgYnkgSUNFLiAgSWYgSUNFIGhhcHBlbnMgdG8gc2VsZWN0
IHRoZSBkZWZhdWx0IGNhbmRpZGF0ZXMsDQo+IG5vDQo+ICAgIHVwZGF0ZWQgb2ZmZXIvYW5zd2Vy
IGlzIHJlcXVpcmVkLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEhh
dmluZyB0byBwZXJmb3JtIGEgc2Vjb25kIFNEUCBPL0EganVzdCB0byAiZml4IHRoZSBjPSBsaW5l
IiBzZWVtcw0KPiB0ZXJyaWJsbHkgYW5ub3lpbmcgYW5kIHVudXNlZnVsIElNSE8uIFNhaWQgdGhh
dCwgdGhpcyBpcyBvYnZpb3VzbHkNCj4gInZpb2xhdGVkIiBieSBXZWJSVEMgYnJvd3NlcnMsIHJp
Z2h0Pw0KPiANCj4gVGhhbmtzIGEgbG90Lg0KPiANCj4gDQo+IA0KPiAtLQ0KPiBJw7Fha2kgQmF6
IENhc3RpbGxvDQo+IDxpYmNAYWxpYXgubmV0Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBp
ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K

From ibc@aliax.net  Thu Oct 24 03:56:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CC311E817A for ; Thu, 24 Oct 2013 03:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyPHdE2OHbbK for ; Thu, 24 Oct 2013 03:56:30 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE3711E812D for ; Thu, 24 Oct 2013 03:56:30 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id cm18so4918941qab.3 for ; Thu, 24 Oct 2013 03:56:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=5DlsC+7lzSUzv9Gmrmz10m+6Fxjw9lz7B5aicVgAjoU=; b=gUwsL28SwtlmuaXrLVltdSEvHfod/QesVBixcTxB7QdmtUcC8b65O5Onsgt4a9yIw7 vt4lfExngvufhzFAteOhVOI6G4Y2DEp0zk4KVDlgjOUkraeGuoFphVcRb15gC9lUi8k9 CN0TlvAdq/ZikHvdqQ8sGQBLm0yV3F/zkqTaE4Z/VvTQdf6vmB19+sy1lZav09qX5gHE dBgxp/jWZP1SvGSy06mIyGWQggkGNG2CycAYUZsfSu07NhM/DRWO1NibQoMTqTaHb6lk r7jfdXsEFKgKTZf6R7g60BjEUf8CgbUlfzZIOTH4zR6eCBPGAx/58a+FkBsnpnecYvQR OOGg==
X-Gm-Message-State: ALoCoQmVK+EF5ej+Rtf4BRVcEcLs/6hJoUxCJgPkgIPJY3uJIVtuuY3+uM+ZIEkpQyJeaCvZmUeE
X-Received: by 10.229.73.6 with SMTP id o6mr2513219qcj.2.1382612189752; Thu, 24 Oct 2013 03:56:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.71.8 with HTTP; Thu, 24 Oct 2013 03:56:08 -0700 (PDT)
In-Reply-To: 
References:  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 24 Oct 2013 12:56:08 +0200
Message-ID: 
To: "Stach, Thomas" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] New SDP O/A required if selected ICE candidate does not match c= line?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 10:56:34 -0000

2013/10/24 Stach, Thomas :
> I=C3=B1aki,
>
> in the past some thoughts were already presented that the updated SDP off=
er/answer exchange is not necessary in all environments.
> See e.g. https://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01=
#section-5.4.2 as cited below:
>
> =E2=80=9CICE defines conditions on which an updated offer is required to =
be sent after ICE concludes - namely, if the candidates selected by ICE are=
 not a match for the default candidates, an updated exchange is sent.
> This function of ICE is primarily an artifact of the realities of SIP dep=
loyments. It is not at all needed for correctness of ICE operation. In the =
case of SIP, signaling intermediaries that are inspecting the offer/answer =
exchanges, but are not ICE aware, will be confused unless there is an updat=
ed exchange. This same consideration applies to using protocols. If the usi=
ng protocol has deployments with intermediaries that inspect messages, and =
will be confused if the actual connections/media are established to somethi=
ng different than any defaults that were signaled, the updated exchange sho=
uld be used. If not, it can be avoided.=E2=80=9D
>
> I think that in a pure WebRTC environment the second O/A can be omitted.


So, basically such a "SDP fix up" is 100% unnecesary for SIP endpoints
in the session, and just "useful" for intermediary servers to know
which media path is being used. IMHO RFC 5245 should NOT state that at
all.

Thanks a lot for the clarification.

--=20
I=C3=B1aki Baz Castillo


From keith.drage@alcatel-lucent.com  Thu Oct 24 04:05:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00711E8318 for ; Thu, 24 Oct 2013 04:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.567
X-Spam-Level: 
X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txTlx+FspwcL for ; Thu, 24 Oct 2013 04:05:29 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CB11E82D5 for ; Thu, 24 Oct 2013 04:05:28 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9OB5LPV020136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Oct 2013 06:05:23 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9OB5HTn019921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 13:05:20 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 24 Oct 2013 13:05:20 +0200
From: "DRAGE, Keith (Keith)" 
To: Silvia Pfeiffer , Basil Mohamed Gohar 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0CDs3TqGWYrUlUulPtrUXYOsppoCjkaAgAAUTICAAALdAIAAC1MAgAD9uDA=
Date: Thu, 24 Oct 2013 11:05:19 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BE4E2@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<526837B5.8020507@bbs.darktech.org> <52683A1C.1090506@librevideo.org> 
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
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 11:05:36 -0000

"requires all IPR holders on a technology that is made part of an RFC to di=
sclose"

Is not what the document actually says.

If you are going to attribute please attribute correctly.=20

Regards

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Silvia Pfeiffer
> Sent: 23 October 2013 22:46
> To: Basil Mohamed Gohar
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
>=20
> On Thu, Oct 24, 2013 at 8:05 AM, Basil Mohamed Gohar=20
>  wrote:
> > On 10/23/2013 04:55 PM, cowwoc wrote:
> >> Harald,
> >>
> >>     I think it is premature to imply that VP8 is royalty=20
> free. I have=20
> >> nothing against the codec (it's great) but it's my=20
> understanding that=20
> >> Google can't guarantee that someone else won't exercise IPR rights=20
> >> against VP8 in the future. The best we can say is that=20
> H264 requires=20
> >> royalties today and VP8 *might* require royalties in the=20
> future. H264=20
> >> has a slight advantage in this space in that we have=20
> well-understood=20
> >> licensing terms.
> >>
> >>     I just wanted to put that out there so there are no=20
> confusions in=20
> >> the future.
> >>
> >> Gili
> >
> > Actually, this is exactly the kind of FUD that has stifled the=20
> > adoption of VP8 and, before it, Theora and Vorbis, as=20
> > universally-available multimedia format.  It serves only to confuse=20
> > the issue further, as I will explain below.
> >
> > For starters, there is no evidence whatsoever that there is=20
> a viable=20
> > IPR concern with VP8, but there exist baseless allegations.=20
>  In fact,=20
> > what little doubt that there might have been one was settled by the=20
> > agreement signed between Google and MPEG-LA [1] a short while ago,=20
> > which resulted in MPEG-LA withdrawing their attempt a=20
> forming a patent=20
> > pool for VP8 altogether.  An attempt, I might add, that had little=20
> > public activity save for its initial announcement once VP8=20
> was being=20
> > concerned for international standards.  In fact, the extremely=20
> > generous terms of the agreement lend credence to the fact=20
> that there=20
> > was little that existing that would have been enforceable.
> >
> > Furthermore, the fact that there is an existing licensing structure=20
> > for
> > H.264 give exactly zero assurances of protections from IPR claims,=20
> > because not all licensors of H.264 technology are a member of the=20
> > MPEG-LA patent pool agreement, and there have been numerous patent=20
> > cases related to H.264 and other technologies thought to be=20
> covered by=20
> > RAND and FRAND terms.
> >
> > Finally, the current patent and IPR landscape, at least in=20
> the US, and=20
> > widely in other portions of the world, eliminates the=20
> possibility of=20
> > something *never* being under a patent threat, due to the=20
> presence of=20
> > patent trolls that actively wait for adoption as well the sheer=20
> > magnitude of patents and the very ease with which patent=20
> legislation=20
> > can be brought up (including for those already "covered" by=20
> existing=20
> > patent pools, e.g., H.264).
> >
> > So, in actuality, H.264 holds no advantage over VP8 in this regard,=20
> > and the claim that VP8 is a liability to use is not=20
> evidenced by any=20
> > actual unique tangible threat to date.
> >
> > [1] http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html
>=20
>=20
> On top of all this, it seems to me that
> http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders=20
> on a technology that is made part of an RFC to disclose their=20
> IPR and sign a patent disclosure:=20
> http://tools.ietf.org/html/rfc3905 . I think this process is=20
> trivial for VP8, but will require lengthy delays for sorting=20
> out for H.264. In the interest of the Internet Community,=20
> given that both codecs provide comparable quality at=20
> comparable bitrates, we need to choose what is best for the=20
> Internet community.
> RFC3979 even states this explicitly:
>=20
> " In all matters of Intellectual Property Rights, the intent is to
>    benefit the Internet community and the public at large, while
>    respecting the legitimate rights of others."
>=20
> It seems clear that given that there is no substantial=20
> technical difference between the two, given that the IRP=20
> situation is so much cleaner for VP8, and that the only known=20
> IPR holder for VP8 (ever after challenges) is Google who are=20
> providing a perpetual royalty-free license=20
> (http://www.webmproject.org/license/bitstream/), the=20
> preference of the Internet community must clearly lie with VP8.
>=20
> I would be surprised if the IESG - who has to consider IPR=20
> rights when approving an RFC for publication - wouldn't have=20
> to overrule any decision made by this WG to choose H.264 over VP8.
>=20
> RFC3979 states:
> " In general, IETF working groups prefer technologies with no=20
> known IPR
>    claims or, for technologies with claims against them, an offer of
>    royalty-free licensing."
>=20
>=20
> Best Regards,
> Silvia.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From harald@alvestrand.no  Thu Oct 24 04:12:25 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA4311E831C for ; Thu, 24 Oct 2013 04:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.523
X-Spam-Level: 
X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXLdxZwYtPdS for ; Thu, 24 Oct 2013 04:12:20 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 566B611E8315 for ; Thu, 24 Oct 2013 04:12:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DF3639E18D for ; Thu, 24 Oct 2013 13:12:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTtyCWjqlmuB for ; Thu, 24 Oct 2013 13:12:16 +0200 (CEST)
Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A535E39E031 for ; Thu, 24 Oct 2013 13:12:16 +0200 (CEST)
Message-ID: <52690090.2050609@alvestrand.no>
Date: Thu, 24 Oct 2013 13:12:16 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>
In-Reply-To: <526826AF.5030308@librevideo.org>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------080903010205000000020202"
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 11:12:25 -0000

This is a multi-part message in MIME format.
--------------080903010205000000020202
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:
> On 10/23/2013 02:51 PM, Harald Alvestrand wrote:
>> Just a reminder:
>> The back-and-forth of numbers doesn't change the core question of this
>> debate.
>> Both codecs are capable of high quality video encoding, and performance
>> numbers are comparable.
>>
>> The real core question is the IPR issue.
>>
>> The tradition of the IETF says that allowing only business models that
>> can sustain royalty agreements and royalty payments is Bad for the Internet.
>>
>> The dominant video codec, H.264, is a royalty-required codec.
>>
>> Do we switch now, or do we give up and live with royalties forever?
>>
> Harald,
>
> I would like to see some references to the tradition of the IETF that
> you've quoted.
>
> For the record, I agree with the sentiment, but I'd like to be able to
> back up the claim itself with references or explicit decisions that were
> made in that regard.  I'm not trying to be a thorn in your side, just
> looking for citations to back up the arguments, both on and off list.
>
Basil, very happy to provide references!

RFC 3979, a core document about IPR in the IETF, 2005:

8.  Evaluating Alternative Technologies in IETF Working Groups

   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.


The complete section gives some more details, but this is the central quote.

You may also enjoy reading the section of RFC 6569 (the guidelines that
were followed in the OPUS work) that deals with IPR:

http://tools.ietf.org/html/rfc6569#page-8




-- 
Surveillance is pervasive. Go Dark.


--------------080903010205000000020202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/23/2013 09:42 PM, Basil Mohamed
      Gohar wrote:

    

    

      
On 10/23/2013 02:51 PM, Harald Alvestrand wrote:


      

        
Just a reminder:
The back-and-forth of numbers doesn't change the core question of this
debate.
Both codecs are capable of high quality video encoding, and performance
numbers are comparable.

The real core question is the IPR issue.

The tradition of the IETF says that allowing only business models that
can sustain royalty agreements and royalty payments is Bad for the Internet.

The dominant video codec, H.264, is a royalty-required codec.

Do we switch now, or do we give up and live with royalties forever?



      

      
Harald,

I would like to see some references to the tradition of the IETF that
you've quoted.

For the record, I agree with the sentiment, but I'd like to be able to
back up the claim itself with references or explicit decisions that were
made in that regard.  I'm not trying to be a thorn in your side, just
looking for citations to back up the arguments, both on and off list.



    

    Basil, very happy to provide references!

    

    RFC 3979, a core document about IPR in the IETF, 2005:

    

    
    
8.  Evaluating Alternative Technologies in IETF Working Groups

   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.


    

    The complete section gives some more details, but this is the
    central quote.

    

    You may also enjoy reading the section of RFC 6569 (the guidelines
    that were followed in the OPUS work) that deals with IPR:

    

    
    http://tools.ietf.org/html/rfc6569#page-8

    

    

    

    

    
-- 
Surveillance is pervasive. Go Dark.


  


--------------080903010205000000020202--

From harald@alvestrand.no  Thu Oct 24 04:33:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D20211E8312 for ; Thu, 24 Oct 2013 04:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.528
X-Spam-Level: 
X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN1slBfn+Rfa for ; Thu, 24 Oct 2013 04:33:04 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9008B11E8240 for ; Thu, 24 Oct 2013 04:33:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4588839E18D for ; Thu, 24 Oct 2013 13:33:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UZxaJ6-XX+o for ; Thu, 24 Oct 2013 13:32:59 +0200 (CEST)
Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 027F539E031 for ; Thu, 24 Oct 2013 13:32:59 +0200 (CEST)
Message-ID: <5269056A.9060700@alvestrand.no>
Date: Thu, 24 Oct 2013 13:32:58 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52665274.9080705@alvestrand.no>	<52671AF7.5040107@librevideo.org>	<5267882B.4060906@alvestrand.no>	<5267CFE0.6040300@librevideo.org> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - subjective evaluation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 11:33:10 -0000

On 10/24/2013 10:49 AM, Bo Burman wrote:
> It is really difficult to at all comment on this since there is far too little data available. There is no way to review the settings and parameters used, and of course no way to repeat the tests, and hopefully our previous inputs related to objective quality evaluation has made it clear to everyone that parameter settings make a huge difference.

Bo, your organization is an MPEG member, so you can get the streams, and
the scripts used to produce them, any day you want.
I've sent you the login details to the server in separate mail.

The VP8 parameters were the ones used for the VP8 vs IVC comparision
presented in MPEG input documents to the Geneva MPEG meeting; I think
you will find the actual command lines either in the input documents or
in the attachments.

The AVC streams used were the ones produced for the initial MPEG
"royalty-free video codec" call for proposals 2 years back, using the JM
encoder; I don't know who produced them, it might even have been
Ericsson. I'd expect that you'd find the encoding parameters used in
those documents.

If you want to repeat the tests, feel very free to hire your own
independent laboratory to do so - Vittorio's evaluation methods are very
well known in the MPEG community.

We have absolutely no interest in keeping anything secret here - the
only reason it's not all in the open is because of MPEG rules about
access to documents and test sequences!

>
> It can also be noted that even if the results are assumed to be correct (which there is currently no way to verify) the conclusions drawn seem incorrect. E.g., it is stated that "In 7/10 sequences tested VP8 LD was clearly better than AVC constrained baseline", but when examining the plots the confidence intervals seem to be overlapping.

I'm not sure what you are looking at - could you identify the slides
where you see overlapping confidence intervals between the red line (VP8
LD) and the green line (AVC constrained baseline)?

>
> Without any more information it can only be concluded that this test has very little value.

As I've noted in another thread, discussions about quality seem to have
very little value anyway, since there's nobody who's said that they will
change their mind if they get some new quality information. But we had
this evaluation already, so sharing information with the community
seemed to be the community-minded thing to do.

-- 
Surveillance is pervasive. Go Dark.


From bo.burman@ericsson.com  Thu Oct 24 06:26:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0FC11E8193 for ; Thu, 24 Oct 2013 06:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.816
X-Spam-Level: 
X-Spam-Status: No, score=-3.816 tagged_above=-999 required=5 tests=[AWL=-1.218, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PGCkM36Rpar for ; Thu, 24 Oct 2013 06:26:33 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4761011E8153 for ; Thu, 24 Oct 2013 06:26:32 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-19-526920079415
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 07.2D.09019.70029625; Thu, 24 Oct 2013 15:26:31 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 15:26:31 +0200
From: Bo Burman 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0CDhJVyL5itEmEWrISFOF+nwVJoCjkaAgAEDvACAAEBxAA==
Date: Thu, 24 Oct 2013 13:26:30 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>
In-Reply-To: <52690090.2050609@alvestrand.no>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22DFCD683ESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+JvjS67QmaQwZJZyhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDL2LLzLVLAos2L5571sDYzzoroYOTkkBEwk rq3cxgphi0lcuLeerYuRi0NI4CijxPx1HVDOIkaJrZ+msoBUsQloSMzfcZcRxBYRCJboff4e zBYWMJZY8vc6E0TcROL/ox4o20liyc9fYBtYBFQlfh++DjSHg4NXwFfi7nZtkLCQQKHEv1tv wMZwCuhK7D4IMZJRQFbi/vd7YGuZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/9BPaAocXX6ciaI +nyJe/++gPXyCghKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDF FzCyr2LkKE4tTspNNzLYxAiMnoNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGJ0096o//XElzEX0VmIxA8+8lRt0+BJsNtiXdk79wCQrzHjf61yqw566 vxcNBfavYe2LtF3tfOFN1ZOGOct/Mi3ScNliKFpyYqdGT8isdVd33XkapLp7088X52a4OFYZ vjyk8+njr5f3SySnLonWtdv1Jod76h1Dh9C9uX4lCqa9fDND3ATOL1FiKc5INNRiLipOBABl eB+ObAIAAA==
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 13:26:37 -0000

--_000_BBE9739C2C302046BD34B42713A1E2A22DFCD683ESESSMB105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

1) We do agree that H.264 Constrained Baseline and VP8 are comparable in te=
rms of video quality. But do not forget that Constrained Baseline's twin si=
ster H.264 Constrained High outperforms VP8 by a huge margin. This is also =
relevant.

2) The "back-and forth of numbers" seems to refer to Ericsson's work where =
we tried to make a fair comparison to evaluate the extraordinary claims fro=
m Google that VP8 is 70 or 40 percent better than x264. We found serious is=
sues with the way Google performed the test, maybe the most striking were t=
he use of padding (+8% for x264) and excessive number of threads (+10% to +=
40% for x264) to add overhead to x264. That Google managed to remember the =
threading parameter only when it helped
VP8 (the speed test) is also quite remarkable.

3) Regarding IPR, this is a difficult topic, but we're not at all convinced=
 that VP8 is royalty free. For example, there is an IETF IPR disclosure (ht=
tps://datatracker.ietf.org/ipr/2035/) where the IPR holder seems unwilling =
to license (on any terms), and http://www.fosspatents.com/2013/06/german-vp=
8-infringement-cases-show.html and http://www.fosspatents.com/2013/06/itc-i=
nstitutes-investigation-of-nokias.html show that there are in fact ongoing =
litigations regarding VP8 - and this is only skimming the surface of what i=
s available in public space.

/Bo

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Harald Alvestrand
Sent: den 24 oktober 2013 13:12
To: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:

On 10/23/2013 02:51 PM, Harald Alvestrand wrote:

Just a reminder:

The back-and-forth of numbers doesn't change the core question of this

debate.

Both codecs are capable of high quality video encoding, and performance

numbers are comparable.



The real core question is the IPR issue.



The tradition of the IETF says that allowing only business models that

can sustain royalty agreements and royalty payments is Bad for the Internet=
.



The dominant video codec, H.264, is a royalty-required codec.



Do we switch now, or do we give up and live with royalties forever?





Harald,



I would like to see some references to the tradition of the IETF that

you've quoted.



For the record, I agree with the sentiment, but I'd like to be able to

back up the claim itself with references or explicit decisions that were

made in that regard.  I'm not trying to be a thorn in your side, just

looking for citations to back up the arguments, both on and off list.


Basil, very happy to provide references!

RFC 3979, a core document about IPR in the IETF, 2005:



8.  Evaluating Alternative Technologies in IETF Working Groups



   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.

The complete section gives some more details, but this is the central quote=
.

You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:

http://tools.ietf.org/html/rfc6569#page-8






--

Surveillance is pervasive. Go Dark.

--_000_BBE9739C2C302046BD34B42713A1E2A22DFCD683ESESSMB105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











1) We do agree that H.264=
 Constrained Baseline and VP8 are comparable in terms of video quality. But=
 do not forget that Constrained Baseline's twin sister H.264
 Constrained High outperforms VP8 by a huge margin. This is also relevant.<=
o:p>


 <=
/p>

2) The "back-and for=
th of numbers" seems to refer to Ericsson's work where we tried to mak=
e a fair comparison to evaluate the extraordinary claims from Google
 that VP8 is 70 or 40 percent better than x264. We found serious issues wit=
h the way Google performed the test, maybe the most striking were the use o=
f padding (+8% for x264) and excessive number of threads (+10% to &=
#43;40% for x264) to add overhead to x264. That
 Google managed to remember the threading parameter only when it helped


VP8 (the speed test) is a=
lso quite remarkable.


 <=
/p>

3) Regarding IPR, this is=
 a difficult topic, but we're not at all convinced that VP8 is royalty free=
. For example, there is an IETF IPR disclosure (https://datatracker.ietf.org/ipr/2035/)
 where the IPR holder seems unwilling to license (on any terms), and 
http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html<=
/a> and

http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.h=
tml show that there are in fact ongoing litigations regarding VP8 - and=
 this is only skimming the surface of what is available in public space.


 <=
/p>

/Bo


 <=
/p>







From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ie=
tf.org]
On Behalf Of Harald Alvestrand

Sent: den 24 oktober 2013 13:12

To: rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 




On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:






On 10/23/2013 02:51 PM, Harald Alvestrand wrote:




Just a reminder:


The back-and-forth of numbers doesn't change the core question of this=



debate.


Both codecs are capable of high quality video encoding, and performanc=
e


numbers are comparable.


 


The real core question is the IPR issue.


 


The tradition of the IETF says that allowing only business models that=



can sustain royalty agreements and royalty payments is Bad for the Int=
ernet.


 


The dominant video codec, H.264, is a royalty-required codec.


 


Do we switch now, or do we give up and live with royalties forever?


 




 


Harald,


 


I would like to see some references to the tradition of the IETF that<=
o:p>


you've quoted.


 


For the record, I agree with the sentiment, but I'd like to be able to=



back up the claim itself with references or explicit decisions that we=
re


made in that regard.  I'm not trying to be a thorn in your side, =
just


looking for citations to back up the arguments, both on and off list.<=
o:p>


 




Basil, very happy to provide references!



RFC 3979, a core document about IPR in the IETF, 2005:








8.  Evaluating Alternative Technologies in IETF Working Groups


 


   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 hav=
e the discretion


   to adopt technology with a commitment of fair and non-dis=
criminatory


   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 l=
icenses.




The complete section gives some more details, but this is the central quote=
.



You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:



http://tools.ietf.org=
/html/rfc6569#page-8














-- 


Surveillance is pervasive. Go Dark.








--_000_BBE9739C2C302046BD34B42713A1E2A22DFCD683ESESSMB105erics_--

From bo.burman@ericsson.com  Thu Oct 24 06:43:47 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6EB11E821C for ; Thu, 24 Oct 2013 06:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.489
X-Spam-Level: 
X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=0.759,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbsxhx-JW4eG for ; Thu, 24 Oct 2013 06:43:32 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D2A1A21E8094 for ; Thu, 24 Oct 2013 06:42:30 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-f5-526923c3779a
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5E.57.16099.3C329625; Thu, 24 Oct 2013 15:42:27 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 15:42:27 +0200
From: Bo Burman 
To: "rtcweb@ietf.org" 
Thread-Topic: Performance of rate-controlled H.264 Constrained High Profile
Thread-Index: Ac7QuEtPXArxHy7dRIOE8SxORBoczg==
Date: Thu, 24 Oct 2013 13:42:26 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22DFCD6C3ESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje5h5cwgg00LNCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrEpd5kLVutUHHk6j7WBcYNaFyMnh4SAicSXz23MELaYxIV7 69m6GLk4hAQOM0q83jcfylnEKLFx2wGwKjYBDYn5O+4ygtgiAuoSlx9eYAexhQXcJC6fns0E EfeWWLf0BjOErSdx8u8/IJuDg0VAVWLJLi6QMK+Ar8Tnx8vBShgFZCXuf7/HAmIzC4hL3Hoy nwniIAGJJXvOQx0nKvHy8T9WCFtR4ur05UwQ9fkSrx9sZ4aYKShxcuYTlgmMQrOQjJqFpGwW kjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73ccBMjMOwPbvmtu4Px1DmR Q4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBUWL5Z2DB9QksHg9uLIr+t RdruXsLnT/rPjn7Fvsu2d/vvU9p/z9auMPBaE3nofE/S7Ia32fN+2fQ9zWKY/p0pPOJoj6j5 ys3RS8KMuW/N0ROYu3Lz5WqmiRvUW+/qJ5/5HWuwsLWDO6S75VRY6se8qfH+i3ujbNmrGW5s YHg114zHpfxNvKcSS3FGoqEWc1FxIgBOwqkoSQIAAA==
Subject: [rtcweb] Performance of rate-controlled H.264 Constrained High Profile
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 13:43:49 -0000

--_000_BBE9739C2C302046BD34B42713A1E2A22DFCD6C3ESESSMB105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Our recent post on comparing H.264 Constrained Baseline Profile (CBP) and V=
P8 objective performance with the x264 rate-control patch applied showed th=
at H.264 CBP and VP8 are comparable.

When using that same patch applied to Constrained High Profile (CHP) settin=
gs of x264, as used in draft-burman-rtcweb-h264-proposal, we get the following re=
sults for rate-controlled CHP:

VP8 is anchor: H.264 CHP is 16% better
H.264 is anchor: H.264 CHP is 24% better

This latter result is fully consistent with the fixed-QP tests used in the =
above draft.

While we still propose CBP as MTI to get maximum reach, we recommend and ex=
pect most implementations to also support CHP, which can be seen to give a =
clear quality advantage irrespective if rate control is used or not. Regard=
ing technical differences between CBP and CHP, see a summary in section 8 o=
f the above draft. There is also no difference in licensing situation betwe=
en CBP and CHP.

Regarding choice of anchor; in cases like this where two competing alternat=
ives are compared and there is no obvious anchor, it is possible to instead=
 use a geometric mean (http://en.wikipedia.org/wiki/Geometric_mean) that wi=
ll not depend on any anchor but give a single consistent figure.

Geometric mean: H.264 CHP is 22% better

/Bo


--_000_BBE9739C2C302046BD34B42713A1E2A22DFCD6C3ESESSMB105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


Our recent post on comparing H.264 Constrained Basel=
ine Profile (CBP) and VP8 objective performance with the x264 rate-control =
patch applied showed that H.264 CBP and VP8 are comparable.


 


When using that same patch applied to Constrained Hi=
gh Profile (CHP) settings of x264, as used in
draft-burman-rtcweb-h264-proposal, we get the following results fo=
r rate-controlled CHP:


 


VP8 is anchor: H.264 CHP is 16% better

H.264 is anchor: H.264 CHP is 24% better<=
/p>

 


This latter result is fully consistent with the fixe=
d-QP tests used in the above draft.


 


While we still propose CBP as MTI to get maximum rea=
ch, we recommend and expect most implementations to also support CHP, which=
 can be seen to give a clear quality advantage irrespective if rate control=
 is used or not. Regarding technical
 differences between CBP and CHP, see a summary in section 8 of the above d=
raft. There is also no difference in licensing situation between CBP and CH=
P.


 


Regarding choice of anchor; in cases like this where=
 two competing alternatives are compared and there is no obvious anchor, it=
 is possible to instead use a geometric mean (http://en.wikipedia.org/wiki/Geometric_mean)
 that will not depend on any anchor but give a single consistent figure.


 


Geometric mean: H.264 CHP is 22% better

 


/Bo


 






--_000_BBE9739C2C302046BD34B42713A1E2A22DFCD6C3ESESSMB105erics_--

From basilgohar@librevideo.org  Thu Oct 24 06:56:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6903611E83CE for ; Thu, 24 Oct 2013 06:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLD8eRsgTenh for ; Thu, 24 Oct 2013 06:56:29 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id E8FF921E809C for ; Thu, 24 Oct 2013 06:56:24 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id B884479FDE9 for ; Thu, 24 Oct 2013 09:56:22 -0400 (EDT)
Message-ID: <526926FF.7000602@librevideo.org>
Date: Thu, 24 Oct 2013 09:56:15 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Performance of rate-controlled H.264 Constrained High Profile
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 13:56:46 -0000

On 10/24/2013 09:42 AM, Bo Burman wrote:
> Hi all,
> 
> Our recent post on comparing H.264 Constrained Baseline Profile (CBP)
> and VP8 objective performance with the x264 rate-control patch applied
> showed that H.264 CBP and VP8 are comparable.
> 
> When using that same patch applied to Constrained High Profile (CHP)
> settings of x264, as used in draft-burman-rtcweb-h264-proposal
> ,
> we get the following results for rate-controlled CHP:
> 
> VP8 is anchor: H.264 CHP is 16% better
> 
> H.264 is anchor: H.264 CHP is 24% better
> 
> This latter result is fully consistent with the fixed-QP tests used in
> the above draft.
> 
> While we still propose CBP as MTI to get maximum reach, we recommend and
> expect most implementations to also support CHP, which can be seen to
> give a clear quality advantage irrespective if rate control is used or
> not. Regarding technical differences between CBP and CHP, see a summary
> in section 8 of the above draft. There is also no difference in
> licensing situation between CBP and CHP.
> 
> Regarding choice of anchor; in cases like this where two competing
> alternatives are compared and there is no obvious anchor, it is possible
> to instead use a geometric mean
> (http://en.wikipedia.org/wiki/Geometric_mean) that will not depend on
> any anchor but give a single consistent figure.
> 
> Geometric mean: H.264 CHP is 22% better
> 
> /Bo

Bo,

Thanks for sharing the results of this comparison.

Correct me if I'm wrong, but I thought CBP was being used as a
comparison point to represent the H.264 option because the CBP was being
considered for offer under IPR terms that would be royalty free.

If this is the case, has the same offer or implication also been made
for CHP?  I may have missed it, but I don't recall that being the case.
 If it has not, then while these numbers are nice to have, they still
overlook the IPR issues completely.

-- 
Libre Video
http://librevideo.org

From harald@alvestrand.no  Thu Oct 24 07:10:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148C211E830C for ; Thu, 24 Oct 2013 07:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.532
X-Spam-Level: 
X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzB5XjbJ-X+q for ; Thu, 24 Oct 2013 07:10:14 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 95EAB11E8155 for ; Thu, 24 Oct 2013 07:09:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F72939E031; Thu, 24 Oct 2013 16:09:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT9Js-LecaWt; Thu, 24 Oct 2013 16:09:38 +0200 (CEST)
Received: from [192.168.1.186] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 62F2B39E197; Thu, 24 Oct 2013 16:09:38 +0200 (CEST)
Message-ID: <52692A21.7010609@alvestrand.no>
Date: Thu, 24 Oct 2013 16:09:37 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Bo Burman ,  "rtcweb@ietf.org" 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------000801070907050900000307"
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 14:10:22 -0000

This is a multi-part message in MIME format.
--------------000801070907050900000307
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10/24/2013 03:26 PM, Bo Burman wrote:
>
> 1) We do agree that H.264 Constrained Baseline and VP8 are comparable
> in terms of video quality. But do not forget that Constrained
> Baseline's twin sister H.264 Constrained High outperforms VP8 by a
> huge margin. This is also relevant.
>

I actually haven't seen a test I can quote on that - at least not with
parameters that make sense in a videoconferencing setting (use of rate
control, no B-frames and CBR mode).

There was a series of tests (both subjective and objective) done on both
High Profile and VP8 as part of the MPEG evaluation of VP8 as a response
to the last Call for Proposals, but after the discussions we had in
Incheon, MPEG decided to not publish the results of this viewing as a
"comparision", so I won't call it that.

>  
>
> 2) The "back-and forth of numbers" seems to refer to Ericsson's work
> where we tried to make a fair comparison to evaluate the extraordinary
> claims from Google that VP8 is 70 or 40 percent better than x264. We
> found serious issues with the way Google performed the test, maybe the
> most striking were the use of padding (+8% for x264) and excessive
> number of threads (+10% to +40% for x264) to add overhead to x264.
> That Google managed to remember the threading parameter only when it
> helped
>
> VP8 (the speed test) is also quite remarkable.
>

I was also astonished to learn that x264's default value for "threads"
gave a 10-40% performance penalty over "threads=1"!

On a speed test, we tried to do a bit of "like against like" - the VP8
encoder is by default single-threaded, so it seemed only reasonable to
run the other encoder single-threaded too. I haven't pursued the speed
tests since then; they are quite a bit harder to get consistent results
from than tests that have a deterministic result.

Yes, we should have tested each piece of the advice we got from the x264
developers on how to run x264 in something close to "constant bitrate
mode", instead of just dumping all the flags on our command line
uncritically. That was a mistake, and led to the nal-unit parameter,
whch we should never have used.

We have published our tests, exactly so that they can be evaluated.
We want to do a good job of incorporating feedback - but we will keep on
insisting that the tests should have some relationship to a realistic
WebRTC scenario.

In our opinion, that means working in one pass and using rate control.

>  
>
> 3) Regarding IPR, this is a difficult topic, but we're not at all
> convinced that VP8 is royalty free. For example, there is an IETF IPR
> disclosure (https://datatracker.ietf.org/ipr/2035/) where the IPR
> holder seems unwilling to license (on any terms), and
> http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html
> and
> http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.html
> show that there are in fact ongoing litigations regarding VP8 - and
> this is only skimming the surface of what is available in public space.
>

If you have more specific information, feel free to share it.
The continued use of "there's more information out there" is not helpful
to anyone. Either you have specific information to bring, or you don't.

And since you bring a June mention of the German case, I should mention
this August note from the same case, which I also quoted in the VP8
internet-draft:

http://blog.webmproject.org/2013/08/good-news-from-germany.html

I refuse to comment on fosspatents.com's commentary.


--------------000801070907050900000307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/24/2013 03:26 PM, Bo Burman
      wrote:

    

    

      
      
      
      

        
1)
            We do agree that H.264 Constrained Baseline and VP8 are
            comparable in terms of video quality. But do not forget that
            Constrained Baseline's twin sister H.264 Constrained High
            outperforms VP8 by a huge margin. This is also relevant.

      

    

    

    I actually haven't seen a test I can quote on that - at least not
    with parameters that make sense in a videoconferencing setting (use
    of rate control, no B-frames and CBR mode).

    

    There was a series of tests (both subjective and objective) done on
    both High Profile and VP8 as part of the MPEG evaluation of VP8 as a
    response to the last Call for Proposals, but after the discussions
    we had in Incheon, MPEG decided to not publish the results of this
    viewing as a "comparision", so I won't call it that.

    

    

      

        

        
 

        
2)
            The "back-and forth of numbers" seems to refer to Ericsson's
            work where we tried to make a fair comparison to evaluate
            the extraordinary claims from Google that VP8 is 70 or 40
            percent better than x264. We found serious issues with the
            way Google performed the test, maybe the most striking were
            the use of padding (+8% for x264) and excessive number of
            threads (+10% to +40% for x264) to add overhead to x264.
            That Google managed to remember the threading parameter only
            when it helped

        
VP8
            (the speed test) is also quite remarkable.

      

    

    

    I was also astonished to learn that x264's default value for
    "threads" gave a 10-40% performance penalty over "threads=1"!

    

    On a speed test, we tried to do a bit of "like against like" - the
    VP8 encoder is by default single-threaded, so it seemed only
    reasonable to run the other encoder single-threaded too. I haven't
    pursued the speed tests since then; they are quite a bit harder to
    get consistent results from than tests that have a deterministic
    result.

    

    Yes, we should have tested each piece of the advice we got from the
    x264 developers on how to run x264 in something close to "constant
    bitrate mode", instead of just dumping all the flags on our command
    line uncritically. That was a mistake, and led to the nal-unit
    parameter, whch we should never have used.

    

    We have published our tests, exactly so that they can be evaluated.

    We want to do a good job of incorporating feedback - but we will
    keep on insisting that the tests should have some relationship to a
    realistic WebRTC scenario.

    

    In our opinion, that means working in one pass and using rate
    control.

    

    

      

        

        
 

        
3)
            Regarding IPR, this is a difficult topic, but we're not at
            all convinced that VP8 is royalty free. For example, there
            is an IETF IPR disclosure (https://datatracker.ietf.org/ipr/2035/)
            where the IPR holder seems unwilling to license (on any
            terms), and http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html
            and
            http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.html
            show that there are in fact ongoing litigations regarding
            VP8 - and this is only skimming the surface of what is
            available in public space.

      

    

    

    If you have more specific information, feel free to share it.

    The continued use of "there's more information out there" is not
    helpful to anyone. Either you have specific information to bring, or
    you don't.

    

    And since you bring a June mention of the German case, I should
    mention this August note from the same case, which I also quoted in
    the VP8 internet-draft:

    

    
    http://blog.webmproject.org/2013/08/good-news-from-germany.html

    

    I refuse to comment on fosspatents.com's commentary.

    

  


--------------000801070907050900000307--

From basilgohar@librevideo.org  Thu Oct 24 07:21:12 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A591011E830C for ; Thu, 24 Oct 2013 07:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eT4DPWCtyj3 for ; Thu, 24 Oct 2013 07:21:07 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5767A11E8179 for ; Thu, 24 Oct 2013 07:21:06 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id C62207B3D89 for ; Thu, 24 Oct 2013 10:21:05 -0400 (EDT)
Message-ID: <52692CCF.5030006@librevideo.org>
Date: Thu, 24 Oct 2013 10:21:03 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>  <52692A21.7010609@alvestrand.no>
In-Reply-To: <52692A21.7010609@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 14:21:12 -0000

On 10/24/2013 10:09 AM, Harald Alvestrand wrote:
> 
> I refuse to comment on fosspatents.com's commentary.
> 

Of course, as we do, after all, want to keep things civil, right?  ;)

-- 
Libre Video
http://librevideo.org

From fluffy@cisco.com  Thu Oct 24 07:29:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6226C11E832B for ; Thu, 24 Oct 2013 07:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.432
X-Spam-Level: 
X-Spam-Status: No, score=-110.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5vhbyjMxvq9 for ; Thu, 24 Oct 2013 07:28:58 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BA84611E82F0 for ; Thu, 24 Oct 2013 07:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=205; q=dns/txt; s=iport; t=1382624938; x=1383834538; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WZlon/doJQ6v/IQ++al6nDqdsR2kGP/MfMQ0uITcQ+0=; b=ltmpHNISjC6s3mTV4s/bDfKw41bxsKvO9d76Ma0IMrHXw6zttdUcbBL6 9X0sooEaNe7ZTRpM84aFfkis5YPwBsSpYTPLVTMBUnKVfYAAB5NplQAVR Z1MhoBq1KkjxN0R4qfZy96/QHSWp/qu6f8KX80+X3QGAMtKchx268Rlc1 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtAHADguaVKtJV2Y/2dsb2JhbABZgweBDD2+G4EbFnSCJQEBAQMBeQULAgEIIiQyJQIEDgUIh3kGuj2PHDEHgx+BDQOJB6EKgWaBPoIq
X-IronPort-AV: E=Sophos;i="4.93,562,1378857600"; d="scan'208";a="275953206"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 24 Oct 2013 14:28:56 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9OEStI3027363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 14:28:55 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 09:28:56 -0500
From: "Cullen Jennings (fluffy)" 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [rtcweb] New SDP O/A required if selected ICE candidate does not match c= line?
Thread-Index: AQHO0MVeQzjafjX5rUSd+qRNV+IBTg==
Date: Thu, 24 Oct 2013 14:28:55 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] New SDP O/A required if selected ICE candidate does not match c= line?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 14:29:04 -0000

On Oct 24, 2013, at 4:56 AM, I=F1aki Baz Castillo  wrote:

> IMHO RFC 5245 should NOT state that at
> all.

I will note that people are working on draft-ietf-mmusic-rfc5245bis-00=20



From ted.ietf@gmail.com  Thu Oct 24 07:30:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE73811E831E for ; Thu, 24 Oct 2013 07:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level: 
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6A1uV8bRoxV for ; Thu, 24 Oct 2013 07:30:14 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E583711E818A for ; Thu, 24 Oct 2013 07:30:02 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so3944116iec.20 for ; Thu, 24 Oct 2013 07:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BC+fZamLnqb/g+XlqqJyD3/kciQ4rlAb+JMHRqp6ZM0=; b=YItYiF++uPafADttny8fPVgQQ2MPkl0bIdZG1Ch2ckPC4hyodNvqtJt44vZUB8LUTX dnlHGbqj/GjtBCaTECQkV7i+dUAB669hU+MZTiB96fyTf8a0Lugg0TPf5YuNGpARYVQg BRyfBL8OZ8s+2vcE17YlwGvdvsWxm1FCgxnF7qaPfN7Zm8DI+LyhJsT4CLN5ootFqcTZ XG+0mVAlKj1YF2YEFWPVPustZkG2myra1zXDWWtEDd3VsGoW6qCN0JwL4ZqU1CopmBa4 IuvDg+guAMjEucgt1YkEBx44DJ4gbTVTXSFUe5B+ZgUmPDs4NMXHBO4xTghJT5hqteQQ kngw==
MIME-Version: 1.0
X-Received: by 10.42.18.136 with SMTP id x8mr1787264ica.11.1382625002383; Thu, 24 Oct 2013 07:30:02 -0700 (PDT)
Received: by 10.42.29.202 with HTTP; Thu, 24 Oct 2013 07:30:02 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no> 
Date: Thu, 24 Oct 2013 07:30:02 -0700
Message-ID: 
From: Ted Hardie 
To: Bo Burman 
Content-Type: multipart/alternative; boundary=20cf303f69101ff40d04e97d78c7
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 14:30:15 -0000

--20cf303f69101ff40d04e97d78c7
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 24, 2013 at 6:26 AM, Bo Burman  wrote:

>  1) We do agree that H.264 Constrained Baseline and VP8 are comparable in
> terms of video quality. But do not forget that Constrained Baseline's twin
> sister H.264 Constrained High outperforms VP8 by a huge margin. This is
> also relevant.****
>
> ** **
>
>
Hi Bo,

I note that one of the recent editorial updates you made to the draft is
this:

 H.264 Constrained High Profile Level 1.3, logically extended to
      support 720p resolution at 30 Hz framerate is RECOMMENDED.


that is, you added the word "logically".  Is "logically extended" a term of
art here, or do you simply mean you think it makes sense to extend the

support to Constrained High Profile Level 1.3?

I also note that the discussion here is about a Mandatory to Implement codec
(that is, something at a MUST level that avoids negotiation failure).  Your
document appears to assign that to Constrained Baseline Profile Level 1.2.

The discussion of Constrained High seems to me about an optimization and
is at most an aside, and not part of the core issue to be decided.
If you have changed your view and  believe that Constrained High Profile
Level 1.3 should be mandatory to implement, then it would be useful to say
so more forcefully than above. If you have not, then I believe it is not,
strictly speaking, relevant.


My personal view,

regards,

Ted Hardie

--20cf303f69101ff40d04e97d78c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Oct 24, 2013 at 6:26 AM, Bo Burman <bo.burma=
n@ericsson.com> wrote:













1) We do agree that =
H.264 Constrained Baseline and VP8 are comparable in terms of video quality=
. But do not forget that Constrained Baseline's twin sister H.264
 Constrained High outperforms VP8 by a huge margin. This is also relevant.<=
u>


=A0



Hi Bo,

I note that one of the recen=
t editorial updates you made to the draft is this:

=A0H.264 Constrai=
ned High Profile Level 1.3, logically extended to
=A0 =A0 =A0 support 72=
0p resolution at 30 Hz framerate is RECOMMENDED.



that is, you added the word "logically". =A0Is "logi=
cally extended" a term of 
art here, or do you simply mean you thin=
k it makes sense to extend the

support to Constrained High Profile L=
evel 1.3?


I also note that the discussion here is about a Mandatory to Implement =
codec
(that is, something at a MUST level that avoids negotiation failur=
e). =A0Your
document appears to assign that to Constrained Baseline Prof=
ile Level 1.2. 


The discussion of Constrained High seems to me about an optimization an=
d
is at most an aside, and not part of the core issue to be decided.=A0 =

If you have changed your view and=A0 believe that Constrained High Prof=
ile 

Level 1.3 should be mandatory to implement, then it would be useful to say =

so more forcefully than above. If you have not, then I believe it is no=
t, 
strictly speaking, relevant.



<=
/tr>My personal view,

regards,
=

Ted Hardie


=








--20cf303f69101ff40d04e97d78c7--

From bo.burman@ericsson.com  Thu Oct 24 08:42:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFDE11E834B for ; Thu, 24 Oct 2013 08:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.573
X-Spam-Level: 
X-Spam-Status: No, score=-5.573 tagged_above=-999 required=5 tests=[AWL=0.675,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpBKtqSlsRca for ; Thu, 24 Oct 2013 08:42:10 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F201B11E832F for ; Thu, 24 Oct 2013 08:40:49 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-8d-52693f74621e
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B0.A2.03802.47F39625; Thu, 24 Oct 2013 17:40:36 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 17:40:36 +0200
From: Bo Burman 
To: Ted Hardie 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0CDhJVyL5itEmEWrISFOF+nwVJoCjkaAgAEDvACAAEBxAP//9tAAgAAiP5A=
Date: Thu, 24 Oct 2013 15:40:35 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>  
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22DFCE869ESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+JvjW6JfWaQwYJpWhbH+rrYLNb+a2e3 aJxr58DscWXCFVaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugStjXv8XloKOzIpFv/pYGxgn R3UxcnJICJhInPnaxQJhi0lcuLeerYuRi0NI4DCjxKPTK1ggnEWMEhca9rCDVLEJaEjM33GX EcQWEVCW2HtlBxuIzSwQLNHbNZkVxBYWMJZY8vc6E0SNicT/Rz1Qtp/Eq5Y7YNtYBFQlmte9 A5vDK+Arce/lAVaIZX8YJbYvOQvkcHBwCgRKbFuUClLDKCArcf/7PRaIXeISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YIWxFiavTlzNB1OdL3Ho1kQlil6DEyZlPWCYwis5CMmoWkrJZSMog4joS C3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7Kkb23MTMnPRyo02MwDg7uOW36g7GO+dEDjFKc7Ao ifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxW2RiQ9KmI7YfP/m2bBB45Hs1v+3j HbZVEbyuviz94Rxqv9QYrk/bddGgadINm9eWcgvk/SZzF7KnTbJes+PP9R7/dxMVH85QPa+9 op3x50+b7TMykm36eRJ6P38WXm88oesIF5OSw9uvmT0L6+rvPhZlTVg9lSW4k0n3XrCygbp2 k8eF0BlKLMUZiYZazEXFiQBDppjdgQIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 15:42:31 -0000

--_000_BBE9739C2C302046BD34B42713A1E2A22DFCE869ESESSMB105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: den 24 oktober 2013 16:30
To: Bo Burman
Cc: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

On Thu, Oct 24, 2013 at 6:26 AM, Bo Burman > wrote:
1) We do agree that H.264 Constrained Baseline and VP8 are comparable in te=
rms of video quality. But do not forget that Constrained Baseline's twin si=
ster H.264 Constrained High outperforms VP8 by a huge margin. This is also =
relevant.



Hi Bo,
I note that one of the recent editorial updates you made to the draft is th=
is:

 H.264 Constrained High Profile Level 1.3, logically extended to
      support 720p resolution at 30 Hz framerate is RECOMMENDED.


that is, you added the word "logically".  Is "logically extended" a term of
art here, or do you simply mean you think it makes sense to extend the

support to Constrained High Profile Level 1.3?
[BoB] Maybe the text is unclear. It is not meant to modify the MTI in any w=
ay. See further discussion at the bottom of this mail.

What "logically extended" intends to achieve is to specify a set of paramet=
er values applied to the encoding process, starting from the set called "le=
vel 1.3" and increasing a few parameter values beyond "level 1.3". The word=
 "extended" for this operation is fully in line with existing text in RFC 6=
184 specifying how to signal H.264 codec capability. "Logically extended" i=
s not a term of art but was chosen due to a comment that an H.264 level can=
not formally be "extended" in ISO/ITU-T terms even though the term is used =
in RFC 6184, but you will have to restrict a higher level instead. The resu=
lt is however the same; a set of specified parameter values applied to the =
encoding process.



I also note that the discussion here is about a Mandatory to Implement code=
c
(that is, something at a MUST level that avoids negotiation failure).  Your
document appears to assign that to Constrained Baseline Profile Level 1.2.
[BoB] Yes, and still do.


The discussion of Constrained High seems to me about an optimization and
is at most an aside, and not part of the core issue to be decided.
If you have changed your view and  believe that Constrained High Profile
Level 1.3 should be mandatory to implement, then it would be useful to say
so more forcefully than above. If you have not, then I believe it is not,
strictly speaking, relevant.
[BoB] I did not change my mind on MTI; it is Constrained Baseline.

I do believe the discussion on Constrained High is relevant; it is part of =
the overall argumentation for H.264 and relates to the important aspect of =
potential for improvement beyond MTI. H.264 Profiles and Levels are essenti=
ally parameter restrictions on a single codec specification. If you have H.=
264 CBP as MTI but want access to even better performance, you don't have t=
o implement or license yet another codec but can still make use of H.264, o=
nly with another parameter setting (given that the specific implementation =
supports both CBP and CHP). Given that there are many other possible ways t=
o set parameters to "H.264", pointing to a specific "good" one beyond MTI s=
eemed reasonable. This is arguably an optimization, but not only that.


My personal view,

regards,

Ted Hardie




--_000_BBE9739C2C302046BD34B42713A1E2A22DFCE869ESESSMB105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 <=
/p>







From: Ted Hard=
ie [mailto:ted.ietf@gmail.com]


Sent: den 24 oktober 2013 16:30

To: Bo Burman

Cc: Harald Alvestrand; rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 




On Thu, Oct 24, 2013 at 6:26 AM, Bo Burman <bo.burman@ericsson.c=
om> wrote:












1) We do agree that H.264 Constrained B=
aseline and VP8 are comparable in terms of video quality.
 But do not forget that Constrained Baseline's twin sister H.264 Constraine=
d High outperforms VP8 by a huge margin. This is also relevant.=



 


 










 






Hi Bo,






I note that one of the recent editorial updates you =
made to the draft is this:



 H.264 Constrained High Profile Level 1.3, logically extended to

      support 720p resolution at 30 Hz framerate is RECOMMEN=
DED.





that is, you added the word "logically".  Is "logically=
 extended" a term of 

art here, or do you simply mean you think it makes sense to extend the



support to Constrained High Profile Level 1.3?


[BoB] Maybe the tex=
t is unclear. It is not meant to modify the MTI in any way. See further dis=
cussion at the bottom of this mail.


 


What “logical=
ly extended” intends to achieve is to specify a set of parameter valu=
es applied to the encoding process, starting from the set called “lev=
el
 1.3” and increasing a few parameter values beyond “level 1.3&#=
8221;. The word “extended” for this operation is fully in line =
with existing text in RFC 6184 specifying how to signal H.264 codec capabil=
ity. “Logically extended” is not a term of art but was chosen
 due to a comment that an H.264 level cannot formally be “extended=
221; in ISO/ITU-T terms even though the term is used in RFC 6184, but you w=
ill have to restrict a higher level instead. The result is however the same=
; a set of specified parameter values applied
 to the encoding process. 


 






I also note that the discussion here is about a Mandatory to Implement code=
c

(that is, something at a MUST level that avoids negotiation failure).  =
;Your

document appears to assign that to Constrained Baseline Profile Level 1.2. =




[BoB] Yes, and stil=
l do.






The discussion of Constrained High seems to me about an optimization and
is at most an aside, and not part of the core issue to be decided.  
If you have changed your view and  believe that Constrained High Profi=
le 

Level 1.3 should be mandatory to implement, then it would be useful to say =


so more forcefully than above. If you have not, then I believe it is not, <=
br>
strictly speaking, relevant.


[BoB] I did not cha=
nge my mind on MTI; it is Constrained Baseline.

 


I do believe the di=
scussion on Constrained High is relevant; it is part of the overall argumen=
tation for H.264 and relates to the important aspect of
 potential for improvement beyond MTI. H.264 Profiles and Levels are essent=
ially parameter restrictions on a single codec specification. If you have H=
.264 CBP as MTI but want access to even better performance, you don’t=
 have to implement or license yet another
 codec but can still make use of H.264, only with another parameter setting=
 (given that the specific implementation supports both CBP and CHP). Given =
that there are many other possible ways to set parameters to “H.264&#=
8221;, pointing to a specific “good” one beyond
 MTI seemed reasonable. This is arguably an optimization, but not only that=
.


 <=
/p>

















My personal view,



regards,



Ted Hardie





















 












--_000_BBE9739C2C302046BD34B42713A1E2A22DFCE869ESESSMB105erics_--

From matthew.kaufman@skype.net  Thu Oct 24 09:09:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3811E8367 for ; Thu, 24 Oct 2013 09:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDbp51N5y5ti for ; Thu, 24 Oct 2013 09:09:40 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8121F99F4 for ; Thu, 24 Oct 2013 09:03:33 -0700 (PDT)
Received: from BY2PR03CA035.namprd03.prod.outlook.com (10.242.234.156) by BY2PR03MB237.namprd03.prod.outlook.com (10.242.37.13) with Microsoft SMTP Server (TLS) id 15.0.800.7; Thu, 24 Oct 2013 16:03:24 +0000
Received: from BN1BFFO11FD006.protection.gbl (2a01:111:f400:7c10::188) by BY2PR03CA035.outlook.office365.com (2a01:111:e400:2c2c::28) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Thu, 24 Oct 2013 16:03:24 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD006.mail.protection.outlook.com (10.58.53.66) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Thu, 24 Oct 2013 16:03:23 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.222]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0158.002; Thu, 24 Oct 2013 16:02:38 +0000
From: "Matthew Kaufman (SKYPE)" 
To: Bo Burman , Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0CDh4m5GXoZVQ0C+YhxDfWssZZoCr86AgAEDuwCAACWBAIAAKTgQ
Date: Thu, 24 Oct 2013 16:02:37 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.35]
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D45DC08TK5EX14MBXC266r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454002)(479174003)(53434003)(189002)(199002)(377454003)(84326002)(31966008)(85306002)(81686001)(74366001)(16236675002)(76482001)(76796001)(76786001)(74662001)(81816001)(56776001)(20776003)(63696002)(54316002)(55846006)(47446002)(74502001)(56816003)(77096001)(79102001)(80022001)(80976001)(65816001)(66066001)(44976005)(19580405001)(83322001)(15975445006)(19580395003)(53806001)(51856001)(19300405004)(54356001)(46102001)(6806004)(15202345003)(74706001)(4396001)(69226001)(16297215004)(74876001)(81342001)(71186001)(47976001)(47736001)(49866001)(50986001)(512954002)(77982001)(59766001)(81542001)(33656001)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB237; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-O365ENT-EOP-Header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 000947967F
X-OriginatorOrg: skype.net
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 16:09:46 -0000

--_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D45DC08TK5EX14MBXC266r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On the IPR issue, Google reached agreement with 11 patent holders. There ar=
e at least 31 companies in the MPEG-LA H.264 pool. There is considerable te=
chnical overlap between VP8 and H.264.

My employer is one of those in the H.264 pool, and wasn't one of the 11 com=
panies Google reached an agreement with.

Draw your own conclusions and take your own IPR risks.

Personally I'd rather the IPR devil I know vs. the IPR devil I don't know.

Google could fix this for most potential users (through indemnification, si=
milar to what Oracle offers its Linux licensees) but has chosen not to. You=
 can draw your own conclusion there, too.

Matthew Kaufman

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Bo Burman
Sent: Thursday, October 24, 2013 6:27 AM
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

1) We do agree that H.264 Constrained Baseline and VP8 are comparable in te=
rms of video quality. But do not forget that Constrained Baseline's twin si=
ster H.264 Constrained High outperforms VP8 by a huge margin. This is also =
relevant.

2) The "back-and forth of numbers" seems to refer to Ericsson's work where =
we tried to make a fair comparison to evaluate the extraordinary claims fro=
m Google that VP8 is 70 or 40 percent better than x264. We found serious is=
sues with the way Google performed the test, maybe the most striking were t=
he use of padding (+8% for x264) and excessive number of threads (+10% to +=
40% for x264) to add overhead to x264. That Google managed to remember the =
threading parameter only when it helped
VP8 (the speed test) is also quite remarkable.

3) Regarding IPR, this is a difficult topic, but we're not at all convinced=
 that VP8 is royalty free. For example, there is an IETF IPR disclosure (ht=
tps://datatracker.ietf.org/ipr/2035/) where the IPR holder seems unwilling =
to license (on any terms), and http://www.fosspatents.com/2013/06/german-vp=
8-infringement-cases-show.html and http://www.fosspatents.com/2013/06/itc-i=
nstitutes-investigation-of-nokias.html show that there are in fact ongoing =
litigations regarding VP8 - and this is only skimming the surface of what i=
s available in public space.

/Bo

From: rtcweb-bounces@ietf.org [mailto:rtcwe=
b-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: den 24 oktober 2013 13:12
To: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:

On 10/23/2013 02:51 PM, Harald Alvestrand wrote:

Just a reminder:

The back-and-forth of numbers doesn't change the core question of this

debate.

Both codecs are capable of high quality video encoding, and performance

numbers are comparable.



The real core question is the IPR issue.



The tradition of the IETF says that allowing only business models that

can sustain royalty agreements and royalty payments is Bad for the Internet=
.



The dominant video codec, H.264, is a royalty-required codec.



Do we switch now, or do we give up and live with royalties forever?





Harald,



I would like to see some references to the tradition of the IETF that

you've quoted.



For the record, I agree with the sentiment, but I'd like to be able to

back up the claim itself with references or explicit decisions that were

made in that regard.  I'm not trying to be a thorn in your side, just

looking for citations to back up the arguments, both on and off list.


Basil, very happy to provide references!

RFC 3979, a core document about IPR in the IETF, 2005:


8.  Evaluating Alternative Technologies in IETF Working Groups



   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.

The complete section gives some more details, but this is the central quote=
.

You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:

http://tools.ietf.org/html/rfc6569#page-8





--

Surveillance is pervasive. Go Dark.

--_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D45DC08TK5EX14MBXC266r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











On the IPR issue, Google =
reached agreement with 11 patent holders. There are at least 31 companies i=
n the MPEG-LA H.264 pool. There is considerable technical
 overlap between VP8 and H.264.


 <=
/p>

My employer is one of tho=
se in the H.264 pool, and wasn’t one of the 11 companies Google reach=
ed an agreement with.


 <=
/p>

Draw your own conclusions=
 and take your own IPR risks.


 <=
/p>

Personally I’d rath=
er the IPR devil I know vs. the IPR devil I don’t know.


 <=
/p>

Google could fix this for=
 most potential users (through indemnification, similar to what Oracle offe=
rs its Linux licensees) but has chosen not to. You can draw
 your own conclusion there, too.


 <=
/p>



Matthew Kaufman




 <=
/p>







From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@=
ietf.org]
On Behalf Of Bo Burman

Sent: Thursday, October 24, 2013 6:27 AM

To: Harald Alvestrand; rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 


1) We do agree that H.264=
 Constrained Baseline and VP8 are comparable in terms of video quality. But=
 do not forget that Constrained Baseline's twin sister H.264
 Constrained High outperforms VP8 by a huge margin. This is also relevant.<=
o:p>


 <=
/p>

2) The "back-and for=
th of numbers" seems to refer to Ericsson's work where we tried to mak=
e a fair comparison to evaluate the extraordinary claims from Google
 that VP8 is 70 or 40 percent better than x264. We found serious issues wit=
h the way Google performed the test, maybe the most striking were the use o=
f padding (+8% for x264) and excessive number of threads (+10% to &=
#43;40% for x264) to add overhead to x264. That
 Google managed to remember the threading parameter only when it helped


VP8 (the speed test) is a=
lso quite remarkable.


 <=
/p>

3) Regarding IPR, this is=
 a difficult topic, but we're not at all convinced that VP8 is royalty free=
. For example, there is an IETF IPR disclosure (https://datatracker.ietf.org/ipr/2035/)
 where the IPR holder seems unwilling to license (on any terms), and 
http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html<=
/a> and

http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.h=
tml show that there are in fact ongoing litigations regarding VP8 - and=
 this is only skimming the surface of what is available in public space.


 <=
/p>

/Bo


 <=
/p>







From:
rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Harald Alvestrand

Sent: den 24 oktober 2013 13:12

To: rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 




On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:






On 10/23/2013 02:51 PM, Harald Alvestrand wrote:




Just a reminder:


The back-and-forth of numbers doesn't change the core question of this=



debate.


Both codecs are capable of high quality video encoding, and performanc=
e


numbers are comparable.


 


The real core question is the IPR issue.


 


The tradition of the IETF says that allowing only business models that=



can sustain royalty agreements and royalty payments is Bad for the Int=
ernet.


 


The dominant video codec, H.264, is a royalty-required codec.


 


Do we switch now, or do we give up and live with royalties forever?


 




 


Harald,


 


I would like to see some references to the tradition of the IETF that<=
o:p>


you've quoted.


 


For the record, I agree with the sentiment, but I'd like to be able to=



back up the claim itself with references or explicit decisions that we=
re


made in that regard.  I'm not trying to be a thorn in your side, =
just


looking for citations to back up the arguments, both on and off list.<=
o:p>


 




Basil, very happy to =
provide references!



RFC 3979, a core document about IPR in the IETF, 2005:






8.  Evaluating Alternative Technologies in IETF Working Groups


 


   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 hav=
e the discretion


   to adopt technology with a commitment of fair and non-dis=
criminatory


   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 l=
icenses.




The complete section gives some more details, but this is the central quote=
.



You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:



http://tools.ietf.org=
/html/rfc6569#page-8












-- 


Surveillance is pervasive. Go Dark.










--_000_AE1A6B5FD507DC4FB3C5166F3A05A4843D45DC08TK5EX14MBXC266r_--

From singer@apple.com  Thu Oct 24 09:15:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C504B11E838C for ; Thu, 24 Oct 2013 09:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd4ZpCrO2xzl for ; Thu, 24 Oct 2013 09:15:00 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id C3A9111E83A8 for ; Thu, 24 Oct 2013 09:09:35 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MV600CPLKUXQ5V1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 24 Oct 2013 09:09:08 -0700 (PDT)
X-AuditID: 11807157-b7ff46d000001540-a3-5269462491bd
Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay4.apple.com (Apple SCV relay) with SMTP id 51.CE.05440.42649625; Thu, 24 Oct 2013 09:09:08 -0700 (PDT)
Received: from [17.153.51.31] (unknown [17.153.51.31]) by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MV600K19KV71780@marigold.apple.com> for rtcweb@ietf.org; Thu, 24 Oct 2013 09:09:08 -0700 (PDT)
From: David Singer 
In-reply-to: 
Date: Thu, 24 Oct 2013 09:09:07 -0700
Message-id: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>  
To: Ted Hardie 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoqvilhlkMLOH32Ltv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlHP5wmr3gBGfFmtWHmRoYD7N3MXJySAiYSDzZ3cMGYYtJXLi3 Hsjm4hASmMQkcX9qI5Qzn0li8oytTCBVzAI6Er3fvzGD2LwCehI7925jBbGFBYwlep58BpvE JqAq8WDOMUYQm1MgWOJ3xx4gm4ODBSh+ca8LxBhviZuds6FGaks8eXeBFWKkjcTTw6/BxggJ /GGUaOgFWyUioCyx98oOqENlJU6fe84ygVFgFpKLZiG5aBaSsQsYmVcxChSl5iRWmuglFhTk pOol5+duYgQHXmH4DsZ/y6wOMQpwMCrx8Gp8SA8SYk0sK67MPcQowcGsJMI7TS8zSIg3JbGy KrUoP76oNCe1+BCjNAeLkjhvvgFQSiA9sSQ1OzW1ILUIJsvEwSnVwHjVNbJoS1P8irWNu/LZ W7jz3W3Oz13pvMpTZELBUlND6TLXmn/mO53VVbJFijwCWddf6Tw8bdGebelzhPmFFI9FHhFK 9aqz6Z96YYfte0NeE7Mrbs79VnwLCpfrfM37xPOhreWme92X22mHI9VPN3BLGjkvmdlxblmY 3rPLh/1/MWqobBQ/p8RSnJFoqMVcVJwIAAsCeL44AgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 16:15:14 -0000

On Oct 24, 2013, at 7:30 , Ted Hardie  wrote:

> On Thu, Oct 24, 2013 at 6:26 AM, Bo Burman  wrote:
> 1) We do agree that H.264 Constrained Baseline and VP8 are comparable in terms of video quality. But do not forget that Constrained Baseline's twin sister H.264 Constrained High outperforms VP8 by a huge margin. This is also relevant.
> 
>  
> 
> 
> 
> Hi Bo,
> 
> I note that one of the recent editorial updates you made to the draft is this:
> 
>  H.264 Constrained High Profile Level 1.3, logically extended to
>       support 720p resolution at 30 Hz framerate is RECOMMENDED.
> 
> 
> that is, you added the word "logically".  Is "logically extended" a term of 
> art here, or do you simply mean you think it makes sense to extend the
> 
> support to Constrained High Profile Level 1.3?

I think that merely means it's easier to speak of extending a level to support something, but actually, it would formally have to be expressed as a restriction on a higher level (which takes more explaining and words, which don't seem needed here).

David Singer
Multimedia and Software Standards, Apple Inc.


From bo.burman@ericsson.com  Thu Oct 24 09:26:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBF811E81D9 for ; Thu, 24 Oct 2013 09:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.641
X-Spam-Level: 
X-Spam-Status: No, score=-5.641 tagged_above=-999 required=5 tests=[AWL=0.607,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-bmD1WjI0I6 for ; Thu, 24 Oct 2013 09:26:36 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF3411E81AD for ; Thu, 24 Oct 2013 09:26:35 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-36-52694a3ad987
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 58.57.03802.A3A49625; Thu, 24 Oct 2013 18:26:34 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 18:26:34 +0200
From: Bo Burman 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0CDhJVyL5itEmEWrISFOF+nwVJoCjkaAgAEDvACAAEBxAP//8RyAgAAlpVA=
Date: Thu, 24 Oct 2013 16:26:33 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>  <52692A21.7010609@alvestrand.no>
In-Reply-To: <52692A21.7010609@alvestrand.no>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22DFCEECBESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvja6VV2aQwYEtJhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJW7HzHVvBKr2Lnx9VsDYzHNLoYOTgkBEwk lq5x72LkBDLFJC7cW8/WxcjFISRwmFFi44I/zBDOIkaJ2492M4FUsQloSMzfcZcRxBYRCJbo ff4ezBYWMJZY8vc6E0TcROL/ox4o20/i5992FhCbRUBVYsaH7ewgNq+Ar8S+7YeZIBbcYJT4 1rudDSTBKaArMfnRGrAiRgFZifvf74E1MwuIS9x6Mp8J4lQBiSV7zjND2KISLx//Y4WwFSWu Tl/OBFGfL3Fr+hlWiGWCEidnPmGZwCgyC8moWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebA YyZk8QWM7KsY2XMTM3PSy402MQKj5+CW36o7GO+cEznEKM3BoiTO++Gtc5CQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGRuabsn7XlszUiBU4vaRldcOMnPWB74o0f/anHlG3ZJ+7LuiZ/UT9 xIueG9yy4pamz14pd3I7E6/JRHsHZm7H8ht7js7xYZm9+fWXa8zmUkZyc0O4GtUEjj7bkOn2 6HWdQW5ylfkOptPO/lIqSw7ozwkPuztJMOVKxnrhW38bPsXbvDLYtOWGphJLcUaioRZzUXEi AGqxnXpsAgAA
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 16:26:43 -0000

--_000_BBE9739C2C302046BD34B42713A1E2A22DFCEECBESESSMB105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: den 24 oktober 2013 16:10
To: Bo Burman; rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue


We have published our tests, exactly so that they can be evaluated.
We want to do a good job of incorporating feedback - but we will keep on in=
sisting that the tests should have some relationship to a realistic WebRTC =
scenario.

In our opinion, that means working in one pass and using rate control.

[BoB] One pass: agree. Using rate control: arguably yes, but as our recent =
posts with the rate control patch to x264 indicate, if you intend to compar=
e codecs and apply similar rate control to all the tested codecs it is like=
ly that you will get comparison results similar to what you would get with =
fixed-QP. Tests with and without rate control will likely not give the same=
 results in absolute terms, but it is likely the relative performance of co=
decs either with or without rate control will yield similar results in a fa=
ir test.



--_000_BBE9739C2C302046BD34B42713A1E2A22DFCEECBESESSMB105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

 <=
/p>







From: Harald Alvestrand [mailto:harald@alvestrand.no]


Sent: den 24 oktober 2013 16:10

To: Bo Burman; rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 


 


We have published our t=
ests, exactly so that they can be evaluated.

We want to do a good job of incorporating feedback - but we will keep on in=
sisting that the tests should have some relationship to a realistic WebRTC =
scenario.



In our opinion, that means working in one pass and using rate control.






[BoB] One pass: agr=
ee. Using rate control: arguably yes, but as our recent posts with the rate=
 control patch to x264 indicate, if you intend to compare
 codecs and apply similar rate control to all the tested codecs it is likel=
y that you will get comparison results similar to what you would get with f=
ixed-QP. Tests with and without rate control will likely not give the same =
results in absolute terms, but it
 is likely the relative performance of codecs either with or without rate c=
ontrol will yield similar results in a fair test.=
















--_000_BBE9739C2C302046BD34B42713A1E2A22DFCEECBESESSMB105erics_--

From bo.burman@ericsson.com  Thu Oct 24 09:30:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AD011E81AD for ; Thu, 24 Oct 2013 09:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Level: 
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.552,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVxdshw634Of for ; Thu, 24 Oct 2013 09:30:37 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4D0D21F9CA0 for ; Thu, 24 Oct 2013 09:30:36 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-e6-52694b2b7fbf
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7C.FC.16099.B2B49625; Thu, 24 Oct 2013 18:30:35 +0200 (CEST)
Received: from ESESSMB105.ericsson.se ([169.254.5.4]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 24 Oct 2013 18:30:34 +0200
From: Bo Burman 
To: Basil Mohamed Gohar , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Performance of rate-controlled H.264 Constrained High Profile
Thread-Index: Ac7QuEtPXArxHy7dRIOE8SxORBoczv//736A///ZjlA=
Date: Thu, 24 Oct 2013 16:30:33 +0000
Message-ID: 
References:  <526926FF.7000602@librevideo.org>
In-Reply-To: <526926FF.7000602@librevideo.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja62d2aQwcvHEhYPPm5mtVj7r53d gcljyZKfTB7Nr68zBTBFcdmkpOZklqUW6dslcGV8+V1ScEOyYkFfTgPjTpEuRk4OCQETiSvr PrBC2GISF+6tZ+ti5OIQEjjMKHH5eRcrhLOIUeLC0UOMIFVsAhoS83fcBbNFBKIknrV3sIPY wgKhEuv+z2OBiIdJnFo7Gcq2kpjVdQ6snkVAVeLU73awOK+Ar8Sr2Z+YQWwhgUKJb8fXM4HY nAJ6Em0zGsHqGQVkJe5/vwdWzywgLnHryXwmiEsFJJbsOc8MYYtKvHz8D+oDRYmr05czQdTr SCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq54SZG YCQc3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDoNTcy 2nXhzz72VQ33vqueqFzy5JXY47fuYhvqpBaqzuovCXwQ+jlu/r3z9VOuKV2uZHf49uDJTy82 5of29TaaHf4v7XnN7t2P27JNTaTMcubH3F3buoJ2Vv5j3cWnHZ7xZfq09xtuFSy8suF8i+nL lVtjA7Yz8yuu2rvCfFUb77ubK5smHDNZpcRSnJFoqMVcVJwIAAWhMytSAgAA
Subject: Re: [rtcweb] Performance of rate-controlled H.264 Constrained High Profile
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 16:30:42 -0000

Hi Basil,

> Correct me if I'm wrong, but I thought CBP was being used as a comparison=
 point to represent the H.264 option because
> the CBP was being considered for offer under IPR terms that would be roya=
lty free.

That was definitely part of the _potential_ reason, but unfortunately seems=
 very hard to achieve. It however still think H.264 CBP is a better choice =
than VP8 since I believe the IPR landscape is more known.

> If this is the case, has the same offer or implication also been made for=
 CHP?  I may have missed it, but I don't recall that
> being the case.

No, that was never done, but if you choose to license CBP, that also includ=
es CHP.


> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of Basil Mohamed Gohar
> Sent: den 24 oktober 2013 15:56
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Performance of rate-controlled H.264 Constrained Hi=
gh Profile
>=20
> On 10/24/2013 09:42 AM, Bo Burman wrote:
> > Hi all,
> >
> > Our recent post on comparing H.264 Constrained Baseline Profile (CBP)
> > and VP8 objective performance with the x264 rate-control patch applied
> > showed that H.264 CBP and VP8 are comparable.
> >
> > When using that same patch applied to Constrained High Profile (CHP)
> > settings of x264, as used in draft-burman-rtcweb-h264-proposal
> > ,
> > we get the following results for rate-controlled CHP:
> >
> > VP8 is anchor: H.264 CHP is 16% better
> >
> > H.264 is anchor: H.264 CHP is 24% better
> >
> > This latter result is fully consistent with the fixed-QP tests used in
> > the above draft.
> >
> > While we still propose CBP as MTI to get maximum reach, we recommend
> > and expect most implementations to also support CHP, which can be seen
> > to give a clear quality advantage irrespective if rate control is used
> > or not. Regarding technical differences between CBP and CHP, see a
> > summary in section 8 of the above draft. There is also no difference
> > in licensing situation between CBP and CHP.
> >
> > Regarding choice of anchor; in cases like this where two competing
> > alternatives are compared and there is no obvious anchor, it is
> > possible to instead use a geometric mean
> > (http://en.wikipedia.org/wiki/Geometric_mean) that will not depend on
> > any anchor but give a single consistent figure.
> >
> > Geometric mean: H.264 CHP is 22% better
> >
> > /Bo
>=20
> Bo,
>=20
> Thanks for sharing the results of this comparison.
>=20
> Correct me if I'm wrong, but I thought CBP was being used as a comparison=
 point to represent the H.264 option because
> the CBP was being considered for offer under IPR terms that would be roya=
lty free.
>=20
> If this is the case, has the same offer or implication also been made for=
 CHP?  I may have missed it, but I don't recall that
> being the case.
>  If it has not, then while these numbers are nice to have, they still ove=
rlook the IPR issues completely.
>=20
> --
> Libre Video
> http://librevideo.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From richard.ejzak@alcatel-lucent.com  Thu Oct 24 09:42:25 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E76611E8354 for ; Thu, 24 Oct 2013 09:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.562
X-Spam-Level: 
X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26tBhR0c1a8a for ; Thu, 24 Oct 2013 09:42:08 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BCF6611E838A for ; Thu, 24 Oct 2013 09:41:46 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9OGfjhV012700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Oct 2013 11:41:46 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9OGfeFO009647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Oct 2013 12:41:45 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 24 Oct 2013 12:41:44 -0400
From: "Ejzak, Richard P (Richard)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-06.txt
Thread-Index: AQHOzpILf6W6Zo5hxU+/KH4u5F3FBZoEA1Jg
Date: Thu, 24 Oct 2013 16:41:43 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86C7EB@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191313.32469.99466.idtracker@ietfa.amsl.com>
In-Reply-To: <20131021191313.32469.99466.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.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-06.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 16:42:26 -0000

I have some comments/questions about draft-ietf-rtcweb-data-channel-06.

The last paragraph of section 6.4 is a little ambiguous, but also seems to =
contradict the decision that the same stream identifier will be used in bot=
h directions.  I assume that "number" and "stream value" in the paragraph b=
oth refer to SCTP "stream identifier"?  Shouldn't the paragraph say that wh=
ile SCTP does not constrain allocation of the stream identifier in the two =
directions, a bidirectional data channel is defined as a pair of streams in=
 opposite directions that use the same stream identifier?

The discussion in the 3rd paragraph of section 6.5, which describes some co=
nstraints on external negotiation, is a bit confusing to me.  I assume that=
 "picks a Stream" is intended to mean "picks a Stream Identifier"?  For cla=
rity I would prefer the latter, unless something else is intended.

In the same paragraph, DTLS role is used as a possible way of determining w=
hether one side can select odd or even stream identifiers, but this is prob=
lematic.  It must be possible for the side requesting (offering) the peer c=
onnection to open a data channel before DTLS role can be determined.  How c=
an the application know whether to request an odd or even stream identifier=
 for a data channel if it doesn't know the DTLS role yet?  May I suggest th=
at a better example would be to say that selection is based on which side s=
ends the initial SDP offer creating the peer connection (e.g., the initial =
offerer picks even stream identifiers and the initial answerer picks odd st=
ream identifiers).

In the same paragraph, the last sentence points out that the other side mus=
t inform the protocol to expect data using the stream identifier selected b=
y the first side, but must also select parameters for use with data that it=
 sends.  I assume that this text requires that the same stream identifier b=
e used for the streams in both directions, but this is not stated clearly. =
 If not, do you assume that external negotiation establishes unidirectional=
 channels only?  If the latter, are the sending parameters relevant to the =
other side?  Is something else intended?

Section 6.6 says that the "higher level" can override the default reliabili=
ty options with per-message options.  I don't think this is allowed by the =
API, or did I miss something?  While I know that SCTP could potentially all=
ow this with API support, it seems confusing to describe capabilities not a=
vailable from the API without some clarifying text.

Thanks,
Richard



From ted.ietf@gmail.com  Thu Oct 24 09:56:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573D311E81BD for ; Thu, 24 Oct 2013 09:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level: 
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU4f1TkG0uw0 for ; Thu, 24 Oct 2013 09:56:42 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C515211E82DA for ; Thu, 24 Oct 2013 09:55:43 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id u16so4283310iet.4 for ; Thu, 24 Oct 2013 09:55:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0DM7U3lOxd6zQ5b7/v/r+Z7YRTXwKRwhRrZbkyq/nvM=; b=Q4vk8v5/qQwJTeFwE/fIWueo0LdJgTskZU+1a6n1lzKflSq4OwfUj9vJIjX1JxMeZa AN3nbX6fwRgVaCTFRH8oMuIj12f8UNYzYaCnIMMVOUbM6iwJ4caRIvVwne/3ZXSebO/8 8oUDw3qiIeeucmg3MC+/j3IbbC+RIGB50am/299R+6DW1Gm9UEPEBMHYuywq+5cIUPnZ NSnZpz291r4rzDTWPnGAltS7hyS6LjHOSB+lejrTApnrYkc6+JUyakcRxnli4emW57/E A/Gny7Z/KSgNRWh78IOLS+mxSP6QlCGLcI4xJu2xzRoooLOZUdAlpYc/HIqqqSGhecby ZGcg==
MIME-Version: 1.0
X-Received: by 10.50.120.10 with SMTP id ky10mr2473989igb.29.1382633742876; Thu, 24 Oct 2013 09:55:42 -0700 (PDT)
Received: by 10.42.29.202 with HTTP; Thu, 24 Oct 2013 09:55:42 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   
Date: Thu, 24 Oct 2013 09:55:42 -0700
Message-ID: 
From: Ted Hardie 
To: Bo Burman 
Content-Type: multipart/alternative; boundary=047d7ba982321951df04e97f81ed
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 16:56:58 -0000

--047d7ba982321951df04e97f81ed
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 24, 2013 at 8:40 AM, Bo Burman  wrote:

>   **
>
> *What =93logically extended=94 intends to achieve is to specify a set of
> parameter values applied to the encoding process, starting from the set
> called =93level 1.3=94 and increasing a few parameter values *
>

Is this meant to be level 1.2?  The draft says:

H.264 Constrained Baseline Profile Level 1.2 MUST be supported as
      Mandatory To Implement video codec.

I assume that this means shifting from 1.2 to 1.3 with the parameter set
for CHB?




> *beyond =93level 1.3=94. The word =93extended=94 for this operation is fu=
lly in
> line with existing text in RFC 6184 specifying how to signal H.264 codec
> capability. =93Logically extended=94 is not a term of art but was chosen =
due to
> a comment that an H.264 level cannot formally be =93extended=94 in ISO/IT=
U-T
> terms even though the term is used in RFC 6184, but you will have to
> restrict a higher level instead. The result is however the same; a set of
> specified parameter values applied to the encoding process. *****
>
> * *
>
>
>
> I also note that the discussion here is about a Mandatory to Implement
> codec
> (that is, something at a MUST level that avoids negotiation failure).  Yo=
ur
> document appears to assign that to Constrained Baseline Profile Level 1.2=
.
> ****
>
> *[BoB] Yes, and still do.*
>
>
>
> The discussion of Constrained High seems to me about an optimization and
> is at most an aside, and not part of the core issue to be decided.
> If you have changed your view and  believe that Constrained High Profile
> Level 1.3 should be mandatory to implement, then it would be useful to sa=
y
> so more forcefully than above. If you have not, then I believe it is not,
> strictly speaking, relevant.****
>
> *[BoB] I did not change my mind on MTI; it is Constrained Baseline.*
>
> * *
>
> *I do believe the discussion on Constrained High is relevant; it is part
> of the overall argumentation for H.264 and relates to the important aspec=
t
> of potential for improvement beyond MTI. *
>

I described this an optimization, and I think your comments actual support
that.  Our overall approach allows negotiating among multiple codes; the MT=
I
is not a restriction.  Having part of that negotiated set be related may
make
is simpler to support, but it is entirely possible to do it across codec
families
as well.



> *H.264 Profiles and Levels are essentially parameter restrictions on a
> single codec specification. If you have H.264 CBP as MTI but want access =
to
> even better performance, you don=92t have to implement or license yet ano=
ther
> codec but can still make use of H.264, only with another parameter settin=
g
> (given that the specific implementation supports both CBP and CHP). Given
> that there are many other possible ways to set parameters to =93H.264=94,
> pointing to a specific =93good=94 one beyond MTI seemed reasonable. This =
is
> arguably an optimization, but not only that.*
>
> **
>

I'm not sure I understand what makes it more than an optimization.

regards,

Ted Hardie




> **
>
> My personal view,
>
> regards,
>
> Ted Hardie****
>
> ** **
>

--047d7ba982321951df04e97f81ed
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Thu, Oct 24, 2013 at 8:40 AM, Bo Burman <bo.burma=
n@ericsson.com> wrote:













=A0




What =93logica=
lly extended=94 intends to achieve is to specify a set of parameter values =
applied to the encoding process, starting from the set called =93level
 1.3=94 and increasing a few parameter values 

Is this meant to be le=
vel 1.2?=A0 The draft says:

H.264 Constrained Baseli=
ne Profile Level 1.2 MUST be supported as
      Mandatory To Implement video codec.

I as=
sume that this means shifting from 1.2 to 1.3 with the parameter set 
fo=
r CHB?

=A0




beyo=
nd =93level 1.3=94. The word =93extended=94 for this operation is fully in =
line with existing text in RFC 6184 specifying how to signal H.264 codec ca=
pability. =93Logically extended=94 is not a term of art but was chosen
 due to a comment that an H.264 level cannot formally be =93extended=94 in =
ISO/ITU-T terms even though the term is used in RFC 6184, but you will have=
 to restrict a higher level instead. The result is however the same; a set =
of specified parameter values applied
 to the encoding process. 


=A0<=
/u>






I also note that the discussion here is about a Mandatory to Implement code=
c

(that is, something at a MUST level that avoids negotiation failure). =A0Yo=
ur

document appears to assign that to Constrained Baseline Profile Level 1.2. =




[BoB] Ye=
s, and still do.






The discussion of Constrained High seems to me about an optimization and
is at most an aside, and not part of the core issue to be decided.=A0 

If you have changed your view and=A0 believe that Constrained High Profile =


Level 1.3 should be mandatory to implement, then it would be useful to say =


so more forcefully than above. If you have not, then I believe it is not, <=
br>
strictly speaking, relevant.


[BoB] I =
did not change my mind on MTI; it is Constrained Baseline.



=A0<=
/u>


I do believe t=
he discussion on Constrained High is relevant; it is part of the overall ar=
gumentation for H.264 and relates to the important aspect of
 potential for improvement beyond MTI. 

I described this an optimizat=
ion, and I think your comments actual support
that.=A0 Our ov=
erall approach allows negotiating among multiple codes; the MTI

is not a restriction.=A0 Having part of that negotiated set be related may =
make
is simpler to support, but it is entirely possible to do it across =
codec families
as well.

=A0




H.26=
4 Profiles and Levels are essentially parameter restrictions on a single co=
dec specification. If you have H.264 CBP as MTI but want access to even bet=
ter performance, you don=92t have to implement or license yet another
 codec but can still make use of H.264, only with another parameter setting=
 (given that the specific implementation supports both CBP and CHP). Given =
that there are many other possible ways to set parameters to =93H.264=94, p=
ointing to a specific =93good=94 one beyond
 MTI seemed reasonable. This is arguably an optimization, but not only that=
.


=A0

I'm not=
 sure I understand what makes it more than an optimization.


regards,

Ted Hardie


=A0






















My personal view,



regards,



Ted Hardie





















=A0
















--047d7ba982321951df04e97f81ed--

From richard.ejzak@alcatel-lucent.com  Thu Oct 24 10:00:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D704611E8189 for ; Thu, 24 Oct 2013 10:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.566
X-Spam-Level: 
X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGW56+p-+OR0 for ; Thu, 24 Oct 2013 09:59:54 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12A11E81A6 for ; Thu, 24 Oct 2013 09:59:36 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9OGxO0W000447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Oct 2013 11:59:24 -0500 (CDT)
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 r9OGxNa5032274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Oct 2013 12:59:24 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 24 Oct 2013 12:59:23 -0400
From: "Ejzak, Richard P (Richard)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQ
Date: Thu, 24 Oct 2013 16:59:23 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com>
In-Reply-To: <20131021191343.32574.60876.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.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 17:00:02 -0000

I have a question about draft-ietf-rtcweb-data-protocol-01.  The browser us=
es DTLS role to determine which side uses even or odd stream identifiers.  =
What does the application on the side sending the initial SDP offer that es=
tablishes the peer connection do if it wants to create data channels before=
 the DTLS role can be determined?  How does the browser know if the applica=
tion tries to select a disallowed stream id?  If the application asks the b=
rowser to select the stream identifier before DTLS role can be determined, =
what does the browser do?

Thanks,
Richard


From ted.ietf@gmail.com  Thu Oct 24 10:00:05 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3211E8189 for ; Thu, 24 Oct 2013 10:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egF33ZGefX5I for ; Thu, 24 Oct 2013 10:00:01 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CC8F221F9CF7 for ; Thu, 24 Oct 2013 09:59:57 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so4492467iec.34 for ; Thu, 24 Oct 2013 09:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bTbm8U+/3B3QOnVACcI/b6p3LFijY4vpvtI8+VdPQBo=; b=C/ozxpT4K1EFo4V9aIEeAkZT6rLdASHHvyhwPq/aFr7epXSJb9YjPJuSwlvcOicgIF PiJbkvDzKGk83dKzQH2kVIo79NLAlULVncqwPIL3r7hT8uf52FXrzuYEW4zy9fLnEX99 rnYy8yB94oMVAEZHuw2ArfL4n2S7BArUHde0OAQTJUb0wmSh/Mh0Jc8nWaXiD2VwNsD5 Pregbdqg8t7v14ZOO7RCxeHK8hizaAkybbiao1U2vXXQ+N0P8sx6R9QeVC0wgNULnN+a w0qBc1456XSvo6u5AqlmOOM3i71LKUUtQGONadCcT0EtR8aH89EnQfVxb8LDNsmGEk+f Se+A==
MIME-Version: 1.0
X-Received: by 10.50.120.10 with SMTP id ky10mr2487707igb.29.1382633996276; Thu, 24 Oct 2013 09:59:56 -0700 (PDT)
Received: by 10.42.29.202 with HTTP; Thu, 24 Oct 2013 09:59:56 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>  
Date: Thu, 24 Oct 2013 09:59:56 -0700
Message-ID: 
From: Ted Hardie 
To: "Matthew Kaufman (SKYPE)" 
Content-Type: multipart/alternative; boundary=047d7ba9823233e95b04e97f90d6
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 17:00:05 -0000

--047d7ba9823233e95b04e97f90d6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Matthew,

On Thu, Oct 24, 2013 at 9:02 AM, Matthew Kaufman (SKYPE) <
matthew.kaufman@skype.net> wrote:

>  On the IPR issue, Google reached agreement with 11 patent holders. There
> are at least 31 companies in the MPEG-LA H.264 pool. There is considerabl=
e
> technical overlap between VP8 and H.264.****
>
> ** **
>
> My employer is one of those in the H.264 pool, and wasn=92t one of the 11
> companies Google reached an agreement with.****
>
> ** **
>
> Draw your own conclusions and take your own IPR risks.****
>
> **
>

If you would like to make an IPR declaration according to the IETF
IPR process, the form is available here:

https://datatracker.ietf.org/ipr/new-specific/

If you would prefer to email one, ietf-ipr@ietf.org is the correct email
address.
Statements of the form above to WG mailing lists do not appear to me qualif=
y
as IPR statements in  the IETF IPR process, at least as I understand it.

regards,

Ted Hardie




> **
>
> Personally I=92d rather the IPR devil I know vs. the IPR devil I don=92t =
know.
> ****
>
> ** **
>
> Google could fix this for most potential users (through indemnification,
> similar to what Oracle offers its Linux licensees) but has chosen not to.
> You can draw your own conclusion there, too.****
>
> ** **
>
> Matthew Kaufman****
>
> ** **
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On
> Behalf Of *Bo Burman
> *Sent:* Thursday, October 24, 2013 6:27 AM
> *To:* Harald Alvestrand; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] VP8 vs H.264 - the core issue****
>
>  ** **
>
> 1) We do agree that H.264 Constrained Baseline and VP8 are comparable in
> terms of video quality. But do not forget that Constrained Baseline's twi=
n
> sister H.264 Constrained High outperforms VP8 by a huge margin. This is
> also relevant.****
>
> ** **
>
> 2) The "back-and forth of numbers" seems to refer to Ericsson's work wher=
e
> we tried to make a fair comparison to evaluate the extraordinary claims
> from Google that VP8 is 70 or 40 percent better than x264. We found serio=
us
> issues with the way Google performed the test, maybe the most striking we=
re
> the use of padding (+8% for x264) and excessive number of threads (+10% t=
o
> +40% for x264) to add overhead to x264. That Google managed to remember t=
he
> threading parameter only when it helped****
>
> VP8 (the speed test) is also quite remarkable.****
>
> ** **
>
> 3) Regarding IPR, this is a difficult topic, but we're not at all
> convinced that VP8 is royalty free. For example, there is an IETF IPR
> disclosure (https://datatracker.ietf.org/ipr/2035/) where the IPR holder
> seems unwilling to license (on any terms), and
> http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.htm=
land
> http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias=
.htmlshow that there are in fact ongoing litigations regarding VP8 - and th=
is is
> only skimming the surface of what is available in public space.****
>
> ** **
>
> /Bo****
>
> ** **
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
> *On Behalf Of *Harald Alvestrand
> *Sent:* den 24 oktober 2013 13:12
> *To:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] VP8 vs H.264 - the core issue****
>
> ** **
>
> On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:****
>
> On 10/23/2013 02:51 PM, Harald Alvestrand wrote:****
>
>  Just a reminder:****
>
> The back-and-forth of numbers doesn't change the core question of this***=
*
>
> debate.****
>
> Both codecs are capable of high quality video encoding, and performance**=
**
>
> numbers are comparable.****
>
> ** **
>
> The real core question is the IPR issue.****
>
> ** **
>
> The tradition of the IETF says that allowing only business models that***=
*
>
> can sustain royalty agreements and royalty payments is Bad for the Intern=
et.****
>
> ** **
>
> The dominant video codec, H.264, is a royalty-required codec.****
>
> ** **
>
> Do we switch now, or do we give up and live with royalties forever?****
>
> ** **
>
>  ** **
>
> Harald,****
>
> ** **
>
> I would like to see some references to the tradition of the IETF that****
>
> you've quoted.****
>
> ** **
>
> For the record, I agree with the sentiment, but I'd like to be able to***=
*
>
> back up the claim itself with references or explicit decisions that were*=
***
>
> made in that regard.  I'm not trying to be a thorn in your side, just****
>
> looking for citations to back up the arguments, both on and off list.****
>
> ** **
>
>  Basil, very happy to provide references!
>
> RFC 3979, a core document about IPR in the IETF, 2005:
>
> ****
>
> 8.  Evaluating Alternative Technologies in IETF Working Groups****
>
> ** **
>
>    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.****
>
>
> The complete section gives some more details, but this is the central
> quote.
>
> You may also enjoy reading the section of RFC 6569 (the guidelines that
> were followed in the OPUS work) that deals with IPR:
>
> http://tools.ietf.org/html/rfc6569#page-8
>
>
>
>
> ****
>
> -- ****
>
> Surveillance is pervasive. Go Dark.****
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--047d7ba9823233e95b04e97f90d6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hi Matthew,

On Thu,=
 Oct 24, 2013 at 9:02 AM, Matthew Kaufman (SKYPE) <matthew.kaufman=
@skype.net> wrote:






On the IPR issue, Go=
ogle reached agreement with 11 patent holders. There are at least 31 compan=
ies in the MPEG-LA H.264 pool. There is considerable technical
 overlap between VP8 and H.264.


=A0


My employer is one o=
f those in the H.264 pool, and wasn=92t one of the 11 companies Google reac=
hed an agreement with.



=A0


Draw your own conclu=
sions and take your own IPR risks.


=A0

If you would like to make an =
IPR declaration according to the IETF

IPR process, the form is available here:

https://datatracker.ietf.org/ipr/new-specif=
ic/

If you would prefer to email one,  ietf-ipr@ietf.org is the correct email address.<=
br>

Statements of the form above to WG mailing lists do not appear t=
o me qualify
as IPR statements in=A0 the IETF IPR process, at least as I=
 understand it.

regards,

Ted Hardie


=A0=






Personally I=92d rat=
her the IPR devil I know vs. the IPR devil I don=92t know.



=A0


Google could fix thi=
s for most potential users (through indemnification, similar to what Oracle=
 offers its Linux licensees) but has chosen not to. You can draw
 your own conclusion there, too.


=A0




Matthew Kaufman




=A0








From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Bo Burman

Sent: Thursday, October 24, 2013 6:27 AM

To: Harald Alvestrand; rtcweb@ietf.org


Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






=A0


1) We do agree that =
H.264 Constrained Baseline and VP8 are comparable in terms of video quality=
. But do not forget that Constrained Baseline's twin sister H.264
 Constrained High outperforms VP8 by a huge margin. This is also relevant.<=
u>


=A0


2) The "back-an=
d forth of numbers" seems to refer to Ericsson's work where we tri=
ed to make a fair comparison to evaluate the extraordinary claims from Goog=
le
 that VP8 is 70 or 40 percent better than x264. We found serious issues wit=
h the way Google performed the test, maybe the most striking were the use o=
f padding (+8% for x264) and excessive number of threads (+10% to +40% for =
x264) to add overhead to x264. That
 Google managed to remember the threading parameter only when it helped<=
/u>


VP8 (the speed test)=
 is also quite remarkable.


=A0


3) Regarding IPR, th=
is is a difficult topic, but we're not at all convinced that VP8 is roy=
alty free. For example, there is an IETF IPR disclosure (https://datatracker.ietf=
.org/ipr/2035/)
 where the IPR holder seems unwilling to license (on any terms), and 
http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html<=
/a> and

http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.h=
tml show that there are in fact ongoing litigations regarding VP8 - and=
 this is only skimming the surface of what is available in public space.=




=A0


/Bo


=A0








From:
rtcweb-bounces=
@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Harald Alvestrand

Sent: den 24 oktober 2013 13:12

To: rtcweb@ietf=
.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






=A0




On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:






On 10/23/2013 02:51 PM, Harald Alvestrand wrote:




Just a reminder:


The back-and-forth of numbers doesn't change the core question of =
this


debate.


Both codecs are capable of high quality video encoding, and performanc=
e


numbers are comparable.


=A0


The real core question is the IPR issue.


=A0


The tradition of the IETF says that allowing only business models that=



can sustain royalty agreements and royalty payments is Bad for the Int=
ernet.


=A0


The dominant video codec, H.264, is a royalty-required codec.


=A0


Do we switch now, or do we give up and live with royalties forever?=



=A0




=A0


Harald,


=A0


I would like to see some references to the tradition of the IETF that<=
u>


you've quoted.


=A0


For the record, I agree with the sentiment, but I'd like to be abl=
e to


back up the claim itself with references or explicit decisions that we=
re


made in that regard.=A0 I'm not trying to be a thorn in your side,=
 just


looking for citations to back up the arguments, both on and off list.<=
u>


=A0




Basil, very happy to pr=
ovide references!



RFC 3979, a core document about IPR in the IETF, 2005:






8.=A0 Evaluating Alternative Technologies in IETF Working Groups


=A0


=A0=A0 In general, IETF working groups prefer technologies with no kno=
wn IPR


=A0=A0 claims or, for technologies with claims against them, an offer =
of


=A0=A0 royalty-free licensing.=A0 But IETF working groups have the dis=
cretion


=A0=A0 to adopt technology with a commitment of fair and non-discrimin=
atory


=A0=A0 terms, or even with no licensing commitment, if they feel that =
this


=A0=A0 technology is superior enough to alternatives with fewer IPR cl=
aims


=A0=A0 or free licensing to outweigh the potential cost of the license=
s.




The complete section gives some more details, but this is the central quote=
.



You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:



htt=
p://tools.ietf.org/html/rfc6569#page-8












-- 


Surveillance is pervasive. Go Dark.











_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7ba9823233e95b04e97f90d6--

From fluffy@cisco.com  Thu Oct 24 10:05:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9393A11E81E2 for ; Thu, 24 Oct 2013 10:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.569
X-Spam-Level: 
X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJnqVa40fzi8 for ; Thu, 24 Oct 2013 10:05:27 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 734A911E81B4 for ; Thu, 24 Oct 2013 10:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1344; q=dns/txt; s=iport; t=1382634306; x=1383843906; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QVnFy+4nV8jcQn0uQDRtZe7dP58U+BTJwFboQ+uTtsE=; b=d0yiVmzUiEdyDJ7Q4zObKgnZT0WgOyN4ItTXO2lLp7/lwtThqk55YPgx djIk6l0ixFC1EnaMHCjP3EPUNfxr2fPj0PoKLo0bhat1qhW3n6/Rma+hw YRt7bOU7sduzmfnLElBgwAOm/JqMBVvtbBcPFum81TyTrnjlPSv74pyzt s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYGAJVSaVKtJV2Z/2dsb2JhbABZgweBDL5YgR0WbQeCJwEEOj8SASoUQicEDg2Hf7pqjXuBITGDJoENA6oRgySCKg
X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="276247576"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 24 Oct 2013 17:05:04 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9OH54Ym024931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 17:05:04 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 12:05:04 -0500
From: "Cullen Jennings (fluffy)" 
To: "rtcweb@ietf.org" 
Thread-Topic: Minor update to Agenda for RTCWEB IETF88
Thread-Index: AQHO0NsurWEVIbdN20OqpnInt/NbYQ==
Date: Thu, 24 Oct 2013 17:05:03 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <87DFB11CD4D15149B9AEEC640CE07E22@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [rtcweb] Minor update to Agenda for RTCWEB IETF88
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 17:05:44 -0000

We added a backup topic on thursday if we end up with extra time.=20

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


Draft Agenda Version #2 - Oct 24


Monday 14:50 to 17:20=20

Chair / Agenda bash (10 min)

JSEP (50 min) - Justin=20
	draft-ietf-rtcweb-jsep-05.txt

Data channel document (40 min) (???)
	draft-ietf-rtcweb-data-channel-06
	draft-ietf-rtcweb-data-protocol-01

Security Documents (20 min) Eric Rescorla=20
- might remove this section if not needed
	draft-ietf-rtcweb-security-05
	draft-ietf-rtcweb-security-arch-07
- deal with any WGLC issues=20

RTP Usages (30 min) (???)
	draft-ietf-rtcweb-rtp-usage-10
- mapping to API considerations
- simulcast
- any need for priority mappings=20
- other open issues



Thursday 13:00 to 15:00
=20
Frame discussions, process, and agenda around MTI video codec: 10 min (chai=
rs)

VP8 presentation with clarify questions -  25 min (???)
	- draft-alvestrand-rtcweb-vp8-02

H.264 presentation with clarify questions - 25 min (???)
	- draft-burman-rtcweb-h264-proposal-03

Microphone discussions of pro/cons - 40 min (all)

Call the question - 10 min ( chairs )=20

Wrap up and next steps - 10 min (chairs)

Celebrate reaching a successful decision


Backup Topics if time permitting:
	draft-ietf-rtcweb-transports-01 - time permitting (???)



From Michael.Tuexen@lurchi.franken.de  Thu Oct 24 10:07:12 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A113511E8347 for ; Thu, 24 Oct 2013 10:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsplYlq4hDIO for ; Thu, 24 Oct 2013 10:07:11 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 069D311E81E2 for ; Thu, 24 Oct 2013 10:06:24 -0700 (PDT)
Received: from [192.168.1.200] (p508F0D8F.dip0.t-ipconnect.de [80.143.13.143]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1D8021C0C069B; Thu, 24 Oct 2013 19:06:12 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen 
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>
Date: Thu, 24 Oct 2013 19:06:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>
To: "Ejzak, Richard P (Richard)" 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 17:07:13 -0000

On Oct 24, 2013, at 6:59 PM, "Ejzak, Richard P (Richard)" =
 wrote:

> I have a question about draft-ietf-rtcweb-data-protocol-01.  The =
browser uses DTLS role to determine which side uses even or odd stream =
identifiers.  What does the application on the side sending the initial =
SDP offer that establishes the peer connection do if it wants to create =
data channels before the DTLS role can be determined?  How does the =
browser know if the application tries to select a disallowed stream id?  =
If the application asks the browser to select the stream identifier =
before DTLS role can be determined, what does the browser do?
Hmm. You can't setup a data channel before you have setup the SCTP =
association which you
can't setup before the DTLS handshake is complete. So how do you want to =
setup a data channel
before knowing the DTLS role?

Best regards
Michael
>=20
> Thanks,
> Richard
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20


From juberti@google.com  Thu Oct 24 11:05:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4DA11E81AB for ; Thu, 24 Oct 2013 11:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3hblPoLY2un for ; Thu, 24 Oct 2013 11:05:24 -0700 (PDT)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 17BDA11E81C5 for ; Thu, 24 Oct 2013 11:05:22 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id jy13so1850794veb.37 for ; Thu, 24 Oct 2013 11:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WWaR8R0Vj1Bh3XpQwF73T8aUzCru13Kts8LyRhzIqbg=; b=MBQOYGjH2i1gP9G756RhU+yv4RHoqxsXfLIh3qSqevn3D4rc1WYnGmCey8y5p+85Yp 9Ja48dWnmwfXzJKPZYg12wibJRob00AvPGOUk6wbhh2or/j7LT6Eoaot+3MxdXn5lOdC /ChZ9dRanY4R6XqbcopSEqAuMKclk1ffCGSyB5PfFvm/p69YE4jjAm6BnSPIc1kuBXvm DL4VU0x2wMoyDnNvqFJBV4Q1c7QEzr0hN6FTAbIiXN8pbrOvrbahNQZZEP6E4jMtVx4/ +IYwWfJeiHGx5/G1aVc31o4CwiO1LXo3zEwSBVI8E9JhO4aLWzvGpsrSnR4Dxuub6eGT IAkw==
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=WWaR8R0Vj1Bh3XpQwF73T8aUzCru13Kts8LyRhzIqbg=; b=VbZsdmxun0pLdOEwBMxRW+z19mnm9jzDwyL1JIj06vgE6eGSfRXcTjdZCcJh9NeGXM ENtebcFdedQLaco1SRdUthMwe0inHDy280YfDqDPQgEHlpR3kRVYImgksEnyoEOE6luF Ml5ldhutPNsT4aGG1nw7AWyvn+94prsKVDLnkuj2wGcHQ6nWv/KRQGpVqVlwmvMxQuex +AGhw4C+T2zbKm4LKdycpmcF21uArioTtajZdALBJDswPOFodIlKoyBlEZY8fyxxyjDw mNIGEIFSVxazjFy38BmSyjRY3R7KPBIH0FUGw2IWcJf7Nl2O5Y9hAyH7p/8KLY43SBtb CIgA==
X-Gm-Message-State: ALoCoQkNy7FE3g4a8u1Mu3kwdyIyJ5BnUNDm0EvUmNFvmbAaBnBcqfiBhd6j32WWq7yJqGag84LQMeX2KjbSeHSk3g3/++nduDrXHg8TzW2ZFCKJeR416JLR7krH88wXaO2nfGmYNEoqeNF1D5sO28Zov1qpmYZYZkH6IgAwXnUE5KZOvdTlK6F7VD3G4NLjkcOu6X/tU3o+
X-Received: by 10.220.173.134 with SMTP id p6mr1648352vcz.36.1382637922471; Thu, 24 Oct 2013 11:05:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 24 Oct 2013 11:05:02 -0700 (PDT)
In-Reply-To: 
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com> 
From: Justin Uberti 
Date: Thu, 24 Oct 2013 11:05:02 -0700
Message-ID: 
To: Michael Tuexen 
Content-Type: multipart/alternative; boundary=089e0158b15438ecc604e9807ab4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 18:05:31 -0000

--089e0158b15438ecc604e9807ab4
Content-Type: text/plain; charset=UTF-8

In Chrome, the stream identifier isn't chosen until the DTLS roles are
known; as Michael says, this is fine because the DTLS roles are known
before the SCTP association starts up.

Note that the DTLS roles can change during the lifetime of the call, so the
initial role ends up being the one that is used.


On Thu, Oct 24, 2013 at 10:06 AM, Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

> On Oct 24, 2013, at 6:59 PM, "Ejzak, Richard P (Richard)" <
> richard.ejzak@alcatel-lucent.com> wrote:
>
> > I have a question about draft-ietf-rtcweb-data-protocol-01.  The browser
> uses DTLS role to determine which side uses even or odd stream identifiers.
>  What does the application on the side sending the initial SDP offer that
> establishes the peer connection do if it wants to create data channels
> before the DTLS role can be determined?  How does the browser know if the
> application tries to select a disallowed stream id?  If the application
> asks the browser to select the stream identifier before DTLS role can be
> determined, what does the browser do?
> Hmm. You can't setup a data channel before you have setup the SCTP
> association which you
> can't setup before the DTLS handshake is complete. So how do you want to
> setup a data channel
> before knowing the DTLS role?
>
> Best regards
> Michael
> >
> > Thanks,
> > Richard
> >
> > _______________________________________________
> > 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
>

--089e0158b15438ecc604e9807ab4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


In Chrome, the stream identifier isn't chosen until th=
e DTLS roles are known; as Michael says, this is fine because the DTLS role=
s are known before the SCTP association starts up.

Note =
that the DTLS roles can change during the lifetime of the call, so the init=
ial role ends up being the one that is used.





On Thu,=
 Oct 24, 2013 at 10:06 AM, Michael Tuexen <Michael.Tuexen@l=
urchi.franken.de> wrote:



On Oct 24, 2013, at 6:59 P=
M, "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> wrote:





> I have a question about draft-ietf-rtcweb-data-protocol-01. =C2=A0The =
browser uses DTLS role to determine which side uses even or odd stream iden=
tifiers. =C2=A0What does the application on the side sending the initial SD=
P offer that establishes the peer connection do if it wants to create data =
channels before the DTLS role can be determined? =C2=A0How does the browser=
 know if the application tries to select a disallowed stream id? =C2=A0If t=
he application asks the browser to select the stream identifier before DTLS=
 role can be determined, what does the browser do?




Hmm. You can't setup a data channel before you have setup the SCT=
P association which you

can't setup before the DTLS handshake is complete. So how do you want t=
o setup a data channel

before knowing the DTLS role?



Best regards

Michael


>

> Thanks,

> Richard

>

> _______________________________________________

> 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





--089e0158b15438ecc604e9807ab4--

From richard.ejzak@alcatel-lucent.com  Thu Oct 24 11:36:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0029511E81F0 for ; Thu, 24 Oct 2013 11:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.569
X-Spam-Level: 
X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWzJHQomLyaK for ; Thu, 24 Oct 2013 11:36:45 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 67AB311E8198 for ; Thu, 24 Oct 2013 11:36:42 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9OIae6k028996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Oct 2013 13:36:40 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r9OIacbH027420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 14:36:40 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Thu, 24 Oct 2013 14:36:39 -0400
From: "Ejzak, Richard P (Richard)" 
To: Justin Uberti , Michael Tuexen 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQgABIioCAABByAP//ww2g
Date: Thu, 24 Oct 2013 18:36:38 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>  
In-Reply-To: 
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: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D86C8DBUS70UWXCHMBA04z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 18:36:54 -0000

--_000_03FBA798AC24E3498B74F47FD082A92F3D86C8DBUS70UWXCHMBA04z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SnVzdGluLCBNaWNoYWVsLA0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbnMuICBPbmUgbW9y
ZSBxdWVzdGlvbi4gIFdoYXQgaGFwcGVucyBpZiB0aGUgYXBwbGljYXRpb24gdHJpZXMgdG8gc2Vs
ZWN0IGEgc3RyZWFtIGlkIGJlZm9yZSB0aGUgRFRMUyByb2xlIGlzIGtub3duIGFuZCBpdCBlbmRz
IHVwIHNlbGVjdGluZyBhbiBpbnZhbGlkIG9uZT8NCg0KTWljaGFlbCwNCldoaWxlIGl04oCZcyB0
cnVlIHRoYXQgdGhlIGRhdGEgY2hhbm5lbCBjb250cm9sIHByb3RvY29sIGNhbm5vdCBvcGVuIHRo
ZSBjaGFubmVsIHdpdGggdGhlIHBlZXIgYmVmb3JlIHRoZSBEVExTIHJvbGUgaXMga25vd24sIHRo
ZSBBUEkgYWxsb3dzIHRoZSBhcHBsaWNhdGlvbiB0byBjcmVhdGUgdGhlIGRhdGEgY2hhbm5lbCBi
ZWZvcmUgdGhlIERUTFMgcm9sZSBpcyBrbm93biwgaW4gd2hpY2ggY2FzZSB0aGUgc2VuZGluZyBv
ZiB0aGUgT3BlbiBtZXNzYWdlIG11c3Qgd2FpdCB1bnRpbCB0aGUgU0NUUCBhc3NvY2lhdGlvbiBp
cyBlc3RhYmxpc2hlZC4gIEkgd2FudCB0byBrbm93IHdoYXQgdGhlIGFwcGxpY2F0aW9uIGlzIHN1
cHBvc2VkIHRvIGRvIGl0IGlmIG5lZWRzIHRvIGNyZWF0ZSBkYXRhIGNoYW5uZWxzIHdpdGggcHJl
c2VsZWN0ZWQgc3RyZWFtIGlkcyBiZWZvcmUgdGhlIERUTFMgcm9sZSBpcyBrbm93bi4gIFRoaXMg
c2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCB0aGUgc3BlYyBzaG91bGQgbWFrZSBjbGVhciByYXRo
ZXIgdGhhbiBsZWF2aW5nIGl0IHRvIGltcGxlbWVudGF0aW9uLg0KDQpUaGFua3MsDQpSaWNoYXJk
DQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50
OiBUaHVyc2RheSwgT2N0b2JlciAyNCwgMjAxMyAxOjA1IFBNDQpUbzogTWljaGFlbCBUdWV4ZW4N
CkNjOiBFanphaywgUmljaGFyZCBQIChSaWNoYXJkKTsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0
OiBSZTogW3J0Y3dlYl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2Nv
bC0wMS50eHQNCg0KSW4gQ2hyb21lLCB0aGUgc3RyZWFtIGlkZW50aWZpZXIgaXNuJ3QgY2hvc2Vu
IHVudGlsIHRoZSBEVExTIHJvbGVzIGFyZSBrbm93bjsgYXMgTWljaGFlbCBzYXlzLCB0aGlzIGlz
IGZpbmUgYmVjYXVzZSB0aGUgRFRMUyByb2xlcyBhcmUga25vd24gYmVmb3JlIHRoZSBTQ1RQIGFz
c29jaWF0aW9uIHN0YXJ0cyB1cC4NCg0KTm90ZSB0aGF0IHRoZSBEVExTIHJvbGVzIGNhbiBjaGFu
Z2UgZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgY2FsbCwgc28gdGhlIGluaXRpYWwgcm9sZSBl
bmRzIHVwIGJlaW5nIHRoZSBvbmUgdGhhdCBpcyB1c2VkLg0KDQpPbiBUaHUsIE9jdCAyNCwgMjAx
MyBhdCAxMDowNiBBTSwgTWljaGFlbCBUdWV4ZW4gPE1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFu
a2VuLmRlPG1haWx0bzpNaWNoYWVsLlR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZT4+IHdyb3RlOg0K
T24gT2N0IDI0LCAyMDEzLCBhdCA2OjU5IFBNLCAiRWp6YWssIFJpY2hhcmQgUCAoUmljaGFyZCki
IDxyaWNoYXJkLmVqemFrQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86cmljaGFyZC5lanpha0Bh
bGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCg0KPiBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBk
cmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sLTAxLiAgVGhlIGJyb3dzZXIgdXNlcyBEVExT
IHJvbGUgdG8gZGV0ZXJtaW5lIHdoaWNoIHNpZGUgdXNlcyBldmVuIG9yIG9kZCBzdHJlYW0gaWRl
bnRpZmllcnMuICBXaGF0IGRvZXMgdGhlIGFwcGxpY2F0aW9uIG9uIHRoZSBzaWRlIHNlbmRpbmcg
dGhlIGluaXRpYWwgU0RQIG9mZmVyIHRoYXQgZXN0YWJsaXNoZXMgdGhlIHBlZXIgY29ubmVjdGlv
biBkbyBpZiBpdCB3YW50cyB0byBjcmVhdGUgZGF0YSBjaGFubmVscyBiZWZvcmUgdGhlIERUTFMg
cm9sZSBjYW4gYmUgZGV0ZXJtaW5lZD8gIEhvdyBkb2VzIHRoZSBicm93c2VyIGtub3cgaWYgdGhl
IGFwcGxpY2F0aW9uIHRyaWVzIHRvIHNlbGVjdCBhIGRpc2FsbG93ZWQgc3RyZWFtIGlkPyAgSWYg
dGhlIGFwcGxpY2F0aW9uIGFza3MgdGhlIGJyb3dzZXIgdG8gc2VsZWN0IHRoZSBzdHJlYW0gaWRl
bnRpZmllciBiZWZvcmUgRFRMUyByb2xlIGNhbiBiZSBkZXRlcm1pbmVkLCB3aGF0IGRvZXMgdGhl
IGJyb3dzZXIgZG8/DQpIbW0uIFlvdSBjYW4ndCBzZXR1cCBhIGRhdGEgY2hhbm5lbCBiZWZvcmUg
eW91IGhhdmUgc2V0dXAgdGhlIFNDVFAgYXNzb2NpYXRpb24gd2hpY2ggeW91DQpjYW4ndCBzZXR1
cCBiZWZvcmUgdGhlIERUTFMgaGFuZHNoYWtlIGlzIGNvbXBsZXRlLiBTbyBob3cgZG8geW91IHdh
bnQgdG8gc2V0dXAgYSBkYXRhIGNoYW5uZWwNCmJlZm9yZSBrbm93aW5nIHRoZSBEVExTIHJvbGU/
DQoNCkJlc3QgcmVnYXJkcw0KTWljaGFlbA0KPg0KPiBUaGFua3MsDQo+IFJpY2hhcmQNCj4NCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2Vi
IG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4N
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWls
aW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K

--_000_03FBA798AC24E3498B74F47FD082A92F3D86C8DBUS70UWXCHMBA04z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu
MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94
bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs
aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+SnVzdGluLCBNaWNoYWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFu
a3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9ucy4mbmJzcDsgT25lIG1vcmUgcXVlc3Rpb24uJm5ic3A7
IFdoYXQgaGFwcGVucyBpZiB0aGUgYXBwbGljYXRpb24gdHJpZXMgdG8gc2VsZWN0IGEgc3RyZWFt
IGlkIGJlZm9yZSB0aGUgRFRMUyByb2xlIGlzIGtub3duIGFuZCBpdCBlbmRzIHVwDQogc2VsZWN0
aW5nIGFuIGludmFsaWQgb25lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbCw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+V2hpbGUgaXTigJlzIHRydWUgdGhhdCB0aGUgZGF0YSBjaGFubmVsIGNvbnRy
b2wgcHJvdG9jb2wgY2Fubm90IG9wZW4gdGhlIGNoYW5uZWwgd2l0aCB0aGUgcGVlciBiZWZvcmUg
dGhlIERUTFMgcm9sZSBpcyBrbm93biwgdGhlIEFQSSBhbGxvd3MgdGhlIGFwcGxpY2F0aW9uIHRv
DQogY3JlYXRlIHRoZSBkYXRhIGNoYW5uZWwgYmVmb3JlIHRoZSBEVExTIHJvbGUgaXMga25vd24s
IGluIHdoaWNoIGNhc2UgdGhlIHNlbmRpbmcgb2YgdGhlIE9wZW4gbWVzc2FnZSBtdXN0IHdhaXQg
dW50aWwgdGhlIFNDVFAgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQuJm5ic3A7IEkgd2FudCB0
byBrbm93IHdoYXQgdGhlIGFwcGxpY2F0aW9uIGlzIHN1cHBvc2VkIHRvIGRvIGl0IGlmIG5lZWRz
IHRvIGNyZWF0ZSBkYXRhIGNoYW5uZWxzIHdpdGggcHJlc2VsZWN0ZWQNCiBzdHJlYW0gaWRzIGJl
Zm9yZSB0aGUgRFRMUyByb2xlIGlzIGtub3duLiZuYnNwOyBUaGlzIHNlZW1zIGxpa2Ugc29tZXRo
aW5nIHRoYXQgdGhlIHNwZWMgc2hvdWxkIG1ha2UgY2xlYXIgcmF0aGVyIHRoYW4gbGVhdmluZyBp
dCB0byBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+UmljaGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0K
PGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDI0LCAyMDEzIDE6MDUgUE08YnI+DQo8Yj5U
bzo8L2I+IE1pY2hhZWwgVHVleGVuPGJyPg0KPGI+Q2M6PC9iPiBFanphaywgUmljaGFyZCBQIChS
aWNoYXJkKTsgcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2Vi
XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sLTAxLnR4dDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBDaHJv
bWUsIHRoZSBzdHJlYW0gaWRlbnRpZmllciBpc24ndCBjaG9zZW4gdW50aWwgdGhlIERUTFMgcm9s
ZXMgYXJlIGtub3duOyBhcyBNaWNoYWVsIHNheXMsIHRoaXMgaXMgZmluZSBiZWNhdXNlIHRoZSBE
VExTIHJvbGVzIGFyZSBrbm93biBiZWZvcmUgdGhlIFNDVFAgYXNzb2NpYXRpb24gc3RhcnRzIHVw
LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0aGF0
IHRoZSBEVExTIHJvbGVzIGNhbiBjaGFuZ2UgZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgY2Fs
bCwgc28gdGhlIGluaXRpYWwgcm9sZSBlbmRzIHVwIGJlaW5nIHRoZSBvbmUgdGhhdCBpcyB1c2Vk
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgT2N0IDI0LCAyMDEzIGF0IDEwOjA2
IEFNLCBNaWNoYWVsIFR1ZXhlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuVHVleGVuQGx1
cmNoaS5mcmFua2VuLmRlIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZy
YW5rZW4uZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5PbiBPY3QgMjQsIDIwMTMsIGF0IDY6NTkgUE0sICZxdW90O0VqemFrLCBSaWNo
YXJkIFAgKFJpY2hhcmQpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFyZC5lanpha0Bh
bGNhdGVsLWx1Y2VudC5jb20iPnJpY2hhcmQuZWp6YWtAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZn
dDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBkcmFmdC1p
ZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sLTAxLiAmbmJzcDtUaGUgYnJvd3NlciB1c2VzIERUTFMg
cm9sZSB0byBkZXRlcm1pbmUgd2hpY2ggc2lkZSB1c2VzIGV2ZW4gb3Igb2RkIHN0cmVhbSBpZGVu
dGlmaWVycy4gJm5ic3A7V2hhdCBkb2VzIHRoZSBhcHBsaWNhdGlvbiBvbiB0aGUgc2lkZSBzZW5k
aW5nIHRoZSBpbml0aWFsIFNEUCBvZmZlciB0aGF0IGVzdGFibGlzaGVzIHRoZSBwZWVyIGNvbm5l
Y3Rpb24NCiBkbyBpZiBpdCB3YW50cyB0byBjcmVhdGUgZGF0YSBjaGFubmVscyBiZWZvcmUgdGhl
IERUTFMgcm9sZSBjYW4gYmUgZGV0ZXJtaW5lZD8gJm5ic3A7SG93IGRvZXMgdGhlIGJyb3dzZXIg
a25vdyBpZiB0aGUgYXBwbGljYXRpb24gdHJpZXMgdG8gc2VsZWN0IGEgZGlzYWxsb3dlZCBzdHJl
YW0gaWQ/ICZuYnNwO0lmIHRoZSBhcHBsaWNhdGlvbiBhc2tzIHRoZSBicm93c2VyIHRvIHNlbGVj
dCB0aGUgc3RyZWFtIGlkZW50aWZpZXIgYmVmb3JlIERUTFMgcm9sZSBjYW4gYmUNCiBkZXRlcm1p
bmVkLCB3aGF0IGRvZXMgdGhlIGJyb3dzZXIgZG8/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkhtbS4gWW91IGNhbid0IHNldHVwIGEgZGF0YSBjaGFubmVsIGJl
Zm9yZSB5b3UgaGF2ZSBzZXR1cCB0aGUgU0NUUCBhc3NvY2lhdGlvbiB3aGljaCB5b3U8YnI+DQpj
YW4ndCBzZXR1cCBiZWZvcmUgdGhlIERUTFMgaGFuZHNoYWtlIGlzIGNvbXBsZXRlLiBTbyBob3cg
ZG8geW91IHdhbnQgdG8gc2V0dXAgYSBkYXRhIGNoYW5uZWw8YnI+DQpiZWZvcmUga25vd2luZyB0
aGUgRFRMUyByb2xlPzxicj4NCjxicj4NCkJlc3QgcmVnYXJkczxicj4NCjxzcGFuIGNsYXNzPSJo
b2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5NaWNoYWVsPC9zcGFuPjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0Ozxi
cj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgUmljaGFyZDxicj4NCiZndDs8YnI+DQomZ3Q7IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBy
dGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu
b3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCiZndDs8YnI+DQo8
YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N
CnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3Jn
Ij5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_03FBA798AC24E3498B74F47FD082A92F3D86C8DBUS70UWXCHMBA04z_--

From Michael.Tuexen@lurchi.franken.de  Thu Oct 24 12:20:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA9B11E83A0 for ; Thu, 24 Oct 2013 12:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level: 
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6ekkNyO8xtz for ; Thu, 24 Oct 2013 12:20:38 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 09FAB11E83AA for ; Thu, 24 Oct 2013 12:20:35 -0700 (PDT)
Received: from [192.168.1.101] (p508F0D8F.dip0.t-ipconnect.de [80.143.13.143]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4E6201C0C069B; Thu, 24 Oct 2013 21:20:33 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen 
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>
Date: Thu, 24 Oct 2013 21:20:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>
To: "Ejzak, Richard P (Richard)" 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 19:20:39 -0000

On Oct 24, 2013, at 8:36 PM, "Ejzak, Richard P (Richard)" =
 wrote:

> Justin, Michael,
> Thanks for the clarifications.  One more question.  What happens if =
the application tries to select a stream id before the DTLS role is =
known and it ends up selecting an invalid one?
I'm not completely familiar with the JS API, but if you want to select a =
stream, aren't
you managing the stream completely on your own. I think the DTLS role =
stuff is only
relevant if the streams are managed by the browser.
> =20
> Michael,
> While it=92s true that the data channel control protocol cannot open =
the channel with the peer before the DTLS role is known, the API allows =
the application to create the data channel before the DTLS role is =
known, in which case the sending of the Open message must wait until the =
SCTP association is established.  I want to know what the application is =
supposed to do it if needs to create data channels with preselected =
stream ids before the DTLS role is known.  This seems like something =
that the spec should make clear rather than leaving it to =
implementation.
Can you assign the stream ID in the API? Could you point me to the text?

Best regards
Michael
> =20
> Thanks,
> Richard
> =20
> From: Justin Uberti [mailto:juberti@google.com]=20
> Sent: Thursday, October 24, 2013 1:05 PM
> To: Michael Tuexen
> Cc: Ejzak, Richard P (Richard); rtcweb@ietf.org
> Subject: Re: [rtcweb] I-D Action: =
draft-ietf-rtcweb-data-protocol-01.txt
> =20
> In Chrome, the stream identifier isn't chosen until the DTLS roles are =
known; as Michael says, this is fine because the DTLS roles are known =
before the SCTP association starts up.
> =20
> Note that the DTLS roles can change during the lifetime of the call, =
so the initial role ends up being the one that is used.
> =20
>=20
> On Thu, Oct 24, 2013 at 10:06 AM, Michael Tuexen =
 wrote:
> On Oct 24, 2013, at 6:59 PM, "Ejzak, Richard P (Richard)" =
 wrote:
>=20
> > I have a question about draft-ietf-rtcweb-data-protocol-01.  The =
browser uses DTLS role to determine which side uses even or odd stream =
identifiers.  What does the application on the side sending the initial =
SDP offer that establishes the peer connection do if it wants to create =
data channels before the DTLS role can be determined?  How does the =
browser know if the application tries to select a disallowed stream id?  =
If the application asks the browser to select the stream identifier =
before DTLS role can be determined, what does the browser do?
> Hmm. You can't setup a data channel before you have setup the SCTP =
association which you
> can't setup before the DTLS handshake is complete. So how do you want =
to setup a data channel
> before knowing the DTLS role?
>=20
> Best regards
> Michael
> >
> > Thanks,
> > Richard
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =20


From basilgohar@librevideo.org  Thu Oct 24 12:34:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7487211E8145 for ; Thu, 24 Oct 2013 12:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGAfsRwbqaBn for ; Thu, 24 Oct 2013 12:34:40 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEEF11E810B for ; Thu, 24 Oct 2013 12:34:40 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id BFCFE8648D7 for ; Thu, 24 Oct 2013 15:34:39 -0400 (EDT)
Message-ID: <5269764C.4030801@librevideo.org>
Date: Thu, 24 Oct 2013 15:34:36 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 19:34:45 -0000

On 10/24/2013 12:02 PM, Matthew Kaufman (SKYPE) wrote:
> On the IPR issue, Google reached agreement with 11 patent holders. There
> are at least 31 companies in the MPEG-LA H.264 pool. There is
> considerable technical overlap between VP8 and H.264.
> 
> My employer is one of those in the H.264 pool, and wasn’t one of the 11
> companies Google reached an agreement with.
> 
> Draw your own conclusions and take your own IPR risks.
> 
> Personally I’d rather the IPR devil I know vs. the IPR devil I don’t know.
> 
> Google could fix this for most potential users (through indemnification,
> similar to what Oracle offers its Linux licensees) but has chosen not
> to. You can draw your own conclusion there, too.
> 
> Matthew Kaufman

There are no conclusions to draw due to lack of sufficient evidence for
anything actionable.  IPR FUD has delayed the adoption of many free,
non-royalty-bearing formats for too long.  And, again, the IPR "devil we
know" is meaningless, because there are still IP litigation threats even
for H.264, MP3, and many other patented, royalty-bearing formats.

So, it contributes little to nothing to the discussion on IPR grounds if
a substantial declaration, as Ted has advised, is not taken, and such
claims should really be discounted in any serious consideration when
weighing options between formats.

-- 
Libre Video
http://librevideo.org

From richard.ejzak@alcatel-lucent.com  Thu Oct 24 13:38:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D9221F9ED4 for ; Thu, 24 Oct 2013 13:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.573
X-Spam-Level: 
X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEjYHRXrVZV9 for ; Thu, 24 Oct 2013 13:38:40 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A021F9E7C for ; Thu, 24 Oct 2013 13:38:39 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9OKcZdC012881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Oct 2013 15:38:35 -0500 (CDT)
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 r9OKcZX1008991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 16:38:35 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 24 Oct 2013 16:38:35 -0400
From: "Ejzak, Richard P (Richard)" 
To: Michael Tuexen 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQgABIioCAABByAP//ww2ggABSCoD//8IcAA==
Date: Thu, 24 Oct 2013 20:38:34 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de>
In-Reply-To: <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 20:38:58 -0000

Hi Michael,

> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> Sent: Thursday, October 24, 2013 2:21 PM

> On Oct 24, 2013, at 8:36 PM, "Ejzak, Richard P (Richard)"
>  wrote:
>=20
> > Justin, Michael,
> > Thanks for the clarifications.  One more question.  What happens if
> the application tries to select a stream id before the DTLS role is
> known and it ends up selecting an invalid one?
> I'm not completely familiar with the JS API, but if you want to select
> a stream, aren't you managing the stream completely on your own. I
> think the DTLS role stuff is only relevant if the streams are managed
> by the browser.

If this is the intent then that clarification would be very useful.  Readin=
g the API text again, it is clear that the browser only manages stream ids =
that it selects.  Does this mean that the browser stream id selection optio=
n is not compatible with the application stream id selection option?  Putti=
ng it more precisely, should we require that the application not be allowed=
 to select stream ids prior to determining DTLS role if it expects that eit=
her side might use the browser stream id selection option?  It would be eas=
ier if the even/odd rule could be determined earlier than DTLS role establi=
shment so that the application could use the same even/odd assignment rule =
for early data channel creation.

> >
> > Michael,
> > While it's true that the data channel control protocol cannot open
> the channel with the peer before the DTLS role is known, the API allows
> the application to create the data channel before the DTLS role is
> known, in which case the sending of the Open message must wait until
> the SCTP association is established.  I want to know what the
> application is supposed to do it if needs to create data channels with
> preselected stream ids before the DTLS role is known.  This seems like
> something that the spec should make clear rather than leaving it to
> implementation.
> Can you assign the stream ID in the API? Could you point me to the
> text?

http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute in the =
RTCDataChannelInit dictionary that must be the equivalent of the "stream id=
entifier".  No other interpretation makes sense to me but please correct me=
 if I am wrong.  Note in particular the following text within the descripti=
on of the createDataChannel procedure (my parenthetical): "If the value of =
the id attribute is null, initialize it to a value generated by the user ag=
ent (browser), according to the WebRTC DataChannel Protocol specification, =
and skip to the next step. Otherwise, if the value of the id attribute is t=
aken by an existing RTCDataChannel, throw a TBD exception and abort these s=
teps."  So "id" must refer to "stream identifier" since there is no other i=
d in your draft that it could refer to.

If I'm right, then it would be good if it were made clear that id refers to=
 "stream identifier", but that is a w3c issue.  Quoting from 5.2.1 (my pare=
ntheticals for clarity): "The id was either assigned by the user agent (bro=
wser) at channel creation time (not channel opening time) or selected by th=
e script (application). The attribute MUST return the value to which it was=
 set when the RTCDataChannel was created (not opened)."

I used the wrong terminology in my earlier mail when I referred to "open" o=
f the data channel when I meant "creation".  Since the data channel can be =
"created" before DTLS role is known and before the data channel can be open=
ed, the quoted text above would seem to indicate that the application can n=
ever determine the stream id actually assigned to the data channel if id ca=
n't be determined at time of creation.  Justin implied that the chrome beha=
vior does not conform to this description.  Comment, Justin?

It still seems to me that a change in the rule describing even/odd stream i=
d assignment would be a good idea.

BR, Richard

From cowwoc@bbs.darktech.org  Thu Oct 24 13:47:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B76911E8387 for ; Thu, 24 Oct 2013 13:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.291
X-Spam-Level: 
X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=-2.692, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LA0SpvsT6EO for ; Thu, 24 Oct 2013 13:47:47 -0700 (PDT)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34B3A11E8392 for ; Thu, 24 Oct 2013 13:47:33 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id 6so1828486qeb.3 for ; Thu, 24 Oct 2013 13:47:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ir1yPg/YXaDhO8kVIJoJ2HaEgKLivYHmIBqmuX/2v1I=; b=Z+S7nH7mklQBXBkkn1mTC1hUZCJg5Gn+f5b4N9LvOoIBETCXhx2xwPgZRmdFpBoXZC GHP6bxlFMS9NRkbFGylMjbrzUC7RHhORwhgt2yZoZK4I/nfVa956ETNv2BuiDZ2cWP+u ptTdOFXmtx6LQW37XrdFI+ZMM5L2NLO/yQjBm/mgX66nVcbUSxshMgeFydjqMvvysAhz 7OLIoFo1PI+QRvDBs2jb5XTwX11FjgUUUe4Q8nUToeuQhnfek+fKg02CYUW3IIidcS4K vMgn9zwhLu5jh/tTomux/SDrC6DK0crpsSLtHl5xysJYnnTyvndi656amYXWrFfU8xhf eVRA==
X-Gm-Message-State: ALoCoQmLoZkrxH/+mGOJuIMIx/mVx/m0hw0dDJeu4rH/Mad1ypqVOfZqcU5EsII3u/wGzXBmqB7X
X-Received: by 10.229.109.193 with SMTP id k1mr6214544qcp.9.1382647652596; Thu, 24 Oct 2013 13:47:32 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id fx6sm6295618qeb.1.2013.10.24.13.47.31 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Oct 2013 13:47:31 -0700 (PDT)
Message-ID: <52698758.5040404@bbs.darktech.org>
Date: Thu, 24 Oct 2013 16:47:20 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>		 <5269764C.4030801@librevideo.org>
In-Reply-To: <5269764C.4030801@librevideo.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 20:47:53 -0000

On 24/10/2013 3:34 PM, Basil Mohamed Gohar wrote:
> On 10/24/2013 12:02 PM, Matthew Kaufman (SKYPE) wrote:
>> On the IPR issue, Google reached agreement with 11 patent holders. There
>> are at least 31 companies in the MPEG-LA H.264 pool. There is
>> considerable technical overlap between VP8 and H.264.
>>
>> My employer is one of those in the H.264 pool, and wasn’t one of the 11
>> companies Google reached an agreement with.
>>
>> Draw your own conclusions and take your own IPR risks.
>>
>> Personally I’d rather the IPR devil I know vs. the IPR devil I don’t know.
>>
>> Google could fix this for most potential users (through indemnification,
>> similar to what Oracle offers its Linux licensees) but has chosen not
>> to. You can draw your own conclusion there, too.
>>
>> Matthew Kaufman
> There are no conclusions to draw due to lack of sufficient evidence for
> anything actionable.  IPR FUD has delayed the adoption of many free,
> non-royalty-bearing formats for too long.  And, again, the IPR "devil we
> know" is meaningless, because there are still IP litigation threats even
> for H.264, MP3, and many other patented, royalty-bearing formats.
>
> So, it contributes little to nothing to the discussion on IPR grounds if
> a substantial declaration, as Ted has advised, is not taken, and such
> claims should really be discounted in any serious consideration when
> weighing options between formats.

     I would like to point out that we still have the option of 
mandating the use of an older codec whose IPR has expired (and let 
clients upgrade to VP8 or H264 as they fit).

     But if the community rejects this approach, then I agree that this 
should not hold back the use of VP8.

Gili

From silviapfeiffer1@gmail.com  Thu Oct 24 15:01:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9A11E824A for ; Thu, 24 Oct 2013 15:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEcX3bqReRCT for ; Thu, 24 Oct 2013 15:01:40 -0700 (PDT)
Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7260B11E8245 for ; Thu, 24 Oct 2013 15:01:37 -0700 (PDT)
Received: by mail-oa0-f53.google.com with SMTP id n12so153389oag.26 for ; Thu, 24 Oct 2013 15:01:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AnLHYVbsLv3S5u5La2/Wfituam7DHNVj8TUV8aK1yzg=; b=stl906x2ZeoijPsKEYViWBrw+76NpI1CnGXuudvEcYEmeQj7Y3xd7LqRMdeqIF6QHZ aUVcqzFEQ+53/ZkDPMZTsJnBU7Mzw1xGoo1WdYVbm43lrngk/hQRpWHDSCj399mia8WK y4atXthMJbV1NUK5Z70UilUAkw7Nl3MUvvCbUA7/c3OzCoPS1YDxI0KP0dlJRN9sov3i 0kNM2Uyl+7js4FwrLtTLQY+UHBja0snniQWGP6WnNGsRYE4cVKVTevMoZblKL2tYaKB4 wmCdIJC/ZBpNQ2fjq4u1Eq4L9LKbi8qdEBU1UpQdA67GpBEY8XrJgxCV6gJJlmIL/2u4 l4tQ==
MIME-Version: 1.0
X-Received: by 10.60.42.168 with SMTP id p8mr259137oel.73.1382652096994; Thu, 24 Oct 2013 15:01:36 -0700 (PDT)
Received: by 10.76.94.40 with HTTP; Thu, 24 Oct 2013 15:01:36 -0700 (PDT)
Received: by 10.76.94.40 with HTTP; Thu, 24 Oct 2013 15:01:36 -0700 (PDT)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BE4E2@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <526837B5.8020507@bbs.darktech.org> <52683A1C.1090506@librevideo.org>  <949EF20990823C4C85C18D59AA11AD8B0BE4E2@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Fri, 25 Oct 2013 09:01:36 +1100
Message-ID: 
From: Silvia Pfeiffer 
To: "DRAGE, Keith (Keith)" 
Content-Type: multipart/alternative; boundary=047d7b5d41a616e74f04e983c7ff
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 22:01:42 -0000

--047d7b5d41a616e74f04e983c7ff
Content-Type: text/plain; charset=ISO-8859-1

Year I over-interpreted. But it does recommend listing all known IPR issues
and that's a lot.
Silvia.
 On 24 Oct 2013 22:05, "DRAGE, Keith (Keith)" <
keith.drage@alcatel-lucent.com> wrote:

> "requires all IPR holders on a technology that is made part of an RFC to
> disclose"
>
> Is not what the document actually says.
>
> If you are going to attribute please attribute correctly.
>
> Regards
>
> Keith
>
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org
> > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Silvia Pfeiffer
> > Sent: 23 October 2013 22:46
> > To: Basil Mohamed Gohar
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
> >
> > On Thu, Oct 24, 2013 at 8:05 AM, Basil Mohamed Gohar
> >  wrote:
> > > On 10/23/2013 04:55 PM, cowwoc wrote:
> > >> Harald,
> > >>
> > >>     I think it is premature to imply that VP8 is royalty
> > free. I have
> > >> nothing against the codec (it's great) but it's my
> > understanding that
> > >> Google can't guarantee that someone else won't exercise IPR rights
> > >> against VP8 in the future. The best we can say is that
> > H264 requires
> > >> royalties today and VP8 *might* require royalties in the
> > future. H264
> > >> has a slight advantage in this space in that we have
> > well-understood
> > >> licensing terms.
> > >>
> > >>     I just wanted to put that out there so there are no
> > confusions in
> > >> the future.
> > >>
> > >> Gili
> > >
> > > Actually, this is exactly the kind of FUD that has stifled the
> > > adoption of VP8 and, before it, Theora and Vorbis, as
> > > universally-available multimedia format.  It serves only to confuse
> > > the issue further, as I will explain below.
> > >
> > > For starters, there is no evidence whatsoever that there is
> > a viable
> > > IPR concern with VP8, but there exist baseless allegations.
> >  In fact,
> > > what little doubt that there might have been one was settled by the
> > > agreement signed between Google and MPEG-LA [1] a short while ago,
> > > which resulted in MPEG-LA withdrawing their attempt a
> > forming a patent
> > > pool for VP8 altogether.  An attempt, I might add, that had little
> > > public activity save for its initial announcement once VP8
> > was being
> > > concerned for international standards.  In fact, the extremely
> > > generous terms of the agreement lend credence to the fact
> > that there
> > > was little that existing that would have been enforceable.
> > >
> > > Furthermore, the fact that there is an existing licensing structure
> > > for
> > > H.264 give exactly zero assurances of protections from IPR claims,
> > > because not all licensors of H.264 technology are a member of the
> > > MPEG-LA patent pool agreement, and there have been numerous patent
> > > cases related to H.264 and other technologies thought to be
> > covered by
> > > RAND and FRAND terms.
> > >
> > > Finally, the current patent and IPR landscape, at least in
> > the US, and
> > > widely in other portions of the world, eliminates the
> > possibility of
> > > something *never* being under a patent threat, due to the
> > presence of
> > > patent trolls that actively wait for adoption as well the sheer
> > > magnitude of patents and the very ease with which patent
> > legislation
> > > can be brought up (including for those already "covered" by
> > existing
> > > patent pools, e.g., H.264).
> > >
> > > So, in actuality, H.264 holds no advantage over VP8 in this regard,
> > > and the claim that VP8 is a liability to use is not
> > evidenced by any
> > > actual unique tangible threat to date.
> > >
> > > [1] http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html
> >
> >
> > On top of all this, it seems to me that
> > http://www.ietf.org/rfc/rfc3979.txt requires all IPR holders
> > on a technology that is made part of an RFC to disclose their
> > IPR and sign a patent disclosure:
> > http://tools.ietf.org/html/rfc3905 . I think this process is
> > trivial for VP8, but will require lengthy delays for sorting
> > out for H.264. In the interest of the Internet Community,
> > given that both codecs provide comparable quality at
> > comparable bitrates, we need to choose what is best for the
> > Internet community.
> > RFC3979 even states this explicitly:
> >
> > " In all matters of Intellectual Property Rights, the intent is to
> >    benefit the Internet community and the public at large, while
> >    respecting the legitimate rights of others."
> >
> > It seems clear that given that there is no substantial
> > technical difference between the two, given that the IRP
> > situation is so much cleaner for VP8, and that the only known
> > IPR holder for VP8 (ever after challenges) is Google who are
> > providing a perpetual royalty-free license
> > (http://www.webmproject.org/license/bitstream/), the
> > preference of the Internet community must clearly lie with VP8.
> >
> > I would be surprised if the IESG - who has to consider IPR
> > rights when approving an RFC for publication - wouldn't have
> > to overrule any decision made by this WG to choose H.264 over VP8.
> >
> > RFC3979 states:
> > " 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."
> >
> >
> > Best Regards,
> > Silvia.
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >

--047d7b5d41a616e74f04e983c7ff
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Year I over-interpreted. But it does recommend listing all k=
nown IPR issues and that's a lot.

Silvia.




On 24 Oct 2013 22:05, "DRAGE, Keith (Keith)=
" <keith.drage@al=
catel-lucent.com> wrote:

"requires all IPR holders on a technology that is made part of an RFC =
to disclose"



Is not what the document actually says.



If you are going to attribute please attribute correctly.



Regards



Keith



> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg

> [mailto:rtcweb-bounces@ietf=
.org] On Behalf Of Silvia Pfeiffer

> Sent: 23 October 2013 22:46

> To: Basil Mohamed Gohar

> Cc: rtcweb@ietf.org

> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

>

> On Thu, Oct 24, 2013 at 8:05 AM, Basil Mohamed Gohar

> <basilgohar@librevideo=
.org> wrote:

> > On 10/23/2013 04:55 PM, cowwoc wrote:

> >> Harald,

> >>

> >> =A0 =A0 I think it is premature to imply that VP8 is royalty<=
br>
> free. I have

> >> nothing against the codec (it's great) but it's my
> understanding that

> >> Google can't guarantee that someone else won't exerci=
se IPR rights

> >> against VP8 in the future. The best we can say is that

> H264 requires

> >> royalties today and VP8 *might* require royalties in the

> future. H264

> >> has a slight advantage in this space in that we have

> well-understood

> >> licensing terms.

> >>

> >> =A0 =A0 I just wanted to put that out there so there are no
> confusions in

> >> the future.

> >>

> >> Gili

> >

> > Actually, this is exactly the kind of FUD that has stifled the
> > adoption of VP8 and, before it, Theora and Vorbis, as

> > universally-available multimedia format. =A0It serves only to con=
fuse

> > the issue further, as I will explain below.

> >

> > For starters, there is no evidence whatsoever that there is

> a viable

> > IPR concern with VP8, but there exist baseless allegations.

> =A0In fact,

> > what little doubt that there might have been one was settled by t=
he

> > agreement signed between Google and MPEG-LA [1] a short while ago=
,

> > which resulted in MPEG-LA withdrawing their attempt a

> forming a patent

> > pool for VP8 altogether. =A0An attempt, I might add, that had lit=
tle

> > public activity save for its initial announcement once VP8

> was being

> > concerned for international standards. =A0In fact, the extremely<=
br>
> > generous terms of the agreement lend credence to the fact

> that there

> > was little that existing that would have been enforceable.

> >

> > Furthermore, the fact that there is an existing licensing structu=
re

> > for

> > H.264 give exactly zero assurances of protections from IPR claims=
,

> > because not all licensors of H.264 technology are a member of the=


> > MPEG-LA patent pool agreement, and there have been numerous paten=
t

> > cases related to H.264 and other technologies thought to be

> covered by

> > RAND and FRAND terms.

> >

> > Finally, the current patent and IPR landscape, at least in

> the US, and

> > widely in other portions of the world, eliminates the

> possibility of

> > something *never* being under a patent threat, due to the

> presence of

> > patent trolls that actively wait for adoption as well the sheer
> > magnitude of patents and the very ease with which patent

> legislation

> > can be brought up (including for those already "covered"=
; by

> existing

> > patent pools, e.g., H.264).

> >

> > So, in actuality, H.264 holds no advantage over VP8 in this regar=
d,

> > and the claim that VP8 is a liability to use is not

> evidenced by any

> > actual unique tangible threat to date.

> >

> > [1] http://blog.webmproject.org/2013/03/vp8-and-mpeg-=
la.html

>

>

> On top of all this, it seems to me that

> http=
://www.ietf.org/rfc/rfc3979.txt requires all IPR holders

> on a technology that is made part of an RFC to disclose their

> IPR and sign a patent disclosure:

> http:=
//tools.ietf.org/html/rfc3905 . I think this process is

> trivial for VP8, but will require lengthy delays for sorting

> out for H.264. In the interest of the Internet Community,

> given that both codecs provide comparable quality at

> comparable bitrates, we need to choose what is best for the

> Internet community.

> RFC3979 even states this explicitly:

>

> " In all matters of Intellectual Property Rights, the intent is t=
o

> =A0 =A0benefit the Internet community and the public at large, while
> =A0 =A0respecting the legitimate rights of others."

>

> It seems clear that given that there is no substantial

> technical difference between the two, given that the IRP

> situation is so much cleaner for VP8, and that the only known

> IPR holder for VP8 (ever after challenges) is Google who are

> providing a perpetual royalty-free license

> (http://www.webmproject.org/license/bitstream/), the

> preference of the Internet community must clearly lie with VP8.

>

> I would be surprised if the IESG - who has to consider IPR

> rights when approving an RFC for publication - wouldn't have

> to overrule any decision made by this WG to choose H.264 over VP8.

>

> RFC3979 states:

> " In general, IETF working groups prefer technologies with no

> known IPR

> =A0 =A0claims or, for technologies with claims against them, an offer =
of

> =A0 =A0royalty-free licensing."

>

>

> Best Regards,

> Silvia.

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

> 


--047d7b5d41a616e74f04e983c7ff--

From silviapfeiffer1@gmail.com  Thu Oct 24 15:09:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8A611E81FD for ; Thu, 24 Oct 2013 15:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rHBobpdxQXi for ; Thu, 24 Oct 2013 15:09:38 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id A040D11E8205 for ; Thu, 24 Oct 2013 15:09:38 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id m17so161752oag.35 for ; Thu, 24 Oct 2013 15:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2IqEoqwZkDeTThnAZ8Z40tuIzuSZKUFB0qa7UFGCsJw=; b=iDlRT2Em/YFD5/UWG2STepkP57VpSGv08QvIvSX3ns231y7EQQtAVO22RutyXQ3SPv l/oKdaa+rTsyZajKEiCywC39IsVchFqyP9PBYNBSwH+BjvEIRN2o8c0RHBUebrjD4p3k bVinaBCgQHoycGDEG5GCgPHZ5Subq8wmSeRqcSyiwuLFZeMdsze+uvwKw6k18/sclzGx jfK7Yz1MEfQ9qu8N1RCRkxKoaRFkfQg3D1xDGPn77nMHDrhI9PtssMXxXAit4tmsIjx8 BasleA8MA2f3qri7SAHlCbf+dWAcdGyMuFrDwt9AtbSiYizVWfDlkO9HtDybI7oJN7HQ 4mQQ==
MIME-Version: 1.0
X-Received: by 10.182.84.132 with SMTP id z4mr315843oby.49.1382652578080; Thu, 24 Oct 2013 15:09:38 -0700 (PDT)
Received: by 10.76.94.40 with HTTP; Thu, 24 Oct 2013 15:09:37 -0700 (PDT)
Received: by 10.76.94.40 with HTTP; Thu, 24 Oct 2013 15:09:37 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>  
Date: Fri, 25 Oct 2013 09:09:37 +1100
Message-ID: 
From: Silvia Pfeiffer 
To: Matthew Kaufman 
Content-Type: multipart/alternative; boundary=089e0111c09ac3b91604e983e34d
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 22:09:41 -0000

--089e0111c09ac3b91604e983e34d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

If VP8 is chosen as MTI, you'd need to come out as per IETF requirements.
So would others. That's a good thing. If there indeed is anything there.
Silvia.
 On 25 Oct 2013 03:11, "Matthew Kaufman (SKYPE)" 
wrote:

>  On the IPR issue, Google reached agreement with 11 patent holders. There
> are at least 31 companies in the MPEG-LA H.264 pool. There is considerabl=
e
> technical overlap between VP8 and H.264.****
>
> ** **
>
> My employer is one of those in the H.264 pool, and wasn=92t one of the 11
> companies Google reached an agreement with.****
>
> ** **
>
> Draw your own conclusions and take your own IPR risks.****
>
> ** **
>
> Personally I=92d rather the IPR devil I know vs. the IPR devil I don=92t =
know.
> ****
>
> ** **
>
> Google could fix this for most potential users (through indemnification,
> similar to what Oracle offers its Linux licensees) but has chosen not to.
> You can draw your own conclusion there, too.****
>
> ** **
>
> Matthew Kaufman****
>
> ** **
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On
> Behalf Of *Bo Burman
> *Sent:* Thursday, October 24, 2013 6:27 AM
> *To:* Harald Alvestrand; rtcweb@ietf.org
> *Subject:* Re: [rtcweb] VP8 vs H.264 - the core issue****
>
> ** **
>
> 1) We do agree that H.264 Constrained Baseline and VP8 are comparable in
> terms of video quality. But do not forget that Constrained Baseline's twi=
n
> sister H.264 Constrained High outperforms VP8 by a huge margin. This is
> also relevant.****
>
> ** **
>
> 2) The "back-and forth of numbers" seems to refer to Ericsson's work wher=
e
> we tried to make a fair comparison to evaluate the extraordinary claims
> from Google that VP8 is 70 or 40 percent better than x264. We found serio=
us
> issues with the way Google performed the test, maybe the most striking we=
re
> the use of padding (+8% for x264) and excessive number of threads (+10% t=
o
> +40% for x264) to add overhead to x264. That Google managed to remember t=
he
> threading parameter only when it helped****
>
> VP8 (the speed test) is also quite remarkable.****
>
> ** **
>
> 3) Regarding IPR, this is a difficult topic, but we're not at all
> convinced that VP8 is royalty free. For example, there is an IETF IPR
> disclosure (https://datatracker.ietf.org/ipr/2035/) where the IPR holder
> seems unwilling to license (on any terms), and
> http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.htm=
land
> http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias=
.htmlshow that there are in fact ongoing litigations regarding VP8 - and th=
is is
> only skimming the surface of what is available in public space.****
>
> ** **
>
> /Bo****
>
> ** **
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
> *On Behalf Of *Harald Alvestrand
> *Sent:* den 24 oktober 2013 13:12
> *To:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] VP8 vs H.264 - the core issue****
>
> ** **
>
> On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:****
>
> On 10/23/2013 02:51 PM, Harald Alvestrand wrote:****
>
>  Just a reminder:****
>
> The back-and-forth of numbers doesn't change the core question of this***=
*
>
> debate.****
>
> Both codecs are capable of high quality video encoding, and performance**=
**
>
> numbers are comparable.****
>
> ** **
>
> The real core question is the IPR issue.****
>
> ** **
>
> The tradition of the IETF says that allowing only business models that***=
*
>
> can sustain royalty agreements and royalty payments is Bad for the Intern=
et.****
>
> ** **
>
> The dominant video codec, H.264, is a royalty-required codec.****
>
> ** **
>
> Do we switch now, or do we give up and live with royalties forever?****
>
> ** **
>
>  ** **
>
> Harald,****
>
> ** **
>
> I would like to see some references to the tradition of the IETF that****
>
> you've quoted.****
>
> ** **
>
> For the record, I agree with the sentiment, but I'd like to be able to***=
*
>
> back up the claim itself with references or explicit decisions that were*=
***
>
> made in that regard.  I'm not trying to be a thorn in your side, just****
>
> looking for citations to back up the arguments, both on and off list.****
>
> ** **
>
>  Basil, very happy to provide references!
>
> RFC 3979, a core document about IPR in the IETF, 2005:
>
> ****
>
> 8.  Evaluating Alternative Technologies in IETF Working Groups****
>
> ** **
>
>    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.****
>
>
> The complete section gives some more details, but this is the central
> quote.
>
> You may also enjoy reading the section of RFC 6569 (the guidelines that
> were followed in the OPUS work) that deals with IPR:
>
> http://tools.ietf.org/html/rfc6569#page-8
>
>
>
>
> ****
>
> -- ****
>
> Surveillance is pervasive. Go Dark.****
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--089e0111c09ac3b91604e983e34d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


If VP8 is chosen as MTI, you'd need to come out as per I=
ETF requirements. So would others. That's a good thing. If there indeed=
 is anything there.

Silvia.




On 25 Oct 2013 03:11, "Matthew Kaufman (SKY=
PE)" <matthew.kaufman@=
skype.net> wrote:












On the IPR issue, Google =
reached agreement with 11 patent holders. There are at least 31 companies i=
n the MPEG-LA H.264 pool. There is considerable technical
 overlap between VP8 and H.264.


=A0<=
/p>

My employer is one of tho=
se in the H.264 pool, and wasn=92t one of the 11 companies Google reached a=
n agreement with.



=A0<=
/p>

Draw your own conclusions=
 and take your own IPR risks.


=A0<=
/p>

Personally I=92d rather t=
he IPR devil I know vs. the IPR devil I don=92t know.<=
/p>


=A0<=
/p>

Google could fix this for=
 most potential users (through indemnification, similar to what Oracle offe=
rs its Linux licensees) but has chosen not to. You can draw
 your own conclusion there, too.


=A0<=
/p>



Matthew Kaufman=





=A0<=
/p>







From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Bo Burman

Sent: Thursday, October 24, 2013 6:27 AM

To: Harald Alvestrand; rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






=A0


1) We do agree that H.264=
 Constrained Baseline and VP8 are comparable in terms of video quality. But=
 do not forget that Constrained Baseline's twin sister H.264
 Constrained High outperforms VP8 by a huge margin. This is also relevant.<=
u>


=A0<=
/p>

2) The "back-and for=
th of numbers" seems to refer to Ericsson's work where we tried to=
 make a fair comparison to evaluate the extraordinary claims from Google
 that VP8 is 70 or 40 percent better than x264. We found serious issues wit=
h the way Google performed the test, maybe the most striking were the use o=
f padding (+8% for x264) and excessive number of threads (+10% to +40% for =
x264) to add overhead to x264. That
 Google managed to remember the threading parameter only when it helped<=
/u>


VP8 (the speed test) is a=
lso quite remarkable.


=A0<=
/p>

3) Regarding IPR, this is=
 a difficult topic, but we're not at all convinced that VP8 is royalty =
free. For example, there is an IETF IPR disclosure (https://datatracker.ietf.org/=
ipr/2035/)
 where the IPR holder seems unwilling to license (on any terms), and 
http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html<=
/a> and

http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.h=
tml show that there are in fact ongoing litigations regarding VP8 - and=
 this is only skimming the surface of what is available in public space.=




=A0<=
/p>

/Bo<=
/p>

=A0<=
/p>







From:
rtcweb-bounces=
@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Harald Alvestrand

Sent: den 24 oktober 2013 13:12

To: rtcweb@ietf=
.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






=A0




On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:






On 10/23/2013 02:51 PM, Harald Alvestrand wrote:




Just a reminder:


The back-and-forth of numbers doesn't change the core question of =
this


debate.


Both codecs are capable of high quality video encoding, and performanc=
e


numbers are comparable.


=A0


The real core question is the IPR issue.


=A0


The tradition of the IETF says that allowing only business models that=



can sustain royalty agreements and royalty payments is Bad for the Int=
ernet.


=A0


The dominant video codec, H.264, is a royalty-required codec.


=A0


Do we switch now, or do we give up and live with royalties forever?=



=A0




=A0


Harald,


=A0


I would like to see some references to the tradition of the IETF that<=
u>


you've quoted.


=A0


For the record, I agree with the sentiment, but I'd like to be abl=
e to


back up the claim itself with references or explicit decisions that we=
re


made in that regard.=A0 I'm not trying to be a thorn in your side,=
 just


looking for citations to back up the arguments, both on and off list.<=
u>


=A0




Basil, very happy to =
provide references!



RFC 3979, a core document about IPR in the IETF, 2005:






8.=A0 Evaluating Alternative Technologies in IETF Working Groups


=A0


=A0=A0 In general, IETF working groups prefer technologies with no kno=
wn IPR


=A0=A0 claims or, for technologies with claims against them, an offer =
of


=A0=A0 royalty-free licensing.=A0 But IETF working groups have the dis=
cretion


=A0=A0 to adopt technology with a commitment of fair and non-discrimin=
atory


=A0=A0 terms, or even with no licensing commitment, if they feel that =
this


=A0=A0 technology is superior enough to alternatives with fewer IPR cl=
aims


=A0=A0 or free licensing to outweigh the potential cost of the license=
s.




The complete section gives some more details, but this is the central quote=
.



You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:



htt=
p://tools.ietf.org/html/rfc6569#page-8












-- 


Surveillance is pervasive. Go Dark.











_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb




--089e0111c09ac3b91604e983e34d--

From keith.drage@alcatel-lucent.com  Thu Oct 24 16:07:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F9811E825A for ; Thu, 24 Oct 2013 16:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.571
X-Spam-Level: 
X-Spam-Status: No, score=-110.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp40nGhArjCy for ; Thu, 24 Oct 2013 16:07:00 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0F11E8250 for ; Thu, 24 Oct 2013 16:07:00 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9ON6uHp013328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Oct 2013 18:06:57 -0500 (CDT)
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 r9ON6s23026051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 01:06:54 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 01:06:54 +0200
From: "DRAGE, Keith (Keith)" 
To: cowwoc , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0PAS3TqGWYrUlUulPtrUXYOsppoEMQ8AgABHl3A=
Date: Thu, 24 Oct 2013 23:06:54 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BF068@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>
In-Reply-To: <52698758.5040404@bbs.darktech.org>
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
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 23:07:11 -0000

Nothing in this decision, whether we make one or not, is holding back the d=
evelopment of any codec.

The debate is on whether and what to specify as a mandatory to implement co=
dec.=20

If that was to be the only codecs available, then there will never be any n=
ew codecs.

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
> Sent: 24 October 2013 21:47
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
>=20
> On 24/10/2013 3:34 PM, Basil Mohamed Gohar wrote:
> > On 10/24/2013 12:02 PM, Matthew Kaufman (SKYPE) wrote:
> >> On the IPR issue, Google reached agreement with 11 patent holders.=20
> >> There are at least 31 companies in the MPEG-LA H.264 pool.=20
> There is=20
> >> considerable technical overlap between VP8 and H.264.
> >>
> >> My employer is one of those in the H.264 pool, and wasn't=20
> one of the=20
> >> 11 companies Google reached an agreement with.
> >>
> >> Draw your own conclusions and take your own IPR risks.
> >>
> >> Personally I'd rather the IPR devil I know vs. the IPR=20
> devil I don't know.
> >>
> >> Google could fix this for most potential users (through=20
> >> indemnification, similar to what Oracle offers its Linux=20
> licensees)=20
> >> but has chosen not to. You can draw your own conclusion there, too.
> >>
> >> Matthew Kaufman
> > There are no conclusions to draw due to lack of sufficient evidence=20
> > for anything actionable.  IPR FUD has delayed the adoption of many=20
> > free, non-royalty-bearing formats for too long.  And,=20
> again, the IPR=20
> > "devil we know" is meaningless, because there are still IP=20
> litigation=20
> > threats even for H.264, MP3, and many other patented,=20
> royalty-bearing formats.
> >
> > So, it contributes little to nothing to the discussion on=20
> IPR grounds=20
> > if a substantial declaration, as Ted has advised, is not taken, and=20
> > such claims should really be discounted in any serious=20
> consideration=20
> > when weighing options between formats.
>=20
>      I would like to point out that we still have the option=20
> of mandating the use of an older codec whose IPR has expired=20
> (and let clients upgrade to VP8 or H264 as they fit).
>=20
>      But if the community rejects this approach, then I agree=20
> that this should not hold back the use of VP8.
>=20
> Gili
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From cb.list6@gmail.com  Thu Oct 24 16:13:42 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5ADA11E8274 for ; Thu, 24 Oct 2013 16:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FBY3AkyLHK0 for ; Thu, 24 Oct 2013 16:13:42 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C6A2311E825F for ; Thu, 24 Oct 2013 16:13:41 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id b13so251912wgh.0 for ; Thu, 24 Oct 2013 16:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pPO+tPtMD/LqQjyV1y6CpBJrwUyd4+J2NrF0kKh9nfg=; b=CkXZBsi7bzIafLGKl5egz7X/Pxl09m/F9tfwOllDulQy/fFHtKGlcvfX7UorgmzHhd EMvFr+oSDLp7rZil0SsE/6xQobUViAwnSpZHL2WcdhLFFXPmTk2OxQSlvIf25cwC1Nz/ LEdOsPrr94Sd8LrCSmgT0LTgAh7hD6axBYNN8RjI2O4XlhenCw2UlLkcqH1ECN/7icf+ WfPcyvLQIIe26jH32uuUWFC8HqcGShdgDRjeKYTzXcz4ZGD8SIkHAgfHhYapzku3xKJA 6M60ixDJ/MZWoyQMGTQgenQVkxDiFG3UF9fxVxrtd+IzAaTdhkyOXMQ80FOqtT2Sz9aa 5OdQ==
MIME-Version: 1.0
X-Received: by 10.180.108.103 with SMTP id hj7mr2435345wib.49.1382656420352; Thu, 24 Oct 2013 16:13:40 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Thu, 24 Oct 2013 16:13:40 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Thu, 24 Oct 2013 16:13:40 -0700 (PDT)
In-Reply-To: <52698758.5040404@bbs.darktech.org>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>
Date: Thu, 24 Oct 2013 16:13:40 -0700
Message-ID: 
From: "cb.list6" 
To: cowwoc 
Content-Type: multipart/alternative; boundary=e89a8f3ba1c9c81f4404e984c85f
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 23:13:43 -0000

--e89a8f3ba1c9c81f4404e984c85f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Oct 24, 2013 1:47 PM, "cowwoc"  wrote:
>
> On 24/10/2013 3:34 PM, Basil Mohamed Gohar wrote:
>>
>> On 10/24/2013 12:02 PM, Matthew Kaufman (SKYPE) wrote:
>>>
>>> On the IPR issue, Google reached agreement with 11 patent holders. Ther=
e
>>> are at least 31 companies in the MPEG-LA H.264 pool. There is
>>> considerable technical overlap between VP8 and H.264.
>>>
>>> My employer is one of those in the H.264 pool, and wasn=92t one of the =
11
>>> companies Google reached an agreement with.
>>>
>>> Draw your own conclusions and take your own IPR risks.
>>>
>>> Personally I=92d rather the IPR devil I know vs. the IPR devil I don=92=
t
know.
>>>
>>> Google could fix this for most potential users (through indemnification=
,
>>> similar to what Oracle offers its Linux licensees) but has chosen not
>>> to. You can draw your own conclusion there, too.
>>>
>>> Matthew Kaufman
>>
>> There are no conclusions to draw due to lack of sufficient evidence for
>> anything actionable.  IPR FUD has delayed the adoption of many free,
>> non-royalty-bearing formats for too long.  And, again, the IPR "devil we
>> know" is meaningless, because there are still IP litigation threats even
>> for H.264, MP3, and many other patented, royalty-bearing formats.
>>
>> So, it contributes little to nothing to the discussion on IPR grounds if
>> a substantial declaration, as Ted has advised, is not taken, and such
>> claims should really be discounted in any serious consideration when
>> weighing options between formats.
>
>
>     I would like to point out that we still have the option of mandating
the use of an older codec whose IPR has expired (and let clients upgrade to
VP8 or H264 as they fit).
>
>     But if the community rejects this approach, then I agree that this
should not hold back the use of VP8.
>
> Gili
>

There is no holding back vp8, it can always be negotiated.

My guidance is no mti.

I, for one, am tired of the gang-land ipr turf wars and posturing. This
argument is all about ipr, and ietf is explicitly setup to punt on all ipr
issue because they are hard.

Any layperson can see there is no concensus to be found. That's why we
designed for codec negotiating and negotiating away from failure is left
for implementation

CB

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

--e89a8f3ba1c9c81f4404e984c85f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




On Oct 24, 2013 1:47 PM, "cowwoc" <cowwoc@bbs.darktech.org> wrote:

>

> On 24/10/2013 3:34 PM, Basil Mohamed Gohar wrote:

>>

>> On 10/24/2013 12:02 PM, Matthew Kaufman (SKYPE) wrote:

>>>

>>> On the IPR issue, Google reached agreement with 11 patent hold=
ers. There

>>> are at least 31 companies in the MPEG-LA H.264 pool. There is<=
br>
>>> considerable technical overlap between VP8 and H.264.

>>>

>>> My employer is one of those in the H.264 pool, and wasn=92t on=
e of the 11

>>> companies Google reached an agreement with.

>>>

>>> Draw your own conclusions and take your own IPR risks.

>>>

>>> Personally I=92d rather the IPR devil I know vs. the IPR devil=
 I don=92t know.

>>>

>>> Google could fix this for most potential users (through indemn=
ification,

>>> similar to what Oracle offers its Linux licensees) but has cho=
sen not

>>> to. You can draw your own conclusion there, too.

>>>

>>> Matthew Kaufman

>>

>> There are no conclusions to draw due to lack of sufficient evidenc=
e for

>> anything actionable. =A0IPR FUD has delayed the adoption of many f=
ree,

>> non-royalty-bearing formats for too long. =A0And, again, the IPR &=
quot;devil we

>> know" is meaningless, because there are still IP litigation t=
hreats even

>> for H.264, MP3, and many other patented, royalty-bearing formats.<=
br>
>>

>> So, it contributes little to nothing to the discussion on IPR grou=
nds if

>> a substantial declaration, as Ted has advised, is not taken, and s=
uch

>> claims should really be discounted in any serious consideration wh=
en

>> weighing options between formats.

>

>

> =A0 =A0 I would like to point out that we still have the option of man=
dating the use of an older codec whose IPR has expired (and let clients upg=
rade to VP8 or H264 as they fit).

>

> =A0 =A0 But if the community rejects this approach, then I agree that =
this should not hold back the use of VP8.

>

> Gili

>


There is no holding back vp8, it can always be negotiated.=
=A0 


My guidance is no mti. 


I, for one, am tired of the gang-land ipr turf wars and post=
uring. This argument is all about ipr, and ietf is explicitly setup to punt=
 on all ipr issue because they are hard. 


Any layperson can see there is no concensus to be found. Tha=
t's why we designed for codec negotiating and negotiating away from fai=
lure is left for implementation


CB


> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb




--e89a8f3ba1c9c81f4404e984c85f--

From karl.stahl@intertex.se  Thu Oct 24 19:27:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADB411E824B for ; Thu, 24 Oct 2013 19:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMDa1vRO80Zj for ; Thu, 24 Oct 2013 19:27:41 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7F80211E8168 for ; Thu, 24 Oct 2013 19:27:39 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310250427366045; Fri, 25 Oct 2013 04:27:36 +0200
From: "Karl Stahl" 
To: "'Bo Burman'" , "'Harald Alvestrand'" , , 
References: <52681A96.2020904@alvestrand.no>	<526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no> 
In-Reply-To: 
Date: Fri, 25 Oct 2013 04:27:39 +0200
Message-ID: <021101ced129$c6bafa90$5430efb0$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0212_01CED13A.8A43CA90"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHO0CDhJVyL5itEmEWrISFOF+nwVJoCjkaAgAEDvACAAEBxAIAAvOeQ
Content-Language: sv
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 02:27:46 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0212_01CED13A.8A43CA90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Interesting discussion with very technical detail regarding specific =
tests
verses very general IPR allegations regarding the royal free issue, =
under
this same thread.

=20

Does anyone know if Nokia has provided any technical relevant and
understandable detail regarding where they think VP8 is infringing or is
https://datatracker.ietf.org/ipr/2035/=20

just a list of some 67 maybe related patents (I count 35 cm * 2,5 =
lines/cm /
1,3 patents/line =3D 67 patents) poured into this declaration?=20

=20

I notice the =93No information submitted=94:


C. If an Internet-Draft or RFC includes multiple parts and it is not
reasonably apparent which part of such Internet-Draft or RFC is alleged =
to
be covered by the patent information disclosed in Section V(A) or V(B), =
it
is helpful if the discloser identifies here the sections of the
Internet-Draft or RFC that are alleged to be so covered:=20

=09
No information submitted

=20

Is the IETF in a position to say something stronger than =93it is =
helpful if
the discloser identifies here the sections of the Internet-Draft or RFC =
that
are alleged to be so covered=94 if such declaration is supposed to =
influence
the selection of codec?

=20

An idea of which claim in which of the 67 listed patents Nokia believes =
is
being infringed by VP8 is relevant to be able to form an opinion. I =
added
the named Nokia contact to this email.

=20

/Karl

=20

=20

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Bo Burman
Skickat: den 24 oktober 2013 15:27
Till: Harald Alvestrand; rtcweb@ietf.org
=C4mne: Re: [rtcweb] VP8 vs H.264 - the core issue

=20

1) We do agree that H.264 Constrained Baseline and VP8 are comparable in
terms of video quality. But do not forget that Constrained Baseline's =
twin
sister H.264 Constrained High outperforms VP8 by a huge margin. This is =
also
relevant.

=20

2) The "back-and forth of numbers" seems to refer to Ericsson's work =
where
we tried to make a fair comparison to evaluate the extraordinary claims =
from
Google that VP8 is 70 or 40 percent better than x264. We found serious
issues with the way Google performed the test, maybe the most striking =
were
the use of padding (+8% for x264) and excessive number of threads (+10% =
to
+40% for x264) to add overhead to x264. That Google managed to remember =
the
threading parameter only when it helped

VP8 (the speed test) is also quite remarkable.

=20

3) Regarding IPR, this is a difficult topic, but we're not at all =
convinced
that VP8 is royalty free. For example, there is an IETF IPR disclosure
(https://datatracker.ietf.org/ipr/2035/) where the IPR holder seems
unwilling to license (on any terms), and
http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.htm=
l
and
http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias=
.ht
ml show that there are in fact ongoing litigations regarding VP8 - and =
this
is only skimming the surface of what is available in public space.

=20

/Bo

=20

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of
Harald Alvestrand
Sent: den 24 oktober 2013 13:12
To: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

=20

On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:

On 10/23/2013 02:51 PM, Harald Alvestrand wrote:

Just a reminder:
The back-and-forth of numbers doesn't change the core question of this
debate.
Both codecs are capable of high quality video encoding, and performance
numbers are comparable.
=20
The real core question is the IPR issue.
=20
The tradition of the IETF says that allowing only business models that
can sustain royalty agreements and royalty payments is Bad for the =
Internet.
=20
The dominant video codec, H.264, is a royalty-required codec.
=20
Do we switch now, or do we give up and live with royalties forever?
=20

=20
Harald,
=20
I would like to see some references to the tradition of the IETF that
you've quoted.
=20
For the record, I agree with the sentiment, but I'd like to be able to
back up the claim itself with references or explicit decisions that were
made in that regard.  I'm not trying to be a thorn in your side, just
looking for citations to back up the arguments, both on and off list.
=20

Basil, very happy to provide references!

RFC 3979, a core document about IPR in the IETF, 2005:



8.  Evaluating Alternative Technologies in IETF Working Groups
=20
   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.


The complete section gives some more details, but this is the central =
quote.

You may also enjoy reading the section of RFC 6569 (the guidelines that =
were
followed in the OPUS work) that deals with IPR:

http://tools.ietf.org/html/rfc6569#page-8






--=20
Surveillance is pervasive. Go Dark.

------=_NextPart_000_0212_01CED13A.8A43CA90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


In=
teresting discussion with very technical detail regarding specific tests =
verses very general IPR allegations regarding the royal free issue, =
under this same thread.
 
Do=
es anyone know if Nokia has provided any technical relevant and =
understandable detail regarding where they think VP8 is infringing or is =
https://datatracker.ietf.=
org/ipr/2035/ 
ju=
st a list of some 67 maybe related patents (I count 35 cm * 2,5 lines/cm =
/ 1,3 patents/line =3D 67 patents) poured into this declaration? =

 
I =
notice the “No information =
submitted”:
C. If an Internet-Draft or RFC includes multiple parts and it is not =
reasonably apparent which part of such Internet-Draft or RFC is alleged =
to be covered by the patent information disclosed in Section V(A) or =
V(B), it is helpful if the discloser identifies here the sections of the =
Internet-Draft or RFC that are alleged to be so covered: =

No information submitted
 
Is=
 the IETF in a position to say something stronger than =
“it is helpful if the discloser identifies here the sections of the =
Internet-Draft or RFC that are alleged to be so covered&#=
8221; if such declaration is supposed to influence the selection of =
codec?
 
An=
 idea of which claim in which of the 67 listed patents Nokia believes is =
being infringed by VP8 is relevant to be able to form an opinion. I =
added the named Nokia contact to this email.
 
/K=
arl
 
 
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Bo Burman
Skickat: den 24 oktober 2013 =
15:27
Till: Harald Alvestrand; =
rtcweb@ietf.org
=C4mne: Re: [rtcweb] VP8 vs H.264 - the core =
issue
 
1) We do agree that H.264 Constrained Baseline and VP8 are comparable =
in terms of video quality. But do not forget that Constrained Baseline's =
twin sister H.264 Constrained High outperforms VP8 by a huge margin. =
This is also relevant.
 
2) The "back-and forth of numbers" seems to refer to =
Ericsson's work where we tried to make a fair comparison to evaluate the =
extraordinary claims from Google that VP8 is 70 or 40 percent better =
than x264. We found serious issues with the way Google performed the =
test, maybe the most striking were the use of padding (+8% for x264) and =
excessive number of threads (+10% to +40% for x264) to add overhead to =
x264. That Google managed to remember the threading parameter only when =
it helped
VP8 (the speed test) is also quite =
remarkable.
 
3) Regarding IPR, this is a difficult topic, but we're not at all =
convinced that VP8 is royalty free. For example, there is an IETF IPR =
disclosure (https://datatracker.ietf.=
org/ipr/2035/) where the IPR holder seems unwilling to license (on =
any terms), and http://www.fosspatents.com/2013/06/german-vp8-infringement-cas=
es-show.html and http://www.fosspatents.com/2013/06/itc-institutes-investig=
ation-of-nokias.html show that there are in fact ongoing litigations =
regarding VP8 - and this is only skimming the surface of what is =
available in public space.
 
/Bo
 
 
On 10/23/2013 09:42 PM, Basil Mohamed Gohar =
wrote:
On 10/23/2013 02:51 PM, Harald Alvestrand =
wrote:
Just a reminder:
The back-and-forth of numbers doesn't change the core =
question of this
debate.
Both =
codecs are capable of high quality video encoding, and =
performance
numbers are =
comparable.
 
The =
real core question is the IPR issue.
 
The =
tradition of the IETF says that allowing only business models =
that
can sustain royalty =
agreements and royalty payments is Bad for the =
Internet.
 
The =
dominant video codec, H.264, is a royalty-required =
codec.
 
Do we =
switch now, or do we give up and live with royalties =
forever?
 
 
Harald,
 
I =
would like to see some references to the tradition of the IETF =
that
you've =
quoted.
 
For =
the record, I agree with the sentiment, but I'd like to be able =
to
back up the claim =
itself with references or explicit decisions that =
were
made in that =
regard.  I'm not trying to be a thorn in your side, =
just
looking for =
citations to back up the arguments, both on and off =
list.
 
Basil, very happy to provide references!

RFC 3979, a =
core document about IPR in the IETF, =
2005:

8.  =
Evaluating Alternative Technologies in IETF Working =
Groups
 
   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.

The complete =
section gives some more details, but this is the central =
quote.

You may also enjoy reading the section of RFC 6569 (the =
guidelines that were followed in the OPUS work) that deals with =
IPR:

http://tools.ietf.org/=
html/rfc6569#page-8




-- 
Surveillance is pervasive. Go =
Dark.

------=_NextPart_000_0212_01CED13A.8A43CA90--


From harald@alvestrand.no  Thu Oct 24 21:16:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B5021E8085 for ; Thu, 24 Oct 2013 21:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.536
X-Spam-Level: 
X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHtCRAupgcQl for ; Thu, 24 Oct 2013 21:16:17 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F94411E80F5 for ; Thu, 24 Oct 2013 21:16:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97C1139E56A for ; Fri, 25 Oct 2013 06:16:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD6NfSiypYRZ for ; Fri, 25 Oct 2013 06:16:15 +0200 (CEST)
Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0E97339E3C2 for ; Fri, 25 Oct 2013 06:16:15 +0200 (CEST)
Message-ID: <5269F098.2020904@alvestrand.no>
Date: Fri, 25 Oct 2013 06:16:24 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 04:16:30 -0000

On 10/25/2013 01:13 AM, cb.list6 wrote:
>
> There is no holding back vp8, it can always be negotiated.
>
> My guidance is no mti.
>
> I, for one, am tired of the gang-land ipr turf wars and posturing. 
> This argument is all about ipr, and ietf is explicitly setup to punt 
> on all ipr issue because they are hard.
>
> Any layperson can see there is no concensus to be found. That's why we 
> designed for codec negotiating and negotiating away from failure is 
> left for implementation
>
Formalistically, the people who argue for abandoning an MTI, like the 
people who argue for adapting an antiquated codec, have not put in a 
draft by the chairs' deadline of October 6, so have not made a proposal.

But I'm not the one who argued for this to be put on the agenda for 2 hours.
The people who pushed for this to be on the agenda for 2 hours need to 
come forward and say why they believe this is a good use of our time. I 
haven't yet heard a VP8 proponent saying so.

So far, apart from learning a bit more about configuring x264, I haven't 
seen much new information.


From harald@alvestrand.no  Thu Oct 24 21:29:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C411E8116 for ; Thu, 24 Oct 2013 21:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.539
X-Spam-Level: 
X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B0Yr1aFQDSU for ; Thu, 24 Oct 2013 21:29:39 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D04EF11E8120 for ; Thu, 24 Oct 2013 21:29:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42E3539E56A for ; Fri, 25 Oct 2013 06:29:34 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9rlJymL6ecR for ; Fri, 25 Oct 2013 06:29:32 +0200 (CEST)
Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9143739E3C2 for ; Fri, 25 Oct 2013 06:29:32 +0200 (CEST)
Message-ID: <5269F3B5.2020308@alvestrand.no>
Date: Fri, 25 Oct 2013 06:29:41 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com>	<03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>			<03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>	<120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 04:29:44 -0000

On 10/24/2013 10:38 PM, Ejzak, Richard P (Richard) wrote:
> Hi Michael,
>
>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Sent: Thursday, October 24, 2013 2:21 PM
>> On Oct 24, 2013, at 8:36 PM, "Ejzak, Richard P (Richard)"
>>  wrote:
>>
>>> Justin, Michael,
>>> Thanks for the clarifications.  One more question.  What happens if
>> the application tries to select a stream id before the DTLS role is
>> known and it ends up selecting an invalid one?
>> I'm not completely familiar with the JS API, but if you want to select
>> a stream, aren't you managing the stream completely on your own. I
>> think the DTLS role stuff is only relevant if the streams are managed
>> by the browser.
> If this is the intent then that clarification would be very useful.  Reading the API text again, it is clear that the browser only manages stream ids that it selects.  Does this mean that the browser stream id selection option is not compatible with the application stream id selection option?  Putting it more precisely, should we require that the application not be allowed to select stream ids prior to determining DTLS role if it expects that either side might use the browser stream id selection option?  It would be easier if the even/odd rule could be determined earlier than DTLS role establishment so that the application could use the same even/odd assignment rule for early data channel creation.

My reading has been that once you start selecting IDs, you're 
responsible for making sure those don't collide with platform-generated 
ones, or deal with the result if they do.

The result of

A: pc.createDataChannel(label="foo") -> (channel with ID = 5, open 
message sent)
B: pc.createDataChannel(label="bar", id=5)


should be well defined. I don't much care what the result is, as long as 
it's well defined; closing the channel and calling the onerror() handler 
with DOMError(error="UsageError", message="Duelling paradigms") is fine 
with me.

I can't see a way to mix the two paradigms that guarantees this never 
happening.

>
>>> Michael,
>>> While it's true that the data channel control protocol cannot open
>> the channel with the peer before the DTLS role is known, the API allows
>> the application to create the data channel before the DTLS role is
>> known, in which case the sending of the Open message must wait until
>> the SCTP association is established.  I want to know what the
>> application is supposed to do it if needs to create data channels with
>> preselected stream ids before the DTLS role is known.  This seems like
>> something that the spec should make clear rather than leaving it to
>> implementation.
>> Can you assign the stream ID in the API? Could you point me to the
>> text?
> http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute in the RTCDataChannelInit dictionary that must be the equivalent of the "stream identifier".  No other interpretation makes sense to me but please correct me if I am wrong.  Note in particular the following text within the description of the createDataChannel procedure (my parenthetical): "If the value of the id attribute is null, initialize it to a value generated by the user agent (browser), according to the WebRTC DataChannel Protocol specification, and skip to the next step. Otherwise, if the value of the id attribute is taken by an existing RTCDataChannel, throw a TBD exception and abort these steps."  So "id" must refer to "stream identifier" since there is no other id in your draft that it could refer to.
>
> If I'm right, then it would be good if it were made clear that id refers to "stream identifier", but that is a w3c issue.  Quoting from 5.2.1 (my parentheticals for clarity): "The id was either assigned by the user agent (browser) at channel creation time (not channel opening time) or selected by the script (application). The attribute MUST return the value to which it was set when the RTCDataChannel was created (not opened)."
>
> I used the wrong terminology in my earlier mail when I referred to "open" of the data channel when I meant "creation".  Since the data channel can be "created" before DTLS role is known and before the data channel can be opened, the quoted text above would seem to indicate that the application can never determine the stream id actually assigned to the data channel if id can't be determined at time of creation.  Justin implied that the chrome behavior does not conform to this description.  Comment, Justin?
>
> It still seems to me that a change in the rule describing even/odd stream id assignment would be a good idea.
>
> BR, Richard
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From cowwoc@bbs.darktech.org  Fri Oct 25 01:03:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFE911E8158 for ; Fri, 25 Oct 2013 01:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level: 
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMXXwvppwdoX for ; Fri, 25 Oct 2013 01:03:21 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id B7F0C11E82C3 for ; Fri, 25 Oct 2013 01:03:15 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id s19so2001302qcw.7 for ; Fri, 25 Oct 2013 01:03:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pYuA8IbzNd2/RCJUBZXYR2QMDs3OXycnptcVLD4Ucsw=; b=ZQawtYQ0j5IiUa7TnCOuAmB9DDR7NKd7+tJbgJWudrsSvgdowgCF9cKouVuHBkNh3A TwZN/Xa2gYsspasLh3GXYKnT+6YbCbKICLRR0oHKfbSQbepDRhfmhspJlljwAKjOiJIF Jp24Kl5oKjjMLRTNGFk/UFMh6eFUraxLjc+TqCLoNJYGHhRN52speEhl2tDs7WJzRxNN Rhxk6N9DWKy+7IK4CVyMEoUqDAcyb82pPPP2fV4oRLLIpeDQPNV4DKHoY7t8YPLWSRNF F5wvtZR/QiXzfdNiyXf3zQYeIVO3X/x1PhwdDtnW48oQ833b8lWWwARAF4VRVU+Xxpof 7spw==
X-Gm-Message-State: ALoCoQmLNcs6rMQDzJHekT0JilZTrgYjFTdsdeHi5KG4JNBK8f110Xt4qiu1VHKS7/OJ93xppfEJ
X-Received: by 10.224.57.77 with SMTP id b13mr9562425qah.63.1382688195167; Fri, 25 Oct 2013 01:03:15 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k4sm16898919qaa.8.2013.10.25.01.03.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 01:03:14 -0700 (PDT)
Message-ID: <526A25C0.6080406@bbs.darktech.org>
Date: Fri, 25 Oct 2013 04:03:12 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no>	<526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>	 <5269F098.2020904@alvestrand.no>
In-Reply-To: <5269F098.2020904@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 08:03:27 -0000

On 25/10/2013 12:16 AM, Harald Alvestrand wrote:
> On 10/25/2013 01:13 AM, cb.list6 wrote:
>>
>> There is no holding back vp8, it can always be negotiated.
>>
>> My guidance is no mti.
>>
>> I, for one, am tired of the gang-land ipr turf wars and posturing. 
>> This argument is all about ipr, and ietf is explicitly setup to punt 
>> on all ipr issue because they are hard.
>>
>> Any layperson can see there is no concensus to be found. That's why 
>> we designed for codec negotiating and negotiating away from failure 
>> is left for implementation
>>
> Formalistically, the people who argue for abandoning an MTI, like the 
> people who argue for adapting an antiquated codec, have not put in a 
> draft by the chairs' deadline of October 6, so have not made a proposal.
>
> But I'm not the one who argued for this to be put on the agenda for 2 
> hours.
> The people who pushed for this to be on the agenda for 2 hours need to 
> come forward and say why they believe this is a good use of our time. 
> I haven't yet heard a VP8 proponent saying so.
>
> So far, apart from learning a bit more about configuring x264, I 
> haven't seen much new information.

     I think the real elephant in the room is whether Apple and 
Microsoft (who are on the H264 bandwagon) will decide to implement VP8 
just because you mandate it or whether they will side-step WebRTC 
altogether. FireFox's market-share is decline so more and more this is 
becoming a story of Chrome vs IE (on desktop) + Safari (on mobile).

     The real question we should be asking is how to get Apple and 
Microsoft on board. If we could get everyone on board, the question of 
what codec should be used would melt away (hint: there is no objective 
answer to this question).

Gili

From Markus.Isomaki@nokia.com  Fri Oct 25 01:06:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77A011E82C1 for ; Fri, 25 Oct 2013 01:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUIMuOwH-HuY for ; Fri, 25 Oct 2013 01:05:56 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDFC11E82C7 for ; Fri, 25 Oct 2013 01:05:51 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.50]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r9P84NhY027245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 25 Oct 2013 11:04:24 +0300
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.235]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.03.0136.001; Fri, 25 Oct 2013 08:04:23 +0000
From: 
To: , 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0CDhRcO5ZGLqUUag+6tiIuKaVJoCjkaAgAEDvACAAEBxAIAAMjWAgAA7OwCAABRSAIAAKOIAgABUlgCAADylkA==
Date: Fri, 25 Oct 2013 08:04:22 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>
In-Reply-To: <5269F098.2020904@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiWc+o8hXFUdLEV0dd3jRi9ZSnsyh2XxM9weacZlWDiXp2iugdu9/GeoD1NA6FKLHcwaKBRAiccUJ0MNT8h9MBXc/rgYtLrRsB5pMO+FxzwPovcKyyYUD6X9TbWJu8NgcZi7McFgkluASQ00lfICVg6apNxFMnyGEEuExlpdykNE18BSUlOpvQLyhfy/vKX6vQk6IExW9utbu+gZQFMDBmthSHLcbECFAcwYBHig4JX1
x-originating-ip: [172.21.80.105]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 08:06:04 -0000

Hi,

Harald Alvestrand wrote:
>
> Formalistically, the people who argue for abandoning an MTI, like the peo=
ple
> who argue for adapting an antiquated codec, have not put in a draft by th=
e
> chairs' deadline of October 6, so have not made a proposal.
>=20
> But I'm not the one who argued for this to be put on the agenda for 2 hou=
rs.
> The people who pushed for this to be on the agenda for 2 hours need to
> come forward and say why they believe this is a good use of our time. I
> haven't yet heard a VP8 proponent saying so.
>=20

I thought it has been mainly the VP8 proponents who have insisted to contin=
ue this discussion and have it on the agenda.

I am a H.264 proponent but it's clear to me there is no consensus, no subst=
antially new information since March, and for that reason the IETF should n=
ot pick either H.264 or VP8 as *mandatory*. And consequently 2 hours is too=
 much time for this.

It is useful to discuss pros and cons of H.264 and VP8 and compare them, si=
nce most likely every WebRTC endpoint will implement at least one of them, =
but I think we need to stop pushing for the decision of mandating one of th=
em.

Of course, if we come back to this issue every November, we can eventually =
choose H.264 as mandatory, after all of its IPR has expired :-)=20

Markus

From Markus.Isomaki@nokia.com  Fri Oct 25 01:15:47 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9425D21E80A6 for ; Fri, 25 Oct 2013 01:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUc3RgQkozvh for ; Fri, 25 Oct 2013 01:15:41 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD121E8094 for ; Fri, 25 Oct 2013 01:15:40 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.59]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r9P8BuME024607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 25 Oct 2013 11:11:57 +0300
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.235]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.03.0136.001; Fri, 25 Oct 2013 08:11:56 +0000
From: 
To: , 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0VimRcO5ZGLqUUag+6tiIuKaVJoFDwMQ
Date: Fri, 25 Oct 2013 08:11:56 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no> <526A25C0.6080406@bbs.darktech.org>
In-Reply-To: <526A25C0.6080406@bbs.darktech.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiWc+o8hXFUdLEV0dd3jRi9ZSnsyh2XxM9weacZlWDiXp2iugdu9/GeoD1NA6FKLHcwaKBRAiccUJ0MNT8h9MBXc/rgYtLrRsB5pMO+FxzwPovcKyyYUD6X9TbWJu8NgcZi7McFgkluASQ00lfICVg6apNxFMnyGEEuExlpdykNE18BSUlOpvQLyhfy/vKX6vQk6IExW9utbu+gZQFMDBmthSHLcbECFAcwYBHig4JX1
x-originating-ip: [172.21.80.105]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 08:15:47 -0000

Hi,

cowwoc wrote:
>=20
>      I think the real elephant in the room is whether Apple and Microsoft=
 (who
> are on the H264 bandwagon) will decide to implement VP8 just because you
> mandate it or whether they will side-step WebRTC altogether. FireFox's
> market-share is decline so more and more this is becoming a story of Chro=
me
> vs IE (on desktop) + Safari (on mobile).
>=20

I think we can equally well ask whether Chrome and Firefox will support H.2=
64 for WebRTC if IETF mandates that codec.

If the answer to both of these questions is "no", the value of the IETF dec=
ision is not that great.=20

Markus

From lorenzo@meetecho.com  Fri Oct 25 01:44:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD7211E82EA for ; Fri, 25 Oct 2013 01:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvBwnCBWsySp for ; Fri, 25 Oct 2013 01:44:29 -0700 (PDT)
Received: from smtpdg2.aruba.it (smtpdg220.aruba.it [62.149.158.220]) by ietfa.amsl.com (Postfix) with ESMTP id 292F011E82C8 for ; Fri, 25 Oct 2013 01:43:55 -0700 (PDT)
Received: from lminiero ([143.225.229.175]) by smtpcmd01.ad.aruba.it with bizsmtp id hLjs1m0113niPy701Ljsrr; Fri, 25 Oct 2013 10:43:53 +0200
Date: Fri, 25 Oct 2013 10:43:52 +0200
From: Lorenzo Miniero 
To: cowwoc 
Message-ID: <20131025104352.7333ee91@lminiero>
In-Reply-To: <526A25C0.6080406@bbs.darktech.org>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no> <526A25C0.6080406@bbs.darktech.org>
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
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 08:44:34 -0000

Il giorno Fri, 25 Oct 2013 04:03:12 -0400
cowwoc  ha scritto:

> On 25/10/2013 12:16 AM, Harald Alvestrand wrote:
> > On 10/25/2013 01:13 AM, cb.list6 wrote:
> >>
> >> There is no holding back vp8, it can always be negotiated.
> >>
> >> My guidance is no mti.
> >>
> >> I, for one, am tired of the gang-land ipr turf wars and posturing. 
> >> This argument is all about ipr, and ietf is explicitly setup to
> >> punt on all ipr issue because they are hard.
> >>
> >> Any layperson can see there is no concensus to be found. That's
> >> why we designed for codec negotiating and negotiating away from
> >> failure is left for implementation
> >>
> > Formalistically, the people who argue for abandoning an MTI, like
> > the people who argue for adapting an antiquated codec, have not put
> > in a draft by the chairs' deadline of October 6, so have not made a
> > proposal.
> >
> > But I'm not the one who argued for this to be put on the agenda for
> > 2 hours.
> > The people who pushed for this to be on the agenda for 2 hours need
> > to come forward and say why they believe this is a good use of our
> > time. I haven't yet heard a VP8 proponent saying so.
> >
> > So far, apart from learning a bit more about configuring x264, I 
> > haven't seen much new information.
> 
>      I think the real elephant in the room is whether Apple and 
> Microsoft (who are on the H264 bandwagon) will decide to implement
> VP8 just because you mandate it or whether they will side-step WebRTC 
> altogether. FireFox's market-share is decline so more and more this
> is becoming a story of Chrome vs IE (on desktop) + Safari (on mobile).
> 
>      The real question we should be asking is how to get Apple and 
> Microsoft on board. If we could get everyone on board, the question
> of what codec should be used would melt away (hint: there is no
> objective answer to this question).
> 
> Gili


The real question is not whether or not Apple and Microsoft will
implement VP8, but when they'll deign to start working on something
WebRTC at all. As most of the H.264 advocates in general, I'd dare to
say (at least from what I've seen so far).

Lorenzo


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


From keith.drage@alcatel-lucent.com  Fri Oct 25 01:51:06 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0097C11E834A for ; Fri, 25 Oct 2013 01:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.573
X-Spam-Level: 
X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Pm7-qRfDbm for ; Fri, 25 Oct 2013 01:50:58 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BB1CF11E8313 for ; Fri, 25 Oct 2013 01:50:56 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9P8ooQm019388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2013 03:50:51 -0500 (CDT)
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 r9P8omBR010245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 10:50:49 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 10:50:48 +0200
From: "DRAGE, Keith (Keith)" 
To: "Markus.Isomaki@nokia.com" , "harald@alvestrand.no" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0Tj33TqGWYrUlUulPtrUXYOsppoE7acAgAAlvcA=
Date: Fri, 25 Oct 2013 08:50:47 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no> 
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
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 08:51:06 -0000

Agree

We can either explicitly make a "no MTI" decision, or just let it become th=
e default by the absence of agreement.

Keith=20

> -----Original Message-----
> From: rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com
> Sent: 25 October 2013 09:04
> To: harald@alvestrand.no; rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
>=20
> Hi,
>=20
> Harald Alvestrand wrote:
> >
> > Formalistically, the people who argue for abandoning an=20
> MTI, like the=20
> > people who argue for adapting an antiquated codec, have not=20
> put in a=20
> > draft by the chairs' deadline of October 6, so have not=20
> made a proposal.
> >=20
> > But I'm not the one who argued for this to be put on the=20
> agenda for 2 hours.
> > The people who pushed for this to be on the agenda for 2=20
> hours need to=20
> > come forward and say why they believe this is a good use of=20
> our time.=20
> > I haven't yet heard a VP8 proponent saying so.
> >=20
>=20
> I thought it has been mainly the VP8 proponents who have=20
> insisted to continue this discussion and have it on the agenda.
>=20
> I am a H.264 proponent but it's clear to me there is no=20
> consensus, no substantially new information since March, and=20
> for that reason the IETF should not pick either H.264 or VP8=20
> as *mandatory*. And consequently 2 hours is too much time for this.
>=20
> It is useful to discuss pros and cons of H.264 and VP8 and=20
> compare them, since most likely every WebRTC endpoint will=20
> implement at least one of them, but I think we need to stop=20
> pushing for the decision of mandating one of them.
>=20
> Of course, if we come back to this issue every November, we=20
> can eventually choose H.264 as mandatory, after all of its=20
> IPR has expired :-)=20
>=20
> Markus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From lgeyser@gmail.com  Fri Oct 25 02:05:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1B11E82FC for ; Fri, 25 Oct 2013 02:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWZ-g8pd9jVS for ; Fri, 25 Oct 2013 02:05:34 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E611E82C8 for ; Fri, 25 Oct 2013 02:05:23 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id u14so490633lbd.22 for ; Fri, 25 Oct 2013 02:05:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i637FphcrUAUDcBW4yGJU81OlpRqdMWEDAuVS+H0YmU=; b=nXggA9imDVm0z/fk2ggP27wRakQbzakavebzC/K9njxbeZfs+su7KIg5J8Seg0Cq6L 0wPyyqv79akwOiOb5lOc671Rrjs2LnFQNI3moHZnwutDtop5yTdXoGItwnIR+4RZZ//L U6JPDfOzREFLE85VxFnvFcjRr2VOhtiX0SSsJRWbR3NlGbIU+BHMa2D3N5SGfN3gFYim RldQ5TMQeus1v/BMgbwJaqbvKGHfwCMhChC1lJ3DFJwSvbux3j5LcSQZtpo8LHeGsup2 OHzsV+IdW5DMs+PNyGCNDE82IupzoVJDYSgJ0bkvQqJSx7GCa6KAVltBWHNlagKmOQoi BqlQ==
MIME-Version: 1.0
X-Received: by 10.152.121.3 with SMTP id lg3mr4537296lab.0.1382691913671; Fri, 25 Oct 2013 02:05:13 -0700 (PDT)
Received: by 10.114.168.70 with HTTP; Fri, 25 Oct 2013 02:05:13 -0700 (PDT)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Fri, 25 Oct 2013 11:05:13 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0112d1645929b004e98d0c16
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 09:05:35 -0000

--089e0112d1645929b004e98d0c16
Content-Type: text/plain; charset=ISO-8859-1

It would be nice if video just works for the end user instead of them
having to install a different browser or buying a different device with a
different browser.

I personally think there needs to be a MTI video codec even if it is an old
codec such as H.261. Although the codec should not require a lot of
bandwidth to look decent which excludes something such as MJPEG.


On 25 October 2013 10:50, DRAGE, Keith (Keith) <
keith.drage@alcatel-lucent.com> wrote:

> Agree
>
> We can either explicitly make a "no MTI" decision, or just let it become
> the default by the absence of agreement.
>
> Keith
>
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org
> > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com
> > Sent: 25 October 2013 09:04
> > To: harald@alvestrand.no; rtcweb@ietf.org
> > Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
> >
> > Hi,
> >
> > Harald Alvestrand wrote:
> > >
> > > Formalistically, the people who argue for abandoning an
> > MTI, like the
> > > people who argue for adapting an antiquated codec, have not
> > put in a
> > > draft by the chairs' deadline of October 6, so have not
> > made a proposal.
> > >
> > > But I'm not the one who argued for this to be put on the
> > agenda for 2 hours.
> > > The people who pushed for this to be on the agenda for 2
> > hours need to
> > > come forward and say why they believe this is a good use of
> > our time.
> > > I haven't yet heard a VP8 proponent saying so.
> > >
> >
> > I thought it has been mainly the VP8 proponents who have
> > insisted to continue this discussion and have it on the agenda.
> >
> > I am a H.264 proponent but it's clear to me there is no
> > consensus, no substantially new information since March, and
> > for that reason the IETF should not pick either H.264 or VP8
> > as *mandatory*. And consequently 2 hours is too much time for this.
> >
> > It is useful to discuss pros and cons of H.264 and VP8 and
> > compare them, since most likely every WebRTC endpoint will
> > implement at least one of them, but I think we need to stop
> > pushing for the decision of mandating one of them.
> >
> > Of course, if we come back to this issue every November, we
> > can eventually choose H.264 as mandatory, after all of its
> > IPR has expired :-)
> >
> > Markus
> > _______________________________________________
> > 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
>

--089e0112d1645929b004e98d0c16
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


It would be nice if video just works for the end user=
 instead of them having to install a different browser or buying a differen=
t device with a different browser.

I personally think there ne=
eds to be a MTI video codec even if it is an old codec such as H.261. Altho=
ugh the codec should not require a lot of bandwidth to look decent which ex=
cludes something such as MJPEG.




On 25 O=
ctober 2013 10:50, DRAGE, Keith (Keith) <keith.drage@alcatel-=
lucent.com> wrote:


Agree



We can either explicitly make a "no MTI" decision, or just let it=
 become the default by the absence of agreement.



Keith




> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg

> [mailto:rtcweb-bounces@ietf=
.org] On Behalf Of Markus.I=
somaki@nokia.com

> Sent: 25 October 2013 09:04

> To: harald@alvestrand.no; =
rtcweb@ietf.org

> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

>


> Hi,

>

> Harald Alvestrand wrote:

> >

> > Formalistically, the people who argue for abandoning an

> MTI, like the

> > people who argue for adapting an antiquated codec, have not

> put in a

> > draft by the chairs' deadline of October 6, so have not

> made a proposal.

> >

> > But I'm not the one who argued for this to be put on the

> agenda for 2 hours.

> > The people who pushed for this to be on the agenda for 2

> hours need to

> > come forward and say why they believe this is a good use of

> our time.

> > I haven't yet heard a VP8 proponent saying so.

> >

>

> I thought it has been mainly the VP8 proponents who have

> insisted to continue this discussion and have it on the agenda.

>

> I am a H.264 proponent but it's clear to me there is no

> consensus, no substantially new information since March, and

> for that reason the IETF should not pick either H.264 or VP8

> as *mandatory*. And consequently 2 hours is too much time for this.
>

> It is useful to discuss pros and cons of H.264 and VP8 and

> compare them, since most likely every WebRTC endpoint will

> implement at least one of them, but I think we need to stop

> pushing for the decision of mandating one of them.

>

> Of course, if we come back to this issue every November, we

> can eventually choose H.264 as mandatory, after all of its

> IPR has expired :-)

>

> Markus

> _______________________________________________

> 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





--089e0112d1645929b004e98d0c16--

From Markus.Isomaki@nokia.com  Fri Oct 25 02:06:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE521E80BD for ; Fri, 25 Oct 2013 02:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfYLzoIJL3c7 for ; Fri, 25 Oct 2013 02:05:58 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3E21E80C1 for ; Fri, 25 Oct 2013 02:05:57 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.47]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r9P8xgRX008858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 25 Oct 2013 11:59:43 +0300
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.235]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.03.0136.001; Fri, 25 Oct 2013 08:59:41 +0000
From: 
To: , 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0CDhRcO5ZGLqUUag+6tiIuKaVJoCjkaAgAEDvACAAEBxAIAAMjWAgABmioCAAKhqMA==
Date: Fri, 25 Oct 2013 08:59:41 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiWc+o8hXFUdLEV0dd3jRi9ZSnsyh2XxM9weacZlWDiXp2iugdu9/GeoD1NA6FKLHcwaKBRAiccUJ0MNT8h9MBXc/rgYtLrRsB5pMO+FxzwPovcKyyYUD6X9TbWJu8NgcZi7McFgkluASQ00lfICVg6apNxFMnyGEEuExlpdykNE18BSUlOpvQLyhfy/vKX6vQk6IExW9utbu+gZQFMDBmthSHLcbECFAcwYBHig4JX1
x-originating-ip: [172.21.80.105]
Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A0F27E9008AM1MPN1043mg_"
MIME-Version: 1.0
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 09:06:03 -0000

--_000_E44893DD4E290745BB608EB23FDDB7620A0F27E9008AM1MPN1043mg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I don't think this is true. A person must disclose all IPR he/she is reason=
ably and personally aware of related to his/her own contribution or contrib=
ution made by others (in certain conditions). But in neither case is the pe=
rson required to know all potential IPR his/her employer has, nor is the em=
ployer required to do a search of their IPR portfolio for that purpose. In =
this particular case things are even more vague since neither VP8 or H.264 =
is an IETF-developed technology. IETF is just referencing those technologie=
s in its own documents. For instance regarding H.264 everyone's interpretat=
ion is (or seems to be) that IETF declarations are not done especially sinc=
e the IPR is already declared in ISO/MPEG/ITU. For VP8 Nokia indeed did a d=
eclaration, but we did not think we were _required_ to do so. And I have he=
ard from a few other companies that their interpretation is the same.

So I don't think the IETF IPR disclosure & declaration process can be much =
relied upon in this case, especially related to what IPR do the various _co=
mpanies_ _overall_ have. Otherwise we could also consider H.264 as unencumb=
ered since there are no IETF IPR declarations about it at the moment...

Markus


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 ext Silvia Pfeiffer
Sent: 25 October, 2013 01:10
To: Matthew Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue


If VP8 is chosen as MTI, you'd need to come out as per IETF requirements. S=
o would others. That's a good thing. If there indeed is anything there.
Silvia.
On 25 Oct 2013 03:11, "Matthew Kaufman (SKYPE)" > wrote:
On the IPR issue, Google reached agreement with 11 patent holders. There ar=
e at least 31 companies in the MPEG-LA H.264 pool. There is considerable te=
chnical overlap between VP8 and H.264.

My employer is one of those in the H.264 pool, and wasn't one of the 11 com=
panies Google reached an agreement with.

Draw your own conclusions and take your own IPR risks.

Personally I'd rather the IPR devil I know vs. the IPR devil I don't know.

Google could fix this for most potential users (through indemnification, si=
milar to what Oracle offers its Linux licensees) but has chosen not to. You=
 can draw your own conclusion there, too.

Matthew Kaufman

From: rtcweb-bounces@ietf.org [mailto:rtcwe=
b-bounces@ietf.org] On Behalf Of Bo Burman
Sent: Thursday, October 24, 2013 6:27 AM
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

1) We do agree that H.264 Constrained Baseline and VP8 are comparable in te=
rms of video quality. But do not forget that Constrained Baseline's twin si=
ster H.264 Constrained High outperforms VP8 by a huge margin. This is also =
relevant.

2) The "back-and forth of numbers" seems to refer to Ericsson's work where =
we tried to make a fair comparison to evaluate the extraordinary claims fro=
m Google that VP8 is 70 or 40 percent better than x264. We found serious is=
sues with the way Google performed the test, maybe the most striking were t=
he use of padding (+8% for x264) and excessive number of threads (+10% to +=
40% for x264) to add overhead to x264. That Google managed to remember the =
threading parameter only when it helped
VP8 (the speed test) is also quite remarkable.

3) Regarding IPR, this is a difficult topic, but we're not at all convinced=
 that VP8 is royalty free. For example, there is an IETF IPR disclosure (ht=
tps://datatracker.ietf.org/ipr/2035/) where the IPR holder seems unwilling =
to license (on any terms), and http://www.fosspatents.com/2013/06/german-vp=
8-infringement-cases-show.html and http://www.fosspatents.com/2013/06/itc-i=
nstitutes-investigation-of-nokias.html show that there are in fact ongoing =
litigations regarding VP8 - and this is only skimming the surface of what i=
s available in public space.

/Bo

From: rtcweb-bounces@ietf.org [mailto:rtcwe=
b-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: den 24 oktober 2013 13:12
To: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:

On 10/23/2013 02:51 PM, Harald Alvestrand wrote:

Just a reminder:

The back-and-forth of numbers doesn't change the core question of this

debate.

Both codecs are capable of high quality video encoding, and performance

numbers are comparable.



The real core question is the IPR issue.



The tradition of the IETF says that allowing only business models that

can sustain royalty agreements and royalty payments is Bad for the Internet=
.



The dominant video codec, H.264, is a royalty-required codec.



Do we switch now, or do we give up and live with royalties forever?





Harald,



I would like to see some references to the tradition of the IETF that

you've quoted.



For the record, I agree with the sentiment, but I'd like to be able to

back up the claim itself with references or explicit decisions that were

made in that regard.  I'm not trying to be a thorn in your side, just

looking for citations to back up the arguments, both on and off list.


Basil, very happy to provide references!

RFC 3979, a core document about IPR in the IETF, 2005:

8.  Evaluating Alternative Technologies in IETF Working Groups



   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.

The complete section gives some more details, but this is the central quote=
.

You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:

http://tools.ietf.org/html/rfc6569#page-8




--

Surveillance is pervasive. Go Dark.

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

--_000_E44893DD4E290745BB608EB23FDDB7620A0F27E9008AM1MPN1043mg_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

I don’t think this =
is true. A person must disclose all IPR he/she is reasonably and personally=
 aware of related to his/her own contribution or contribution
 made by others (in certain conditions). But in neither case is the person =
required to know all potential IPR his/her employer has, nor is the employe=
r required to do a search of their IPR portfolio for that purpose. In this =
particular case things are even
 more vague since neither VP8 or H.264 is an IETF-developed technology. IET=
F is just referencing those technologies in its own documents. For instance=
 regarding H.264 everyone’s interpretation is (or seems to be) that I=
ETF declarations are not done especially
 since the IPR is already declared in ISO/MPEG/ITU. For VP8 Nokia indeed di=
d a declaration, but we did not think we were _required_ to do so. A=
nd I have heard from a few other companies that their interpretation is the=
 same.



 <=
/p>

So I don’t think th=
e IETF IPR disclosure & declaration process can be much relied upon in =
this case, especially related to what IPR do the various _companies_
 _overall_ have. Otherwise we could also consider H.264 as unencumbe=
red since there are no IETF IPR declarations about it at the moment…<=
o:p>


 <=
/p>

Markus  <=
/span>


 <=
/p>

 <=
/p>







From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounce=
s@ietf.org]
On Behalf Of ext Silvia Pfeiffer

Sent: 25 October, 2013 01:10

To: Matthew Kaufman

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 


If VP8 is chosen as MTI, you'd need to come out as per IETF requirements=
. So would others. That's a good thing. If there indeed is anything there.<=
br>
Silvia.




On 25 Oct 2013 03:11, "Matthew Kaufman (SKYPE)&=
quot; <matthew.kaufman@skyp=
e.net> wrote:






On the IPR issue, Google reached agreem=
ent with 11 patent holders. There are at least 31 companies
 in the MPEG-LA H.264 pool. There is considerable technical overlap between=
 VP8 and H.264.


 


My employer is one of those in the H.26=
4 pool, and wasn’t one of the 11 companies Google reached
 an agreement with.


 


Draw your own conclusions and take your=
 own IPR risks.


 


Personally I’d rather the IPR dev=
il I know vs. the IPR devil I don’t know.


 


Google could fix this for most potentia=
l users (through indemnification, similar to what Oracle offers
 its Linux licensees) but has chosen not to. You can draw your own conclusi=
on there, too.


 




Matthew Kaufman




 








From:
rtcweb-bounces=
@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Bo Burman

Sent: Thursday, October 24, 2013 6:27 AM

To: Harald Alvestrand; rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 


1) We do agree that H.264 Constrained B=
aseline and VP8 are comparable in terms of video quality.
 But do not forget that Constrained Baseline's twin sister H.264 Constraine=
d High outperforms VP8 by a huge margin. This is also relevant.=



 


2) The "back-and forth of numbers&=
quot; seems to refer to Ericsson's work where we tried to make a fair
 comparison to evaluate the extraordinary claims from Google that VP8 is 70=
 or 40 percent better than x264. We found serious issues with the way Googl=
e performed the test, maybe the most striking were the use of padding (+=
;8% for x264) and excessive number of
 threads (+10% to +40% for x264) to add overhead to x264. That Goog=
le managed to remember the threading parameter only when it helped


VP8 (the speed test) is also quite rema=
rkable.


 


3) Regarding IPR, this is a difficult t=
opic, but we're not at all convinced that VP8 is royalty free.
 For example, there is an IETF IPR disclosure (https://datatracker.ietf.org/ipr/2=
035/) where the IPR holder seems unwilling to license (on any terms), a=
nd

http://www.fosspatents.com/2013/06/german-vp8-infringement-cases-show.html<=
/a> and

http://www.fosspatents.com/2013/06/itc-institutes-investigation-of-nokias.h=
tml show that there are in fact ongoing litigations regarding VP8 - and=
 this is only skimming the surface of what is available in public space.


 


/Bo


 








From:
rtcweb-bounces=
@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Harald Alvestrand

Sent: den 24 oktober 2013 13:12

To: rtcweb@ietf=
.org

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue






 




On 10/23/2013 09:42 PM, Basil Mohamed Gohar wrote:






On 10/23/2013 02:51 PM, Harald Alvestrand wrote:




Just a reminder:


The back-and-forth of numbers doesn't change the core question of this=



debate.


Both codecs are capable of high quality video encoding, and performanc=
e


numbers are comparable.


 


The real core question is the IPR issue.


 


The tradition of the IETF says that allowing only business models that=



can sustain royalty agreements and royalty payments is Bad for the Int=
ernet.


 


The dominant video codec, H.264, is a royalty-required codec.


 


Do we switch now, or do we give up and live with royalties forever?


 




 


Harald,


 


I would like to see some references to the tradition of the IETF that<=
o:p>


you've quoted.


 


For the record, I agree with the sentiment, but I'd like to be able to=



back up the claim itself with references or explicit decisions that we=
re


made in that regard.  I'm not trying to be a thorn in your side, =
just


looking for citations to back up the arguments, both on and off list.<=
o:p>


 




Basil, very happy to provide references!



RFC 3979, a core document about IPR in the IETF, 2005:


8.  Evaluating Alternative Technologies in IETF Working Groups


 


   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 hav=
e the discretion


   to adopt technology with a commitment of fair and non-dis=
criminatory


   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 l=
icenses.




The complete section gives some more details, but this is the central quote=
.



You may also enjoy reading the section of RFC 6569 (the guidelines that wer=
e followed in the OPUS work) that deals with IPR:



htt=
p://tools.ietf.org/html/rfc6569#page-8










-- 


Surveillance is pervasive. Go Dark.












_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb










--_000_E44893DD4E290745BB608EB23FDDB7620A0F27E9008AM1MPN1043mg_--

From keith.drage@alcatel-lucent.com  Fri Oct 25 04:13:06 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A559521F9ECE for ; Fri, 25 Oct 2013 04:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.574
X-Spam-Level: 
X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV9Ck9wVWttX for ; Fri, 25 Oct 2013 04:13:01 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CFE1F11E8127 for ; Fri, 25 Oct 2013 04:12:58 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9PBCpuZ022177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2013 06:12:53 -0500 (CDT)
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 r9PBColp010059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 13:12:50 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 13:12:50 +0200
From: "DRAGE, Keith (Keith)" 
To: Leon Geyser , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0WFQ3TqGWYrUlUulPtrUXYOsppoFQslw
Date: Fri, 25 Oct 2013 11:12:49 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BF4A7@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0BF4A7FR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 11:13:06 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B0BF4A7FR712WXCHMBA11zeu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If you want that, then you would need both VP8 and H.264 as MTI.

While VP8 might give you what you want in webrtc islands, it would not be a=
ble to communicate outside those islands, where the predominant codec is st=
ill H.248.

While a position of both codecs being MTI would be acceptable to me, I don'=
t see the VP8 proponents going there.

Keith

________________________________
From: Leon Geyser [mailto:lgeyser@gmail.com]
Sent: 25 October 2013 10:05
To: rtcweb@ietf.org
Cc: Markus.Isomaki@nokia.com; harald@alvestrand.no; DRAGE, Keith (Keith)
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

It would be nice if video just works for the end user instead of them havin=
g to install a different browser or buying a different device with a differ=
ent browser.

I personally think there needs to be a MTI video codec even if it is an old=
 codec such as H.261. Although the codec should not require a lot of bandwi=
dth to look decent which excludes something such as MJPEG.


On 25 October 2013 10:50, DRAGE, Keith (Keith) > wrote:
Agree

We can either explicitly make a "no MTI" decision, or just let it become th=
e default by the absence of agreement.

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behal=
f Of Markus.Isomaki@nokia.com
> Sent: 25 October 2013 09:04
> To: harald@alvestrand.no; rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
>
> Hi,
>
> Harald Alvestrand wrote:
> >
> > Formalistically, the people who argue for abandoning an
> MTI, like the
> > people who argue for adapting an antiquated codec, have not
> put in a
> > draft by the chairs' deadline of October 6, so have not
> made a proposal.
> >
> > But I'm not the one who argued for this to be put on the
> agenda for 2 hours.
> > The people who pushed for this to be on the agenda for 2
> hours need to
> > come forward and say why they believe this is a good use of
> our time.
> > I haven't yet heard a VP8 proponent saying so.
> >
>
> I thought it has been mainly the VP8 proponents who have
> insisted to continue this discussion and have it on the agenda.
>
> I am a H.264 proponent but it's clear to me there is no
> consensus, no substantially new information since March, and
> for that reason the IETF should not pick either H.264 or VP8
> as *mandatory*. And consequently 2 hours is too much time for this.
>
> It is useful to discuss pros and cons of H.264 and VP8 and
> compare them, since most likely every WebRTC endpoint will
> implement at least one of them, but I think we need to stop
> pushing for the decision of mandating one of them.
>
> Of course, if we come back to this issue every November, we
> can eventually choose H.264 as mandatory, after all of its
> IPR has expired :-)
>
> Markus
> _______________________________________________
> 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_949EF20990823C4C85C18D59AA11AD8B0BF4A7FR712WXCHMBA11zeu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









If you want that, then you would =
need both VP8 and H.264 as MTI.


 


While VP8 might give you what you=
 want in webrtc islands, it would not be able to communicate outside those =
islands, where the predominant codec is still
 H.248.


 


While a position of both codecs b=
eing MTI would be acceptable to me, I don't see the VP8 proponents going th=
ere.


 


Keith









From: Leon Geyser [mailto:lgeyser@g=
mail.com] 

Sent: 25 October 2013 10:05

To: rtcweb@ietf.org

Cc: Markus.Isomaki@nokia.com; harald@alvestrand.no; DRAGE, Keith (Ke=
ith)

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue










It would be nice if video just works for the end user instead of them =
having to install a different browser or buying a different device with a d=
ifferent browser.





I personally think there needs to be a MTI video codec even if it is an old=
 codec such as H.261. Although the codec should not require a lot of bandwi=
dth to look decent which excludes something such as MJPEG.









On 25 October 2013 10:50, DRAGE, Keith (Keith) <=
span dir=3D"ltr">
<kei=
th.drage@alcatel-lucent.com> wrote:



Agree



We can either explicitly make a "no MTI" decision, or just let it=
 become the default by the absence of agreement.



Keith





> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg

> [mailto:rtcweb-bounces@ietf=
.org] On Behalf Of
Markus.Isomaki@nokia.com
> Sent: 25 October 2013 09:04

> To: harald@alvestrand.no; =

rtcweb@ietf.org

> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

>






> Hi,

>

> Harald Alvestrand wrote:

> >

> > Formalistically, the people who argue for abandoning an

> MTI, like the

> > people who argue for adapting an antiquated codec, have not

> put in a

> > draft by the chairs' deadline of October 6, so have not

> made a proposal.

> >

> > But I'm not the one who argued for this to be put on the

> agenda for 2 hours.

> > The people who pushed for this to be on the agenda for 2

> hours need to

> > come forward and say why they believe this is a good use of

> our time.

> > I haven't yet heard a VP8 proponent saying so.

> >

>

> I thought it has been mainly the VP8 proponents who have

> insisted to continue this discussion and have it on the agenda.

>

> I am a H.264 proponent but it's clear to me there is no

> consensus, no substantially new information since March, and

> for that reason the IETF should not pick either H.264 or VP8

> as *mandatory*. And consequently 2 hours is too much time for this.
>

> It is useful to discuss pros and cons of H.264 and VP8 and

> compare them, since most likely every WebRTC endpoint will

> implement at least one of them, but I think we need to stop

> pushing for the decision of mandating one of them.

>

> Of course, if we come back to this issue every November, we

> can eventually choose H.264 as mandatory, after all of its

> IPR has expired :-)

>

> Markus

> _______________________________________________

> 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_949EF20990823C4C85C18D59AA11AD8B0BF4A7FR712WXCHMBA11zeu_--

From christer.holmberg@ericsson.com  Fri Oct 25 04:26:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714B311E83C1 for ; Fri, 25 Oct 2013 04:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.792
X-Spam-Level: 
X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[AWL=-1.194, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYQc6tJuJi7H for ; Fri, 25 Oct 2013 04:25:54 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6B11E8316 for ; Fri, 25 Oct 2013 04:25:36 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-a7-526a552f60fb
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 00.8C.09019.F255A625; Fri, 25 Oct 2013 13:25:35 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 13:25:35 +0200
From: Christer Holmberg 
To: "DRAGE, Keith (Keith)" , Leon Geyser , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0WFQ3TqGWYrUlUulPtrUXYOsppoFQslwgAAEDsCAAABB/Q==
Date: Fri, 25 Oct 2013 11:25:34 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F4C3C@ESESSMB209.ericsson.se>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com> , <949EF20990823C4C85C18D59AA11AD8B0BF4A7@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BF4A7@FR712WXCHMBA11.zeu.alcatel-lucent.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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F4C3CESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja5+aFaQwcZjmhZPG88yWnSvnsVm sfZfO7sDs0frs72sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxoKfm1kKLgdV/Gh/xdbA uNWti5GDQ0LARGLOltouRk4gU0ziwr31bF2MXBxCAkcZJU7cXM0M4SxhlNj65Tk7SAObgIVE 9z9tkLiIQDOjxI3u1Ywg3cICxhJL/l5nArFFgIb+f9QDZTtJLGiZygpiswioSnzZ/4EdxOYV 8JXo2LsfattnVonHneeZQRKcAtESj0/8BWtgBDrp+6k1YIOYBcQlbj2ZzwRxqoDEkj0Q9RIC ohIvH/9jhbCVJH5suMQCciizQL7EqXnyELsEJU7OfMIygVFkFpJJsxCqZiGpgijRk7gxdQob hK0tsWzha2YIW1dixr9DUDXWEhduXWNEVrOAkWMVI0dxanFSbrqRwSZGYJwd3PLbYgfj5b82 hxilOViUxHk/vnUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDYfutc5k/mlUHVfZq/ts6/ k7hgwf6qKefui+u1qnUYiqxTtd2v2lViKHp/BXNgYOHM+X2Mxvt9TDmX+Szf59/ed3TZnTOi XXcWy+52LJ+6NvH71n8nN1u8P72nM+nDug7+99Mv7Nyq86y6/Hu8y8q5QfzthRPe3/z5oafp Rka89lkDK0eVLikHJZbijERDLeai4kQAeHlPxoECAAA=
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 11:26:04 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C4F4C3CESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



>While VP8 might give you what you want in webrtc islands, it would not be =
able to communicate outside those islands, where the predominant codec is s=
till H.248.

If we choose the H.248 codec, we also need to choose an MTI encoding: text =
or binary ;)

Regards,

Christer


________________________________
From: Leon Geyser [mailto:lgeyser@gmail.com]
Sent: 25 October 2013 10:05
To: rtcweb@ietf.org
Cc: Markus.Isomaki@nokia.com; harald@alvestrand.no; DRAGE, Keith (Keith)
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

It would be nice if video just works for the end user instead of them havin=
g to install a different browser or buying a different device with a differ=
ent browser.

I personally think there needs to be a MTI video codec even if it is an old=
 codec such as H.261. Although the codec should not require a lot of bandwi=
dth to look decent which excludes something such as MJPEG.


On 25 October 2013 10:50, DRAGE, Keith (Keith) > wrote:
Agree

We can either explicitly make a "no MTI" decision, or just let it become th=
e default by the absence of agreement.

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behal=
f Of Markus.Isomaki@nokia.com
> Sent: 25 October 2013 09:04
> To: harald@alvestrand.no; rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
>
> Hi,
>
> Harald Alvestrand wrote:
> >
> > Formalistically, the people who argue for abandoning an
> MTI, like the
> > people who argue for adapting an antiquated codec, have not
> put in a
> > draft by the chairs' deadline of October 6, so have not
> made a proposal.
> >
> > But I'm not the one who argued for this to be put on the
> agenda for 2 hours.
> > The people who pushed for this to be on the agenda for 2
> hours need to
> > come forward and say why they believe this is a good use of
> our time.
> > I haven't yet heard a VP8 proponent saying so.
> >
>
> I thought it has been mainly the VP8 proponents who have
> insisted to continue this discussion and have it on the agenda.
>
> I am a H.264 proponent but it's clear to me there is no
> consensus, no substantially new information since March, and
> for that reason the IETF should not pick either H.264 or VP8
> as *mandatory*. And consequently 2 hours is too much time for this.
>
> It is useful to discuss pros and cons of H.264 and VP8 and
> compare them, since most likely every WebRTC endpoint will
> implement at least one of them, but I think we need to stop
> pushing for the decision of mandating one of them.
>
> Of course, if we come back to this issue every November, we
> can eventually choose H.264 as mandatory, after all of its
> IPR has expired :-)
>
> Markus
> _______________________________________________
> 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_7594FB04B1934943A5C02806D1A2204B1C4F4C3CESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable










 




>While VP8 might give you what=
 you want in webrtc islands, it would not be able to communicate outside th=
ose islands, where the predominant codec is still
 H.248.


 


If we choose the H.248 codec, we also n=
eed to choose an MTI encoding: text or binary ;)


 


Regards,


 


Christer


 









From: Leon Geyser [mailto:lgeyser@g=
mail.com] 

Sent: 25 October 2013 10:05

To: rtcweb@ietf.org

Cc: Markus.Isomaki@nokia.com; harald@alvestrand.no; DRAGE, Keith (Ke=
ith)

Subject: Re: [rtcweb] VP8 vs H.264 - the core issue










It would be nice if video just works for the end user instead of them =
having to install a different browser or buying a different device with a d=
ifferent browser.





I personally think there needs to be a MTI video codec even if it is an old=
 codec such as H.261. Although the codec should not require a lot of bandwi=
dth to look decent which excludes something such as MJPEG.









On 25 October 2013 10:50, DRAGE, Keith (Keith) <=
span dir=3D"ltr">
<kei=
th.drage@alcatel-lucent.com> wrote:



Agree



We can either explicitly make a "no MTI" decision, or just let it=
 become the default by the absence of agreement.



Keith





> -----Original Message-----

> From: rtc=
web-bounces@ietf.org

> [mailto:r=
tcweb-bounces@ietf.org] On Behalf Of
Markus.Isomak=
i@nokia.com

> Sent: 25 October 2013 09:04

> To: harald@a=
lvestrand.no;
rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

>






> Hi,

>

> Harald Alvestrand wrote:

> >

> > Formalistically, the people who argue for abandoning an

> MTI, like the

> > people who argue for adapting an antiquated codec, have not

> put in a

> > draft by the chairs' deadline of October 6, so have not

> made a proposal.

> >

> > But I'm not the one who argued for this to be put on the

> agenda for 2 hours.

> > The people who pushed for this to be on the agenda for 2

> hours need to

> > come forward and say why they believe this is a good use of

> our time.

> > I haven't yet heard a VP8 proponent saying so.

> >

>

> I thought it has been mainly the VP8 proponents who have

> insisted to continue this discussion and have it on the agenda.

>

> I am a H.264 proponent but it's clear to me there is no

> consensus, no substantially new information since March, and

> for that reason the IETF should not pick either H.264 or VP8

> as *mandatory*. And consequently 2 hours is too much time for this.
>

> It is useful to discuss pros and cons of H.264 and VP8 and

> compare them, since most likely every WebRTC endpoint will

> implement at least one of them, but I think we need to stop

> pushing for the decision of mandating one of them.

>

> Of course, if we come back to this issue every November, we

> can eventually choose H.264 as mandatory, after all of its

> IPR has expired :-)

>

> Markus

> _______________________________________________

> 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_7594FB04B1934943A5C02806D1A2204B1C4F4C3CESESSMB209erics_--

From jlaurens@cisco.com  Fri Oct 25 04:26:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9E11E83C4 for ; Fri, 25 Oct 2013 04:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-pg32dLcszd for ; Fri, 25 Oct 2013 04:26:04 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C603411E83A6 for ; Fri, 25 Oct 2013 04:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21333; q=dns/txt; s=iport; t=1382700343; x=1383909943; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XTwa5imZVXGvO8sXN4MQlkbod2v86hs7Ia7L/0zUPnE=; b=YmMTdk/cPiho2YDOaA9+fX4qv4ozZaIKxcILAhSTvYjDIk+8hq2rPPER gYD3BCpl/ryK9QUh8VfxGcNuXyjuLZixXBkurXVMb5OlfZbe9LpL8Qo2j /DBri1605zlzJgEzf+U5do6LZD5UAuSqvDmxT8cQxHs8scTRmd0uyiA7k w=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUGAPFTalKtJV2c/2dsb2JhbABZgwc4VL1+S4EhFm0HgiUBAQEDAQEBAQtXCRAHBAIBCBEEAQEBCh0HAh8GCxQJCAIEEwgGh2cDCQYNr1INiWcEjGOCPy0LBoMZgQ0DkC2BMIRCjjuFN4Mmgio
X-IronPort-AV: E=Sophos;i="4.93,569,1378857600";  d="p7s'?scan'208,217";a="276648007"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 25 Oct 2013 11:25:37 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9PBPbHn031462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Oct 2013 11:25:37 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 06:25:36 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0PpTxT4El2I6hESqrgdop2l1XQ==
Date: Fri, 25 Oct 2013 11:25:35 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.208.62]
Content-Type: multipart/signed; boundary="Apple-Mail=_C2D9D839-5110-474E-A235-F1D8B267CAE0"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 11:26:10 -0000

--Apple-Mail=_C2D9D839-5110-474E-A235-F1D8B267CAE0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_28262C08-9787-4633-A4DE-5D14EA4680A9"


--Apple-Mail=_28262C08-9787-4633-A4DE-5D14EA4680A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

First, my area of focus is system deployment for existing organizations, =
and my employer is clearly leaning H.264, however as an individual:

I am of the opinion that from a "browser user perspective" this is =
pretty easy because two of the issues I see seem not to have a =
significant winner based on all this list activity:
	The average browser user does not care, except that bandwidth is =
materially affected - and there seems both are close in performance.
		(Profiles and efficiency could be argued forever at this =
rate)
	IPR does seem to be in the air - and without being a lawyer, I =
see Nokia folks on this list declaring there is an issue here.
		(But lawyers can argue forever)

There seems to be a split.... however I believe the third factor here, =
while less technical in nature, will affect deployment and adoption.

I believe the ability to leverage existing applications/infrastructure =
with a relatively small amount of work is a third leg in this stool and =
tips the balance materially for those looking to light up applications.

Simply put, a user would ask why a new, less-interoperable standard is =
being introduced in absence of  functionality or bandwidth savings.

This has material cost savings and media flow implications for a large =
set of the people who are going to use this technology. Clearly this was =
an important factor based on the SDP slant of the content of the spec.
=09
In my opinion we are not paying enough attention to an important line in =
the burman h.264 proposal: "In addition, using H.264 enables =
interoperability with many other services without video transcoding."

On Oct 25, 2013, at 5:05 AM, Leon Geyser  wrote:

> It would be nice if video just works for the end user instead of them =
having to install a different browser or buying a different device with =
a different browser.
>=20
> I personally think there needs to be a MTI video codec even if it is =
an old codec such as H.261. Although the codec should not require a lot =
of bandwidth to look decent which excludes something such as MJPEG.
>=20
>=20
> On 25 October 2013 10:50, DRAGE, Keith (Keith) =
 wrote:
> Agree
>=20
> We can either explicitly make a "no MTI" decision, or just let it =
become the default by the absence of agreement.
>=20
> Keith
>=20
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org
> > [mailto:rtcweb-bounces@ietf.org] On Behalf Of =
Markus.Isomaki@nokia.com
> > Sent: 25 October 2013 09:04
> > To: harald@alvestrand.no; rtcweb@ietf.org
> > Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
> >
> > Hi,
> >
> > Harald Alvestrand wrote:
> > >
> > > Formalistically, the people who argue for abandoning an
> > MTI, like the
> > > people who argue for adapting an antiquated codec, have not
> > put in a
> > > draft by the chairs' deadline of October 6, so have not
> > made a proposal.
> > >
> > > But I'm not the one who argued for this to be put on the
> > agenda for 2 hours.
> > > The people who pushed for this to be on the agenda for 2
> > hours need to
> > > come forward and say why they believe this is a good use of
> > our time.
> > > I haven't yet heard a VP8 proponent saying so.
> > >
> >
> > I thought it has been mainly the VP8 proponents who have
> > insisted to continue this discussion and have it on the agenda.
> >
> > I am a H.264 proponent but it's clear to me there is no
> > consensus, no substantially new information since March, and
> > for that reason the IETF should not pick either H.264 or VP8
> > as *mandatory*. And consequently 2 hours is too much time for this.
> >
> > It is useful to discuss pros and cons of H.264 and VP8 and
> > compare them, since most likely every WebRTC endpoint will
> > implement at least one of them, but I think we need to stop
> > pushing for the decision of mandating one of them.
> >
> > Of course, if we come back to this issue every November, we
> > can eventually choose H.264 as mandatory, after all of its
> > IPR has expired :-)
> >
> > Markus
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_28262C08-9787-4633-A4DE-5D14EA4680A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


First, my area of focus is system deployment =
for existing organizations, and my employer is clearly leaning H.264, =
however as an individual:

I am of the opinion that from a =
"browser user perspective" this is pretty easy because two of the issues =
I see seem not to have a significant winner based on all this list =
activity:
	The average browser user does not =
care, except that bandwidth is materially affected - and there seems =
both are close in performance.
		=
(Profiles and efficiency could be argued forever at this =
rate)
	IPR does seem to be in the air - =
and without being a lawyer, I see Nokia folks on this list declaring =
there is an issue here.
		(But lawyers can argue =
forever)

There seems to be a split.... however =
I believe the third factor here, while less technical in nature, will =
affect deployment and adoption.

I believe the =
ability to leverage existing applications/infrastructure with a =
relatively small amount of work is a third leg in this stool and tips =
the balance materially for those looking to light up =
applications.

Simply put, a user would ask why =
a new, less-interoperable standard is being introduced in absence of =
 functionality or bandwidth savings.

This =
has material cost savings and media flow implications for a large set of =
the people who are going to use this technology. Clearly this was an =
important factor based on the SDP slant of the content of the =
spec.
	
In my opinion we are not paying =
enough attention to an important line in the burman h.264 proposal: =
"In =
addition, using H.264 enables interoperability with many other services =
without video transcoding."






On Oct 25, 2013, at 5:05 AM, Leon Geyser <lgeyser@gmail.com> =
wrote:

It would be nice if video =
just works for the end user instead of them having to install a =
different browser or buying a different device with a different =
browser.

I personally think there needs to be a MTI video =
codec even if it is an old codec such as H.261. Although the codec =
should not require a lot of bandwidth to look decent which excludes =
something such as MJPEG.




On =
25 October 2013 10:50, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> =
wrote:


Agree



We can either explicitly make a "no MTI" decision, or just let it become =
the default by the absence of agreement.



Keith




> -----Original Message-----

> From: rtcweb-bounces@ietf.org

> [mailto:rtcweb-bounces@ietf.org] On =
Behalf Of Markus.Isomaki@nokia.com

> Sent: 25 October 2013 09:04

> To: harald@alvestrand.no;=
 rtcweb@ietf.org

> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

>


> Hi,

>

> Harald Alvestrand wrote:

> >

> > Formalistically, the people who argue for abandoning an

> MTI, like the

> > people who argue for adapting an antiquated codec, have =
not

> put in a

> > draft by the chairs' deadline of October 6, so have not

> made a proposal.

> >

> > But I'm not the one who argued for this to be put on the

> agenda for 2 hours.

> > The people who pushed for this to be on the agenda for 2

> hours need to

> > come forward and say why they believe this is a good use =
of

> our time.

> > I haven't yet heard a VP8 proponent saying so.

> >

>

> I thought it has been mainly the VP8 proponents who have

> insisted to continue this discussion and have it on the agenda.

>

> I am a H.264 proponent but it's clear to me there is no

> consensus, no substantially new information since March, and

> for that reason the IETF should not pick either H.264 or VP8

> as *mandatory*. And consequently 2 hours is too much time for =
this.

>

> It is useful to discuss pros and cons of H.264 and VP8 and

> compare them, since most likely every WebRTC endpoint will

> implement at least one of them, but I think we need to stop

> pushing for the decision of mandating one of them.

>

> Of course, if we come back to this issue every November, we

> can eventually choose H.264 as mandatory, after all of its

> IPR has expired :-)

>

> Markus

> _______________________________________________

> 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.or=
g/mailman/listinfo/rtcweb

=

--Apple-Mail=_28262C08-9787-4633-A4DE-5D14EA4680A9--

--Apple-Mail=_C2D9D839-5110-474E-A235-F1D8B267CAE0
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTAyNTExMjUzNlowIwYJKoZIhvcNAQkEMRYEFNa2IMNqOVJF1mZo8A2elmvdBy6h
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAQQrSIQ2dG/I38IzKYw+YCgKzbvvD
ooUcrTkHSe7dTioPQhdp0AiQ6yAeGKseBxD2w+xU0OqIgZRcWhXUbGcp+pJX481dfYPm6CUJ35fC
hdQEFPmshiRmPlx4yDuxm22LFk1wQSGtGgHUwaJrOjME+9eVDYh6A8kq+tKdmkbWk/NWhlAe3oTH
JLMVvjvQN41DN5sh+gYSZ51QXKuf7f8XrASxFXyKoue6rfwESJW4JjEmT8doPdID44t8YPS7bYN2
Ey3kBLaaZ3zeATUS8q8qRjzSFDlxiSdc7Ddrni1z1IVEkyXL6/qerAOEYdOtnj3v2uYgB9/vzN5t
ohH2tOsK6QAAAAAAAA==

--Apple-Mail=_C2D9D839-5110-474E-A235-F1D8B267CAE0--

From keith.drage@alcatel-lucent.com  Fri Oct 25 04:28:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715BB11E8127 for ; Fri, 25 Oct 2013 04:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.576
X-Spam-Level: 
X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIOzNH9WNZtl for ; Fri, 25 Oct 2013 04:28:08 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id EAAB811E830A for ; Fri, 25 Oct 2013 04:28:07 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9PBS3pp024619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2013 06:28:05 -0500 (CDT)
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 r9PBS1lv030325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 13:28:02 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 13:28:02 +0200
From: "DRAGE, Keith (Keith)" 
To: Leon Geyser , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0WFQ3TqGWYrUlUulPtrUXYOsppoFQslwgAAE3PA=
Date: Fri, 25 Oct 2013 11:28:02 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BF512@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B0BF4A7@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BF4A7@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.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 11:28:13 -0000

Correction - meant H.264 in the message below.

Keith=20

> -----Original Message-----
> From: rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
> Sent: 25 October 2013 12:13
> To: Leon Geyser; rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
>=20
> If you want that, then you would need both VP8 and H.264 as MTI.
> =20
> While VP8 might give you what you want in webrtc islands, it=20
> would not be able to communicate outside those islands, where=20
> the predominant codec is still H.248.
> =20
> While a position of both codecs being MTI would be acceptable=20
> to me, I don't see the VP8 proponents going there.
> =20
> Keith
>=20
>=20
> ________________________________
>=20
> 	From: Leon Geyser [mailto:lgeyser@gmail.com]=20
> 	Sent: 25 October 2013 10:05
> 	To: rtcweb@ietf.org
> 	Cc: Markus.Isomaki@nokia.com; harald@alvestrand.no;=20
> DRAGE, Keith (Keith)
> 	Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
> =09
> =09
> 	It would be nice if video just works for the end user=20
> instead of them having to install a different browser or=20
> buying a different device with a different browser.
> =09
> =09
> 	I personally think there needs to be a MTI video codec=20
> even if it is an old codec such as H.261. Although the codec=20
> should not require a lot of bandwidth to look decent which=20
> excludes something such as MJPEG.
> =09
>=20
>=20
> 	On 25 October 2013 10:50, DRAGE, Keith (Keith)=20
>  wrote:
> =09
>=20
> 		Agree
> 	=09
> 		We can either explicitly make a "no MTI"=20
> decision, or just let it become the default by the absence of=20
> agreement.
> 	=09
> 		Keith
> 	=09
>=20
> 		> -----Original Message-----
> 		> From: rtcweb-bounces@ietf.org
> 		> [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20
> Markus.Isomaki@nokia.com
> 		> Sent: 25 October 2013 09:04
> 		> To: harald@alvestrand.no; rtcweb@ietf.org=20
> =20
> 		> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
> 		>
> 	=09
> 		> Hi,
> 		>
> 		> Harald Alvestrand wrote:
> 		> >
> 		> > Formalistically, the people who argue for=20
> abandoning an
> 		> MTI, like the
> 		> > people who argue for adapting an antiquated=20
> codec, have not
> 		> put in a
> 		> > draft by the chairs' deadline of October 6,=20
> so have not
> 		> made a proposal.
> 		> >
> 		> > But I'm not the one who argued for this to=20
> be put on the
> 		> agenda for 2 hours.
> 		> > The people who pushed for this to be on the=20
> agenda for 2
> 		> hours need to
> 		> > come forward and say why they believe this=20
> is a good use of
> 		> our time.
> 		> > I haven't yet heard a VP8 proponent saying so.
> 		> >
> 		>
> 		> I thought it has been mainly the VP8=20
> proponents who have
> 		> insisted to continue this discussion and have=20
> it on the agenda.
> 		>
> 		> I am a H.264 proponent but it's clear to me=20
> there is no
> 		> consensus, no substantially new information=20
> since March, and
> 		> for that reason the IETF should not pick=20
> either H.264 or VP8
> 		> as *mandatory*. And consequently 2 hours is=20
> too much time for this.
> 		>
> 		> It is useful to discuss pros and cons of=20
> H.264 and VP8 and
> 		> compare them, since most likely every WebRTC=20
> endpoint will
> 		> implement at least one of them, but I think=20
> we need to stop
> 		> pushing for the decision of mandating one of them.
> 		>
> 		> Of course, if we come back to this issue=20
> every November, we
> 		> can eventually choose H.264 as mandatory,=20
> after all of its
> 		> IPR has expired :-)
> 		>
> 		> Markus
> 		> _______________________________________________
> 		> 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
> 	=09
>=20
>=20
> =

From cb.list6@gmail.com  Fri Oct 25 09:36:19 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BF211E836D for ; Fri, 25 Oct 2013 09:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIVcV5EomNJU for ; Fri, 25 Oct 2013 09:36:01 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE6B11E8363 for ; Fri, 25 Oct 2013 09:36:01 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id t60so4127146wes.30 for ; Fri, 25 Oct 2013 09:36:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8gFeSOeJrK2nNbXiMH568iOG9QbKQ/QSDBhHceftD28=; b=GZr27l2SR8Ph5RSPHT9OSfpTqnF45oRNORXhdAcVyhCGOqh8yzUGFCL4q7KNjXf+9T oRMoSRaeDKm2cXPU4+5e67KLWv11hHLLknbu5tBeaeXL/1zD5xBcdjcSgC1Yvndiah2W xihwlObf3fXhUe0xr6MktFNLNubMLlGDiX8p8wn8fiOK7NDkFLOBr/l3hc0boc+nw3w0 xXYt6EYkcfZClA0PzztAr+qCTEyPHLM9uU6dR1aGOa5vJ4GoVhgQGejlWXyLa4SSkD0Q 6kcFTu18dGz0NRI94xai0Fx80+646dtHib7kfr65W1Bt2F/Igqw9+GwrVwjGYKIkpZFV lIbw==
MIME-Version: 1.0
X-Received: by 10.194.20.170 with SMTP id o10mr8124820wje.4.1382718960136; Fri, 25 Oct 2013 09:36:00 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Fri, 25 Oct 2013 09:35:59 -0700 (PDT)
In-Reply-To: <5269F098.2020904@alvestrand.no>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>
Date: Fri, 25 Oct 2013 09:35:59 -0700
Message-ID: 
From: "cb.list6" 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 16:36:19 -0000

On Thu, Oct 24, 2013 at 9:16 PM, Harald Alvestrand  wrote:
> On 10/25/2013 01:13 AM, cb.list6 wrote:
>>
>>
>> There is no holding back vp8, it can always be negotiated.
>>
>> My guidance is no mti.
>>
>> I, for one, am tired of the gang-land ipr turf wars and posturing. This
>> argument is all about ipr, and ietf is explicitly setup to punt on all ipr
>> issue because they are hard.
>>
>> Any layperson can see there is no concensus to be found. That's why we
>> designed for codec negotiating and negotiating away from failure is left for
>> implementation
>>
> Formalistically, the people who argue for abandoning an MTI, like the people
> who argue for adapting an antiquated codec, have not put in a draft by the
> chairs' deadline of October 6, so have not made a proposal.
>

Yes. I should have done a better job of advocating no MTI in a timely manner.

I am happy to post an I-D when the tool comes back up, or i can email
it.  But, i respect the chairs need for a deadline and that i have
missed it.

I am happy to present the salient points in Vancouver if asked to.

That said, here they are in email:

1.  There are 2 camps H264 and VP8

2.  H264 and VP8 are both high quality and efficient video codecs,
there is no dispute

3.  H264 camp claims there is no IPR liability-free path.  Thus they
claim H264 has a more mature IPR model via MPEG than VP8.

4.  The IETF does not adjudicate on validity of any IPR claim, the
IETF only distributes information that is volunteered to the IETF.

5.  The 2 camps have irreconcilable legal and business assumptions,
thus the ideal of MTI cannot be achieved.

6.  Having both H264 and VP8 as MTI is not viable, because we know it
would cannot be true that both would be implemented.

7.  Voice-only WebRTC does have an MTI.  In the event that a common
video codec cannot be negotiated during video session setup, the
session SHOULD fall-back to voice-only session negotiation where there
is a MTI .

CB




> But I'm not the one who argued for this to be put on the agenda for 2 hours.
> The people who pushed for this to be on the agenda for 2 hours need to come
> forward and say why they believe this is a good use of our time. I haven't
> yet heard a VP8 proponent saying so.
>
> So far, apart from learning a bit more about configuring x264, I haven't
> seen much new information.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From juberti@google.com  Fri Oct 25 12:50:41 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC30711E8182 for ; Fri, 25 Oct 2013 12:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DfHx4hETCm5 for ; Fri, 25 Oct 2013 12:50:41 -0700 (PDT)
Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC511E8137 for ; Fri, 25 Oct 2013 12:50:40 -0700 (PDT)
Received: by mail-vb0-f43.google.com with SMTP id g10so2879355vbg.30 for ; Fri, 25 Oct 2013 12:50:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eGexBcG6ow2+8gDWPMz7BwnoEwmXvfbSsAkwQViFmJY=; b=eujZzXg5impl2Vm2x9v66/Vrnhdp6i+YHIFLR8xOFWBEePi/RsCuDI2D9x9jK5+Rlm PierH5pTY0Mp6yIZmD3iJCvjYNZQghWXv0T4sh2o0J4HJnBZZoVVEFD+3XT/fvkvreY3 xz/oJMaSGOZlIBg/SO0gkwrYiLoF4T/9BvM81qFYzTeBgd/erJATek6VO/wI2uY9L+bQ BVr2FAD7dLIggBjM3cWJDCOhqTwtqBdyvvldIIyLEloGbNiG36JVJisBpWonUsYQJmr7 xrTxGDoYktRu2UGMCb7HF+g/29b79tBbR8RehnL0bnZI1A4TW/qhiqDDbaju0GrhbHgs Q1Bw==
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=eGexBcG6ow2+8gDWPMz7BwnoEwmXvfbSsAkwQViFmJY=; b=Crbbxj+/5dr4bGBkTMtq6j4ObS7w9A4Kud+K2E5LQ5VdAzI7BuooTro6VZyqmLkVF9 YE04af9oSkAqReBtQoOZbhdHRUzVKfZQfh12RsbEDCyX97FW6qpZjDi9ouvQC1h3/QfO 5yw7BCyMBthohnPnsQB2ScJsk7WK9KKQt/Uqzo2ccD6t9kCyfAEw0YysALdQzGa+mvLn 2fNTVELRg+reUT3xD5qxgT7+6iIpvurPu3VsF7vKdiyUi8duGvAPDZuO+hwkv5DGAM06 BRo9HCdbzkhcZyqr26jP7OhxjR2yNO0ZAL/9dTCt2x+4MqpCvsZKEDo9Qff/ju2Bip5z txXg==
X-Gm-Message-State: ALoCoQkswX4kqkVFZr5l3OR3DKlTr7Bw51T4/MUJkb2EWqi+Ioys16yJv/WH9AGen6ELoIi1QNbkMlbr+WvNCz9k/cBNlsUzmzzWExNfM9uoAibFMJEOYT/eyhRNfANRO/PiAshxrCPG57h3wD4ek35oGtXy3h+5s2mjOIMCPlQdVw/kWAKPDkKQ+oo8cEY6shPv6jmi3WmH
X-Received: by 10.52.230.35 with SMTP id sv3mr4789996vdc.27.1382730639984; Fri, 25 Oct 2013 12:50:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 25 Oct 2013 12:50:18 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>  
From: Justin Uberti 
Date: Fri, 25 Oct 2013 12:50:18 -0700
Message-ID: 
To: "Jeremy Laurenson (jlaurens)" 
Content-Type: multipart/alternative; boundary=089e0102fe6e9dec7c04e9961032
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 19:50:42 -0000

--089e0102fe6e9dec7c04e9961032
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 25, 2013 at 4:25 AM, Jeremy Laurenson (jlaurens) <
jlaurens@cisco.com> wrote:

> First, my area of focus is system deployment for existing organizations,
> and my employer is clearly leaning H.264, however as an individual:
>
> I am of the opinion that from a "browser user perspective" this is pretty
> easy because two of the issues I see seem not to have a significant winner
> based on all this list activity:
> The average browser user does not care, except that bandwidth is
> materially affected - and there seems both are close in performance.
>  (Profiles and efficiency could be argued forever at this rate)
> IPR does seem to be in the air - and without being a lawyer, I see Nokia
> folks on this list declaring there is an issue here.
>  (But lawyers can argue forever)
>

No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, "we
give up and live with royalties forever". This will have a significant
impact on WebRTC innovation and adoption.

The fact that there are some who disagree with the IPR status of VP8 does
not invalidate this point.

>
> There seems to be a split.... however I believe the third factor here,
> while less technical in nature, will affect deployment and adoption.
>
> I believe the ability to leverage existing applications/infrastructure
> with a relatively small amount of work is a third leg in this stool and
> tips the balance materially for those looking to light up applications.
>
> Simply put, a user would ask why a new, less-interoperable standard is
> being introduced in absence of  functionality or bandwidth savings.
>
> This has material cost savings and media flow implications for a large set
> of the people who are going to use this technology. Clearly this was an
> important factor based on the SDP slant of the content of the spec.
>  In my opinion we are not paying enough attention to an important line in
> the burman h.264 proposal: "In addition, using H.264 enables
> interoperability with many other services without video transcoding."
>

Nobody is saying implementors can't support H.264. If interoperability with
such services is a high priority, implementors will ship H.264 regardless
of what we decide here.

>
> On Oct 25, 2013, at 5:05 AM, Leon Geyser  wrote:
>
> It would be nice if video just works for the end user instead of them
> having to install a different browser or buying a different device with a
> different browser.
>
> I personally think there needs to be a MTI video codec even if it is an
> old codec such as H.261. Although the codec should not require a lot of
> bandwidth to look decent which excludes something such as MJPEG.
>
>
> On 25 October 2013 10:50, DRAGE, Keith (Keith) <
> keith.drage@alcatel-lucent.com> wrote:
>
>> Agree
>>
>> We can either explicitly make a "no MTI" decision, or just let it become
>> the default by the absence of agreement.
>>
>> Keith
>>
>> > -----Original Message-----
>> > From: rtcweb-bounces@ietf.org
>> > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com
>> > Sent: 25 October 2013 09:04
>> > To: harald@alvestrand.no; rtcweb@ietf.org
>> > Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
>> >
>> > Hi,
>> >
>> > Harald Alvestrand wrote:
>> > >
>> > > Formalistically, the people who argue for abandoning an
>> > MTI, like the
>> > > people who argue for adapting an antiquated codec, have not
>> > put in a
>> > > draft by the chairs' deadline of October 6, so have not
>> > made a proposal.
>> > >
>> > > But I'm not the one who argued for this to be put on the
>> > agenda for 2 hours.
>> > > The people who pushed for this to be on the agenda for 2
>> > hours need to
>> > > come forward and say why they believe this is a good use of
>> > our time.
>> > > I haven't yet heard a VP8 proponent saying so.
>> > >
>> >
>> > I thought it has been mainly the VP8 proponents who have
>> > insisted to continue this discussion and have it on the agenda.
>> >
>> > I am a H.264 proponent but it's clear to me there is no
>> > consensus, no substantially new information since March, and
>> > for that reason the IETF should not pick either H.264 or VP8
>> > as *mandatory*. And consequently 2 hours is too much time for this.
>> >
>> > It is useful to discuss pros and cons of H.264 and VP8 and
>> > compare them, since most likely every WebRTC endpoint will
>> > implement at least one of them, but I think we need to stop
>> > pushing for the decision of mandating one of them.
>> >
>> > Of course, if we come back to this issue every November, we
>> > can eventually choose H.264 as mandatory, after all of its
>> > IPR has expired :-)
>> >
>> > Markus
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--089e0102fe6e9dec7c04e9961032
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Oct 25, 2013 at 4:25 AM, Jeremy Laurenson (jlaurens) <jla=
urens@cisco.com> wrote:



First, my area of=
 focus is system deployment for existing organizations, and my employer is =
clearly leaning H.264, however as an individual:




I am of the opinion that from a "browser user perspective&quo=
t; this is pretty easy because two of the issues I see seem not to have a s=
ignificant winner based on all this list activity:
	The average browser user does not care,=
 except that bandwidth is materially affected - and there seems both are cl=
ose in performance.



		(Profiles and effic=
iency could be argued forever at this rate)
	IPR does seem to be in the air - and without =
being a lawyer, I see Nokia folks on this list declaring there is an issue =
here.



		(But lawyers can argue f=
orever)

No, this is a fun=
damental issue. If H.264 is the MTI, to quote Harald, "we give up and live with royal=
ties forever". This will have a significant impact on WebRTC innovatio=
n and adoption.




The=
 fact that there are some who disagree with the IPR status of VP8 does not =
invalidate this point.






There seems to be a split.... however I believe the third factor here, whil=
e less technical in nature, will affect deployment and adoption.
=

I believe the ability to leverage existing applications/infr=
astructure with a relatively small amount of work is a third leg in this st=
ool and tips the balance materially for those looking to light up applicati=
ons.




Simply put, a user would ask why a new, less-interopera=
ble standard is being introduced in absence of =C2=A0functionality or bandw=
idth savings.

This has material cost savings and m=
edia flow implications for a large set of the people who are going to use t=
his technology. Clearly this was an important factor based on the SDP slant=
 of the content of the spec.



	
In m=
y opinion we are not paying enough attention to an important line in the bu=
rman h.264 proposal: "In addition, using H.264 enables interoperability with many =
other services without video transcoding."




Nobody is saying i=
mplementors can't support H.264. If interoperability with such services=
 is a high priority, implementors will ship H.264 regardless of what we dec=
ide here.



























On Oct 25, 2013, at 5:05 AM, Leon Geyser <lgeyser@gmail.com> wrote:
It would be nice if v=
ideo just works for the end user instead of them having to install a differ=
ent browser or buying a different device with a different browser.



I personally think there needs to be a MTI video codec even if it=
 is an old codec such as H.261. Although the codec should not require a lot=
 of bandwidth to look decent which excludes something such as MJPEG.






On 25 O=
ctober 2013 10:50, DRAGE, Keith (Keith) <keith.drage@alcatel-=
lucent.com> wrote:




Agree



We can either explicitly make a "no MTI" decision, or just let it=
 become the default by the absence of agreement.



Keith




> -----Original Message-----

> From: rtc=
web-bounces@ietf.org

> [mailto:r=
tcweb-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com

> Sent: 25 October 2013 09:04

> To: harald@a=
lvestrand.no; rtcw=
eb@ietf.org

> Subject: Re: [rtcweb] VP8 vs H.264 - the core issue

>


> Hi,

>

> Harald Alvestrand wrote:

> >

> > Formalistically, the people who argue for abandoning an

> MTI, like the

> > people who argue for adapting an antiquated codec, have not

> put in a

> > draft by the chairs' deadline of October 6, so have not

> made a proposal.

> >

> > But I'm not the one who argued for this to be put on the

> agenda for 2 hours.

> > The people who pushed for this to be on the agenda for 2

> hours need to

> > come forward and say why they believe this is a good use of

> our time.

> > I haven't yet heard a VP8 proponent saying so.

> >

>

> I thought it has been mainly the VP8 proponents who have

> insisted to continue this discussion and have it on the agenda.

>

> I am a H.264 proponent but it's clear to me there is no

> consensus, no substantially new information since March, and

> for that reason the IETF should not pick either H.264 or VP8

> as *mandatory*. And consequently 2 hours is too much time for this.
>

> It is useful to discuss pros and cons of H.264 and VP8 and

> compare them, since most likely every WebRTC endpoint will

> implement at least one of them, but I think we need to stop

> pushing for the decision of mandating one of them.

>

> Of course, if we come back to this issue every November, we

> can eventually choose H.264 as mandatory, after all of its

> IPR has expired :-)

>

> Markus

> _______________________________________________

> 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
<=
a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
=
=
https://www.ietf.org/mailman/listinfo/rtcweb





______=
_________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e0102fe6e9dec7c04e9961032--

From richard.ejzak@alcatel-lucent.com  Fri Oct 25 13:51:46 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5911E8202 for ; Fri, 25 Oct 2013 13:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.575
X-Spam-Level: 
X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwwaI7BUk7eQ for ; Fri, 25 Oct 2013 13:51:41 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 081E311E81DC for ; Fri, 25 Oct 2013 13:51:40 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9PKpdXk028800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 25 Oct 2013 15:51:40 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9PKpd5a004372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Oct 2013 16:51:39 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 25 Oct 2013 16:51:39 -0400
From: "Ejzak, Richard P (Richard)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQgABIioCAABByAP//ww2ggABSCoD//8IcAIAA11OAgABsdbA=
Date: Fri, 25 Oct 2013 20:51:38 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no>
In-Reply-To: <5269F3B5.2020308@alvestrand.no>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 20:51:47 -0000

Hi Harald,
You said: " I can't see a way to mix the two paradigms that guarantees this=
 never happening."  The two paradigms being browser selection vs. applicati=
on selection of data channel stream ids.

I agree with this statement if the browser selection algorithm is based on =
DTLS role since the application needs to be able to select ids before the D=
TLS role is known.  It is also clear that this is not an easy problem to so=
lve since the peers need to interact in some way before their relative role=
s are clearly established.

I am ok with documenting this limitation clearly (i.e., that the applicatio=
n should use either browser selection of stream ids or application selectio=
n of stream ids but not both together) but have a suggested alternative sol=
ution for consideration.  I would prefer a solution where the two paradigms=
 can be "mixed", if one can be agreed.

My proposal has three elements, which together can guarantee that there are=
 no stream id allocation conflicts between peers:
	1. The browser and application select stream ids based on initial SDP offe=
rer/answerer role rather than DTLS role (e.g., initial offerer uses even id=
s, initial answerer uses odd ids).  With this rule, the offering applicatio=
n knows its role immediately without waiting for the DTLS or SDP handshake =
to occur.
	2. For early data channel creation, the browser assumes that it will take =
the offerer role in selecting stream ids until the application determines i=
ts role through the API (using JSEP API calls).
	3. The answerer application refrains from requesting browser selection of =
stream ids when creating data channels until after the browser knows it wil=
l take the answerer role (based on the sequence of JSEP API calls).  This i=
s not a significant limitation since the answerer will typically not even c=
reate its end of the peer connection until after it receives the offer.

This approach also has the advantage of being consistent with the data chan=
nel API spec as it is currently written, which requires stream id assignmen=
t at the time of data channel creation.

Another (admittedly secondary) advantage of choosing a new selection algori=
thm that makes the two paradigms compatible would be that external negotiat=
ion options could use the same algorithm and also be fully compatible with =
the in-band options.

BR, Richard

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Harald Alvestrand
> Sent: Thursday, October 24, 2013 11:30 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> 01.txt
>=20
> On 10/24/2013 10:38 PM, Ejzak, Richard P (Richard) wrote:
> > Hi Michael,
> >
> >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> >> Sent: Thursday, October 24, 2013 2:21 PM On Oct 24, 2013, at 8:36
> PM,
> >> "Ejzak, Richard P (Richard)"
> >>  wrote:
> >>
> >>> Justin, Michael,
> >>> Thanks for the clarifications.  One more question.  What happens if
> >> the application tries to select a stream id before the DTLS role is
> >> known and it ends up selecting an invalid one?
> >> I'm not completely familiar with the JS API, but if you want to
> >> select a stream, aren't you managing the stream completely on your
> >> own. I think the DTLS role stuff is only relevant if the streams are
> >> managed by the browser.
> > If this is the intent then that clarification would be very useful.
> Reading the API text again, it is clear that the browser only manages
> stream ids that it selects.  Does this mean that the browser stream id
> selection option is not compatible with the application stream id
> selection option?  Putting it more precisely, should we require that
> the application not be allowed to select stream ids prior to
> determining DTLS role if it expects that either side might use the
> browser stream id selection option?  It would be easier if the even/odd
> rule could be determined earlier than DTLS role establishment so that
> the application could use the same even/odd assignment rule for early
> data channel creation.
>=20
> My reading has been that once you start selecting IDs, you're
> responsible for making sure those don't collide with platform-generated
> ones, or deal with the result if they do.
>=20
> The result of
>=20
> A: pc.createDataChannel(label=3D"foo") -> (channel with ID =3D 5, open
> message sent)
> B: pc.createDataChannel(label=3D"bar", id=3D5) 
>=20
> should be well defined. I don't much care what the result is, as long
> as it's well defined; closing the channel and calling the onerror()
> handler with DOMError(error=3D"UsageError", message=3D"Duelling paradigms=
")
> is fine with me.
>=20
> I can't see a way to mix the two paradigms that guarantees this never
> happening.
>=20
> >
> >>> Michael,
> >>> While it's true that the data channel control protocol cannot open
> >> the channel with the peer before the DTLS role is known, the API
> >> allows the application to create the data channel before the DTLS
> >> role is known, in which case the sending of the Open message must
> >> wait until the SCTP association is established.  I want to know what
> >> the application is supposed to do it if needs to create data
> channels
> >> with preselected stream ids before the DTLS role is known.  This
> >> seems like something that the spec should make clear rather than
> >> leaving it to implementation.
> >> Can you assign the stream ID in the API? Could you point me to the
> >> text?
> > http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute
> in the RTCDataChannelInit dictionary that must be the equivalent of the
> "stream identifier".  No other interpretation makes sense to me but
> please correct me if I am wrong.  Note in particular the following text
> within the description of the createDataChannel procedure (my
> parenthetical): "If the value of the id attribute is null, initialize
> it to a value generated by the user agent (browser), according to the
> WebRTC DataChannel Protocol specification, and skip to the next step.
> Otherwise, if the value of the id attribute is taken by an existing
> RTCDataChannel, throw a TBD exception and abort these steps."  So "id"
> must refer to "stream identifier" since there is no other id in your
> draft that it could refer to.
> >
> > If I'm right, then it would be good if it were made clear that id
> refers to "stream identifier", but that is a w3c issue.  Quoting from
> 5.2.1 (my parentheticals for clarity): "The id was either assigned by
> the user agent (browser) at channel creation time (not channel opening
> time) or selected by the script (application). The attribute MUST
> return the value to which it was set when the RTCDataChannel was
> created (not opened)."
> >
> > I used the wrong terminology in my earlier mail when I referred to
> "open" of the data channel when I meant "creation".  Since the data
> channel can be "created" before DTLS role is known and before the data
> channel can be opened, the quoted text above would seem to indicate
> that the application can never determine the stream id actually
> assigned to the data channel if id can't be determined at time of
> creation.  Justin implied that the chrome behavior does not conform to
> this description.  Comment, Justin?
> >
> > It still seems to me that a change in the rule describing even/odd
> stream id assignment would be a good idea.
> >
> > BR, Richard
> > _______________________________________________
> > 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 cowwoc@bbs.darktech.org  Fri Oct 25 14:47:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8964E11E820C for ; Fri, 25 Oct 2013 14:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.932
X-Spam-Level: 
X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=-2.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVPRnzHTDfil for ; Fri, 25 Oct 2013 14:47:51 -0700 (PDT)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 777C521F9EF0 for ; Fri, 25 Oct 2013 14:47:51 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id k18so2600967qcv.10 for ; Fri, 25 Oct 2013 14:47:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=L7mCzqLp8Hpgc7qD17sXE72tTA2yTRPenA/XOyb986Q=; b=VdzPLfnLJHNbxpKYmPLyY82hmcKRCfcjbfzSJ98u5AkQaAmjWStCHNoAfNQasYUHaj ermfSN+D7+25K5ZpCjYjn+8/MzWd5pChax+4R0woEIBbfW6FXzW0MC0oOqW626pNUlLS 7U8SZdCpJiC/zMjM/D6OY5TOdqg6FZ+Nc7+4cZikZK9CxxWW0IBYrfLarboP7VemMpb8 51SrM5oAfXFsWolOENcuoS2hJqFTDqXIVbHJvnQHgUtNvS31XZmC0svNMXvgRmNOcKe+ fJlG8szNbAhP9JTobeY6VYTLiFUz14Uc7bJetzgx4LQ2qjWN2VEtv52QqNA6F8hG3ibv vZpw==
X-Gm-Message-State: ALoCoQmHoK6xD8vJEjN6DnDM7tgLfKvl4NfO12M+vCU04uLr08JguAyZdy1iCv6pIWzYuJEdP6fK
X-Received: by 10.49.110.36 with SMTP id hx4mr13401531qeb.93.1382737670801; Fri, 25 Oct 2013 14:47:50 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id jw9sm17324545qeb.2.2013.10.25.14.47.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 14:47:50 -0700 (PDT)
Message-ID: <526AE703.8000409@bbs.darktech.org>
Date: Fri, 25 Oct 2013 17:47:47 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>		 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070604070903020904090509"
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 21:47:57 -0000

This is a multi-part message in MIME format.
--------------070604070903020904090509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 25/10/2013 3:50 PM, Justin Uberti wrote:
> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, 
> "we give up and live with royalties forever". This will have a 
> significant impact on WebRTC innovation and adoption.
>
> The fact that there are some who disagree with the IPR status of VP8 
> does not invalidate this point.

     What prevents us from retiring H264, VP8 or any other codec in the 
future? Surely we are allowed to retire codecs after 5-10 years? If not, 
listing any codec as MTI (including VP8) places us at a some level of risk.

> Nobody is saying implementors can't support H.264. If interoperability 
> with such services is a high priority, implementors will ship H.264 
> regardless of what we decide here.

     The same is true for VP8, so why mandate it as required? If VP8 is 
as good as everyone alleges (and I think it is) then surely vendors 
should be moving in this direction. But they are not. Forcing VP8 as MTI 
comes across as a political ploy to force their hand.

     From an end-user point of view, the only thing I really care about 
is getting WebRTC support from Microsoft and Apple. Because I view 
everything through that prism, my primary concern is how this decision 
affects them jumping on board.

Gili

--------------070604070903020904090509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 25/10/2013 3:50 PM, Justin Uberti
      wrote:

    

    

      
No, this is a fundamental issue. If H.264 is the
        MTI, to quote Harald, "we give up
          and live with royalties forever". This will have a significant
          impact on WebRTC innovation and adoption.
        

          

            


              

            
The
                fact that there are some who disagree with the IPR
                status of VP8 does not invalidate this point.

          

        

      

    

    

        What prevents us from retiring H264, VP8 or any other codec in
    the future? Surely we are allowed to retire codecs after 5-10 years?
    If not, listing any codec as MTI (including VP8) places us at a some
    level of risk.

    

    

      

        

          

            
Nobody is saying implementors can't support H.264. If
              interoperability with such services is a high priority,
              implementors will ship H.264 regardless of what we decide
              here.

          

        

      

    

    

        The same is true for VP8, so why mandate it as required? If VP8
    is as good as everyone alleges (and I think it is) then surely
    vendors should be moving in this direction. But they are not.
    Forcing VP8 as MTI comes across as a political ploy to force their
    hand.

    

        From an end-user point of view, the only thing I really care
    about is getting WebRTC support from Microsoft and Apple. Because I
    view everything through that prism, my primary concern is how this
    decision affects them jumping on board.

    

    Gili

  


--------------070604070903020904090509--

From ted.ietf@gmail.com  Fri Oct 25 16:23:47 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB5C11E80F1 for ; Fri, 25 Oct 2013 16:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level: 
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WP0BqI5U7vX for ; Fri, 25 Oct 2013 16:23:46 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4237A11E819C for ; Fri, 25 Oct 2013 16:23:43 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id tp5so7425432ieb.2 for ; Fri, 25 Oct 2013 16:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SXlQ7g7EF1GvcHuMKhDfGsVh0ijnDLmlckUA3tX5+dk=; b=dXwkQTgudPZvrzZ766HBYeXrUvNhjdIjT9BvS8vv72PK6A/74SiOdXIOyvcn4xjSIZ Q+Rf1MQckQLn1xp87Kcg9myrqTh3dx7I7q1Fs8X0ghrJJCJGdYZSVAsMLRTYhYEcWQrp SxrstjSFY2FLOOJJsU6+DTjOzsb7GdljWC8ZaFaVSMRKJrkVooBVxXZ14/c9kOAjKxFa bYy7Et9CpR00Yo+BMvEseEpSWCylM6KkLXh0nO4R0gKo26AtNBS1Cfar5RJkk2rKZBDT WaTi1v7IBzBQTdRGCtCgh+s2Q/boN1x7cm4qsSUzaUKCtuI4t2A9VwdI7ua4jcHhXs4v DjVQ==
MIME-Version: 1.0
X-Received: by 10.50.120.104 with SMTP id lb8mr557351igb.22.1382743422763; Fri, 25 Oct 2013 16:23:42 -0700 (PDT)
Received: by 10.42.29.202 with HTTP; Fri, 25 Oct 2013 16:23:42 -0700 (PDT)
In-Reply-To: <526AE703.8000409@bbs.darktech.org>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org>
Date: Fri, 25 Oct 2013 16:23:42 -0700
Message-ID: 
From: Ted Hardie 
To: cowwoc 
Content-Type: multipart/alternative; boundary=047d7bd76bb2878b9304e9990a80
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 23:23:47 -0000

--047d7bd76bb2878b9304e9990a80
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 25, 2013 at 2:47 PM, cowwoc  wrote:

>
>     From an end-user point of view, the only thing I really care about is
> getting WebRTC support from Microsoft and Apple. Because I view everything
> through that prism, my primary concern is how this decision affects them
> jumping on board.
>

Do you mean "getting WebRTC support from Microsoft and Apple." or "adding
WebRTC support from Microsoft and  Apple to that available from Firefox and
Chrome?"

regards,

Ted Hardie

--047d7bd76bb2878b9304e9990a80
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Oct 25, 2013 at 2:47 PM, cowwoc =
<cowwoc@bbs=
.darktech.org> wrote:



 =20
   =20
 =20
  


    =A0=A0=A0 From an end-user point of view, the only thing I really care
    about is getting WebRTC support from Microsoft and Apple. Because I
    view everything through that prism, my primary concern is how this
    decision affects them jumping on board.

=

Do you mean "getting WebRTC support from Microsoft and Appl=
e." or "adding WebRTC support from Microsoft and=A0 Apple to that=
 available from Firefox and Chrome?" 


regards,

Ted Hardie


--047d7bd76bb2878b9304e9990a80--

From juberti@google.com  Fri Oct 25 16:32:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B720C11E819C for ; Fri, 25 Oct 2013 16:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pOtwV8KydU1 for ; Fri, 25 Oct 2013 16:32:26 -0700 (PDT)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08111E81CD for ; Fri, 25 Oct 2013 16:32:23 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id jy13so3937534veb.9 for ; Fri, 25 Oct 2013 16:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p2yVI5Ls5AqSYHTyMqBtIgD5jj/6ruOOH6qojj9NDwI=; b=VkJX94ZySmefDRy0gbt/lxaWVm94spqK2eiP3i9JjHwKxhG7PLdfe+ucjXbz+6KYeH YTTbR4n8ZE0pSbzpBj/a+jPq3Mzu3MpVvAxrhSSpL3rWhm14Kr6WQJSvEN3H7kl4KV43 6VJY7RS0O80PVLdb6ASU1fxpXY474HnnStMI+gYBfzaoMnMHniz3tponl5h01VUvoFzi K02oDZHCk7ivOgE/PbTplLx+Ph0HvEnC/xIS3+iaAZTT5TqPTkEZb160HYXUuE+pnZLz gD9M39fUQYoZgOXYhUEHf4/3zfKQL8uUi6pmBcsRoduLoBM2SMJuvnaXh41FoC0tyKsp yy5Q==
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=p2yVI5Ls5AqSYHTyMqBtIgD5jj/6ruOOH6qojj9NDwI=; b=gOyHcV3BekyH+YyDrWp70cgXN/vR/Fv7siASAudQEn1KwpKdMT8lmiJkQS3K3rkZJr qMUvmuynvtawtsQ3hAA2FIfkQpRXTIFoYas23E41HtEFMvqcyotpbWo0KwNH1WU4lDni j8P6i7WfXAW21CTc/hLAhvC+MeTMqw8UNgDJoZtonWg8SxyCvddnY024q8Nr64HyoNuW z4hWUWPit/TGgLfYDEJvkUCeviMaj9JRY+jJDhmi+2xXzMwDSnRq4S0SngzQCCvrORPp Jbo8bZgRVbynTvtZsAZ7rLiDhJTElvCyjJBLNmGY32qDv3IQnEjfi1OrXsX8DhZruedB 6+Qg==
X-Gm-Message-State: ALoCoQn+FcQmZatNg2sS6sLWU+jtEmaApTXO3UGDviITexdHAKQgQtI6Ez4Pe3BKE0q+rHQU0HZstld6Mki+o2x6TIMadwT0Z4AZFDCMR/qr3scWbSvH+1yQjgUMtXVP9A2QHCH4EdzM9kY33Y8RbvNRfkcqDw1uIWvR9WzTenGRmPeDhG0dTvUzol0v3eUn2jw4Wc905NCD
X-Received: by 10.58.39.97 with SMTP id o1mr6149323vek.15.1382743942798; Fri, 25 Oct 2013 16:32:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 25 Oct 2013 16:32:02 -0700 (PDT)
In-Reply-To: <526AE703.8000409@bbs.darktech.org>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org>
From: Justin Uberti 
Date: Fri, 25 Oct 2013 16:32:02 -0700
Message-ID: 
To: cowwoc 
Content-Type: multipart/alternative; boundary=089e011834d886b8c904e9992949
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 23:32:26 -0000

--089e011834d886b8c904e9992949
Content-Type: text/plain; charset=UTF-8

On Fri, Oct 25, 2013 at 2:47 PM, cowwoc  wrote:

>  On 25/10/2013 3:50 PM, Justin Uberti wrote:
>
> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, "we
> give up and live with royalties forever". This will have a significant
> impact on WebRTC innovation and adoption.
>
>  The fact that there are some who disagree with the IPR status of VP8
> does not invalidate this point.
>
>
>     What prevents us from retiring H264, VP8 or any other codec in the
> future? Surely we are allowed to retire codecs after 5-10 years? If not,
> listing any codec as MTI (including VP8) places us at a some level of risk.
>
>
>   Nobody is saying implementors can't support H.264. If interoperability
> with such services is a high priority, implementors will ship H.264
> regardless of what we decide here.
>
>
>     The same is true for VP8, so why mandate it as required?
>

Because we want to guarantee video interoperability without forcing
everyone to pay licensing feeds.


> If VP8 is as good as everyone alleges (and I think it is) then surely
> vendors should be moving in this direction. But they are not. Forcing VP8
> as MTI comes across as a political ploy to force their hand.
>

Regarding VP8, pretty much every SoC vendor is now shipping HW VP8
acceleration, so I think there is clear movement in this direction.

>
>     From an end-user point of view, the only thing I really care about is
> getting WebRTC support from Microsoft and Apple. Because I view everything
> through that prism, my primary concern is how this decision affects them
> jumping on board.
>

I can't speak for Microsoft and Apple, but I don't think they are sitting
around waiting for us to make up our mind on this.

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

--089e011834d886b8c904e9992949
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Fri, Oct 25, 2013 at 2:47 PM, cowwoc <cowwoc@bbs.darktech=
.org> wrote:




 =20
   =20
 =20
  

    
On 25/10/2013 3:50 PM, Justin Uberti
      wrote:

    

    

      
No, this is a fundamental issue. If H.264 is the
        MTI, to quote Harald, "we give up
          and live with royalties forever". This will have a significa=
nt
          impact on WebRTC innovation and adoption.
        

          

            


              

            
The
                fact that there are some who disagree with the IPR
                status of VP8 does not invalidate this point.

          

        

      

    

    

    =C2=A0=C2=A0=C2=A0 What prevents us from retiring H264, VP8 or any othe=
r codec in
    the future? Surely we are allowed to retire codecs after 5-10 years?
    If not, listing any codec as MTI (including VP8) places us at a some
    level of risk.


    

    

      

        

          

            
Nobody is saying implementors can't support H.264. If
              interoperability with such services is a high priority,
              implementors will ship H.264 regardless of what we decide
              here.

          

        

      

    

    

    =C2=A0=C2=A0=C2=A0 The same is true for VP8, so why mandate it as requi=
red?

Because we want to guarantee vid=
eo interoperability without forcing everyone to pay licensing feeds.=C2=A0<=
br>
=C2=A0



 If VP8
    is as good as everyone alleges (and I think it is) then surely
    vendors should be moving in this direction. But they are not.
    Forcing VP8 as MTI comes across as a political ploy to force their
    hand.

Regarding VP8, pretty m=
uch every SoC vendor is now shipping HW VP8 acceleration, so I think there =
is clear movement in this direction.




    

    =C2=A0=C2=A0=C2=A0 From an end-user point of view, the only thing I rea=
lly care
    about is getting WebRTC support from Microsoft and Apple. Because I
    view everything through that prism, my primary concern is how this
    decision affects them jumping on board.

=

I can't speak for Microsoft and Apple, but I don't think=
 they are sitting around waiting for us to make up our mind on this.




    

    Gili

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e011834d886b8c904e9992949--

From cb.list6@gmail.com  Fri Oct 25 16:37:43 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47921E80A3 for ; Fri, 25 Oct 2013 16:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPPUD-HRtWv0 for ; Fri, 25 Oct 2013 16:37:42 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE211E819C for ; Fri, 25 Oct 2013 16:37:41 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id t60so4552977wes.12 for ; Fri, 25 Oct 2013 16:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sPK2y/TGmVV1JkXguA5Y+gNr0ApzBQAKlAGQJhrqSeE=; b=w67Dlynnx8LX8RAKcRFufT5b2IyBNoi4Q1JW5XoCH9f0+YZHPVJzNeHVylC0tfFPQP ysL8KpAGl1TFCGBCGOSAemDpQ5juxYy6w1CUkcSgZyq9eG5x03yVap4gIodNNAe742gi QXfrYLeshZ+7GVQ7Lg0rx68g913QoUfcNKfmOxS8jWMUr5Fe/kqtiZJQN38KILrcCWOp 74/fh9vd79drBFqspXBVJvvOOGKKPhY7zygWhvo8dkLX9hsGcyN8M7dVHZtnxo4DMGFR hb8y5GLvBfAF2Lxfg6plwayAulV/Qwcu92R3AL+My2bZ0GN4QH9iMDzQkYBmsa6mA+SZ NG3g==
MIME-Version: 1.0
X-Received: by 10.180.37.227 with SMTP id b3mr578523wik.24.1382744261381; Fri, 25 Oct 2013 16:37:41 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Fri, 25 Oct 2013 16:37:41 -0700 (PDT)
Received: by 10.217.114.137 with HTTP; Fri, 25 Oct 2013 16:37:41 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org> 
Date: Fri, 25 Oct 2013 16:37:41 -0700
Message-ID: 
From: "cb.list6" 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=e89a8f646ff983d3af04e9993ca9
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 23:37:43 -0000

--e89a8f646ff983d3af04e9993ca9
Content-Type: text/plain; charset=ISO-8859-1

On Oct 25, 2013 4:32 PM, "Justin Uberti"  wrote:
>
>
>
>
> On Fri, Oct 25, 2013 at 2:47 PM, cowwoc  wrote:
>>
>> On 25/10/2013 3:50 PM, Justin Uberti wrote:
>>>
>>> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald,
"we give up and live with royalties forever". This will have a significant
impact on WebRTC innovation and adoption.
>>>
>>> The fact that there are some who disagree with the IPR status of VP8
does not invalidate this point.
>>
>>
>>     What prevents us from retiring H264, VP8 or any other codec in the
future? Surely we are allowed to retire codecs after 5-10 years? If not,
listing any codec as MTI (including VP8) places us at a some level of risk.
>>
>>
>>> Nobody is saying implementors can't support H.264. If interoperability
with such services is a high priority, implementors will ship H.264
regardless of what we decide here.
>>
>>
>>     The same is true for VP8, so why mandate it as required?
>
>
> Because we want to guarantee video interoperability without forcing
everyone to pay licensing feeds.
>

That's a fine goal. But there are camps in this wg that want license fees
paid.

So there will be no concensus.

>>
>> If VP8 is as good as everyone alleges (and I think it is) then surely
vendors should be moving in this direction. But they are not. Forcing VP8
as MTI comes across as a political ploy to force their hand.
>
>
> Regarding VP8, pretty much every SoC vendor is now shipping HW VP8
acceleration, so I think there is clear movement in this direction.
>>

Ack. Then the market may favor vp8.

>>
>>     From an end-user point of view, the only thing I really care about
is getting WebRTC support from Microsoft and Apple. Because I view
everything through that prism, my primary concern is how this decision
affects them jumping on board.
>
>
> I can't speak for Microsoft and Apple, but I don't think they are sitting
around waiting for us to make up our mind on this.
>>

Right.  So it sounds like you agree there is no need for mti since each
implementation will drive it's own strategy.

CB

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

--e89a8f646ff983d3af04e9993ca9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Oct 25, 2013 4:32 PM, "Justin Uberti" <juberti@google.com> wrote:

>

>

>

>

> On Fri, Oct 25, 2013 at 2:47 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>>

>> On 25/10/2013 3:50 PM, Justin Uberti wrote:

>>>

>>> No, this is a fundamental issue. If H.264 is the MTI, to quote=
 Harald, "we give up and live with royalties forever". This will =
have a significant impact on WebRTC innovation and adoption.

>>>

>>> The fact that there are some who disagree with the IPR status =
of VP8 does not invalidate this point.

>>

>>

>> =A0=A0=A0 What prevents us from retiring H264, VP8 or any other co=
dec in the future? Surely we are allowed to retire codecs after 5-10 years?=
 If not, listing any codec as MTI (including VP8) places us at a some level=
 of risk.


>>

>>

>>> Nobody is saying implementors can't support H.264. If inte=
roperability with such services is a high priority, implementors will ship =
H.264 regardless of what we decide here.

>>

>>

>> =A0=A0=A0 The same is true for VP8, so why mandate it as required?=


>

>

> Because we want to guarantee video interoperability without forcing ev=
eryone to pay licensing feeds.=A0

> =A0


That's a fine goal. But there are camps in this wg that =
want license fees paid.


So there will be no concensus. 


>>

>> If VP8 is as good as everyone alleges (and I think it is) then sur=
ely vendors should be moving in this direction. But they are not. Forcing V=
P8 as MTI comes across as a political ploy to force their hand.

>

>

> Regarding VP8, pretty much every SoC vendor is now shipping HW VP8 acc=
eleration, so I think there is clear movement in this direction.

>>


Ack. Then the market may favor vp8. 


>>

>> =A0=A0=A0 From an end-user point of view, the only thing I really =
care about is getting WebRTC support from Microsoft and Apple. Because I vi=
ew everything through that prism, my primary concern is how this decision a=
ffects them jumping on board.


>

>

> I can't speak for Microsoft and Apple, but I don't think they =
are sitting around waiting for us to make up our mind on this.

>>


Right.=A0 So it sounds like you agree there is no need for m=
ti since each implementation will drive it's own strategy. 


CB


>>

>> Gili

>>

>> _______________________________________________

>> rtcweb mailing list

>> rtcweb@ietf.org

>> https://w=
ww.ietf.org/mailman/listinfo/rtcweb

>>

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb

>




--e89a8f646ff983d3af04e9993ca9--

From xiphmont@gmail.com  Fri Oct 25 17:12:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B6F11E81EB for ; Fri, 25 Oct 2013 17:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.52
X-Spam-Level: 
X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=2.080,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPgZ7pWzPqUB for ; Fri, 25 Oct 2013 17:12:10 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id CDAE911E819C for ; Fri, 25 Oct 2013 17:12:09 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id u14so1258061lbd.22 for ; Fri, 25 Oct 2013 17:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0ZGUTjwGc46TH9EQNVUn4pYlF9QRVtCiDGCxJiSmqXM=; b=HRgnO+8/TZwz5TcxximD3tlQAqtc59lTIK4XclAUse1QbCW2U4XczYKhrHTPeE7Oha bJOrBdhJ4/amjBsIBDWp7S/aufeAn37SfO7MIHNE9/oHUPHBwx5KvNWRQtK+Wm6kAxu2 Fl1vriTe3yzQmyEPLWOdJrdt2xZW8bKkyWncKI21Cl8QBAlowhMOo9/UZObCx/ap8LwI 0J6W4kDrB9TtoshiOuh6BzndNpgPTmzEeBK9SB1PAhYBSmkVocxR0UZJmH3D7FiC/Kxh 7EheZtKHGMqcmKKmTMNOAFtTDWekO4bHMORF0/GQjsJErcF0fE0W1Bo4z7wHxYt+hE2F czEQ==
MIME-Version: 1.0
X-Received: by 10.152.29.38 with SMTP id g6mr7065382lah.25.1382746322844; Fri, 25 Oct 2013 17:12:02 -0700 (PDT)
Received: by 10.112.11.48 with HTTP; Fri, 25 Oct 2013 17:12:02 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org> 
Date: Fri, 25 Oct 2013 20:12:02 -0400
Message-ID: 
From: Monty Montgomery 
To: Justin Uberti 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 00:12:10 -0000

>>     The same is true for VP8, so why mandate it as required?
>
> Because we want to guarantee video interoperability without forcing everyone
> to pay licensing feeds.

Remember, it's not about the money.  It's about the market control,
and it's about asking permission (or having to beg forgiveness).

Not saying you forgot; I'm addressing the gallery.

Cheers,
Monty

From jlaurens@cisco.com  Fri Oct 25 17:58:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2562911E8212 for ; Fri, 25 Oct 2013 17:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YorDN1t99WD for ; Fri, 25 Oct 2013 17:57:55 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AB2AC11E81DB for ; Fri, 25 Oct 2013 17:57:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14319; q=dns/txt; s=iport; t=1382749073; x=1383958673; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eXA2SklnIN+0tC0fWAJ+WVaF+AMlmvbRDV+jXOFjpdk=; b=FoqOQ90hfACsfb+WW53EuvpMHfDA2dUZwjS1mufQBk8PmTym/pmp3qxd FMrpqHWvFKesxuBFQI6IRQVLCCu1qexjxTwVdfnY3gHvkYpGFW1G/SyaW pdXiVEURvYvP9G6dqRS/Ks5x/Q7EjWLpVDw+wTMyYzZOahqAulJ/KCZXK w=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlAFALASa1KtJXHA/2dsb2JhbABZgkNEgQy+SoEhFnSCJQEBAQMBDlcUEAIBCA4KCiQCMCUCBA4FCAaHcwa4bo8iMQeDH4ENA5AtgTCYNIMmgio
X-IronPort-AV: E=Sophos;i="4.93,574,1378857600";  d="p7s'?scan'208,217";a="276870151"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 26 Oct 2013 00:57:49 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9Q0vnfB016228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Oct 2013 00:57:49 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 19:57:48 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: Justin Uberti 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0PpTxT4El2I6hESqrgdop2l1XQ==
Date: Sat, 26 Oct 2013 00:57:47 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.253.75]
Content-Type: multipart/signed; boundary="Apple-Mail=_A5B37282-3EE1-4D78-996D-53A375A2A56F"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 00:58:07 -0000

--Apple-Mail=_A5B37282-3EE1-4D78-996D-53A375A2A56F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_64D605DE-C227-4727-86A9-6C47EBB2840C"


--Apple-Mail=_64D605DE-C227-4727-86A9-6C47EBB2840C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



On Oct 25, 2013, at 3:50 PM, Justin Uberti  wrote:

>=20
>=20
>=20
> On Fri, Oct 25, 2013 at 4:25 AM, Jeremy Laurenson (jlaurens) =
 wrote:
> First, my area of focus is system deployment for existing =
organizations, and my employer is clearly leaning H.264, however as an =
individual:
>=20
> I am of the opinion that from a "browser user perspective" this is =
pretty easy because two of the issues I see seem not to have a =
significant winner based on all this list activity:
> 	The average browser user does not care, except that bandwidth is =
materially affected - and there seems both are close in performance.
> 		(Profiles and efficiency could be argued forever at this =
rate)
> 	IPR does seem to be in the air - and without being a lawyer, I =
see Nokia folks on this list declaring there is an issue here.
> 		(But lawyers can argue forever)
>=20
> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, =
"we give up and live with royalties forever". This will have a =
significant impact on WebRTC innovation and adoption.

>=20
> The fact that there are some who disagree with the IPR status of VP8 =
does not invalidate this point.

The fact that Nokia has informed the group they believe there are IPR =
issues and they will not license means that regardless of whether we are =
all proponents of "royalty free", VP8 is likely not "the answer". This =
would mean that VP8 has no bearing whatsoever on the point Harald made. =
Until someone here digs into the Nokia filings, I remain firmly =
unconvinced.

>=20
> There seems to be a split.... however I believe the third factor here, =
while less technical in nature, will affect deployment and adoption.
>=20
> I believe the ability to leverage existing applications/infrastructure =
with a relatively small amount of work is a third leg in this stool and =
tips the balance materially for those looking to light up applications.
>=20
> Simply put, a user would ask why a new, less-interoperable standard is =
being introduced in absence of  functionality or bandwidth savings.
>=20
> This has material cost savings and media flow implications for a large =
set of the people who are going to use this technology. Clearly this was =
an important factor based on the SDP slant of the content of the spec.
> =09
> In my opinion we are not paying enough attention to an important line =
in the burman h.264 proposal: "In addition, using H.264 enables =
interoperability with many other services without video transcoding."


--Apple-Mail=_64D605DE-C227-4727-86A9-6C47EBB2840C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii





On Oct 25, 2013, at 3:50 PM, Justin Uberti <juberti@google.com> =
wrote:




On Fri, Oct 25, =
2013 at 4:25 AM, Jeremy Laurenson (jlaurens) <jlaurens@cisco.com> wrote:



First, my area of focus is system =
deployment for existing organizations, and my employer is clearly =
leaning H.264, however as an individual:




I am of the opinion that from a "browser user perspective" this =
is pretty easy because two of the issues I see seem not to have a =
significant winner based on all this list activity:
	The average browser user does not =
care, except that bandwidth is materially affected - and there seems =
both are close in performance.



		(Profiles =
and efficiency could be argued forever at this rate)
	IPR does seem to be in the air - =
and without being a lawyer, I see Nokia folks on this list declaring =
there is an issue here.



		(But =
lawyers can argue =
forever)

No, this is a =
fundamental issue. If H.264 is the MTI, to quote Harald, "we give up and =
live with royalties forever". This will have a significant impact on =
WebRTC innovation and =
adoption.

The fact =
that there are some who disagree with the IPR status of VP8 does not =
invalidate this =
point.

The =
fact that Nokia has informed the group they believe there are IPR issues =
and they will not license means that regardless of whether we are all =
proponents of "royalty free", VP8 is likely not "the answer". This would =
mean that VP8 has no bearing whatsoever on the point Harald made. Until =
someone here digs into the Nokia filings, I remain firmly =
unconvinced.







There seems to be a split.... however I believe the third factor here, =
while less technical in nature, will affect deployment and =
adoption.

I believe the ability to leverage =
existing applications/infrastructure with a relatively small amount of =
work is a third leg in this stool and tips the balance materially for =
those looking to light up applications.




Simply put, a user would ask why a new, =
less-interoperable standard is being introduced in absence of =
 functionality or bandwidth savings.

This =
has material cost savings and media flow implications for a large set of =
the people who are going to use this technology. Clearly this was an =
important factor based on the SDP slant of the content of the =
spec.



	=

In my opinion we are not paying enough attention =
to an important line in the burman h.264 proposal: "In addition, =
using H.264 enables interoperability with many other services without =
video transcoding."


=


=

--Apple-Mail=_64D605DE-C227-4727-86A9-6C47EBB2840C--

--Apple-Mail=_A5B37282-3EE1-4D78-996D-53A375A2A56F
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTAyNjAwNTYyNlowIwYJKoZIhvcNAQkEMRYEFNIXuQcauxPrdamZJ+W+zKrYm+RW
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAkJ+bypb9S1ROXtV0+7AETYD/xl4R
e8E7Sz+T5w4Uc8s/rRFkFuk1Y0dwdzN4dBtPjqlP+XYQs0Ts9RwsqvUXQ+ufPu3pbJvWjOtcFhEL
cL3k2gG+hg307xEx/Yj0fyTfsZ1FY+0ORHYI7AGn1nc1xHh3E8Tkor58DqGsnPt/LIhPLBhPatky
37e9jeT68uah35stJJtKvvQm2KF3edw9Yh7ZP9UNYKDXy8WHza+ul78gxKv0FUdm4MYDAMXI0qyo
vNLFmomd+JimvONqOIID9SKdbxBO/1GBlMhXG6HH3DhNUVGss4ZQlxFjqOb9oCCUuxoSiJSGb1Tk
ePMn1JBxxQAAAAAAAA==

--Apple-Mail=_A5B37282-3EE1-4D78-996D-53A375A2A56F--

From fluffy@cisco.com  Fri Oct 25 21:40:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D4811E8128 for ; Fri, 25 Oct 2013 21:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.572
X-Spam-Level: 
X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLnOa0diC2OW for ; Fri, 25 Oct 2013 21:40:40 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 025F011E81A4 for ; Fri, 25 Oct 2013 21:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1514; q=dns/txt; s=iport; t=1382762437; x=1383972037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gagGE54p/DLv086Hn8OKcDEb+YYsqBRoDwZbYVmxgDo=; b=f9jHQ9QGvxSSWHZjpcc5Q10ZeRNoNfer+lF+XrTWE7T93gEOAFfccsvu te3+gxHws2jTIB51zCQ5zzoQ/yCWoo3q8WLDymLIxEw4725504W7v/K23 CQt54OLxFeGZKP/nA47hqYUMNcTQ2Dh+3dXE3dOyBqNl52rN95vmv/YfW Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQFACtHa1KtJXG8/2dsb2JhbABZgweBDL5JgR4WdIIlAQEBAwF5BQsCAQgiJCERJQIEDgUIh20DCQaudQ2Ja4xjgSeBFgIxB4MfgQ0Dlh+OO4U3gyaBcTk
X-IronPort-AV: E=Sophos;i="4.93,575,1378857600"; d="scan'208";a="276920356"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 26 Oct 2013 04:40:36 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9Q4eaBQ026942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Oct 2013 04:40:36 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 23:40:36 -0500
From: "Cullen Jennings (fluffy)" 
To: "cb.list6" 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO0gWDJVyL5itEmEWrISFOF+nwVA==
Date: Sat, 26 Oct 2013 04:40:35 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 04:40:45 -0000

On Oct 25, 2013, at 10:35 AM, cb.list6  wrote:

> I am happy to present the salient points in Vancouver if asked to.

Hi,=20

I just want to explain why chairs are not likely to allocate agenda time fo=
r this at IETF88. I have not discussed this my co-chairs so this is certain=
ly not a chair decision but instead my guess of some items that would come =
up=85

1) we clearly asked for any proposals that wanted agenda time to be in in t=
he form of a draft by Oct 6. I think we would view this as another proposal=
.=20

2) the WG has previous agreed they don't want interoperability failures. Th=
is would not get us there. (Yes, I do realize the WG might fail at that goa=
l but the current plan is to try not to fail)

3) The agenda looks really full to me. ( The chairs will be thrilled if we =
turn out to be wrong on that and we can cover the stuff on the agenda and m=
ove on to other things )

But here's the really important thing - getting to consensus on an MTI woul=
d be better than no MTI. And we have never asked the question. Let me say t=
hat again - this WG has never had a consensus call on which codec should be=
 the MTI one. We agreed to do that and if it fails to reach consensus, then=
, as the WG has discussed before, we can move on to discussing what to do n=
ext.=20

I really don't want to start another long thread on why we are spending tim=
e on this topic at all but I did think your email deserved a response.=20

Cullen


From karl.stahl@intertex.se  Sat Oct 26 08:04:18 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DED11E814F for ; Sat, 26 Oct 2013 08:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Level: 
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_BACKHAIR_31=1, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtnBo8Wejxli for ; Sat, 26 Oct 2013 08:04:13 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 050D111E80F1 for ; Sat, 26 Oct 2013 08:04:10 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310261704081388; Sat, 26 Oct 2013 17:04:08 +0200
From: "Karl Stahl" 
To: "'Cullen Jennings \(fluffy\)'" , "'cb.list6'" , "'Harald Alvestrand'" , "'Justin Uberti'" 
References: <52681A96.2020904@alvestrand.no>	<526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>	 
In-Reply-To: 
Date: Sat, 26 Oct 2013 17:04:10 +0200
Message-ID: <038801ced25c$a076fda0$e164f8e0$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHO0gWDJVyL5itEmEWrISFOF+nwVJoGx3LQ
Content-Language: sv
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 15:04:18 -0000

Has a Video Codec Plug-in Slot been considered or discussed?
Wouldn't specifying such codec slots and making them mandatory for =
WebRTC
make (almost) everyone happy?=20

For service providers having invested in H.264 gear (e.g. IMS/RCS) or =
PBX/UC
vendor's video-solutions, they could offer their users the =
royalty-bearing
codec as a plug-in (they are used to supplying these codecs in current
clients), when they wish to use the WebRTC browser as a soft client for
their services.

That is their need, and most of them certainly understand that a
royalty-bearing codec cannot be made mandatory in free web browsers (How
could it? IETF cannot ban free web browsers and will not pay the
royalties...).=20

We (Ingate/Intertex SBCs) get requests for transcoding VP8<->H.264 in
network gateways. Others have already announced such. That would really =
be
ugly - a technically bad and resource consuming, quality degenerating
solution, that by definition also breaks the end-to-end privacy idea =
behind
WebRTC. Let's only have codecs in the endpoints - Make codec slots MTI! =
Few
really expect the H.264 can be MTI.

For the WebRTC browser itself, any mandating must be royalty free if it
should go into the web browser we know, mustn't it?

Having MTI codec slots will be great if we cannot reach consensus around =
VP8
(e.g. because of Nokia pouring some 67 patent numbers into an IPR
declaration, refusing to submit what their infringed innovation may be
https://datatracker.ietf.org/ipr/2035/). It is not hard to guess that =
Google
then will offer free VP8 plug-ins to any WebRTC browser when using their
search engine, especially Microsoft and Apple users'... Then we get the
video compatibility.

And the MPEG-group can be happy about a new efficient distribution =
channel
for their H.264 codecs, via service providers and PBX/UC vendors =
offering
such plug-ins to their users.

Maybe I should be sad, being deprived of the opportunity to build =
massive
H.264/VP8 transcoding gateways into the network...

/Karl



-----Ursprungligt meddelande-----
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Cullen
Jennings (fluffy)
Skickat: den 26 oktober 2013 06:41
Till: cb.list6
Kopia: rtcweb@ietf.org
=C4mne: Re: [rtcweb] VP8 vs H.264 - the core issue


On Oct 25, 2013, at 10:35 AM, cb.list6  wrote:

> I am happy to present the salient points in Vancouver if asked to.

Hi,=20

I just want to explain why chairs are not likely to allocate agenda time =
for
this at IETF88. I have not discussed this my co-chairs so this is =
certainly
not a chair decision but instead my guess of some items that would come =
up=85

1) we clearly asked for any proposals that wanted agenda time to be in =
in
the form of a draft by Oct 6. I think we would view this as another
proposal.=20

2) the WG has previous agreed they don't want interoperability failures.
This would not get us there. (Yes, I do realize the WG might fail at =
that
goal but the current plan is to try not to fail)

3) The agenda looks really full to me. ( The chairs will be thrilled if =
we
turn out to be wrong on that and we can cover the stuff on the agenda =
and
move on to other things )

But here's the really important thing - getting to consensus on an MTI =
would
be better than no MTI. And we have never asked the question. Let me say =
that
again - this WG has never had a consensus call on which codec should be =
the
MTI one. We agreed to do that and if it fails to reach consensus, then, =
as
the WG has discussed before, we can move on to discussing what to do =
next.=20

I really don't want to start another long thread on why we are spending =
time
on this topic at all but I did think your email deserved a response.=20

Cullen

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


From tim@phonefromhere.com  Sat Oct 26 08:11:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31CB21E805F for ; Sat, 26 Oct 2013 08:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20K9G-xiQNHn for ; Sat, 26 Oct 2013 08:11:30 -0700 (PDT)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id D475E11E80F1 for ; Sat, 26 Oct 2013 08:11:26 -0700 (PDT)
Received: (qmail 73739 invoked from network); 26 Oct 2013 15:11:25 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 1252
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 26 Oct 2013 15:11:25 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 019EC18A029D; Sat, 26 Oct 2013 16:11:25 +0100 (BST)
Received: from [192.168.157.136] (unknown [192.67.4.37]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 1ECE418A01EF;  Sat, 26 Oct 2013 16:11:24 +0100 (BST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: tim panton 
In-Reply-To: <038801ced25c$a076fda0$e164f8e0$@stahl@intertex.se>
Date: Sat, 26 Oct 2013 16:11:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <52681A96.2020904@alvestrand.no>	<526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>	  <038801ced25c$a076fda0$e164f8e0$@stahl@intertex.se>
To: Karl Stahl 
X-Mailer: Apple Mail (2.1816)
Cc: "Cullen Jennings \(fluffy\)" , rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 15:11:36 -0000

On 26 Oct 2013, at 16:04, Karl Stahl  wrote:

> Has a Video Codec Plug-in Slot been considered or discussed?
> Wouldn't specifying such codec slots and making them mandatory for =
WebRTC
> make (almost) everyone happy?=20

A _very_ long time ago (in terms of the rtcweb efforts) I floated the =
idea of having codecs as javascript objects,
which would then be manageable and replaceable in javascript, and could =
be implemented with technologies like NaCL. However at that time it was =
viewed as overly complex and taken no further.

Tim.


From lgeyser@gmail.com  Sat Oct 26 08:41:02 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A43511E8191 for ; Sat, 26 Oct 2013 08:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2Ch8RUDYBdD for ; Sat, 26 Oct 2013 08:41:01 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 720C111E81A0 for ; Sat, 26 Oct 2013 08:41:00 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id eo20so4043255lab.12 for ; Sat, 26 Oct 2013 08:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NKfwj7DseGR+BMr2v5VrpeX9CBJ3+/Tlf6oV7WmloFg=; b=UyCemuNsZT5/A+avTwyXUFciyfHFTBqS8kAmLrbepEQ4+Y1F8PAivjFdQDe8JkFTtz M799GcKr8DRxnTGbzh8sFK7X9pMQwMqQ301mrzkIlGPP8Jr83i2L57b9t6O3eN6Hv0vK jpOOnEsOEuhbqHme4qp9r854sjAmqdfW+oFjVLeLIlIg6QiueZq5WGXTcQsXwt1wTi9k dj/HjrDcMfz4vvmKmSV8B2rVbgNVJZNX1aQvfTybzcXp5O9yk6a216jiq+x8AGI4Qeud EoYLrazz8R7dWzTjHCeHoQ+m+dQAJgVk9hTY3/eMT5a7/I4LgFWz3/k2buQB501TEac7 nC9Q==
MIME-Version: 1.0
X-Received: by 10.112.132.70 with SMTP id os6mr235235lbb.38.1382802059161; Sat, 26 Oct 2013 08:40:59 -0700 (PDT)
Received: by 10.114.168.70 with HTTP; Sat, 26 Oct 2013 08:40:59 -0700 (PDT)
In-Reply-To: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>   
Date: Sat, 26 Oct 2013 17:40:59 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b3a836a87f5bc04e9a6b18b
Cc: "Cullen Jennings \(fluffy\)" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 15:41:02 -0000

--047d7b3a836a87f5bc04e9a6b18b
Content-Type: text/plain; charset=ISO-8859-1

I don't think it is such a great idea, because it now places the plug-in
development away from the browser developers. The reason why I say that is
bad: Who says the plug-in maintainers will be willing to release a plugin
for each new browser that comes out on each platform? And how do we install
those plug-ins on mobile phones where we don't have access to the
application's isolated storage?
It probably could work somehow, but a lot of thinking would be required. It
will be easier just to mandate a MTI codec.


On 26 October 2013 17:11, tim panton  wrote:

>
> On 26 Oct 2013, at 16:04, Karl Stahl  wrote:
>
> > Has a Video Codec Plug-in Slot been considered or discussed?
> > Wouldn't specifying such codec slots and making them mandatory for WebRTC
> > make (almost) everyone happy?
>
> A _very_ long time ago (in terms of the rtcweb efforts) I floated the idea
> of having codecs as javascript objects,
> which would then be manageable and replaceable in javascript, and could be
> implemented with technologies like NaCL. However at that time it was viewed
> as overly complex and taken no further.
>
> Tim.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7b3a836a87f5bc04e9a6b18b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I don't think it is such a great idea, because it=
 now places the plug-in development away from the browser developers. The r=
eason why I say that is bad: Who says the plug-in maintainers will be willi=
ng to release a plugin for each new browser that comes out on each platform=
? And how do we install those plug-ins on mobile phones where we don't =
have access to the application's isolated storage?

It probably could work somehow, but a lot of thinking would be required. It=
 will be easier just to mandate a MTI codec.


On 26 October 2013 17:11, ti=
m panton <tim@phonefromhere.com> wrote:




On 26 Oct 2013, at 16:04, Karl Stahl <karl.stahl@intertex.se> wrote:



> Has a Video Codec Plug-in Slot been considered or discussed?

> Wouldn't specifying such codec slots and making them mandatory for=
 WebRTC

> make (almost) everyone happy?




A _very_ long time ago (in terms of the rtcweb efforts) I floated the=
 idea of having codecs as javascript objects,

which would then be manageable and replaceable in javascript, and could be =
implemented with technologies like NaCL. However at that time it was viewed=
 as overly complex and taken no further.



Tim.




_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7b3a836a87f5bc04e9a6b18b--

From cowwoc@bbs.darktech.org  Sat Oct 26 11:49:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C746811E81DF for ; Sat, 26 Oct 2013 11:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.786
X-Spam-Level: 
X-Spam-Status: No, score=-5.786 tagged_above=-999 required=5 tests=[AWL=-2.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slIDde7dBrKI for ; Sat, 26 Oct 2013 11:48:57 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0344721F9E89 for ; Sat, 26 Oct 2013 11:48:56 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id ar20so8932462iec.28 for ; Sat, 26 Oct 2013 11:48:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=ektXDKdjPGxvnug1Y1Ng/jJG/06RH1ZBsTFcQ0Eu5PI=; b=Qsv7cZl293OcinxysNr3dgsYx0xo0+VS0HsDn7YbhNL1cCARjGHFZtl314O89puGCO W4IPGDsCRif9EvdfKjtUo7a/i37Kyo85pPWm8HcNGofghc/ejN53aYON6z1YPs8u1A2p 4zp8r+bgDbVYmawHju2QhJGvcAyxl4jBzCkntZBm/N+qDt0NqxsTIp9756uKI1Xa768o Bq4I4qEn1CZBJOE+MJWDP97OJxFIYT43U3r2zLCsjbiMzRpLvQLoRBD3sUpTCg6d08Fv hJ9dBj0PewjVzuLNHGm04WLIeHPHI26i05kmPchzOqeP8ijYtyjvPny3hX9HyUx7YyMd U+sw==
X-Gm-Message-State: ALoCoQlZm2tmLeHZAN+HVea4mYpCqH7zIjXd8IxGdwURDrU0Bt6/S5dRYWFu2NxfEDriM9Vi3vdT
X-Received: by 10.50.11.67 with SMTP id o3mr2975968igb.55.1382813336027; Sat, 26 Oct 2013 11:48:56 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i3sm9811758igh.0.2013.10.26.11.48.54 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Oct 2013 11:48:54 -0700 (PDT)
Message-ID: <526C0E94.9020009@bbs.darktech.org>
Date: Sat, 26 Oct 2013 14:48:52 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>			 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060702010906040004090906"
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 18:49:02 -0000

This is a multi-part message in MIME format.
--------------060702010906040004090906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


     I think you are a lot more likely to see H264/VP8 proponents 
offering free plugins then you are getting everyone to accept the same 
codec as MTI.

     Then again, Google refused to carry H264 in Chrome (I doubt 
licensing fees had anything to do with it) so maybe I'm wrong.

Gili

On 26/10/2013 11:40 AM, Leon Geyser wrote:
> I don't think it is such a great idea, because it now places the 
> plug-in development away from the browser developers. The reason why I 
> say that is bad: Who says the plug-in maintainers will be willing to 
> release a plugin for each new browser that comes out on each platform? 
> And how do we install those plug-ins on mobile phones where we don't 
> have access to the application's isolated storage?
> It probably could work somehow, but a lot of thinking would be 
> required. It will be easier just to mandate a MTI codec.
>
>
> On 26 October 2013 17:11, tim panton  > wrote:
>
>
>     On 26 Oct 2013, at 16:04, Karl Stahl      > wrote:
>
>     > Has a Video Codec Plug-in Slot been considered or discussed?
>     > Wouldn't specifying such codec slots and making them mandatory
>     for WebRTC
>     > make (almost) everyone happy?
>
>     A _very_ long time ago (in terms of the rtcweb efforts) I floated
>     the idea of having codecs as javascript objects,
>     which would then be manageable and replaceable in javascript, and
>     could be implemented with technologies like NaCL. However at that
>     time it was viewed as overly complex and taken no further.
>
>     Tim.
>
>     _______________________________________________
>     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


--------------060702010906040004090906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


          I think you are a lot more likely to see H264/VP8 proponents
      offering free plugins then you are getting everyone to accept the
      same codec as MTI.

      

          Then again, Google refused to carry H264 in Chrome (I doubt
      licensing fees had anything to do with it) so maybe I'm wrong.

      

      Gili

      

      On 26/10/2013 11:40 AM, Leon Geyser wrote:

    

    

      

        
I don't think it is such a great idea, because it now
          places the plug-in development away from the browser
          developers. The reason why I say that is bad: Who says the
          plug-in maintainers will be willing to release a plugin for
          each new browser that comes out on each platform? And how do
          we install those plug-ins on mobile phones where we don't have
          access to the application's isolated storage?

          It probably could work somehow, but a lot of thinking would be
          required. It will be easier just to mandate a MTI codec.

        

      

      


        

        
On 26 October 2013 17:11, tim panton <tim@phonefromhere.com>
          wrote:

          

            


              On 26 Oct 2013, at 16:04, Karl Stahl <karl.stahl@intertex.se>
              wrote:

              

              > Has a Video Codec Plug-in Slot been considered or
              discussed?

              > Wouldn't specifying such codec slots and making them
              mandatory for WebRTC

              > make (almost) everyone happy?

              

            

            A _very_ long time ago (in terms of the rtcweb efforts) I
            floated the idea of having codecs as javascript objects,

            which would then be manageable and replaceable in
            javascript, and could be implemented with technologies like
            NaCL. However at that time it was viewed as overly complex
            and taken no further.

            

                Tim.

              
            

              


                _______________________________________________

                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


    

    

  


--------------060702010906040004090906--

From cowwoc@bbs.darktech.org  Sat Oct 26 12:19:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456D011E81B3 for ; Sat, 26 Oct 2013 12:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.657
X-Spam-Level: 
X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=-2.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXQyxhwafZHb for ; Sat, 26 Oct 2013 12:19:45 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF9111E81E6 for ; Sat, 26 Oct 2013 12:19:45 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id aq17so8632699iec.38 for ; Sat, 26 Oct 2013 12:19:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=SzMNFDOhbVE6pbLVcSeUdBhv4VBoId3bme7Ya4Msng4=; b=XhEIeCVD1i26EoYnIyxrzF2cUYPXVywttguhVo6bolob7lFjmnj59QCVQnX9FT0gTH QmzUhHJxnYev+DZBk/ACzxhaId4RDHBvRn2mHuAV0sbQeHDLEJ4ClUqs+tsNuXskJkcD t/tGK97HJf/2P+7xRnpcCXjGRmMu1LY3bz02bUxGqIWyzD4NTzA7IbNjFpWYRRhDfQLE vNa+TAVcm0Cs3g5LheDnU8rT4Lz24Qz0+iEs6a+j28GIKey79DUtmP8AXSdrPuCjWcnQ FAwfPqOBpv0OZFSE9yHLb8UMUlezYSzueZtXATADRnI0h+kS+DBvjAgd7v3telXWoy1G LwMg==
X-Gm-Message-State: ALoCoQmCykV8FrXUCtB27xUrhTxmfmxMo1vCQUcJ4gbh42oFAxlIrQdA3+E0YNcgu+F6M8zvom8D
X-Received: by 10.50.82.41 with SMTP id f9mr3228242igy.26.1382815184461; Sat, 26 Oct 2013 12:19:44 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm9926439igx.8.2013.10.26.12.19.43 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Oct 2013 12:19:43 -0700 (PDT)
Message-ID: <526C15CD.5020601@bbs.darktech.org>
Date: Sat, 26 Oct 2013 15:19:41 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Ted Hardie 
References: <52681A96.2020904@alvestrand.no>	<526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>				<526AE703.8000409@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070204030301090901000700"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 19:19:51 -0000

This is a multi-part message in MIME format.
--------------070204030301090901000700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 25/10/2013 7:23 PM, Ted Hardie wrote:
> On Fri, Oct 25, 2013 at 2:47 PM, cowwoc  > wrote:
>
>
>         From an end-user point of view, the only thing I really care
>     about is getting WebRTC support from Microsoft and Apple. Because
>     I view everything through that prism, my primary concern is how
>     this decision affects them jumping on board.
>
>
> Do you mean "getting WebRTC support from Microsoft and Apple." or 
> "adding WebRTC support from Microsoft and Apple to that available from 
> Firefox and Chrome?"
>
> regards,
>
> Ted Hardie

Hi Ted,

     I'm not sure whether I understood your question correctly. Is this 
what you meant?

 1. Getting Microsoft and Apple to implement and bundle WebRTC as part
    of IE and Safari, versus
 2. Having outsiders (e.g. Firefox or Chrome) offer free plugins for IE
    and Safari without Microsoft and Apple's support

     If that's what you meant, then I'm asking for #1. As we've seen 
before (e.g. Chrome refusing to carry H264) just because a plugin is 
available does not mean that a vendor will agree to bundle it as part of 
the browser. As Monty pointed out, this has more to do with market 
control than licensing fees.

     I think we will all suffer unless Microsoft and Apple genuinely 
want to jump on board the WebRTC train. I disagree with the assessment 
that they are sitting around waiting for us to make up our mind. 
Microsoft put out some feelers in the form of CU-RTC-Web and, regardless 
of the merits of that proposal, was clobbered from all directions. A 
more appropriate response would have been to sit down with their 
representatives and say "Listen. We value your feedback. We won't be 
able to integrate all of it in version 1.0 but here is a compromise that 
integrates part of what you said... Can we use this as a basis for an 
ongoing relationship?" Instead, the representative from Microsoft is 
sounding very defensive and I can't say I blame them.

     An open process has to feel genuine, not just in words, but also in 
actions.

Gili

--------------070204030301090901000700
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 25/10/2013 7:23 PM, Ted Hardie
      wrote:

    

    

      
On Fri, Oct 25, 2013 at 2:47 PM, cowwoc <cowwoc@bbs.darktech.org>
        wrote:

        

          

            

              


                    From an end-user point of view, the only thing I
                really care about is getting WebRTC support from
                Microsoft and Apple. Because I view everything through
                that prism, my primary concern is how this decision
                affects them jumping on board.

              

            

            


            

            
Do you mean "getting WebRTC support from Microsoft and
              Apple." or "adding WebRTC support from Microsoft and 
              Apple to that available from Firefox and Chrome?" 

              

            

            
regards,

              

              Ted Hardie

            

          

        

      

    

    

    Hi Ted,

    

        I'm not sure whether I understood your question correctly. Is
    this what you meant?

    
    
      
  1. Getting Microsoft and Apple to implement and bundle WebRTC as
        part of IE and Safari, versus
    2. 
      
  2. Having outsiders (e.g. Firefox or Chrome) offer free plugins
        for IE and Safari without Microsoft and Apple's support
    3. 
    

    
    If that's what you meant, then I'm asking for #1. As we've
      seen before (e.g. Chrome refusing to carry H264) just because a
      plugin is available does not mean that a vendor will agree to
      bundle it as part of the browser. As Monty pointed out, this has
      more to do with market control than licensing fees.

    

    
    I think we will all suffer unless Microsoft and Apple
      genuinely want to jump on board the WebRTC train. I disagree with
      the assessment that they are sitting around waiting for us to make
      up our mind. Microsoft put out some feelers in the form of
      CU-RTC-Web and, regardless of the merits of that proposal, was
      clobbered from all directions. A more appropriate response would
      have been to sit down with their representatives and say "Listen.
      We value your feedback. We won't be able to integrate all of it in
      version 1.0 but here is a compromise that integrates part of what
      you said... Can we use this as a basis for an ongoing
      relationship?" Instead, the representative from Microsoft is
      sounding very defensive and I can't say I blame them.

    

    
    An open process has to feel genuine, not just in words, but
      also in actions.

    

    Gili

  


--------------070204030301090901000700--

From harald@alvestrand.no  Sat Oct 26 15:19:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714A621E8098 for ; Sat, 26 Oct 2013 15:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE9-hufkYcYP for ; Sat, 26 Oct 2013 15:19:28 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 475C711E8108 for ; Sat, 26 Oct 2013 15:19:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49E2239E2B4 for ; Sun, 27 Oct 2013 00:19:19 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXib3lNU9n7E for ; Sun, 27 Oct 2013 00:19:17 +0200 (CEST)
Received: from [10.1.218.3] (unknown [62.192.18.162]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2E03539E2A9 for ; Sun, 27 Oct 2013 00:19:17 +0200 (CEST)
Message-ID: <526C3FE4.2040301@alvestrand.no>
Date: Sun, 27 Oct 2013 00:19:16 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no>	<526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>				<526AE703.8000409@bbs.darktech.org>	 <526C15CD.5020601@bbs.darktech.org>
In-Reply-To: <526C15CD.5020601@bbs.darktech.org>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------070709010605070803020904"
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 22:19:34 -0000

This is a multi-part message in MIME format.
--------------070709010605070803020904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10/26/2013 09:19 PM, cowwoc wrote:
> On 25/10/2013 7:23 PM, Ted Hardie wrote:
>> On Fri, Oct 25, 2013 at 2:47 PM, cowwoc > > wrote:
>>
>>
>>         From an end-user point of view, the only thing I really care
>>     about is getting WebRTC support from Microsoft and Apple. Because
>>     I view everything through that prism, my primary concern is how
>>     this decision affects them jumping on board.
>>
>>
>> Do you mean "getting WebRTC support from Microsoft and Apple." or
>> "adding WebRTC support from Microsoft and  Apple to that available
>> from Firefox and Chrome?"
>>
>> regards,
>>
>> Ted Hardie
>
> Hi Ted,
>
>     I'm not sure whether I understood your question correctly. Is this
> what you meant?
>
>  1. Getting Microsoft and Apple to implement and bundle WebRTC as part
>     of IE and Safari, versus
>  2. Having outsiders (e.g. Firefox or Chrome) offer free plugins for
>     IE and Safari without Microsoft and Apple's support
>
>     If that's what you meant, then I'm asking for #1. As we've seen
> before (e.g. Chrome refusing to carry H264) just because a plugin is
> available does not mean that a vendor will agree to bundle it as part
> of the browser. As Monty pointed out, this has more to do with market
> control than licensing fees.
>
>     I think we will all suffer unless Microsoft and Apple genuinely
> want to jump on board the WebRTC train. I disagree with the assessment
> that they are sitting around waiting for us to make up our mind.
> Microsoft put out some feelers in the form of CU-RTC-Web and,
> regardless of the merits of that proposal, was clobbered from all
> directions. A more appropriate response would have been to sit down
> with their representatives and say "Listen. We value your feedback. We
> won't be able to integrate all of it in version 1.0 but here is a
> compromise that integrates part of what you said... Can we use this as
> a basis for an ongoing relationship?" Instead, the representative from
> Microsoft is sounding very defensive and I can't say I blame them.
>

I actually think Martin Thomson and Travis Leithead have been giving
great input and been positive contributors. Not to belittle the
contributions of others, but those two especially have made many
positive contributions.

>     An open process has to feel genuine, not just in words, but also
> in actions.
>
>

I think we may have some differing perspectives.

-- 
Surveillance is pervasive. Go Dark.


--------------070709010605070803020904
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/26/2013 09:19 PM, cowwoc wrote:

    

    

      
      
On 25/10/2013 7:23 PM, Ted Hardie
        wrote:

      

      

        
On Fri, Oct 25, 2013 at 2:47 PM, cowwoc <cowwoc@bbs.darktech.org>
          wrote:

          

            

              

                


                      From an end-user point of view, the only thing I
                  really care about is getting WebRTC support from
                  Microsoft and Apple. Because I view everything through
                  that prism, my primary concern is how this decision
                  affects them jumping on board.

                

              

              


              

              
Do you mean "getting WebRTC support from Microsoft
                and Apple." or "adding WebRTC support from Microsoft
                and  Apple to that available from Firefox and Chrome?" 

                

              

              
regards,

                

                Ted Hardie

              

            

          

        

      

      

      Hi Ted,

      

          I'm not sure whether I understood your question correctly. Is
      this what you meant?

      
    
        
  1. Getting Microsoft and Apple to implement and bundle WebRTC
          as part of IE and Safari, versus
    2. 
        
  2. Having outsiders (e.g. Firefox or Chrome) offer free plugins
          for IE and Safari without Microsoft and Apple's support
    3. 
      

      
    If that's what you meant, then I'm asking for #1. As we've
        seen before (e.g. Chrome refusing to carry H264) just because a
        plugin is available does not mean that a vendor will agree to
        bundle it as part of the browser. As Monty pointed out, this has
        more to do with market control than licensing fees.

      

      
    I think we will all suffer unless Microsoft and Apple
        genuinely want to jump on board the WebRTC train. I disagree
        with the assessment that they are sitting around waiting for us
        to make up our mind. Microsoft put out some feelers in the form
        of CU-RTC-Web and, regardless of the merits of that proposal,
        was clobbered from all directions. A more appropriate response
        would have been to sit down with their representatives and say
        "Listen. We value your feedback. We won't be able to integrate
        all of it in version 1.0 but here is a compromise that
        integrates part of what you said... Can we use this as a basis
        for an ongoing relationship?" Instead, the representative from
        Microsoft is sounding very defensive and I can't say I blame
        them.

      

    

    

    I actually think Martin Thomson and Travis Leithead have been giving
    great input and been positive contributors. Not to belittle the
    contributions of others, but those two especially have made many
    positive contributions.

    

    

      
 

      
    An open process has to feel genuine, not just in words, but
        also in actions.

      

      

    

    

    I think we may have some differing perspectives.

    

    
-- 
Surveillance is pervasive. Go Dark.


  


--------------070709010605070803020904--

From pkyzivat@alum.mit.edu  Sat Oct 26 15:30:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6911E81EC for ; Sat, 26 Oct 2013 15:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.048
X-Spam-Level: 
X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-0.115,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G47BoGIfj7O1 for ; Sat, 26 Oct 2013 15:30:48 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 978CC11E81D1 for ; Sat, 26 Oct 2013 15:30:48 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id hyW71m0011uE5Es5EyWooy; Sat, 26 Oct 2013 22:30:48 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id hyWn1m00X3ZTu2S3cyWn2l; Sat, 26 Oct 2013 22:30:48 +0000
Message-ID: <526C4297.2000006@alum.mit.edu>
Date: Sat, 26 Oct 2013 18:30:47 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com>	<03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>			<03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>	<120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de>	<03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>	<5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com>
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=q20121106; t=1382826648; bh=2wdlussntnQthENuwSj4doPdsw2CHhIlTzvDgin7ZFw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hhHdcXmNK1McoNByLF/mRebOeXjH4vYWNUijPQM5dRBELFy4Z+TRIrixfFEpE1IwJ 5CZazr0L9j7GpUkin5UpCY0ZAcdl4ruvCDr2240gM0+lIjcebyoi2m8NVzs9czYegQ ANZC/y7OAsm+JNxyRCO2fOlQ8Y2/KSj1u5l3I0YroFbaQiMdgKxAX9vu1J/0EK6WHD wb5syZiqevNb0FebdyzyZhuLSyMHrb/JuIQsSR3j9sken6zRtCKthibRQw0K1Je15A JL9smMA1RNTNXtpOa1Vv0fqvT5JLFAlFImcKAVs/XfFDhKUsyqLaSHkEbR4FUDN3wZ FDzGHvtt8Gv7Q==
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 22:30:53 -0000

Richard,

On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
> Hi Harald,
> You said: " I can't see a way to mix the two paradigms that guarantees this never happening."  The two paradigms being browser selection vs. application selection of data channel stream ids.
>
> I agree with this statement if the browser selection algorithm is based on DTLS role since the application needs to be able to select ids before the DTLS role is known.  It is also clear that this is not an easy problem to solve since the peers need to interact in some way before their relative roles are clearly established.
>
> I am ok with documenting this limitation clearly (i.e., that the application should use either browser selection of stream ids or application selection of stream ids but not both together) but have a suggested alternative solution for consideration.  I would prefer a solution where the two paradigms can be "mixed", if one can be agreed.
>
> My proposal has three elements, which together can guarantee that there are no stream id allocation conflicts between peers:
> 	1. The browser and application select stream ids based on initial SDP offerer/answerer role rather than DTLS role (e.g., initial offerer uses even ids, initial answerer uses odd ids).  With this rule, the offering application knows its role immediately without waiting for the DTLS or SDP handshake to occur.

A similar issue has come up in the discussion of partial offers/answers. 
(Regarding how to assign a=mid values.) And a similar solution was proposed.

It was then rejected on the basis that sometimes both "ends" think they 
are offerers or answerers. This comes about as a result of 
signaling-only B2BUAs that play games with O/A on two legs.

	Thanks,
	Paul

> 	2. For early data channel creation, the browser assumes that it will take the offerer role in selecting stream ids until the application determines its role through the API (using JSEP API calls).
> 	3. The answerer application refrains from requesting browser selection of stream ids when creating data channels until after the browser knows it will take the answerer role (based on the sequence of JSEP API calls).  This is not a significant limitation since the answerer will typically not even create its end of the peer connection until after it receives the offer.
>
> This approach also has the advantage of being consistent with the data channel API spec as it is currently written, which requires stream id assignment at the time of data channel creation.
>
> Another (admittedly secondary) advantage of choosing a new selection algorithm that makes the two paradigms compatible would be that external negotiation options could use the same algorithm and also be fully compatible with the in-band options.
>
> BR, Richard
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Harald Alvestrand
>> Sent: Thursday, October 24, 2013 11:30 PM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
>> 01.txt
>>
>> On 10/24/2013 10:38 PM, Ejzak, Richard P (Richard) wrote:
>>> Hi Michael,
>>>
>>>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>>>> Sent: Thursday, October 24, 2013 2:21 PM On Oct 24, 2013, at 8:36
>> PM,
>>>> "Ejzak, Richard P (Richard)"
>>>>  wrote:
>>>>
>>>>> Justin, Michael,
>>>>> Thanks for the clarifications.  One more question.  What happens if
>>>> the application tries to select a stream id before the DTLS role is
>>>> known and it ends up selecting an invalid one?
>>>> I'm not completely familiar with the JS API, but if you want to
>>>> select a stream, aren't you managing the stream completely on your
>>>> own. I think the DTLS role stuff is only relevant if the streams are
>>>> managed by the browser.
>>> If this is the intent then that clarification would be very useful.
>> Reading the API text again, it is clear that the browser only manages
>> stream ids that it selects.  Does this mean that the browser stream id
>> selection option is not compatible with the application stream id
>> selection option?  Putting it more precisely, should we require that
>> the application not be allowed to select stream ids prior to
>> determining DTLS role if it expects that either side might use the
>> browser stream id selection option?  It would be easier if the even/odd
>> rule could be determined earlier than DTLS role establishment so that
>> the application could use the same even/odd assignment rule for early
>> data channel creation.
>>
>> My reading has been that once you start selecting IDs, you're
>> responsible for making sure those don't collide with platform-generated
>> ones, or deal with the result if they do.
>>
>> The result of
>>
>> A: pc.createDataChannel(label="foo") -> (channel with ID = 5, open
>> message sent)
>> B: pc.createDataChannel(label="bar", id=5) 
>>
>> should be well defined. I don't much care what the result is, as long
>> as it's well defined; closing the channel and calling the onerror()
>> handler with DOMError(error="UsageError", message="Duelling paradigms")
>> is fine with me.
>>
>> I can't see a way to mix the two paradigms that guarantees this never
>> happening.
>>
>>>
>>>>> Michael,
>>>>> While it's true that the data channel control protocol cannot open
>>>> the channel with the peer before the DTLS role is known, the API
>>>> allows the application to create the data channel before the DTLS
>>>> role is known, in which case the sending of the Open message must
>>>> wait until the SCTP association is established.  I want to know what
>>>> the application is supposed to do it if needs to create data
>> channels
>>>> with preselected stream ids before the DTLS role is known.  This
>>>> seems like something that the spec should make clear rather than
>>>> leaving it to implementation.
>>>> Can you assign the stream ID in the API? Could you point me to the
>>>> text?
>>> http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute
>> in the RTCDataChannelInit dictionary that must be the equivalent of the
>> "stream identifier".  No other interpretation makes sense to me but
>> please correct me if I am wrong.  Note in particular the following text
>> within the description of the createDataChannel procedure (my
>> parenthetical): "If the value of the id attribute is null, initialize
>> it to a value generated by the user agent (browser), according to the
>> WebRTC DataChannel Protocol specification, and skip to the next step.
>> Otherwise, if the value of the id attribute is taken by an existing
>> RTCDataChannel, throw a TBD exception and abort these steps."  So "id"
>> must refer to "stream identifier" since there is no other id in your
>> draft that it could refer to.
>>>
>>> If I'm right, then it would be good if it were made clear that id
>> refers to "stream identifier", but that is a w3c issue.  Quoting from
>> 5.2.1 (my parentheticals for clarity): "The id was either assigned by
>> the user agent (browser) at channel creation time (not channel opening
>> time) or selected by the script (application). The attribute MUST
>> return the value to which it was set when the RTCDataChannel was
>> created (not opened)."
>>>
>>> I used the wrong terminology in my earlier mail when I referred to
>> "open" of the data channel when I meant "creation".  Since the data
>> channel can be "created" before DTLS role is known and before the data
>> channel can be opened, the quoted text above would seem to indicate
>> that the application can never determine the stream id actually
>> assigned to the data channel if id can't be determined at time of
>> creation.  Justin implied that the chrome behavior does not conform to
>> this description.  Comment, Justin?
>>>
>>> It still seems to me that a change in the rule describing even/odd
>> stream id assignment would be a good idea.
>>>
>>> BR, Richard
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From cowwoc@bbs.darktech.org  Sat Oct 26 15:48:01 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D278921E80A7 for ; Sat, 26 Oct 2013 15:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.543
X-Spam-Level: 
X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=-1.945, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBrhLTEEuSH2 for ; Sat, 26 Oct 2013 15:47:47 -0700 (PDT)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8312821F9E7C for ; Sat, 26 Oct 2013 15:47:42 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id as1so8953146iec.27 for ; Sat, 26 Oct 2013 15:47:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=jhpNbJULZBK0MVjsHoiQHsDAl17s3HXbT3q/hWd1OvQ=; b=Q6QpXhZA7SkM9mli2r6DOIjoU0+T3c2wDQEcH9XhGgxMA39WSn4YOtKPdN2GOU4alu kI23stCN5EsPrsXkQmCSJDTvlmN0vnD7OWTuajcP/1fsOTYHS/1FPHF7HQ7n64ZAv9ga YT/mbgsKva5+OgdJiLRKaXgkuMrQpuhiPwU+nkotkmu0XW3ztLfj5xN98n+ptIDKNek9 VdzPzo4m+qFfeklHd9pmtvAkvvOS8QUfEufdC7hzwEysiPfiU1gdwiT8OWA48kZgRQ+x ITGc8eSblRdK6+pWPz+MeHFs64zaK4oGrxvzkw7+V1bb6XWb5EHC/M621JG/zth3MEKc ucmQ==
X-Gm-Message-State: ALoCoQnquu5oIWtU3tfWwcPA7UfZsKheTWT40HXKeb6qMFzXPPvsfe3sOJB1+h+6f1B3X3s2Gpa1
X-Received: by 10.42.142.129 with SMTP id s1mr9353984icu.30.1382827659643; Sat, 26 Oct 2013 15:47:39 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i3sm10893807igh.0.2013.10.26.15.47.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Oct 2013 15:47:38 -0700 (PDT)
Message-ID: <526C4686.2080702@bbs.darktech.org>
Date: Sat, 26 Oct 2013 18:47:34 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no>	<526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>			<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>				<526AE703.8000409@bbs.darktech.org>		<526C15CD.5020601@bbs.darktech.org> <526C3FE4.2040301@alvestrand.no>
In-Reply-To: <526C3FE4.2040301@alvestrand.no>
Content-Type: multipart/alternative; boundary="------------020604090800030404010902"
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Oct 2013 22:48:01 -0000

This is a multi-part message in MIME format.
--------------020604090800030404010902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 26/10/2013 6:19 PM, Harald Alvestrand wrote:
> I actually think Martin Thomson and Travis Leithead have been giving 
> great input and been positive contributors. Not to belittle the 
> contributions of others, but those two especially have made many 
> positive contributions.
>
>>     An open process has to feel genuine, not just in words, but also 
>> in actions.
>>
>
> I think we may have some differing perspectives.

I guess what I'm saying is... if all is well, then what's going on with 
Microsoft and Apple? What's their official position regarding MTI? Will 
it impact their intent to bundle WebRTC in their browsers? If we truly 
have an open process and representatives from Microsoft and Apple 
sitting on the WG then I would expect to get official answers to these 
questions.

I've seen multiple representatives from Microsoft, but not a single 
person from Apple. Is anyone representing them in an official capacity?

Gili

--------------020604090800030404010902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 26/10/2013 6:19 PM, Harald
      Alvestrand wrote:

    

    

      
      I actually think Martin Thomson and Travis Leithead have been
      giving great input and been positive contributors. Not to belittle
      the contributions of others, but those two especially have made
      many positive contributions.

      

      

        
 

        
    An open process has to feel genuine, not just in words,
          but also in actions.

        

      

      

      I think we may have some differing perspectives.

    

    

    I guess what I'm saying is... if all is well, then what's going on
    with Microsoft and Apple? What's their official position regarding
    MTI? Will it impact their intent to bundle WebRTC in their browsers?
    If we truly have an open process and representatives from Microsoft
    and Apple sitting on the WG then I would expect to get official
    answers to these questions.

    

    I've seen multiple representatives from Microsoft, but not a single
    person from Apple. Is anyone representing them in an official
    capacity?

    

    Gili

  


--------------020604090800030404010902--

From randell-ietf@jesup.org  Sun Oct 27 02:22:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25D011E8125 for ; Sun, 27 Oct 2013 02:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-a95iJ8bgmM for ; Sun, 27 Oct 2013 02:22:51 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id F392421F9EF2 for ; Sun, 27 Oct 2013 02:22:47 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:2107 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VaMYY-000GOT-VC for rtcweb@ietf.org; Sun, 27 Oct 2013 04:22:47 -0500
Message-ID: <526CDB44.7000002@jesup.org>
Date: Sun, 27 Oct 2013 05:22:12 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191313.32469.99466.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C7EB@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86C7EB@US70UWXCHMBA04.zam.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-06.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 09:22:56 -0000

On 10/24/2013 12:41 PM, Ejzak, Richard P (Richard) wrote:
> I have some comments/questions about draft-ietf-rtcweb-data-channel-06.

Thanks!

> The last paragraph of section 6.4 is a little ambiguous, but also seems to contradict the decision that the same stream identifier will be used in both directions.  I assume that "number" and "stream value" in the paragraph both refer to SCTP "stream identifier"?  Shouldn't the paragraph say that while SCTP does not constrain allocation of the stream identifier in the two directions, a bidirectional data channel is defined as a pair of streams in opposite directions that use the same stream identifier?

Likely we should remove the Note in 6.4 that allows bidirectional 
streams to have different SCTP Stream numbers in each direction - I'm 
pretty sure this is left over from before the switch from 3-way 
handshake to 1-way declarative.

> The discussion in the 3rd paragraph of section 6.5, which describes some constraints on external negotiation, is a bit confusing to me.  I assume that "picks a Stream" is intended to mean "picks a Stream Identifier"?  For clarity I would prefer the latter, unless something else is intended.

I'll look; that seems reasonable.

> In the same paragraph, DTLS role is used as a possible way of determining whether one side can select odd or even stream identifiers, but this is problematic.  It must be possible for the side requesting (offering) the peer connection to open a data channel before DTLS role can be determined.  How can the application know whether to request an odd or even stream identifier for a data channel if it doesn't know the DTLS role yet?  May I suggest that a better example would be to say that selection is based on which side sends the initial SDP offer creating the peer connection (e.g., the initial offerer picks even stream identifiers and the initial answerer picks odd stream identifiers).

That breaks down when a server decides to connect two offers together 
(i.e. an offer could be transformed into an answer to an existing offer 
(and the same for the other direction) without either side knowing).  
This is done in SIP servers all the time (surprised me the first time I 
ran into it), along with offers that originate "in the middle" from the 
server or SBC.   Kinda evil, but stuff like this will be done I believe, 
given the server is also normally supplying the JS application and so it 
would expect this behavior.

The stream ID used is selected once the DTLS role is known.  In W3 
terms, the channel.id isn't a valid value immediately when calling 
createDataChannel before SetLocal/RemoteDescription.  Before that 
happens (at the W3 api level), we currently return an invalid ID (65535 
- max per the data channel spec is 65534).

> In the same paragraph, the last sentence points out that the other side must inform the protocol to expect data using the stream identifier selected by the first side, but must also select parameters for use with data that it sends.  I assume that this text requires that the same stream identifier be used for the streams in both directions, but this is not stated clearly.  If not, do you assume that external negotiation establishes unidirectional channels only?  If the latter, are the sending parameters relevant to the other side?  Is something else intended?

They must inform the other side in some manner so that the other side 
knows why data is appearing on a specific stream id.  The W3 side is 
based on the assumption that DataChannels (W3 level) are bidirectional 
and have a consistent 'id' value on both sides.  (see comments about 6.4 
above)

The intention was to define an external negotiation as the equivalent to 
internal - i.e. reliability settings SHOULD be provided, and SHOULD 
match on both sides.  This was specifically not a MUST, and the decision 
to match or not is in the application's hands.

> Section 6.6 says that the "higher level" can override the default reliability options with per-message options.  I don't think this is allowed by the API, or did I miss something?  While I know that SCTP could potentially allow this with API support, it seems confusing to describe capabilities not available from the API without some clarifying text.

The current WebRTC W3 API does not allow for this.  However, this draft 
is designed to work if that were to change, as there's no technical 
reason the IETF-level spec has to require that.  (This is similar to the 
use of SHOULD on matching the reliability options in external 
negotiation.)  For example, perhaps CLUE would use data-channels, and 
would want to use an optional per-message reliability to override the 
default.  This would require that both ends know and expect this can happen.

-- 
Randell Jesup -- rjesup a t mozilla d o t com


From randell-ietf@jesup.org  Sun Oct 27 02:35:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7411E810F for ; Sun, 27 Oct 2013 02:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrJxYE6l+gRN for ; Sun, 27 Oct 2013 02:35:41 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E521E80B4 for ; Sun, 27 Oct 2013 02:35:36 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:2166 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VaMkv-000EWk-Sf for rtcweb@ietf.org; Sun, 27 Oct 2013 04:35:34 -0500
Message-ID: <526CDE43.9090209@jesup.org>
Date: Sun, 27 Oct 2013 05:34:59 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 09:35:54 -0000

On 10/24/2013 12:59 PM, Ejzak, Richard P (Richard) wrote:
> I have a question about draft-ietf-rtcweb-data-protocol-01.  The browser uses DTLS role to determine which side uses even or odd stream identifiers.  What does the application on the side sending the initial SDP offer that establishes the peer connection do if it wants to create data channels before the DTLS role can be determined?  How does the browser know if the application tries to select a disallowed stream id?  If the application asks the browser to select the stream identifier before DTLS role can be determined, what does the browser do?

The W3-level channels are assigned an ID once the DTLS roles are 
determined; until then the id is undefined (in our implementation they 
return 65535, an invalid id value - the exact action here is not yet 
speced in the W3C).

You call createDataChannel(...) one or more times.  The channel.id's 
return 65535; when onopen fires the id has been set (and perhaps before, 
there may be a small window between DTLS role setting/id-selection and 
onopen).  In fact this is the norm, as we won't offer an m=application 
line for data channels unless the first createDataChannel was called 
before createOffer (and once we support negotiationneeded, you'll be 
able to call it later, but that just means negotiationneeded will fire 
and make you call createOffer()). Once you're connected, you can call 
createDataChannel all you want with no further negotiationneeded firings.

On external negotiation, it's the application's responsibility to select 
values that won't collide by mistake with either other 
externally-negotiated values or automatically-generated ones.  There are 
no 'disallowed' values (in the range 0-65534).  You can specify an 
externally-negotiated id value before DTLS roles are set; again, it's up 
to you not to screw it up.  Generally applications won't mix 
external-negotiated channels with data-protocol negotiated ones, but 
that is possible so long as the application is moderately careful.

-- 
Randell Jesup -- rjesup a t mozilla d o t com


From randell-ietf@jesup.org  Sun Oct 27 02:46:15 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CC911E8163 for ; Sun, 27 Oct 2013 02:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTKlZIRzPyqk for ; Sun, 27 Oct 2013 02:46:09 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C3EBF11E8160 for ; Sun, 27 Oct 2013 02:46:08 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:2216 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VaMvA-000GuJ-98 for rtcweb@ietf.org; Sun, 27 Oct 2013 04:46:08 -0500
Message-ID: <526CE0BE.90606@jesup.org>
Date: Sun, 27 Oct 2013 05:45:34 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com>	<03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>			<03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>	<120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de>	<03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>	<5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu>
In-Reply-To: <526C4297.2000006@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 09:46:15 -0000

On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
> Richard,
>
> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
>> Hi Harald,
>> You said: " I can't see a way to mix the two paradigms that 
>> guarantees this never happening."  The two paradigms being browser 
>> selection vs. application selection of data channel stream ids.

You can.  You just have to be careful.  For example, your application 
could define that pre-negotiated channels will use 100-110, and then 
specify those to both ends before association/offer/answer.  Later it 
could use data-protocol to add dynamic channels (using even-odd).  Since 
we've told both ends about 100-110, there's no problem here.  Even/odd 
is ONLY to avoid glare when both sides decide to open a channel "at the 
same time".  If you add a pre-negotiated channel after initial 
establishment, it's up to you to avoid colliding with any existing 
channels and to avoid colliding with any in-process-of-creation dynamic 
(data-protocol) channels.  There are a number of ways to avoid such a 
collision safely (never use dynamic channels; use the DTLS role or an 
existing dynamic channel id to determine even/odd, etc).

>> My proposal has three elements, which together can guarantee that 
>> there are no stream id allocation conflicts between peers:
>>     1. The browser and application select stream ids based on initial 
>> SDP offerer/answerer role rather than DTLS role (e.g., initial 
>> offerer uses even ids, initial answerer uses odd ids). With this 
>> rule, the offering application knows its role immediately without 
>> waiting for the DTLS or SDP handshake to occur.
>
> A similar issue has come up in the discussion of partial 
> offers/answers. (Regarding how to assign a=mid values.) And a similar 
> solution was proposed.
>
> It was then rejected on the basis that sometimes both "ends" think 
> they are offerers or answerers. This comes about as a result of 
> signaling-only B2BUAs that play games with O/A on two legs.

Exactly why we went with DTLS roles.

-- 
Randell Jesup -- rjesup a t mozilla d o t com


From vsingh.ietf@gmail.com  Sun Oct 27 03:57:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66511E8162; Sun, 27 Oct 2013 03:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level: 
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.179,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDG+d24J07X4; Sun, 27 Oct 2013 03:57:34 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAB11E8144; Sun, 27 Oct 2013 03:57:34 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id u16so9158984iet.4 for ; Sun, 27 Oct 2013 03:57:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=mymBHQPqvBP7FJmEqZ+rUEcI3Mc1FnVw+ZxkAaruUBg=; b=esd2rUZmHNV84VUnnZXB0b00Yh8JcvzG5PmnUYzm0fo3/Xxz/0l3HVMhuXmN/W54g7 MsRyxGz1HTYfOpEWluRJL8b3+80N6qCmeqpgI1VM2PDvbJYeSxA0VELGvfl5i07Ck77y q2o3F4xD5enTbVkJcApDXV/PEK5poAuHAXAQ87KaIrlC40RRF7N+8qL5yEAWYJZKnDCd WLipNbDQ2Vgyh4AiKiaPv9Y3RgoXWtk9QRbTXXfofUGsRVnHrIiF6+Fg21W1x2fob2Ma DiMJBXqeg48qQ3uDe69MAhWXlHVGMpK0y+9utUUHKFDDVDBE1QEnjJTUpDfoNbzwZnDS kTjA==
X-Received: by 10.50.77.72 with SMTP id q8mr4891071igw.14.1382871453857; Sun, 27 Oct 2013 03:57:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.102.8 with HTTP; Sun, 27 Oct 2013 03:57:13 -0700 (PDT)
From: Varun Singh 
Date: Sun, 27 Oct 2013 12:57:13 +0200
Message-ID: 
To: "rtcweb@ietf.org" , "avt@ietf.org" , rmcat WG 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Colin Perkins 
Subject: [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 10:57:35 -0000

Hi all,

In RMCAT WG there has been discussion surrounding the use
of a media traffic generator and to facilitate discussion,
RMCAT is hosting a side meeting on Sunday, 03 November
at 1300-1500. I suppose the room details will be announced
shortly.

Below is a list of questions that will help design or choose
an appropriate traffic generator for Interactive multimedia traffic.
The list is an initial set and mainly to foster discussion both
on the mailing list and at the meeting.

Mirja and Lars are not available that day, hence on their behalf,
the meeting is hosted by Colin and I .

Cheers,
Varun
---

Traffic generator: to model the intrinsic variability of video:

- what target bit rates can be achieved? (max?, min?)
- how much variability in media bit rate for a given target bit rate
- how to model motion? capturing high motion leads to bursty video
  (higher than target bit rate), but by how much? can this even be done?

Traffic generator: on responsiveness to a new target bitrate:

- how quickly can the codec generate a lower bit rate?
- immediately? does this depend on the new or requested bit rate?
- what is immediately? is it next frame or a few frames later, until then
  does it generates at the current rate?
- if not immediately, what bitrates (and duration) will it generate before
  meeting the target bitrate.


- how quickly can the codec generate a higher bit rate?
- immediately in the next frame? does this also depend on the new
   or requested bit rate?
- not immediately but in steps of intermediate bitrates, i.e., intermediate
  bitrate for a short duration then an increase in step, repeating until
  reaching the target bit rate.

- If the target bit rate is achieved in steps, can they be announced to the
  congestion controller, i.e., the congestion controller knows the ramp up
  curve to meet the target bit rate.

- If the media bit rate has not yet reached the requested target bit rate and
  the congestion control requests a new target bit rate, how does the codec
  respond?

Application design related:
- should the congestion control be able to change the frame rate (video) or
  packetization time (audio) or is this something that the application controls.
- should the congestion control be able to change video resolution?
- should error-repair: NACKs, FEC be considered part of congestion control or
  outside it, i.e., it is something that the application does and not
  congestion control
- If FEC is controlled by the congestion control, how quickly can the sending
  rate be adapted by reducing/adding redundancy (FEC)? is something link this
  done? Does this makes sense at all?
- Apart from loss and RTT, what other congestion cues are currently used by
  congestion control algorithms? e.g., Decoding rate/goodput, application
  decode error rate, ECN, PCN, etc.
- If the codec is data limited, i.e., producing a sending rate smaller than the
  one calculated by the congestion control, can the congestion control probe
  the bandwidth by sending additional data packets in a certain pattern (e.g.,
  PathChirp)? would somehting link this help?
- application input on prioritization: audio vs video (vs data)





-- 
http://www.netlab.tkk.fi/~varun/

From fluffy@cisco.com  Sun Oct 27 11:27:20 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2246B11E81A6 for ; Sun, 27 Oct 2013 11:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.574
X-Spam-Level: 
X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzpt1yji-ppI for ; Sun, 27 Oct 2013 11:27:07 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 66C1011E81A1 for ; Sun, 27 Oct 2013 11:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1550; q=dns/txt; s=iport; t=1382898424; x=1384108024; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iOWBVfLwjINQ5kFw276oTfQ8WNb+yECQebcbfv8E74U=; b=cNdml09KZ0aJu2wzYgg4pl7qu2xJO5yvQfFm/YN2hPxy3RpwV+aIJyVx x34rPV9LqeJLGEFkKRrX7uVYU0jZE/8bDfFks00in9QeXhxHmSXmeaFkS 8AxNHPJ/UPRLL7UuqTeNpUbhrJfopDTKYTmJi33ldZ/RsvG59ZFeONR/6 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAIVabVKtJXHA/2dsb2JhbABZgweBDL5fgRwWdIIlAQEBAwF5BQsCAQgYCiQyJQIEDgUIh3kGuA6PIgIxB4MfgQ0DiQehCoMmgio
X-IronPort-AV: E=Sophos;i="4.93,581,1378857600"; d="scan'208";a="277247697"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 27 Oct 2013 18:26:45 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9RIQj0b022859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Oct 2013 18:26:45 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sun, 27 Oct 2013 13:26:45 -0500
From: "Cullen Jennings (fluffy)" 
To: cowwoc 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO00IXJVyL5itEmEWrISFOF+nwVA==
Date: Sun, 27 Oct 2013 18:26:44 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org>	<52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org>  <526C15CD.5020601@bbs.darktech.org> <526C3FE4.2040301@alvestrand.no> <526C4686.2080702@bbs.darktech.org>
In-Reply-To: <526C4686.2080702@bbs.darktech.org>
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="iso-8859-1"
Content-ID: <702426298958D4499B189D109FA3C798@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 18:27:20 -0000

On Oct 26, 2013, at 4:47 PM, cowwoc  wrote:

> On 26/10/2013 6:19 PM, Harald Alvestrand wrote:
>> I actually think Martin Thomson and Travis Leithead have been giving gre=
at input and been positive contributors. Not to belittle the contributions =
of others, but those two especially have made many positive contributions.
>>=20
>>>=20
>>>     An open process has to feel genuine, not just in words, but also in=
 actions.
>>>=20
>>=20
>> I think we may have some differing perspectives.
>=20
> I guess what I'm saying is... if all is well, then what's going on with M=
icrosoft and Apple? What's their official position regarding MTI? Will it i=
mpact their intent to bundle WebRTC in their browsers? If we truly have an =
open process and representatives from Microsoft and Apple sitting on the WG=
 then I would expect to get official answers to these questions.
>=20
> I've seen multiple representatives from Microsoft, but not a single perso=
n from Apple. Is anyone representing them in an official capacity?

Apple people have been involved (in fact are co-authors of some of the draf=
ts on the VP8 vs H264 topic) and Microsoft clearly been very involved with =
the WG as well.  Kaufman has been clear his employer has a policy of not pr=
e announcing products and I believe the same is true of Apple. This is ofte=
n true of standards work in any WG so it limits how much people can exactly=
 say about their employers until product is announced - that's pretty norma=
l at IETF.=20



From martin.thomson@gmail.com  Sun Oct 27 14:09:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38F311E82AA for ; Sun, 27 Oct 2013 14:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Level: 
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVeDNWVQWRdb for ; Sun, 27 Oct 2013 14:09:38 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BEBFF21E8082 for ; Sun, 27 Oct 2013 14:09:34 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so5886035wes.29 for ; Sun, 27 Oct 2013 14:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2teNN5/lA7aQ8EPgb9OtXrGvzzKK/seq5RC+2c9ZCzU=; b=iuumNviDJSafEAQYEIB0Fjp0Q7bYa8hzxSjjPaMPnjL7DTIg4FqvjbUf4Sx2rJ7y0M yAlL8tdsLYye7tqGPoD8q0p47uUdEip+KieMo8AmCjUVeHLF5XRL2kurt9gQ6Qy9X0DU w2ERkkEqR2EDziLSp12KeqK2mtPU+NwxvZBVcjWD05CZiee7BnP95GP3AreCrZQ9OKDF YdHCy5saDa6eM23vnB+P18zOsmRgvtOZHxeS2GqDSf6R76LTIpjZuqEMHjloRm0ctIvE OksrJQMFKO1XQ7dhs+sGRaJCe4fRcckmEAZXsURDUFNyaMjLLNs5WGfRsFmoLmGlD6K2 6Wkw==
MIME-Version: 1.0
X-Received: by 10.194.202.230 with SMTP id kl6mr15988516wjc.9.1382908168472; Sun, 27 Oct 2013 14:09:28 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Sun, 27 Oct 2013 14:09:28 -0700 (PDT)
In-Reply-To: <526C4686.2080702@bbs.darktech.org>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org>  <526C15CD.5020601@bbs.darktech.org> <526C3FE4.2040301@alvestrand.no> <526C4686.2080702@bbs.darktech.org>
Date: Sun, 27 Oct 2013 14:09:28 -0700
Message-ID: 
From: Martin Thomson 
To: cowwoc 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Oct 2013 21:09:39 -0000

On 26 October 2013 15:47, cowwoc  wrote:
> what's going on with Microsoft and Apple?

I can't speak for Apple, or Microsoft.  However I am able to share
some information.

> What's their official position
> regarding MTI?

For Microsoft at least, their position on MTI remains that specifying
MTI is not preferable.  You can find plenty of elaboration on this
subject if you search around a little.  However, it is also
Microsoft's view that it is extremely important to respect the
consensus process.

> Will it impact their intent to bundle WebRTC in their
> browsers?

That would be pure speculation.  Microsoft has a policy of not
revealing any information about unreleased and unannounced products,
and it seems like Apple act similarly.  I think it unlikely that you
are going to get any information on this subject.  Asking repeatedly
is likely to annoy more than it is to get more answers.  I suggest
that you concentrate on the issues, and try to keep speculation to
yourself.

From duerst@it.aoyama.ac.jp  Sun Oct 27 18:27:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0BC11E82E5 for ; Sun, 27 Oct 2013 18:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.46
X-Spam-Level: 
X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_05=-1.11, DATE_IN_PAST_12_24=0.992, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIgSuENYFeMV for ; Sun, 27 Oct 2013 18:27:20 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id BB8E811E82E1 for ; Sun, 27 Oct 2013 18:27:15 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9S1R6qu031615; Mon, 28 Oct 2013 10:27:06 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3633_afd6_0e85b6c6_3f70_11e3_9b39_001e6722eec2; Mon, 28 Oct 2013 10:27:06 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E6856C0003; Mon, 28 Oct 2013 10:27:05 +0900 (JST)
Message-ID: <526C6C21.90602@it.aoyama.ac.jp>
Date: Sun, 27 Oct 2013 10:28:01 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Bo Burman 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Performance of rate-controlled H.264 Constrained High Profile
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 01:27:27 -0000

On 2013/10/24 22:42, Bo Burman wrote:

> VP8 is anchor: H.264 CHP is 16% better
> H.264 is anchor: H.264 CHP is 24% better

Why don't you guys switch over to something logarithmic (e.g. something 
like dB) so that you don't have to do this VP8 is anchor/H.264 is anchor 
thing?

Regards,   Martin.

From cowwoc@bbs.darktech.org  Sun Oct 27 20:21:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D1411E8302 for ; Sun, 27 Oct 2013 20:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.441
X-Spam-Level: 
X-Spam-Status: No, score=-5.441 tagged_above=-999 required=5 tests=[AWL=-1.842, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlYhvS4oLA+5 for ; Sun, 27 Oct 2013 20:21:30 -0700 (PDT)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4730B11E82EF for ; Sun, 27 Oct 2013 20:21:27 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id x12so3530831qcv.0 for ; Sun, 27 Oct 2013 20:21:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zrQDTyKBvi0yiYIw4t6T2kah1eZ1JzfPdKLHqoRnQsI=; b=glSwVIHfgZaA+BV7EhDcuRr9k45iFGBQTRPKQIuQuJeaJGOiDN8BpfQNQkBYzEbdKS Og0oQYixnSsPo/s9oT78dFCZfIhcRZD+VgDMw+J7C80iblKqCKwKcUe0Wo7IIso0o7Fb QMwFwuJm+knpt2+Xd+ssUXoVu3R+GzPwg2x7Tk6WHmNAMso9jRgAL5irpUW8KcxrEv9o AjOblKIrwS/GF+u0+v9JuLgkcRXerVDPnpi6GwURogsul9JqOkqjd7Pl6y71xho10wHz Y92+BgzFEhmjJYxmlRNMowZriaGgo1j5Gy1FfxtQMSdxMbhoqRRV3HuE9VwoiNRdVDzI R3bQ==
X-Gm-Message-State: ALoCoQl4lgU4mC5IcbQfa5LtWyP69jCFQA+7lCVEqC/SYuM1luqWYICvvDVNTSsCQTFJYbgZ1MKz
X-Received: by 10.224.29.131 with SMTP id q3mr26729116qac.37.1382930486682; Sun, 27 Oct 2013 20:21:26 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id e7sm27986032qag.7.2013.10.27.20.21.25 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Oct 2013 20:21:26 -0700 (PDT)
Message-ID: <526DD833.2060309@bbs.darktech.org>
Date: Sun, 27 Oct 2013 23:21:23 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <52681A96.2020904@alvestrand.no>		<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>				<526AE703.8000409@bbs.darktech.org>		<526C15CD.5020601@bbs.darktech.org>	<526C3FE4.2040301@alvestrand.no>	<526C4686.2080702@bbs.darktech.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 03:21:36 -0000

On 27/10/2013 5:09 PM, Martin Thomson wrote:
> On 26 October 2013 15:47, cowwoc  wrote:
>> what's going on with Microsoft and Apple?
> I can't speak for Apple, or Microsoft.  However I am able to share
> some information.
>
>> What's their official position
>> regarding MTI?
> For Microsoft at least, their position on MTI remains that specifying
> MTI is not preferable.  You can find plenty of elaboration on this
> subject if you search around a little.  However, it is also
> Microsoft's view that it is extremely important to respect the
> consensus process.
>
>> Will it impact their intent to bundle WebRTC in their
>> browsers?
> That would be pure speculation.  Microsoft has a policy of not
> revealing any information about unreleased and unannounced products,
> and it seems like Apple act similarly.  I think it unlikely that you
> are going to get any information on this subject.  Asking repeatedly
> is likely to annoy more than it is to get more answers.  I suggest
> that you concentrate on the issues, and try to keep speculation to
> yourself.
Hi Martin,

     I understand. I'm happy to hear your official stance on MTI and 
Microsoft's commitment to the consensus process.

Thanks,
Gili

From cowwoc@bbs.darktech.org  Sun Oct 27 20:21:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A54B11E8265 for ; Sun, 27 Oct 2013 20:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.349
X-Spam-Level: 
X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rSqsXQQVLkf for ; Sun, 27 Oct 2013 20:21:31 -0700 (PDT)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDB211E82FA for ; Sun, 27 Oct 2013 20:21:28 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id k4so1837297qaq.0 for ; Sun, 27 Oct 2013 20:21:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mZRc/FdSSZ1nAQPQYnGzYkRFlfjgJHmqCK6vzptMFWo=; b=cvcRZlJbiLxve1sNnFTSStIwpZ867ANYfu3YrR1jA+poPg09VUpGx67e9OUIQtVLsp GwVm1FHgT/gi4xB6sr8CLZsJ8vrKTB2ugCsQwZAWaNXLU5HA5UJhJ5jXkLqr3VTkXkHG gKtepZTAD8l6vDI/8gOPw/33tLBDFGB4oylGtwdHmj+bpXyoYl4zzvLGFtsViwvT0oLF uHEwyXdyIzZyRIaczcR/7m8As5T3Zh8uCWk4g+ngrEIm0cTi1wTnHRhlwL85KFlwSiHv /r3xxYjW9efe0fL4A+BZlbx9HnQeICxk8/e6aDhNTGGz96A3M5zkNe9X0kHB+HaR7VZs c96Q==
X-Gm-Message-State: ALoCoQnQrw20V+qvhm4CKniLbc83g8NSIbsbcorIrdPGpf8npCqjE0A2H7Ebzf2775UJMJ11n8yq
X-Received: by 10.49.41.3 with SMTP id b3mr25929360qel.51.1382930487717; Sun, 27 Oct 2013 20:21:27 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ge5sm39581141qeb.5.2013.10.27.20.21.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Oct 2013 20:21:27 -0700 (PDT)
Message-ID: <526DD834.8000308@bbs.darktech.org>
Date: Sun, 27 Oct 2013 23:21:24 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" 
References: <52681A96.2020904@alvestrand.no>		<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>				<526AE703.8000409@bbs.darktech.org>		<526C15CD.5020601@bbs.darktech.org> <526C3FE4.2040301@alvestrand.no> <526C4686.2080702@bbs.darktech.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 03:21:37 -0000

On 27/10/2013 2:26 PM, Cullen Jennings (fluffy) wrote:
> Apple people have been involved (in fact are co-authors of some of the 
> drafts on the VP8 vs H264 topic) and Microsoft clearly been very 
> involved with the WG as well. Kaufman has been clear his employer has 
> a policy of not pre announcing products and I believe the same is true 
> of Apple. This is often true of standards work in any WG so it limits 
> how much people can exactly say about their employers until product is 
> announced - that's pretty normal at IETF. 

     Out of curiosity, who is representing Apple? I don't remember 
seeing the company name appearing on any of the documentation.

Gili

From victor.pascual.avila@gmail.com  Mon Oct 28 00:38:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF211E8210 for ; Mon, 28 Oct 2013 00:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NYWTcGtusfM for ; Mon, 28 Oct 2013 00:38:23 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E400511E81DB for ; Mon, 28 Oct 2013 00:38:11 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id r10so6659061pdi.4 for ; Mon, 28 Oct 2013 00:38:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rAQzIZb2nq0xC7jDb1NlgXB1UyYzQil3iFnnx/6c11Q=; b=tAvMbzV97DK5ho8VgD6R6RE4L24XtDaSFazMWKruswtMSXBJQ/8in23wYJvexBZ0vp Kd3+hDIpE96ieHoHSvmV2oZ/yMfZjMjeqdgHIKR0+OHZc+Z42CUePXvQTsmSQwOrX8NP DBKNTWWN8qvCRjOw+HQlvf5QQUlei9P0wXzPeT33IkkEBkFr+2VcLOq8sFlnng6MZW9a N9Lni/tgK5I3QHO8sflR8HxcXjCYZ/bEs/y1N7OYIZ3Xfkc8vO4jtc/Cbmn+7q8hfzDK Zt2BxzUjOuGcWEXN3jlo+/ikGAicDZwF8c3pQ52ATtNfh2W//p/X5qT9jD6rsZApmu1c nW7Q==
MIME-Version: 1.0
X-Received: by 10.66.65.195 with SMTP id z3mr23876164pas.47.1382945889052; Mon, 28 Oct 2013 00:38:09 -0700 (PDT)
Received: by 10.68.192.66 with HTTP; Mon, 28 Oct 2013 00:38:08 -0700 (PDT)
In-Reply-To: <526DD834.8000308@bbs.darktech.org>
References: <52681A96.2020904@alvestrand.no>  <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org>  <526C15CD.5020601@bbs.darktech.org> <526C3FE4.2040301@alvestrand.no> <526C4686.2080702@bbs.darktech.org>  <526DD834.8000308@bbs.darktech.org>
Date: Mon, 28 Oct 2013 08:38:08 +0100
Message-ID: 
From: Victor Pascual Avila 
To: cowwoc 
Content-Type: text/plain; charset=UTF-8
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 07:38:24 -0000

On Mon, Oct 28, 2013 at 4:21 AM, cowwoc  wrote:
> On 27/10/2013 2:26 PM, Cullen Jennings (fluffy) wrote:
>>
>> Apple people have been involved (in fact are co-authors of some of the
>> drafts on the VP8 vs H264 topic) and Microsoft clearly been very involved
>> with the WG as well. Kaufman has been clear his employer has a policy of not
>> pre announcing products and I believe the same is true of Apple. This is
>> often true of standards work in any WG so it limits how much people can
>> exactly say about their employers until product is announced - that's pretty
>> normal at IETF.
>
>
>     Out of curiosity, who is representing Apple? I don't remember seeing the
> company name appearing on any of the documentation.

http://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal-03

-Victor

From cowwoc@bbs.darktech.org  Mon Oct 28 01:56:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3611E8242 for ; Mon, 28 Oct 2013 01:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.265
X-Spam-Level: 
X-Spam-Status: No, score=-5.265 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa40uGGJJtZJ for ; Mon, 28 Oct 2013 01:56:16 -0700 (PDT)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id DF50411E8239 for ; Mon, 28 Oct 2013 01:55:59 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id e14so10396852iej.25 for ; Mon, 28 Oct 2013 01:55:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=mcKi1F8HBgC4mO7KOFmo7R+zLpLzQKBpPDbqp8pJeYs=; b=Jok3jmsKz70nsH6i29x+Vx17V6Zg/Keg+jkZs8YZclDRDTL7ma5F5t5+TX8BeYDfwz olvhBLu24SufoBWc9I/wgH3Aaz2FoEe7sw1QVOrYXH5gGTQe5+e+aPQu5NKT4H89Y+1t eW0NVTr1Z7+9YnLo9x9hhz/nPteEWR15tqPmCaHcsLcV1z7zLvufvwSs1+pAbVkzRGyj bEMrWfHXvtVKFmnFKa95kYvCC2E5a/SVrMkpdBVsBmTlnxbrXS7BIgjgZYsLYB83NaHb hqRMPZiu+FUOyB98SGtPoCL22Y24Xwemk7MQ7rhq6CqYAUtVB0eCj3Ri8pnr9z1vfGw7 CPfQ==
X-Gm-Message-State: ALoCoQnopS+uJzYrO932xLgI94XIOy3mABlonZSoNXvQF6qnaa4XISxJJCP/fBClW0grmYEE3Sm5
X-Received: by 10.50.40.103 with SMTP id w7mr7460693igk.53.1382950559230; Mon, 28 Oct 2013 01:55:59 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id o15sm18871970igx.6.2013.10.28.01.55.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Oct 2013 01:55:58 -0700 (PDT)
Message-ID: <526E269B.6010903@bbs.darktech.org>
Date: Mon, 28 Oct 2013 04:55:55 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <52681A96.2020904@alvestrand.no>	<5269764C.4030801@librevideo.org>	<52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>				<526AE703.8000409@bbs.darktech.org>		<526C15CD.5020601@bbs.darktech.org>	<526C3FE4.2040301@alvestrand.no>	<526C4686.2080702@bbs.darktech.org>		<526DD834.8000308@bbs.darktech.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050704000706030707000008"
Cc: "Cullen Jennings \(fluffy\)" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 08:56:22 -0000

This is a multi-part message in MIME format.
--------------050704000706030707000008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 28/10/2013 3:38 AM, Victor Pascual Avila wrote:
> On Mon, Oct 28, 2013 at 4:21 AM, cowwoc  wrote:
>> On 27/10/2013 2:26 PM, Cullen Jennings (fluffy) wrote:
>>> Apple people have been involved (in fact are co-authors of some of the
>>> drafts on the VP8 vs H264 topic) and Microsoft clearly been very involved
>>> with the WG as well. Kaufman has been clear his employer has a policy of not
>>> pre announcing products and I believe the same is true of Apple. This is
>>> often true of standards work in any WG so it limits how much people can
>>> exactly say about their employers until product is announced - that's pretty
>>> normal at IETF.
>>
>>      Out of curiosity, who is representing Apple? I don't remember seeing the
>> company name appearing on any of the documentation.
> http://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal-03
>
> -Victor

     Very interesting. Thank you for the head's up.

     I read your blog post (discussed off-list) and it had the opposite 
effect then what you'd expect. It made me reflect back on the days where 
I had to deal with the headache of H264 transcoding (cost and 
complexity) and it made me realize something:

     I would accept MTI any day of the week if it were necessary to 
avoid transcoding.
     I would accept VP8 (instead of H264) as MTI any day of the week to 
avoid licensing fees.

     I've been playing devil's advocate over the past couple of weeks 
because I wanted to hear everyone's arguments (indeed, it resulted in a 
lively debate) but as a webapp developer I err solidly on Google's side 
(in spite of the fact that their intentions are not pure). I fully 
appreciate why most vendors are falling behind H264, but as a webapp 
developer I have different interests (avoiding complex/expensive 
transcoding and licensing fees if possible). Further, I would argue that 
requiring transcoding would have a crippling effect on WebRTC (in many 
ways, it would be no better than the status-quo).

     When comparing H264 to VP8, the discussion has convinced me that 
VP8 is technically "good enough" and that neither H264 nor VP8 is 
completely safe from a legal point of view.

     For those reasons, I would vote for:

 1. No MTI if we can reasonably avoid transcoding for up-to-date clients
    (browsers, mobile devices). I don't mind vendors needing to
    transcode to support legacy devices (telephony).
 2. VP8 as MTI, otherwise.

Gili

--------------050704000706030707000008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 28/10/2013 3:38 AM, Victor Pascual
      Avila wrote:

    

    

      
On Mon, Oct 28, 2013 at 4:21 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:


      

        
On 27/10/2013 2:26 PM, Cullen Jennings (fluffy) wrote:


        

          
Apple people have been involved (in fact are co-authors of some of the
drafts on the VP8 vs H264 topic) and Microsoft clearly been very involved
with the WG as well. Kaufman has been clear his employer has a policy of not
pre announcing products and I believe the same is true of Apple. This is
often true of standards work in any WG so it limits how much people can
exactly say about their employers until product is announced - that's pretty
normal at IETF.


        

        

    Out of curiosity, who is representing Apple? I don't remember seeing the
company name appearing on any of the documentation.


      

      
http://tools.ietf.org/html/draft-burman-rtcweb-h264-proposal-03

-Victor


    

    

        Very interesting. Thank you for the head's up.

    

        I read your blog post (discussed off-list) and it had the
    opposite effect then what you'd expect. It made me reflect back on
    the days where I had to deal with the headache of H264 transcoding
    (cost and complexity) and it made me realize something:

    

        I would accept MTI any day of the week if it were necessary to
    avoid transcoding.

        I would accept VP8 (instead of H264) as MTI any day of the week
    to avoid licensing fees.

    

        I've been playing devil's advocate over the past couple of weeks
    because I wanted to hear everyone's arguments (indeed, it resulted
    in a lively debate) but as a webapp developer I err solidly on
    Google's side (in spite of the fact that their intentions are not
    pure). I fully appreciate why most vendors are falling behind H264,
    but as a webapp developer I have different interests (avoiding
    complex/expensive transcoding and licensing fees if possible).
    Further, I would argue that requiring transcoding would have a
    crippling effect on WebRTC (in many ways, it would be no better than
    the status-quo).

    
    When comparing H264 to VP8, the discussion has convinced me
      that VP8 is technically "good enough" and that neither H264 nor
      VP8 is completely safe from a legal point of view.

    

        For those reasons, I would vote for:

    
    
      
  1. No MTI if we can reasonably avoid transcoding for up-to-date
        clients (browsers, mobile devices). I don't mind vendors needing
        to transcode to support legacy devices (telephony).
    2. 
      
  2. VP8 as MTI, otherwise.
    3. 
    

    Gili

  


--------------050704000706030707000008--

From singer@apple.com  Mon Oct 28 02:20:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3B911E824C for ; Mon, 28 Oct 2013 02:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s57smGbq2KWR for ; Mon, 28 Oct 2013 02:19:53 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7721811E8239 for ; Mon, 28 Oct 2013 02:19:53 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVD00G1PGKFST00@mail-out.apple.com> for rtcweb@ietf.org; Mon, 28 Oct 2013 02:19:53 -0700 (PDT)
X-AuditID: 11807157-b7ff46d000001540-69-526e2c3878a1
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay4.apple.com (Apple SCV relay) with SMTP id 03.A7.05440.83C2E625; Mon, 28 Oct 2013 02:19:52 -0700 (PDT)
Received: from [17.153.57.41] (unknown [17.153.57.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVD00BADGL2A620@spicerack.apple.com> for rtcweb@ietf.org; Mon, 28 Oct 2013 02:19:52 -0700 (PDT)
Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated.
From: David Singer 
In-reply-to: 
Date: Mon, 28 Oct 2013 10:19:49 +0100
Message-id: <0DB4F63F-F111-41E3-B961-0B73B058867D@apple.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no>   <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>  <5269F098.2020904@alvestrand.no>  <949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>    <526AE703.8000409@bbs.darktech.org>  <526C15CD.5020601@bbs.darktech.org> <526C3FE4.2040301@alvestrand.no> <526C4686.2080702@bbs.darktech>
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCsoWuhkxdksPGKlcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPx1DWvBcaGKYy/2sTUwfuTrYuTkkBAwkVjdtJYRwhaTuHBv PRuILSQwmUni++TALkYuIHshk8SJL3OZQRLCAgESnxr3sYDYzAJaEut3HmcCsXkF9CR27t3G ClFjLNHz5DPYIDYBVYkHc46BLeAU8JU4PeUeWD0LUHzSxodQc7Qlnry7ANTLATTHRuLkUROI vS0cEk1L1oDNFBFQl7j88AI7xKGyEqfPPWeZwCgwC8kZs5CcMQvJ2AWMzKsYBYpScxIrTfQS CwpyUvWS83M3MYIDrzB8B+O/ZVaHGAU4GJV4eCNW5wYJsSaWFVfmHmKU4GBWEuE1Uc0LEuJN SaysSi3Kjy8qzUktPsQozcGiJM67sDs7SEggPbEkNTs1tSC1CCbLxMEp1cCYdWrBwk7xyeUs nO/cb75MbfsXf4LFY7XGFvauO5x8+4qVsids+WvBUjlTc0cAp9gC5inK7cdOv30uss91h8bO tTLTppge+7n5/4rwB4rnkzOf/zL/5DNNpd3L2jVn8wypywvnfFPhe5fVHc3zdIm+uKmchcX6 Saom97/trdt08vHh6asf3VLgVGIpzkg01GIuKk4EAJpdDvI4AgAA
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 09:20:00 -0000

On Oct 27, 2013, at 19:26 , Cullen Jennings (fluffy)  wrote:

> 
> On Oct 26, 2013, at 4:47 PM, cowwoc  wrote:
> 
>> On 26/10/2013 6:19 PM, Harald Alvestrand wrote:
>>> I actually think Martin Thomson and Travis Leithead have been giving great input and been positive contributors. Not to belittle the contributions of others, but those two especially have made many positive contributions.
>>> 
>>>> 
>>>>    An open process has to feel genuine, not just in words, but also in actions.
>>>> 
>>> 
>>> I think we may have some differing perspectives.
>> 
>> I guess what I'm saying is... if all is well, then what's going on with Microsoft and Apple? What's their official position regarding MTI? Will it impact their intent to bundle WebRTC in their browsers? If we truly have an open process and representatives from Microsoft and Apple sitting on the WG then I would expect to get official answers to these questions.
>> 
>> I've seen multiple representatives from Microsoft, but not a single person from Apple. Is anyone representing them in an official capacity?
> 
> Apple people have been involved (in fact are co-authors of some of the drafts on the VP8 vs H264 topic) and Microsoft clearly been very involved with the WG as well.  Kaufman has been clear his employer has a policy of not pre announcing products and I believe the same is true of Apple. This is often true of standards work in any WG so it limits how much people can exactly say about their employers until product is announced - that's pretty normal at IETF. 

We would be delighted for the community to establish a royalty free codec, in particular for web applications. To that goal, among other efforts, and together with several other companies, we proposed to MPEG last year H.264 Constrained Baseline as a basis for a new royalty free standard. This project, named by MPEG Web Video Coding, is now at a DIS (Draft International Standard) stage, and we are collecting IPR disclosures.
We are also co-authors on the H.264 proposal for MTI to WebRTC.

As others have noted, we are, alas, formally constrained not to discuss what we might or might not do in future (sorry).

David Singer
Multimedia and Software Standards, Apple Inc.


From Michael.Tuexen@lurchi.franken.de  Mon Oct 28 05:05:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D04921F9FBA for ; Mon, 28 Oct 2013 05:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6BAAb3cmnEp for ; Mon, 28 Oct 2013 05:05:26 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id E0ADD11E824F for ; Mon, 28 Oct 2013 05:05:21 -0700 (PDT)
Received: from [192.168.1.200] (p508F23F7.dip0.t-ipconnect.de [80.143.35.247]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 598FA1C0C0692; Mon, 28 Oct 2013 13:05:19 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen 
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>
Date: Mon, 28 Oct 2013 13:05:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <52B42DFC-7A8E-4FD3-9820-F57E4B98ADCA@lurchi.franken.de>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>
To: "Ejzak, Richard P (Richard)" 
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 12:05:29 -0000

On Oct 24, 2013, at 10:38 PM, "Ejzak, Richard P (Richard)" =
 wrote:

> Hi Michael,
>=20
>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Sent: Thursday, October 24, 2013 2:21 PM
>=20
>> On Oct 24, 2013, at 8:36 PM, "Ejzak, Richard P (Richard)"
>>  wrote:
>>=20
>>> Justin, Michael,
>>> Thanks for the clarifications.  One more question.  What happens if
>> the application tries to select a stream id before the DTLS role is
>> known and it ends up selecting an invalid one?
>> I'm not completely familiar with the JS API, but if you want to =
select
>> a stream, aren't you managing the stream completely on your own. I
>> think the DTLS role stuff is only relevant if the streams are managed
>> by the browser.
>=20
> If this is the intent then that clarification would be very useful.  =
Reading the API text again, it is clear that the browser only manages =
stream ids that it selects.  Does this mean that the browser stream id =
selection option is not compatible with the application stream id =
selection option?  Putting it more precisely, should we require that the =
application not be allowed to select stream ids prior to determining =
DTLS role if it expects that either side might use the browser stream id =
selection option?  It would be easier if the even/odd rule could be =
determined earlier than DTLS role establishment so that the application =
could use the same even/odd assignment rule for early data channel =
creation.
>=20
>>>=20
>>> Michael,
>>> While it's true that the data channel control protocol cannot open
>> the channel with the peer before the DTLS role is known, the API =
allows
>> the application to create the data channel before the DTLS role is
>> known, in which case the sending of the Open message must wait until
>> the SCTP association is established.  I want to know what the
>> application is supposed to do it if needs to create data channels =
with
>> preselected stream ids before the DTLS role is known.  This seems =
like
>> something that the spec should make clear rather than leaving it to
>> implementation.
>> Can you assign the stream ID in the API? Could you point me to the
>> text?
>=20
> http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute in =
the RTCDataChannelInit dictionary that must be the equivalent of the =
"stream identifier".  No other interpretation makes sense to me but =
please correct me if I am wrong.  Note in particular the following text =
within the description of the createDataChannel procedure (my =
parenthetical): "If the value of the id attribute is null, initialize it =
to a value generated by the user agent (browser), according to the =
WebRTC DataChannel Protocol specification, and skip to the next step. =
Otherwise, if the value of the id attribute is taken by an existing =
RTCDataChannel, throw a TBD exception and abort these steps."  So "id" =
must refer to "stream identifier" since there is no other id in your =
draft that it could refer to.
I don't see in the document a statement that the id corresponds to the =
stream identifier.
If that is the case, it should be mentioned. The W3C document indicates =
that the type
of id is unsigned short?. I don't know enough JS to know if this =
corresponds to uint16_t
or not. If not, there is a problem...
>=20
> If I'm right, then it would be good if it were made clear that id =
refers to "stream identifier", but that is a w3c issue.  Quoting from =
5.2.1 (my parentheticals for clarity): "The id was either assigned by =
the user agent (browser) at channel creation time (not channel opening =
time) or selected by the script (application). The attribute MUST return =
the value to which it was set when the RTCDataChannel was created (not =
opened)."
>=20
> I used the wrong terminology in my earlier mail when I referred to =
"open" of the data channel when I meant "creation".  Since the data =
channel can be "created" before DTLS role is known and before the data =
channel can be opened, the quoted text above would seem to indicate that =
the application can never determine the stream id actually assigned to =
the data channel if id can't be determined at time of creation.  Justin =
implied that the chrome behavior does not conform to this description.  =
Comment, Justin?
>=20
> It still seems to me that a change in the rule describing even/odd =
stream id assignment would be a good idea.
It depends on the restrictions we have for external negotiation...

Best regards
Michael
>=20
> BR, Richard
>=20


From Michael.Tuexen@lurchi.franken.de  Mon Oct 28 12:20:52 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22AF21E805D for ; Mon, 28 Oct 2013 12:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACNBMqDuSAIE for ; Mon, 28 Oct 2013 12:20:52 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 2B39A21E80B2 for ; Mon, 28 Oct 2013 12:20:48 -0700 (PDT)
Received: from [10.0.1.102] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7C9E91C0C0692; Mon, 28 Oct 2013 20:20:47 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen 
In-Reply-To: <526CDB44.7000002@jesup.org>
Date: Mon, 28 Oct 2013 20:20:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <20C2D87A-0627-4112-A9E0-E93AAF2E50F0@lurchi.franken.de>
References: <20131021191313.32469.99466.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C7EB@US70UWXCHMBA04.zam.alcatel-lucent.com> <526CDB44.7000002@jesup.org>
To: Randell Jesup 
X-Mailer: Apple Mail (2.1510)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-06.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 19:20:52 -0000

On Oct 27, 2013, at 10:22 AM, Randell Jesup  =
wrote:

> On 10/24/2013 12:41 PM, Ejzak, Richard P (Richard) wrote:
>> I have some comments/questions about =
draft-ietf-rtcweb-data-channel-06.
>=20
> Thanks!
>=20
>> The last paragraph of section 6.4 is a little ambiguous, but also =
seems to contradict the decision that the same stream identifier will be =
used in both directions.  I assume that "number" and "stream value" in =
the paragraph both refer to SCTP "stream identifier"?  Shouldn't the =
paragraph say that while SCTP does not constrain allocation of the =
stream identifier in the two directions, a bidirectional data channel is =
defined as a pair of streams in opposite directions that use the same =
stream identifier?
>=20
> Likely we should remove the Note in 6.4 that allows bidirectional =
streams to have different SCTP Stream numbers in each direction - I'm =
pretty sure this is left over from before the switch from 3-way =
handshake to 1-way declarative.
We might want to bring this up in the presentation on data channels at =
the IETF.
Just to make sure everyone has the same understanding on external =
negotiated channels...


Best regards
Michael
>=20
>> The discussion in the 3rd paragraph of section 6.5, which describes =
some constraints on external negotiation, is a bit confusing to me.  I =
assume that "picks a Stream" is intended to mean "picks a Stream =
Identifier"?  For clarity I would prefer the latter, unless something =
else is intended.
>=20
> I'll look; that seems reasonable.
>=20
>> In the same paragraph, DTLS role is used as a possible way of =
determining whether one side can select odd or even stream identifiers, =
but this is problematic.  It must be possible for the side requesting =
(offering) the peer connection to open a data channel before DTLS role =
can be determined.  How can the application know whether to request an =
odd or even stream identifier for a data channel if it doesn't know the =
DTLS role yet?  May I suggest that a better example would be to say that =
selection is based on which side sends the initial SDP offer creating =
the peer connection (e.g., the initial offerer picks even stream =
identifiers and the initial answerer picks odd stream identifiers).
>=20
> That breaks down when a server decides to connect two offers together =
(i.e. an offer could be transformed into an answer to an existing offer =
(and the same for the other direction) without either side knowing).  =
This is done in SIP servers all the time (surprised me the first time I =
ran into it), along with offers that originate "in the middle" from the =
server or SBC.   Kinda evil, but stuff like this will be done I believe, =
given the server is also normally supplying the JS application and so it =
would expect this behavior.
>=20
> The stream ID used is selected once the DTLS role is known.  In W3 =
terms, the channel.id isn't a valid value immediately when calling =
createDataChannel before SetLocal/RemoteDescription.  Before that =
happens (at the W3 api level), we currently return an invalid ID (65535 =
- max per the data channel spec is 65534).
>=20
>> In the same paragraph, the last sentence points out that the other =
side must inform the protocol to expect data using the stream identifier =
selected by the first side, but must also select parameters for use with =
data that it sends.  I assume that this text requires that the same =
stream identifier be used for the streams in both directions, but this =
is not stated clearly.  If not, do you assume that external negotiation =
establishes unidirectional channels only?  If the latter, are the =
sending parameters relevant to the other side?  Is something else =
intended?
>=20
> They must inform the other side in some manner so that the other side =
knows why data is appearing on a specific stream id.  The W3 side is =
based on the assumption that DataChannels (W3 level) are bidirectional =
and have a consistent 'id' value on both sides.  (see comments about 6.4 =
above)
>=20
> The intention was to define an external negotiation as the equivalent =
to internal - i.e. reliability settings SHOULD be provided, and SHOULD =
match on both sides.  This was specifically not a MUST, and the decision =
to match or not is in the application's hands.
>=20
>> Section 6.6 says that the "higher level" can override the default =
reliability options with per-message options.  I don't think this is =
allowed by the API, or did I miss something?  While I know that SCTP =
could potentially allow this with API support, it seems confusing to =
describe capabilities not available from the API without some clarifying =
text.
>=20
> The current WebRTC W3 API does not allow for this.  However, this =
draft is designed to work if that were to change, as there's no =
technical reason the IETF-level spec has to require that.  (This is =
similar to the use of SHOULD on matching the reliability options in =
external negotiation.)  For example, perhaps CLUE would use =
data-channels, and would want to use an optional per-message reliability =
to override the default.  This would require that both ends know and =
expect this can happen.
>=20
> --=20
> Randell Jesup -- rjesup a t mozilla d o t com
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20


From ted.ietf@gmail.com  Mon Oct 28 14:08:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7646F11E82AB for ; Mon, 28 Oct 2013 14:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxnGgRT0KLBF for ; Mon, 28 Oct 2013 14:08:16 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4311E82A9 for ; Mon, 28 Oct 2013 14:08:13 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id e14so12089824iej.39 for ; Mon, 28 Oct 2013 14:08:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ySANhqUb3eNxeX4GXzSalElmyz2Jcpm1oOqUZFRdJM0=; b=IrSTXwdqy+3kVs4HccroZKqhoUyW6NBI5+w/s5CWSYvaIDs461Mdnw/4k8MKtRb2IT m46wfDsOpvhOWhfIS2lgN99cK2bii3DOe+KEcmIevet+bR70aJssuXmkQjegEtiz6Nfs KVWLg51WnlidddAXI+DoQOmMGS7ne6+MLcU/lQdAGm3rDu2DU/JSj6PewBZ1aonYUITI M0jllLrOAy6mEUcdcfnXtf5g4YNS7z826KuDt9sDYKMVoNTIqO5BrflrCQcHZzyvT8+x xVFzj5Qk/vgo6gRWsluY22EpiVKSAs/FnMkO5D5orz+rrLYycVLpocOFw76TZ2h+f2tU Gk1g==
MIME-Version: 1.0
X-Received: by 10.50.61.205 with SMTP id s13mr10091611igr.29.1382994492590; Mon, 28 Oct 2013 14:08:12 -0700 (PDT)
Received: by 10.43.115.72 with HTTP; Mon, 28 Oct 2013 14:08:12 -0700 (PDT)
Date: Mon, 28 Oct 2013 14:08:12 -0700
Message-ID: 
From: Ted Hardie 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bd7679a7526ac04e9d37f2b
Subject: [rtcweb] Chair request on video codec discussion
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 21:08:16 -0000

--047d7bd7679a7526ac04e9d37f2b
Content-Type: text/plain; charset=ISO-8859-1

Howdy,

While the proponents of H.264 and VP8 continue to discuss performance,
there appears to be general agreement that either codec could serve the
purpose set out our for our MTI:  to avoid negotiation failure that results
in the loss of basic functionality.  If there are technical issues which
would prevent  either from being used as the MTI that have not yet been
raised, please do so before the beginning of IETF88.

regards,

Ted, Cullen, Magnus

--047d7bd7679a7526ac04e9d37f2b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





-- 




--bcaec520ef43cea2de04e9f8c931--

From matthew@matthew.at  Wed Oct 30 10:41:46 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E468D11E8238 for ; Wed, 30 Oct 2013 10:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myiP-pMCpA65 for ; Wed, 30 Oct 2013 10:41:39 -0700 (PDT)
Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 673EA21E8151 for ; Wed, 30 Oct 2013 10:41:35 -0700 (PDT)
Received: from [10.10.155.2] (unknown [10.10.155.2]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id C44053C9DE0; Wed, 30 Oct 2013 10:40:39 -0700 (PDT)
Message-ID: <52714498.1090401@matthew.at>
Date: Wed, 30 Oct 2013 10:40:40 -0700
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Jack Moffitt 
References: <52681A96.2020904@alvestrand.no>	<52713962.3010201@matthew.at> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:41:47 -0000

On 10/30/2013 10:07 AM, Jack Moffitt wrote:
>>> Do we switch now, or do we give up and live with royalties forever?
>> This is a little dramatic. One can trivially prove that every technology
>> required to implement H.264 will lose the protection of the patent system in
>> a finite period of time. Much, much sooner than "forever".
> Selection of royalty-required codecs sets a precedent.
>
> jack.

Prove that VP8 isn't such a thing, and we'd have a clear decision to make.

Matthew Kaufman

From adam@nostrum.com  Wed Oct 30 10:46:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E25A21F9F23 for ; Wed, 30 Oct 2013 10:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po28mmqa8lS5 for ; Wed, 30 Oct 2013 10:46:33 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A111E8126 for ; Wed, 30 Oct 2013 10:45:53 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9UHjkxA026188 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 12:45:47 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <527145C5.9040401@nostrum.com>
Date: Wed, 30 Oct 2013 12:45:41 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Jonathan Rosenberg , Leon Geyser 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>	<527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>				<527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>				 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010405030401040906030508"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:46:34 -0000

This is a multi-part message in MIME format.
--------------010405030401040906030508
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/30/13 12:37, Jonathan Rosenberg wrote:
> This covers all of the desktop platforms (Windows, Mac, Linux), and 
> Android, and probably others. I think thats a pretty solid set. For 
> small volume platforms where this doesnt work,  they can use the 
> source code and then we cannot cover any MPEG-LA licensing fees - but 
> you should check the MPEG-LA terms since they don't kick in until a 
> certain volume is reached anyway.
>

Also (from the FAQ): " As long as there are ports of the source code and 
automatic build scripts contributed as part of the open source, we do 
not see difficulties in adding additional platforms."

/a

--------------010405030401040906030508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/30/13 12:37, Jonathan Rosenberg
      wrote:

    

    

      
This covers all of the desktop platforms (Windows,
        Mac, Linux), and Android, and probably others. I think thats a
        pretty solid set. For small volume platforms where this doesnt
        work,  they can use the source code and then we cannot cover any
        MPEG-LA licensing fees - but you should check the MPEG-LA terms
        since they don't kick in until a certain volume is reached
        anyway. 

      


      

    

    

    Also (from the FAQ): "
    
    As long as there are ports of the source code and automatic build
    scripts contributed as part of the open source, we do not see
    difficulties in adding additional platforms."

    

    /a

  


--------------010405030401040906030508--

From adam@nostrum.com  Wed Oct 30 10:55:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FE211E8160 for ; Wed, 30 Oct 2013 10:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level: 
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXQyjvBCVBHE for ; Wed, 30 Oct 2013 10:55:23 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78911E8238 for ; Wed, 30 Oct 2013 10:55:18 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9UHtG0v026579 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 30 Oct 2013 12:55:18 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <527147FF.5010506@nostrum.com>
Date: Wed, 30 Oct 2013 12:55:11 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:55:27 -0000

As Jonathan mentioned earlier, this morning Cisco announced that it will 
be open sourcing an H.264 implementation as well as gratis binary 
modules compiled from that source and hosted by Cisco for download. 
Mozilla will be modifying Firefox to support H.264 by downloading 
Cisco's binary module.

In previous discussions of which codec should be MTI, Mozilla has stated 
that it could not accept H.264 as MTI, primarily because we could not 
deliver H.264 in Firefox. That obstacle is now removed, and we can 
accept either codec as MTI.

Mozilla intends to continue supporting VP8 in WebRTC, but we will also 
support H.264.

/a

From pkyzivat@alum.mit.edu  Wed Oct 30 10:59:02 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254AC11E82C1 for ; Wed, 30 Oct 2013 10:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.248
X-Spam-Level: 
X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[AWL=0.189,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaEg+HH7pPGs for ; Wed, 30 Oct 2013 10:58:46 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 90A7E21E8140 for ; Wed, 30 Oct 2013 10:57:31 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id jPox1m0031c6gX85FVxXkg; Wed, 30 Oct 2013 17:57:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id jVxW1m00N3ZTu2S3jVxWZj; Wed, 30 Oct 2013 17:57:31 +0000
Message-ID: <5271488A.4090206@alum.mit.edu>
Date: Wed, 30 Oct 2013 13:57:30 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Eric Rescorla 
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>  <526FFEBC.7090302@alum.mit.edu>  <527005A1.7000007@alum.mit.edu> 
In-Reply-To: 
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=q20121106; t=1383155851; bh=Us64lSeyVPdRexl9bB0DjfIQKSR1ieXN4uI3TauozYo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y36ZzmgCC4SU4EEambI0PprIxHKFmYP/Rv/pyAK36YOYwg5bEkd4uv691Klc9WLeL 6d7+yNeVxwVMWJABr6shJdKKpEr2z8FepQaqLPXe2SXciFkYZ3vgePGywzh3rMAmeT VSHXqOVivV1GqEsiy+hJGC+j1+IPMD+cz+JJhcMB9Pkcmd3ayPNc6R422WmzUy5elf Vg3Hy9UEcQI3IxvfkQaIt2qEDBh/INHDg5ELvZLxaGIXblsBUviLL3bGYW0Il6Sldt uRJhzlkKt+l2dsbO0a/lLy/KrCDlCYrGYBLEgio21Rt6RZPkJjizyfLICDU7xzWWw/ Tsc7U16R5fXAg==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:59:02 -0000

On 10/29/13 4:47 PM, Eric Rescorla wrote:
>
> On Tue, Oct 29, 2013 at 11:59 AM, Paul Kyzivat  > wrote:
>
>     (trimming)
>
>
>     On 10/29/13 2:46 PM, Eric Rescorla wrote:
>
>                       Is it not possible for an intermediary on the
>         signaling path to
>                       insert itself in the media path, manipulating the
>         SDP such
>                  that the
>                       two ends both establish the DTLS with the
>         intermediary?
>
>                  There is a separate role negotiation for DTLS (actpass,
>         etc.)
>                  that works
>                  even if both sides think they are the offerer or answerer.
>
>
>              I know about that. That mechanism is also used for TCP
>         negotiation
>              in SDP. And that is one place where an intermediary
>         sometimes sticks
>              its nose in explicitly to manipulate the roles, allowing
>         both ends
>              to be active.
>
>              In the current case, ICE and possible TURN result in
>         getting the
>              media path established without those games. So maybe there
>         is less
>              motivation for an intermediary. But still, they still seem
>         to show
>              up because administrators think they need them. And once there,
>              couldn't the intermediary still end up making both ends
>         think they
>              are active?
>
>         Well, it could but then they wouldn't be able to negotiate DTLS.
>
>
>     Couldn't it negotiation independently on each side - becoming a true
>     MITM.
>
>     (I'm not advocating this as a good thing. But if it is possible,
>     there will be someone who wants to do it, and somebody willing to
>     sell them stuff to do it.)
>
>
> Sure, but then you would need to also intermediate the SCTP.
>
> I'm not following what you see as the problem here.

I'm not certain there is a problem. This just smells like other problems 
that have arisen in the past.

Yes, this attack would require terminating and splicing two SCTP 
associations. Ultimately it comes down to how much work must be done in 
the middle.

So maybe its better to just leave it as hard as possible for 
intermediaries to do so.

	Thanks,
	Paul


From lgeyser@gmail.com  Wed Oct 30 11:20:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E5711E818B for ; Wed, 30 Oct 2013 11:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.406
X-Spam-Level: 
X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0pEHsdI+Er2 for ; Wed, 30 Oct 2013 11:20:22 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BE4C411E82C4 for ; Wed, 30 Oct 2013 11:20:21 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id q8so1535214lbi.33 for ; Wed, 30 Oct 2013 11:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JuZ/6nVkLXpiunM4SaTgJ/Si6y+wC/ueRTlNkBYcNkg=; b=U9fbzmGNM4RDazo8NgxcXdiqn6Z7oDAxUa81Zdddb+KlLHPeU4r3dQTvP1QiGfibvZ +N5JyZWq5A6nCe3eOn93RpRsv4zIIr1nZ5H4im5ixBCZ5uP8MINk2ULzJJ61F0EvunSq Xe091cqff/S5tptdZ7wapUcjnwt6qiJVJFKN3wKbVad4Q8vui2kc1pV2Nok4/wbIVdIo Apc9EBg2ySKEN9658z/CwPIX9sGflqUd9bJeuxBJEs2W+NEZ549lkYMQ2asXootwAKC3 /iQtb0ixR4weZ36VNsuAxS69Flna9uUTPlAIBoWjHioKveUNqkA9Lyi2SBmtxmclku7w 0pUw==
MIME-Version: 1.0
X-Received: by 10.152.36.41 with SMTP id n9mr4056488laj.21.1383157220743; Wed, 30 Oct 2013 11:20:20 -0700 (PDT)
Received: by 10.114.168.70 with HTTP; Wed, 30 Oct 2013 11:20:20 -0700 (PDT)
In-Reply-To: <527147FF.5010506@nostrum.com>
References: <527147FF.5010506@nostrum.com>
Date: Wed, 30 Oct 2013 20:20:20 +0200
Message-ID: 
From: Leon Geyser 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=089e0158b608cf9cba04e9f96246
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:20:22 -0000

--089e0158b608cf9cba04e9f96246
Content-Type: text/plain; charset=ISO-8859-1

Unfortunately like Jonathan pointed out H.264 will only be able to be used
royalty free on certain(most popular) platforms.
To be able to avoid negotiation failure we need a MTI codec that every
potential now/future browser would be able to implement freely.
I like what Cisco did, but the solution seems a bit half-baked.

On 30 October 2013 19:55, Adam Roach  wrote:

> As Jonathan mentioned earlier, this morning Cisco announced that it will
> be open sourcing an H.264 implementation as well as gratis binary modules
> compiled from that source and hosted by Cisco for download. Mozilla will be
> modifying Firefox to support H.264 by downloading Cisco's binary module.
>
> In previous discussions of which codec should be MTI, Mozilla has stated
> that it could not accept H.264 as MTI, primarily because we could not
> deliver H.264 in Firefox. That obstacle is now removed, and we can accept
> either codec as MTI.
>
> Mozilla intends to continue supporting VP8 in WebRTC, but we will also
> support H.264.
>
> /a
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb
>

--089e0158b608cf9cba04e9f96246
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Unfortunately like Jonathan pointed out H.264 will on=
ly be able to be used royalty free on certain(most popular) platforms.
T=
o be able to avoid negotiation failure we need a MTI codec that every poten=
tial now/future browser would be able to implement freely.


I like what Cisco did, but the solution seems a bit half-baked.

On 30 October 2013 =
19:55, Adam Roach <adam@nostrum.com> wrote:


As Jonathan mentioned earlier, this morning =
Cisco announced that it will be open sourcing an H.264 implementation as we=
ll as gratis binary modules compiled from that source and hosted by Cisco f=
or download. Mozilla will be modifying Firefox to support H.264 by download=
ing Cisco's binary module.




In previous discussions of which codec should be MTI, Mozilla has stated th=
at it could not accept H.264 as MTI, primarily because we could not deliver=
 H.264 in Firefox. That obstacle is now removed, and we can accept either c=
odec as MTI.




Mozilla intends to continue supporting VP8 in WebRTC, but we will also supp=
ort H.264.



/a

_______________________________________________

rtcweb mailing list

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





--089e0158b608cf9cba04e9f96246--

From jlaurens@cisco.com  Wed Oct 30 11:22:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C208E21E8137 for ; Wed, 30 Oct 2013 11:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2xuBCHNR4Tk for ; Wed, 30 Oct 2013 11:22:51 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 01D9C11E82B1 for ; Wed, 30 Oct 2013 11:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11581; q=dns/txt; s=iport; t=1383157371; x=1384366971; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yEJuUIFXgIt3vPz8PusZBsA1lBVweA40lMeIW9LhaxA=; b=Ua7jMMuzUm7VGQakuAnFWkG8avfbyZ+eGUDHOcktpXtxc3twXpzTxF33 iBalLT7jmaFkoG3oiW7RzjZfMoXYbAjS6JB05hdWh285uSHM/85Me2tTv JW8NTtTUfWoAlg/ZCfvAfmP1GR1mWRujjPeYNAI8vUsyTsMaESs/Oak0h I=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAFhOcVKtJV2a/2dsb2JhbABZgweBDL9UgScWdIIlAQEBAwF5BQsCAQgYCiQCMCUCBA4FCAYGh20GunWOFoEIFhsHgx+BDQOQLYEwmDaBaIE+gXE5
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="p7s'?scan'208,217";a="278630330"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2013 18:22:48 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIMl8M024441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:22:47 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:22:47 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: Max Jonas Werner 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1Z0Imf9gXRoQT1qWOAYOe51tPQ==
Date: Wed, 30 Oct 2013 18:22:46 +0000
Message-ID: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>  <52712BE4.5040003@makk.es>
In-Reply-To: <52712BE4.5040003@makk.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.234.135]
Content-Type: multipart/signed; boundary="Apple-Mail=_546F2AF4-A793-4FF7-9A5F-4769267E201D"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:22:56 -0000

--Apple-Mail=_546F2AF4-A793-4FF7-9A5F-4769267E201D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D6C83E41-437C-43A2-8BCE-761D3ADD248F"


--Apple-Mail=_D6C83E41-437C-43A2-8BCE-761D3ADD248F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I think questions like these will be answered and satisfied under the =
framework set up so that "Development and maintenance will be overseen =
by a board from industry and the open source community."



On Oct 30, 2013, at 11:55 AM, Max Jonas Werner  wrote:

> On 30.10.2013 16:52, Ethan Hugg wrote:
>> Lorenzo,
>>=20
>> You will be able to inspect the source yourself for nefarious things =
like
>> tracking as the code will be freely available.
>=20
> This implies there exists a way to verify that the code under review =
is
> actually the exact same code used to compile the binary which is not
> trivial IIRC.
>=20
> Max
>=20


--Apple-Mail=_D6C83E41-437C-43A2-8BCE-761D3ADD248F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I =
think questions like these will be answered and satisfied under the =
framework set up so that "Development and maintenance will be overseen by a board =
from industry and the open source community."






On Oct 30, 2013, at 11:55 AM, Max Jonas Werner <mail@makk.es> wrote:

On =
30.10.2013 16:52, Ethan Hugg wrote:
Lorenzo,

You will be able to inspect the source =
yourself for nefarious things like
tracking as the code will be =
freely available.

This implies there exists a way to =
verify that the code under review is
actually the exact same code =
used to compile the binary which is not
trivial =
IIRC.

Max


=

--Apple-Mail=_D6C83E41-437C-43A2-8BCE-761D3ADD248F--

--Apple-Mail=_546F2AF4-A793-4FF7-9A5F-4769267E201D
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTAzMDE4MjI0NlowIwYJKoZIhvcNAQkEMRYEFFaJRcyZDdRPioXXx7rBZNmPmanz
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEApL13LKx1YX1iPXdt7Q/xvmPgBeEL
rNNiucHEV7G9/Dhrj+piiM9q1kSLDTQtW4KW0NHSfXrtjvieDPtOjm6IcEQvNffqTbY86Py6xSPR
wGMuq+y0pbKscQpL9vpSMm8OHhYhM+5Ln1kZWSTRt+/zI+LWqzi595QyqioNBN9PD3ZKZP0T2+q7
DHGUwVN5qmht3W69d1stPGcgALUaWAHTrRQbN5GqgRLLxGba+HfkXFd8WvgxNya1ylaSGZBeVYkw
ho5KZovFhceNXTcOuUTrgEV5PCHYkYHICkNKOICoBqmvRkY9koneu5rmkFc74FJtdzvyNhmg0AYi
rgdiMLnBFgAAAAAAAA==

--Apple-Mail=_546F2AF4-A793-4FF7-9A5F-4769267E201D--

From fluffy@cisco.com  Wed Oct 30 11:24:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4043511E8160 for ; Wed, 30 Oct 2013 11:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.578
X-Spam-Level: 
X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuA853TflPdX for ; Wed, 30 Oct 2013 11:24:17 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 053C421F9F23 for ; Wed, 30 Oct 2013 11:24:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=998; q=dns/txt; s=iport; t=1383157454; x=1384367054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fOAsVx/k4R5ASyDl2PkC1vHG+Ssl+Qc/QchV8NeBrTk=; b=cv80khZu3pNUQHnx+6oiXn2QZfa2LEszTnrXf9YCnme4UJwFP1QTgtAg 5+nA623786ZWP+K+KlDBJeBZT51RBL8RZ4Oo9Ra8fmYkXGUpP7dno0w4R iOsbNh41ZXS2TrsLOdJDsThx5NaSwJYwuVgqkjCHBTOkuRMFpRCemXbaC A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAFhOcVKtJXHA/2dsb2JhbABZgweBDL9UgScWdIIlAQEBAwF5BQsCAQgOCgokMiUCBA4FCId5Brp1jxwCMQeDH4ENA4kHoQyBaIE+gWgHOw
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600"; d="scan'208";a="278630852"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2013 18:24:01 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIO1Ji013936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:24:01 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:24:01 -0500
From: "Cullen Jennings (fluffy)" 
To: Matt Fredrickson 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1ZKFmf9gXRoQT1qWOAYOe51tPZoN4xQA
Date: Wed, 30 Oct 2013 18:24:00 +0000
Message-ID: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <31BB9217558211489073BFE21C4095B6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:24:23 -0000

On Oct 30, 2013, at 11:07 AM, Matt Fredrickson 
 wrote:

> On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy)  wrote:
>=20
> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote:
>=20
> > That is only as long as the binary versions don't have any additions or=
 changes for such things.  Nothing says that the binary modules cannot be b=
uilt in this way.
>=20
> The binary module will be build that way.
>=20
> All the build scripts etc that Cisco uses will be part of the open source=
 project so that anyone can build it them selves and check that their build=
 matches the Cisco binary and check the code does not have backdoors to sen=
d all your video to the NSA.
>=20
> :-)
>=20
> Sorry, wasn't implying as such, but it's good to be reassured.  Thanks ag=
ain for the response.

No apology needed, I did not think you were implying as much. I was just lo=
oking for an excuse to say that :-)=20


From jlaurens@cisco.com  Wed Oct 30 11:27:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7089011E8160 for ; Wed, 30 Oct 2013 11:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfXPIQtVtUqk for ; Wed, 30 Oct 2013 11:27:20 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D668921F9F23 for ; Wed, 30 Oct 2013 11:27:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12246; q=dns/txt; s=iport; t=1383157640; x=1384367240; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=g/UJHrfgxSzJuX+AYv30NaAYiVF4gaqwslkJSwkhqxw=; b=R8uFPm+i4BrqGiY7VhAmTN+8JA71Qfbil2j2eSSps4QdR4hxRwtyFnlh nT01ncxPbtvMPeAR0BJixPjfZWzBxFYU5O3ur+/F14zxvFItNP1DF7vLd LNvY2kRPD2aSw5W8PInaIhEixmjhWk286O2YdpKYscP90Aw1NRpEWraJF k=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFACFOcVKtJV2b/2dsb2JhbABZgwc4VL8JS4EnFnSCJQEBAQMBAQEBawsFCwIBCBgKJAIlCyUCBA4FCAaHcwYNumMEjx4WGweDH4ENA5AtgTCYNoMmgio
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="p7s'?scan'208,217";a="278639744"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 30 Oct 2013 18:27:07 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIR6D2032740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:27:07 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:27:06 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: Matthew Kaufman 
Thread-Topic: [rtcweb] VP8 vs H.264 - the core issue
Thread-Index: AQHO1Z2jxT4El2I6hESqrgdop2l1XQ==
Date: Wed, 30 Oct 2013 18:27:06 +0000
Message-ID: 
References: <52681A96.2020904@alvestrand.no>	<52713962.3010201@matthew.at>  <52714498.1090401@matthew.at>
In-Reply-To: <52714498.1090401@matthew.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.234.135]
Content-Type: multipart/signed; boundary="Apple-Mail=_855C223F-299A-4230-AA37-7C0B5C8D97E9"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:27:26 -0000

--Apple-Mail=_855C223F-299A-4230-AA37-7C0B5C8D97E9
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0969AB4A-6AE2-4B1F-9D3E-2B1DD6625533"


--Apple-Mail=_0969AB4A-6AE2-4B1F-9D3E-2B1DD6625533
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1


On Oct 30, 2013, at 1:40 PM, Matthew Kaufman  wrote:

> On 10/30/2013 10:07 AM, Jack Moffitt wrote:
>>>> Do we switch now, or do we give up and live with royalties forever?
>>> This is a little dramatic. One can trivially prove that every =
technology
>>> required to implement H.264 will lose the protection of the patent =
system in
>>> a finite period of time. Much, much sooner than "forever".
>> Selection of royalty-required codecs sets a precedent.
>>=20
>> jack.
>=20
> Prove that VP8 isn't such a thing, and we'd have a clear decision to =
make.
>=20
> Matthew Kaufman
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_0969AB4A-6AE2-4B1F-9D3E-2B1DD6625533
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

+1







On Oct 30, 2013, at 1:40 PM, Matthew Kaufman =
<matthew@matthew.at> =
wrote:

On 10/30/2013 10:07 AM, Jack Moffitt wrote:
Do we =
switch now, or do we give up and live with royalties =
forever?
This is a little dramatic. One can trivially =
prove that every technology
required to implement H.264 will lose the =
protection of the patent system in
a finite period of time. Much, =
much sooner than "forever".
Selection of =
royalty-required codecs sets a =
precedent.

jack.

Prove that VP8 isn't such a =
thing, and we'd have a clear decision to make.

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

=

--Apple-Mail=_0969AB4A-6AE2-4B1F-9D3E-2B1DD6625533--

--Apple-Mail=_855C223F-299A-4230-AA37-7C0B5C8D97E9
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTAzMDE4MjcwNFowIwYJKoZIhvcNAQkEMRYEFE3+evjeRWNn/JB8on8XtYStmtx6
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAHbdZ6GekoD5tCbI9tMf8laKjnFdK
mfQwkNUAD3/YgTf10CV9Y1uCkAdhYe+96CTRs6f5xQhfq+55El9l1br5X1BsaGIdqC8xMdLRwzh7
kGQLVMsgpPzxxDMgrHoV4dTISqe6tsn+0dEVeZqlbfW1IWWX8Vlm8Hc4GAwraFpMkmtmuQVAQhEL
eXftivilrQy6BiEq7bK5idLhepDJrCgg9EIi57o3+DmiqlIhKDoZ37HtmCNz1RJ+BoOnY3xTGqoE
Y8NmS/oSMu6uERj8OmaYyiSNo0CCGE2m8Oy+q1A+5+07TErkJAK2h7+rq920g9R7V0h17zpWoKjy
fBm9ljFtjwAAAAAAAA==

--Apple-Mail=_855C223F-299A-4230-AA37-7C0B5C8D97E9--

From jlaurens@cisco.com  Wed Oct 30 11:30:49 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9111E8182 for ; Wed, 30 Oct 2013 11:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.465
X-Spam-Level: 
X-Spam-Status: No, score=-9.465 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Coz6+k+o2uZb for ; Wed, 30 Oct 2013 11:30:44 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7511E8181 for ; Wed, 30 Oct 2013 11:30:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17150; q=dns/txt; s=iport; t=1383157844; x=1384367444; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZBEebiUmwaQLTOxylwpAHVF1wSHuNXCtlbKBVd5xDeM=; b=dvZ4d1U65yJkZs2w6RHZ30XoAz3u2MfWgZIV2Pwo8gtrL4Cw5bxksbnu 3FjQbS11rk2huzSDaexE5vTfw8f3UNJ2txazezSC+hX8rhhFAedJ/leVB KTtvHgSZ/VCb16L+KmXchGEaYJJ3+o1qjW1jkNoS5kNCvAQK7wuZf//D0 E=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnwGAAZPcVKtJXG//2dsb2JhbABWA4MHOE4GtweIAkuBJxZ0giUBAQEDAQEBAWsLBQsCAQgOCgokAh8GCyUCBA4FCAYNh1oDCQYIBbBxDYlrjF+CPxYLDAQHEYMOgQ0DkC2BMIRCgxqLIwOFNIE7gWuCKg
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="p7s'?scan'208,217";a="278627170"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 30 Oct 2013 18:30:44 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIUh99009263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:30:43 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:30:43 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: Leon Geyser 
Thread-Topic: [rtcweb] On the topic of MTI video codecs
Thread-Index: AQHO1Z4jKQxeI4sckkKmXOLHp/+Z/g==
Date: Wed, 30 Oct 2013 18:30:42 +0000
Message-ID: 
References: <527147FF.5010506@nostrum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.234.135]
Content-Type: multipart/signed; boundary="Apple-Mail=_70C13BA3-5231-4D54-A600-1C72F6672465"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:30:49 -0000

--Apple-Mail=_70C13BA3-5231-4D54-A600-1C72F6672465
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4AD85770-2395-49DA-A64D-63007571632E"


--Apple-Mail=_4AD85770-2395-49DA-A64D-63007571632E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

" As long as there are ports of the source code and automatic build =
scripts contributed as part of the open source, we do not see =
difficulties in adding additional platforms."

	Jeremy Laurenson
Distinguished Systems Engineer
Global UCC Strategy Group
+1 408 894-1349
Video chat now.    	Join my bridge    	Or find more contact =
options...=20
http://cs.co/jlaurens	http://cs.co/jlaurensbridge=20
Business relevant Unified Communications use cases...



On Oct 30, 2013, at 2:20 PM, Leon Geyser  wrote:

> Unfortunately like Jonathan pointed out H.264 will only be able to be =
used royalty free on certain(most popular) platforms.
> To be able to avoid negotiation failure we need a MTI codec that every =
potential now/future browser would be able to implement freely.
> I like what Cisco did, but the solution seems a bit half-baked.
>=20
> On 30 October 2013 19:55, Adam Roach  wrote:
> As Jonathan mentioned earlier, this morning Cisco announced that it =
will be open sourcing an H.264 implementation as well as gratis binary =
modules compiled from that source and hosted by Cisco for download. =
Mozilla will be modifying Firefox to support H.264 by downloading =
Cisco's binary module.
>=20
> In previous discussions of which codec should be MTI, Mozilla has =
stated that it could not accept H.264 as MTI, primarily because we could =
not deliver H.264 in Firefox. That obstacle is now removed, and we can =
accept either codec as MTI.
>=20
> Mozilla intends to continue supporting VP8 in WebRTC, but we will also =
support H.264.
>=20
> /a
> _______________________________________________
> 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=_4AD85770-2395-49DA-A64D-63007571632E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

" As long as there are ports of the source code and automatic =
build scripts contributed as part of the open source, we do not see =
difficulties in adding additional platforms."



<=
font color=3D"BLACK" face=3D"CENTURY GOTHIC" size=3D"2">Jeremy =
Laurenson
Distinguished Systems Engineer
Global UCC Strategy =
Group
+1 408 =
894-1349
Video chat =
now.    Join my =
bridge    Or find more =
contact options... 
http://cs.co/jlaurenshttp://cs.co/jlaurensbridge 
Business relevant =
Unified Communications use =
cases...






On Oct 30, 2013, at 2:20 PM, Leon Geyser <lgeyser@gmail.com> =
wrote:

Unfortunately like Jonathan =
pointed out H.264 will only be able to be used royalty free on =
certain(most popular) platforms.
To be able to avoid negotiation =
failure we need a MTI codec that every potential now/future browser =
would be able to implement freely.


I like what Cisco did, but the solution seems a bit =
half-baked.

On 30 October 2013 19:55, Adam Roach <adam@nostrum.com> wrote:


As Jonathan mentioned =
earlier, this morning Cisco announced that it will be open sourcing an =
H.264 implementation as well as gratis binary modules compiled from that =
source and hosted by Cisco for download. Mozilla will be modifying =
Firefox to support H.264 by downloading Cisco's binary module.




In previous discussions of which codec should be MTI, Mozilla has stated =
that it could not accept H.264 as MTI, primarily because we could not =
deliver H.264 in Firefox. That obstacle is now removed, and we can =
accept either codec as MTI.




Mozilla intends to continue supporting VP8 in WebRTC, but we will also =
support H.264.



/a

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb<=
br>



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

=

--Apple-Mail=_4AD85770-2395-49DA-A64D-63007571632E--

--Apple-Mail=_70C13BA3-5231-4D54-A600-1C72F6672465
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTAzMDE4MzA0MFowIwYJKoZIhvcNAQkEMRYEFDpF5wap+BHf9edp8pEByIsaiaU7
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAAu1OIIjC88JmFoinUAIXLxlRDVUb
h2v8U5IsGs1941JIgYZjP0lXZvLMfOOtdtvUiLDIBXln7WY7aVPoM6n9Yf3Xfh7VDWgUx5hD4CrD
UNmX5qvJwpQmw9JKXOSnrnkXdkKrV6scedERbNcdcyFeq2g7hcY5g1tE7O6e9KOAFVG2WnZhaRAp
0zoOJKgphthIBjxOkxjsk19JCbyizwtCoIx4zhfmSaWNIlC+SEmQDujbWld3xILl95hUi6yKWu8U
FFKS4XXFCKNpapz3l+ALSpTPfMNqtLWyBCJMG3ME5qwtDTa455zO0I3QV8ZhsyVXEBRP4S4eWHBE
cMeP1XalswAAAAAAAA==

--Apple-Mail=_70C13BA3-5231-4D54-A600-1C72F6672465--

From adam@nostrum.com  Wed Oct 30 11:30:55 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0694A21E814B for ; Wed, 30 Oct 2013 11:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.157
X-Spam-Level: 
X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYUrpvfUh7pa for ; Wed, 30 Oct 2013 11:30:54 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8C911E8192 for ; Wed, 30 Oct 2013 11:30:53 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9UIUkNU028065 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 13:30:47 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52715051.1090206@nostrum.com>
Date: Wed, 30 Oct 2013 13:30:41 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Leon Geyser 
References: <527147FF.5010506@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:30:55 -0000

On 10/30/13 13:20, Leon Geyser wrote:
> Unfortunately like Jonathan pointed out H.264 will only be able to be 
> used royalty free on certain(most popular) platforms.
> To be able to avoid negotiation failure we need a MTI codec that every 
> potential now/future browser would be able to implement freely.

Fortunately, as I pointed out in an earlier message, the stated 
intention of Cisco's project is to support as many platforms as the 
development community is willing to work on. In light of that fact: is 
there a specific existing and viable platform that you think cannot 
support H.264 already *and* cannot use the OpenH264 library?

If not, can you tell a credible story about how such a platform might arise?

/a

From jlaurens@cisco.com  Wed Oct 30 11:33:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA4321E812F for ; Wed, 30 Oct 2013 11:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.465
X-Spam-Level: 
X-Spam-Status: No, score=-9.465 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0WJNT-ehPy9 for ; Wed, 30 Oct 2013 11:33:49 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D7D8F11E818B for ; Wed, 30 Oct 2013 11:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8757; q=dns/txt; s=iport; t=1383158025; x=1384367625; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AyJCz8IK9o7MJfBDYtvyBPuCzwnVsqagw5NUIHtZgLw=; b=DGLwDfDy3qW/Ff3WJy4B0bWLhKOi5Oy5ilmS5ersCODkoptr0Q1O50lh BgRZu7PBILv0QzBOZBnml4TV2CsaZzJzswSa5SA/bXYIvw4Im+Yn6lD1L Zqh/s8zf0EtHGWje94kSn+5ZDmdt6DVS3Qmi6esEaGSQfTLZap4RZi2hD A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAKtQcVKtJV2d/2dsb2JhbABZgwc4VL8JS4EnFnSCJgEBBAEBAWsLEAIBCA4UHQchBgsUEQIEDgUIE4daAw8NsHQNiWcEjF+CPy0EB4MfgQ0Dlh+OPYU3gTuBa4Iq
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="scan'208,217";a="278634747"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2013 18:33:45 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIXjsB025617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:33:45 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:33:45 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: Leon Geyser 
Thread-Topic: [rtcweb] On the topic of MTI video codecs
Thread-Index: AQHO1Z6QKQxeI4sckkKmXOLHp/+Z/g==
Date: Wed, 30 Oct 2013 18:33:44 +0000
Message-ID: 
References: <527147FF.5010506@nostrum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.254.104]
Content-Type: multipart/alternative; boundary="_000_FCBEDCB500188C488DA30C874B94F80E1C018E19xmbrcdx03ciscoc_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:33:54 -0000

--_000_FCBEDCB500188C488DA30C874B94F80E1C018E19xmbrcdx03ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

" As long as there are ports of the source code and automatic build scripts=
 contributed as part of the open source, we do not see difficulties in addi=
ng additional platforms."






On Oct 30, 2013, at 2:20 PM, Leon Geyser > wrote:

Unfortunately like Jonathan pointed out H.264 will only be able to be used =
royalty free on certain(most popular) platforms.
To be able to avoid negotiation failure we need a MTI codec that every pote=
ntial now/future browser would be able to implement freely.
I like what Cisco did, but the solution seems a bit half-baked.

On 30 October 2013 19:55, Adam Roach > wrote:
As Jonathan mentioned earlier, this morning Cisco announced that it will be=
 open sourcing an H.264 implementation as well as gratis binary modules com=
piled from that source and hosted by Cisco for download. Mozilla will be mo=
difying Firefox to support H.264 by downloading Cisco's binary module.

In previous discussions of which codec should be MTI, Mozilla has stated th=
at it could not accept H.264 as MTI, primarily because we could not deliver=
 H.264 in Firefox. That obstacle is now removed, and we can accept either c=
odec as MTI.

Mozilla intends to continue supporting VP8 in WebRTC, but we will also supp=
ort H.264.

/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


--_000_FCBEDCB500188C488DA30C874B94F80E1C018E19xmbrcdx03ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <50B5D4F65DA24841A610B6DD57797FC5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable






" As long as there are ports of the source code and automatic b=
uild scripts contributed as part of the open source, we do not see difficul=
ties in adding additional platforms."





































In previous discussions of which codec should be MTI, Mozilla has stated th=
at it could not accept H.264 as MTI, primarily because we could not deliver=
 H.264 in Firefox. That obstacle is now removed, and we can accept either c=
odec as MTI.


Mozilla intends to continue supporting VP8 in WebRTC, but we will also supp=
ort H.264.


/a

_______________________________________________

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







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.o=
rg/mailman/listinfo/rtcweb









--_000_FCBEDCB500188C488DA30C874B94F80E1C018E19xmbrcdx03ciscoc_--

From jlaurens@cisco.com  Wed Oct 30 11:34:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB321E815A for ; Wed, 30 Oct 2013 11:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.899
X-Spam-Level: 
X-Spam-Status: No, score=-8.899 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChvrMtSDP2yE for ; Wed, 30 Oct 2013 11:33:54 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5362721E8088 for ; Wed, 30 Oct 2013 11:33:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12798; q=dns/txt; s=iport; t=1383158026; x=1384367626; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4OQdFod/tC0PMhbpVohIm2IKg/Y32KYtxdL6iIsur3A=; b=Dk+f/U4MNNOAh8edWSBfuCHMliCByGgD6HWuF0993XhNsA6xUVvtoIjc 6fGUrQMTlEuvfoX8LThZLONXIXewzAXIzumU+t+PGMDmn0bDNNY5JcMSc tuAEW99TXQiMZO4kK2Edlsvh062C/ZjNtrchUHVo6RdSzo3/udG0zxUnn o=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAKtQcVKtJV2d/2dsb2JhbABZgwc4VL8JS4EnFnSCJQEBAQMBAQEBawsFCwIBCA4KCiQCHwYLJQIEDgUIBg2HWgMJBg2wdA2JZwSMX4I/LQQHgx+BDQOQLYEwhEKOPYU3gTuBa4Iq
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="p7s'?scan'208,217";a="278642343"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 30 Oct 2013 18:33:45 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIXj87025622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:33:45 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:33:45 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: Leon Geyser 
Thread-Topic: [rtcweb] On the topic of MTI video codecs
Thread-Index: AQHO1Z6QKQxeI4sckkKmXOLHp/+Z/g==
Date: Wed, 30 Oct 2013 18:33:44 +0000
Message-ID: 
References: <527147FF.5010506@nostrum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.254.104]
Content-Type: multipart/signed; boundary="Apple-Mail=_2A660EFB-E107-407E-BBC9-D8D7E2170CAA"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:34:00 -0000

--Apple-Mail=_2A660EFB-E107-407E-BBC9-D8D7E2170CAA
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8ADC3277-6088-403F-B50C-E5F582F6F65E"


--Apple-Mail=_8ADC3277-6088-403F-B50C-E5F582F6F65E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


" As long as there are ports of the source code and automatic build =
scripts contributed as part of the open source, we do not see =
difficulties in adding additional platforms."

Contribute away...


On Oct 30, 2013, at 2:20 PM, Leon Geyser  wrote:

> Unfortunately like Jonathan pointed out H.264 will only be able to be =
used royalty free on certain(most popular) platforms.
> To be able to avoid negotiation failure we need a MTI codec that every =
potential now/future browser would be able to implement freely.
> I like what Cisco did, but the solution seems a bit half-baked.
>=20
> On 30 October 2013 19:55, Adam Roach  wrote:
> As Jonathan mentioned earlier, this morning Cisco announced that it =
will be open sourcing an H.264 implementation as well as gratis binary =
modules compiled from that source and hosted by Cisco for download. =
Mozilla will be modifying Firefox to support H.264 by downloading =
Cisco's binary module.
>=20
> In previous discussions of which codec should be MTI, Mozilla has =
stated that it could not accept H.264 as MTI, primarily because we could =
not deliver H.264 in Firefox. That obstacle is now removed, and we can =
accept either codec as MTI.
>=20
> Mozilla intends to continue supporting VP8 in WebRTC, but we will also =
support H.264.
>=20
> /a
> _______________________________________________
> 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=_8ADC3277-6088-403F-B50C-E5F582F6F65E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


" As long as there are ports of =
the source code and automatic build scripts contributed as part of the =
open source, we do not see difficulties in adding additional =
platforms."

Contribute away...


On Oct 30, 2013, at 2:20 PM, Leon Geyser <lgeyser@gmail.com> =
wrote:

Unfortunately like Jonathan =
pointed out H.264 will only be able to be used royalty free on =
certain(most popular) platforms.
To be able to avoid negotiation =
failure we need a MTI codec that every potential now/future browser =
would be able to implement freely.


I like what Cisco did, but the solution seems a bit =
half-baked.

On 30 October 2013 19:55, Adam Roach <adam@nostrum.com> wrote:


As Jonathan mentioned =
earlier, this morning Cisco announced that it will be open sourcing an =
H.264 implementation as well as gratis binary modules compiled from that =
source and hosted by Cisco for download. Mozilla will be modifying =
Firefox to support H.264 by downloading Cisco's binary module.




In previous discussions of which codec should be MTI, Mozilla has stated =
that it could not accept H.264 as MTI, primarily because we could not =
deliver H.264 in Firefox. That obstacle is now removed, and we can =
accept either codec as MTI.




Mozilla intends to continue supporting VP8 in WebRTC, but we will also =
support H.264.



/a

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb<=
br>



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

=

--Apple-Mail=_8ADC3277-6088-403F-B50C-E5F582F6F65E--

--Apple-Mail=_2A660EFB-E107-407E-BBC9-D8D7E2170CAA
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTAzMDE4MzI0OFowIwYJKoZIhvcNAQkEMRYEFLJtY/0+IKn0iJnh/WXojd4H7PkO
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAW64FwOUCvi0SM9jvcP4V1JWQtUx6
teMdTHf6I015Fa2H/y2ULBSeDU9tp0/GUOIiNDUA99CuzWQDBjDIHM7QZ4mo5B6Gnb7oIaIw9jfs
7e2jBrZAo/1SQUnPGzvDechPYJsashdUQmHu0xyFe0Q51+T6pHIObX3+UnfMHqORqSAz6HuY64HX
CZADGeIivERCodjTIPdXBBM6e8hKRWEouhUss400CocgqDBBBvnHOTN656yV/Bs+5JMnb5cVmr7B
VVivZ1HoykrDGjeCaMcnHiwloWjUpFRtAJXcWARPAPOmMtTN1f1IuDEa6wI2pssmkcue5qzt/ctJ
ktXzwy2sygAAAAAAAA==

--Apple-Mail=_2A660EFB-E107-407E-BBC9-D8D7E2170CAA--

From goran.ap.eriksson@ericsson.com  Wed Oct 30 11:46:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3448911E826B for ; Wed, 30 Oct 2013 11:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQzhnWv5kIfP for ; Wed, 30 Oct 2013 11:46:05 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id ED71611E8240 for ; Wed, 30 Oct 2013 11:44:18 -0700 (PDT)
X-AuditID: c1b4fb38-b7f178e00000233b-64-5271537f44b3
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 61.85.09019.F7351725; Wed, 30 Oct 2013 19:44:15 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 30 Oct 2013 19:44:14 +0100
From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= 
To: "Cullen Jennings (fluffy)" 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1YZ+mf9gXRoQT1qWOAYOe51tPZoNUs0AgAABYACAAADfgIAABhIAgAAOHACAABVdAIAAFmtE
Date: Wed, 30 Oct 2013 18:44:14 +0000
Message-ID: <5E38FE0B-E47F-4F33-AF13-54C08408F9EC@ericsson.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>    , 
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: sv-SE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+JvjW59cGGQwdsHIhY/181ntOiYzGax /OAVZou1/9rZHVg8pvzeyOpxoXsZk8eSJT+ZApijuGxSUnMyy1KL9O0SuDI2Xj3BVrCTu2LW pagGxgmcXYycHBICJhJnF69jhbDFJC7cW8/WxcjFISRwhFFiVttfJghnCaPE7g8TWUCq2AS8 JaatOAvWISJgKNG0Zx5YEbNAC6PElCUbGUESwgLpErcPrmCCKMqQeHt0NhuEHSUxccEaMJtF QFXiy7wudhCbV8Be4mjTIhaIbc1sEtNffGbuYuTg4BTwlVgxFWwxo4CsxP3v98BsZgFxic9z HzBBnC0gsWTPeWYIW1Ti5eN/rBA1ehI3pk5hg7C1JZYtfM0MsUtQ4uTMJywTGEVnIRk1C0nL LCQts5C0LGBkWcXIUZxanJSbbmSwiREYKwe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MPZqpbjpp7G6J/2xra3wv7TGJDS62MfY8W3AM5bPdmV+03td dnkcXrNso7Qhl8TVle6CKq8V8p4F6GbUOsrEX2l5vH7u++rLYtZmx8X6ywr9ay5YhBgWLZzv /umku13c2bNxK6+I/zv3Oew2c/neCvfz6gU7VDcFFgh3WG9a0rC86N7LvOvVSizFGYmGWsxF xYkA2X3+UmMCAAA=
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:46:10 -0000

30 okt 2013 kl. 19:24 skrev "Cullen Jennings (fluffy)" :

>=20
> On Oct 30, 2013, at 11:07 AM, Matt Fredrickson 
> wrote:
>=20
>> On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy)  wrote:
>>=20
>> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote=
:
>>=20
>>> That is only as long as the binary versions don't have any additions or=
 changes for such things.  Nothing says that the binary modules cannot be b=
uilt in this way.
>>=20
>> The binary module will be build that way.
>>=20
>> All the build scripts etc that Cisco uses will be part of the open sourc=
e project so that anyone can build it them selves and check that their buil=
d matches the Cisco binary and check the code does not have backdoors to se=
nd all your video to the NSA.
>>=20
>> :-)
>>=20
>> Sorry, wasn't implying as such, but it's good to be reassured.  Thanks a=
gain for the response.
>=20
> No apology needed, I did not think you were implying as much. I was just =
looking for an excuse to say that :-)=20

Noted and appreciated. Concerns about this need to be taken seriously and I=
 foresee us discussing this in more detail in the future, together with the=
 relevant W3C groups.=20

Regards
G=F6ran



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

From jlaurens@cisco.com  Wed Oct 30 11:46:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9952621E8165 for ; Wed, 30 Oct 2013 11:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.315
X-Spam-Level: 
X-Spam-Status: No, score=-10.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM8r13DifvON for ; Wed, 30 Oct 2013 11:46:11 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B10D211E8160 for ; Wed, 30 Oct 2013 11:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18028; q=dns/txt; s=iport; t=1383158658; x=1384368258; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FZwCDKLEahnLT4ifoJsaTUnLSi80mKoIJ+kYZO006f4=; b=Vqhw7oQTP6Cj566pf0omxZkDXJDJQUZO9fX2B+SjCRzvIxkyDhQxvrKB YwvDd6VBGenroZUIKBaFvbXoBOxEHG8FEbz/ouv74VTxhioKymVES3yEi aF3Rass70EPoBuOxq/SP470GcT3nPju/Fj3ohawWA00uZyvYOlseVwffO E=;
X-Files: smime.p7s : 4459
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFANpScVKtJV2a/2dsb2JhbABZgkNEOFS/CUuBJxZ0giUBAQEDAQEBAWsLBQsCAQgOCgokAh8GCyUCBA4FCAaHZwMJBg2wdA2JZwSMX4I/FhcEB4MfgQ0DkC2BMIRCjj2FN4FogT6BaAc7
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="p7s'?scan'208,217";a="278638905"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2013 18:44:09 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIi9Cc022694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 18:44:09 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:44:08 -0500
From: "Jeremy Laurenson (jlaurens)" 
To: Steve Sokol 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1XYAmf9gXRoQT1qWOAYOe51tPQ==
Date: Wed, 30 Oct 2013 18:44:08 +0000
Message-ID: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.254.104]
Content-Type: multipart/signed; boundary="Apple-Mail=_88E10742-EE33-4E6C-B5B0-7F8F2B1ED8AF"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 18:46:18 -0000

--Apple-Mail=_88E10742-EE33-4E6C-B5B0-7F8F2B1ED8AF
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_491735C4-B5D9-477B-B40A-4916E2DC5878"


--Apple-Mail=_491735C4-B5D9-477B-B40A-4916E2DC5878
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

+1

I suppose from a WebRTC platform support perspective, the gods at Apple =
could easily adopt WebRTC in Safari and deliver their own =
hardware-accelerated .264 implementation. Developers could surface that =
in a UIWebView, although I have not noodled what types of additional =
hooks may be needed.

Ultimately this falls into the Apple bucket.
=20

On Oct 30, 2013, at 12:42 PM, Steve Sokol  wrote:

> Jonathan and Fluffy,
>=20
> In regards to Apple's restriction on the installation of binary =
modules the prevents iOS from being included in the list of supported =
platforms: what precludes Cisco from offering a binary static library =
built for iOS? If it's because the licensing terms you've struck with =
MPEG LA require you count downloads, could you offer an iOS version that =
simply does a one-time "phone-home" to cover the count requirement? The =
phone-home call could be anonymous and unique (hash of MAC or similar). =
Not necessarily ideal from a privacy perspective, but better than =
leaving a large, affluent and vocal part of the digital ecosystem out.
>=20
>=20
>=20
> On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy) =
 wrote:
>=20
> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  =
wrote:
>=20
> > That is only as long as the binary versions don't have any additions =
or changes for such things.  Nothing says that the binary modules cannot =
be built in this way.
>=20
> The binary module will be build that way.
>=20
> All the build scripts etc that Cisco uses will be part of the open =
source project so that anyone can build it them selves and check that =
their build matches the Cisco binary and check the code does not have =
backdoors to send all your video to the NSA.
>=20
>=20
> >
> > Matthew Fredrickson
> >
> >
> > On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg  =
wrote:
> >
> > Lorenzo,
> >
> > You will be able to inspect the source yourself for nefarious things =
like tracking as the code will be freely available.
> >
> > -EH
> >
> >
> >
> > On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero =
 wrote:
> > Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> > Adam Roach  ha scritto:
> >
> > > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > > Does this mean that system information (for systems that this is
> > > > installed on) may be tracked and sent back to the Cisco servers =
for
> > > > accurate license usage count?  (ethernet MAC address, or some =
other
> > > > system specific info) so that redownloads of modules on the same
> > > > system are not counted towards your license usage accounting?
> > >
> > > My understanding is that MPEG-LA has a per-organization royalty =
cap
> > > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches =
that
> > > cap quite easily with their own products.
> > >
> > > /a
> >
> >
> > Which doesn't preclude the fact the module may do tracking anyway.
> >
> > Lorenzo
> >
> >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
>=20
> --=20
> 
> Steven Sokol
> Digium, Inc. =B7 Director of Strategic Programs
> 445 Jan Davis Drive NW =B7 Huntsville, AL 35806 =B7 US
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_491735C4-B5D9-477B-B40A-4916E2DC5878
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

+1

I suppose from a WebRTC =
platform support perspective, the gods at Apple could easily adopt =
WebRTC in Safari and deliver their own hardware-accelerated .264 =
implementation. Developers could surface that in a UIWebView, although I =
have not noodled what types of additional hooks may be =
needed.

Ultimately this falls into the Apple =
bucket.
 



On Oct 30, 2013, at 12:42 PM, Steve Sokol <ssokol@digium.com> =
wrote:

Jonathan and =
Fluffy,

In regards to Apple's restriction on the =
installation of binary modules the prevents iOS from being included in =
the list of supported platforms: what precludes Cisco from offering a =
binary static library built for iOS? If it's because the licensing terms =
you've struck with MPEG LA require you count downloads, could you offer =
an iOS version that simply does a one-time "phone-home" to cover the =
count requirement? The phone-home call could be anonymous and unique =
(hash of MAC or similar). Not necessarily ideal from a privacy =
perspective, but better than leaving a large, affluent and vocal part of =
the digital ecosystem out.





On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings =
(fluffy) <fluffy@cisco.com> wrote:




On Oct 30, 2013, at 9:55 AM, Matt Fredrickson <creslin@digium.com> wrote:



> That is only as long as the binary versions don't have any =
additions or changes for such things.  Nothing says that the binary =
modules cannot be built in this way.




The binary module will be build that way.



All the build scripts etc that Cisco uses will be part of the open =
source project so that anyone can build it them selves and check that =
their build matches the Cisco binary and check the code does not have =
backdoors to send all your video to the NSA.







>

> Matthew Fredrickson

>

>

> On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg <ethanhugg@gmail.com> =
wrote:

>

> Lorenzo,

>

> You will be able to inspect the source yourself for nefarious =
things like tracking as the code will be freely available.

>

> -EH

>

>

>

> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> =
wrote:

> Il giorno Wed, 30 Oct 2013 10:41:27 -0500

> Adam Roach <adam@nostrum.com> ha =
scritto:

>

> > On 10/30/13 10:20, Matt Fredrickson wrote:

> > > Does this mean that system information (for systems that =
this is

> > > installed on) may be tracked and sent back to the Cisco =
servers for

> > > accurate license usage count?  (ethernet MAC =
address, or some other

> > > system specific info) so that redownloads of modules on =
the same

> > > system are not counted towards your license usage =
accounting?

> >

> > My understanding is that MPEG-LA has a per-organization =
royalty cap

> > for H.264 (13 MUSD, if my memory serves), and that Cisco =
reaches that

> > cap quite easily with their own products.

> >

> > /a

>

>

> Which doesn't preclude the fact the module may do tracking =
anyway.

>

> Lorenzo

>

>

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.org

> > https://www.ietf.org/mailman/listinfo/rtcweb

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb





-- =

<digium_RGB_signature.gif>

Steven =
Sokol
Digium, =
Inc. =B7 Director of Strategic Programs

445 Jan Davis Drive NW =B7 Huntsville, AL =
35806 =B7 US



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

=

--Apple-Mail=_491735C4-B5D9-477B-B40A-4916E2DC5878--

--Apple-Mail=_88E10742-EE33-4E6C-B5B0-7F8F2B1ED8AF
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw
ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug
b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ
BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50
ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD
Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi
VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey
xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/
xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28
ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB
o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS
MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo
dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB
8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu
IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb
dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4
e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po
mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9
5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4
OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi
dE0HbYQwggb/MIIF56ADAgECAhBMB51Pnvlk8cSmNt8H9SnjMA0GCSqGSIb3DQEBBQUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu
dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE
AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzEw
MTEwMDAwMDBaFw0xNDEwMTIyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQgLSAxMzgxNDg5MjU3Mzg2MSEwHwYJKoZIhvcNAQkBFhJqbGF1cmVuc0BjaXNjby5jb20xDzAN
BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT
eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/+Nq7kMnqR6fQzT7AdPZqAFXEHu2WpnwBLsyXj
TZLjXzU4sk37efasq1jwJ6bhYarwFOnnM32PAtmEjWsWYrVC/yerrjDiQetD+ja7mEidL/SrOKNt
9oVnOO8SNdOYeFwydzx/mIFlQXLWA3DOj+xxHkonk9Zvz6kU4aOMC9eodawruobR5rBwn7dybplc
e9m3BbDpIIKDIhkNjXQw8nesBtpwj40wIMsdPKh+YauCZW1mhh3LCAbU8JnJ9ruDKO6w+9EEFeFA
6F3DFqaHAnNdQj/bPVulnYpDqhNjOZqrp4677+fnCmWpHMqla0KuB6ujLY6rwc2T1ocpeT+zfb8C
AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU6AbcYQIy/DM74yCnYa/NhoUDAbowHQYDVR0R
BBYwFIESamxhdXJlbnNAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB
MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku
dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs
JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90
JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy
QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1
dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww
bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1
dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg
hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw
KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA
A4IBAQCaq/WPMAj7VTYbcIaIj4ejrezJkEdvtM7qG49B8Q/FG1nDEkyeQ6me9VcYMauVoP92PzB9
f9jaHRUPFPJ5O/HIZ3OrK4B9Ejc6zMO20Nlbf0hAX+9vJfOfz8iVYyfY0/7pO1bw2W/2u0S+KLL+
nocRFuDLiKaaKNeXaXb9spxSUer97n3oT862+cSWfbMHv4x1GeHAyRyWZfkHi2USNbetMaJ87uxy
drfB/tkaik47F+0O6bSk5bGO/qklOHtdAiZvWyqzODKRTmtSeY7WjvhWkQaUKNjMuVZP7KIGJXUn
UJoycIMIHCOBX+WMKDPjSib+FchE77R5wPJE3lUTnScgMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV
BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg
VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSm
Nt8H9SnjMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEzMTAzMDE4NDQwOFowIwYJKoZIhvcNAQkEMRYEFEZsFmhPS2K906ZgtRiYC28ArxxS
MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD
b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy
c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg
U3Vic2NyaWJlciBDQSAtIEc0AhBMB51Pnvlk8cSmNt8H9SnjMIHOBgsqhkiG9w0BCRACCzGBvqCB
uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL
ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx
NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC
EEwHnU+e+WTxxKY23wf1KeMwDQYJKoZIhvcNAQEBBQAEggEAg01eiZckuqnSEqtoFeMtD6ER7IvG
bXbuhaYJRTwq/WOqfyqqlvWG2leSoP7TypNUVXR/YgF4Y/a8BVfpgL5k2YWfqfkEqUuUokjXh5Ir
IWV4Gl6v0/S9o80fgRpdX4URwCiDuMshKc9loZlIP6QNCER/e4QFzwHCsohhcil79Og/NBHJg1Nb
zT6x1j7H9+vjxdIcUSMo53R347XKOo1tpcW5Pkb02yb2arXcqn7aQZlIk7VV6C1urE7bFHkhZz3p
vGisjMoHe/2mF99fnyWRiIB/9D3dhofAOnSw0GwioJIHbBUMN+sPFnDfZ98uS3l/B/qdCfDj2T7e
tVP0D6uq5wAAAAAAAA==

--Apple-Mail=_88E10742-EE33-4E6C-B5B0-7F8F2B1ED8AF--

From lgeyser@gmail.com  Wed Oct 30 12:09:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAA521F9E3F for ; Wed, 30 Oct 2013 12:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.06
X-Spam-Level: 
X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=-0.061,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2MIRGhTJG7L for ; Wed, 30 Oct 2013 12:09:36 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 213C111E826B for ; Wed, 30 Oct 2013 12:09:04 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id w6so1622011lbh.27 for ; Wed, 30 Oct 2013 12:08:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/+PygL4fahvDci58Dr7pKgCi7X8b72XLVLPcv5Fb8R4=; b=Qs1743cb2p6eA5kBfszfaiJ8NPR8iUyIqt6ICFt7pZ7Cr0UMSwwZ59TEISDUUtRTlA ZoZSjwC4GbUgRG4h4kUOfA0dLTQ0cVoE6t1Qg2SmH3gfvPjOpx/ANOx4BiBNmbikIIbl YVLeikf+8lfan9CrEbg+H5J8g9kycHDnHNAfrFIdQFT6Uub/c7URUidZXnwUtIwYyNMC DWhM431AZkRH/ZOF3vMk0FR0Rg+VagJHbkDho0lHObkThfrvLUkXDSvFm+PYoQ2PJF7y 1n/70V99M2izpS1toV/r6jmkLJDsLBKARGfr2TphxFTEg9Al/FurklzqXijZDX7tkKWJ v5CQ==
MIME-Version: 1.0
X-Received: by 10.152.26.72 with SMTP id j8mr4200732lag.19.1383160134283; Wed, 30 Oct 2013 12:08:54 -0700 (PDT)
Received: by 10.114.168.70 with HTTP; Wed, 30 Oct 2013 12:08:54 -0700 (PDT)
In-Reply-To: <52715051.1090206@nostrum.com>
References: <527147FF.5010506@nostrum.com>  <52715051.1090206@nostrum.com>
Date: Wed, 30 Oct 2013 21:08:54 +0200
Message-ID: 
From: Leon Geyser 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=089e0160c36e78b52104e9fa1027
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 19:09:37 -0000

--089e0160c36e78b52104e9fa1027
Content-Type: text/plain; charset=ISO-8859-1

http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.media.capture.audiovideocapturedevice.supportedvideoencodingformats%28v=vs.105%29.aspx
Playback of H.264 should be supported on all Windows Phones, but encoding
looks like it is device specific.
It may or may not return H.264, but in reality most Windows Phones probably
do support it. I am not sure.
I don't think it would be possible to download and use the Cisco library
though.

The future is uncertain. I have no idea if new platforms will popup without
H.264 support.


On 30 October 2013 20:30, Adam Roach  wrote:

> On 10/30/13 13:20, Leon Geyser wrote:
>
>> Unfortunately like Jonathan pointed out H.264 will only be able to be
>> used royalty free on certain(most popular) platforms.
>> To be able to avoid negotiation failure we need a MTI codec that every
>> potential now/future browser would be able to implement freely.
>>
>
> Fortunately, as I pointed out in an earlier message, the stated intention
> of Cisco's project is to support as many platforms as the development
> community is willing to work on. In light of that fact: is there a specific
> existing and viable platform that you think cannot support H.264 already
> *and* cannot use the OpenH264 library?
>
> If not, can you tell a credible story about how such a platform might
> arise?
>
> /a
>

--089e0160c36e78b52104e9fa1027
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Playback of H.264 should be supported on all Windows Phones, but=
 encoding looks like it is device specific.
It may or may not retu=
rn H.264, but in reality most Windows Phones probably do support it. I am n=
ot sure.


I don't think it would be possible to download and use the C=
isco library though.

The future is uncertain. I have no i=
dea if new platforms will popup without H.264 support.



On 30 October 2013 20:30, Adam Roach <ad=
am@nostrum.com> wrote:


On 10/30/13 13:20, Leon Geyser wrote:



Unfortunately like Jonathan pointed out H.264 will only be able to be used =
royalty free on certain(most popular) platforms.

To be able to avoid negotiation failure we need a MTI codec that every pote=
ntial now/future browser would be able to implement freely.





Fortunately, as I pointed out in an earlier message, the stated intention o=
f Cisco's project is to support as many platforms as the development co=
mmunity is willing to work on. In light of that fact: is there a specific e=
xisting and viable platform that you think cannot support H.264 already *an=
d* cannot use the OpenH264 library?




If not, can you tell a credible story about how such a platform might arise=
?



/a





--089e0160c36e78b52104e9fa1027--

From lorenzo@meetecho.com  Wed Oct 30 12:17:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDF321E8088 for ; Wed, 30 Oct 2013 12:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXnTOJYrgbHv for ; Wed, 30 Oct 2013 12:17:22 -0700 (PDT)
Received: from smtpdg5.aruba.it (smtpdg223.aruba.it [62.149.158.223]) by ietfa.amsl.com (Postfix) with ESMTP id 254F521E815F for ; Wed, 30 Oct 2013 12:16:59 -0700 (PDT)
Received: from lminiero ([82.49.174.20]) by smtpcmd02.ad.aruba.it with bizsmtp id jXGr1m00v0SmHqA01XGrwt; Wed, 30 Oct 2013 20:16:51 +0100
Date: Wed, 30 Oct 2013 20:16:51 +0100
From: Lorenzo Miniero 
To: "Jonathan Rosenberg (jdrosen)" 
Message-ID: <20131030201651.79401531@lminiero>
In-Reply-To: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.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=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 19:17:27 -0000

Il giorno Wed, 30 Oct 2013 12:28:50 +0000
"Jonathan Rosenberg (jdrosen)"  ha scritto:

> I'd like to make an announcement material to the conversations around
> MTI video codecs in rtcweb.
> 
> Cisco is announcing today that we will take our H.264 implementation,
> and open source it under BSD license terms. Development and
> maintenance will be overseen by a board from industry and the open
> source community.  Furthermore, we will provide a binary form
> suitable for inclusion in applications across a number of different
> operating systems (Windows, MacOS, Linux x86, Linux ARM and Android
> ARM), and make this binary module available for download from the
> Internet. We will not pass on our MPEG-LA licensing costs for this
> module, and based on the current licensing environment, this will
> effectively make H.264 free for use on supported platforms.
> 
> We believe that this contribution to the community can help address
> the concerns many have raised around selection of H.264 as MTI. I
> firmly believe that with H.264 we can achieve maximal
> interoperability and now, do it with open source and for free (well,
> at least for others - its not free for Cisco :)) More information on
> the open source project can be found at http://www.openh264.org,
> which is sparse now but more coming soon.
> 
> 
> Thx,
> Jonathan R.
> 
> --
> Jonathan Rosenberg, PhD
> VP, CTO Collaboration
> Cisco Systems
> jdrosen@cisco.com
> 


Am I really the only one not that enthusiastic about this?

Don't get me wrong, I appreciated Cisco's statement. I just don't think
it changes anything. It doesn't make H.264 more open (or less closed,
if you prefer) than it was before. It just says that, if you download
their module from them when installing your stuff, your applications
can use it to encode/decode H.264 and not worry about fees (hoping with
your fingers crossed that the platform is supported, that is). I still
cannot use x264, ffmpeg, randomsuperawesomeopensourceH264codec or even
a version of Cisco's H.264 code I compile myself: at least, not if I
don't want (or just can't afford) to pay license fees, that is. Which
means we're back to step one again. Under those premises, I still think
it's not MTI material.

The problem is, I don't want to rely on Cisco's generosity[*] (or
anyone else's, for that matter) to work with video, especially when
we're building an (allegedly) open web communication framework. What if
their module sucks? I'm sure it won't, but I still don't have any
choice, there are no free alternatives. Besides, we have no assurance
at all that this is something we can rely on. If Cisco wakes up in a
couple of months and decides it's all not worth it and shuts all of
this down, what happens to WebRTC implementations, to companies that
decided to depend on it, to their clients/customers? We wait for
another generous "mecenate", while big companies thrive? We complain on
social networks? We cry at the moon?  And this is not such a remote
possibility: after all (and I'm quoting one of Jonathan's latest tweets
here), "We cannot say forever but unless things change we will continue
this indefinitely". If this is supposed to convince me H.264 is now the
best solution as MTI for WebRTC then, especially as a developer, I'm
not convinced.

I see this opening more as the (welcome, no denying that) software
equivalent of daddy pinching you on the cheek and giving you a coupon
for your "free ice cream (for a while)". Everyone loves free stuff, I
do as well. But IMHO it's not more than that, a free gift to convince
the unconvinced. Ancient Romans would have called this "Panem et
Circenses", and according to all the enthusiastic posts on Twitter and
the like, I guess it still works: people are entertained.

Make the codec REALLY free, without any license fee required at all,
and then you'll entertain me as well.

Lorenzo


[*] I must shamefully admit I sniggered a bit when I read the "it's not
free for Cisco" part, as if you were really paying for this. I have
trouble thinking Cisco doesn't already pay the infamous cap every year.
You're doing something you really don't have to (and we really
appreciate this, make no mistake), but that's not the same thing.

From adam@nostrum.com  Wed Oct 30 12:17:58 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76521E8179 for ; Wed, 30 Oct 2013 12:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level: 
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR77drIKRksH for ; Wed, 30 Oct 2013 12:17:58 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB621E8151 for ; Wed, 30 Oct 2013 12:17:16 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9UJHBum029976 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 14:17:12 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52715B32.6010404@nostrum.com>
Date: Wed, 30 Oct 2013 14:17:06 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Leon Geyser 
References: <527147FF.5010506@nostrum.com>		<52715051.1090206@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 19:17:58 -0000

On 10/30/13 14:08, Leon Geyser wrote:
> http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.media.capture.audiovideocapturedevice.supportedvideoencodingformats%28v=vs.105%29.aspx
> Playback of H.264 should be supported on all Windows Phones, but 
> encoding looks like it is device specific.
> It may or may not return H.264, but in reality most Windows Phones 
> probably do support it. I am not sure.

Given that Microsoft has been pushing pretty hard to make H.264 the 
WebRTC MTi video codec, I doubt they would neglect to support it in 
their own platform.

> I don't think it would be possible to download and use the Cisco 
> library though.

I don't know why you'd want to. Native platform support is probably 
hardware accelerated.

> The future is uncertain. I have no idea if new platforms will popup 
> without H.264 support.

I didn't ask you to predict whether one would. What I asked for was 
much, much easier. What I asked for was a non-laughable story around how 
such a platform might arise in a way that precludes using the Cisco library.

/a

From stpeter@stpeter.im  Wed Oct 30 12:19:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7006021E8088 for ; Wed, 30 Oct 2013 12:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.044
X-Spam-Level: 
X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NikRPV+0urGf for ; Wed, 30 Oct 2013 12:19:09 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 80A8221E8106 for ; Wed, 30 Oct 2013 12:19:04 -0700 (PDT)
Received: from ergon.local (unknown [64.101.72.104]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A287B4010C; Wed, 30 Oct 2013 13:19:03 -0600 (MDT)
Message-ID: <52715BA6.9070608@stpeter.im>
Date: Wed, 30 Oct 2013 13:19:02 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Leon Geyser , Adam Roach 
References: <527147FF.5010506@nostrum.com>		<52715051.1090206@nostrum.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 19:19:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/13 1:08 PM, Leon Geyser wrote:

> The future is uncertain.

This we can all agree on.

The codecs we have today won't last forever, and new codecs will be
developed and deployed. H.264 matters for immediate interoperability,
but we simply can't know what will enable interoperability 5 or 10 or
15 years from now. Presumably an update to the relevant RFC will need
to happen at that point. Assuming that, in the uncertain future, the
IETF and W3C still exist. ;-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJScVumAAoJEOoGpJErxa2pY+MQAJHqYpzqT/sbVbrJzOHnv2tB
lBzspA+DGQOMKUZS/p3NqCOEhhdChq2GsO4K4CwdRJxETwA3sEO204rt3xZcddOc
PWObmeTI2Z9EDXzwLS/BMDpS0hrBeCSZoZ+6JP6cbDI+lLYTMnhYB/9WtFa6T6Ws
S3iWiZlPrEu5KOKVKls6RYtyjdFx/Wbyfq+Oh/ZW826PS5w+Ullp9D9qyIviPhaw
q+K4L9MR28m63ufQXPlsbeBqLtZRkQZOmnHvZQfiCkPyqMhIcqniR9i1kRL8+wOh
ga7ztQKyu1cUKsFYacFZU44hsJAF8tzhGXLm/83/5X+ffM12nMpTg8ZEDQ+HXJ+G
sqvBxgGu0Yl7ErgXxH06kD3W/GKhjNQEYMowMiP6Kop8DrQyH1noqNkt/0DV6dEs
jn8iPjBfXemq8W1anV7ffA7Y0JLjotrTNKdP+O5EIrVFw1Q0hPl744C28phBPvtu
lJRsJ2/HiLvQsrTQf7rRZcf111DodKHJTvzJcGlE33pEUlXwxAPVWqBvwmIWLCal
6PlZ+5cF2fS5x+K3R+71OMc0LxWDzzla3gA4mRbjWm7253VhRo2QdPVT8aO1giP2
cbodgo1lTQ1sZtoKbG9tTi4xxX58IBP84OyoPgJdI8IilVehr5ILwniuKuggqU/B
f+hTRtDlTZxkJTQb+9Cz
=+szN
-----END PGP SIGNATURE-----

From fluffy@cisco.com  Wed Oct 30 12:51:18 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4762721E8164 for ; Wed, 30 Oct 2013 12:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.579
X-Spam-Level: 
X-Spam-Status: No, score=-110.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPYdJeKXoBOl for ; Wed, 30 Oct 2013 12:51:12 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 55F6221E8155 for ; Wed, 30 Oct 2013 12:51:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=547; q=dns/txt; s=iport; t=1383162665; x=1384372265; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fyph27KSogP06cL+b6hN3nSghNscjzi6szFC6wukvvw=; b=V+mwAxyWYR3pXfA+k2cbCIvSKWLn2c+r9pG8ATTWGIHne+GMhO6hs7yI CQbqQiU10+LSZKXf8sL99LjlVwT/VLzTGSTco5OSGkj67zmQD9+hL+XFW 6C3QrhyaV+z1PP90nMFuStQdT5++h5PnGQla4a7IhyZm6+QV0KKAJCR4h A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAEVicVKtJXG8/2dsb2JhbABZgweBDL9UgSgWdIImAQEEOj8QAgEIIhQQMiUCBA4FCId/unGPHAIxB4MfgQ0DqhOBaIE+gio
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600"; d="scan'208";a="278665967"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2013 19:51:05 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9UJp4NA017923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 19:51:04 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 14:51:04 -0500
From: "Cullen Jennings (fluffy)" 
To: Lorenzo Miniero 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1aldmf9gXRoQT1qWOAYOe51tPQ==
Date: Wed, 30 Oct 2013 19:51:03 +0000
Message-ID: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <20131030201651.79401531@lminiero>
In-Reply-To: <20131030201651.79401531@lminiero>
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
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 19:51:18 -0000

On Oct 30, 2013, at 1:16 PM, Lorenzo Miniero  wrote:

> [*] I must shamefully admit I sniggered a bit when I read the "it's not
> free for Cisco" part, as if you were really paying for this. I have
> trouble thinking Cisco doesn't already pay the infamous cap every year.

I'm not going to provide numbers but I will say just for the record that Ci=
sco does not even come close to paying the cap right now. I also realize th=
at compared to Cisco overall budget, the MEPG LA cap is a very small percen=
tage.=20





From keith.drage@alcatel-lucent.com  Wed Oct 30 13:10:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3321F9E68 for ; Wed, 30 Oct 2013 13:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.528
X-Spam-Level: 
X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRK9QHpzFn+m for ; Wed, 30 Oct 2013 13:09:42 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5821F9E2B for ; Wed, 30 Oct 2013 13:09:41 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9UK9c5x003816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Oct 2013 15:09:39 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r9UK9beS032159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 21:09:37 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 30 Oct 2013 21:09:37 +0100
From: "DRAGE, Keith (Keith)" 
To: Lorenzo Miniero , "Jonathan Rosenberg (jdrosen)" 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1aSWmf9gXRoQT1qWOAYOe51tPZoNqXyQ
Date: Wed, 30 Oct 2013 20:09:36 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C4743@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <20131030201651.79401531@lminiero>
In-Reply-To: <20131030201651.79401531@lminiero>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 20:10:01 -0000

But to work with VP8 you are also relying on Google's generosity.=20

Google have IPR on VP8; you are relying on a statement from them they will =
continue to offer it royalty free.=20

Google and Cisco are both reputable organisations, but ultimately you trust=
 who you trust, and I don't see that being different whichever path you fol=
low.

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Lorenzo Miniero
> Sent: 30 October 2013 19:17
> To: Jonathan Rosenberg (jdrosen)
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Cisco to open source its H.264=20
> implementation and absorb MPEG-LA licensing fees
>=20
> Il giorno Wed, 30 Oct 2013 12:28:50 +0000 "Jonathan Rosenberg=20
> (jdrosen)"  ha scritto:
>=20
> > I'd like to make an announcement material to the=20
> conversations around=20
> > MTI video codecs in rtcweb.
> >=20
> > Cisco is announcing today that we will take our H.264=20
> implementation,=20
> > and open source it under BSD license terms. Development and=20
> > maintenance will be overseen by a board from industry and the open=20
> > source community.  Furthermore, we will provide a binary=20
> form suitable=20
> > for inclusion in applications across a number of different=20
> operating=20
> > systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and=20
> > make this binary module available for download from the=20
> Internet. We=20
> > will not pass on our MPEG-LA licensing costs for this module, and=20
> > based on the current licensing environment, this will=20
> effectively make=20
> > H.264 free for use on supported platforms.
> >=20
> > We believe that this contribution to the community can help address=20
> > the concerns many have raised around selection of H.264 as MTI. I=20
> > firmly believe that with H.264 we can achieve maximal=20
> interoperability=20
> > and now, do it with open source and for free (well, at least for=20
> > others - its not free for Cisco :)) More information on the open=20
> > source project can be found at http://www.openh264.org, which is=20
> > sparse now but more coming soon.
> >=20
> >=20
> > Thx,
> > Jonathan R.
> >=20
> > --
> > Jonathan Rosenberg, PhD
> > VP, CTO Collaboration
> > Cisco Systems
> > jdrosen@cisco.com
> >=20
>=20
>=20
> Am I really the only one not that enthusiastic about this?
>=20
> Don't get me wrong, I appreciated Cisco's statement. I just=20
> don't think it changes anything. It doesn't make H.264 more=20
> open (or less closed, if you prefer) than it was before. It=20
> just says that, if you download their module from them when=20
> installing your stuff, your applications can use it to=20
> encode/decode H.264 and not worry about fees (hoping with=20
> your fingers crossed that the platform is supported, that=20
> is). I still cannot use x264, ffmpeg,=20
> randomsuperawesomeopensourceH264codec or even a version of=20
> Cisco's H.264 code I compile myself: at least, not if I don't=20
> want (or just can't afford) to pay license fees, that is.=20
> Which means we're back to step one again. Under those=20
> premises, I still think it's not MTI material.
>=20
> The problem is, I don't want to rely on Cisco's generosity[*]=20
> (or anyone else's, for that matter) to work with video,=20
> especially when we're building an (allegedly) open web=20
> communication framework. What if their module sucks? I'm sure=20
> it won't, but I still don't have any choice, there are no=20
> free alternatives. Besides, we have no assurance at all that=20
> this is something we can rely on. If Cisco wakes up in a=20
> couple of months and decides it's all not worth it and shuts=20
> all of this down, what happens to WebRTC implementations, to=20
> companies that decided to depend on it, to their=20
> clients/customers? We wait for another generous "mecenate",=20
> while big companies thrive? We complain on social networks?=20
> We cry at the moon?  And this is not such a remote
> possibility: after all (and I'm quoting one of Jonathan's=20
> latest tweets here), "We cannot say forever but unless things=20
> change we will continue this indefinitely". If this is=20
> supposed to convince me H.264 is now the best solution as MTI=20
> for WebRTC then, especially as a developer, I'm not convinced.
>=20
> I see this opening more as the (welcome, no denying that)=20
> software equivalent of daddy pinching you on the cheek and=20
> giving you a coupon for your "free ice cream (for a while)".=20
> Everyone loves free stuff, I do as well. But IMHO it's not=20
> more than that, a free gift to convince the unconvinced.=20
> Ancient Romans would have called this "Panem et Circenses",=20
> and according to all the enthusiastic posts on Twitter and=20
> the like, I guess it still works: people are entertained.
>=20
> Make the codec REALLY free, without any license fee required=20
> at all, and then you'll entertain me as well.
>=20
> Lorenzo
>=20
>=20
> [*] I must shamefully admit I sniggered a bit when I read the=20
> "it's not free for Cisco" part, as if you were really paying=20
> for this. I have trouble thinking Cisco doesn't already pay=20
> the infamous cap every year.
> You're doing something you really don't have to (and we=20
> really appreciate this, make no mistake), but that's not the=20
> same thing.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From cowwoc@bbs.darktech.org  Wed Oct 30 13:33:59 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884C421E80A9 for ; Wed, 30 Oct 2013 13:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.189
X-Spam-Level: 
X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=-1.591, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7xkgesaqGiI for ; Wed, 30 Oct 2013 13:33:55 -0700 (PDT)
Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by ietfa.amsl.com (Postfix) with ESMTP id A0C3711E8191 for ; Wed, 30 Oct 2013 13:33:51 -0700 (PDT)
Received: by mail-yh0-f48.google.com with SMTP id f64so838829yha.35 for ; Wed, 30 Oct 2013 13:33:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=jgt2Ekrt0GBe9B9AVjFZYludJjQapdk73KyimQgrGt0=; b=fAdbRZvAzrONzTwdFeFxn0o3M3Q3xscPfeQcifZ/zzbOnOjrRM4Nzlg4V3bC2OspB2 VJJPfPMEJhrKelnMYdsaTcJ4YYeuY3kDXzKvln8Bcf4gYViUIjUUE0rv/fwQCkUOAaMk uG/RWy2XniXeosaARr0Fqotay3ul3tYPnF9/0eZ/NnyaHyHkiRIq9KX35oRoPIgE61mm KZ5/s0+AiVOa5+TxGNnOR1s9W6Cy/dZ08NGFRCaD+8q3srkMyIOmzvx3DSgm8UfXL+LK COrDs7Tb6PnctAnNcwzuEJgWIUkcOpWx7t9UBtFmuoUbA557EBtaiWG/2c80hyegADoz PpKg==
X-Gm-Message-State: ALoCoQmbTefZ0rZZ+1KM4kKu3LJ19Qam3g36eO/nGQBYwadjV7jhGM6PX/+UyNnuULFhzb3eOVva
X-Received: by 10.236.17.34 with SMTP id i22mr105656yhi.110.1383165230158; Wed, 30 Oct 2013 13:33:50 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id s46sm49759180yha.27.2013.10.30.13.33.48 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Oct 2013 13:33:49 -0700 (PDT)
Message-ID: <52716D29.6050403@bbs.darktech.org>
Date: Wed, 30 Oct 2013 16:33:45 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>	<20131030201651.79401531@lminiero> <949EF20990823C4C85C18D59AA11AD8B0C4743@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0C4743@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------040705080406000705090205"
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 20:33:59 -0000

This is a multi-part message in MIME format.
--------------040705080406000705090205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


     While I appreciate Cisco's huge contribution in this area, Lorenzo 
and Keith bring up some good points.

     How about this approach?

  * Mandate both codecs as MTI
  * If either codec becomes problematic (requiring us to pay royalties)
    we simply drop that codec as MTI (implementation becomes optional)
    and searching for a replacement to add as MTI. In the meantime, we
    have that other codec to fall back on.

     With this approach we no longer have to depend on the generosity of 
Cisco or Google, and it reduces the incentive of patent trolls (it's 
harder to squeeze us for royalties when we have a fallback).

Gili

On 30/10/2013 4:09 PM, DRAGE, Keith (Keith) wrote:
> But to work with VP8 you are also relying on Google's generosity.
>
> Google have IPR on VP8; you are relying on a statement from them they will continue to offer it royalty free.
>
> Google and Cisco are both reputable organisations, but ultimately you trust who you trust, and I don't see that being different whichever path you follow.
>
> Keith
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Lorenzo Miniero
>> Sent: 30 October 2013 19:17
>> To: Jonathan Rosenberg (jdrosen)
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Cisco to open source its H.264
>> implementation and absorb MPEG-LA licensing fees
>>
>> Il giorno Wed, 30 Oct 2013 12:28:50 +0000 "Jonathan Rosenberg
>> (jdrosen)"  ha scritto:
>>
>>> I'd like to make an announcement material to the
>> conversations around
>>> MTI video codecs in rtcweb.
>>>
>>> Cisco is announcing today that we will take our H.264
>> implementation,
>>> and open source it under BSD license terms. Development and
>>> maintenance will be overseen by a board from industry and the open
>>> source community.  Furthermore, we will provide a binary
>> form suitable
>>> for inclusion in applications across a number of different
>> operating
>>> systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and
>>> make this binary module available for download from the
>> Internet. We
>>> will not pass on our MPEG-LA licensing costs for this module, and
>>> based on the current licensing environment, this will
>> effectively make
>>> H.264 free for use on supported platforms.
>>>
>>> We believe that this contribution to the community can help address
>>> the concerns many have raised around selection of H.264 as MTI. I
>>> firmly believe that with H.264 we can achieve maximal
>> interoperability
>>> and now, do it with open source and for free (well, at least for
>>> others - its not free for Cisco :)) More information on the open
>>> source project can be found at http://www.openh264.org, which is
>>> sparse now but more coming soon.
>>>
>>>
>>> Thx,
>>> Jonathan R.
>>>
>>> --
>>> Jonathan Rosenberg, PhD
>>> VP, CTO Collaboration
>>> Cisco Systems
>>> jdrosen@cisco.com
>>>
>>
>> Am I really the only one not that enthusiastic about this?
>>
>> Don't get me wrong, I appreciated Cisco's statement. I just
>> don't think it changes anything. It doesn't make H.264 more
>> open (or less closed, if you prefer) than it was before. It
>> just says that, if you download their module from them when
>> installing your stuff, your applications can use it to
>> encode/decode H.264 and not worry about fees (hoping with
>> your fingers crossed that the platform is supported, that
>> is). I still cannot use x264, ffmpeg,
>> randomsuperawesomeopensourceH264codec or even a version of
>> Cisco's H.264 code I compile myself: at least, not if I don't
>> want (or just can't afford) to pay license fees, that is.
>> Which means we're back to step one again. Under those
>> premises, I still think it's not MTI material.
>>
>> The problem is, I don't want to rely on Cisco's generosity[*]
>> (or anyone else's, for that matter) to work with video,
>> especially when we're building an (allegedly) open web
>> communication framework. What if their module sucks? I'm sure
>> it won't, but I still don't have any choice, there are no
>> free alternatives. Besides, we have no assurance at all that
>> this is something we can rely on. If Cisco wakes up in a
>> couple of months and decides it's all not worth it and shuts
>> all of this down, what happens to WebRTC implementations, to
>> companies that decided to depend on it, to their
>> clients/customers? We wait for another generous "mecenate",
>> while big companies thrive? We complain on social networks?
>> We cry at the moon?  And this is not such a remote
>> possibility: after all (and I'm quoting one of Jonathan's
>> latest tweets here), "We cannot say forever but unless things
>> change we will continue this indefinitely". If this is
>> supposed to convince me H.264 is now the best solution as MTI
>> for WebRTC then, especially as a developer, I'm not convinced.
>>
>> I see this opening more as the (welcome, no denying that)
>> software equivalent of daddy pinching you on the cheek and
>> giving you a coupon for your "free ice cream (for a while)".
>> Everyone loves free stuff, I do as well. But IMHO it's not
>> more than that, a free gift to convince the unconvinced.
>> Ancient Romans would have called this "Panem et Circenses",
>> and according to all the enthusiastic posts on Twitter and
>> the like, I guess it still works: people are entertained.
>>
>> Make the codec REALLY free, without any license fee required
>> at all, and then you'll entertain me as well.
>>
>> Lorenzo
>>
>>
>> [*] I must shamefully admit I sniggered a bit when I read the
>> "it's not free for Cisco" part, as if you were really paying
>> for this. I have trouble thinking Cisco doesn't already pay
>> the infamous cap every year.
>> You're doing something you really don't have to (and we
>> really appreciate this, make no mistake), but that's not the
>> same thing.
>> _______________________________________________
>> 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


--------------040705080406000705090205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    


          While I appreciate Cisco's huge contribution in this area,
      Lorenzo and Keith bring up some good points.

      

          How about this approach?

      
    
        
  • Mandate both codecs as MTI
    • 
        
  • If either codec becomes problematic (requiring us to pay
          royalties) we simply drop that codec as MTI (implementation
          becomes optional) and searching for a replacement to add as
          MTI. In the meantime, we have that other codec to fall back
          on.
    
        
    • 
      

          With this approach we no longer have to depend on the
      generosity of Cisco or Google, and it reduces the incentive of
      patent trolls (it's harder to squeeze us for royalties when we
      have a fallback).

      

      Gili

      

      On 30/10/2013 4:09 PM, DRAGE, Keith (Keith) wrote:

    

    

      
But to work with VP8 you are also relying on Google's generosity. 

Google have IPR on VP8; you are relying on a statement from them they will continue to offer it royalty free. 

Google and Cisco are both reputable organisations, but ultimately you trust who you trust, and I don't see that being different whichever path you follow.

Keith



      

        
-----Original Message-----
From: rtcweb-bounces@ietf.org 
[mailto:rtcweb-bounces@ietf.org] On Behalf Of Lorenzo Miniero
Sent: 30 October 2013 19:17
To: Jonathan Rosenberg (jdrosen)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Cisco to open source its H.264 
implementation and absorb MPEG-LA licensing fees

Il giorno Wed, 30 Oct 2013 12:28:50 +0000 "Jonathan Rosenberg 
(jdrosen)" <jdrosen@cisco.com> ha scritto:



        

          
I'd like to make an announcement material to the 


        

        
conversations around 


        

          
MTI video codecs in rtcweb.

Cisco is announcing today that we will take our H.264 


        

        
implementation, 


        

          
and open source it under BSD license terms. Development and 
maintenance will be overseen by a board from industry and the open 
source community.  Furthermore, we will provide a binary 


        

        
form suitable 


        

          
for inclusion in applications across a number of different 


        

        
operating 


        

          
systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and 
make this binary module available for download from the 


        

        
Internet. We 


        

          
will not pass on our MPEG-LA licensing costs for this module, and 
based on the current licensing environment, this will 


        

        
effectively make 


        

          
H.264 free for use on supported platforms.

We believe that this contribution to the community can help address 
the concerns many have raised around selection of H.264 as MTI. I 
firmly believe that with H.264 we can achieve maximal 


        

        
interoperability 


        

          
and now, do it with open source and for free (well, at least for 
others - its not free for Cisco :)) More information on the open 
source project can be found at http://www.openh264.org, which is 
sparse now but more coming soon.


Thx,
Jonathan R.

--
Jonathan Rosenberg, PhD
VP, CTO Collaboration
Cisco Systems
jdrosen@cisco.com



        

        

Am I really the only one not that enthusiastic about this?

Don't get me wrong, I appreciated Cisco's statement. I just 
don't think it changes anything. It doesn't make H.264 more 
open (or less closed, if you prefer) than it was before. It 
just says that, if you download their module from them when 
installing your stuff, your applications can use it to 
encode/decode H.264 and not worry about fees (hoping with 
your fingers crossed that the platform is supported, that 
is). I still cannot use x264, ffmpeg, 
randomsuperawesomeopensourceH264codec or even a version of 
Cisco's H.264 code I compile myself: at least, not if I don't 
want (or just can't afford) to pay license fees, that is. 
Which means we're back to step one again. Under those 
premises, I still think it's not MTI material.

The problem is, I don't want to rely on Cisco's generosity[*] 
(or anyone else's, for that matter) to work with video, 
especially when we're building an (allegedly) open web 
communication framework. What if their module sucks? I'm sure 
it won't, but I still don't have any choice, there are no 
free alternatives. Besides, we have no assurance at all that 
this is something we can rely on. If Cisco wakes up in a 
couple of months and decides it's all not worth it and shuts 
all of this down, what happens to WebRTC implementations, to 
companies that decided to depend on it, to their 
clients/customers? We wait for another generous "mecenate", 
while big companies thrive? We complain on social networks? 
We cry at the moon?  And this is not such a remote
possibility: after all (and I'm quoting one of Jonathan's 
latest tweets here), "We cannot say forever but unless things 
change we will continue this indefinitely". If this is 
supposed to convince me H.264 is now the best solution as MTI 
for WebRTC then, especially as a developer, I'm not convinced.

I see this opening more as the (welcome, no denying that) 
software equivalent of daddy pinching you on the cheek and 
giving you a coupon for your "free ice cream (for a while)". 
Everyone loves free stuff, I do as well. But IMHO it's not 
more than that, a free gift to convince the unconvinced. 
Ancient Romans would have called this "Panem et Circenses", 
and according to all the enthusiastic posts on Twitter and 
the like, I guess it still works: people are entertained.

Make the codec REALLY free, without any license fee required 
at all, and then you'll entertain me as well.

Lorenzo


[*] I must shamefully admit I sniggered a bit when I read the 
"it's not free for Cisco" part, as if you were really paying 
for this. I have trouble thinking Cisco doesn't already pay 
the infamous cap every year.
You're doing something you really don't have to (and we 
really appreciate this, make no mistake), but that's not the 
same thing.
_______________________________________________
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


    

    

  


--------------040705080406000705090205--

From lorenzo@meetecho.com  Wed Oct 30 13:43:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA8611E8263 for ; Wed, 30 Oct 2013 13:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMwTv-iNvu45 for ; Wed, 30 Oct 2013 13:43:25 -0700 (PDT)
Received: from smtpdg6.aruba.it (smtpdg2.aruba.it [62.149.158.232]) by ietfa.amsl.com (Postfix) with ESMTP id 594ED11E8143 for ; Wed, 30 Oct 2013 13:43:21 -0700 (PDT)
Received: from rainpc ([82.49.174.20]) by smtpcmd02.ad.aruba.it with bizsmtp id jYjK1m0040SmHqA01YjKl4; Wed, 30 Oct 2013 21:43:19 +0100
Date: Wed, 30 Oct 2013 21:43:18 +0100
From: Lorenzo Miniero 
To: "DRAGE, Keith (Keith)" 
Message-ID: <20131030214318.7ec23c9e@rainpc>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0C4743@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <20131030201651.79401531@lminiero> <949EF20990823C4C85C18D59AA11AD8B0C4743@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 20:43:29 -0000

On Wed, 30 Oct 2013 20:09:36 +0000
"DRAGE, Keith (Keith)"  wrote:

> But to work with VP8 you are also relying on Google's generosity. 
> 
> Google have IPR on VP8; you are relying on a statement from them they will continue to offer it royalty free. 
> 
> Google and Cisco are both reputable organisations, but ultimately you trust who you trust, and I don't see that being different whichever path you follow.
> 
> Keith
> 


True, but that "royalty free" makes all the difference in the world. I can make my own ice cream, if I want (and there's people doing this).

Lorenzo



> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org 
> > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Lorenzo Miniero
> > Sent: 30 October 2013 19:17
> > To: Jonathan Rosenberg (jdrosen)
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Cisco to open source its H.264 
> > implementation and absorb MPEG-LA licensing fees
> > 
> > Il giorno Wed, 30 Oct 2013 12:28:50 +0000 "Jonathan Rosenberg 
> > (jdrosen)"  ha scritto:
> > 
> > > I'd like to make an announcement material to the 
> > conversations around 
> > > MTI video codecs in rtcweb.
> > > 
> > > Cisco is announcing today that we will take our H.264 
> > implementation, 
> > > and open source it under BSD license terms. Development and 
> > > maintenance will be overseen by a board from industry and the open 
> > > source community.  Furthermore, we will provide a binary 
> > form suitable 
> > > for inclusion in applications across a number of different 
> > operating 
> > > systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and 
> > > make this binary module available for download from the 
> > Internet. We 
> > > will not pass on our MPEG-LA licensing costs for this module, and 
> > > based on the current licensing environment, this will 
> > effectively make 
> > > H.264 free for use on supported platforms.
> > > 
> > > We believe that this contribution to the community can help address 
> > > the concerns many have raised around selection of H.264 as MTI. I 
> > > firmly believe that with H.264 we can achieve maximal 
> > interoperability 
> > > and now, do it with open source and for free (well, at least for 
> > > others - its not free for Cisco :)) More information on the open 
> > > source project can be found at http://www.openh264.org, which is 
> > > sparse now but more coming soon.
> > > 
> > > 
> > > Thx,
> > > Jonathan R.
> > > 
> > > --
> > > Jonathan Rosenberg, PhD
> > > VP, CTO Collaboration
> > > Cisco Systems
> > > jdrosen@cisco.com
> > > 
> > 
> > 
> > Am I really the only one not that enthusiastic about this?
> > 
> > Don't get me wrong, I appreciated Cisco's statement. I just 
> > don't think it changes anything. It doesn't make H.264 more 
> > open (or less closed, if you prefer) than it was before. It 
> > just says that, if you download their module from them when 
> > installing your stuff, your applications can use it to 
> > encode/decode H.264 and not worry about fees (hoping with 
> > your fingers crossed that the platform is supported, that 
> > is). I still cannot use x264, ffmpeg, 
> > randomsuperawesomeopensourceH264codec or even a version of 
> > Cisco's H.264 code I compile myself: at least, not if I don't 
> > want (or just can't afford) to pay license fees, that is. 
> > Which means we're back to step one again. Under those 
> > premises, I still think it's not MTI material.
> > 
> > The problem is, I don't want to rely on Cisco's generosity[*] 
> > (or anyone else's, for that matter) to work with video, 
> > especially when we're building an (allegedly) open web 
> > communication framework. What if their module sucks? I'm sure 
> > it won't, but I still don't have any choice, there are no 
> > free alternatives. Besides, we have no assurance at all that 
> > this is something we can rely on. If Cisco wakes up in a 
> > couple of months and decides it's all not worth it and shuts 
> > all of this down, what happens to WebRTC implementations, to 
> > companies that decided to depend on it, to their 
> > clients/customers? We wait for another generous "mecenate", 
> > while big companies thrive? We complain on social networks? 
> > We cry at the moon?  And this is not such a remote
> > possibility: after all (and I'm quoting one of Jonathan's 
> > latest tweets here), "We cannot say forever but unless things 
> > change we will continue this indefinitely". If this is 
> > supposed to convince me H.264 is now the best solution as MTI 
> > for WebRTC then, especially as a developer, I'm not convinced.
> > 
> > I see this opening more as the (welcome, no denying that) 
> > software equivalent of daddy pinching you on the cheek and 
> > giving you a coupon for your "free ice cream (for a while)". 
> > Everyone loves free stuff, I do as well. But IMHO it's not 
> > more than that, a free gift to convince the unconvinced. 
> > Ancient Romans would have called this "Panem et Circenses", 
> > and according to all the enthusiastic posts on Twitter and 
> > the like, I guess it still works: people are entertained.
> > 
> > Make the codec REALLY free, without any license fee required 
> > at all, and then you'll entertain me as well.
> > 
> > Lorenzo
> > 
> > 
> > [*] I must shamefully admit I sniggered a bit when I read the 
> > "it's not free for Cisco" part, as if you were really paying 
> > for this. I have trouble thinking Cisco doesn't already pay 
> > the infamous cap every year.
> > You're doing something you really don't have to (and we 
> > really appreciate this, make no mistake), but that's not the 
> > same thing.
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > 

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From richard.ejzak@alcatel-lucent.com  Wed Oct 30 13:49:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA2511E8254 for ; Wed, 30 Oct 2013 13:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.218
X-Spam-Level: 
X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUYhbjUr8Jhp for ; Wed, 30 Oct 2013 13:49:26 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 70F8A21F9DC7 for ; Wed, 30 Oct 2013 13:49:26 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9UKnPZ1002069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 30 Oct 2013 15:49:25 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9UKnPWf017819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Oct 2013 16:49:25 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 30 Oct 2013 16:49:25 -0400
From: "Ejzak, Richard P (Richard)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQgABIioCAABByAP//ww2ggABSCoD//8IcAIAA11OAgABsdbCAAlPugIAAvIgAgAGzAlCAAR2/AIAAUj5wgAEc5oCAAOONsA==
Date: Wed, 30 Oct 2013 20:49:24 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86DB71@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com> <526F3D5A.9010205@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com> <52707155.8090003@jesup.org>
In-Reply-To: <52707155.8090003@jesup.org>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 20:49:32 -0000

Hi Randell,
Thanks again for your response.

You asked what I thought would help to clear up any confusion around the st=
ream id assignment issue.  I think clearer definitions of the different typ=
es of negotiation, and a few more guidelines in the text would be great.  P=
lease correct any of the following suggested guidelines to avoid potential =
stream id conflicts.

1) For in-band negotiation before establishment of the SCTP association, th=
e application should use only deferred stream id assignment based on DTLS r=
ole.  (A little discussion of what this means also wouldn't hurt.)  Otherwi=
se a preselected stream id on one side might conflict with a deferred selec=
tion on the other side.
2) For external negotiation before establishment of the SCTP association, t=
he application must select stream ids without waiting for determination of =
DTLS role.  Both peers need to know the stream id allocated to each data ch=
annel via the external negotiation mechanism, so deferred selection cannot =
be used.
3) Prior to establishment of the SCTP association, if the application has d=
ata channels to establish using both in-band and external negotiation, exte=
rnal negotiation data channels should always be created before in-band nego=
tiation data channels.  This allows the protocol to avoid reusing any poten=
tially conflicting stream ids allocated by the external negotiation mechani=
sm.
4) After establishment of the SCTP association, in-band and external negoti=
ation can be freely mixed as long as stream id assignment is based on DTLS =
role while avoiding already allocated ids.  For application selection of st=
ream ids (rather than protocol selection of stream ids), the application ca=
n determine the DTLS role by examining the exchanged SDP messages.

This paraphrases many of the things in your email that aren't yet in the dr=
aft.  Some of my confusion was that I was thinking of hybrid negotiation me=
chanisms to allow application selection of stream ids with in-band negotiat=
ion before establishment of the SCTP association, but it's far easier to si=
mply disallow that!

BR, Richard

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Randell Jesup
> Sent: Tuesday, October 29, 2013 9:39 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> 01.txt
>=20
> On 10/29/2013 11:06 AM, Ejzak, Richard P (Richard) wrote:
> > Hi Randell,
> > There is clearly a problem with terminology here that is not allowing
> us to converge.  Even after your explanation, I believe my
> issues/questions remain valid.  I understand that we are discussing the
> data protocol draft, but we cannot ignore the pure external negotiation
> case when discussing compatibility issues.
>=20
> I'm definitely not ignoring it.  I'm not specifying what the
> application does in the external negotiation; just how that affects the
> protocol stacks at either end.  See my pseudo-code below, which has the
> advantage of avoiding english vagueries.  I think part of the confusion
> comes from looking/thinking about the JS API, not the IETF protocol.
>=20
> > When I refer to in-band negotiation, I mean the use of the data
> channel protocol Open message to inform the peer browser that a
> specific stream id has been allocated to a data channel.
>=20
> Agreed.
>=20
> > When I refer to external negotiation, I mean the case where the data
> channel protocol Open message is NOT used but instead both applications
> need to use the create data channel method on the API to each browser
> to create both ends of each data channel.
>=20
> Agreed.  That's how I've been using it, with what happens to decide on
> what the two apps end up using to initialize the two ends being largely
> out-of-scope to this discussion.
>=20
> > You apparently also use the term "external negotiation" to apply to
> the case where in-band negotiation needs to be augmented with
> additional communication (i.e., in addition to the Open message)
> between the applications.
>=20
> No, I didn't mean that to be what the term meant.  Where do you think I
> implied that?
>=20
> >    I consider this just a special case of in-band negotiation.  Clear
> terminology to separate these cases would be useful since they have
> very different characteristics.  Perhaps "augmented in-band
> negotiation" or "hybrid in-band/external negotiation"?
> >
> > The application can choose when creating a data channel via the API
> whether to select the stream id for the data channel or to request the
> browser to select the stream id.  Apparently there are cases when the
> application MUST use only one of these options to guarantee correct
> operation.
>=20
> There are many ways the application can guarantee correct operation.
> Letting the first side of an external negotiation request the stack
> assign a free id of 'correct' oddness is merely an API helper at the JS
> level; it has no impact on the protocol per se, and the application can
> do it itself (with extra bookkeeping, as I stated).  As such, it's only
> mentioned in the JS API spec, not the IETF drafts.
>=20
> > The application can also specifically request whether to send the
> data channel Open message once the SCTP association is established.  It
> is understood that if the browser does not send the Open message that
> the peer application must also use its API to create the other end of
> the data channel.
>=20
> This is the external negotiation - both sides tell the stack that a
> channel has been agreed to.   "Agreed to" can be "one side send to the
> other a channel definition, and the second side installs it, completing
> the channel."  It also can be "both sides (same JS app) know a priori
> that channel id 0 is the reliable control channel used for Foo
> messages, and so inform the stack".
>=20
> > Without going through all the cases again, I think it's fair to say
> that the situation warrants some additional explanation (in the drafts)
> to describe these various cases and under what circumstances each is
> allowed.  Your pseudo-code does not cover all the cases, and the
> situation is more subtle than you describe it to be.  The current
> drafts are far from adequate in this regard.
>=20
> I think the pseudo-code does cover it - as that's also virtually what
> we've implemented (running code and all that). ;-)   The other
> properties discussed emerge from that design and the JS API on top of
> it.  You can see the actual (rather more messy!) code in
> netwerk/sctp/datachannel/DataChannel.cpp in Firefox.  (Need to handle
> failures, requirement to allocate more streams from SCTP, JS interface,
> etc).
>=20
> Has my discussion above cleared up any of the confusion?  If it has, do
> you have any proposed way to help others avoid that confusion?
>=20
> Thanks for looking at it before we're at the mics!
>=20
>      Randell
>=20
> >
> > Please just answer one question: How does the application determine
> its DTLS role (i.e., whether to request even or odd numbers when
> choosing to select stream ids)?  Does this need to be inferred from
> allocated stream ids or can the application determine it directly?
> >
> > Thanks,
> > Richard
> >
> >
> >> -----Original Message-----
> >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> >> Behalf Of Randell Jesup
> >> Sent: Monday, October 28, 2013 11:45 PM
> >> To: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> >> 01.txt
> >>
> >> On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
> >>> Hi Randell,
> >>> Thanks for suggesting the stream id assignment algorithm below.
> >> Please bear with me a little longer.  I agree that limited
> >> coexistence of application and browser stream id selection is
> >> possible, but it seems that there are some significant restrictions.
> >>> Using in-band negotiation, I cannot see any way in which
> application
> >> selection and browser selection of stream ids can co-exist before
> >> DTLS roles are determined.  If application A selects an odd stream
> >> id, the only way to communicate this selection to application B's
> >> browser is via the in-band open message after the SCTP association
> >> has been established.
> >>
> >> No, the application can tell the other end that in conjunction with
> >> the offer (i.e. in application-specific signaling that accompanies
> >> the offer).  Any application using external negotiation must, in
> >> fact, handle external negotiation (even if that 'negotiation' is a
> >> set of hard-coded channel ids).
> >>
> >> Any later non-external-negotiated channel creations will select an
> >> unused id of the correct even/oddness (per DTLS role).  One SHOULD
> >> create all initial-connection-time externally negotiated channels
> >> before adding any new automatic (data-protocol) ones, in order to
> >> avoid surprises -- though I'd be rather surprised that an
> application
> >> would mix them in that way.  If the app does, it will work fine
> though.
> >>
> >> There is an implicit assumption that anything using external
> >> negotiation is either two instances of the same JS app or a
> >> cooperating app and server (those are by far the most common cases,
> >> and virtually the only cases), or two different apps that
> nonetheless
> >> know how to talk to each other and negotiate the channels on their
> >> own (I'll believe this when I see it, but it might happen).
> External
> >> negotiation was added specifically for these pre-cooperating cases.
> >>
> >> Also, one point perhaps missed from the W3 spec:
> >>
> >>      7. If the value of the |id
> >>
> >>  >> id>|
> >>      attribute is null, initialize it to a value generated by the
> user
> >>      agent, according to the WebRTC DataChannel Protocol
> specification,
> >>      and skip to the next step. Otherwise, if the value of the |id
> >>
> >>  >> id>|
> >>      attribute is taken by an existing ||RTCDataChannel|
> >>       >> RTCDataChannel>|,
> >>      throw a |TBD| exception and abort these steps.
> >>
> >> Note this means you can create a channel for external negotation and
> >> let the browser select the id (which you then would tell the other
> >> side, and
> >> *they* would specify it to their end).  Note that the ID will not be
> >> set until DTLS roles are decided (and that's when onopen should fire
> >> as well).  This would not be very useful for setting up channels
> >> before offer/answer, but once offer/answer has completed, it lets
> you
> >> get a local channel id of correct oddness without having to scan all
> >> current datachannels to find an unused id value (assuming you're
> >> mixing styles of creation).
> >>
> >> (We may need to add a line to the IETF drafts to cover this case;
> >> need to check).  The application *could* just scan all known
> channels
> >> instead, that's just a pain.  And it really only matters if you mix
> >> types, which is likely to be rare outside of "create these N
> >> hard-coded channels at offer/answer time, then have some dynamic
> >> (automatically-assigned-id) channels that get used later if needed."
> >>
> >>>     It doesn't help to tell application B since it can't report the
> >> information to its browser.  So if application B creates another
> data
> >> channel and requests browser selection of a stream id then B's
> >> browser might end up selecting the same odd stream id, since it has
> >> no way to know to avoid it.  Not unless we reserve id values
> >> exclusively for application selection.  Do you agree?  If so, we
> >> should document this restriction.
> >>
> >> When you tell the browser/protocol that a channel has been
> externally
> >> negotiated, it will mark that as in-use of course. That's why
> >> collisions can only happen when the other side creates an
> externally-
> >> negotiated channel of the "wrong" oddness in a race with an
> automatic
> >> creation from this side.  This is trivially avoided when building an
> >> app.
> >>
> >> Much of this  discussion in the mail I'm replying to is moot, since
> >> it's based on an incorrect assumption about mixing.
> >>
> >>> There is no problem if only browser selection of stream ids is
> >> allowed before the SCTP association is established since both
> >> applications can learn which side owns odd/even values after channel
> >> open is reported to the peer (since there has to be at least one
> data
> >> channel created to trigger the establishment of the SCTP
> association).
> >> Now application and browser stream id selection can co-exist without
> >> a hitch.
> >>> If we assume only application selection of stream ids is allowed
> >>> with
> >> in-band negotiation before the SCTP association is established, then
> >> we can also allow co-existence of application selection and browser
> >> selection of stream ids after establishment of the SCTP association,
> >> as long as there is a way for each application to determine DTLS
> role.
> >> They can't use the trick in the last paragraph since the browsers
> >> haven't been asked to assign any stream ids.  Is there an API
> >> mechanism available to determine DTLS role?  Am I missing something
> here?
> >>> With external negotiation, only application selection of stream ids
> >> can be allowed before DTLS role is determined since the external
> >> negotiation mechanism needs to be able to report to both peers (and
> >> browsers) the stream id(s) selected.  Once DTLS role is determined
> >> then application and browser selection of stream ids could co-exist,
> >> but requires that the applications learn which DTLS roles were
> >> negotiated (same issue as above).
> >>> Interestingly, in-band and external negotiation can co-exist before
> >> DTLS role is established as long as application selection of stream
> >> ids is used exclusively.  All forms of in-band and external
> >> negotiation can co-exist after the SCTP association is established
> as
> >> long as the applications know the DTLS roles.
> >>
> >> I'm not going to reply line-by-line here, since I think much of this
> >> is based on a slightly incorrect understanding.
> >>
> >>> In summary, the following combinations are allowed:
> >>>
> >>> 1) application selection with in-band negotiation before SCTP
> >>> established and app determines DTLS role
> >>> 2) browser selection with in-band negotiation before SCTP
> >>> established
> >>> 3) application selection with external negotiation before app
> >>> determines DTLS role
> >>> 4) application selection with in-band and external negotiation
> >>> before SCTP established and app determines DTLS role
> >>> 5) any combination of selection and negotiation after SCTP is
> >>> established if DTLS role is available to app
> >> I'd put it this way:
> >>
> >> 1)  You can create any number of DataChannels before
> >> createOffer()/createAnswer() so long as all of them are
> automatically
> >> assigned ids (what you call browser selection).  The actual ids are
> >> assigned after the DTLS roles are known.
> >>
> >> 2)  You can create any number of externally-negotiated channels
> >> before createOffer().  There is no need for them to match DTLS
> roles.
> >>
> >> 3) The answerer must create any externally-negotiated channels from
> >> its side before the channels can be used, and also SHOULD do so
> >> before creating automatic channels unless the application has made
> >> sure somehow
> >> a collision is impossible/unlikely.   In reality, there's no reason
> not
> >> to install the externally-negotiated channels before trying to
> create
> >> more, so the point is basically moot. (Note: you don't have to
> >> install the externally-negotiated channels before createAnswer,
> >> though normally I'd suggest doing so, just before creating
> >> automatically-generated
> >> ones.)
> >>
> >> 4) You can create externally-negotiated channels and then
> >> automatically negotiated channels before calling createOffer.  You
> >> can even mix them, since the automatically-generated ones will be
> >> assigned ids later when DTLS role is known (and will avoid any
> >> already in-use).  I'm not sure this is behavior that anyone would
> >> *need*, so I see no reason to promote mixing in that way - but it'll
> work.
> >>
> >> 5) Once the association is up, the application can use the method
> >> above (negotiated=3Dtrue but no id=3DN) to allocate ids without fear o=
f
> >> collision with automatic channels.
> >>
> >> This is all emergent from the even/odd selection and letting the
> >> protocol choose ids when not externally negotiated.
> >>
> >> Pseudo-code:
> >>
> >> creation:
> >>       externally-selected-id?
> >>           yes-> mark channel in use
> >>               if channel already in use complain and fail
> >>           no-> dtls role known?
> >>               yes-> assign unused channel of correct oddness; send
> OPEN
> >>               no-> queue channel id selection
> >>       fire onopen if association is up
> >>
> >> incoming OPEN message:
> >>      if channel already in use
> >>         yes-> complain (perhaps fire onerror TBD)
> >>         no-> Mark channel in use; inform application
> (ondatachannel);
> >> send ACK
> >>
> >> Pretty darn simple.
> >>
> >>> If DTLS exchange and SCTP establishment are associated with
> separate
> >> offer/answer transactions, there might be a few more combinations to
> >> consider.  The list also does not describe what is possible if DTLS
> >> role is not available directly to the apps.
> >>
> >> DTLS and SCTP association establishment are async to offer/answer
> >> (kicked off by successful offer/answer completion).
> >>
> >>> The above discussion might be an argument for segregating the
> stream
> >> ids available for application and browser selection.  There sure are
> >> plenty of them.  What do you think?  Then we wouldn't need to make
> >> DTLS role available to the app and there would only be a few
> >> restrictions on browser selection (it can't be used for external
> >> negotiation before DTLS role is determined).  And you could always
> have an overflow rule.
> >>> Please correct me if I have missed anything.  Thanks!
> >>>
> >>> BR, Richard
> >>>
> >>>> -----Original Message-----
> >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> >>>> Behalf Of Randell Jesup
> >>>> Sent: Sunday, October 27, 2013 4:46 AM
> >>>> To: rtcweb@ietf.org
> >>>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> >>>> 01.txt
> >>>>
> >>>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
> >>>>> Richard,
> >>>>>
> >>>>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
> >>>>>> Hi Harald,
> >>>>>> You said: " I can't see a way to mix the two paradigms that
> >>>>>> guarantees this never happening."  The two paradigms being
> >>>>>> browser selection vs. application selection of data channel
> stream ids.
> >>>> You can.  You just have to be careful.  For example, your
> >> application
> >>>> could define that pre-negotiated channels will use 100-110, and
> >>>> then specify those to both ends before association/offer/answer.
> >>>> Later
> >> it
> >>>> could use data-protocol to add dynamic channels (using even-odd).
> >>>> Since we've told both ends about 100-110, there's no problem here.
> >>>> Even/odd is ONLY to avoid glare when both sides decide to open a
> >>>> channel "at the same time".  If you add a pre-negotiated channel
> >>>> after initial establishment, it's up to you to avoid colliding
> with
> >>>> any existing channels and to avoid colliding with any
> >>>> in-process-of- creation dynamic
> >>>> (data-protocol) channels.  There are a number of ways to avoid
> such
> >> a
> >>>> collision safely (never use dynamic channels; use the DTLS role or
> >> an
> >>>> existing dynamic channel id to determine even/odd, etc).
> >>>>
> >>>>>> My proposal has three elements, which together can guarantee
> that
> >>>>>> there are no stream id allocation conflicts between peers:
> >>>>>>       1. The browser and application select stream ids based on
> >>>> initial
> >>>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
> >>>>>> offerer uses even ids, initial answerer uses odd ids). With this
> >>>>>> rule, the offering application knows its role immediately
> without
> >>>>>> waiting for the DTLS or SDP handshake to occur.
> >>>>> A similar issue has come up in the discussion of partial
> >>>>> offers/answers. (Regarding how to assign a=3Dmid values.) And a
> >>>>> similar solution was proposed.
> >>>>>
> >>>>> It was then rejected on the basis that sometimes both "ends"
> think
> >>>>> they are offerers or answerers. This comes about as a result of
> >>>>> signaling-only B2BUAs that play games with O/A on two legs.
> >>>> Exactly why we went with DTLS roles.
> >>>>
> >>>> --
> >>>> Randell Jesup -- rjesup a t mozilla d o t com
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >> --
> >> Randell Jesup -- rjesup a t mozilla d o t com
> >>
> >> _______________________________________________
> >> 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
>=20
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From fluffy@cisco.com  Wed Oct 30 14:40:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D81211E8286 for ; Wed, 30 Oct 2013 14:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level: 
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgeAD4tqLe1n for ; Wed, 30 Oct 2013 14:40:12 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F050211E8244 for ; Wed, 30 Oct 2013 14:40:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=729; q=dns/txt; s=iport; t=1383169209; x=1384378809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X6iIZcGjMuWKzlUjXcj04SjNlOTZZzZmawMs5ZqISUE=; b=lF2wM1seZQmUapdMrL7e2FJIqTzb6zTd5nYvOrFB/6xEgkCBR3r/MR+c nC5hW8Yg9u8PqzBCSR43QevjPCQ6mjdtt4swrYrwadoqrz2f8G8MI6ygt kTKI6/PHkuHJiEMx3pIwZbxdGmzdHL/AKP1I89q0YjhH1hkPXaGoYnLon A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAAN8cVKtJV2b/2dsb2JhbABZgweBDL9XAQmBKhZ0giUBAQEDAXkFCwIBCA4UJCERJQIEDgUIE4daAwkGsQ0NiWuMX4I9AjEHgx+BDQOJB40Yjj2FN4Mmgio
X-IronPort-AV: E=Sophos;i="4.93,604,1378857600"; d="scan'208";a="278677597"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 30 Oct 2013 21:40:08 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9ULe8Jd003439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 21:40:08 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 16:40:08 -0500
From: "Cullen Jennings (fluffy)" 
To: Leon Geyser 
Thread-Topic: [rtcweb] On the topic of MTI video codecs
Thread-Index: AQHO1bia3d+Iz9aO0UWTLuasWULgLg==
Date: Wed, 30 Oct 2013 21:40:08 +0000
Message-ID: 
References: <527147FF.5010506@nostrum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <69FC795EA726F6448D259BF054BAAD7C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 21:40:23 -0000

On Oct 30, 2013, at 12:20 PM, Leon Geyser  wrote:

> Unfortunately like Jonathan pointed out H.264 will only be able to be use=
d royalty free on certain(most popular) platforms.
> To be able to avoid negotiation failure we need a MTI codec that every po=
tential now/future browser would be able to implement freely.
> I like what Cisco did, but the solution seems a bit half-baked.
>=20

I think that Mozilla put it pretty nicely in their blog. What this annoucem=
ent gives us is not a perfect world. Mozilla is working towards a better fu=
ture but in the mean time, this is the best thing we could possibly figure =
out on how to make the internet today be the best it can be for users.=20






From jmvalin@mozilla.com  Wed Oct 30 15:36:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56F811E8287 for ; Wed, 30 Oct 2013 15:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlYMNT6dGX+S for ; Wed, 30 Oct 2013 15:36:44 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0508321F9FB9 for ; Wed, 30 Oct 2013 15:36:24 -0700 (PDT)
Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 04B00F262C;  Wed, 30 Oct 2013 15:36:23 -0700 (PDT)
Message-ID: <527189E7.7060505@mozilla.com>
Date: Wed, 30 Oct 2013 18:36:23 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" ,  Leon Geyser 
References: <527147FF.5010506@nostrum.com>	 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 22:36:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/2013 05:40 PM, Cullen Jennings (fluffy) wrote:
> I think that Mozilla put it pretty nicely in their blog. What this 
> annoucement gives us is not a perfect world. Mozilla is working 
> towards a better future but in the mean time, this is the best
> thing we could possibly figure out on how to make the internet
> today be the best it can be for users.

For those who haven't read it, I also recommend Monty's post:
http://xiphmont.livejournal.com/61927.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJScYnnAAoJEJ6/8sItn9q9HYoH/j+wDYU9VWwcu35G96KOQ5E9
p0MTnoSuwXuMh6nx4kgPvow8e50NdpbobvTy7NsrwQDKVSgmRqzQG54SYedtXWmx
LwdD3mtFDGJxdCLAtA3R8OdlXQ4wAZhjbNd6CFM0nt6/lWAJs+/Mv9LTRqwhauea
iI/hRoRgPki6eXPS4zlRLiWyOuiR462i9IZcxfZWxxZWLf6vPcL4/3K2O3WuGPH0
yrim8DrtVbpZsh8Yni3iDYDWoXIbhjtrJR7aHsHvves8Hj6t1DRGHDHfNbVsiaq1
c2YIzC4iCU12+IXggl5yDNwcol9ICBH1mJPTqnwRV8XszXE+U+uMNQOm0iaKDnQ=
=zTD4
-----END PGP SIGNATURE-----

From juberti@google.com  Wed Oct 30 17:23:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5321F9FE9 for ; Wed, 30 Oct 2013 17:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.634
X-Spam-Level: 
X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id susVrHWTsbTq for ; Wed, 30 Oct 2013 17:23:29 -0700 (PDT)
Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B881011E82DF for ; Wed, 30 Oct 2013 17:23:26 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id 11so1421122vbe.17 for ; Wed, 30 Oct 2013 17:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UuNq3QO/lpOhwsYA4bAII/e4SU+batEm2pn8rlaKf6k=; b=VMdBCDYiEjcuT0EIn51zj4++dcZqLNAjcLn7ofqt0KSEU840V9vnvqznwZ/0CcTatA ozqGfnC+1DrZaYZGkIG844tS1icYl8yD436/Mph2KaFGAtY44mIx5LagCJrraUSS2JWQ BewiDfbJMKqd+5z5SQYa8Iyv1mN439MRuEDjPb+hTeOJ3v5268kPf84WwToAlD7rtBF4 gOnqGAKmNyxw+ic/YgP+bMOiNGigXvnbIDeYdeeCZ2Z26bTQSKJpo3Tt+ihQB9ObT3Fn Caticd0VM0t8RhH8v6mHovI8PjO5J5pLs4emo37YYKZ3F14oFwbkTQSC+SVkkpCmgncz JbdA==
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=UuNq3QO/lpOhwsYA4bAII/e4SU+batEm2pn8rlaKf6k=; b=EfgfeKFIFQ18MITh4MRgoWpD94fn+XAwgL1iPlG3kUG0DA4LYSPLBpcJ7GuYmcTE/V iqqj1EYlIEGomWZiKcTezbMt7Y2j4WfyMoq0NgnNVgg8jvlF6aUtPZG9y7bSIQCS/B0/ 3tyM74owG84MiYV2/WlDpoQRurvZt8K+/Z9MhF+URU+81WsbWehfevH9M/zzQhlLxBZ6 X9Fvk6BBIAQ4vh59tP0YrEmjv71VuFUjkVQjx1pUDlmWxjcPz71GgyuyPiaOE3c7ll2Z 0KYMXuI7uMvoe51g8dKWJeAkzVVf1aS7SVrKq2Nle17YwrpN+r+L6lKJchBanMB4ICwh koTg==
X-Gm-Message-State: ALoCoQkco7lzNDbswmZ5z6MNjLk73mg4nuGMo30VdPR1PsoJUQdYt4eUAWZQ3DEYu2ofDPjjhvOfW6sgYh+oVKTPsR+jzjw58zoAqYqly1ytIr6OxbUnxEi8BwPFe40kGCifT2BMBb/zKfEusCTb0hdP3X+jYak5sCyg+2Vhstpr/g0D28QRMScxh74oDtkWS/UhAKD7K2x9
X-Received: by 10.58.238.9 with SMTP id vg9mr131042vec.43.1383179006101; Wed, 30 Oct 2013 17:23:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Wed, 30 Oct 2013 17:23:05 -0700 (PDT)
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86DB71@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com> <526F3D5A.9010205@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com> <52707155.8090003@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86DB71@US70UWXCHMBA04.zam.alcatel-lucent.com>
From: Justin Uberti 
Date: Wed, 30 Oct 2013 17:23:05 -0700
Message-ID: 
To: "Ejzak, Richard P (Richard)" 
Content-Type: multipart/alternative; boundary=047d7bd7578251e5b304e9fe75ce
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 00:23:32 -0000

--047d7bd7578251e5b304e9fe75ce
Content-Type: text/plain; charset=UTF-8

Note also that DTLS role can change during the lifetime of the session
(e.g. a peer that was active can become passive, and vice versa). So we
will need to be more specific about when the role is in fact determined -
perhaps the initial DTLS roles used in the session.


On Wed, Oct 30, 2013 at 1:49 PM, Ejzak, Richard P (Richard) <
richard.ejzak@alcatel-lucent.com> wrote:

> Hi Randell,
> Thanks again for your response.
>
> You asked what I thought would help to clear up any confusion around the
> stream id assignment issue.  I think clearer definitions of the different
> types of negotiation, and a few more guidelines in the text would be great.
>  Please correct any of the following suggested guidelines to avoid
> potential stream id conflicts.
>
> 1) For in-band negotiation before establishment of the SCTP association,
> the application should use only deferred stream id assignment based on DTLS
> role.  (A little discussion of what this means also wouldn't hurt.)
>  Otherwise a preselected stream id on one side might conflict with a
> deferred selection on the other side.
> 2) For external negotiation before establishment of the SCTP association,
> the application must select stream ids without waiting for determination of
> DTLS role.  Both peers need to know the stream id allocated to each data
> channel via the external negotiation mechanism, so deferred selection
> cannot be used.
> 3) Prior to establishment of the SCTP association, if the application has
> data channels to establish using both in-band and external negotiation,
> external negotiation data channels should always be created before in-band
> negotiation data channels.  This allows the protocol to avoid reusing any
> potentially conflicting stream ids allocated by the external negotiation
> mechanism.
> 4) After establishment of the SCTP association, in-band and external
> negotiation can be freely mixed as long as stream id assignment is based on
> DTLS role while avoiding already allocated ids.  For application selection
> of stream ids (rather than protocol selection of stream ids), the
> application can determine the DTLS role by examining the exchanged SDP
> messages.
>
> This paraphrases many of the things in your email that aren't yet in the
> draft.  Some of my confusion was that I was thinking of hybrid negotiation
> mechanisms to allow application selection of stream ids with in-band
> negotiation before establishment of the SCTP association, but it's far
> easier to simply disallow that!
>
> BR, Richard
>
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Randell Jesup
> > Sent: Tuesday, October 29, 2013 9:39 PM
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> > 01.txt
> >
> > On 10/29/2013 11:06 AM, Ejzak, Richard P (Richard) wrote:
> > > Hi Randell,
> > > There is clearly a problem with terminology here that is not allowing
> > us to converge.  Even after your explanation, I believe my
> > issues/questions remain valid.  I understand that we are discussing the
> > data protocol draft, but we cannot ignore the pure external negotiation
> > case when discussing compatibility issues.
> >
> > I'm definitely not ignoring it.  I'm not specifying what the
> > application does in the external negotiation; just how that affects the
> > protocol stacks at either end.  See my pseudo-code below, which has the
> > advantage of avoiding english vagueries.  I think part of the confusion
> > comes from looking/thinking about the JS API, not the IETF protocol.
> >
> > > When I refer to in-band negotiation, I mean the use of the data
> > channel protocol Open message to inform the peer browser that a
> > specific stream id has been allocated to a data channel.
> >
> > Agreed.
> >
> > > When I refer to external negotiation, I mean the case where the data
> > channel protocol Open message is NOT used but instead both applications
> > need to use the create data channel method on the API to each browser
> > to create both ends of each data channel.
> >
> > Agreed.  That's how I've been using it, with what happens to decide on
> > what the two apps end up using to initialize the two ends being largely
> > out-of-scope to this discussion.
> >
> > > You apparently also use the term "external negotiation" to apply to
> > the case where in-band negotiation needs to be augmented with
> > additional communication (i.e., in addition to the Open message)
> > between the applications.
> >
> > No, I didn't mean that to be what the term meant.  Where do you think I
> > implied that?
> >
> > >    I consider this just a special case of in-band negotiation.  Clear
> > terminology to separate these cases would be useful since they have
> > very different characteristics.  Perhaps "augmented in-band
> > negotiation" or "hybrid in-band/external negotiation"?
> > >
> > > The application can choose when creating a data channel via the API
> > whether to select the stream id for the data channel or to request the
> > browser to select the stream id.  Apparently there are cases when the
> > application MUST use only one of these options to guarantee correct
> > operation.
> >
> > There are many ways the application can guarantee correct operation.
> > Letting the first side of an external negotiation request the stack
> > assign a free id of 'correct' oddness is merely an API helper at the JS
> > level; it has no impact on the protocol per se, and the application can
> > do it itself (with extra bookkeeping, as I stated).  As such, it's only
> > mentioned in the JS API spec, not the IETF drafts.
> >
> > > The application can also specifically request whether to send the
> > data channel Open message once the SCTP association is established.  It
> > is understood that if the browser does not send the Open message that
> > the peer application must also use its API to create the other end of
> > the data channel.
> >
> > This is the external negotiation - both sides tell the stack that a
> > channel has been agreed to.   "Agreed to" can be "one side send to the
> > other a channel definition, and the second side installs it, completing
> > the channel."  It also can be "both sides (same JS app) know a priori
> > that channel id 0 is the reliable control channel used for Foo
> > messages, and so inform the stack".
> >
> > > Without going through all the cases again, I think it's fair to say
> > that the situation warrants some additional explanation (in the drafts)
> > to describe these various cases and under what circumstances each is
> > allowed.  Your pseudo-code does not cover all the cases, and the
> > situation is more subtle than you describe it to be.  The current
> > drafts are far from adequate in this regard.
> >
> > I think the pseudo-code does cover it - as that's also virtually what
> > we've implemented (running code and all that). ;-)   The other
> > properties discussed emerge from that design and the JS API on top of
> > it.  You can see the actual (rather more messy!) code in
> > netwerk/sctp/datachannel/DataChannel.cpp in Firefox.  (Need to handle
> > failures, requirement to allocate more streams from SCTP, JS interface,
> > etc).
> >
> > Has my discussion above cleared up any of the confusion?  If it has, do
> > you have any proposed way to help others avoid that confusion?
> >
> > Thanks for looking at it before we're at the mics!
> >
> >      Randell
> >
> > >
> > > Please just answer one question: How does the application determine
> > its DTLS role (i.e., whether to request even or odd numbers when
> > choosing to select stream ids)?  Does this need to be inferred from
> > allocated stream ids or can the application determine it directly?
> > >
> > > Thanks,
> > > Richard
> > >
> > >
> > >> -----Original Message-----
> > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > >> Behalf Of Randell Jesup
> > >> Sent: Monday, October 28, 2013 11:45 PM
> > >> To: rtcweb@ietf.org
> > >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> > >> 01.txt
> > >>
> > >> On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
> > >>> Hi Randell,
> > >>> Thanks for suggesting the stream id assignment algorithm below.
> > >> Please bear with me a little longer.  I agree that limited
> > >> coexistence of application and browser stream id selection is
> > >> possible, but it seems that there are some significant restrictions.
> > >>> Using in-band negotiation, I cannot see any way in which
> > application
> > >> selection and browser selection of stream ids can co-exist before
> > >> DTLS roles are determined.  If application A selects an odd stream
> > >> id, the only way to communicate this selection to application B's
> > >> browser is via the in-band open message after the SCTP association
> > >> has been established.
> > >>
> > >> No, the application can tell the other end that in conjunction with
> > >> the offer (i.e. in application-specific signaling that accompanies
> > >> the offer).  Any application using external negotiation must, in
> > >> fact, handle external negotiation (even if that 'negotiation' is a
> > >> set of hard-coded channel ids).
> > >>
> > >> Any later non-external-negotiated channel creations will select an
> > >> unused id of the correct even/oddness (per DTLS role).  One SHOULD
> > >> create all initial-connection-time externally negotiated channels
> > >> before adding any new automatic (data-protocol) ones, in order to
> > >> avoid surprises -- though I'd be rather surprised that an
> > application
> > >> would mix them in that way.  If the app does, it will work fine
> > though.
> > >>
> > >> There is an implicit assumption that anything using external
> > >> negotiation is either two instances of the same JS app or a
> > >> cooperating app and server (those are by far the most common cases,
> > >> and virtually the only cases), or two different apps that
> > nonetheless
> > >> know how to talk to each other and negotiate the channels on their
> > >> own (I'll believe this when I see it, but it might happen).
> > External
> > >> negotiation was added specifically for these pre-cooperating cases.
> > >>
> > >> Also, one point perhaps missed from the W3 spec:
> > >>
> > >>      7. If the value of the |id
> > >>
> > >>  > >> id>|
> > >>      attribute is null, initialize it to a value generated by the
> > user
> > >>      agent, according to the WebRTC DataChannel Protocol
> > specification,
> > >>      and skip to the next step. Otherwise, if the value of the |id
> > >>
> > >>  > >> id>|
> > >>      attribute is taken by an existing ||RTCDataChannel|
> > >>       > >> RTCDataChannel>|,
> > >>      throw a |TBD| exception and abort these steps.
> > >>
> > >> Note this means you can create a channel for external negotation and
> > >> let the browser select the id (which you then would tell the other
> > >> side, and
> > >> *they* would specify it to their end).  Note that the ID will not be
> > >> set until DTLS roles are decided (and that's when onopen should fire
> > >> as well).  This would not be very useful for setting up channels
> > >> before offer/answer, but once offer/answer has completed, it lets
> > you
> > >> get a local channel id of correct oddness without having to scan all
> > >> current datachannels to find an unused id value (assuming you're
> > >> mixing styles of creation).
> > >>
> > >> (We may need to add a line to the IETF drafts to cover this case;
> > >> need to check).  The application *could* just scan all known
> > channels
> > >> instead, that's just a pain.  And it really only matters if you mix
> > >> types, which is likely to be rare outside of "create these N
> > >> hard-coded channels at offer/answer time, then have some dynamic
> > >> (automatically-assigned-id) channels that get used later if needed."
> > >>
> > >>>     It doesn't help to tell application B since it can't report the
> > >> information to its browser.  So if application B creates another
> > data
> > >> channel and requests browser selection of a stream id then B's
> > >> browser might end up selecting the same odd stream id, since it has
> > >> no way to know to avoid it.  Not unless we reserve id values
> > >> exclusively for application selection.  Do you agree?  If so, we
> > >> should document this restriction.
> > >>
> > >> When you tell the browser/protocol that a channel has been
> > externally
> > >> negotiated, it will mark that as in-use of course. That's why
> > >> collisions can only happen when the other side creates an
> > externally-
> > >> negotiated channel of the "wrong" oddness in a race with an
> > automatic
> > >> creation from this side.  This is trivially avoided when building an
> > >> app.
> > >>
> > >> Much of this  discussion in the mail I'm replying to is moot, since
> > >> it's based on an incorrect assumption about mixing.
> > >>
> > >>> There is no problem if only browser selection of stream ids is
> > >> allowed before the SCTP association is established since both
> > >> applications can learn which side owns odd/even values after channel
> > >> open is reported to the peer (since there has to be at least one
> > data
> > >> channel created to trigger the establishment of the SCTP
> > association).
> > >> Now application and browser stream id selection can co-exist without
> > >> a hitch.
> > >>> If we assume only application selection of stream ids is allowed
> > >>> with
> > >> in-band negotiation before the SCTP association is established, then
> > >> we can also allow co-existence of application selection and browser
> > >> selection of stream ids after establishment of the SCTP association,
> > >> as long as there is a way for each application to determine DTLS
> > role.
> > >> They can't use the trick in the last paragraph since the browsers
> > >> haven't been asked to assign any stream ids.  Is there an API
> > >> mechanism available to determine DTLS role?  Am I missing something
> > here?
> > >>> With external negotiation, only application selection of stream ids
> > >> can be allowed before DTLS role is determined since the external
> > >> negotiation mechanism needs to be able to report to both peers (and
> > >> browsers) the stream id(s) selected.  Once DTLS role is determined
> > >> then application and browser selection of stream ids could co-exist,
> > >> but requires that the applications learn which DTLS roles were
> > >> negotiated (same issue as above).
> > >>> Interestingly, in-band and external negotiation can co-exist before
> > >> DTLS role is established as long as application selection of stream
> > >> ids is used exclusively.  All forms of in-band and external
> > >> negotiation can co-exist after the SCTP association is established
> > as
> > >> long as the applications know the DTLS roles.
> > >>
> > >> I'm not going to reply line-by-line here, since I think much of this
> > >> is based on a slightly incorrect understanding.
> > >>
> > >>> In summary, the following combinations are allowed:
> > >>>
> > >>> 1) application selection with in-band negotiation before SCTP
> > >>> established and app determines DTLS role
> > >>> 2) browser selection with in-band negotiation before SCTP
> > >>> established
> > >>> 3) application selection with external negotiation before app
> > >>> determines DTLS role
> > >>> 4) application selection with in-band and external negotiation
> > >>> before SCTP established and app determines DTLS role
> > >>> 5) any combination of selection and negotiation after SCTP is
> > >>> established if DTLS role is available to app
> > >> I'd put it this way:
> > >>
> > >> 1)  You can create any number of DataChannels before
> > >> createOffer()/createAnswer() so long as all of them are
> > automatically
> > >> assigned ids (what you call browser selection).  The actual ids are
> > >> assigned after the DTLS roles are known.
> > >>
> > >> 2)  You can create any number of externally-negotiated channels
> > >> before createOffer().  There is no need for them to match DTLS
> > roles.
> > >>
> > >> 3) The answerer must create any externally-negotiated channels from
> > >> its side before the channels can be used, and also SHOULD do so
> > >> before creating automatic channels unless the application has made
> > >> sure somehow
> > >> a collision is impossible/unlikely.   In reality, there's no reason
> > not
> > >> to install the externally-negotiated channels before trying to
> > create
> > >> more, so the point is basically moot. (Note: you don't have to
> > >> install the externally-negotiated channels before createAnswer,
> > >> though normally I'd suggest doing so, just before creating
> > >> automatically-generated
> > >> ones.)
> > >>
> > >> 4) You can create externally-negotiated channels and then
> > >> automatically negotiated channels before calling createOffer.  You
> > >> can even mix them, since the automatically-generated ones will be
> > >> assigned ids later when DTLS role is known (and will avoid any
> > >> already in-use).  I'm not sure this is behavior that anyone would
> > >> *need*, so I see no reason to promote mixing in that way - but it'll
> > work.
> > >>
> > >> 5) Once the association is up, the application can use the method
> > >> above (negotiated=true but no id=N) to allocate ids without fear of
> > >> collision with automatic channels.
> > >>
> > >> This is all emergent from the even/odd selection and letting the
> > >> protocol choose ids when not externally negotiated.
> > >>
> > >> Pseudo-code:
> > >>
> > >> creation:
> > >>       externally-selected-id?
> > >>           yes-> mark channel in use
> > >>               if channel already in use complain and fail
> > >>           no-> dtls role known?
> > >>               yes-> assign unused channel of correct oddness; send
> > OPEN
> > >>               no-> queue channel id selection
> > >>       fire onopen if association is up
> > >>
> > >> incoming OPEN message:
> > >>      if channel already in use
> > >>         yes-> complain (perhaps fire onerror TBD)
> > >>         no-> Mark channel in use; inform application
> > (ondatachannel);
> > >> send ACK
> > >>
> > >> Pretty darn simple.
> > >>
> > >>> If DTLS exchange and SCTP establishment are associated with
> > separate
> > >> offer/answer transactions, there might be a few more combinations to
> > >> consider.  The list also does not describe what is possible if DTLS
> > >> role is not available directly to the apps.
> > >>
> > >> DTLS and SCTP association establishment are async to offer/answer
> > >> (kicked off by successful offer/answer completion).
> > >>
> > >>> The above discussion might be an argument for segregating the
> > stream
> > >> ids available for application and browser selection.  There sure are
> > >> plenty of them.  What do you think?  Then we wouldn't need to make
> > >> DTLS role available to the app and there would only be a few
> > >> restrictions on browser selection (it can't be used for external
> > >> negotiation before DTLS role is determined).  And you could always
> > have an overflow rule.
> > >>> Please correct me if I have missed anything.  Thanks!
> > >>>
> > >>> BR, Richard
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > >>>> Behalf Of Randell Jesup
> > >>>> Sent: Sunday, October 27, 2013 4:46 AM
> > >>>> To: rtcweb@ietf.org
> > >>>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> > >>>> 01.txt
> > >>>>
> > >>>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
> > >>>>> Richard,
> > >>>>>
> > >>>>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
> > >>>>>> Hi Harald,
> > >>>>>> You said: " I can't see a way to mix the two paradigms that
> > >>>>>> guarantees this never happening."  The two paradigms being
> > >>>>>> browser selection vs. application selection of data channel
> > stream ids.
> > >>>> You can.  You just have to be careful.  For example, your
> > >> application
> > >>>> could define that pre-negotiated channels will use 100-110, and
> > >>>> then specify those to both ends before association/offer/answer.
> > >>>> Later
> > >> it
> > >>>> could use data-protocol to add dynamic channels (using even-odd).
> > >>>> Since we've told both ends about 100-110, there's no problem here.
> > >>>> Even/odd is ONLY to avoid glare when both sides decide to open a
> > >>>> channel "at the same time".  If you add a pre-negotiated channel
> > >>>> after initial establishment, it's up to you to avoid colliding
> > with
> > >>>> any existing channels and to avoid colliding with any
> > >>>> in-process-of- creation dynamic
> > >>>> (data-protocol) channels.  There are a number of ways to avoid
> > such
> > >> a
> > >>>> collision safely (never use dynamic channels; use the DTLS role or
> > >> an
> > >>>> existing dynamic channel id to determine even/odd, etc).
> > >>>>
> > >>>>>> My proposal has three elements, which together can guarantee
> > that
> > >>>>>> there are no stream id allocation conflicts between peers:
> > >>>>>>       1. The browser and application select stream ids based on
> > >>>> initial
> > >>>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
> > >>>>>> offerer uses even ids, initial answerer uses odd ids). With this
> > >>>>>> rule, the offering application knows its role immediately
> > without
> > >>>>>> waiting for the DTLS or SDP handshake to occur.
> > >>>>> A similar issue has come up in the discussion of partial
> > >>>>> offers/answers. (Regarding how to assign a=mid values.) And a
> > >>>>> similar solution was proposed.
> > >>>>>
> > >>>>> It was then rejected on the basis that sometimes both "ends"
> > think
> > >>>>> they are offerers or answerers. This comes about as a result of
> > >>>>> signaling-only B2BUAs that play games with O/A on two legs.
> > >>>> Exactly why we went with DTLS roles.
> > >>>>
> > >>>> --
> > >>>> Randell Jesup -- rjesup a t mozilla d o t com
> > >>>>
> > >>>> _______________________________________________
> > >>>> 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
> > >>
> > >> --
> > >> Randell Jesup -- rjesup a t mozilla d o t com
> > >>
> > >> _______________________________________________
> > >> 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
> >
> >
> > --
> > Randell Jesup -- rjesup a t mozilla d o t com
> >
> > _______________________________________________
> > 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
>

--047d7bd7578251e5b304e9fe75ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Note also that DTLS role can change during the lifetime of=
 the session (e.g. a peer that was active can become passive, and vice vers=
a). So we will need to be more specific about when the role is in fact dete=
rmined - perhaps the initial DTLS roles used in the session.





On Wed, Oct 3=
0, 2013 at 1:49 PM, Ejzak, Richard P (Richard) <richard.ejz=
ak@alcatel-lucent.com> wrote:



Hi Randell,

Thanks again for your response.



You asked what I thought would help to clear up any confusion around the st=
ream id assignment issue. =C2=A0I think clearer definitions of the differen=
t types of negotiation, and a few more guidelines in the text would be grea=
t. =C2=A0Please correct any of the following suggested guidelines to avoid =
potential stream id conflicts.





1) For in-band negotiation before establishment of the SCTP association, th=
e application should use only deferred stream id assignment based on DTLS r=
ole. =C2=A0(A little discussion of what this means also wouldn't hurt.)=
 =C2=A0Otherwise a preselected stream id on one side might conflict with a =
deferred selection on the other side.



2) For external negotiation before establishment of the SCTP association, t=
he application must select stream ids without waiting for determination of =
DTLS role. =C2=A0Both peers need to know the stream id allocated to each da=
ta channel via the external negotiation mechanism, so deferred selection ca=
nnot be used.



3) Prior to establishment of the SCTP association, if the application has d=
ata channels to establish using both in-band and external negotiation, exte=
rnal negotiation data channels should always be created before in-band nego=
tiation data channels. =C2=A0This allows the protocol to avoid reusing any =
potentially conflicting stream ids allocated by the external negotiation me=
chanism.



4) After establishment of the SCTP association, in-band and external negoti=
ation can be freely mixed as long as stream id assignment is based on DTLS =
role while avoiding already allocated ids. =C2=A0For application selection =
of stream ids (rather than protocol selection of stream ids), the applicati=
on can determine the DTLS role by examining the exchanged SDP messages.





This paraphrases many of the things in your email that aren't yet in th=
e draft. =C2=A0Some of my confusion was that I was thinking of hybrid negot=
iation mechanisms to allow application selection of stream ids with in-band=
 negotiation before establishment of the SCTP association, but it's far=
 easier to simply disallow that!






BR, Richard



> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg [mailto:rtcweb-bounces@ie=
tf.org] On

> Behalf Of Randell Jesup


> Sent: Tuesday, October 2=
9, 2013 9:39 PM

> To: rtcweb@ietf.org

> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-

> 01.txt

>

> On 10/29/2013 11:06 AM, Ejzak, Richard P (Richard) wrote:

> > Hi Randell,

> > There is clearly a problem with terminology here that is not allo=
wing

> us to converge. =C2=A0Even after your explanation, I believe my

> issues/questions remain valid. =C2=A0I understand that we are discussi=
ng the

> data protocol draft, but we cannot ignore the pure external negotiatio=
n

> case when discussing compatibility issues.

>

> I'm definitely not ignoring it. =C2=A0I'm not specifying what =
the

> application does in the external negotiation; just how that affects th=
e

> protocol stacks at either end. =C2=A0See my pseudo-code below, which h=
as the

> advantage of avoiding english vagueries. =C2=A0I think part of the con=
fusion

> comes from looking/thinking about the JS API, not the IETF protocol.
>

> > When I refer to in-band negotiation, I mean the use of the data
> channel protocol Open message to inform the peer browser that a

> specific stream id has been allocated to a data channel.

>

> Agreed.

>

> > When I refer to external negotiation, I mean the case where the d=
ata

> channel protocol Open message is NOT used but instead both application=
s

> need to use the create data channel method on the API to each browser<=
br>
> to create both ends of each data channel.

>

> Agreed. =C2=A0That's how I've been using it, with what happens=
 to decide on

> what the two apps end up using to initialize the two ends being largel=
y

> out-of-scope to this discussion.

>

> > You apparently also use the term "external negotiation"=
 to apply to

> the case where in-band negotiation needs to be augmented with

> additional communication (i.e., in addition to the Open message)

> between the applications.

>

> No, I didn't mean that to be what the term meant. =C2=A0Where do y=
ou think I

> implied that?

>

> > =C2=A0 =C2=A0I consider this just a special case of in-band negot=
iation. =C2=A0Clear

> terminology to separate these cases would be useful since they have
> very different characteristics. =C2=A0Perhaps "augmented in-band<=
br>
> negotiation" or "hybrid in-band/external negotiation"?<=
br>
> >

> > The application can choose when creating a data channel via the A=
PI

> whether to select the stream id for the data channel or to request the=


> browser to select the stream id. =C2=A0Apparently there are cases when=
 the

> application MUST use only one of these options to guarantee correct
> operation.

>

> There are many ways the application can guarantee correct operation.
> Letting the first side of an external negotiation request the stack
> assign a free id of 'correct' oddness is merely an API helper =
at the JS

> level; it has no impact on the protocol per se, and the application ca=
n

> do it itself (with extra bookkeeping, as I stated). =C2=A0As such, it&=
#39;s only

> mentioned in the JS API spec, not the IETF drafts.

>

> > The application can also specifically request whether to send the=


> data channel Open message once the SCTP association is established. =
=C2=A0It

> is understood that if the browser does not send the Open message that<=
br>
> the peer application must also use its API to create the other end of<=
br>
> the data channel.

>

> This is the external negotiation - both sides tell the stack that a
> channel has been agreed to. =C2=A0 "Agreed to" can be "=
one side send to the

> other a channel definition, and the second side installs it, completin=
g

> the channel." =C2=A0It also can be "both sides (same JS app)=
 know a priori

> that channel id 0 is the reliable control channel used for Foo

> messages, and so inform the stack".

>

> > Without going through all the cases again, I think it's fair =
to say

> that the situation warrants some additional explanation (in the drafts=
)

> to describe these various cases and under what circumstances each is
> allowed. =C2=A0Your pseudo-code does not cover all the cases, and the<=
br>
> situation is more subtle than you describe it to be. =C2=A0The current=


> drafts are far from adequate in this regard.

>

> I think the pseudo-code does cover it - as that's also virtually w=
hat

> we've implemented (running code and all that). ;-) =C2=A0 The othe=
r

> properties discussed emerge from that design and the JS API on top of<=
br>
> it. =C2=A0You can see the actual (rather more messy!) code in

> netwerk/sctp/datachannel/DataChannel.cpp in Firefox. =C2=A0(Need to ha=
ndle

> failures, requirement to allocate more streams from SCTP, JS interface=
,

> etc).

>

> Has my discussion above cleared up any of the confusion? =C2=A0If it h=
as, do

> you have any proposed way to help others avoid that confusion?

>

> Thanks for looking at it before we're at the mics!

>

> =C2=A0 =C2=A0 =C2=A0Randell

>

> >

> > Please just answer one question: How does the application determi=
ne

> its DTLS role (i.e., whether to request even or odd numbers when

> choosing to select stream ids)? =C2=A0Does this need to be inferred fr=
om

> allocated stream ids or can the application determine it directly?

> >

> > Thanks,

> > Richard

> >

> >

> >> -----Original Message-----

> >> From: rtcweb-bounc=
es@ietf.org [mailto:rtcweb-b=
ounces@ietf.org] On

> >> Behalf Of Randell Jesup

> >> Sent: Monday, October 28, 2013 11:45 PM

> >> To: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-prot=
ocol-

> >> 01.txt

> >>

> >> On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:

> >>> Hi Randell,

> >>> Thanks for suggesting the stream id assignment algorithm =
below.

> >> Please bear with me a little longer. =C2=A0I agree that limit=
ed

> >> coexistence of application and browser stream id selection is=


> >> possible, but it seems that there are some significant restri=
ctions.

> >>> Using in-band negotiation, I cannot see any way in which<=
br>
> application

> >> selection and browser selection of stream ids can co-exist be=
fore

> >> DTLS roles are determined. =C2=A0If application A selects an =
odd stream

> >> id, the only way to communicate this selection to application=
 B's

> >> browser is via the in-band open message after the SCTP associ=
ation

> >> has been established.

> >>

> >> No, the application can tell the other end that in conjunctio=
n with

> >> the offer (i.e. in application-specific signaling that accomp=
anies

> >> the offer). =C2=A0Any application using external negotiation =
must, in

> >> fact, handle external negotiation (even if that 'negotiat=
ion' is a

> >> set of hard-coded channel ids).

> >>

> >> Any later non-external-negotiated channel creations will sele=
ct an

> >> unused id of the correct even/oddness (per DTLS role). =C2=A0=
One SHOULD

> >> create all initial-connection-time externally negotiated chan=
nels

> >> before adding any new automatic (data-protocol) ones, in orde=
r to

> >> avoid surprises -- though I'd be rather surprised that an=


> application

> >> would mix them in that way. =C2=A0If the app does, it will wo=
rk fine

> though.

> >>

> >> There is an implicit assumption that anything using external<=
br>
> >> negotiation is either two instances of the same JS app or a
> >> cooperating app and server (those are by far the most common =
cases,

> >> and virtually the only cases), or two different apps that

> nonetheless

> >> know how to talk to each other and negotiate the channels on =
their

> >> own (I'll believe this when I see it, but it might happen=
).

> External

> >> negotiation was added specifically for these pre-cooperating =
cases.

> >>

> >> Also, one point perhaps missed from the W3 spec:

> >>

> >> =C2=A0 =C2=A0 =C2=A07. If the value of the |id

> >>

> >> <http://dev.w3.org/2011/webrtc/editor=
/webrtc.html#dom-datachannel-

> >> id>|

> >> =C2=A0 =C2=A0 =C2=A0attribute is null, initialize it to a val=
ue generated by the

> user

> >> =C2=A0 =C2=A0 =C2=A0agent, according to the WebRTC DataChanne=
l Protocol

> specification,

> >> =C2=A0 =C2=A0 =C2=A0and skip to the next step. Otherwise, if =
the value of the |id

> >>

> >> <http://dev.w3.org/2011/webrtc/editor=
/webrtc.html#dom-datachannel-

> >> id>|

> >> =C2=A0 =C2=A0 =C2=A0attribute is taken by an existing ||RTCDa=
taChannel|

> >> =C2=A0 =C2=A0 =C2=A0<http://dev.w3.org/2011/w=
ebrtc/editor/webrtc.html#idl-def-

> >> RTCDataChannel>|,

> >> =C2=A0 =C2=A0 =C2=A0throw a |TBD| exception and abort these s=
teps.

> >>

> >> Note this means you can create a channel for external negotat=
ion and

> >> let the browser select the id (which you then would tell the =
other

> >> side, and

> >> *they* would specify it to their end). =C2=A0Note that the ID=
 will not be

> >> set until DTLS roles are decided (and that's when onopen =
should fire

> >> as well). =C2=A0This would not be very useful for setting up =
channels

> >> before offer/answer, but once offer/answer has completed, it =
lets

> you

> >> get a local channel id of correct oddness without having to s=
can all

> >> current datachannels to find an unused id value (assuming you=
're

> >> mixing styles of creation).

> >>

> >> (We may need to add a line to the IETF drafts to cover this c=
ase;

> >> need to check). =C2=A0The application *could* just scan all k=
nown

> channels

> >> instead, that's just a pain. =C2=A0And it really only mat=
ters if you mix

> >> types, which is likely to be rare outside of "create the=
se N

> >> hard-coded channels at offer/answer time, then have some dyna=
mic

> >> (automatically-assigned-id) channels that get used later if n=
eeded."

> >>

> >>> =C2=A0 =C2=A0 It doesn't help to tell application B s=
ince it can't report the

> >> information to its browser. =C2=A0So if application B creates=
 another

> data

> >> channel and requests browser selection of a stream id then B&=
#39;s

> >> browser might end up selecting the same odd stream id, since =
it has

> >> no way to know to avoid it. =C2=A0Not unless we reserve id va=
lues

> >> exclusively for application selection. =C2=A0Do you agree? =
=C2=A0If so, we

> >> should document this restriction.

> >>

> >> When you tell the browser/protocol that a channel has been
> externally

> >> negotiated, it will mark that as in-use of course. That's=
 why

> >> collisions can only happen when the other side creates an

> externally-

> >> negotiated channel of the "wrong" oddness in a race=
 with an

> automatic

> >> creation from this side. =C2=A0This is trivially avoided when=
 building an

> >> app.

> >>

> >> Much of this =C2=A0discussion in the mail I'm replying to=
 is moot, since

> >> it's based on an incorrect assumption about mixing.

> >>

> >>> There is no problem if only browser selection of stream i=
ds is

> >> allowed before the SCTP association is established since both=


> >> applications can learn which side owns odd/even values after =
channel

> >> open is reported to the peer (since there has to be at least =
one

> data

> >> channel created to trigger the establishment of the SCTP

> association).

> >> Now application and browser stream id selection can co-exist =
without

> >> a hitch.

> >>> If we assume only application selection of stream ids is =
allowed

> >>> with

> >> in-band negotiation before the SCTP association is establishe=
d, then

> >> we can also allow co-existence of application selection and b=
rowser

> >> selection of stream ids after establishment of the SCTP assoc=
iation,

> >> as long as there is a way for each application to determine D=
TLS

> role.

> >> They can't use the trick in the last paragraph since the =
browsers

> >> haven't been asked to assign any stream ids. =C2=A0Is the=
re an API

> >> mechanism available to determine DTLS role? =C2=A0Am I missin=
g something

> here?

> >>> With external negotiation, only application selection of =
stream ids

> >> can be allowed before DTLS role is determined since the exter=
nal

> >> negotiation mechanism needs to be able to report to both peer=
s (and

> >> browsers) the stream id(s) selected. =C2=A0Once DTLS role is =
determined

> >> then application and browser selection of stream ids could co=
-exist,

> >> but requires that the applications learn which DTLS roles wer=
e

> >> negotiated (same issue as above).

> >>> Interestingly, in-band and external negotiation can co-ex=
ist before

> >> DTLS role is established as long as application selection of =
stream

> >> ids is used exclusively. =C2=A0All forms of in-band and exter=
nal

> >> negotiation can co-exist after the SCTP association is establ=
ished

> as

> >> long as the applications know the DTLS roles.

> >>

> >> I'm not going to reply line-by-line here, since I think m=
uch of this

> >> is based on a slightly incorrect understanding.

> >>

> >>> In summary, the following combinations are allowed:

> >>>

> >>> 1) application selection with in-band negotiation before =
SCTP

> >>> established and app determines DTLS role

> >>> 2) browser selection with in-band negotiation before SCTP=


> >>> established

> >>> 3) application selection with external negotiation before=
 app

> >>> determines DTLS role

> >>> 4) application selection with in-band and external negoti=
ation

> >>> before SCTP established and app determines DTLS role

> >>> 5) any combination of selection and negotiation after SCT=
P is

> >>> established if DTLS role is available to app

> >> I'd put it this way:

> >>

> >> 1) =C2=A0You can create any number of DataChannels before

> >> createOffer()/createAnswer() so long as all of them are

> automatically

> >> assigned ids (what you call browser selection). =C2=A0The act=
ual ids are

> >> assigned after the DTLS roles are known.

> >>

> >> 2) =C2=A0You can create any number of externally-negotiated c=
hannels

> >> before createOffer(). =C2=A0There is no need for them to matc=
h DTLS

> roles.

> >>

> >> 3) The answerer must create any externally-negotiated channel=
s from

> >> its side before the channels can be used, and also SHOULD do =
so

> >> before creating automatic channels unless the application has=
 made

> >> sure somehow

> >> a collision is impossible/unlikely. =C2=A0 In reality, there&=
#39;s no reason

> not

> >> to install the externally-negotiated channels before trying t=
o

> create

> >> more, so the point is basically moot. (Note: you don't ha=
ve to

> >> install the externally-negotiated channels before createAnswe=
r,

> >> though normally I'd suggest doing so, just before creatin=
g

> >> automatically-generated

> >> ones.)

> >>

> >> 4) You can create externally-negotiated channels and then

> >> automatically negotiated channels before calling createOffer.=
 =C2=A0You

> >> can even mix them, since the automatically-generated ones wil=
l be

> >> assigned ids later when DTLS role is known (and will avoid an=
y

> >> already in-use). =C2=A0I'm not sure this is behavior that=
 anyone would

> >> *need*, so I see no reason to promote mixing in that way - bu=
t it'll

> work.

> >>

> >> 5) Once the association is up, the application can use the me=
thod

> >> above (negotiated=3Dtrue but no id=3DN) to allocate ids witho=
ut fear of

> >> collision with automatic channels.

> >>

> >> This is all emergent from the even/odd selection and letting =
the

> >> protocol choose ids when not externally negotiated.

> >>

> >> Pseudo-code:

> >>

> >> creation:

> >> =C2=A0 =C2=A0 =C2=A0 externally-selected-id?

> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yes-> mark channel in u=
se

> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if channel a=
lready in use complain and fail

> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no-> dtls role known?
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yes-> ass=
ign unused channel of correct oddness; send

> OPEN

> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no-> queu=
e channel id selection

> >> =C2=A0 =C2=A0 =C2=A0 fire onopen if association is up

> >>

> >> incoming OPEN message:

> >> =C2=A0 =C2=A0 =C2=A0if channel already in use

> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 yes-> complain (perhaps fire o=
nerror TBD)

> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 no-> Mark channel in use; info=
rm application

> (ondatachannel);

> >> send ACK

> >>

> >> Pretty darn simple.

> >>

> >>> If DTLS exchange and SCTP establishment are associated wi=
th

> separate

> >> offer/answer transactions, there might be a few more combinat=
ions to

> >> consider. =C2=A0The list also does not describe what is possi=
ble if DTLS

> >> role is not available directly to the apps.

> >>

> >> DTLS and SCTP association establishment are async to offer/an=
swer

> >> (kicked off by successful offer/answer completion).

> >>

> >>> The above discussion might be an argument for segregating=
 the

> stream

> >> ids available for application and browser selection. =C2=A0Th=
ere sure are

> >> plenty of them. =C2=A0What do you think? =C2=A0Then we wouldn=
't need to make

> >> DTLS role available to the app and there would only be a few<=
br>
> >> restrictions on browser selection (it can't be used for e=
xternal

> >> negotiation before DTLS role is determined). =C2=A0And you co=
uld always

> have an overflow rule.

> >>> Please correct me if I have missed anything. =C2=A0Thanks=
!

> >>>

> >>> BR, Richard

> >>>

> >>>> -----Original Message-----

> >>>> From: rtcw=
eb-bounces@ietf.org [mailto:=
rtcweb-bounces@ietf.org] On

> >>>> Behalf Of Randell Jesup

> >>>> Sent: Sunday, October 27, 2013 4:46 AM

> >>>> To: rtcweb@ietf.or=
g

> >>>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-d=
ata-protocol-

> >>>> 01.txt

> >>>>

> >>>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:

> >>>>> Richard,

> >>>>>

> >>>>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) w=
rote:

> >>>>>> Hi Harald,

> >>>>>> You said: " I can't see a way to mix=
 the two paradigms that

> >>>>>> guarantees this never happening." =C2=A0=
The two paradigms being

> >>>>>> browser selection vs. application selection o=
f data channel

> stream ids.

> >>>> You can. =C2=A0You just have to be careful. =C2=A0For=
 example, your

> >> application

> >>>> could define that pre-negotiated channels will use 10=
0-110, and

> >>>> then specify those to both ends before association/of=
fer/answer.

> >>>> Later

> >> it

> >>>> could use data-protocol to add dynamic channels (usin=
g even-odd).

> >>>> Since we've told both ends about 100-110, there&#=
39;s no problem here.

> >>>> Even/odd is ONLY to avoid glare when both sides decid=
e to open a

> >>>> channel "at the same time". =C2=A0If you ad=
d a pre-negotiated channel

> >>>> after initial establishment, it's up to you to av=
oid colliding

> with

> >>>> any existing channels and to avoid colliding with any=


> >>>> in-process-of- creation dynamic

> >>>> (data-protocol) channels. =C2=A0There are a number of=
 ways to avoid

> such

> >> a

> >>>> collision safely (never use dynamic channels; use the=
 DTLS role or

> >> an

> >>>> existing dynamic channel id to determine even/odd, et=
c).

> >>>>

> >>>>>> My proposal has three elements, which togethe=
r can guarantee

> that

> >>>>>> there are no stream id allocation conflicts b=
etween peers:

> >>>>>> =C2=A0 =C2=A0 =C2=A0 1. The browser and appli=
cation select stream ids based on

> >>>> initial

> >>>>>> SDP offerer/answerer role rather than DTLS ro=
le (e.g., initial

> >>>>>> offerer uses even ids, initial answerer uses =
odd ids). With this

> >>>>>> rule, the offering application knows its role=
 immediately

> without

> >>>>>> waiting for the DTLS or SDP handshake to occu=
r.

> >>>>> A similar issue has come up in the discussion of =
partial

> >>>>> offers/answers. (Regarding how to assign a=3Dmid =
values.) And a

> >>>>> similar solution was proposed.

> >>>>>

> >>>>> It was then rejected on the basis that sometimes =
both "ends"

> think

> >>>>> they are offerers or answerers. This comes about =
as a result of

> >>>>> signaling-only B2BUAs that play games with O/A on=
 two legs.

> >>>> Exactly why we went with DTLS roles.

> >>>>

> >>>> --

> >>>> Randell Jesup -- rjesup a t mozilla d o t com

> >>>>

> >>>> _______________________________________________

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

> >>

> >> --

> >> Randell Jesup -- rjesup a t mozilla d o t com

> >>

> >> _______________________________________________

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

>

>

> --

> Randell Jesup -- rjesup a t mozilla d o t com

>

> _______________________________________________

> 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





--047d7bd7578251e5b304e9fe75ce--

From basilgohar@librevideo.org  Wed Oct 30 19:36:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2331F11E82F7 for ; Wed, 30 Oct 2013 19:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUmHZ7LjcovH for ; Wed, 30 Oct 2013 19:36:03 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0511E82F2 for ; Wed, 30 Oct 2013 19:36:02 -0700 (PDT)
Received: from [192.168.1.100] (d60-65-38-134.col.wideopenwest.com [65.60.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 156FE65A309 for ; Wed, 30 Oct 2013 22:35:57 -0400 (EDT)
Message-ID: <5271C20A.6000206@librevideo.org>
Date: Wed, 30 Oct 2013 22:35:54 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no>	<52713962.3010201@matthew.at>	 <52714498.1090401@matthew.at>
In-Reply-To: <52714498.1090401@matthew.at>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 02:36:23 -0000

On 10/30/2013 01:40 PM, Matthew Kaufman wrote:
> On 10/30/2013 10:07 AM, Jack Moffitt wrote:
>>>> Do we switch now, or do we give up and live with royalties forever?
>>> This is a little dramatic. One can trivially prove that every technology
>>> required to implement H.264 will lose the protection of the patent
>>> system in
>>> a finite period of time. Much, much sooner than "forever".
>> Selection of royalty-required codecs sets a precedent.
>>
>> jack.
> 
> Prove that VP8 isn't such a thing, and we'd have a clear decision to make.
> 
> Matthew Kaufman

1. Proving the absence of something is usually impossible when you would
have to exhaustively find all uses to rule out the possibility.

2. Proving the presence of something, on the other hand, would be an
exceptionally easy task.  Just find one.

Aside from Google, who's both purchased On2 and also entered into an
agreement with MPEG-LA to STOP their attempts at forming a patent pool
for VP8 (highly indicating there was very little money that could be
sought from VP8, maybe even saving face for them somewhat), it has never
been demonstrated that anyone has paid any licensing fees for VP8 since
Google released it as free software and also issue their patent grant,
for those using it in the VP8 implementation (a condition of their
grant, I believe).

So, just provide us the one (non-contrived, like Ericsson paying Apple
or something like that) case where someone was forced to pay a licensing
fee for VP8 as above, and it would give your suspicion credence.  Absent
that, then it's just FUD (Fear, Uncertainty, and Doubt), and don't
contribute anything useful to the discussion.

-- 
Libre Video
http://librevideo.org

From singer@apple.com  Thu Oct 31 02:14:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C773921F9FDE for ; Thu, 31 Oct 2013 02:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHKd+3nj-v3W for ; Thu, 31 Oct 2013 02:14:16 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id D222721F9EE9 for ; Thu, 31 Oct 2013 02:14:16 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVJ004BY0BSEZH1@mail-out.apple.com> for rtcweb@ietf.org; Thu, 31 Oct 2013 02:14:16 -0700 (PDT)
X-AuditID: 11807166-b7f8b6d000001072-9a-52721f6809b0
Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay8.apple.com (Apple SCV relay) with SMTP id F0.42.04210.86F12725; Thu, 31 Oct 2013 02:14:16 -0700 (PDT)
Received: from [17.153.55.121] (unknown [17.153.55.121]) by chicory.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVJ0038X0BPMW10@chicory.apple.com> for rtcweb@ietf.org; Thu, 31 Oct 2013 02:14:16 -0700 (PDT)
From: David Singer 
In-reply-to: <52716D29.6050403@bbs.darktech.org>
Date: Thu, 31 Oct 2013 10:14:14 +0100
Content-transfer-encoding: quoted-printable
Message-id: <59056F16-7501-40B3-8799-47CA7EBAE99C@apple.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <20131030201651.79401531@lminiero> <949EF20990823C4C85C18D59AA11AD8B0C4743@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52716D29.6050403@bbs.darktech.org>
To: cowwoc 
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCcrJshXxRk0PhX2GLtv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlLPp8lbngrGXF1dmdbA2Mz/W6GDk5JARMJK5M6mGHsMUkLtxb z9bFyMUhJNDPJLH16yJ2CGc+k8TjT3eZuhg5OJgF9CTuX9QCaeAFMnfu3cYKYgsLpEtcmTKN CcRmE1CVeDDnGCOIzSlgINHw8AhYDQtQ/Nr/22wgNrOAsMT3x/dYIGxtiSfvLrBCzLSRuHv3 HRPE3heMEi9fvQcrEhFQkbhx7BbUpbISp889Z5nAKDAL4aRZSE6ahWTsAkbmVYwCRak5iZUW eokFBTmpesn5uZsYwYFXmLaDsWm51SFGAQ5GJR5eBt3CICHWxLLiytxDjBIczEoivNulioKE eFMSK6tSi/Lji0pzUosPMUpzsCiJ85YnAFULpCeWpGanphakFsFkmTg4pRoYTSbP4pix3zu+ rmP31fpT3Vds29y3GxfH8gYWbPu95OWaHItatxqTrKDw9z8Cl//ODSqOyOVQm/ykxstH0pHT YYuhUMTXksWKDdOttU5vlrnO7nnJZrbnmr0/ihkztggllF12mxnj8mxe5o/fho87zOI6TVcd +Pupr3LmtS8Lma5+P7leQMBNiaU4I9FQi7moOBEASVU8tTgCAAA=
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 09:14:21 -0000

On Oct 30, 2013, at 21:33 , cowwoc  wrote:

>=20
>     While I appreciate Cisco's huge contribution in this area, Lorenzo =
and Keith bring up some good points.
>=20
>     How about this approach?
> 	=95 Mandate both codecs as MTI
> 	=95 If either codec becomes problematic (requiring us to pay =
royalties) we simply drop that codec as MTI (implementation becomes =
optional) and searching for a replacement to add as MTI. In the =
meantime, we have that other codec to fall back on.

That is, alas, not the only way a codec becomes problematic.  One can =
also get sued.

>     With this approach we no longer have to depend on the generosity =
of Cisco or Google, and it reduces the incentive of patent trolls (it's =
harder to squeeze us for royalties when we have a fallback).
>=20
> Gili
>=20
> On 30/10/2013 4:09 PM, DRAGE, Keith (Keith) wrote:
>> But to work with VP8 you are also relying on Google's generosity.=20
>>=20
>> Google have IPR on VP8; you are relying on a statement from them they =
will continue to offer it royalty free.=20
>>=20
>> Google and Cisco are both reputable organisations, but ultimately you =
trust who you trust, and I don't see that being different whichever path =
you follow.
>>=20
>> Keith
>>=20
>>=20
>>> -----Original Message-----
>>> From:=20
>>> rtcweb-bounces@ietf.org
>>> =20
>>> [
>>> mailto:rtcweb-bounces@ietf.org
>>> ] On Behalf Of Lorenzo Miniero
>>> Sent: 30 October 2013 19:17
>>> To: Jonathan Rosenberg (jdrosen)
>>> Cc:=20
>>> rtcweb@ietf.org
>>>=20
>>> Subject: Re: [rtcweb] Cisco to open source its H.264=20
>>> implementation and absorb MPEG-LA licensing fees
>>>=20
>>> Il giorno Wed, 30 Oct 2013 12:28:50 +0000 "Jonathan Rosenberg=20
>>> (jdrosen)"=20
>>> 
>>>  ha scritto:
>>>=20
>>>=20
>>>> I'd like to make an announcement material to the=20
>>>>=20
>>> conversations around=20
>>>=20
>>>> MTI video codecs in rtcweb.
>>>>=20
>>>> Cisco is announcing today that we will take our H.264=20
>>>>=20
>>> implementation,=20
>>>=20
>>>> and open source it under BSD license terms. Development and=20
>>>> maintenance will be overseen by a board from industry and the open=20=

>>>> source community.  Furthermore, we will provide a binary=20
>>>>=20
>>> form suitable=20
>>>=20
>>>> for inclusion in applications across a number of different=20
>>>>=20
>>> operating=20
>>>=20
>>>> systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and=20=

>>>> make this binary module available for download from the=20
>>>>=20
>>> Internet. We=20
>>>=20
>>>> will not pass on our MPEG-LA licensing costs for this module, and=20=

>>>> based on the current licensing environment, this will=20
>>>>=20
>>> effectively make=20
>>>=20
>>>> H.264 free for use on supported platforms.
>>>>=20
>>>> We believe that this contribution to the community can help address=20=

>>>> the concerns many have raised around selection of H.264 as MTI. I=20=

>>>> firmly believe that with H.264 we can achieve maximal=20
>>>>=20
>>> interoperability=20
>>>=20
>>>> and now, do it with open source and for free (well, at least for=20
>>>> others - its not free for Cisco :)) More information on the open=20
>>>> source project can be found at=20
>>>> http://www.openh264.org
>>>> , which is=20
>>>> sparse now but more coming soon.
>>>>=20
>>>>=20
>>>> Thx,
>>>> Jonathan R.
>>>>=20
>>>> --
>>>> Jonathan Rosenberg, PhD
>>>> VP, CTO Collaboration
>>>> Cisco Systems
>>>>=20
>>>> jdrosen@cisco.com
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> Am I really the only one not that enthusiastic about this?
>>>=20
>>> Don't get me wrong, I appreciated Cisco's statement. I just=20
>>> don't think it changes anything. It doesn't make H.264 more=20
>>> open (or less closed, if you prefer) than it was before. It=20
>>> just says that, if you download their module from them when=20
>>> installing your stuff, your applications can use it to=20
>>> encode/decode H.264 and not worry about fees (hoping with=20
>>> your fingers crossed that the platform is supported, that=20
>>> is). I still cannot use x264, ffmpeg,=20
>>> randomsuperawesomeopensourceH264codec or even a version of=20
>>> Cisco's H.264 code I compile myself: at least, not if I don't=20
>>> want (or just can't afford) to pay license fees, that is.=20
>>> Which means we're back to step one again. Under those=20
>>> premises, I still think it's not MTI material.
>>>=20
>>> The problem is, I don't want to rely on Cisco's generosity[*]=20
>>> (or anyone else's, for that matter) to work with video,=20
>>> especially when we're building an (allegedly) open web=20
>>> communication framework. What if their module sucks? I'm sure=20
>>> it won't, but I still don't have any choice, there are no=20
>>> free alternatives. Besides, we have no assurance at all that=20
>>> this is something we can rely on. If Cisco wakes up in a=20
>>> couple of months and decides it's all not worth it and shuts=20
>>> all of this down, what happens to WebRTC implementations, to=20
>>> companies that decided to depend on it, to their=20
>>> clients/customers? We wait for another generous "mecenate",=20
>>> while big companies thrive? We complain on social networks?=20
>>> We cry at the moon?  And this is not such a remote
>>> possibility: after all (and I'm quoting one of Jonathan's=20
>>> latest tweets here), "We cannot say forever but unless things=20
>>> change we will continue this indefinitely". If this is=20
>>> supposed to convince me H.264 is now the best solution as MTI=20
>>> for WebRTC then, especially as a developer, I'm not convinced.
>>>=20
>>> I see this opening more as the (welcome, no denying that)=20
>>> software equivalent of daddy pinching you on the cheek and=20
>>> giving you a coupon for your "free ice cream (for a while)".=20
>>> Everyone loves free stuff, I do as well. But IMHO it's not=20
>>> more than that, a free gift to convince the unconvinced.=20
>>> Ancient Romans would have called this "Panem et Circenses",=20
>>> and according to all the enthusiastic posts on Twitter and=20
>>> the like, I guess it still works: people are entertained.
>>>=20
>>> Make the codec REALLY free, without any license fee required=20
>>> at all, and then you'll entertain me as well.
>>>=20
>>> Lorenzo
>>>=20
>>>=20
>>> [*] I must shamefully admit I sniggered a bit when I read the=20
>>> "it's not free for Cisco" part, as if you were really paying=20
>>> for this. I have trouble thinking Cisco doesn't already pay=20
>>> the infamous cap every year.
>>> You're doing something you really don't have to (and we=20
>>> really appreciate this, make no mistake), but that's not the=20
>>> same thing.
>>> _______________________________________________
>>> rtcweb mailing list
>>>=20
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>=20
>>>=20
>>>=20
>> _______________________________________________
>> rtcweb mailing list
>>=20
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.


From cowwoc@bbs.darktech.org  Thu Oct 31 02:32:45 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44C511E820B for ; Thu, 31 Oct 2013 02:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.121
X-Spam-Level: 
X-Spam-Status: No, score=-5.121 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hV4iw2+Wfvm for ; Thu, 31 Oct 2013 02:32:38 -0700 (PDT)
Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id C340311E8211 for ; Thu, 31 Oct 2013 02:32:37 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id a11so1550670qen.8 for ; Thu, 31 Oct 2013 02:32:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G0qJmBpaiQzBZ4bRvlBFRTLjxXfCfL9Iq25Nenh/QLM=; b=SRyO+poSUD3+jKh5RMgTJcZnWCGfoOxK+ek5Q/BVko/UT3G5K2/7SvXSxnebHqjHB9 Wm8WEg4Ta9cFVJ24R4fu/QrlBp9WaGI9k4sh/zuwG7+7IsStiog0fVFDCf3KjUyMrUrc NJGI8kCkFW/4D/rBnSxCUI75jOp6Z5Z0Mx2Dv0RSy8nQuTxSFD5FO4dzxipmnPNra1Q0 46aNu+w4Lnhy+GKQ2Z2qsajqPiESIq5gA57BrWhEtd46XIu5OSK+AOoeYRkK+14SoYMW NA3r1GOovaaQ+txWPGut6pM0dds4WHxkL0cbim2p8sYcC7eIIpwRtgqm/I1psKs8DHpD mhJw==
X-Gm-Message-State: ALoCoQmPfuhOlVcFbVFdDRb1C/U15FX/EZKDC9/HK684ujnJ3zqWruuKTu5/tMwt4ceGx3cMyqHD
X-Received: by 10.49.116.66 with SMTP id ju2mr1117803qeb.94.1383211957237; Thu, 31 Oct 2013 02:32:37 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id r5sm7258153qaj.13.2013.10.31.02.32.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 02:32:36 -0700 (PDT)
Message-ID: <527223B0.5060204@bbs.darktech.org>
Date: Thu, 31 Oct 2013 05:32:32 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: David Singer 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <20131030201651.79401531@lminiero> <949EF20990823C4C85C18D59AA11AD8B0C4743@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52716D29.6050403@bbs.darktech.org> <59056F16-7501-40B3-8799-47CA7EBAE99C@apple.com>
In-Reply-To: <59056F16-7501-40B3-8799-47CA7EBAE99C@apple.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 09:32:45 -0000

On 31/10/2013 5:14 AM, David Singer wrote:
> On Oct 30, 2013, at 21:33 , cowwoc  wrote:
>
>>      While I appreciate Cisco's huge contribution in this area, Lorenzo and Keith bring up some good points.
>>
>>      How about this approach?
>> 	• Mandate both codecs as MTI
>> 	• If either codec becomes problematic (requiring us to pay royalties) we simply drop that codec as MTI (implementation becomes optional) and searching for a replacement to add as MTI. In the meantime, we have that other codec to fall back on.
> That is, alas, not the only way a codec becomes problematic.  One can also get sued.
>
>>      With this approach we no longer have to depend on the generosity of Cisco or Google, and it reduces the incentive of patent trolls (it's harder to squeeze us for royalties when we have a fallback).

     I'm no lawyer but, my understanding is that this could happen no 
matter what codec we choose. Our goal should be to minimize the 
probability of infringement, reduce the profitability of suing, and 
provide a backup plan if we're forced to move off a codec.

     At least with this approach our liability is limited to past 
infringement. They can't blackmail us with unreasonable licensing fees 
because we can switch to the other codec without losing our business. 
This lowers the profitability of suing which reduces the chance that 
they'll sue in the first place. At least, that's my reasoning :)

Gili

From oej@edvina.net  Thu Oct 31 02:36:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217AD21E80D1 for ; Thu, 31 Oct 2013 02:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.081
X-Spam-Level: 
X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF+tZBxtOgmD for ; Thu, 31 Oct 2013 02:36:00 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE421E80A1 for ; Thu, 31 Oct 2013 02:35:51 -0700 (PDT)
Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id B8CDD93C2A2; Thu, 31 Oct 2013 09:35:50 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Thu, 31 Oct 2013 10:35:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <527147FF.5010506@nostrum.com>  
To: "Cullen Jennings (fluffy)" 
X-Mailer: Apple Mail (2.1816)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 09:36:10 -0000

On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy)  =
wrote:

>=20
> On Oct 30, 2013, at 12:20 PM, Leon Geyser  wrote:
>=20
>> Unfortunately like Jonathan pointed out H.264 will only be able to be =
used royalty free on certain(most popular) platforms.
>> To be able to avoid negotiation failure we need a MTI codec that =
every potential now/future browser would be able to implement freely.
>> I like what Cisco did, but the solution seems a bit half-baked.
>>=20
>=20
> I think that Mozilla put it pretty nicely in their blog. What this =
annoucement gives us is not a perfect world. Mozilla is working towards =
a better future but in the mean time, this is the best thing we could =
possibly figure out on how to make the internet today be the best it can =
be for users.=20
>=20

For the Open Source community in general I beleve this is a big move =
forward and I want to thank everyone involved in getting this done. It =
can not have been an easy internal struggle through all layers of the =
company. Everyone will benefit from it.

For us in the Asterisk community I believe this opens up for use of =
video in a whole new way. I've been struggling to find legal ways to do =
things like video IVR for many years. The experiences we get from =
working with this will lead to new applications, regardless of which =
codecs we use in the future.

This statement is outside of the discussion of MTI for webrtc though. I =
still haven't sorted up my views of that part of the discussion...=20

/O=

From silviapfeiffer1@gmail.com  Thu Oct 31 05:11:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99B711E8115 for ; Thu, 31 Oct 2013 05:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-jJ-09gTHL0 for ; Thu, 31 Oct 2013 05:11:53 -0700 (PDT)
Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id DD51B11E8151 for ; Thu, 31 Oct 2013 05:11:51 -0700 (PDT)
Received: by mail-oa0-f51.google.com with SMTP id h1so2892009oag.24 for ; Thu, 31 Oct 2013 05:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=b2j2+tEwpvROObJ1zEoRXqj9EQ6LhEO+K4xC1AyZy3k=; b=Q77bj3kRT3tdnKV37crWTACnR82ZBpFo1RDAZj2Xd7Rh+w/MRAnFF/kY2oE8q4kdeJ Zebek8WZ7N+96OfZBDYhy8+vY4qlLVw/Qz9iwoetx18XXRoyun63UkTSS95T/kpsuJ2y gq1LFeJJ0xRXxe4l+O84p+ribfUPPFsVqU0nU9tBaa174WuKqLRWzSdpThs/ytu/a8p0 OACJcbMsmyqFWvH8TjI8on0Oo3teLvhzp0Q0X2ggKQdiu3y3uv3fveWbQasmUhATBO0r 4NYmRyu5l2VDgCkJcyMIV4UNyIwXt50dxRsoXdpMQn7Yc3X0b8uN6Gcj8mNZNuADFnIr rWew==
X-Received: by 10.60.50.168 with SMTP id d8mr44264oeo.77.1383221511403; Thu, 31 Oct 2013 05:11:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.94.40 with HTTP; Thu, 31 Oct 2013 05:11:31 -0700 (PDT)
In-Reply-To: 
References: <527147FF.5010506@nostrum.com>  
From: Silvia Pfeiffer 
Date: Thu, 31 Oct 2013 23:11:31 +1100
Message-ID: 
To: "Cullen Jennings (fluffy)" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 12:11:54 -0000

On Thu, Oct 31, 2013 at 8:40 AM, Cullen Jennings (fluffy)
 wrote:
>
> On Oct 30, 2013, at 12:20 PM, Leon Geyser  wrote:
>
>> Unfortunately like Jonathan pointed out H.264 will only be able to be us=
ed royalty free on certain(most popular) platforms.
>> To be able to avoid negotiation failure we need a MTI codec that every p=
otential now/future browser would be able to implement freely.
>> I like what Cisco did, but the solution seems a bit half-baked.
>>
>
> I think that Mozilla put it pretty nicely in their blog. What this annouc=
ement gives us is not a perfect world. Mozilla is working towards a better =
future but in the mean time, this is the best thing we could possibly figur=
e out on how to make the internet today be the best it can be for users.


This is a very grand gesture of CISCO.

I'm just a bit cautious, since it looks too good to be true: have you
considered that MPEG LA could change the license conditions on H.264
next year and make this impossible?

Regards,
Silvia.

From fluffy@cisco.com  Thu Oct 31 07:15:31 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6842B11E8167 for ; Thu, 31 Oct 2013 07:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.28
X-Spam-Level: 
X-Spam-Status: No, score=-110.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGeRT88YnXFd for ; Thu, 31 Oct 2013 07:15:25 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 79A3B21F9F3A for ; Thu, 31 Oct 2013 07:15:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4804; q=dns/txt; s=iport; t=1383228924; x=1384438524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=60mHpwVAb7QqV9ktLfMXuyOEaQm56CTzio41T3saA80=; b=S7bkhrNQTShaOB14bh2cMMwBS6qlKBwGMknBIuvwkEXOdk4cOE8Vf+DM gTl+AOzdVvui7AeMU5H6qebuUQ+4cuVmO9rF/alr820wJwSjB8wqTLHRc 0ikfQNwz7N0lxGfi2rb4owRRA0iAf4g3r+jPs6Mx/j9IoDIrzMjL+MKTU U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFALllclKtJXG+/2dsb2JhbABZgweBDL9ogSQWdIIlAQEBAwF0BQULAgEIGAokIRElAgQOBQgTh1oDCQayWg2Ja4xfgj0CMQeDIIEOA4kIjRiOPYU3gyaCKg
X-IronPort-AV: E=Sophos;i="4.93,609,1378857600"; d="scan'208";a="279029342"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 31 Oct 2013 14:15:24 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9VEFNHl013914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 14:15:23 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 09:15:23 -0500
From: "Cullen Jennings (fluffy)" 
To: Silvia Pfeiffer 
Thread-Topic: [rtcweb] On the topic of MTI video codecs
Thread-Index: AQHO1jJVo5rTC0oW2EeRy8AoSXc56ZoPLrIA
Date: Thu, 31 Oct 2013 14:15:23 +0000
Message-ID: 
References: <527147FF.5010506@nostrum.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <57D81E24EFE3CD42BD93AE8825057B52@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 14:15:31 -0000

On Oct 31, 2013, at 6:11 AM, Silvia Pfeiffer 
 wrote:

> On Thu, Oct 31, 2013 at 8:40 AM, Cullen Jennings (fluffy)
>  wrote:
>>=20
>> On Oct 30, 2013, at 12:20 PM, Leon Geyser  wrote:
>>=20
>>> Unfortunately like Jonathan pointed out H.264 will only be able to be u=
sed royalty free on certain(most popular) platforms.
>>> To be able to avoid negotiation failure we need a MTI codec that every =
potential now/future browser would be able to implement freely.
>>> I like what Cisco did, but the solution seems a bit half-baked.
>>>=20
>>=20
>> I think that Mozilla put it pretty nicely in their blog. What this annou=
cement gives us is not a perfect world. Mozilla is working towards a better=
 future but in the mean time, this is the best thing we could possibly figu=
re out on how to make the internet today be the best it can be for users.
>=20
>=20
> This is a very grand gesture of CISCO.
>=20
> I'm just a bit cautious, since it looks too good to be true: have you
> considered that MPEG LA could change the license conditions on H.264
> next year and make this impossible?
>=20
> Regards,
> Silvia.


Yes, I have deeply considered that including discussion with relevant lawye=
rs.=20

I do not see any path where significant changes could be be made that could=
 stop this from continuing. Keep in mind that many of the companies in the =
MPEG LA 264 pool are in favor of just making H.264 RF for use on the intern=
et. Theses same companies, and they include people like, cough, cisco, and =
apple, have to approve changes that happen in the future. I would not be su=
rprised to see the discussion on future changes to the MEPG LA license be a=
round just making the license pool RF. Or perhaps just moving the price of =
the cap up a bit.=20

Now you can say, ok, that is way too good to be true, no big company would =
ever give away valuable IPR. Lets clear up one thing, the amount of money t=
hat any large company gets in royalties from 264 MPEG LA pool is so small i=
t is a joke - and a quick back of the envelope estimate will show you the l=
imits. But ask yourself this instead, Why does Cisco care about webrtc at a=
ll? what would a company like Cisco pay to MPEG LA to improve the ability f=
or lots of companies, particularly small companies or open source projects,=
 to be able to produce, consume, and distribute video on the internet? What=
 would it take to make it so video on the internet was far more important t=
o people's lives than watching cats on skateboards.=20

This whole discussion reminds me of a real blast from the past. In 2000 Cis=
co acquired Vovida (where I worked) and open sourced 100% of the technology=
. People said said Cisco was nuts to acquire that and give it away for fee =
- the numbers were much larger than anything being discussed here. People l=
ike vonage starting using the code. People said "It's a trap" and included =
the appropriate star wars images - Cisco has patents on SIP and is going to=
 get you for using the open source. Cisco did not go after people for using=
 the software and companies like vonage effectively helped drive lots of vo=
ice traffic that resulted in good business for Cisco. Open source helped en=
able that. You might say that was then this is now but you might want to lo=
ok at what we did this month - 2.7 billion for the Sourcefire, a company th=
at's most interesting product is open source.=20

Snort is not a trap, it's exactly what it seem. This is the same - Cisco wa=
nts there to be a video codec that can be widely used on the internet as it=
 exists today - Cisco will continue to want that and will continue to pay M=
PEG LA to make that happen.=20

Which leads of of course to why this codecs and not some other one. We don'=
t believe VP8 is the one that works with the internet today and given the r=
easons have been on this before I don't want to reiterate here. I'd be doin=
g a little dance of joy at the IETF microphone if Daala can meet their goal=
s of better than existing codecs, royalty free, and wide adoption and I rea=
lly hope that happens but it clear that is not here today and this is proje=
ct still at early stage. I'm glad they are working on something better for =
the future. Older codecs like, just for example, H.263 might be easier / ch=
eaper to get to be RF but, sadly they sort of blow chunks. I don't believe =
a business model like apple iTunes, Netflix streaming video, or even Skype =
could be successful in today's market if it had to use a codec like 263, or=
 for that matter any of the older codecs - thus they don't really meet Cisc=
o's goals of widespread viable codec people can use today.=20



From lorenzo@meetecho.com  Thu Oct 31 07:39:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A57611E8163 for ; Thu, 31 Oct 2013 07:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.419
X-Spam-Level: 
X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5RxEmh8UoFh for ; Thu, 31 Oct 2013 07:39:39 -0700 (PDT)
Received: from smtpdg3.aruba.it (smtpdg1.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFE21E805D for ; Thu, 31 Oct 2013 07:39:24 -0700 (PDT)
Received: from lminiero ([143.225.229.175]) by smtpcmd01.ad.aruba.it with bizsmtp id jqfM1m0123niPy701qfMFu; Thu, 31 Oct 2013 15:39:22 +0100
Date: Thu, 31 Oct 2013 15:39:21 +0100
From: Lorenzo Miniero 
To: "Cullen Jennings (fluffy)" 
Message-ID: <20131031153921.2a4635fd@lminiero>
In-Reply-To: 
References: <527147FF.5010506@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=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 14:39:44 -0000

Il giorno Thu, 31 Oct 2013 14:15:23 +0000
"Cullen Jennings (fluffy)"  ha scritto:

> 
> On Oct 31, 2013, at 6:11 AM, Silvia Pfeiffer
>  wrote:
> 
> > On Thu, Oct 31, 2013 at 8:40 AM, Cullen Jennings (fluffy)
> >  wrote:
> >> 
> >> On Oct 30, 2013, at 12:20 PM, Leon Geyser 
> >> wrote:
> >> 
> >>> Unfortunately like Jonathan pointed out H.264 will only be able
> >>> to be used royalty free on certain(most popular) platforms. To be
> >>> able to avoid negotiation failure we need a MTI codec that every
> >>> potential now/future browser would be able to implement freely. I
> >>> like what Cisco did, but the solution seems a bit half-baked.
> >>> 
> >> 
> >> I think that Mozilla put it pretty nicely in their blog. What this
> >> annoucement gives us is not a perfect world. Mozilla is working
> >> towards a better future but in the mean time, this is the best
> >> thing we could possibly figure out on how to make the internet
> >> today be the best it can be for users.
> > 
> > 
> > This is a very grand gesture of CISCO.
> > 
> > I'm just a bit cautious, since it looks too good to be true: have
> > you considered that MPEG LA could change the license conditions on
> > H.264 next year and make this impossible?
> > 
> > Regards,
> > Silvia.
> 
> 
> Yes, I have deeply considered that including discussion with relevant
> lawyers. 
> 
> I do not see any path where significant changes could be be made that
> could stop this from continuing. Keep in mind that many of the
> companies in the MPEG LA 264 pool are in favor of just making H.264
> RF for use on the internet. Theses same companies, and they include
> people like, cough, cisco, and apple, have to approve changes that
> happen in the future. I would not be surprised to see the discussion
> on future changes to the MEPG LA license be around just making the
> license pool RF. Or perhaps just moving the price of the cap up a
> bit. 
> 
> Now you can say, ok, that is way too good to be true, no big company
> would ever give away valuable IPR. Lets clear up one thing, the
> amount of money that any large company gets in royalties from 264
> MPEG LA pool is so small it is a joke - and a quick back of the
> envelope estimate will show you the limits. But ask yourself this
> instead, Why does Cisco care about webrtc at all? what would a
> company like Cisco pay to MPEG LA to improve the ability for lots of
> companies, particularly small companies or open source projects, to
> be able to produce, consume, and distribute video on the internet?
> What would it take to make it so video on the internet was far more
> important to people's lives than watching cats on skateboards. 
> 
> This whole discussion reminds me of a real blast from the past. In
> 2000 Cisco acquired Vovida (where I worked) and open sourced 100% of
> the technology. People said said Cisco was nuts to acquire that and
> give it away for fee - the numbers were much larger than anything
> being discussed here. People like vonage starting using the code.
> People said "It's a trap" and included the appropriate star wars
> images - Cisco has patents on SIP and is going to get you for using
> the open source. Cisco did not go after people for using the software
> and companies like vonage effectively helped drive lots of voice
> traffic that resulted in good business for Cisco. Open source helped
> enable that. You might say that was then this is now but you might
> want to look at what we did this month - 2.7 billion for the
> Sourcefire, a company that's most interesting product is open source. 
> 
> Snort is not a trap, it's exactly what it seem. This is the same -
> Cisco wants there to be a video codec that can be widely used on the
> internet as it exists today - Cisco will continue to want that and
> will continue to pay MPEG LA to make that happen. 
> 
> Which leads of of course to why this codecs and not some other one.
> We don't believe VP8 is the one that works with the internet today
> and given the reasons have been on this before I don't want to
> reiterate here. I'd be doing a little dance of joy at the IETF
> microphone if Daala can meet their goals of better than existing
> codecs, royalty free, and wide adoption and I really hope that
> happens but it clear that is not here today and this is project still
> at early stage. I'm glad they are working on something better for the
> future. Older codecs like, just for example, H.263 might be easier /
> cheaper to get to be RF but, sadly they sort of blow chunks. I don't
> believe a business model like apple iTunes, Netflix streaming video,
> or even Skype could be successful in today's market if it had to use
> a codec like 263, or for that matter any of the older codecs - thus
> they don't really meet Cisco's goals of widespread viable codec
> people can use today. 
> 


Interesting read, but it still doesn't address the concerns I raised
yesterday. Companies like yours may not be doing that much money on
licensee fees, but the fact itself that they exist makes them leverage
they can (whether they will or not) use, and clear the market of those
who can't.

I want to be free to use what I want, and H.264 doesn't allow that:
Cisco is providing a way to do so, but I want to be able to pick
alternatives. Telling the MPEG LA may make H.264 RF some day is smoke:
if the money you're getting is so pathetic, do that for real then and
make us poor guys happy.

Lorenzo


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


From neils@vipadia.com  Thu Oct 31 02:02:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D7B11E821A for ; Thu, 31 Oct 2013 02:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOQLRGu5n7Y3 for ; Thu, 31 Oct 2013 02:02:18 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2821F9FDE for ; Thu, 31 Oct 2013 02:02:17 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id n12so2415276wgh.35 for ; Thu, 31 Oct 2013 02:02:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IZP52jWPExPYbhg8H7+MlH/62tV7ZB5dUG4QdIH1Tco=; b=CGBGsoQAIkYemxK2WGmE7mOiG9X0st1H1zlfl2+Vl6YQBoH6a0UmDHDmCt2gHz7fzg bxWGUP+aEbQZgDfsuEMfFXVDqzjRUhSmgvyELUV3I9tFYymEJZfyc+hlpaVOmb5jgSo7 3ebrnUTBkg5fowsmTpJAE4pV8fVE+3AMSdcliMpNQpIAys+81AyBKU4d/qNivIPl+NgB q1hRday/piy1KBr9ild+P5K/Zq9oFKEU7pQV2l1VMaM4xg0nQiJFeDaTL/j+KBnI+FMy TVJFBRCCS5GLXHjQbYULm21pkS0W2mV+WwbaPExuVWtB+gixcfZR/JIGLllf6R6A+oF4 v0lg==
X-Gm-Message-State: ALoCoQmmBYhgjQqbQMm0exvqVBqcZFq4w73TdFJpTX1ss2HWx2fmPG7y+WGKjK1T1KDTC7KzFwwV
X-Received: by 10.194.8.137 with SMTP id r9mr717957wja.78.1383210136946; Thu, 31 Oct 2013 02:02:16 -0700 (PDT)
Received: from [192.168.0.22] (host-78-150-50-192.as13285.net. [78.150.50.192]) by mx.google.com with ESMTPSA id gg20sm24250648wic.1.2013.10.31.02.02.11 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 02:02:13 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Neil Stratford 
In-Reply-To: <527147FF.5010506@nostrum.com>
Date: Thu, 31 Oct 2013 09:02:09 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <527147FF.5010506@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.1816)
X-Mailman-Approved-At: Thu, 31 Oct 2013 08:02:53 -0700
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 09:02:24 -0000

On 30 Oct 2013, at 17:55, Adam Roach  wrote:

> As Jonathan mentioned earlier, this morning Cisco announced that it =
will be open sourcing an H.264 implementation as well as gratis binary =
modules compiled from that source and hosted by Cisco for download. =
Mozilla will be modifying Firefox to support H.264 by downloading =
Cisco's binary module.


It seems like most of the groundwork is being done here for a real codec =
plugin API which would obviate the need for any particular codec to be =
selected as MTI.

Can we encourage this new codec plugin API to be developed in an open =
way as part of the standards process and therefore be supported in all =
browsers? (Enabling for example the addition of VP8 to a browser that =
may not natively ship with it.)

Neil=

From oej@edvina.net  Thu Oct 31 08:10:29 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF821E8099 for ; Thu, 31 Oct 2013 08:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.354
X-Spam-Level: 
X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UZHkfVxFFAc for ; Thu, 31 Oct 2013 08:10:29 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 1B95C21E808F for ; Thu, 31 Oct 2013 08:10:28 -0700 (PDT)
Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 11EFD93C2A3; Thu, 31 Oct 2013 15:10:28 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Thu, 31 Oct 2013 16:10:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <527147FF.5010506@nostrum.com> 
To: Neil Stratford 
X-Mailer: Apple Mail (2.1816)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 15:10:30 -0000

On 31 Oct 2013, at 10:02, Neil Stratford  wrote:

> On 30 Oct 2013, at 17:55, Adam Roach  wrote:
>=20
>> As Jonathan mentioned earlier, this morning Cisco announced that it =
will be open sourcing an H.264 implementation as well as gratis binary =
modules compiled from that source and hosted by Cisco for download. =
Mozilla will be modifying Firefox to support H.264 by downloading =
Cisco's binary module.
>=20
>=20
> It seems like most of the groundwork is being done here for a real =
codec plugin API which would obviate the need for any particular codec =
to be selected as MTI.
>=20
> Can we encourage this new codec plugin API to be developed in an open =
way as part of the standards process and therefore be supported in all =
browsers? (Enabling for example the addition of VP8 to a browser that =
may not natively ship with it.)

I don't agree. The idea was to create a realtime web platform without =
the need for any plugins or downloadable modules. We've had that for =
ages and it is not a good solution.

I am still for a MTI codec or set of codecs so we always can set up =
video calls, regardless of implementation and if it's possible to =
download by policy or network conditions a specific binary.

/O=

From hta@google.com  Thu Oct 31 11:47:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6921F9DA9 for ; Thu, 31 Oct 2013 11:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level: 
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.326,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+9Pry4qgsWI for ; Thu, 31 Oct 2013 11:47:53 -0700 (PDT)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C6A7B21E808A for ; Thu, 31 Oct 2013 11:47:52 -0700 (PDT)
Received: by mail-ve0-f172.google.com with SMTP id cz12so2403772veb.17 for ; Thu, 31 Oct 2013 11:47:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=eJVV0DfYzzEXor8MLKGtn44Qpyp7pX1p1Du2batYkmY=; b=G1POrir4XCKHILm9wOyrJ4v6jI0ylTraAAsjgcWZJPYzYIERcWyIFyKkbSQK/PDn/1 7CtQm/21wLv+nmLevWlb8azXmrvVDVloqDWVarbhPaexyABr/3l7UhbrCeSlQGZUcHpm LNPiynefe2CZ8jsFLO7h0eiQp7TADR2FRAOGPe2HqkCzkGMHJGuBedJF79hDfGiqOz63 NubybdzD6g/feOTEODj7GXsn8u8X2fATZDm6U3hUge0COuzkPRcNlahB+gfbhw2GdfPH R/NFh/p3U11sH9fzrE/1a2W6QJcG5C9gQ/CN4byKn7YPqMgt99kMXrO8lX0u556RnZ5E Mrpw==
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=eJVV0DfYzzEXor8MLKGtn44Qpyp7pX1p1Du2batYkmY=; b=mjL4V+8/eKSAAXt/ZPQrj11xlzpWdte6DTdaCHdAQXPl6vUPjhFB/WqqaBkuM7txUl RGZiGfqB+Y9fhWC6J+iPRGPbUk5N1Mhj2rX625iVzTuqgPbCHUmLxB/WVzi0zx4mRKAC +JL2IfzVEQEhtdZfRBxPC4uH+Sp+ENRRd48pYQg9PdO/35P0sprwAjCmVewqpw8VWid+ tT4Fg435k/b4wX6PuZR5zSpc2MCioUQaynrzTlaj74JrfKXsoAb1qfkf3yQ5CoDxB052 e5nUJsVoPG5+EEXOhNPhkrEjRpoFSnEl+qEnmL960cJ4JkGfp2ZCIZIAr5bFLKJrTXjd cKmg==
X-Gm-Message-State: ALoCoQn2DDs/FyVqWduDd7aewtSxgl3wDRsBuj0YzUNyKLmhJXjaz9q+usnuJ4OHa2gr4STP7aC1CLjuOc/ozSSxLnrxrlUAE3MtCxMjaBd1fSiq9ZvlZ2Hb9dvhOG2UDEOF8uW1lunJUNiOo+0kQQnvyFq2oVSLQvfun1DUHzG72+XFjfrw5eobIPXWuFw1jqYxnzKMLTXk
X-Received: by 10.52.32.66 with SMTP id g2mr2595921vdi.14.1383245272018; Thu, 31 Oct 2013 11:47:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.176.8 with HTTP; Thu, 31 Oct 2013 11:47:31 -0700 (PDT)
From: Harald Alvestrand 
Date: Thu, 31 Oct 2013 19:47:31 +0100
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=bcaec51d255e13a0e004ea0de328
Subject: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 18:47:53 -0000

--bcaec51d255e13a0e004ea0de328
Content-Type: text/plain; charset=UTF-8

We congratulate Cisco on their intention to make an open source H.264 codec
available and usable by the community. We look forward to seeing the result
of this effort.

Google still believes that VP8 - a freely available, fully open,
high-quality video codec that you can download, compile for your platform,
include in your binary, distribute and put into production today - is the
best choice of a Mandatory to Implement video codec for the WebRTC effort.

Harald (sending this from my Google address)

--bcaec51d255e13a0e004ea0de328
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


We congratulate Cisco on their intention to m=
ake an open source H.264 codec available and usable by the community. We lo=
ok forward to seeing the result of this effort.



Google still believes that=
 VP8 - a freely available, fully open, high-quality video codec that you ca=
n download, compile for your platform, include in your binary, distribute a=
nd put into production today - is the best choice of a Mandatory to Impleme=
nt video codec for the WebRTC effort.



Harald (sending this from my Google address)





--bcaec51d255e13a0e004ea0de328--

From miconda@gmail.com  Thu Oct 31 13:51:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395DF11E81E4 for ; Thu, 31 Oct 2013 13:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTs0B8jY9GgA for ; Thu, 31 Oct 2013 13:51:09 -0700 (PDT)
Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15721F9E28 for ; Thu, 31 Oct 2013 13:51:08 -0700 (PDT)
Received: by mail-ea0-f170.google.com with SMTP id q10so1411701eaj.1 for ; Thu, 31 Oct 2013 13:51:08 -0700 (PDT)
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=P1VqA/kPRkrueURMvBKP7pYgUNwNquQWiqL7CBfYkBo=; b=Kfgyui8twPtpjWwvLJdcn32Z+UnoIMt1BXBzrKQtoFbm2+6MOxuL7/ZBsq7hjJYBpE oJU1kw37+iw0mrZwW3gCOF7EQMQwHU+cxFe1HIjOTJsAqM4aPRaM+YrVmSXdy9qeIlvB uWcMMGl21Olmw3/M71KjC1YHRxaue0HXjweBLiF2zb2ByA0Fvqj/PCrXdaTu2o7UkWxO pmtjcnOM8D/a/uNXk9h8U2FBiNK9hBTrQ3AdKiHnVq8IdR369TWL8QPXsLHpiK6PrmnU mS7c8SFbzJUljQv8u8IqdNxuXz4GhTdd3Q2onw8KoN3z9Rqi82ux3C8MHfm2cG5kNac/ Rj4g==
X-Received: by 10.15.49.6 with SMTP id i6mr1048405eew.109.1383252668023; Thu, 31 Oct 2013 13:51:08 -0700 (PDT)
Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id a1sm13731096eem.1.2013.10.31.13.51.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 13:51:05 -0700 (PDT)
Message-ID: <5272C2B7.2080907@gmail.com>
Date: Thu, 31 Oct 2013 21:51:03 +0100
From: Daniel-Constantin Mierla 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "Olle E. Johansson" ,  "Cullen Jennings (fluffy)" 
References: <527147FF.5010506@nostrum.com>		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2013 20:51:10 -0000

On 10/31/13 10:35 AM, Olle E. Johansson wrote:
> On 30 Oct 2013, at 22:40, Cullen Jennings (fluffy)  wrote:
>
>> On Oct 30, 2013, at 12:20 PM, Leon Geyser  wrote:
>>
>>> Unfortunately like Jonathan pointed out H.264 will only be able to be used royalty free on certain(most popular) platforms.
>>> To be able to avoid negotiation failure we need a MTI codec that every potential now/future browser would be able to implement freely.
>>> I like what Cisco did, but the solution seems a bit half-baked.
>>>
>> I think that Mozilla put it pretty nicely in their blog. What this annoucement gives us is not a perfect world. Mozilla is working towards a better future but in the mean time, this is the best thing we could possibly figure out on how to make the internet today be the best it can be for users.
>>
> For the Open Source community in general I beleve this is a big move forward and I want to thank everyone involved in getting this done. It can not have been an easy internal struggle through all layers of the company. Everyone will benefit from it.
>
> For us in the Asterisk community I believe this opens up for use of video in a whole new way.
To my understanding, the release of the codec is for webrtc only, and 
particularly for client side/browsers. For clarification, is this 
codec/blob available to use for free in any application, no matter its 
relation with webrtc sessions?

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -


From miconda@gmail.com  Thu Oct 31 14:08:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D981821E80A9 for ; Thu, 31 Oct 2013 14:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0uNDo2Ihq3m for ; Thu, 31 Oct 2013 14:08:34 -0700 (PDT)
Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B134121E80FF for ; Thu, 31 Oct 2013 14:08:27 -0700 (PDT)
Received: by mail-ee0-f41.google.com with SMTP id e53so1654839eek.14 for ; Thu, 31 Oct 2013 14:08:26 -0700 (PDT)
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=dgtH1//cyFevOQOkA4FZEs8385eLyW/55P0MlVibnsM=; b=qmevsqrLwUzxHluLtACYznDF1bNFLqNvU0B7vtEibVnAIz00G0DaipJ+3iTLBe4BQe IUUJwMTRFwDN+K9Kbm09y9bZURir01X6A694i6zkNxCU71Vikf5ptaGtBrx8ENqystQq bdLqTwQGsPAop+KvFntSquh3JG6jbj0SVKVR3hqSFTQi2Jooeu0NL45cwQdA5BOLCYXi pEtrZ3wkC8DRX+NcoTGMz+6Aqeh4eiGeU04EtjcXwZVNRymR4KDNNJlvnoI+xLEQOdta O6C7PtvWtg7jxsCiEbVzEM68iWSbR0r0GIL/TB9oh2UcCFISqSo9yDQay7GdRqdbfK0E 5uhg==
X-Received: by 10.14.42.6 with SMTP id i6mr4965395eeb.65.1383253706704; Thu, 31 Oct 2013 14:08:26 -0700 (PDT)
Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id bn13sm14014676eeb.11.2013.10.31.14.08.24 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 14:08:25 -0700 (PDT)
Message-ID: <5272C6C8.3070006@gmail.com>
Date: Thu, 31 Oct 2013 22:08:24 +0100
From: Daniel-Constantin Mierla 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "Olle E. Johansson" , Neil Stratford 
References: <527147FF.5010506@nostrum.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2013 21:08:37 -0000

On 10/31/13 4:10 PM, Olle E. Johansson wrote:
> On 31 Oct 2013, at 10:02, Neil Stratford  wrote:
>
>> On 30 Oct 2013, at 17:55, Adam Roach  wrote:
>>
>>> As Jonathan mentioned earlier, this morning Cisco announced that it will be open sourcing an H.264 implementation as well as gratis binary modules compiled from that source and hosted by Cisco for download. Mozilla will be modifying Firefox to support H.264 by downloading Cisco's binary module.
>>
>> It seems like most of the groundwork is being done here for a real codec plugin API which would obviate the need for any particular codec to be selected as MTI.
>>
>> Can we encourage this new codec plugin API to be developed in an open way as part of the standards process and therefore be supported in all browsers? (Enabling for example the addition of VP8 to a browser that may not natively ship with it.)
> I don't agree. The idea was to create a realtime web platform without the need for any plugins or downloadable modules. We've had that for ages and it is not a good solution.
>
> I am still for a MTI codec or set of codecs so we always can set up video calls, regardless of implementation and if it's possible to download by policy or network conditions a specific binary.
Downloading a binary opens doors for tons of risks, knowing that lot of 
carriers do caching or interpose themselves (e.g., it happens very 
commonly for dns to redirect you to some adds page when typing an 
invalid domain), thus is easy to replace the original source, so a 
rather complex security mechanism has to be put in place.

Even the argument that the code can be compiled and signatures compared 
is not really feasible - simply it cannot be done by mobile devices - 
they don't have the sdk installed.

I can't see an impediment for Cisco to grant the main web browsers 
(e.g., Mozilla, ...) to simply have the codec built in, using the BSD 
open sourced codec. If the webrtc is going to the masses, then the 
yearly fee cap will be reached anyhow.

For the sake of clarification, I am not in a favor of a particular video 
codec, but the one to be selected has to be embedded directly in all 
browsers, specially in those open source, for full transparency. 
Otherwise, better as Neil said, make it a plugin API so there can be 
many providers - with binary blob download, there has to be an API 
anyhow, make that the standard.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -


From ekr@rtfm.com  Thu Oct 31 14:28:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D088A21F9F2D for ; Thu, 31 Oct 2013 14:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.737
X-Spam-Level: 
X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIuOhN-8Mffb for ; Thu, 31 Oct 2013 14:28:33 -0700 (PDT)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7C00721F9F23 for ; Thu, 31 Oct 2013 14:28:28 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id u57so3242499wes.18 for ; Thu, 31 Oct 2013 14:28:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gyXVRwK42aqmvZskkafd5QMIoLdylXwdk7FxgO8ufzo=; b=eVIoZWS8x0Af7g5K9nlnv0g6SbcJgmokmkGlrZ9ZXTDctdXqDFAF5BjiYQyakM4IXj nYO2I1V7VS4Lw5xLUHm/KOD0zj4ks7ITc6/SWSF9OyzOMKyCKJi0kDgD4lXbJQIkIF4g 8il2+TnTPRQ2Adkusyb581B38qJOSnFvWXLlgBALyNcCN6Zpuqy+XQNB6WcjDUnLeDzq TSWNgXwkPEvIVzZDaPsXe9SQSncvauaTQczsyfpkwpldeMjDv4keWGL6xJnBESA+IG9M ecRXOCbw1Qa1JyaMX/QBMHLWpM7MuigIOJI+m+8qLs596s7NlO8kI7jGz/h/RStHVCSx nHxw==
X-Gm-Message-State: ALoCoQkKffwGi9GTLcKeneM3CeR/6aIS5RBBeGK/+OzQ7/Cak4QerPxnnP5vxy+J4y+uqZzlXSKk
X-Received: by 10.180.24.137 with SMTP id u9mr50618wif.5.1383254907474; Thu, 31 Oct 2013 14:28:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 31 Oct 2013 14:27:47 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <5272C6C8.3070006@gmail.com>
References: <527147FF.5010506@nostrum.com>   <5272C6C8.3070006@gmail.com>
From: Eric Rescorla 
Date: Thu, 31 Oct 2013 14:27:47 -0700
Message-ID: 
To: miconda@gmail.com
Content-Type: multipart/alternative; boundary=f46d04447f6764f69204ea1021ab
Cc: "rtcweb@ietf.org" , Neil Stratford 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 21:28:39 -0000

--f46d04447f6764f69204ea1021ab
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla  wrote:

>
> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>
>> On 31 Oct 2013, at 10:02, Neil Stratford  wrote:
>>
>>  On 30 Oct 2013, at 17:55, Adam Roach  wrote:
>>>
>>>  As Jonathan mentioned earlier, this morning Cisco announced that it
>>>> will be open sourcing an H.264 implementation as well as gratis binary
>>>> modules compiled from that source and hosted by Cisco for download. Mozilla
>>>> will be modifying Firefox to support H.264 by downloading Cisco's binary
>>>> module.
>>>>
>>>
>>> It seems like most of the groundwork is being done here for a real codec
>>> plugin API which would obviate the need for any particular codec to be
>>> selected as MTI.
>>>
>>> Can we encourage this new codec plugin API to be developed in an open
>>> way as part of the standards process and therefore be supported in all
>>> browsers? (Enabling for example the addition of VP8 to a browser that may
>>> not natively ship with it.)
>>>
>> I don't agree. The idea was to create a realtime web platform without the
>> need for any plugins or downloadable modules. We've had that for ages and
>> it is not a good solution.
>>
>> I am still for a MTI codec or set of codecs so we always can set up video
>> calls, regardless of implementation and if it's possible to download by
>> policy or network conditions a specific binary.
>>
> Downloading a binary opens doors for tons of risks, knowing that lot of
> carriers do caching or interpose themselves (e.g., it happens very commonly
> for dns to redirect you to some adds page when typing an invalid domain),
> thus is easy to replace the original source, so a rather complex security
> mechanism has to be put in place.
>

Solely on the security question...

I'm not sure what you mean by "rather complex". What I would expect is to
have signed
binaries. This addresses the question of attack from the network and is how
we
intend to handle things in Firefox.

Note that any product that auto-updates (like Firefox and Chrome) already
need
to have some mechanism for verifying that the things they download are
correct.



> Even the argument that the code can be compiled and signatures compared is
> not really feasible - simply it cannot be done by mobile devices - they
> don't have the sdk installed.
>

I don't see why this would be needed. The containing program (e.g., the
browser) doesn't compile, it just does signature verification.

Obviously, this only addresses the question of attack from the network,
not malicious binaries constructed by Cisco. I expect that to be addressed
by third parties doing verified builds and comparing the binaries.
Presumably,
one could invent some countersignature mechanism to allow clients to
verify that a specific third party had verified a build.

-Ekr

--f46d04447f6764f69204ea1021ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <miconda=
@gmail.com> wrote:





On 10/31/13 4:10 PM, Olle E. Johansson wrote:



On 31 Oct 2013, at 10:02, Neil Stratford <neils@vipadia.com> wrote:





On 30 Oct 2013, at 17:55, Adam Roach <adam@nostrum.com> wrote:





As Jonathan mentioned earlier, this morning Cisco announced that it will be=
 open sourcing an H.264 implementation as well as gratis binary modules com=
piled from that source and hosted by Cisco for download. Mozilla will be mo=
difying Firefox to support H.264 by downloading Cisco's binary module.<=
br>






It seems like most of the groundwork is being done here for a real codec pl=
ugin API which would obviate the need for any particular codec to be select=
ed as MTI.



Can we encourage this new codec plugin API to be developed in an open way a=
s part of the standards process and therefore be supported in all browsers?=
 (Enabling for example the addition of VP8 to a browser that may not native=
ly ship with it.)





I don't agree. The idea was to create a realtime web platform without t=
he need for any plugins or downloadable modules. We've had that for age=
s and it is not a good solution.



I am still for a MTI codec or set of codecs so we always can set up video c=
alls, regardless of implementation and if it's possible to download by =
policy or network conditions a specific binary.



Downloading a binary opens doors for tons of risks, knowing that lot of car=
riers do caching or interpose themselves (e.g., it happens very commonly fo=
r dns to redirect you to some adds page when typing an invalid domain), thu=
s is easy to replace the original source, so a rather complex security mech=
anism has to be put in place.




Solely on the security question...

I'm not sure what you mean by "rather complex&qu=
ot;. What I would expect is to have signed
binaries. This address=
es the question of attack from the network and is how we



intend to handle things in Firefox.

Note that=
 any product that auto-updates (like Firefox and Chrome) already need
=

to have some mechanism for verifying that the things they download are=
 correct.




=A0

Even the argument that the code can be compiled and signatures compared is =
not really feasible - simply it cannot be done by mobile devices - they don=
't have the sdk installed.

I don=
9;t see why this would be needed. The containing program (e.g., the



browser) doesn't compile, it just does signature verification.

Obviously, this only addresses the question of attack=
 from the network,
not malicious binaries constructed by Cisco. I=
 expect that to be addressed



by third parties doing verified builds and comparing the binaries. Pre=
sumably,
one could invent some countersignature mechanism to allo=
w clients to
verify that a specific third party had verified a bu=
ild.




-Ekr



--f46d04447f6764f69204ea1021ab--

From miconda@gmail.com  Thu Oct 31 14:40:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5328C21F9E3B for ; Thu, 31 Oct 2013 14:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yYbWEi7lP9H for ; Thu, 31 Oct 2013 14:40:24 -0700 (PDT)
Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9090521F9EF2 for ; Thu, 31 Oct 2013 14:40:20 -0700 (PDT)
Received: by mail-ee0-f54.google.com with SMTP id c50so1002615eek.13 for ; Thu, 31 Oct 2013 14:40:19 -0700 (PDT)
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=0YIn02QmbK01WSlcM87af065gu1mzrTa/eCqa7zd8JM=; b=sMD3C6x1uFCy89MGs4DOHwxZI188U9dIPECZ5IQ5p0IU7FA5pM227c/otzLX7Jbtz+ VM1/l6a3csS/V2+k07NQ8jnrzkzAlZ8aMA0mR16+KAX8uyrvDqYJFrHQgnNF5YLP1lzW 8SDXW/vrVjk/PN5f+l1SCtlO7Jn/Ussb5ZK5K0sjCNlfRPlwjmVEgKlgmEtmt5eKGIPM mrbD7shbfT/3GTSjVYXrFnxODHoviIu4qgolsYV8kvxPGLXGBTmPkwab6bInjdIphZRW XZDb7Ne0Gt9rc3qOIoVqQykgBAnmlx8rfwe+hnQ3HP205lggVBuVOm4GQDMiDOCtcSRk jTYA==
X-Received: by 10.14.219.4 with SMTP id l4mr98842eep.37.1383255619615; Thu, 31 Oct 2013 14:40:19 -0700 (PDT)
Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id j7sm14363935eeo.15.2013.10.31.14.40.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 14:40:18 -0700 (PDT)
Message-ID: <5272CE40.4080908@gmail.com>
Date: Thu, 31 Oct 2013 22:40:16 +0100
From: Daniel-Constantin Mierla 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Eric Rescorla 
References: <527147FF.5010506@nostrum.com>   <5272C6C8.3070006@gmail.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050100080701070303070509"
Cc: "rtcweb@ietf.org" , Neil Stratford 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2013 21:40:26 -0000

This is a multi-part message in MIME format.
--------------050100080701070303070509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 10/31/13 10:27 PM, Eric Rescorla wrote:
>
>
>
> On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla 
> > wrote:
>
>
>     On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>
>         On 31 Oct 2013, at 10:02, Neil Stratford          > wrote:
>
>             On 30 Oct 2013, at 17:55, Adam Roach              > wrote:
>
>                 As Jonathan mentioned earlier, this morning Cisco
>                 announced that it will be open sourcing an H.264
>                 implementation as well as gratis binary modules
>                 compiled from that source and hosted by Cisco for
>                 download. Mozilla will be modifying Firefox to support
>                 H.264 by downloading Cisco's binary module.
>
>
>             It seems like most of the groundwork is being done here
>             for a real codec plugin API which would obviate the need
>             for any particular codec to be selected as MTI.
>
>             Can we encourage this new codec plugin API to be developed
>             in an open way as part of the standards process and
>             therefore be supported in all browsers? (Enabling for
>             example the addition of VP8 to a browser that may not
>             natively ship with it.)
>
>         I don't agree. The idea was to create a realtime web platform
>         without the need for any plugins or downloadable modules.
>         We've had that for ages and it is not a good solution.
>
>         I am still for a MTI codec or set of codecs so we always can
>         set up video calls, regardless of implementation and if it's
>         possible to download by policy or network conditions a
>         specific binary.
>
>     Downloading a binary opens doors for tons of risks, knowing that
>     lot of carriers do caching or interpose themselves (e.g., it
>     happens very commonly for dns to redirect you to some adds page
>     when typing an invalid domain), thus is easy to replace the
>     original source, so a rather complex security mechanism has to be
>     put in place.
>
>
> Solely on the security question...
>
> I'm not sure what you mean by "rather complex". What I would expect is 
> to have signed
> binaries. This addresses the question of attack from the network and 
> is how we
> intend to handle things in Firefox.
>
> Note that any product that auto-updates (like Firefox and Chrome) 
> already need
> to have some mechanism for verifying that the things they download are 
> correct.

Typically the updates you mentioned are done from the project's sites, 
so that is easier to handle. Now there is a third party involved, 
requiring some sync'ing between Cisco and browser's sites. It's like a 
menage-a-trios, pretty dirty affair. I wonder why flash plugin was not 
loaded this way, it was always free -- but had to be 
downloaded/installed explicitly by users.

>
>
>     Even the argument that the code can be compiled and signatures
>     compared is not really feasible - simply it cannot be done by
>     mobile devices - they don't have the sdk installed.
>
>
> I don't see why this would be needed. The containing program (e.g., the
> browser) doesn't compile, it just does signature verification.
>
> Obviously, this only addresses the question of attack from the network,
> not malicious binaries constructed by Cisco. I expect that to be addressed
> by third parties doing verified builds and comparing the binaries. 
> Presumably,
> one could invent some countersignature mechanism to allow clients to
> verify that a specific third party had verified a build.
If we get to 'one could invent some ...' and wait for that, better wait 
for a pure open source video codec. Mozilla is working in that direction 
anyhow.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -


--------------050100080701070303070509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 10/31/13 10:27 PM, Eric Rescorla
      wrote:

    

    

      


        


          

          
On Thu, Oct 31, 2013 at 2:08 PM,
            Daniel-Constantin Mierla <miconda@gmail.com> wrote:

            

              

                


                  On 10/31/13 4:10 PM, Olle E. Johansson wrote:

                  

                    On 31 Oct 2013, at 10:02, Neil Stratford <neils@vipadia.com>
                    wrote:

                    

                    

                      On 30 Oct 2013, at 17:55, Adam Roach <adam@nostrum.com>
                      wrote:

                      

                      

                        As Jonathan mentioned earlier, this morning
                        Cisco announced that it will be open sourcing an
                        H.264 implementation as well as gratis binary
                        modules compiled from that source and hosted by
                        Cisco for download. Mozilla will be modifying
                        Firefox to support H.264 by downloading Cisco's
                        binary module.

                      

                      

                      It seems like most of the groundwork is being done
                      here for a real codec plugin API which would
                      obviate the need for any particular codec to be
                      selected as MTI.

                      

                      Can we encourage this new codec plugin API to be
                      developed in an open way as part of the standards
                      process and therefore be supported in all
                      browsers? (Enabling for example the addition of
                      VP8 to a browser that may not natively ship with
                      it.)

                    

                    I don't agree. The idea was to create a realtime web
                    platform without the need for any plugins or
                    downloadable modules. We've had that for ages and it
                    is not a good solution.

                    

                    I am still for a MTI codec or set of codecs so we
                    always can set up video calls, regardless of
                    implementation and if it's possible to download by
                    policy or network conditions a specific binary.

                  

                

              

              Downloading a binary opens doors for tons of risks,
              knowing that lot of carriers do caching or interpose
              themselves (e.g., it happens very commonly for dns to
              redirect you to some adds page when typing an invalid
              domain), thus is easy to replace the original source, so a
              rather complex security mechanism has to be put in place.

            

            


            

            
Solely on the security question...

            


            

            
I'm not sure what you mean by "rather complex". What I
              would expect is to have signed

            
binaries. This addresses the question of attack from
              the network and is how we

            
intend to handle things in Firefox.

            


            

            
Note that any product that auto-updates (like Firefox
              and Chrome) already need

            
to have some mechanism for verifying that the things
              they download are correct.

          

        

      

    

    

    Typically the updates you mentioned are done from the project's
    sites, so that is easier to handle. Now there is a third party
    involved, requiring some sync'ing between Cisco and browser's sites.
    It's like a menage-a-trios, pretty dirty affair. I wonder why flash
    plugin was not loaded this way, it was always free -- but had to be
    downloaded/installed explicitly by users.

    

    

      

        

          

            


            

            
 

            

            

              Even the argument that the code can be compiled and
              signatures compared is not really feasible - simply it
              cannot be done by mobile devices - they don't have the sdk
              installed.

            

            


            

            
I don't see why this would be needed. The containing
              program (e.g., the

            
browser) doesn't compile, it just does signature
              verification.

            


            

            
Obviously, this only addresses the question of attack
              from the network,

            
not malicious binaries constructed by Cisco. I expect
              that to be addressed

            
by third parties doing verified builds and comparing
              the binaries. Presumably,

            
one could invent some countersignature mechanism to
              allow clients to

            
verify that a specific third party had verified a
              build.

          

        

      

    

    If we get to 'one could invent some ...' and wait for that, better
    wait for a pure open source video codec. Mozilla is working in that
    direction anyhow.

    

    Daniel

    
-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
  - more details about Kamailio trainings at http://www.asipto.com -


  


--------------050100080701070303070509--

From ekr@rtfm.com  Thu Oct 31 14:50:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11F411E8254 for ; Thu, 31 Oct 2013 14:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.461
X-Spam-Level: 
X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guT9IjXOCv0R for ; Thu, 31 Oct 2013 14:50:48 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id C5CB611E81C0 for ; Thu, 31 Oct 2013 14:50:45 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id z12so3349908wgg.0 for ; Thu, 31 Oct 2013 14:50:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6RkDpVSr+7UwRFylbRWeuFlLisLTJfwFbrGQwbHcu7w=; b=Hh2vX6hBwTCnsz3/eVT2SSxaVwqr4ZG9Fu+LrOK9B64a+GT3HFqFO5V9KjU7pPfAGL G8d9qe/xk3RoaK7jLROKF/LZLtpICt/4YV5dM1GjdGX1nOeYKeHg84Vth2WCAxeHqOng Uz4kH2hP2DCHfZA/VdPEJVu2bFHL2pMKdnpeu9sZpTWNPEoK3a4o4+DMDOa3ydvHeF9f Ajs4DyEig4aLEsBKtEEBHt7jYULMq+e2Bo57QoNZ1+H8pk5ZOvUD8v5LY0bCBEz5IAX1 /tvvNNTwZtQA3Hu33p3EwTKIZJDGM3yZw/r95gnm6MPESpGiBGhpYo5Jx5HDXuBYnI+a sVOQ==
X-Gm-Message-State: ALoCoQlRIkVcGt0TZXlCLV1sLE/K3ZOHax0cpsNYi6JJq22euIPQ/EbjAiBTNEXi3p/+R/PyZsCt
X-Received: by 10.194.1.139 with SMTP id 11mr4646895wjm.33.1383256245010; Thu, 31 Oct 2013 14:50:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 31 Oct 2013 14:50:03 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <5272CE40.4080908@gmail.com>
References: <527147FF.5010506@nostrum.com>   <5272C6C8.3070006@gmail.com>  <5272CE40.4080908@gmail.com>
From: Eric Rescorla 
Date: Thu, 31 Oct 2013 14:50:03 -0700
Message-ID: 
To: Daniel-Constantin Mierla 
Content-Type: multipart/alternative; boundary=047d7b3a8c301e213604ea1071a1
Cc: "rtcweb@ietf.org" , Neil Stratford 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 21:50:52 -0000

--047d7b3a8c301e213604ea1071a1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 31, 2013 at 2:40 PM, Daniel-Constantin Mierla  wrote:

>
> On 10/31/13 10:27 PM, Eric Rescorla wrote:
>
>
>
>
> On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <
> miconda@gmail.com> wrote:
>
>>
>> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>>
>>> On 31 Oct 2013, at 10:02, Neil Stratford  wrote:
>>>
>>>  On 30 Oct 2013, at 17:55, Adam Roach  wrote:
>>>>
>>>>  As Jonathan mentioned earlier, this morning Cisco announced that it
>>>>> will be open sourcing an H.264 implementation as well as gratis binary
>>>>> modules compiled from that source and hosted by Cisco for download. Mozilla
>>>>> will be modifying Firefox to support H.264 by downloading Cisco's binary
>>>>> module.
>>>>>
>>>>
>>>> It seems like most of the groundwork is being done here for a real
>>>> codec plugin API which would obviate the need for any particular codec to
>>>> be selected as MTI.
>>>>
>>>> Can we encourage this new codec plugin API to be developed in an open
>>>> way as part of the standards process and therefore be supported in all
>>>> browsers? (Enabling for example the addition of VP8 to a browser that may
>>>> not natively ship with it.)
>>>>
>>> I don't agree. The idea was to create a realtime web platform without
>>> the need for any plugins or downloadable modules. We've had that for ages
>>> and it is not a good solution.
>>>
>>> I am still for a MTI codec or set of codecs so we always can set up
>>> video calls, regardless of implementation and if it's possible to download
>>> by policy or network conditions a specific binary.
>>>
>>  Downloading a binary opens doors for tons of risks, knowing that lot of
>> carriers do caching or interpose themselves (e.g., it happens very commonly
>> for dns to redirect you to some adds page when typing an invalid domain),
>> thus is easy to replace the original source, so a rather complex security
>> mechanism has to be put in place.
>>
>
>  Solely on the security question...
>
>  I'm not sure what you mean by "rather complex". What I would expect is
> to have signed
> binaries. This addresses the question of attack from the network and is
> how we
> intend to handle things in Firefox.
>
>  Note that any product that auto-updates (like Firefox and Chrome)
> already need
> to have some mechanism for verifying that the things they download are
> correct.
>
>
> Typically the updates you mentioned are done from the project's sites, so
> that is easier to handle. Now there is a third party involved, requiring
> some sync'ing between Cisco and browser's sites. It's like a
> menage-a-trios, pretty dirty affair.
>

I don't anticipate any problems implementing this in Firefox (and in case
I wasn't clear previously, I'm probably the person who will be responsible
for figuring out how to make it work).



>  I wonder why flash plugin was not loaded this way, it was always free --
> but had to be downloaded/installed explicitly by users.
>

Well, that's not true for Chrome, at least, which ships with Flash, though
I agree that that's somewhat different.



 Even the argument that the code can be compiled and signatures compared is
>> not really feasible - simply it cannot be done by mobile devices - they
>> don't have the sdk installed.
>>
>
>  I don't see why this would be needed. The containing program (e.g., the
> browser) doesn't compile, it just does signature verification.
>
>  Obviously, this only addresses the question of attack from the network,
> not malicious binaries constructed by Cisco. I expect that to be addressed
> by third parties doing verified builds and comparing the binaries.
> Presumably,
> one could invent some countersignature mechanism to allow clients to
> verify that a specific third party had verified a build.
>
> If we get to 'one could invent some ...' and wait for that, better wait
> for a pure open source video codec.
>

You might be interested in:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17



> Mozilla is working in that direction anyhow.
>

That's going to take rather longer than this.

-Ekr



>
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Trainings - Berlin, Nov 25-28
>   - more details about Kamailio trainings at http://www.asipto.com -
>
>

--047d7b3a8c301e213604ea1071a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Oct 31, 2013 at 2:40 PM, Daniel-Constantin Mierla =
<miconda@gmail.com> wrote:




 =20
   =20
 =20
  

    

    
On 10/31/13 10:27 PM, Eric Rescorla
      wrote:

    

    

      


        


          

          
On Thu, Oct 31, 2013 at 2:08 PM,
            Daniel-Constantin Mierla <miconda@gmail.com> wro=
te:

            

              

                


                  On 10/31/13 4:10 PM, Olle E. Johansson wrote:

                  

                    On 31 Oct 2013, at 10:02, Neil Stratford <neils@vipadia.com>
                    wrote:

                    

                    

                      On 30 Oct 2013, at 17:55, Adam Roach <adam@nostrum.com>
                      wrote:

                      

                      

                        As Jonathan mentioned earlier, this morning
                        Cisco announced that it will be open sourcing an
                        H.264 implementation as well as gratis binary
                        modules compiled from that source and hosted by
                        Cisco for download. Mozilla will be modifying
                        Firefox to support H.264 by downloading Cisco's
                        binary module.

                      

                      

                      It seems like most of the groundwork is being done
                      here for a real codec plugin API which would
                      obviate the need for any particular codec to be
                      selected as MTI.

                      

                      Can we encourage this new codec plugin API to be
                      developed in an open way as part of the standards
                      process and therefore be supported in all
                      browsers? (Enabling for example the addition of
                      VP8 to a browser that may not natively ship with
                      it.)

                    

                    I don't agree. The idea was to create a realtime we=
b
                    platform without the need for any plugins or
                    downloadable modules. We've had that for ages and i=
t
                    is not a good solution.

                    

                    I am still for a MTI codec or set of codecs so we
                    always can set up video calls, regardless of
                    implementation and if it's possible to download by
                    policy or network conditions a specific binary.

                  

                

              

              Downloading a binary opens doors for tons of risks,
              knowing that lot of carriers do caching or interpose
              themselves (e.g., it happens very commonly for dns to
              redirect you to some adds page when typing an invalid
              domain), thus is easy to replace the original source, so a
              rather complex security mechanism has to be put in place.

            

            


            

            
Solely on the security question...

            


            

            
I'm not sure what you mean by "rather complex&quo=
t;. What I
              would expect is to have signed

            
binaries. This addresses the question of attack from
              the network and is how we

            
intend to handle things in Firefox.

            


            

            
Note that any product that auto-updates (like Firefox
              and Chrome) already need

            
to have some mechanism for verifying that the things
              they download are correct.

          

        

      

    

    

    Typically the updates you mentioned are done from the project's
    sites, so that is easier to handle. Now there is a third party
    involved, requiring some sync'ing between Cisco and browser's s=
ites.
    It's like a menage-a-trios, pretty dirty affair.
=


I don't anticipate any problems implementing this i=
n Firefox (and in case
I wasn't clear previously, I'm pro=
bably the person who will be responsible



for figuring out how to make it work).

=A0



 I wonder why flash
    plugin was not loaded this way, it was always free -- but had to be
    downloaded/installed explicitly by users.

Well, that's not true for Chrome, at least, which ships with F=
lash, though
I agree that that's somewhat different.










            

              Even the argument that the code can be compiled and
              signatures compared is not really feasible - simply it
              cannot be done by mobile devices - they don't have the sd=
k
              installed.

            

            


            

            
I don't see why this would be needed. The containing
              program (e.g., the

            
browser) doesn't compile, it just does signature
              verification.

            


            

            
Obviously, this only addresses the question of attack
              from the network,

            
not malicious binaries constructed by Cisco. I expect
              that to be addressed

            
by third parties doing verified builds and comparing
              the binaries. Presumably,

            
one could invent some countersignature mechanism to
              allow clients to

            
verify that a specific third party had verified a
              build.

          

        

      

    

    If we get to 'one could invent some ...' and wait for that, bet=
ter
    wait for a pure open source video codec.

You might be interested in:




=A0


Mozilla is working in that
    direction anyhow.

That's goin=
g to take rather longer than this.

-Ekr
=







    

    Daniel

    
--=20
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.=
com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
  - more details about Kamailio trainings at http://www.asipto.com -


  






--047d7b3a8c301e213604ea1071a1--

From rlb@ipv.sx  Thu Oct 31 15:36:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E8211E8244 for ; Thu, 31 Oct 2013 15:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.889
X-Spam-Level: 
X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t94-a6V0H+0N for ; Thu, 31 Oct 2013 15:36:45 -0700 (PDT)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 859DA11E8182 for ; Thu, 31 Oct 2013 15:36:45 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id j6so3768884oag.23 for ; Thu, 31 Oct 2013 15:36:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KvLjw2KtP5kSTwP34RkeDGNDnXC+A65r1tsb91pGViM=; b=lCfeDe+gVT7XDgoZApR3goDXYgI+exq4n6alN+LjxxKCsX4x4XUsOBrdzHmZ/zB6Cg uK+GcTdR15mgjnrhmmI2mgOWwcGNVfsgfWeQYAa5I0um6fqOD3mOZeOjzpdJsQke67+m w7akXk+hbz584qXSs5CnYMxIYBlqI6Lj7SyR5RTFADcFN8fgkVfn0Y1tk8QRPLvEA+e+ TWz7fjZW83SdUgJqO7FZ3R3uKstvLKxalHDNo3V4uRo78imvpgqEiaeSspQofFMRlvqH SuM+ETg8B9pg4yjMW3ei9hvztCRBU4sSJbOkM1u9bK5gHaGh/kpwbxeWLNw0mv12Q7LE 9djA==
X-Gm-Message-State: ALoCoQkwlp15rDN+b5VoOTfLvz2sAtQPiRJsgMmZXExpXoLh47pUovgznPLLWr6jzbsBN2PaJem8
MIME-Version: 1.0
X-Received: by 10.60.43.169 with SMTP id x9mr30114oel.88.1383259004853; Thu, 31 Oct 2013 15:36:44 -0700 (PDT)
Received: by 10.76.101.10 with HTTP; Thu, 31 Oct 2013 15:36:44 -0700 (PDT)
In-Reply-To: 
References: <527147FF.5010506@nostrum.com>   <5272C6C8.3070006@gmail.com> 
Date: Thu, 31 Oct 2013 18:36:44 -0400
Message-ID: 
From: Richard Barnes 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=001a11330a009dfae004ea1115e7
Cc: "rtcweb@ietf.org" , Neil Stratford 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 22:36:50 -0000

--001a11330a009dfae004ea1115e7
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 31, 2013 at 5:27 PM, Eric Rescorla  wrote:

>
> On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <
> miconda@gmail.com> wrote:
>
>>
>> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>>
>>> On 31 Oct 2013, at 10:02, Neil Stratford  wrote:
>>>
>>>  On 30 Oct 2013, at 17:55, Adam Roach  wrote:
>>>>
>>>>  As Jonathan mentioned earlier, this morning Cisco announced that it
>>>>> will be open sourcing an H.264 implementation as well as gratis binary
>>>>> modules compiled from that source and hosted by Cisco for download. Mozilla
>>>>> will be modifying Firefox to support H.264 by downloading Cisco's binary
>>>>> module.
>>>>>
>>>>
>>>> It seems like most of the groundwork is being done here for a real
>>>> codec plugin API which would obviate the need for any particular codec to
>>>> be selected as MTI.
>>>>
>>>> Can we encourage this new codec plugin API to be developed in an open
>>>> way as part of the standards process and therefore be supported in all
>>>> browsers? (Enabling for example the addition of VP8 to a browser that may
>>>> not natively ship with it.)
>>>>
>>> I don't agree. The idea was to create a realtime web platform without
>>> the need for any plugins or downloadable modules. We've had that for ages
>>> and it is not a good solution.
>>>
>>> I am still for a MTI codec or set of codecs so we always can set up
>>> video calls, regardless of implementation and if it's possible to download
>>> by policy or network conditions a specific binary.
>>>
>> Downloading a binary opens doors for tons of risks, knowing that lot of
>> carriers do caching or interpose themselves (e.g., it happens very commonly
>> for dns to redirect you to some adds page when typing an invalid domain),
>> thus is easy to replace the original source, so a rather complex security
>> mechanism has to be put in place.
>>
>
> Solely on the security question...
>
> I'm not sure what you mean by "rather complex". What I would expect is to
> have signed
> binaries. This addresses the question of attack from the network and is
> how we
> intend to handle things in Firefox.
>

You would need something more than that if you don't trust Cisco not to
tinker with the binaries (no offense).  But even that doesn't have to be
complicated.  You could just do something like have the software call back
to the vendor whenever it gets a new binary from Cisco to check that the
binary it just got is good (say, by comparing hashes).

That way at least Cisco and the vendor would have to collude to introduce a
bad modification to the binary.  Which is not so bad, because the user is
already trusting the vendor not to screw them in all sorts of other ways.

--Richard



>
> Note that any product that auto-updates (like Firefox and Chrome) already
> need
> to have some mechanism for verifying that the things they download are
> correct.
>
>
>
>> Even the argument that the code can be compiled and signatures compared
>> is not really feasible - simply it cannot be done by mobile devices - they
>> don't have the sdk installed.
>>
>
> I don't see why this would be needed. The containing program (e.g., the
> browser) doesn't compile, it just does signature verification.
>
> Obviously, this only addresses the question of attack from the network,
> not malicious binaries constructed by Cisco. I expect that to be addressed
> by third parties doing verified builds and comparing the binaries.
> Presumably,
> one could invent some countersignature mechanism to allow clients to
> verify that a specific third party had verified a build.
>
> -Ekr
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11330a009dfae004ea1115e7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Oct 31, 2013 at 5:27 PM, Eric Rescorla <ekr@rtfm.com=
> wrote:



=

On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla=
 <miconda@gmail.com> wrote:






On 10/31/13 4:10 PM, Olle E. Johansson wrote:



On 31 Oct 2013, at 10:02, Neil Stratford <neils@vipadia.com> wrote:





On 30 Oct 2013, at 17:55, Adam Roach <adam@nostrum.com> wrote:





As Jonathan mentioned earlier, this morning Cisco announced that it will be=
 open sourcing an H.264 implementation as well as gratis binary modules com=
piled from that source and hosted by Cisco for download. Mozilla will be mo=
difying Firefox to support H.264 by downloading Cisco's binary module.<=
br>







It seems like most of the groundwork is being done here for a real codec pl=
ugin API which would obviate the need for any particular codec to be select=
ed as MTI.



Can we encourage this new codec plugin API to be developed in an open way a=
s part of the standards process and therefore be supported in all browsers?=
 (Enabling for example the addition of VP8 to a browser that may not native=
ly ship with it.)






I don't agree. The idea was to create a realtime web platform without t=
he need for any plugins or downloadable modules. We've had that for age=
s and it is not a good solution.



I am still for a MTI codec or set of codecs so we always can set up video c=
alls, regardless of implementation and if it's possible to download by =
policy or network conditions a specific binary.



Downloading a binary opens doors for tons of risks, knowing that lot of car=
riers do caching or interpose themselves (e.g., it happens very commonly fo=
r dns to redirect you to some adds page when typing an invalid domain), thu=
s is easy to replace the original source, so a rather complex security mech=
anism has to be put in place.





Solely on the security question...

I'm not sure what you mean by "rather comp=
lex". What I would expect is to have signed
binaries. This a=
ddresses the question of attack from the network and is how we




intend to handle things in Firefox.

You would need something more than that if you don=
9;t trust Cisco not to tinker with the binaries (no offense).=A0 But even t=
hat doesn't have to be complicated.=A0 You could just do something like=
 have the software call back to the vendor whenever it gets a new binary fr=
om Cisco to check that the binary it just got is good (say, by comparing ha=
shes).=A0 


That way at least Cisco and the vendor would have to collude to introdu=
ce a bad modification to the binary.=A0 Which is not so bad, because the us=
er is already trusting the vendor not to screw them in all sorts of other w=
ays.


--Richard

=A0


Note that any product that auto-updates (like Firefox and Ch=
rome) already need
to have some mechanism for verifying that the =
things they download are correct.




=A0

Even the argument that the code can be compiled and signatures compared is =
not really feasible - simply it cannot be done by mobile devices - they don=
't have the sdk installed.


I don't see why this would be needed. The containing program (e.g., the=




browser) doesn't compile, it just does signature verification.

Obviously, this only addresses the question of attack=
 from the network,
not malicious binaries constructed by Cisco. I=
 expect that to be addressed




by third parties doing verified builds and comparing the binaries. Pre=
sumably,
one could invent some countersignature mechanism to allo=
w clients to
verify that a specific third party had verified a bu=
ild.





-Ekr



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11330a009dfae004ea1115e7--

From ekr@rtfm.com  Thu Oct 31 15:45:33 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77311E826C for ; Thu, 31 Oct 2013 15:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.753
X-Spam-Level: 
X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzenbwz0JCKw for ; Thu, 31 Oct 2013 15:45:27 -0700 (PDT)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6646011E8261 for ; Thu, 31 Oct 2013 15:45:26 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so3356693wes.15 for ; Thu, 31 Oct 2013 15:45:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PXBDQ4iNYlxz9K+R5XulDRbP3J2JYeY8u1b+Q7Hd9XU=; b=LwFTsshSdYaAZEaiQ0Gh79MDsX2SUcxaGIAaoQXxa3fQRHdNGh/VYH22JMTK4WIRro r53cYcc70NgP0TOQ6E5e4oXEISgT50Cr4K5oyr2rfTymBIXCEmD+vwAYipld7LMPeQw4 SmSLufuFcTioFEH20KKDMSxOuIB6fjHpH96r2vgmg1OeuQL1v9u6GcJn6a9VRD3FfJ0a /p5hEw6YX0OgYm6n+IwJPlL6vonyPGuf60ws4ynxYNHUo5ttCacHoG1RBdMWb/7+9caF v0UEhnesJXZu4kbldQ5DiHpoLd9Z9k37KldiaRn2DJDe6EU31KodFSHWi73Oc+r0zUCa 8GiA==
X-Gm-Message-State: ALoCoQntjuBKFYCOVa84S1S3QxG6Gb2Hi6xCpENRFKtImSsbuop97z3q9gtFbKo5hylywEsGdx3h
X-Received: by 10.180.24.197 with SMTP id w5mr296517wif.8.1383259522288; Thu, 31 Oct 2013 15:45:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 31 Oct 2013 15:44:42 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: 
References: <527147FF.5010506@nostrum.com>   <5272C6C8.3070006@gmail.com>  
From: Eric Rescorla 
Date: Thu, 31 Oct 2013 15:44:42 -0700
Message-ID: 
To: Richard Barnes 
Content-Type: multipart/alternative; boundary=f46d044286e275626604ea11342a
Cc: "rtcweb@ietf.org" , Neil Stratford 
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 22:45:33 -0000

--f46d044286e275626604ea11342a
Content-Type: text/plain; charset=ISO-8859-1

Keep reading below.

"Obviously, this only addresses the question of attack from the network,
not malicious binaries constructed by Cisco. I expect that to be addressed
by third parties doing verified builds and comparing the binaries.
Presumably,
one could invent some countersignature mechanism to allow clients to
verify that a specific third party had verified a build."



On Thu, Oct 31, 2013 at 3:36 PM, Richard Barnes  wrote:

> On Thu, Oct 31, 2013 at 5:27 PM, Eric Rescorla  wrote:
>
>>
>> On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <
>> miconda@gmail.com> wrote:
>>
>>>
>>> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>>>
>>>> On 31 Oct 2013, at 10:02, Neil Stratford  wrote:
>>>>
>>>>  On 30 Oct 2013, at 17:55, Adam Roach  wrote:
>>>>>
>>>>>  As Jonathan mentioned earlier, this morning Cisco announced that it
>>>>>> will be open sourcing an H.264 implementation as well as gratis binary
>>>>>> modules compiled from that source and hosted by Cisco for download. Mozilla
>>>>>> will be modifying Firefox to support H.264 by downloading Cisco's binary
>>>>>> module.
>>>>>>
>>>>>
>>>>> It seems like most of the groundwork is being done here for a real
>>>>> codec plugin API which would obviate the need for any particular codec to
>>>>> be selected as MTI.
>>>>>
>>>>> Can we encourage this new codec plugin API to be developed in an open
>>>>> way as part of the standards process and therefore be supported in all
>>>>> browsers? (Enabling for example the addition of VP8 to a browser that may
>>>>> not natively ship with it.)
>>>>>
>>>> I don't agree. The idea was to create a realtime web platform without
>>>> the need for any plugins or downloadable modules. We've had that for ages
>>>> and it is not a good solution.
>>>>
>>>> I am still for a MTI codec or set of codecs so we always can set up
>>>> video calls, regardless of implementation and if it's possible to download
>>>> by policy or network conditions a specific binary.
>>>>
>>> Downloading a binary opens doors for tons of risks, knowing that lot of
>>> carriers do caching or interpose themselves (e.g., it happens very commonly
>>> for dns to redirect you to some adds page when typing an invalid domain),
>>> thus is easy to replace the original source, so a rather complex security
>>> mechanism has to be put in place.
>>>
>>
>> Solely on the security question...
>>
>> I'm not sure what you mean by "rather complex". What I would expect is to
>> have signed
>> binaries. This addresses the question of attack from the network and is
>> how we
>> intend to handle things in Firefox.
>>
>
> You would need something more than that if you don't trust Cisco not to
> tinker with the binaries (no offense).  But even that doesn't have to be
> complicated.  You could just do something like have the software call back
> to the vendor whenever it gets a new binary from Cisco to check that the
> binary it just got is good (say, by comparing hashes).
>
> That way at least Cisco and the vendor would have to collude to introduce
> a bad modification to the binary.  Which is not so bad, because the user is
> already trusting the vendor not to screw them in all sorts of other ways.
>
> --Richard
>
>
>
>>
>> Note that any product that auto-updates (like Firefox and Chrome) already
>> need
>> to have some mechanism for verifying that the things they download are
>> correct.
>>
>>
>>
>>> Even the argument that the code can be compiled and signatures compared
>>> is not really feasible - simply it cannot be done by mobile devices - they
>>> don't have the sdk installed.
>>>
>>
>> I don't see why this would be needed. The containing program (e.g., the
>> browser) doesn't compile, it just does signature verification.
>>
>> Obviously, this only addresses the question of attack from the network,
>> not malicious binaries constructed by Cisco. I expect that to be addressed
>> by third parties doing verified builds and comparing the binaries.
>> Presumably,
>> one could invent some countersignature mechanism to allow clients to
>> verify that a specific third party had verified a build.
>>
>> -Ekr
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>

--f46d044286e275626604ea11342a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Keep reading below.

"Obvious=
ly, this only addresses the question of attack from the network,

not malicious binaries constructed by Cisco. I expect that to be addressed<=
/div>
by third parties doing verified builds and comparing the binaries. =
Presumably,



one could invent some countersignature mechanism to allow clients to


verify that a specific third party had verified a build."

=





On Thu, Oct 31, 2013 at 3:36 PM, Richard Barnes <rlb@ipv.sx> wrote:=




On Thu, Oct 31, 2013 at 5:27 PM, Eric Re=
scorla <ekr@rtfm.com> wrote:
=







=

On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <miconda@gm=
ail.com> wrote:








On 10/31/13 4:10 PM, Olle E. Johansson wrote:



On 31 Oct 2013, at 10:02, Neil Stratford <neils@vipadia.com> wrote:





On 30 Oct 2013, at 17:55, Adam Roach <adam@nostrum.com> wrote:





As Jonathan mentioned earlier, this morning Cisco announced that it will be=
 open sourcing an H.264 implementation as well as gratis binary modules com=
piled from that source and hosted by Cisco for download. Mozilla will be mo=
difying Firefox to support H.264 by downloading Cisco's binary module.<=
br>









It seems like most of the groundwork is being done here for a real codec pl=
ugin API which would obviate the need for any particular codec to be select=
ed as MTI.



Can we encourage this new codec plugin API to be developed in an open way a=
s part of the standards process and therefore be supported in all browsers?=
 (Enabling for example the addition of VP8 to a browser that may not native=
ly ship with it.)








I don't agree. The idea was to create a realtime web platform without t=
he need for any plugins or downloadable modules. We've had that for age=
s and it is not a good solution.



I am still for a MTI codec or set of codecs so we always can set up video c=
alls, regardless of implementation and if it's possible to download by =
policy or network conditions a specific binary.



Downloading a binary opens doors for tons of risks, knowing that lot of car=
riers do caching or interpose themselves (e.g., it happens very commonly fo=
r dns to redirect you to some adds page when typing an invalid domain), thu=
s is easy to replace the original source, so a rather complex security mech=
anism has to be put in place.







Solely on the security question...

I'm not sure what you mean by "rather comp=
lex". What I would expect is to have signed
binaries. This a=
ddresses the question of attack from the network and is how we






intend to handle things in Firefox.

You would need something more than that if you =
don't trust Cisco not to tinker with the binaries (no offense).=A0 But =
even that doesn't have to be complicated.=A0 You could just do somethin=
g like have the software call back to the vendor whenever it gets a new bin=
ary from Cisco to check that the binary it just got is good (say, by compar=
ing hashes).=A0 




That way at least Cisco and the vendor would have to collude to introdu=
ce a bad modification to the binary.=A0 Which is not so bad, because the us=
er is already trusting the vendor not to screw them in all sorts of other w=
ays.




--Richard

=A0





Note that any product that auto-updates (like Firefox and Ch=
rome) already need
to have some mechanism for verifying that the =
things they download are correct.




=A0

Even the argument that the code can be compiled and signatures compared is =
not really feasible - simply it cannot be done by mobile devices - they don=
't have the sdk installed.




I don't see why this would be needed. The containing program (e.g., the=




browser) doesn't compile, it just does signature verification.

Obviously, this only addresses the question of attack=
 from the network,
not malicious binaries constructed by Cisco. I=
 expect that to be addressed






by third parties doing verified builds and comparing the binaries. Pre=
sumably,
one could invent some countersignature mechanism to allo=
w clients to
verify that a specific third party had verified a bu=
ild.







-Ekr



_______________________________________________=


rtcweb mailing list

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








--f46d044286e275626604ea11342a--

From cowwoc@bbs.darktech.org  Thu Oct 31 17:54:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4C021E8087 for ; Thu, 31 Oct 2013 17:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.057
X-Spam-Level: 
X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQEc3b5zjxg1 for ; Thu, 31 Oct 2013 17:54:45 -0700 (PDT)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 166CB21E809D for ; Thu, 31 Oct 2013 17:54:42 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id n7so2154961qcx.27 for ; Thu, 31 Oct 2013 17:54:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T4I0gIJopDcHNEMv5HdRpgFheZqKfQBq7TU/R4/sLOk=; b=UaM9NTbfQzU5TI0FIX0rlQ28oPwYkRn16d0xxVztQUc4STyfjOkeAt/7vOJaQQlXVj MvP2o5vR7J9oRd7L6QBPmv24cJxzdn9mcs8mBs2FZYC4TBWyaLiLbkNddYXZBKtHPj/E t9KY0g1nzGYen/ycS0mcG3ATBGbMjFA5zmD0mn93PRXuphy9Ql4YuOspo+Yctkb9+o7X 3s33NIA2wxzTRkkby7c0nNk38S7iep5K+nQfJray6zQrfugNY8/nlXLHWU+9ywxnNOvM 1ISPPgTTOYyw7oBQkqKnH+N9Yg34q0stUawKVUHOgzpXNM9XG1KNVkqufuCatspor7wH jwQw==
X-Gm-Message-State: ALoCoQnJwhWhR7urUaJvNF25PF1GOsJo+lbtZzS6Z+msAX/ajoeDFjHXz/H3juhr9aLhXdcsfyqY
X-Received: by 10.224.95.10 with SMTP id b10mr625019qan.6.1383267282367; Thu, 31 Oct 2013 17:54:42 -0700 (PDT)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id h9sm15312076qaq.9.2013.10.31.17.54.40 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 17:54:41 -0700 (PDT)
Message-ID: <5272FBCD.60106@bbs.darktech.org>
Date: Thu, 31 Oct 2013 20:54:37 -0400
From: cowwoc 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <527147FF.5010506@nostrum.com>		 <5272C6C8.3070006@gmail.com>
In-Reply-To: <5272C6C8.3070006@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Nov 2013 00:54:51 -0000

     Everyone seems to be fixated on web browsers. What happens to those 
of us who wish to integrate WebRTC as a library into non-browser 
applications? What about standalone (client) applications? What about 
(auditing) web servers? Are we expected to download the binary module 
once per user? Or does our build machine download it once and deploy it 
to a million users?

     VP8 is far more attractive from a security and deployment point of 
view.

Gili

On 31/10/2013 5:08 PM, Daniel-Constantin Mierla wrote:
>
> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>> On 31 Oct 2013, at 10:02, Neil Stratford  wrote:
>>
>>> On 30 Oct 2013, at 17:55, Adam Roach  wrote:
>>>
>>>> As Jonathan mentioned earlier, this morning Cisco announced that it 
>>>> will be open sourcing an H.264 implementation as well as gratis 
>>>> binary modules compiled from that source and hosted by Cisco for 
>>>> download. Mozilla will be modifying Firefox to support H.264 by 
>>>> downloading Cisco's binary module.
>>>
>>> It seems like most of the groundwork is being done here for a real 
>>> codec plugin API which would obviate the need for any particular 
>>> codec to be selected as MTI.
>>>
>>> Can we encourage this new codec plugin API to be developed in an 
>>> open way as part of the standards process and therefore be supported 
>>> in all browsers? (Enabling for example the addition of VP8 to a 
>>> browser that may not natively ship with it.)
>> I don't agree. The idea was to create a realtime web platform without 
>> the need for any plugins or downloadable modules. We've had that for 
>> ages and it is not a good solution.
>>
>> I am still for a MTI codec or set of codecs so we always can set up 
>> video calls, regardless of implementation and if it's possible to 
>> download by policy or network conditions a specific binary.
> Downloading a binary opens doors for tons of risks, knowing that lot 
> of carriers do caching or interpose themselves (e.g., it happens very 
> commonly for dns to redirect you to some adds page when typing an 
> invalid domain), thus is easy to replace the original source, so a 
> rather complex security mechanism has to be put in place.
>
> Even the argument that the code can be compiled and signatures 
> compared is not really feasible - simply it cannot be done by mobile 
> devices - they don't have the sdk installed.
>
> I can't see an impediment for Cisco to grant the main web browsers 
> (e.g., Mozilla, ...) to simply have the codec built in, using the BSD 
> open sourced codec. If the webrtc is going to the masses, then the 
> yearly fee cap will be reached anyhow.
>
> For the sake of clarification, I am not in a favor of a particular 
> video codec, but the one to be selected has to be embedded directly in 
> all browsers, specially in those open source, for full transparency. 
> Otherwise, better as Neil said, make it a plugin API so there can be 
> many providers - with binary blob download, there has to be an API 
> anyhow, make that the standard.
>
> Daniel
>







Howdy,

While the proponents of H.264 and =
VP8 continue to discuss performance,=20
there appears to be general agreement that either codec could serve the=20
purpose set out our for our MTI:=A0 to avoid negotiation failure that=20
results in the loss of basic functionality.=A0 If there are technical=20
issues which would prevent=A0 either from being used as the MTI that have=
=20
not yet been raised, please do so before the beginning of IETF88.

regards,

Ted, Cullen, Magnus


--047d7bd7679a7526ac04e9d37f2b--

From randell-ietf@jesup.org  Mon Oct 28 14:45:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE2E11E833D for ; Mon, 28 Oct 2013 14:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level: 
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0ZcbY+gufwJ for ; Mon, 28 Oct 2013 14:45:20 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id F140221F9ED4 for ; Mon, 28 Oct 2013 14:45:08 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:2342 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VaucW-0005Ji-0w for rtcweb@ietf.org; Mon, 28 Oct 2013 16:45:08 -0500
Message-ID: <526EDABE.1090403@jesup.org>
Date: Mon, 28 Oct 2013 17:44:30 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <52B42DFC-7A8E-4FD3-9820-F57E4B98ADCA@lurchi.franken.de>
In-Reply-To: <52B42DFC-7A8E-4FD3-9820-F57E4B98ADCA@lurchi.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 21:45:26 -0000

On 10/28/2013 8:05 AM, Michael Tuexen wrote:
> On Oct 24, 2013, at 10:38 PM, "Ejzak, Richard P (Richard)"  wrote:
>
>>
>> http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute in the RTCDataChannelInit dictionary that must be the equivalent of the "stream identifier".  No other interpretation makes sense to me but please correct me if I am wrong.  Note in particular the following text within the description of the createDataChannel procedure (my parenthetical): "If the value of the id attribute is null, initialize it to a value generated by the user agent (browser), according to the WebRTC DataChannel Protocol specification, and skip to the next step. Otherwise, if the value of the id attribute is taken by an existing RTCDataChannel, throw a TBD exception and abort these steps."  So "id" must refer to "stream identifier" since there is no other id in your draft that it could refer to.
> I don't see in the document a statement that the id corresponds to the stream identifier.
> If that is the case, it should be mentioned. The W3C document indicates that the type
> of id is unsigned short?. I don't know enough JS to know if this corresponds to uint16_t
> or not. If not, there is a problem...

That's uint16_t, yes.  There's no specific link in the W3C draft that W3 
DataChannel id == SCTP Stream ID, but it's strongly implied and probably 
should be specified now that we allow external negotiation (before that 
it was less interesting).  Also we should specify that 65535 means "no 
id established yet" in the W3 spec.


-- 
Randell Jesup -- rjesup a t mozilla d o t com


From richard.ejzak@alcatel-lucent.com  Mon Oct 28 18:23:00 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8869611E81DD for ; Mon, 28 Oct 2013 18:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.269
X-Spam-Level: 
X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVv4CnGAFsOn for ; Mon, 28 Oct 2013 18:22:48 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id CAFFE21E8095 for ; Mon, 28 Oct 2013 18:22:46 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9T1MjL6002028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Oct 2013 20:22:45 -0500 (CDT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r9T1MiS9015165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Oct 2013 21:22:44 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 28 Oct 2013 21:22:44 -0400
From: "Ejzak, Richard P (Richard)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQgABIioCAABByAP//ww2ggABSCoD//8IcAIAA11OAgABsdbCAAlPugIAAvIgAgAGzAlA=
Date: Tue, 29 Oct 2013 01:22:43 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org>
In-Reply-To: <526CE0BE.90606@jesup.org>
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
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 01:23:00 -0000

Hi Randell,
Thanks for suggesting the stream id assignment algorithm below.  Please bea=
r with me a little longer.  I agree that limited coexistence of application=
 and browser stream id selection is possible, but it seems that there are s=
ome significant restrictions.

Using in-band negotiation, I cannot see any way in which application select=
ion and browser selection of stream ids can co-exist before DTLS roles are =
determined.  If application A selects an odd stream id, the only way to com=
municate this selection to application B's browser is via the in-band open =
message after the SCTP association has been established.  It doesn't help t=
o tell application B since it can't report the information to its browser. =
 So if application B creates another data channel and requests browser sele=
ction of a stream id then B's browser might end up selecting the same odd s=
tream id, since it has no way to know to avoid it.  Not unless we reserve i=
d values exclusively for application selection.  Do you agree?  If so, we s=
hould document this restriction.

There is no problem if only browser selection of stream ids is allowed befo=
re the SCTP association is established since both applications can learn wh=
ich side owns odd/even values after channel open is reported to the peer (s=
ince there has to be at least one data channel created to trigger the estab=
lishment of the SCTP association).  Now application and browser stream id s=
election can co-exist without a hitch.

If we assume only application selection of stream ids is allowed with in-ba=
nd negotiation before the SCTP association is established, then we can also=
 allow co-existence of application selection and browser selection of strea=
m ids after establishment of the SCTP association, as long as there is a wa=
y for each application to determine DTLS role.  They can't use the trick in=
 the last paragraph since the browsers haven't been asked to assign any str=
eam ids.  Is there an API mechanism available to determine DTLS role?  Am I=
 missing something here?

With external negotiation, only application selection of stream ids can be =
allowed before DTLS role is determined since the external negotiation mecha=
nism needs to be able to report to both peers (and browsers) the stream id(=
s) selected.  Once DTLS role is determined then application and browser sel=
ection of stream ids could co-exist, but requires that the applications lea=
rn which DTLS roles were negotiated (same issue as above). =20

Interestingly, in-band and external negotiation can co-exist before DTLS ro=
le is established as long as application selection of stream ids is used ex=
clusively.  All forms of in-band and external negotiation can co-exist afte=
r the SCTP association is established as long as the applications know the =
DTLS roles.

In summary, the following combinations are allowed:

1) application selection with in-band negotiation before SCTP established a=
nd app determines DTLS role
2) browser selection with in-band negotiation before SCTP established
3) application selection with external negotiation before app determines DT=
LS role
4) application selection with in-band and external negotiation before SCTP =
established and app determines DTLS role
5) any combination of selection and negotiation after SCTP is established i=
f DTLS role is available to app

If DTLS exchange and SCTP establishment are associated with separate offer/=
answer transactions, there might be a few more combinations to consider.  T=
he list also does not describe what is possible if DTLS role is not availab=
le directly to the apps.

The above discussion might be an argument for segregating the stream ids av=
ailable for application and browser selection.  There sure are plenty of th=
em.  What do you think?  Then we wouldn't need to make DTLS role available =
to the app and there would only be a few restrictions on browser selection =
(it can't be used for external negotiation before DTLS role is determined).=
  And you could always have an overflow rule.

Please correct me if I have missed anything.  Thanks!

BR, Richard

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Randell Jesup
> Sent: Sunday, October 27, 2013 4:46 AM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> 01.txt
>=20
> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
> > Richard,
> >
> > On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
> >> Hi Harald,
> >> You said: " I can't see a way to mix the two paradigms that
> >> guarantees this never happening."  The two paradigms being browser
> >> selection vs. application selection of data channel stream ids.
>=20
> You can.  You just have to be careful.  For example, your application
> could define that pre-negotiated channels will use 100-110, and then
> specify those to both ends before association/offer/answer.  Later it
> could use data-protocol to add dynamic channels (using even-odd).
> Since we've told both ends about 100-110, there's no problem here.
> Even/odd is ONLY to avoid glare when both sides decide to open a
> channel "at the same time".  If you add a pre-negotiated channel after
> initial establishment, it's up to you to avoid colliding with any
> existing channels and to avoid colliding with any in-process-of-
> creation dynamic
> (data-protocol) channels.  There are a number of ways to avoid such a
> collision safely (never use dynamic channels; use the DTLS role or an
> existing dynamic channel id to determine even/odd, etc).
>=20
> >> My proposal has three elements, which together can guarantee that
> >> there are no stream id allocation conflicts between peers:
> >>     1. The browser and application select stream ids based on
> initial
> >> SDP offerer/answerer role rather than DTLS role (e.g., initial
> >> offerer uses even ids, initial answerer uses odd ids). With this
> >> rule, the offering application knows its role immediately without
> >> waiting for the DTLS or SDP handshake to occur.
> >
> > A similar issue has come up in the discussion of partial
> > offers/answers. (Regarding how to assign a=3Dmid values.) And a similar
> > solution was proposed.
> >
> > It was then rejected on the basis that sometimes both "ends" think
> > they are offerers or answerers. This comes about as a result of
> > signaling-only B2BUAs that play games with O/A on two legs.
>=20
> Exactly why we went with DTLS roles.
>=20
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From randell-ietf@jesup.org  Mon Oct 28 21:47:06 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8B11E8211 for ; Mon, 28 Oct 2013 21:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAF9l-Zy8Si0 for ; Mon, 28 Oct 2013 21:46:58 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7027221F9DF7 for ; Mon, 28 Oct 2013 21:45:58 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:3863 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Vb1Bg-0003Dr-B6 for rtcweb@ietf.org; Mon, 28 Oct 2013 23:45:52 -0500
Message-ID: <526F3D5A.9010205@jesup.org>
Date: Tue, 29 Oct 2013 00:45:14 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 04:47:07 -0000

On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
> Hi Randell,
> Thanks for suggesting the stream id assignment algorithm below.  Please bear with me a little longer.  I agree that limited coexistence of application and browser stream id selection is possible, but it seems that there are some significant restrictions.
>
> Using in-band negotiation, I cannot see any way in which application selection and browser selection of stream ids can co-exist before DTLS roles are determined.  If application A selects an odd stream id, the only way to communicate this selection to application B's browser is via the in-band open message after the SCTP association has been established.

No, the application can tell the other end that in conjunction with the 
offer (i.e. in application-specific signaling that accompanies the 
offer).  Any application using external negotiation must, in fact, 
handle external negotiation (even if that 'negotiation' is a set of 
hard-coded channel ids).

Any later non-external-negotiated channel creations will select an 
unused id of the correct even/oddness (per DTLS role).  One SHOULD 
create all initial-connection-time externally negotiated channels before 
adding any new automatic (data-protocol) ones, in order to avoid 
surprises -- though I'd be rather surprised that an application would 
mix them in that way.  If the app does, it will work fine though.

There is an implicit assumption that anything using external negotiation 
is either two instances of the same JS app or a cooperating app and 
server (those are by far the most common cases, and virtually the only 
cases), or two different apps that nonetheless know how to talk to each 
other and negotiate the channels on their own (I'll believe this when I 
see it, but it might happen).  External negotiation was added 
specifically for these pre-cooperating cases.

Also, one point perhaps missed from the W3 spec:

    7. If the value of the |id
    |
    attribute is null, initialize it to a value generated by the user
    agent, according to the WebRTC DataChannel Protocol specification,
    and skip to the next step. Otherwise, if the value of the |id
    |
    attribute is taken by an existing ||RTCDataChannel|
    |,
    throw a |TBD| exception and abort these steps.

Note this means you can create a channel for external negotation and let 
the browser select the id (which you then would tell the other side, and 
*they* would specify it to their end).  Note that the ID will not be set 
until DTLS roles are decided (and that's when onopen should fire as 
well).  This would not be very useful for setting up channels before 
offer/answer, but once offer/answer has completed, it lets you get a 
local channel id of correct oddness without having to scan all current 
datachannels to find an unused id value (assuming you're mixing styles 
of creation).

(We may need to add a line to the IETF drafts to cover this case; need 
to check).  The application *could* just scan all known channels 
instead, that's just a pain.  And it really only matters if you mix 
types, which is likely to be rare outside of "create these N hard-coded 
channels at offer/answer time, then have some dynamic 
(automatically-assigned-id) channels that get used later if needed."

>    It doesn't help to tell application B since it can't report the information to its browser.  So if application B creates another data channel and requests browser selection of a stream id then B's browser might end up selecting the same odd stream id, since it has no way to know to avoid it.  Not unless we reserve id values exclusively for application selection.  Do you agree?  If so, we should document this restriction.

When you tell the browser/protocol that a channel has been externally 
negotiated, it will mark that as in-use of course. That's why collisions 
can only happen when the other side creates an externally-negotiated 
channel of the "wrong" oddness in a race with an automatic creation from 
this side.  This is trivially avoided when building an app.

Much of this  discussion in the mail I'm replying to is moot, since it's 
based on an incorrect assumption about mixing.

> There is no problem if only browser selection of stream ids is allowed before the SCTP association is established since both applications can learn which side owns odd/even values after channel open is reported to the peer (since there has to be at least one data channel created to trigger the establishment of the SCTP association).  Now application and browser stream id selection can co-exist without a hitch.
>
> If we assume only application selection of stream ids is allowed with in-band negotiation before the SCTP association is established, then we can also allow co-existence of application selection and browser selection of stream ids after establishment of the SCTP association, as long as there is a way for each application to determine DTLS role.  They can't use the trick in the last paragraph since the browsers haven't been asked to assign any stream ids.  Is there an API mechanism available to determine DTLS role?  Am I missing something here?
>
> With external negotiation, only application selection of stream ids can be allowed before DTLS role is determined since the external negotiation mechanism needs to be able to report to both peers (and browsers) the stream id(s) selected.  Once DTLS role is determined then application and browser selection of stream ids could co-exist, but requires that the applications learn which DTLS roles were negotiated (same issue as above).
>
> Interestingly, in-band and external negotiation can co-exist before DTLS role is established as long as application selection of stream ids is used exclusively.  All forms of in-band and external negotiation can co-exist after the SCTP association is established as long as the applications know the DTLS roles.

I'm not going to reply line-by-line here, since I think much of this is 
based on a slightly incorrect understanding.

> In summary, the following combinations are allowed:
>
> 1) application selection with in-band negotiation before SCTP established and app determines DTLS role
> 2) browser selection with in-band negotiation before SCTP established
> 3) application selection with external negotiation before app determines DTLS role
> 4) application selection with in-band and external negotiation before SCTP established and app determines DTLS role
> 5) any combination of selection and negotiation after SCTP is established if DTLS role is available to app

I'd put it this way:

1)  You can create any number of DataChannels before 
createOffer()/createAnswer() so long as all of them are automatically 
assigned ids (what you call browser selection).  The actual ids are 
assigned after the DTLS roles are known.

2)  You can create any number of externally-negotiated channels before 
createOffer().  There is no need for them to match DTLS roles.

3) The answerer must create any externally-negotiated channels from its 
side before the channels can be used, and also SHOULD do so before 
creating automatic channels unless the application has made sure somehow 
a collision is impossible/unlikely.   In reality, there's no reason not 
to install the externally-negotiated channels before trying to create 
more, so the point is basically moot. (Note: you don't have to install 
the externally-negotiated channels before createAnswer, though normally 
I'd suggest doing so, just before creating automatically-generated ones.)

4) You can create externally-negotiated channels and then automatically 
negotiated channels before calling createOffer.  You can even mix them, 
since the automatically-generated ones will be assigned ids later when 
DTLS role is known (and will avoid any already in-use).  I'm not sure 
this is behavior that anyone would *need*, so I see no reason to promote 
mixing in that way - but it'll work.

5) Once the association is up, the application can use the method above 
(negotiated=true but no id=N) to allocate ids without fear of collision 
with automatic channels.

This is all emergent from the even/odd selection and letting the 
protocol choose ids when not externally negotiated.

Pseudo-code:

creation:
     externally-selected-id?
         yes-> mark channel in use
             if channel already in use complain and fail
         no-> dtls role known?
             yes-> assign unused channel of correct oddness; send OPEN
             no-> queue channel id selection
     fire onopen if association is up

incoming OPEN message:
    if channel already in use
       yes-> complain (perhaps fire onerror TBD)
       no-> Mark channel in use; inform application (ondatachannel); 
send ACK

Pretty darn simple.

>
> If DTLS exchange and SCTP establishment are associated with separate offer/answer transactions, there might be a few more combinations to consider.  The list also does not describe what is possible if DTLS role is not available directly to the apps.

DTLS and SCTP association establishment are async to offer/answer 
(kicked off by successful offer/answer completion).

>
> The above discussion might be an argument for segregating the stream ids available for application and browser selection.  There sure are plenty of them.  What do you think?  Then we wouldn't need to make DTLS role available to the app and there would only be a few restrictions on browser selection (it can't be used for external negotiation before DTLS role is determined).  And you could always have an overflow rule.
>
> Please correct me if I have missed anything.  Thanks!
>
> BR, Richard
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Randell Jesup
>> Sent: Sunday, October 27, 2013 4:46 AM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
>> 01.txt
>>
>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>> Richard,
>>>
>>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
>>>> Hi Harald,
>>>> You said: " I can't see a way to mix the two paradigms that
>>>> guarantees this never happening."  The two paradigms being browser
>>>> selection vs. application selection of data channel stream ids.
>> You can.  You just have to be careful.  For example, your application
>> could define that pre-negotiated channels will use 100-110, and then
>> specify those to both ends before association/offer/answer.  Later it
>> could use data-protocol to add dynamic channels (using even-odd).
>> Since we've told both ends about 100-110, there's no problem here.
>> Even/odd is ONLY to avoid glare when both sides decide to open a
>> channel "at the same time".  If you add a pre-negotiated channel after
>> initial establishment, it's up to you to avoid colliding with any
>> existing channels and to avoid colliding with any in-process-of-
>> creation dynamic
>> (data-protocol) channels.  There are a number of ways to avoid such a
>> collision safely (never use dynamic channels; use the DTLS role or an
>> existing dynamic channel id to determine even/odd, etc).
>>
>>>> My proposal has three elements, which together can guarantee that
>>>> there are no stream id allocation conflicts between peers:
>>>>      1. The browser and application select stream ids based on
>> initial
>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>> rule, the offering application knows its role immediately without
>>>> waiting for the DTLS or SDP handshake to occur.
>>> A similar issue has come up in the discussion of partial
>>> offers/answers. (Regarding how to assign a=mid values.) And a similar
>>> solution was proposed.
>>>
>>> It was then rejected on the basis that sometimes both "ends" think
>>> they are offerers or answerers. This comes about as a result of
>>> signaling-only B2BUAs that play games with O/A on two legs.
>> Exactly why we went with DTLS roles.
>>
>> --
>> Randell Jesup -- rjesup a t mozilla d o t com
>>
>> _______________________________________________
>> 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


-- 
Randell Jesup -- rjesup a t mozilla d o t com


From duerst@it.aoyama.ac.jp  Tue Oct 29 00:37:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC34C11E81A1 for ; Tue, 29 Oct 2013 00:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.792
X-Spam-Level: 
X-Spam-Status: No, score=-103.792 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvV7r9WZKVod for ; Tue, 29 Oct 2013 00:37:19 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1CD21E8064 for ; Tue, 29 Oct 2013 00:37:14 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r9T7b77E013378; Tue, 29 Oct 2013 16:37:07 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0bcb_37b3_e9c347ba_406c_11e3_9314_001e6722eec2; Tue, 29 Oct 2013 16:37:06 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B5543BFBBE; Tue, 29 Oct 2013 16:37:06 +0900 (JST)
Message-ID: <526F6596.7070204@it.aoyama.ac.jp>
Date: Tue, 29 Oct 2013 16:36:54 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: David Singer 
References: <52681A96.2020904@alvestrand.no> 		<5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org>		<5269F098.2020904@alvestrand.no>		<949EF20990823C4C85C18D59AA11AD8B0BF358@FR712WXCHMBA11.zeu.alcatel-lucent.com>				<526AE703.8000409@bbs.darktech.org>		<526C15CD.5020601@bbs.darktech.org> <526C3FE4.2040301@alvestrand.no>	<526C4686.2080702@bbs.darktech> <0DB4F63F-F111-41E3-B961-0B73B058867D@apple.com>
In-Reply-To: <0DB4F63F-F111-41E3-B961-0B73B058867D@apple.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 07:37:28 -0000

Hello David,

On 2013/10/28 18:19, David Singer wrote:
> We would be delighted for the community to establish a royalty free codec, in particular for web applications. To that goal, among other efforts, and together with several other companies, we proposed to MPEG last year H.264 Constrained Baseline as a basis for a new royalty free standard. This project, named by MPEG Web Video Coding, is now at a DIS (Draft International Standard) stage, and we are collecting IPR disclosures.
> We are also co-authors on the H.264 proposal for MTI to WebRTC.

This seems to be somewhat similar to the work by Google a few IETFs ago. 
Is there any timeline for this to become an ISO standard? And what's 
more important, any kind of time expectation or other information about 
when and under what conditions this might become royalty free?

Also, once both V8 and H.264 Constrained Baseline are available without 
the need to pay, what about declaring both of them MTI? That would 
definitely make things interoperable, and keep both sides equally happy. 
Just a crazy idea, I guess.

Regards,   Martin.

> As others have noted, we are, alas, formally constrained not to discuss what we might or might not do in future (sorry).
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From pkyzivat@alum.mit.edu  Tue Oct 29 08:05:51 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452BC11E826E for ; Tue, 29 Oct 2013 08:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.057
X-Spam-Level: 
X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=-0.106,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_18=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxxho2u8iqpf for ; Tue, 29 Oct 2013 08:05:45 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3111E8296 for ; Tue, 29 Oct 2013 08:05:39 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta10.westchester.pa.mail.comcast.net with comcast id izzU1m0031GhbT85A35dlz; Tue, 29 Oct 2013 15:05:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id j35d1m00H3ZTu2S3T35dXc; Tue, 29 Oct 2013 15:05:37 +0000
Message-ID: <526FCEC1.7000904@alum.mit.edu>
Date: Tue, 29 Oct 2013 11:05:37 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
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=q20121106; t=1383059137; bh=P+UF6VnqogQ5RvIh5MfAvGIcEr57mQeGUO684ZE3ST0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Deg8irbtVIzcdpZiyMnS/QmqCV+NITS6qWvFURhWVb90qiAjm3rTyyKdD/JX1dIli ZuRfF2PJ6+wsWrMungUF10UPPUuwdZDQAJvbskmikm1vdF9f2JVkMejBTG/P7ASe/U y7pqNtJDUoh87D3uRftCui4+2JQAheOZzCnu1ouDLfffNMEjlpc/gQmRs0N9ssHTj1 vaq5hVQYTHeKGZ1vQlkr1+MUM6pXfFFRQQBoxQIjAcpCmp4nUE9v4dMXVdY28NPhh7 H3IC7ZOa7PQhW9GJgGh9Ee7ajWZ3tdlTp56S5C2MBoo+PSk9qzJRnQKC3m1D3blhDQ 3iJAVetqCSulQ==
Subject: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 15:05:51 -0000

Scattered through this draft are references to inserting m-lines with 
a=inactive or a=recvonly, without the presence of a corresponding 
MediaStreamTrack. I don't understand how this is intended to work.

Once an offer/answer exchange has been done with that, ICE will be done, 
and after that there is an obligation to proceed with RTCP. In the case 
of recvonly there is also an expectation that packets will be arriving, 
and something needs to be done with them.

How is this expected to work? Is the browser supposed to do this in the 
absence of a MediaStreamTrack?

	Thanks,
	Paul

From richard.ejzak@alcatel-lucent.com  Tue Oct 29 08:06:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772E211E826E for ; Tue, 29 Oct 2013 08:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.25
X-Spam-Level: 
X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5Ci85ZvE2RM for ; Tue, 29 Oct 2013 08:06:30 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D603F21F9E45 for ; Tue, 29 Oct 2013 08:06:29 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9TF6PGC021920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Oct 2013 10:06:26 -0500 (CDT)
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 r9TF6Pm5009325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Oct 2013 11:06:25 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 29 Oct 2013 11:06:25 -0400
From: "Ejzak, Richard P (Richard)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQgABIioCAABByAP//ww2ggABSCoD//8IcAIAA11OAgABsdbCAAlPugIAAvIgAgAGzAlCAAR2/AIAAUj5w
Date: Tue, 29 Oct 2013 15:06:23 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com> <526F3D5A.9010205@jesup.org>
In-Reply-To: <526F3D5A.9010205@jesup.org>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 15:06:36 -0000

Hi Randell,
There is clearly a problem with terminology here that is not allowing us to=
 converge.  Even after your explanation, I believe my issues/questions rema=
in valid.  I understand that we are discussing the data protocol draft, but=
 we cannot ignore the pure external negotiation case when discussing compat=
ibility issues.

When I refer to in-band negotiation, I mean the use of the data channel pro=
tocol Open message to inform the peer browser that a specific stream id has=
 been allocated to a data channel.

When I refer to external negotiation, I mean the case where the data channe=
l protocol Open message is NOT used but instead both applications need to u=
se the create data channel method on the API to each browser to create both=
 ends of each data channel.

You apparently also use the term "external negotiation" to apply to the cas=
e where in-band negotiation needs to be augmented with additional communica=
tion (i.e., in addition to the Open message) between the applications.  I c=
onsider this just a special case of in-band negotiation.  Clear terminology=
 to separate these cases would be useful since they have very different cha=
racteristics.  Perhaps "augmented in-band negotiation" or "hybrid in-band/e=
xternal negotiation"?

The application can choose when creating a data channel via the API whether=
 to select the stream id for the data channel or to request the browser to =
select the stream id.  Apparently there are cases when the application MUST=
 use only one of these options to guarantee correct operation.

The application can also specifically request whether to send the data chan=
nel Open message once the SCTP association is established.  It is understoo=
d that if the browser does not send the Open message that the peer applicat=
ion must also use its API to create the other end of the data channel.

Without going through all the cases again, I think it's fair to say that th=
e situation warrants some additional explanation (in the drafts) to describ=
e these various cases and under what circumstances each is allowed.  Your p=
seudo-code does not cover all the cases, and the situation is more subtle t=
han you describe it to be.  The current drafts are far from adequate in thi=
s regard.

Please just answer one question: How does the application determine its DTL=
S role (i.e., whether to request even or odd numbers when choosing to selec=
t stream ids)?  Does this need to be inferred from allocated stream ids or =
can the application determine it directly?

Thanks,
Richard
=20

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Randell Jesup
> Sent: Monday, October 28, 2013 11:45 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> 01.txt
>=20
> On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
> > Hi Randell,
> > Thanks for suggesting the stream id assignment algorithm below.
> Please bear with me a little longer.  I agree that limited coexistence
> of application and browser stream id selection is possible, but it
> seems that there are some significant restrictions.
> >
> > Using in-band negotiation, I cannot see any way in which application
> selection and browser selection of stream ids can co-exist before DTLS
> roles are determined.  If application A selects an odd stream id, the
> only way to communicate this selection to application B's browser is
> via the in-band open message after the SCTP association has been
> established.
>=20
> No, the application can tell the other end that in conjunction with the
> offer (i.e. in application-specific signaling that accompanies the
> offer).  Any application using external negotiation must, in fact,
> handle external negotiation (even if that 'negotiation' is a set of
> hard-coded channel ids).
>=20
> Any later non-external-negotiated channel creations will select an
> unused id of the correct even/oddness (per DTLS role).  One SHOULD
> create all initial-connection-time externally negotiated channels
> before adding any new automatic (data-protocol) ones, in order to avoid
> surprises -- though I'd be rather surprised that an application would
> mix them in that way.  If the app does, it will work fine though.
>=20
> There is an implicit assumption that anything using external
> negotiation is either two instances of the same JS app or a cooperating
> app and server (those are by far the most common cases, and virtually
> the only cases), or two different apps that nonetheless know how to
> talk to each other and negotiate the channels on their own (I'll
> believe this when I see it, but it might happen).  External negotiation
> was added specifically for these pre-cooperating cases.
>=20
> Also, one point perhaps missed from the W3 spec:
>=20
>     7. If the value of the |id
>      id>|
>     attribute is null, initialize it to a value generated by the user
>     agent, according to the WebRTC DataChannel Protocol specification,
>     and skip to the next step. Otherwise, if the value of the |id
>      id>|
>     attribute is taken by an existing ||RTCDataChannel|
>      RTCDataChannel>|,
>     throw a |TBD| exception and abort these steps.
>=20
> Note this means you can create a channel for external negotation and
> let the browser select the id (which you then would tell the other
> side, and
> *they* would specify it to their end).  Note that the ID will not be
> set until DTLS roles are decided (and that's when onopen should fire as
> well).  This would not be very useful for setting up channels before
> offer/answer, but once offer/answer has completed, it lets you get a
> local channel id of correct oddness without having to scan all current
> datachannels to find an unused id value (assuming you're mixing styles
> of creation).
>=20
> (We may need to add a line to the IETF drafts to cover this case; need
> to check).  The application *could* just scan all known channels
> instead, that's just a pain.  And it really only matters if you mix
> types, which is likely to be rare outside of "create these N hard-coded
> channels at offer/answer time, then have some dynamic
> (automatically-assigned-id) channels that get used later if needed."
>=20
> >    It doesn't help to tell application B since it can't report the
> information to its browser.  So if application B creates another data
> channel and requests browser selection of a stream id then B's browser
> might end up selecting the same odd stream id, since it has no way to
> know to avoid it.  Not unless we reserve id values exclusively for
> application selection.  Do you agree?  If so, we should document this
> restriction.
>=20
> When you tell the browser/protocol that a channel has been externally
> negotiated, it will mark that as in-use of course. That's why
> collisions can only happen when the other side creates an externally-
> negotiated channel of the "wrong" oddness in a race with an automatic
> creation from this side.  This is trivially avoided when building an
> app.
>=20
> Much of this  discussion in the mail I'm replying to is moot, since
> it's based on an incorrect assumption about mixing.
>=20
> > There is no problem if only browser selection of stream ids is
> allowed before the SCTP association is established since both
> applications can learn which side owns odd/even values after channel
> open is reported to the peer (since there has to be at least one data
> channel created to trigger the establishment of the SCTP association).
> Now application and browser stream id selection can co-exist without a
> hitch.
> >
> > If we assume only application selection of stream ids is allowed with
> in-band negotiation before the SCTP association is established, then we
> can also allow co-existence of application selection and browser
> selection of stream ids after establishment of the SCTP association, as
> long as there is a way for each application to determine DTLS role.
> They can't use the trick in the last paragraph since the browsers
> haven't been asked to assign any stream ids.  Is there an API mechanism
> available to determine DTLS role?  Am I missing something here?
> >
> > With external negotiation, only application selection of stream ids
> can be allowed before DTLS role is determined since the external
> negotiation mechanism needs to be able to report to both peers (and
> browsers) the stream id(s) selected.  Once DTLS role is determined then
> application and browser selection of stream ids could co-exist, but
> requires that the applications learn which DTLS roles were negotiated
> (same issue as above).
> >
> > Interestingly, in-band and external negotiation can co-exist before
> DTLS role is established as long as application selection of stream ids
> is used exclusively.  All forms of in-band and external negotiation can
> co-exist after the SCTP association is established as long as the
> applications know the DTLS roles.
>=20
> I'm not going to reply line-by-line here, since I think much of this is
> based on a slightly incorrect understanding.
>=20
> > In summary, the following combinations are allowed:
> >
> > 1) application selection with in-band negotiation before SCTP
> > established and app determines DTLS role
> > 2) browser selection with in-band negotiation before SCTP established
> > 3) application selection with external negotiation before app
> > determines DTLS role
> > 4) application selection with in-band and external negotiation before
> > SCTP established and app determines DTLS role
> > 5) any combination of selection and negotiation after SCTP is
> > established if DTLS role is available to app
>=20
> I'd put it this way:
>=20
> 1)  You can create any number of DataChannels before
> createOffer()/createAnswer() so long as all of them are automatically
> assigned ids (what you call browser selection).  The actual ids are
> assigned after the DTLS roles are known.
>=20
> 2)  You can create any number of externally-negotiated channels before
> createOffer().  There is no need for them to match DTLS roles.
>=20
> 3) The answerer must create any externally-negotiated channels from its
> side before the channels can be used, and also SHOULD do so before
> creating automatic channels unless the application has made sure
> somehow
> a collision is impossible/unlikely.   In reality, there's no reason not
> to install the externally-negotiated channels before trying to create
> more, so the point is basically moot. (Note: you don't have to install
> the externally-negotiated channels before createAnswer, though normally
> I'd suggest doing so, just before creating automatically-generated
> ones.)
>=20
> 4) You can create externally-negotiated channels and then automatically
> negotiated channels before calling createOffer.  You can even mix them,
> since the automatically-generated ones will be assigned ids later when
> DTLS role is known (and will avoid any already in-use).  I'm not sure
> this is behavior that anyone would *need*, so I see no reason to
> promote mixing in that way - but it'll work.
>=20
> 5) Once the association is up, the application can use the method above
> (negotiated=3Dtrue but no id=3DN) to allocate ids without fear of collisi=
on
> with automatic channels.
>=20
> This is all emergent from the even/odd selection and letting the
> protocol choose ids when not externally negotiated.
>=20
> Pseudo-code:
>=20
> creation:
>      externally-selected-id?
>          yes-> mark channel in use
>              if channel already in use complain and fail
>          no-> dtls role known?
>              yes-> assign unused channel of correct oddness; send OPEN
>              no-> queue channel id selection
>      fire onopen if association is up
>=20
> incoming OPEN message:
>     if channel already in use
>        yes-> complain (perhaps fire onerror TBD)
>        no-> Mark channel in use; inform application (ondatachannel);
> send ACK
>=20
> Pretty darn simple.
>=20
> >
> > If DTLS exchange and SCTP establishment are associated with separate
> offer/answer transactions, there might be a few more combinations to
> consider.  The list also does not describe what is possible if DTLS
> role is not available directly to the apps.
>=20
> DTLS and SCTP association establishment are async to offer/answer
> (kicked off by successful offer/answer completion).
>=20
> >
> > The above discussion might be an argument for segregating the stream
> ids available for application and browser selection.  There sure are
> plenty of them.  What do you think?  Then we wouldn't need to make DTLS
> role available to the app and there would only be a few restrictions on
> browser selection (it can't be used for external negotiation before
> DTLS role is determined).  And you could always have an overflow rule.
> >
> > Please correct me if I have missed anything.  Thanks!
> >
> > BR, Richard
> >
> >> -----Original Message-----
> >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> >> Behalf Of Randell Jesup
> >> Sent: Sunday, October 27, 2013 4:46 AM
> >> To: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> >> 01.txt
> >>
> >> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
> >>> Richard,
> >>>
> >>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
> >>>> Hi Harald,
> >>>> You said: " I can't see a way to mix the two paradigms that
> >>>> guarantees this never happening."  The two paradigms being browser
> >>>> selection vs. application selection of data channel stream ids.
> >> You can.  You just have to be careful.  For example, your
> application
> >> could define that pre-negotiated channels will use 100-110, and then
> >> specify those to both ends before association/offer/answer.  Later
> it
> >> could use data-protocol to add dynamic channels (using even-odd).
> >> Since we've told both ends about 100-110, there's no problem here.
> >> Even/odd is ONLY to avoid glare when both sides decide to open a
> >> channel "at the same time".  If you add a pre-negotiated channel
> >> after initial establishment, it's up to you to avoid colliding with
> >> any existing channels and to avoid colliding with any in-process-of-
> >> creation dynamic
> >> (data-protocol) channels.  There are a number of ways to avoid such
> a
> >> collision safely (never use dynamic channels; use the DTLS role or
> an
> >> existing dynamic channel id to determine even/odd, etc).
> >>
> >>>> My proposal has three elements, which together can guarantee that
> >>>> there are no stream id allocation conflicts between peers:
> >>>>      1. The browser and application select stream ids based on
> >> initial
> >>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
> >>>> offerer uses even ids, initial answerer uses odd ids). With this
> >>>> rule, the offering application knows its role immediately without
> >>>> waiting for the DTLS or SDP handshake to occur.
> >>> A similar issue has come up in the discussion of partial
> >>> offers/answers. (Regarding how to assign a=3Dmid values.) And a
> >>> similar solution was proposed.
> >>>
> >>> It was then rejected on the basis that sometimes both "ends" think
> >>> they are offerers or answerers. This comes about as a result of
> >>> signaling-only B2BUAs that play games with O/A on two legs.
> >> Exactly why we went with DTLS roles.
> >>
> >> --
> >> Randell Jesup -- rjesup a t mozilla d o t com
> >>
> >> _______________________________________________
> >> 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
>=20
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From pkyzivat@alum.mit.edu  Tue Oct 29 08:23:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7585711E82DE for ; Tue, 29 Oct 2013 08:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.058
X-Spam-Level: 
X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-0.105,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpKHafCjVEHX for ; Tue, 29 Oct 2013 08:23:32 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id E800311E82D0 for ; Tue, 29 Oct 2013 08:23:04 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id izvz1m0061ei1Bg553P48F; Tue, 29 Oct 2013 15:23:04 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id j3P41m0033ZTu2S3k3P4cQ; Tue, 29 Oct 2013 15:23:04 +0000
Message-ID: <526FD2D8.7000709@alum.mit.edu>
Date: Tue, 29 Oct 2013 11:23:04 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com>	<03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>			<03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>	<120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de>	<03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>	<5269F3B5.2020308@alvestrand.no>	<03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com>	<526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org>
In-Reply-To: <526CE0BE.90606@jesup.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=q20121106; t=1383060184; bh=LHjX540M7qDs0YA2YGNQ6O4IoF9127hEi0K3M4Zomeo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q9HTMTZL8IyP2alAuh2JJ2jRLSrPXNqXiZqvLO+u33K6U5hafOCXKd/RT3o1W4b+3 prCtBOibGZmWatd4PcIPIBtof4wq+Ys3LMdl14/nmb7DBBxE9gS8wmXa1c8blZPm5E kvS087QNjAs8AfFss19AGs47TJ504JScdp7Esg5fp4CcrUxdRAzB//UAcBTk9vlS74 I2crjpoejqKpa5tbhNGm2fuq71Be+nvCWEKO4nFRVSsc1F2xRfb2CCj3I98Ge+YEGA 3gURW59qNIg56pgoICFBkNR4nKxCizjK/6aPyRvK3Kwsu/h4ChKbWqLs+WPcxa7Sd8 UmU6EgznDolYw==
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 15:23:38 -0000

On 10/27/13 5:45 AM, Randell Jesup wrote:
> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:

>>> My proposal has three elements, which together can guarantee that
>>> there are no stream id allocation conflicts between peers:
>>>     1. The browser and application select stream ids based on initial
>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>> offerer uses even ids, initial answerer uses odd ids). With this
>>> rule, the offering application knows its role immediately without
>>> waiting for the DTLS or SDP handshake to occur.
>>
>> A similar issue has come up in the discussion of partial
>> offers/answers. (Regarding how to assign a=mid values.) And a similar
>> solution was proposed.
>>
>> It was then rejected on the basis that sometimes both "ends" think
>> they are offerers or answerers. This comes about as a result of
>> signaling-only B2BUAs that play games with O/A on two legs.
>
> Exactly why we went with DTLS roles.

I'm not sure this eliminates the problem.

Is it not possible for an intermediary on the signaling path to insert 
itself in the media path, manipulating the SDP such that the two ends 
both establish the DTLS with the intermediary?

	Thanks,
	Paul


From ekr@rtfm.com  Tue Oct 29 08:29:35 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA90B21E8184 for ; Tue, 29 Oct 2013 08:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.455
X-Spam-Level: 
X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHsTxLeJ3EOa for ; Tue, 29 Oct 2013 08:29:29 -0700 (PDT)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id AC41311E82F0 for ; Tue, 29 Oct 2013 08:29:02 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id n12so4930143wgh.1 for ; Tue, 29 Oct 2013 08:29:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=StS6wi7MOFTXdvjieakcR8WDYUQMlOD78arxNNWnzzQ=; b=cNWqANjn0lBegPNHMuS9giDuVTXPckPUxlbOeZJqX8GZJ3lkIRjbYmYG6y9CGo84Ju 8Lj7BEfCP7C8W8vQc+Bdj2aZoDL/lA+ozRzrd9BUSWjQSCr0OZtFzMCF65Q/HdFRkUxq 25VX6PmR/emLOIWdGlnOReAs1mU20XORgRa96uvuxqQaKy+WD01YxX6Zbrl/jFGK33w5 F2yhW/Tgrbfcr1q1pGvWt5Pyz013MCBD5iqHFA5W44PtyX7E9KiGSvhi7MUmt3+BzQYe Q1Q0IEonDNQdyQZbwgREyJQ+v2qBnleTm0NCVdEI1Z3k+5xjprQdbyOJ9A6y11nplARU I2Ow==
X-Gm-Message-State: ALoCoQlTOf7818GU352xwHGwMn06IzRR9eG6PmRWoBMriX2KKhWvJN5avo/rPem83uc91rGinbV3
X-Received: by 10.180.24.137 with SMTP id u9mr8901wif.5.1383060541591; Tue, 29 Oct 2013 08:29:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Tue, 29 Oct 2013 08:28:21 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <526FD2D8.7000709@alum.mit.edu>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>
From: Eric Rescorla 
Date: Tue, 29 Oct 2013 08:28:21 -0700
Message-ID: 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=f46d04447f6748e68704e9e2e017
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 15:29:35 -0000

--f46d04447f6748e68704e9e2e017
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat  wrote:

> On 10/27/13 5:45 AM, Randell Jesup wrote:
>
>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>
>
>  My proposal has three elements, which together can guarantee that
>>>> there are no stream id allocation conflicts between peers:
>>>>     1. The browser and application select stream ids based on initial
>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>> rule, the offering application knows its role immediately without
>>>> waiting for the DTLS or SDP handshake to occur.
>>>>
>>>
>>> A similar issue has come up in the discussion of partial
>>> offers/answers. (Regarding how to assign a=mid values.) And a similar
>>> solution was proposed.
>>>
>>> It was then rejected on the basis that sometimes both "ends" think
>>> they are offerers or answerers. This comes about as a result of
>>> signaling-only B2BUAs that play games with O/A on two legs.
>>>
>>
>> Exactly why we went with DTLS roles.
>>
>
> I'm not sure this eliminates the problem.
>
> Is it not possible for an intermediary on the signaling path to insert
> itself in the media path, manipulating the SDP such that the two ends both
> establish the DTLS with the intermediary?
>

There is a separate role negotiation for DTLS (actpass, etc.) that works
even if both sides think they are the offerer or answerer.

-Ekr

--f46d04447f6748e68704e9e2e017
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat <=
;pkyzivat@alum.m=
it.edu> wrote:



On 10/27/13 5:45 AM, Rande=
ll Jesup wrote:



On 10/26/2013 6:30 PM, Paul Kyzivat wrote:










My proposal has three elements, which together can guarantee that

there are no stream id allocation conflicts between peers:

=A0 =A0 1. The browser and application select stream ids based on initial
SDP offerer/answerer role rather than DTLS role (e.g., initial

offerer uses even ids, initial answerer uses odd ids). With this

rule, the offering application knows its role immediately without

waiting for the DTLS or SDP handshake to occur.





A similar issue has come up in the discussion of partial

offers/answers. (Regarding how to assign a=3Dmid values.) And a similar

solution was proposed.



It was then rejected on the basis that sometimes both "ends" thin=
k

they are offerers or answerers. This comes about as a result of

signaling-only B2BUAs that play games with O/A on two legs.





Exactly why we went with DTLS roles.





I'm not sure this eliminates the problem.



Is it not possible for an intermediary on the signaling path to insert itse=
lf in the media path, manipulating the SDP such that the two ends both esta=
blish the DTLS with the intermediary?



There is a separate role negotiation for DTLS (actpass, etc.) that works
even if both sides think they are the offerer or answerer.

-Ekr



--f46d04447f6748e68704e9e2e017--

From creslin@digium.com  Tue Oct 29 08:35:43 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ADA11E82F5 for ; Tue, 29 Oct 2013 08:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level: 
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG2afCkJJoJC for ; Tue, 29 Oct 2013 08:35:38 -0700 (PDT)
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id C2C9D11E82BA for ; Tue, 29 Oct 2013 08:35:37 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id eo20so9130lab.40 for ; Tue, 29 Oct 2013 08:35:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1gCYLCxVDQwGxwJjt9oSL1B0bJABwlWtr/5dnVCcQtk=; b=B2PxTQO0r6uqk1J9bUIW85HT1idEEkt/ExnQUHIJIrW8ZCFI4ARveEMJxNFPriNQgH /TmI3hYr1By/OTP8bwvsbTMLsD0a3mak/d8toz1fjT+axG52MZibXQEDr51p+ub1vNHQ X9HD/easWVK9pUwb7hDTU9Ys05V6ZJGK0odEQm1/QasCuhhf3UG9B/QM8IzEGP6lEkhQ CbfX7zgUPLYIpLRIhRGigyhY/c2vOjY355fDCY1yA1XO1KIWm08QIc8se5By6fBct77+ ENyZ8EHwA0FGiFl1P3B/PwnzUNKYeA3E0/IriKrx2JPtsVYmSGuS4ywYkTS36iFh7ZqX 7KQw==
X-Gm-Message-State: ALoCoQk6FoXssGb5kLTy8gR6QkOx+rV2z4tqAtrCtMojSsuSX3T2lX2CYiVl0vsyrg1PcksaDhRP
MIME-Version: 1.0
X-Received: by 10.152.9.36 with SMTP id w4mr127289laa.34.1383060936704; Tue, 29 Oct 2013 08:35:36 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Tue, 29 Oct 2013 08:35:36 -0700 (PDT)
In-Reply-To: <526FD2D8.7000709@alum.mit.edu>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>
Date: Tue, 29 Oct 2013 10:35:36 -0500
Message-ID: 
From: Matt Fredrickson 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=089e0158b7e8d5d53304e9e2f757
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 15:35:43 -0000

--089e0158b7e8d5d53304e9e2f757
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat wrote:

> On 10/27/13 5:45 AM, Randell Jesup wrote:
>
>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>
>
>  My proposal has three elements, which together can guarantee that
>>>> there are no stream id allocation conflicts between peers:
>>>>     1. The browser and application select stream ids based on initial
>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>> rule, the offering application knows its role immediately without
>>>> waiting for the DTLS or SDP handshake to occur.
>>>>
>>>
>>> A similar issue has come up in the discussion of partial
>>> offers/answers. (Regarding how to assign a=mid values.) And a similar
>>> solution was proposed.
>>>
>>> It was then rejected on the basis that sometimes both "ends" think
>>> they are offerers or answerers. This comes about as a result of
>>> signaling-only B2BUAs that play games with O/A on two legs.
>>>
>>
>> Exactly why we went with DTLS roles.
>>
>
> I'm not sure this eliminates the problem.
>
> Is it not possible for an intermediary on the signaling path to insert
> itself in the media path, manipulating the SDP such that the two ends both
> establish the DTLS with the intermediary?


Correct me if I'm wrong, but I thought that the SDP itself was supposed to
be signed and able to be validated (perhaps using the identity mechanism),
to explicitly catch nefarious man in the middle type scenarios such as this.

Matthew Fredrickson

--089e0158b7e8d5d53304e9e2f757
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat &l=
t;pkyzivat@alum.=
mit.edu> wrote:


On 10/27/13 5:45 AM, Rande=
ll Jesup wrote:



On 10/26/2013 6:30 PM, Paul Kyzivat wrote:









My proposal has three elements, which together can guarantee that

there are no stream id allocation conflicts between peers:

=A0 =A0 1. The browser and application select stream ids based on initial
SDP offerer/answerer role rather than DTLS role (e.g., initial

offerer uses even ids, initial answerer uses odd ids). With this

rule, the offering application knows its role immediately without

waiting for the DTLS or SDP handshake to occur.





A similar issue has come up in the discussion of partial

offers/answers. (Regarding how to assign a=3Dmid values.) And a similar

solution was proposed.



It was then rejected on the basis that sometimes both "ends" thin=
k

they are offerers or answerers. This comes about as a result of

signaling-only B2BUAs that play games with O/A on two legs.





Exactly why we went with DTLS roles.





I'm not sure this eliminates the problem.



Is it not possible for an intermediary on the signaling path to insert itse=
lf in the media path, manipulating the SDP such that the two ends both esta=
blish the DTLS with the intermediary?


Correct me if I'm wrong, but I thought that the SDP itself was supposed=
 to be signed and able to be validated (perhaps using the identity mechanis=
m), to explicitly catch nefarious man in the middle type scenarios such as =
this.



Matthew Fredrickson


--089e0158b7e8d5d53304e9e2f757--

From richard.ejzak@alcatel-lucent.com  Tue Oct 29 08:52:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0A711E8309 for ; Tue, 29 Oct 2013 08:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.233
X-Spam-Level: 
X-Spam-Status: No, score=-10.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15CrPbHCgU0o for ; Tue, 29 Oct 2013 08:52:45 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D2A7C11E8110 for ; Tue, 29 Oct 2013 08:52:44 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r9TFqhWm010268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Oct 2013 10:52:44 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r9TFqh00008013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Oct 2013 11:52:43 -0400
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 29 Oct 2013 11:52:43 -0400
From: "Ejzak, Richard P (Richard)" 
To: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
Thread-Index: AQHOzpJANAkdcRSdIk6SHOj3uGyKMpoEFAyQgABIioCAABByAP//ww2ggABSCoD//8IcAIAA11OAgABsdbCAAlPugIAAvIgAgAGzAlCAAR2/AIAAUj5wgAAhfFA=
Date: Tue, 29 Oct 2013 15:52:42 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D86D329@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com> <526F3D5A.9010205@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 15:52:50 -0000

Hi Randell,
Please ignore the question at the end of my email below.  DTLS role can be =
determined from SDP inspection, which the application might prefer not to d=
o, but would have to be able to do if it uses SDP for external negotiation.=
  Still, we should point this out in the draft(s).

BR, Richard

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Ejzak, Richard P (Richard)
> Sent: Tuesday, October 29, 2013 10:06 AM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> 01.txt
>=20
> Hi Randell,
> There is clearly a problem with terminology here that is not allowing
> us to converge.  Even after your explanation, I believe my
> issues/questions remain valid.  I understand that we are discussing the
> data protocol draft, but we cannot ignore the pure external negotiation
> case when discussing compatibility issues.
>=20
> When I refer to in-band negotiation, I mean the use of the data channel
> protocol Open message to inform the peer browser that a specific stream
> id has been allocated to a data channel.
>=20
> When I refer to external negotiation, I mean the case where the data
> channel protocol Open message is NOT used but instead both applications
> need to use the create data channel method on the API to each browser
> to create both ends of each data channel.
>=20
> You apparently also use the term "external negotiation" to apply to the
> case where in-band negotiation needs to be augmented with additional
> communication (i.e., in addition to the Open message) between the
> applications.  I consider this just a special case of in-band
> negotiation.  Clear terminology to separate these cases would be useful
> since they have very different characteristics.  Perhaps "augmented in-
> band negotiation" or "hybrid in-band/external negotiation"?
>=20
> The application can choose when creating a data channel via the API
> whether to select the stream id for the data channel or to request the
> browser to select the stream id.  Apparently there are cases when the
> application MUST use only one of these options to guarantee correct
> operation.
>=20
> The application can also specifically request whether to send the data
> channel Open message once the SCTP association is established.  It is
> understood that if the browser does not send the Open message that the
> peer application must also use its API to create the other end of the
> data channel.
>=20
> Without going through all the cases again, I think it's fair to say
> that the situation warrants some additional explanation (in the drafts)
> to describe these various cases and under what circumstances each is
> allowed.  Your pseudo-code does not cover all the cases, and the
> situation is more subtle than you describe it to be.  The current
> drafts are far from adequate in this regard.
>=20
> Please just answer one question: How does the application determine its
> DTLS role (i.e., whether to request even or odd numbers when choosing
> to select stream ids)?  Does this need to be inferred from allocated
> stream ids or can the application determine it directly?
>=20
> Thanks,
> Richard
>=20
>=20
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Randell Jesup
> > Sent: Monday, October 28, 2013 11:45 PM
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> > 01.txt
> >
> > On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
> > > Hi Randell,
> > > Thanks for suggesting the stream id assignment algorithm below.
> > Please bear with me a little longer.  I agree that limited
> coexistence
> > of application and browser stream id selection is possible, but it
> > seems that there are some significant restrictions.
> > >
> > > Using in-band negotiation, I cannot see any way in which
> application
> > selection and browser selection of stream ids can co-exist before
> DTLS
> > roles are determined.  If application A selects an odd stream id, the
> > only way to communicate this selection to application B's browser is
> > via the in-band open message after the SCTP association has been
> > established.
> >
> > No, the application can tell the other end that in conjunction with
> > the offer (i.e. in application-specific signaling that accompanies
> the
> > offer).  Any application using external negotiation must, in fact,
> > handle external negotiation (even if that 'negotiation' is a set of
> > hard-coded channel ids).
> >
> > Any later non-external-negotiated channel creations will select an
> > unused id of the correct even/oddness (per DTLS role).  One SHOULD
> > create all initial-connection-time externally negotiated channels
> > before adding any new automatic (data-protocol) ones, in order to
> > avoid surprises -- though I'd be rather surprised that an application
> > would mix them in that way.  If the app does, it will work fine
> though.
> >
> > There is an implicit assumption that anything using external
> > negotiation is either two instances of the same JS app or a
> > cooperating app and server (those are by far the most common cases,
> > and virtually the only cases), or two different apps that nonetheless
> > know how to talk to each other and negotiate the channels on their
> own
> > (I'll believe this when I see it, but it might happen).  External
> > negotiation was added specifically for these pre-cooperating cases.
> >
> > Also, one point perhaps missed from the W3 spec:
> >
> >     7. If the value of the |id
> >      datachannel-
> > id>|
> >     attribute is null, initialize it to a value generated by the user
> >     agent, according to the WebRTC DataChannel Protocol
> specification,
> >     and skip to the next step. Otherwise, if the value of the |id
> >      datachannel-
> > id>|
> >     attribute is taken by an existing ||RTCDataChannel|
> >      > RTCDataChannel>|,
> >     throw a |TBD| exception and abort these steps.
> >
> > Note this means you can create a channel for external negotation and
> > let the browser select the id (which you then would tell the other
> > side, and
> > *they* would specify it to their end).  Note that the ID will not be
> > set until DTLS roles are decided (and that's when onopen should fire
> > as well).  This would not be very useful for setting up channels
> > before offer/answer, but once offer/answer has completed, it lets you
> > get a local channel id of correct oddness without having to scan all
> > current datachannels to find an unused id value (assuming you're
> > mixing styles of creation).
> >
> > (We may need to add a line to the IETF drafts to cover this case;
> need
> > to check).  The application *could* just scan all known channels
> > instead, that's just a pain.  And it really only matters if you mix
> > types, which is likely to be rare outside of "create these N
> > hard-coded channels at offer/answer time, then have some dynamic
> > (automatically-assigned-id) channels that get used later if needed."
> >
> > >    It doesn't help to tell application B since it can't report the
> > information to its browser.  So if application B creates another data
> > channel and requests browser selection of a stream id then B's
> browser
> > might end up selecting the same odd stream id, since it has no way to
> > know to avoid it.  Not unless we reserve id values exclusively for
> > application selection.  Do you agree?  If so, we should document this
> > restriction.
> >
> > When you tell the browser/protocol that a channel has been externally
> > negotiated, it will mark that as in-use of course. That's why
> > collisions can only happen when the other side creates an externally-
> > negotiated channel of the "wrong" oddness in a race with an automatic
> > creation from this side.  This is trivially avoided when building an
> > app.
> >
> > Much of this  discussion in the mail I'm replying to is moot, since
> > it's based on an incorrect assumption about mixing.
> >
> > > There is no problem if only browser selection of stream ids is
> > allowed before the SCTP association is established since both
> > applications can learn which side owns odd/even values after channel
> > open is reported to the peer (since there has to be at least one data
> > channel created to trigger the establishment of the SCTP
> association).
> > Now application and browser stream id selection can co-exist without
> a
> > hitch.
> > >
> > > If we assume only application selection of stream ids is allowed
> > > with
> > in-band negotiation before the SCTP association is established, then
> > we can also allow co-existence of application selection and browser
> > selection of stream ids after establishment of the SCTP association,
> > as long as there is a way for each application to determine DTLS
> role.
> > They can't use the trick in the last paragraph since the browsers
> > haven't been asked to assign any stream ids.  Is there an API
> > mechanism available to determine DTLS role?  Am I missing something
> here?
> > >
> > > With external negotiation, only application selection of stream ids
> > can be allowed before DTLS role is determined since the external
> > negotiation mechanism needs to be able to report to both peers (and
> > browsers) the stream id(s) selected.  Once DTLS role is determined
> > then application and browser selection of stream ids could co-exist,
> > but requires that the applications learn which DTLS roles were
> > negotiated (same issue as above).
> > >
> > > Interestingly, in-band and external negotiation can co-exist before
> > DTLS role is established as long as application selection of stream
> > ids is used exclusively.  All forms of in-band and external
> > negotiation can co-exist after the SCTP association is established as
> > long as the applications know the DTLS roles.
> >
> > I'm not going to reply line-by-line here, since I think much of this
> > is based on a slightly incorrect understanding.
> >
> > > In summary, the following combinations are allowed:
> > >
> > > 1) application selection with in-band negotiation before SCTP
> > > established and app determines DTLS role
> > > 2) browser selection with in-band negotiation before SCTP
> > > established
> > > 3) application selection with external negotiation before app
> > > determines DTLS role
> > > 4) application selection with in-band and external negotiation
> > > before SCTP established and app determines DTLS role
> > > 5) any combination of selection and negotiation after SCTP is
> > > established if DTLS role is available to app
> >
> > I'd put it this way:
> >
> > 1)  You can create any number of DataChannels before
> > createOffer()/createAnswer() so long as all of them are automatically
> > assigned ids (what you call browser selection).  The actual ids are
> > assigned after the DTLS roles are known.
> >
> > 2)  You can create any number of externally-negotiated channels
> before
> > createOffer().  There is no need for them to match DTLS roles.
> >
> > 3) The answerer must create any externally-negotiated channels from
> > its side before the channels can be used, and also SHOULD do so
> before
> > creating automatic channels unless the application has made sure
> > somehow
> > a collision is impossible/unlikely.   In reality, there's no reason
> not
> > to install the externally-negotiated channels before trying to create
> > more, so the point is basically moot. (Note: you don't have to
> install
> > the externally-negotiated channels before createAnswer, though
> > normally I'd suggest doing so, just before creating
> > automatically-generated
> > ones.)
> >
> > 4) You can create externally-negotiated channels and then
> > automatically negotiated channels before calling createOffer.  You
> can
> > even mix them, since the automatically-generated ones will be
> assigned
> > ids later when DTLS role is known (and will avoid any already in-
> use).
> > I'm not sure this is behavior that anyone would *need*, so I see no
> > reason to promote mixing in that way - but it'll work.
> >
> > 5) Once the association is up, the application can use the method
> > above (negotiated=3Dtrue but no id=3DN) to allocate ids without fear of
> > collision with automatic channels.
> >
> > This is all emergent from the even/odd selection and letting the
> > protocol choose ids when not externally negotiated.
> >
> > Pseudo-code:
> >
> > creation:
> >      externally-selected-id?
> >          yes-> mark channel in use
> >              if channel already in use complain and fail
> >          no-> dtls role known?
> >              yes-> assign unused channel of correct oddness; send
> OPEN
> >              no-> queue channel id selection
> >      fire onopen if association is up
> >
> > incoming OPEN message:
> >     if channel already in use
> >        yes-> complain (perhaps fire onerror TBD)
> >        no-> Mark channel in use; inform application (ondatachannel);
> > send ACK
> >
> > Pretty darn simple.
> >
> > >
> > > If DTLS exchange and SCTP establishment are associated with
> separate
> > offer/answer transactions, there might be a few more combinations to
> > consider.  The list also does not describe what is possible if DTLS
> > role is not available directly to the apps.
> >
> > DTLS and SCTP association establishment are async to offer/answer
> > (kicked off by successful offer/answer completion).
> >
> > >
> > > The above discussion might be an argument for segregating the
> stream
> > ids available for application and browser selection.  There sure are
> > plenty of them.  What do you think?  Then we wouldn't need to make
> > DTLS role available to the app and there would only be a few
> > restrictions on browser selection (it can't be used for external
> > negotiation before DTLS role is determined).  And you could always
> have an overflow rule.
> > >
> > > Please correct me if I have missed anything.  Thanks!
> > >
> > > BR, Richard
> > >
> > >> -----Original Message-----
> > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > >> Behalf Of Randell Jesup
> > >> Sent: Sunday, October 27, 2013 4:46 AM
> > >> To: rtcweb@ietf.org
> > >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> > >> 01.txt
> > >>
> > >> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
> > >>> Richard,
> > >>>
> > >>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
> > >>>> Hi Harald,
> > >>>> You said: " I can't see a way to mix the two paradigms that
> > >>>> guarantees this never happening."  The two paradigms being
> > >>>> browser selection vs. application selection of data channel
> stream ids.
> > >> You can.  You just have to be careful.  For example, your
> > application
> > >> could define that pre-negotiated channels will use 100-110, and
> > >> then specify those to both ends before association/offer/answer.
> > >> Later
> > it
> > >> could use data-protocol to add dynamic channels (using even-odd).
> > >> Since we've told both ends about 100-110, there's no problem here.
> > >> Even/odd is ONLY to avoid glare when both sides decide to open a
> > >> channel "at the same time".  If you add a pre-negotiated channel
> > >> after initial establishment, it's up to you to avoid colliding
> with
> > >> any existing channels and to avoid colliding with any
> > >> in-process-of- creation dynamic
> > >> (data-protocol) channels.  There are a number of ways to avoid
> such
> > a
> > >> collision safely (never use dynamic channels; use the DTLS role or
> > an
> > >> existing dynamic channel id to determine even/odd, etc).
> > >>
> > >>>> My proposal has three elements, which together can guarantee
> that
> > >>>> there are no stream id allocation conflicts between peers:
> > >>>>      1. The browser and application select stream ids based on
> > >> initial
> > >>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
> > >>>> offerer uses even ids, initial answerer uses odd ids). With this
> > >>>> rule, the offering application knows its role immediately
> without
> > >>>> waiting for the DTLS or SDP handshake to occur.
> > >>> A similar issue has come up in the discussion of partial
> > >>> offers/answers. (Regarding how to assign a=3Dmid values.) And a
> > >>> similar solution was proposed.
> > >>>
> > >>> It was then rejected on the basis that sometimes both "ends"
> think
> > >>> they are offerers or answerers. This comes about as a result of
> > >>> signaling-only B2BUAs that play games with O/A on two legs.
> > >> Exactly why we went with DTLS roles.
> > >>
> > >> --
> > >> Randell Jesup -- rjesup a t mozilla d o t com
> > >>
> > >> _______________________________________________
> > >> 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
> >
> >
> > --
> > Randell Jesup -- rjesup a t mozilla d o t com
> >
> > _______________________________________________
> > 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 mzanaty@cisco.com  Tue Oct 29 11:12:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF23B21F9F2B for ; Tue, 29 Oct 2013 11:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe8Qt7elR8Wh for ; Tue, 29 Oct 2013 11:12:18 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 61F3B21F9EC8 for ; Tue, 29 Oct 2013 11:12:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3948; q=dns/txt; s=iport; t=1383070338; x=1384279938; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=v4DnYMF2tZLVlUQATqTSygYqOnf0XW+eRTMbBNGnq8s=; b=iF6jgpfq/T3Nk0F3qOMuO0SVI2kQkiBN0M3Dqiy7bxMX93e5t71nIREf TiEs0xa0mzQiV20mJQvGBoj0H1O/bbFwdjgr7rNCzKAZJHfuMagBwVLbU 41QxOGAYv0+IZIDhbisymSrS417j9WMUPjx+wZ3cqlmQxgEzMKv6VYOvK U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjcFAAv6b1KtJV2d/2dsb2JhbABZgkNEOFS/NIEsFnSCJwEEgQsBCAQeHSgRFBECBAESCAyHYQMPDbAsDYlnBIxagjwtC4MfgQ0Dlh+OPIU3gyaCKg
X-IronPort-AV: E=Sophos;i="4.93,594,1378857600";  d="scan'208,217";a="277914687"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 29 Oct 2013 18:12:17 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9TICHF6006894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 18:12:17 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 13:12:17 -0500
From: "Mo Zanaty (mzanaty)" 
To: Ted Hardie , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Chair request on video codec discussion
Thread-Index: AQHO1NJmhjY7i9GuCUeMa9FEJ8cP2w==
Date: Tue, 29 Oct 2013 18:12:17 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91E1252CC@xmb-rcd-x14.cisco.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.150.30.137]
Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91E1252CCxmbrcdx14ciscoc_"
MIME-Version: 1.0
Subject: Re: [rtcweb] Chair request on video codec discussion
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:12:26 -0000

--_000_3879D71E758A7E4AA99A35DD8D41D3D91E1252CCxmbrcdx14ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

One minor point from a developer perspective, that would certainly not be s=
ignificant enough to impact MTI, is the availability of development, debugg=
ing and analysis tools. Things like wireshark dissectors, conversion/extrac=
tion tools like videosnarf, video bitstream analyzers like Elecard, etc. H.=
264 is universally supported. VP8 is supported in recent releases of a few =
analyzers like Interra (that are quite expensive however). A wireshark bug =
(9274) was file=
d a few weeks ago requesting VP8. I don=92t mention this to fuel the pros/c=
ons debate, or suggest it impacts MTI, but to bring visibility to an area w=
here the VP8 team can potentially help developers by sharing any tools they=
 may have with the community, or help develop them if missing.

Mo


On 10/28/13, 5:08 PM, Ted Hardie > wrote:

Howdy,

While the proponents of H.264 and VP8 continue to discuss performance, ther=
e appears to be general agreement that either codec could serve the purpose=
 set out our for our MTI:  to avoid negotiation failure that results in the=
 loss of basic functionality.  If there are technical issues which would pr=
event  either from being used as the MTI that have not yet been raised, ple=
ase do so before the beginning of IETF88.

regards,

Ted, Cullen, Magnus

--_000_3879D71E758A7E4AA99A35DD8D41D3D91E1252CCxmbrcdx14ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <04CC87ABCA1C9049840DC68E23594FB3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







One minor point from a developer perspective, that would certainly not=
 be significant enough to impact MTI, is the availability of development, d=
ebugging and analysis tools. Things like wireshark dissectors, conversion/e=
xtraction tools like videosnarf,
 video bitstream analyzers like Elecard, etc. H.264 is universally supporte=
d. VP8 is supported in recent releases of a few analyzers like Interra (tha=
t are quite expensive however). A
wire=
shark bug (9274) was filed a few weeks ago requesting VP8. I don=92t me=
ntion this to fuel the pros/cons debate, or suggest it impacts MTI, but to =
bring visibility to an area where the
 VP8 team can potentially help developers by sharing any tools they may hav=
e with the community, or help develop them if missing.







Mo















On 10/28/13, 5:08 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

















Howdy,



While the proponents of H.264 and VP8 continue to discuss performance, ther=
e appears to be general agreement that either codec could serve the purpose=
 set out our for our MTI:  to avoid negotiation failure that results i=
n the loss of basic functionality.  If
 there are technical issues which would prevent  either from being use=
d as the MTI that have not yet been raised, please do so before the beginni=
ng of IETF88.





regards,





Ted, Cullen, Magnus











--_000_3879D71E758A7E4AA99A35DD8D41D3D91E1252CCxmbrcdx14ciscoc_--

From martin.thomson@gmail.com  Tue Oct 29 11:27:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81BB21F8E97 for ; Tue, 29 Oct 2013 11:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level: 
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.080,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqC9rtQwo9sc for ; Tue, 29 Oct 2013 11:27:38 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AD57811E8110 for ; Tue, 29 Oct 2013 11:27:35 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id t60so242296wes.40 for ; Tue, 29 Oct 2013 11:27:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ObuDvM3m2hsLUojezhB43nYcftkUhqF9SKkmMbV4VGI=; b=Fw/NDHeBvsvnKWq7E5ROnQoSNXeTP1wXXYBtb3DYOnr7fdBxD0+RQqIExc/62avZsD /XEmJ4rHaqmGXbLOwIVTY/DkCD4+5V+2wAC+5EoOTFX1fS0BdcxyyPSWAag0sIJlYXlg dVwefE/9Og8eJw6ZqEf7U1zBoMnDB1K1KuR9N2B8jqH9xP+DAHNQqVovgvt5v+iF2E6c 4r4hYW5jgbZlaYLtwf7DL4Zu2SzCJ6QglBVuCQEiCk7zYeQBTwugZWlVmHTlaZ5p2/lX jMAEw9XEY2W0m33Sg+1gkIlYYKUSw2sJi/Wfol4aM+s8qEixCsQgMIfnMIvrHvlKY3aO vS/Q==
MIME-Version: 1.0
X-Received: by 10.194.2.108 with SMTP id 12mr947393wjt.64.1383071254684; Tue, 29 Oct 2013 11:27:34 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 29 Oct 2013 11:27:34 -0700 (PDT)
In-Reply-To: <526FCEC1.7000904@alum.mit.edu>
References: <526FCEC1.7000904@alum.mit.edu>
Date: Tue, 29 Oct 2013 11:27:34 -0700
Message-ID: 
From: Martin Thomson 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:27:38 -0000

On 29 October 2013 08:05, Paul Kyzivat  wrote:
> How is this expected to work? Is the browser supposed to do this in the
> absence of a MediaStreamTrack?

As I understand it, and my understanding is probably imperfect [22],
the idea is that at all points where an offer or answer is
constructed, the using application has access to MediaStreamTrack
objects that relate to the various m-lines.  Mostly.

That is, prior to creating an offer, you have the MediaStreamTrack
instances that relate to what you are sending.  And Prior to creating
an answer, you have both the tracks you want to send and the ones that
you want to receive.  Adam has proposed [2] that enabling or disabling
these tracks causes the appropriate a=sendonly/etc. attribute to be
set.

The only case that is a little strange is the one relating to the
received streams when creating an initial offer, where you use the
OfferToReceiveAudio or OfferToReceiveVideo constraint in order to
indirectly control the send/recv attributes.


[22] by which I do not offer as a failing on my part, ...
[2] http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0058.html

From pkyzivat@alum.mit.edu  Tue Oct 29 11:30:27 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400D311E8251 for ; Tue, 29 Oct 2013 11:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.063
X-Spam-Level: 
X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.100,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWbq9BK8st2C for ; Tue, 29 Oct 2013 11:30:21 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 364B911E8185 for ; Tue, 29 Oct 2013 11:30:21 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id j3GW1m0051GhbT85F6WLeB; Tue, 29 Oct 2013 18:30:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id j6WL1m00F3ZTu2S3T6WL75; Tue, 29 Oct 2013 18:30:20 +0000
Message-ID: <526FFEBC.7090302@alum.mit.edu>
Date: Tue, 29 Oct 2013 14:30:20 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Eric Rescorla 
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu> 
In-Reply-To: 
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=q20121106; t=1383071420; bh=yF606yi4Mlk+KLRjMGKwhsHylRUzvf+nyrOIPHw87kk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tntReen9mgy00aMdmGdmLw9d+4o6iruu6T6j7XVqieYFVa8qmHcRbaKHSVWGjV6yS t6p0K2YuAIHL4MYspXEZKZakQ31t2ji9GllTHZXjVuJtLJr/gr1MpvcObZaDPBiSgw 3DiGd9MohexlPsuicGMFKJSpMvHmZcTLeqY2EdkoaSYL8VPOshQt3cpI1AOi20fhlD dOXrtJ9D3g8dqtJJp2IWmKH95sLOJ+C6pbLX+5Jq6lWR65Si68/FSutCCmZO51iCs9 1NVf7U/xQ5oHZG03uAbS8gib/Woqc9TU5L/uAQmV33dTK/4gt9AcZAhk+mlodVuDit ppRNIf7fxYBRA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:30:27 -0000

Comment at end.

On 10/29/13 11:28 AM, Eric Rescorla wrote:
>
> On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat  > wrote:
>     On 10/27/13 5:45 AM, Randell Jesup wrote:
>         On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>
>                 My proposal has three elements, which together can
>                 guarantee that
>                 there are no stream id allocation conflicts between peers:
>                      1. The browser and application select stream ids
>                 based on initial
>                 SDP offerer/answerer role rather than DTLS role (e.g.,
>                 initial
>                 offerer uses even ids, initial answerer uses odd ids).
>                 With this
>                 rule, the offering application knows its role
>                 immediately without
>                 waiting for the DTLS or SDP handshake to occur.
>
>             A similar issue has come up in the discussion of partial
>             offers/answers. (Regarding how to assign a=mid values.) And
>             a similar
>             solution was proposed.
>
>             It was then rejected on the basis that sometimes both "ends"
>             think
>             they are offerers or answerers. This comes about as a result of
>             signaling-only B2BUAs that play games with O/A on two legs.
>
>         Exactly why we went with DTLS roles.
>
>     I'm not sure this eliminates the problem.
>
>     Is it not possible for an intermediary on the signaling path to
>     insert itself in the media path, manipulating the SDP such that the
>     two ends both establish the DTLS with the intermediary?
>
> There is a separate role negotiation for DTLS (actpass, etc.) that works
> even if both sides think they are the offerer or answerer.

I know about that. That mechanism is also used for TCP negotiation in 
SDP. And that is one place where an intermediary sometimes sticks its 
nose in explicitly to manipulate the roles, allowing both ends to be active.

In the current case, ICE and possible TURN result in getting the media 
path established without those games. So maybe there is less motivation 
for an intermediary. But still, they still seem to show up because 
administrators think they need them. And once there, couldn't the 
intermediary still end up making both ends think they are active?

	Thanks,
	Paul


From dave.taht@gmail.com  Tue Oct 29 11:33:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6021F9F45; Tue, 29 Oct 2013 11:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00C-rx1PhhTD; Tue, 29 Oct 2013 11:33:14 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8B411E8185; Tue, 29 Oct 2013 11:33:10 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id b13so263430wgh.27 for ; Tue, 29 Oct 2013 11:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0OykHK2Y/4qJTYzx0R9umLQO+V0KuDTm82t6VZ2tmOA=; b=hJriR93e8N2wgZ8uzfShEOSiGU5hkH7OrEq3Dpf+CUrHT9Uz3DF/2Zo7agjSj+ULyT OekOi+K9BxVtzyrcprjVRytSg5G/lFixsUsqZw8dRZxhTxfkHL6qZGl2YI0u2nCYEFcw QHJRZGwgHzhpm253rvqghM/NZPHOaQaDKt5Y73aIXq130yVxBwBJb+xSWdjDMJ+azVOu MGL/IEMxRL8bE462z9W/T1kllKokNNUlQ7T/vxqWh89GhMf4stUtrNxpAl/rOWljBKqS +pphj9BSIvRZ4l/N7s5QNYOSSMMxDH6tfYKktWEmmQzlFxvybmSQnONf9X6l6f/F8W14 j1rQ==
MIME-Version: 1.0
X-Received: by 10.180.184.14 with SMTP id eq14mr676140wic.56.1383071587668; Tue, 29 Oct 2013 11:33:07 -0700 (PDT)
Received: by 10.217.67.202 with HTTP; Tue, 29 Oct 2013 11:33:07 -0700 (PDT)
Date: Tue, 29 Oct 2013 11:33:07 -0700
Message-ID: 
From: Dave Taht 
To: "rmcat@ietf.org" , rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:33:16 -0000

In having my eyes glaze over at the codec debate I found myself
wondering to what extent anyone was pursuing truly low latency video
and audio, along the lines of what the lola project has been doing for
collaborative concerts.

See:

http://www.conts.it/artistica/lola-project

They ship raw audio and raw video, they actually use cameras where
they can get at scanlines and ship that (saving 16ms)

So I'm ignorant of what webrtc can do is there a codec selection (yuv?
48 bit audio? for the rawest video and audio possible?) All the extra
encoding steps we take today induce extra latency, and available
bandwidth continues to increase... and from a cc perspective if you
drop some bits from a scanline that's not a problem, but from audio
it's a huge deal....


--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html

From juberti@google.com  Tue Oct 29 11:46:09 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A6F11E816D for ; Tue, 29 Oct 2013 11:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level: 
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGafhQ3f+We3 for ; Tue, 29 Oct 2013 11:46:08 -0700 (PDT)
Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E88DB11E81A0 for ; Tue, 29 Oct 2013 11:46:07 -0700 (PDT)
Received: by mail-vb0-f45.google.com with SMTP id p6so186369vbe.18 for ; Tue, 29 Oct 2013 11:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H850kbTC9GrNdsW4BMKLuTfzkmwd0BV8JcrpUvFYvso=; b=CIVJmdegnt0geJYBKAb6xiVwsi8b3j5aLid6uakqa+vB3ahcMVeLz9IPXsdlR11lIH wocJMMbffh6T4zRl64ZnGX9GaCAu1HYuX/c6jjJM3XU2M/yr6h8LE83jVlAeJZzERiCx V7qjt/+CYICRP6itBzMX5pu4Cd8cawb/hNUQxzAjlD1Hd/um3PLFw/njeYrPtTCdxeR/ rrHBlOQ/7nCvlQ1gvldH/byQn2v7U37hDIClGKVx+HtDyFqSfw2ekIZpYLz6BVGgwnJg zjcleiLDVQH9NA+SQP93T2rIkPfWdAzFYxFBeqd8jpbjgIBrhVDyzmzcomJa+FnwEYZL xMVA==
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=H850kbTC9GrNdsW4BMKLuTfzkmwd0BV8JcrpUvFYvso=; b=nASX6YErmW4Pxu3nlc6dC6F1/4OjDZmbyL1i4WFzajX60EJlWJJpKch9XUOh2rvT54 PK4Bv9N0Ycj7p4cr8jdqxXhPa7UsgbHwotnRdhTVuFY5cpey//KHDF8PCXUqwAI5muEL g9nayMNJEOCT27Q4ukTvjoZEovhdDRoGFhmgsOa/tEuEGovRaiEdcXd9ODCyq9DPfLvt nisyHmoBBa6uf67pKgGxWnjVGDyjCxbVjbodns7mqcqis6po4f72Bvc2+z1Leo6pheKW afpjrmvpiU9OYZ7V8TD9OPhVkwktpWQoQYLrdvXTW6db/VUirtEqhgPtJSeaBbDvbNYV 1Trg==
X-Gm-Message-State: ALoCoQnbBMCwbRxv48Srge8hMBTpMFFsCy5s3oQaG3UtLCfp4H6zvzIZsaUmgEAm/nOi52Arak5QoKahRR9OTWhmg6c8Sb17L4y6CtlMPU5kx1N3oVDfQn2v94/Qwdcv2lmNabRLnImwwYarAQKZ5nQyaAdJlJ20TWswLUjoxGCRGlgP/Y8d4fYzPXHzh8c/qwQXmWlUQ1Hs
X-Received: by 10.52.37.36 with SMTP id v4mr364818vdj.54.1383072366203; Tue, 29 Oct 2013 11:46:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Tue, 29 Oct 2013 11:45:45 -0700 (PDT)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Tue, 29 Oct 2013 11:45:45 -0700
Message-ID: 
To: Dave Taht 
Content-Type: multipart/alternative; boundary=20cf307812b218d81604e9e5a109
Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] [rmcat] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:46:09 -0000

--20cf307812b218d81604e9e5a109
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Uncompressed 720p30 (I420) is ~330 Mbps, so even though bandwidth continues
to increase, we're still not at the point where we no longer need codecs
(in the general case).


On Tue, Oct 29, 2013 at 11:33 AM, Dave Taht  wrote:

> In having my eyes glaze over at the codec debate I found myself
> wondering to what extent anyone was pursuing truly low latency video
> and audio, along the lines of what the lola project has been doing for
> collaborative concerts.
>
> See:
>
> http://www.conts.it/artistica/lola-project
>
> They ship raw audio and raw video, they actually use cameras where
> they can get at scanlines and ship that (saving 16ms)
>
> So I'm ignorant of what webrtc can do is there a codec selection (yuv?
> 48 bit audio? for the rawest video and audio possible?) All the extra
> encoding steps we take today induce extra latency, and available
> bandwidth continues to increase... and from a cc perspective if you
> drop some bits from a scanline that's not a problem, but from audio
> it's a huge deal....
>
>
> --
> Dave T=C3=A4ht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>

--20cf307812b218d81604e9e5a109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Uncompressed 720p30 (I420) is ~330 Mbps, so even though ba=
ndwidth continues to increase, we're still not at the point where we no=
 longer need codecs (in the general case).
=




On Tue, Oct 29, 2013 at 11:33 AM, Dave Taht =
<dave.taht@gmail.com> wrote:


In having my eyes glaze over at the codec debate I found myself

wondering to what extent anyone was pursuing truly low latency video

and audio, along the lines of what the lola project has been doing for

collaborative concerts.



See:



ht=
tp://www.conts.it/artistica/lola-project



They ship raw audio and raw video, they actually use cameras where

they can get at scanlines and ship that (saving 16ms)



So I'm ignorant of what webrtc can do is there a codec selection (yuv?<=
br>
48 bit audio? for the rawest video and audio possible?) All the extra

encoding steps we take today induce extra latency, and available

bandwidth continues to increase... and from a cc perspective if you

drop some bits from a scanline that's not a problem, but from audio

it's a huge deal....





--

Dave T=C3=A4ht



Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib=
e.html





--20cf307812b218d81604e9e5a109--

From ekr@rtfm.com  Tue Oct 29 11:47:13 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F61E21F9D15 for ; Tue, 29 Oct 2013 11:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6AVujVvcL-L for ; Tue, 29 Oct 2013 11:47:07 -0700 (PDT)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7DC21F9D28 for ; Tue, 29 Oct 2013 11:47:03 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t61so274696wes.20 for ; Tue, 29 Oct 2013 11:47:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k7JPfQ3fvKkoTXjYWbqMoQYs2TFqGH4uUoKNSKvbrhc=; b=d6ty46NVKZff/txtMU9hxF32qjkXFce+V+Z7v2SqRvS8yucKj6EFtqEpIk1GbCiFET HK+seKmczZjkDohVXVZ/E1oJUuxyaO0/d6hSrUZB9TJNRKc7bydKRrMc21gdogAQN4vo mw/pDy1wHJmSV7r1ezFnwkFSF9WdSo8liYda7hyEyck55ciQb4sLWMuEtrGiOHX/Mi8b ln2klByTcqaa/Mt70FxUzcQIHeLDXBzwtKzWCx1bEcs7o8RBiOk2yAzmdXrJGtYgNRPI HtIPpExrX2/0c1yBwZGkMuMLrDM4Qd59PfAkPuufdFx1NBewLwhnoUxSyEAlGHyL7QMh KXrw==
X-Gm-Message-State: ALoCoQkX2X26rCQwze5tEoNQgiVEapyjnnS5JS+4utO9Mdq3onGyjCzv+vUCFXQMoEHYQDiDcj3M
X-Received: by 10.194.89.233 with SMTP id br9mr911859wjb.15.1383072422359; Tue, 29 Oct 2013 11:47:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Tue, 29 Oct 2013 11:46:22 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <526FFEBC.7090302@alum.mit.edu>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>  <526FFEBC.7090302@alum.mit.edu>
From: Eric Rescorla 
Date: Tue, 29 Oct 2013 11:46:22 -0700
Message-ID: 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=089e0102fb5c6f0cab04e9e5a450
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:47:13 -0000

--089e0102fb5c6f0cab04e9e5a450
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 29, 2013 at 11:30 AM, Paul Kyzivat wrote:

> Comment at end.
>
>
> On 10/29/13 11:28 AM, Eric Rescorla wrote:
>
>>
>> On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat > **> wrote:
>>     On 10/27/13 5:45 AM, Randell Jesup wrote:
>>         On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>
>>                 My proposal has three elements, which together can
>>                 guarantee that
>>                 there are no stream id allocation conflicts between peers:
>>                      1. The browser and application select stream ids
>>                 based on initial
>>                 SDP offerer/answerer role rather than DTLS role (e.g.,
>>                 initial
>>                 offerer uses even ids, initial answerer uses odd ids).
>>                 With this
>>                 rule, the offering application knows its role
>>                 immediately without
>>                 waiting for the DTLS or SDP handshake to occur.
>>
>>             A similar issue has come up in the discussion of partial
>>             offers/answers. (Regarding how to assign a=mid values.) And
>>             a similar
>>             solution was proposed.
>>
>>             It was then rejected on the basis that sometimes both "ends"
>>             think
>>             they are offerers or answerers. This comes about as a result
>> of
>>             signaling-only B2BUAs that play games with O/A on two legs.
>>
>>         Exactly why we went with DTLS roles.
>>
>>     I'm not sure this eliminates the problem.
>>
>>     Is it not possible for an intermediary on the signaling path to
>>     insert itself in the media path, manipulating the SDP such that the
>>     two ends both establish the DTLS with the intermediary?
>>
>> There is a separate role negotiation for DTLS (actpass, etc.) that works
>> even if both sides think they are the offerer or answerer.
>>
>
> I know about that. That mechanism is also used for TCP negotiation in SDP.
> And that is one place where an intermediary sometimes sticks its nose in
> explicitly to manipulate the roles, allowing both ends to be active.
>
> In the current case, ICE and possible TURN result in getting the media
> path established without those games. So maybe there is less motivation for
> an intermediary. But still, they still seem to show up because
> administrators think they need them. And once there, couldn't the
> intermediary still end up making both ends think they are active?
>

Well, it could but then they wouldn't be able to negotiate DTLS.

-Ekr

--089e0102fb5c6f0cab04e9e5a450
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Tue, Oct 29, 2013 at 11:30 AM, Paul Kyzivat &l=
t;pkyzivat@alum.=
mit.edu> wrote:



Comment at end.




On 10/29/13 11:28 AM, Eric Rescorla wrote:





On Tue, Oct 29, 2013 at 8:23 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<=
div class=3D"h5">
<mailto:pkyzi=
vat@alum.mit.edu>> wrote:

=A0 =A0 On 10/27/13 5:45 AM, Randell Jesup wrote:

=A0 =A0 =A0 =A0 On 10/26/2013 6:30 PM, Paul Kyzivat wrote:



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 My proposal has three elements, which toget=
her can

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 guarantee that

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 there are no stream id allocation conflicts=
 between peers:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01. The browser and application s=
elect stream ids

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 based on initial

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SDP offerer/answerer role rather than DTLS =
role (e.g.,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 initial

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offerer uses even ids, initial answerer use=
s odd ids).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 With this

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rule, the offering application knows its ro=
le

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 immediately without

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 waiting for the DTLS or SDP handshake to oc=
cur.



=A0 =A0 =A0 =A0 =A0 =A0 A similar issue has come up in the discussion of pa=
rtial

=A0 =A0 =A0 =A0 =A0 =A0 offers/answers. (Regarding how to assign a=3Dmid va=
lues.) And

=A0 =A0 =A0 =A0 =A0 =A0 a similar

=A0 =A0 =A0 =A0 =A0 =A0 solution was proposed.



=A0 =A0 =A0 =A0 =A0 =A0 It was then rejected on the basis that sometimes bo=
th "ends"

=A0 =A0 =A0 =A0 =A0 =A0 think

=A0 =A0 =A0 =A0 =A0 =A0 they are offerers or answerers. This comes about as=
 a result of

=A0 =A0 =A0 =A0 =A0 =A0 signaling-only B2BUAs that play games with O/A on t=
wo legs.



=A0 =A0 =A0 =A0 Exactly why we went with DTLS roles.



=A0 =A0 I'm not sure this eliminates the problem.



=A0 =A0 Is it not possible for an intermediary on the signaling path to

=A0 =A0 insert itself in the media path, manipulating the SDP such that the=


=A0 =A0 two ends both establish the DTLS with the intermediary?



There is a separate role negotiation for DTLS (actpass, etc.) that works
even if both sides think they are the offerer or answerer.





I know about that. That mechanism is also used for TCP negotiation in SDP. =
And that is one place where an intermediary sometimes sticks its nose in ex=
plicitly to manipulate the roles, allowing both ends to be active.





In the current case, ICE and possible TURN result in getting the media path=
 established without those games. So maybe there is less motivation for an =
intermediary. But still, they still seem to show up because administrators =
think they need them. And once there, couldn't the intermediary still e=
nd up making both ends think they are active?




Well, it could but then they wouldn't =
be able to negotiate DTLS.

-Ekr



--089e0102fb5c6f0cab04e9e5a450--

From christer.holmberg@ericsson.com  Tue Oct 29 11:48:04 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E816311E8243; Tue, 29 Oct 2013 11:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.559
X-Spam-Level: 
X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=0.690,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k11har0YKaWv; Tue, 29 Oct 2013 11:48:00 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2A23421F9D38; Tue, 29 Oct 2013 11:47:32 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-5e-527002c2f694
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2A.AA.03802.2C200725; Tue, 29 Oct 2013 19:47:31 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:47:30 +0100
From: Christer Holmberg 
To: Dave Taht , "rmcat@ietf.org" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] compressed codec-free webrtc?
Thread-Index: AQHO1NVb6o5lvgXpcESWrIk0bOMNk5oMBKaQ
Date: Tue, 29 Oct 2013 18:47:29 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FAEB5@ESESSMB209.ericsson.se>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
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+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvje5hpoIgg9c/hS32bDzJYrH65gc2 i7X/2tkdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsErow79yeyFPzjrpjxNbyB8T1nFyMH h4SAiUTLUokuRk4gU0ziwr31bF2MXBxCAocYJVZP/8sI4SxhlPh44gwbSAObgIVE9z9tEFNE IFdi+0UekF5hAWOJiUv/MYLYIkAjX62dwQphG0lMv7CEBcRmEVCVON94E6yGV8BXYsa2JnYQ W0ggQGLanmfMIDanQKBE9/23TCA2I9A930+tAbOZBcQlPhy8zgxxp4DEkj3noWxRiZeP/7FC 2EoSjUuesELU60ncmDqFDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUj e25iZk56udEmRmA8HNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAOEmt8Hie7e9tqQ9VKmKTtl9Ouep2q7u/voNPW27x4YNJt/24F56OTLjcZXz0zjFz XzuzdSYP1z/X2cxX9WpJK2v3n1ub/jK8reSoE/7rvb/hppAC24fOyImff8a9uzGT42BT+tq9 /x+tOB6S9jeLfdeBl/e2SW3/+UQs+lr1g5U1QvUqc1S7OJRYijMSDbWYi4oTAX9sN5xVAgAA
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:48:05 -0000

Hi Dave,

As far as the standards is concerned, you are allowed to implement and use =
whatever codec you want.

The discussion is about whether there should be a codec that everyone MUST =
implement.

Regards,

Christer

-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] P=
uolesta Dave Taht
L=E4hetetty: 29. lokakuuta 2013 20:33
Vastaanottaja: rmcat@ietf.org; rtcweb@ietf.org
Aihe: [rtcweb] compressed codec-free webrtc?

In having my eyes glaze over at the codec debate I found myself wondering t=
o what extent anyone was pursuing truly low latency video and audio, along =
the lines of what the lola project has been doing for collaborative concert=
s.

See:

http://www.conts.it/artistica/lola-project

They ship raw audio and raw video, they actually use cameras where they can=
 get at scanlines and ship that (saving 16ms)

So I'm ignorant of what webrtc can do is there a codec selection (yuv?
48 bit audio? for the rawest video and audio possible?) All the extra encod=
ing steps we take today induce extra latency, and available bandwidth conti=
nues to increase... and from a cc perspective if you drop some bits from a =
scanline that's not a problem, but from audio it's a huge deal....


--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From pkyzivat@alum.mit.edu  Tue Oct 29 11:53:32 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722411E827C for ; Tue, 29 Oct 2013 11:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.236
X-Spam-Level: 
X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=0.201,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE173N-WreVC for ; Tue, 29 Oct 2013 11:53:26 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0C55A11E8282 for ; Tue, 29 Oct 2013 11:53:22 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id j3kk1m0080SCNGk546tNAZ; Tue, 29 Oct 2013 18:53:22 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id j6tN1m00M3ZTu2S3V6tNei; Tue, 29 Oct 2013 18:53:22 +0000
Message-ID: <52700422.4020002@alum.mit.edu>
Date: Tue, 29 Oct 2013 14:53:22 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <526FCEC1.7000904@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=q20121106; t=1383072802; bh=KPIoDPRB15c19/k75zbxYFKfOuSpxDZa/Juc6ukZxE4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tQvP/behMT7tjNHIFrsKAuQkSlVQX60MThVkphjbFq71o0XTDo3fx7Krehxv5caOe 0ah7S65/Z9iEEZ1ht5GyNt612LU8wA1OXSgkYxQo/5xAXs7A8hrkFmGsuIKaaoiOEW kFNLr9//1K7mD3FBKSO+4DWChnP4oVin3p6U10EQJZcmvFGLQAh1/8ACI0HrFiD7BO 4vKcC96bLMIqH6zqb2zSROV4nRMthTWpvAqrSQNatnqg1px1hQn/YidN0WOBKuX7hf ZGxGM1h08srCrXhb/jObUpR+faiGe4ak9se+xSZh9EbsEaNFW/I+J0I2+QzRK5hJQp cSp+onfjwRMWg==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:53:32 -0000

On 10/29/13 2:27 PM, Martin Thomson wrote:
> On 29 October 2013 08:05, Paul Kyzivat  wrote:
>> How is this expected to work? Is the browser supposed to do this in the
>> absence of a MediaStreamTrack?
>
> As I understand it, and my understanding is probably imperfect [22],
> the idea is that at all points where an offer or answer is
> constructed, the using application has access to MediaStreamTrack
> objects that relate to the various m-lines.  Mostly.

My question only pertains to those cases where it doesn't.

> That is, prior to creating an offer, you have the MediaStreamTrack
> instances that relate to what you are sending.  And Prior to creating
> an answer, you have both the tracks you want to send and the ones that
> you want to receive.  Adam has proposed [2] that enabling or disabling
> these tracks causes the appropriate a=sendonly/etc. attribute to be
> set.

This confuses me a little, probably because I am not well informed about 
JSEP. The above implies that for a sendrecv m-line there will be two 
MediaStreamTracks, one for sending and one for receiving. But section 
5.3.1 of JSEP seems inconsistent with that:

    For each non-rejected m= section of a given media type, if there is a
    local MediaStreamTrack of the specified type which has been added to
    the PeerConnection via addStream and not yet associated with a m=
    section, the MediaStreamTrack is associated with the m= section at
    this time.  If there are more m= sections of a certain type than
    MediaStreamTracks, some m= sections will not have an associated
    MediaStreamTrack.  If there are more MediaStreamTracks of a certain
    type than m= sections, only the first N MediaStreamTracks will be
    able to be associated in the constructed answer.  The remainder will
    need to be associated in a subsequent offer.

This maps each MediaStreamTracks of a given type to a different m-line. 
I *thought* the use of "specified type" above meant audio/video. Am I 
missing something?

> The only case that is a little strange is the one relating to the
> received streams when creating an initial offer, where you use the
> OfferToReceiveAudio or OfferToReceiveVideo constraint in order to
> indirectly control the send/recv attributes.

I know that is one way of creating the situation I was wondering about. 
It isn't clear to me if that is the only way.

	Thanks,
	Paul

From pkyzivat@alum.mit.edu  Tue Oct 29 11:59:54 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31DE11E82A2 for ; Tue, 29 Oct 2013 11:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.238
X-Spam-Level: 
X-Spam-Status: No, score=-0.238 tagged_above=-999 required=5 tests=[AWL=0.199,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhVORfJlYltT for ; Tue, 29 Oct 2013 11:59:47 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id B40A011E827E for ; Tue, 29 Oct 2013 11:59:46 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id j0ZW1m0051GhbT8576zm9E; Tue, 29 Oct 2013 18:59:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id j6zl1m00m3ZTu2S3T6zllA; Tue, 29 Oct 2013 18:59:46 +0000
Message-ID: <527005A1.7000007@alum.mit.edu>
Date: Tue, 29 Oct 2013 14:59:45 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Eric Rescorla 
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>  <526FFEBC.7090302@alum.mit.edu> 
In-Reply-To: 
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=q20121106; t=1383073186; bh=Eu+mt2jYW32Dlea6ey98XaP6zahyvuzwK5J0gRcQSxM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kJvZidXtwtggBUkJ2oya2y07vK4wHYKmgpfG9ARveQg03Icbt0+q23MVrKVAfJQbN kL2V9pTGjAJDKyiYWtupChuftKP3tIt1A0oAp5/VQ58gg2tUWax1ymhA/qp7c3hmQJ sNLon/lI6TGZfkurE5/EwOgKwLDAu9GMMe5stx6wgYfYB38tvhAbShM8ady+Z4b4mZ Iu9rwDqeLex2yZ8bDxaDxTuj7eLKij3M7n6O349neOK9+k8nqt/gOVrN4FSSpcz32I LV94b09443ITUjV5RbAHYLoOobcLqnuR5ER0ij1ZPKfJF26BUlaxp7nFfMr/z3lja+ Wk0N6KSCjLeoA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 18:59:54 -0000

(trimming)

On 10/29/13 2:46 PM, Eric Rescorla wrote:

>              Is it not possible for an intermediary on the signaling path to
>              insert itself in the media path, manipulating the SDP such
>         that the
>              two ends both establish the DTLS with the intermediary?
>
>         There is a separate role negotiation for DTLS (actpass, etc.)
>         that works
>         even if both sides think they are the offerer or answerer.
>
>
>     I know about that. That mechanism is also used for TCP negotiation
>     in SDP. And that is one place where an intermediary sometimes sticks
>     its nose in explicitly to manipulate the roles, allowing both ends
>     to be active.
>
>     In the current case, ICE and possible TURN result in getting the
>     media path established without those games. So maybe there is less
>     motivation for an intermediary. But still, they still seem to show
>     up because administrators think they need them. And once there,
>     couldn't the intermediary still end up making both ends think they
>     are active?
>
> Well, it could but then they wouldn't be able to negotiate DTLS.

Couldn't it negotiation independently on each side - becoming a true MITM.

(I'm not advocating this as a good thing. But if it is possible, there 
will be someone who wants to do it, and somebody willing to sell them 
stuff to do it.)

	Thanks,
	Paul


From martin.thomson@gmail.com  Tue Oct 29 12:07:50 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30D11E8110 for ; Tue, 29 Oct 2013 12:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tFUASIXeTc2 for ; Tue, 29 Oct 2013 12:07:50 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3341811E8184 for ; Tue, 29 Oct 2013 12:07:43 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id t60so301214wes.16 for ; Tue, 29 Oct 2013 12:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yx9wlxcjbBlJ+YH/AZs+QZVeBlyymiuLpdyUReYIjxA=; b=IsUOe9gu/x/qAi5lVL4n0PBAOH0Uv7SllPaPbLT4Kz9AxsFgXQ2eDlmP4r7C2p5kwd mbg4aap4YEJkJh1gILeKAZwgzoItkz8pj0A4fitWo6fHJxP+IsWZUJ82AObGCTMFE4HR y4n6iC5S/3+hhscBRnE1gIdYaXIqYqvFTli3wpf2M7Eq6z04ghitOrINiw3UpefL4lqq VsRtFZKDPhmDgqYSYMP9SnYlFr2AbtdADYkS7apX7m5ookdqXZKYAkMsgX0F5ITNHhTl MHPRCdW2TBosiGiSWGvZgewY9jZQ2rF2451Z0XzvG/W+hbMbGuqUAmEhsXm+ZC5o4uEi IkmQ==
MIME-Version: 1.0
X-Received: by 10.194.205.37 with SMTP id ld5mr882922wjc.67.1383073662608; Tue, 29 Oct 2013 12:07:42 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 29 Oct 2013 12:07:42 -0700 (PDT)
In-Reply-To: <52700422.4020002@alum.mit.edu>
References: <526FCEC1.7000904@alum.mit.edu>  <52700422.4020002@alum.mit.edu>
Date: Tue, 29 Oct 2013 12:07:42 -0700
Message-ID: 
From: Martin Thomson 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 19:07:50 -0000

On 29 October 2013 11:53, Paul Kyzivat  wrote:
> This maps each MediaStreamTracks of a given type to a different m-line. I
> *thought* the use of "specified type" above meant audio/video. Am I missing
> something?

Yes.  sort of, though I'd expand "type" to encompass the concept of
compatibility.  Obviously a source with an H.264 encoder can't be
bound to an m= section that only has VP8 negotiated.

1. RTCPeerConnection binds tracks to m= sections
2. For sending tracks, that binding is tentatively made when an offer
or answer is constructed
3. Sending tracks are bound when setLocalDescription is called
4. For receiving tracks, that binding is made when the track is made,
which is when setRemoteDescription is called

When generating offers or answers, the set of bindings (including
tentative ones) - plus the enabled state of the track - determines
what of the send/recv attributes is attached to that m= section.

From adam@nostrum.com  Tue Oct 29 12:32:25 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1601711E80E2; Tue, 29 Oct 2013 12:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.431
X-Spam-Level: 
X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmPuYvKrC-UQ; Tue, 29 Oct 2013 12:32:24 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9E911E827E; Tue, 29 Oct 2013 12:32:18 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9TJW8op050530 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 14:32:08 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52700D33.30102@nostrum.com>
Date: Tue, 29 Oct 2013 14:32:03 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Dave Taht , "rmcat@ietf.org" , rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050300060905050501070507"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 19:32:25 -0000

This is a multi-part message in MIME format.
--------------050300060905050501070507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/29/13 13:33, Dave Taht wrote:
> In having my eyes glaze over at the codec debate I found myself
> wondering to what extent anyone was pursuing truly low latency video
> and audio, along the lines of what the lola project has been doing for
> collaborative concerts.
>
> See:
>
> http://www.conts.it/artistica/lola-project
>
> They ship raw audio and raw video, they actually use cameras where
> they can get at scanlines and ship that (saving 16ms)
>
> So I'm ignorant of what webrtc can do is there a codec selection (yuv?
> 48 bit audio? for the rawest video and audio possible?)

In theory, what you're looking for is this: 
http://tools.ietf.org/html/rfc4175

However, the caveats in that document are pretty huge:

    It is important to note that uncompressed video can have immense
    bandwidth requirements (up to 270 Mbps for standard-definition video,
    and approximately 1 Gbps for high-definition video).  This is
    sufficient to cause potential for denial-of-service if transmitted
    onto most currently available Internet paths.


Given the risk of Destroying The Internet Forever[tm] if any major 
browser vendor implemented this, I don't expect you'll see much 
deployment any time soon.

/a

--------------050300060905050501070507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/29/13 13:33, Dave Taht wrote:

    

    

      
In having my eyes glaze over at the codec debate I found myself
wondering to what extent anyone was pursuing truly low latency video
and audio, along the lines of what the lola project has been doing for
collaborative concerts.

See:

http://www.conts.it/artistica/lola-project

They ship raw audio and raw video, they actually use cameras where
they can get at scanlines and ship that (saving 16ms)

So I'm ignorant of what webrtc can do is there a codec selection (yuv?
48 bit audio? for the rawest video and audio possible?)

    

    

    In theory, what you're looking for is this:
    http://tools.ietf.org/html/rfc4175

    

    However, the caveats in that document are pretty huge:

    

    
    
   It is important to note that uncompressed video can have immense
   bandwidth requirements (up to 270 Mbps for standard-definition video,
   and approximately 1 Gbps for high-definition video).  This is
   sufficient to cause potential for denial-of-service if transmitted
   onto most currently available Internet paths.

    

    Given the risk of Destroying The Internet Forever[tm] if any major
    browser vendor implemented this, I don't expect you'll see much
    deployment any time soon.

    

    /a

  


--------------050300060905050501070507--

From dave.taht@gmail.com  Tue Oct 29 13:00:05 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1CA11E8255; Tue, 29 Oct 2013 13:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.323
X-Spam-Level: 
X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.277,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpXZGb-+Cffd; Tue, 29 Oct 2013 13:00:04 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 464CD11E81F8; Tue, 29 Oct 2013 13:00:04 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id b13so371908wgh.3 for ; Tue, 29 Oct 2013 13:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7q3rca2ftw1iXiJH7oQ2NjgXNtU320tcKYdQ/K6rpYo=; b=JqxRSgZnuN3Pnfovmb+4yhxTXeaUiOBdT7I64wedgWeP5hIRLElCWWk3vlrot9TSgi s726LJ1o+OPtuusaCtYBjb5EKIM5pI9TYg4DCoxfsUPfdgmAHtE27HAVQXs0ozcnlwg7 G8S1pT79YH9P+d2Lg8XPZDnd2JercX9oVcl+daDNSVzOKmHMbTORJZWmEklYoz+50CqP ccnpZJzIRxL90F3piIsJ8AXW7LzXTVnXfhVfNPoArj6aeA7yGjnDnMuUI+sqJFPyI6ta cJgiMzeD2QpbUykYt08vI3Wd1Is6ocwo943eeUFOGKNfh1UgAP/gdoE4FW7PkSr5BAQa ZeHQ==
MIME-Version: 1.0
X-Received: by 10.194.5.7 with SMTP id o7mr1166058wjo.17.1383076803322; Tue, 29 Oct 2013 13:00:03 -0700 (PDT)
Received: by 10.217.67.202 with HTTP; Tue, 29 Oct 2013 13:00:03 -0700 (PDT)
In-Reply-To: <52700D33.30102@nostrum.com>
References:  <52700D33.30102@nostrum.com>
Date: Tue, 29 Oct 2013 13:00:03 -0700
Message-ID: 
From: Dave Taht 
To: Adam Roach 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rmcat@ietf.org" , rtcweb@ietf.org
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 20:00:05 -0000

On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach  wrote:
> On 10/29/13 13:33, Dave Taht wrote:
>
> In having my eyes glaze over at the codec debate I found myself
> wondering to what extent anyone was pursuing truly low latency video
> and audio, along the lines of what the lola project has been doing for
> collaborative concerts.
>
> See:
>
> http://www.conts.it/artistica/lola-project
>
> They ship raw audio and raw video, they actually use cameras where
> they can get at scanlines and ship that (saving 16ms)
>
> So I'm ignorant of what webrtc can do is there a codec selection (yuv?
> 48 bit audio? for the rawest video and audio possible?)
>
>
> In theory, what you're looking for is this:
> http://tools.ietf.org/html/rfc4175

Thank you!

> However, the caveats in that document are pretty huge:
>
>    It is important to note that uncompressed video can have immense
>    bandwidth requirements (up to 270 Mbps for standard-definition video,
>    and approximately 1 Gbps for high-definition video).  This is
>    sufficient to cause potential for denial-of-service if transmitted
>    onto most currently available Internet paths.
>
>
> Given the risk of Destroying The Internet Forever[tm] if any major browse=
r
> vendor implemented this, I don't expect you'll see much deployment any ti=
me
> soon.

I don't see people doing videoconferences in the same qty as we do,
say, torrents (famous last words!). Certainly the panopticon might
take over the internet (but in that case delays from encoding should
be acceptable to our new robotic panoptic overloads, it's just the
pesky humans that have trouble with latency)

So, maybe running at rates like this would trouble the "Internet" a
bit now, but on internal networks, not so much.

270Mbits is a trivial amount of bandwidth for a modern switched
network. Homes and businesses that are wired are probably close to
universally switched GigE, so internal conversations could possibly
run at max speed and minimal latency.

Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.

Removing a serious delay-inducing-encoding step makes things like echo
cancellation unneeded, and live lola-like-collaboration possible.


> /a



--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.=
html

From martin.thomson@gmail.com  Tue Oct 29 13:01:33 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD011E8255; Tue, 29 Oct 2013 13:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPoORWt8FsYd; Tue, 29 Oct 2013 13:01:33 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id ED55421E809B; Tue, 29 Oct 2013 13:01:32 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id f4so419271wiw.16 for ; Tue, 29 Oct 2013 13:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y44Xqc3N4wTXUPAst2cL9Yc2wpl6ja61XUk9b3UTHA4=; b=oyW6r5IK7O0yBhep2fI1WGdY4FVN7tN15ApySaCV6tDcEcw752PD6ESUVhpZv2s7lK ABWPsc47OraBpFt0bEInmNld/ejWiJl78j0Gd2hIwEc7SGzTcEYTPXTpgnH+Il8OioO4 1TnX39iZ4V3PUvdsNiUjUyDH5FX5zHzoXARrd8de87LybohQSw9+dn3XAiASznEgXLfL ln57Eo8m2iUGStaN2PfhIssbf65C4YA/ApEngfYH1KFc7B9+ZbTjIjFx9uDoiMdWcU9s KHtOOWdsmp16g6BM1UvIwRBtuOeSGQF05fZwgGabpj4evQkhbrXijk5VWyD6YEveiNpE HZTQ==
MIME-Version: 1.0
X-Received: by 10.180.208.49 with SMTP id mb17mr14376539wic.64.1383076892184;  Tue, 29 Oct 2013 13:01:32 -0700 (PDT)
Received: by 10.227.202.194 with HTTP; Tue, 29 Oct 2013 13:01:32 -0700 (PDT)
In-Reply-To: <52700D33.30102@nostrum.com>
References:  <52700D33.30102@nostrum.com>
Date: Tue, 29 Oct 2013 13:01:32 -0700
Message-ID: 
From: Martin Thomson 
To: Adam Roach 
Content-Type: text/plain; charset=UTF-8
Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 20:01:33 -0000

On 29 October 2013 12:32, Adam Roach  wrote:
> In theory, what you're looking for is this:
> http://tools.ietf.org/html/rfc4175

I'm surprised that this didn't come up in the codec discussions.  Of
course, you'd want to use FEC so that you could reduce the need for
loss concealment.

From ekr@rtfm.com  Tue Oct 29 13:48:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4892011E81C4 for ; Tue, 29 Oct 2013 13:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MGWpSrax0vQ for ; Tue, 29 Oct 2013 13:48:27 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id CDA6011E81BB for ; Tue, 29 Oct 2013 13:48:24 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id ex4so3465900wid.9 for ; Tue, 29 Oct 2013 13:48:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ROZurSU7jHl5XJEaaHnWJUgscIkzxBUggya1XqKRb1I=; b=lVha6+dnQs54bKB80HRP6CyqyvduTl3Pr/W6Payj+6Px5RsLGnr5c275mKg/bSF7Go 5o/wDYXfY8Ucntha//jXAEubxSuD7w+qZ66TlJtbzj9wRUYO1FR6tyfCJarof1uUBw4u kucKunluUNFPNn/oGrLjFsW4oEIi/UinH56xrSSgeY/ejOCFaGBZYYSANuSr+1DCxOFS BIWnd4HT0edM2ffD9jrbxNZMk9KOisWgnPdwgdk2Y5nRzfh5wh9vZR8c8TZJNbS+yqVH 8HxXhaTnTdo3rdnZju2pZ4hDzHHKtnXSb7s9LQm7Hi0qRQigeGcaA57gOwG3L91sF95p fgAA==
X-Gm-Message-State: ALoCoQnCwegzEkTL9a5HFC9JEQCn1KWKn6UkZifzA9x0Frhe4RQce4m9AhDbtLnorn1lclxilB7Y
X-Received: by 10.180.24.137 with SMTP id u9mr1111293wif.5.1383079704002; Tue, 29 Oct 2013 13:48:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Tue, 29 Oct 2013 13:47:43 -0700 (PDT)
X-Originating-IP: [184.105.243.107]
In-Reply-To: <527005A1.7000007@alum.mit.edu>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>  <526FFEBC.7090302@alum.mit.edu>  <527005A1.7000007@alum.mit.edu>
From: Eric Rescorla 
Date: Tue, 29 Oct 2013 13:47:43 -0700
Message-ID: 
To: Paul Kyzivat 
Content-Type: multipart/alternative; boundary=f46d04447f67741ca804e9e7564d
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 20:48:44 -0000

--f46d04447f67741ca804e9e7564d
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 29, 2013 at 11:59 AM, Paul Kyzivat wrote:

> (trimming)
>
>
> On 10/29/13 2:46 PM, Eric Rescorla wrote:
>
>               Is it not possible for an intermediary on the signaling path
>> to
>>              insert itself in the media path, manipulating the SDP such
>>         that the
>>              two ends both establish the DTLS with the intermediary?
>>
>>         There is a separate role negotiation for DTLS (actpass, etc.)
>>         that works
>>         even if both sides think they are the offerer or answerer.
>>
>>
>>     I know about that. That mechanism is also used for TCP negotiation
>>     in SDP. And that is one place where an intermediary sometimes sticks
>>     its nose in explicitly to manipulate the roles, allowing both ends
>>     to be active.
>>
>>     In the current case, ICE and possible TURN result in getting the
>>     media path established without those games. So maybe there is less
>>     motivation for an intermediary. But still, they still seem to show
>>     up because administrators think they need them. And once there,
>>     couldn't the intermediary still end up making both ends think they
>>     are active?
>>
>> Well, it could but then they wouldn't be able to negotiate DTLS.
>>
>
> Couldn't it negotiation independently on each side - becoming a true MITM.
>
> (I'm not advocating this as a good thing. But if it is possible, there
> will be someone who wants to do it, and somebody willing to sell them stuff
> to do it.)
>

Sure, but then you would need to also intermediate the SCTP.

I'm not following what you see as the problem here.

-Ekr

--f46d04447f67741ca804e9e7564d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Tue, Oct 29, 2013 at 11:59 AM, Paul Kyzivat &l=
t;pkyzivat@alum.=
mit.edu> wrote:



(trimming)




On 10/29/13 2:46 PM, Eric Rescorla wrote:





=A0 =A0 =A0 =A0 =A0 =A0 =A0Is it not possible for an intermediary on the si=
gnaling path to

=A0 =A0 =A0 =A0 =A0 =A0 =A0insert itself in the media path, manipulating th=
e SDP such

=A0 =A0 =A0 =A0 that the

=A0 =A0 =A0 =A0 =A0 =A0 =A0two ends both establish the DTLS with the interm=
ediary?



=A0 =A0 =A0 =A0 There is a separate role negotiation for DTLS (actpass, etc=
.)

=A0 =A0 =A0 =A0 that works

=A0 =A0 =A0 =A0 even if both sides think they are the offerer or answerer.<=
br>




=A0 =A0 I know about that. That mechanism is also used for TCP negotiation<=
br>
=A0 =A0 in SDP. And that is one place where an intermediary sometimes stick=
s

=A0 =A0 its nose in explicitly to manipulate the roles, allowing both ends<=
br>
=A0 =A0 to be active.



=A0 =A0 In the current case, ICE and possible TURN result in getting the
=A0 =A0 media path established without those games. So maybe there is less<=
br>
=A0 =A0 motivation for an intermediary. But still, they still seem to show<=
br>
=A0 =A0 up because administrators think they need them. And once there,

=A0 =A0 couldn't the intermediary still end up making both ends think t=
hey

=A0 =A0 are active?



Well, it could but then they wouldn't be able to negotiate DTLS.





Couldn't it negotiation independently on each side - becoming a true MI=
TM.



(I'm not advocating this as a good thing. But if it is possible, there =
will be someone who wants to do it, and somebody willing to sell them stuff=
 to do it.)

Sure, but then you would ne=
ed to also intermediate the SCTP.




I'm not following what you see as the problem here.=


-Ekr



--f46d04447f67741ca804e9e7564d--

From harald@alvestrand.no  Tue Oct 29 13:51:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127AE11E8282 for ; Tue, 29 Oct 2013 13:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.998
X-Spam-Level: 
X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmDkBv0aGVBB for ; Tue, 29 Oct 2013 13:51:25 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0975E11E829D for ; Tue, 29 Oct 2013 13:51:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A1D8A39E8A5; Tue, 29 Oct 2013 21:51:14 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2BelmNXZAnZ; Tue, 29 Oct 2013 21:51:12 +0100 (CET)
Received: from [10.184.8.24] (host-95-199-136-24.mobileonline.telia.com [95.199.136.24]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5894039E18D; Tue, 29 Oct 2013 21:51:12 +0100 (CET)
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu> 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----57RKKW5QLKY7YKT9PUQFTMEP96Q64D"
From: Harald Alvestrand 
Date: Tue, 29 Oct 2013 21:51:12 +0100
To: Matt Fredrickson , Paul Kyzivat 
Message-ID: <43f5e30f-f001-4060-b19b-05ea33a865ad@email.android.com>
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 20:51:30 -0000

------57RKKW5QLKY7YKT9PUQFTMEP96Q64D
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

Sorry, you are wrong. Since signalling is left 100% to the application, the browser can make no assumption about the integrity of signalling messages.

Matt Fredrickson  wrote:
>On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat
>wrote:
>
>> On 10/27/13 5:45 AM, Randell Jesup wrote:
>>
>>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>>
>>
>>  My proposal has three elements, which together can guarantee that
>>>>> there are no stream id allocation conflicts between peers:
>>>>>     1. The browser and application select stream ids based on
>initial
>>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>>> rule, the offering application knows its role immediately without
>>>>> waiting for the DTLS or SDP handshake to occur.
>>>>>
>>>>
>>>> A similar issue has come up in the discussion of partial
>>>> offers/answers. (Regarding how to assign a=mid values.) And a
>similar
>>>> solution was proposed.
>>>>
>>>> It was then rejected on the basis that sometimes both "ends" think
>>>> they are offerers or answerers. This comes about as a result of
>>>> signaling-only B2BUAs that play games with O/A on two legs.
>>>>
>>>
>>> Exactly why we went with DTLS roles.
>>>
>>
>> I'm not sure this eliminates the problem.
>>
>> Is it not possible for an intermediary on the signaling path to
>insert
>> itself in the media path, manipulating the SDP such that the two ends
>both
>> establish the DTLS with the intermediary?
>
>
>Correct me if I'm wrong, but I thought that the SDP itself was supposed
>to
>be signed and able to be validated (perhaps using the identity
>mechanism),
>to explicitly catch nefarious man in the middle type scenarios such as
>this.
>
>Matthew Fredrickson
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------57RKKW5QLKY7YKT9PUQFTMEP96Q64D
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Sorry, you are wrong. Since signalling is left 100% to the application, the browser can make no assumption about the integrity of signalling messages.

Matt Fredrickson <creslin@digium.com> wrote:





On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:


On 10/27/13 5:45 AM, Randell Jesup wrote:



On 10/26/2013 6:30 PM, Paul Kyzivat wrote:









My proposal has three elements, which together can guarantee that

there are no stream id allocation conflicts between peers:

    1. The browser and application select stream ids based on initial

SDP offerer/answerer role rather than DTLS role (e.g., initial

offerer uses even ids, initial answerer uses odd ids). With this

rule, the offering application knows its role immediately without

waiting for the DTLS or SDP handshake to occur.





A similar issue has come up in the discussion of partial

offers/answers. (Regarding how to assign a=mid values.) And a similar

solution was proposed.



It was then rejected on the basis that sometimes both "ends" think

they are offerers or answerers. This comes about as a result of

signaling-only B2BUAs that play games with O/A on two legs.





Exactly why we went with DTLS roles.





I'm not sure this eliminates the problem.



Is it not possible for an intermediary on the signaling path to insert itself in the media path, manipulating the SDP such that the two ends both establish the DTLS with the intermediary?


Correct me if I'm wrong, but I thought that the SDP itself was supposed to be signed and able to be validated (perhaps using the identity mechanism), to explicitly catch nefarious man in the middle type scenarios such as this.



Matthew Fredrickson



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


-- 

Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------57RKKW5QLKY7YKT9PUQFTMEP96Q64D--


From harald@alvestrand.no  Tue Oct 29 13:54:34 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C37121E80A6 for ; Tue, 29 Oct 2013 13:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.298
X-Spam-Level: 
X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxWyklZ8bGy2 for ; Tue, 29 Oct 2013 13:54:29 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 57D9411E824C for ; Tue, 29 Oct 2013 13:54:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49D2D39E1BB; Tue, 29 Oct 2013 21:54:06 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yoSw25oFidR; Tue, 29 Oct 2013 21:54:05 +0100 (CET)
Received: from [10.184.8.24] (host-95-199-136-24.mobileonline.telia.com [95.199.136.24]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id ACCE439E18D; Tue, 29 Oct 2013 21:54:04 +0100 (CET)
User-Agent: K-9 Mail for Android
In-Reply-To: <527005A1.7000007@alum.mit.edu>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>  <526FFEBC.7090302@alum.mit.edu>  <527005A1.7000007@alum.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----HVKEM7EFT0DL9F33YWH52FKDMOZGLG"
From: Harald Alvestrand 
Date: Tue, 29 Oct 2013 21:54:09 +0100
To: Paul Kyzivat ,Eric Rescorla 
Message-ID: <8cb687a9-17dc-46d3-b794-d22aff4c1212@email.android.com>
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 20:54:34 -0000

------HVKEM7EFT0DL9F33YWH52FKDMOZGLG
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

If a mitm attack is being performed, one may perhaps assume that the attacker will also terminate and reinitialize the data channels?

Paul Kyzivat  wrote:
>(trimming)
>
>On 10/29/13 2:46 PM, Eric Rescorla wrote:
>
>>              Is it not possible for an intermediary on the signaling
>path to
>>              insert itself in the media path, manipulating the SDP
>such
>>         that the
>>              two ends both establish the DTLS with the intermediary?
>>
>>         There is a separate role negotiation for DTLS (actpass, etc.)
>>         that works
>>         even if both sides think they are the offerer or answerer.
>>
>>
>>     I know about that. That mechanism is also used for TCP
>negotiation
>>     in SDP. And that is one place where an intermediary sometimes
>sticks
>>     its nose in explicitly to manipulate the roles, allowing both
>ends
>>     to be active.
>>
>>     In the current case, ICE and possible TURN result in getting the
>>     media path established without those games. So maybe there is
>less
>>     motivation for an intermediary. But still, they still seem to
>show
>>     up because administrators think they need them. And once there,
>>     couldn't the intermediary still end up making both ends think
>they
>>     are active?
>>
>> Well, it could but then they wouldn't be able to negotiate DTLS.
>
>Couldn't it negotiation independently on each side - becoming a true
>MITM.
>
>(I'm not advocating this as a good thing. But if it is possible, there 
>will be someone who wants to do it, and somebody willing to sell them 
>stuff to do it.)
>
>	Thanks,
>	Paul
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------HVKEM7EFT0DL9F33YWH52FKDMOZGLG
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

If a mitm attack is being performed, one may perhaps assume that the attacker will also terminate and reinitialize the data channels?

Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:


(trimming)

On 10/29/13 2:46 PM, Eric Rescorla wrote:

Is it not possible for an intermediary on the signaling path to
insert itself in the media path, manipulating the SDP such
that the
two ends both establish the DTLS with the intermediary?

There is a separate role negotiation for DTLS (actpass, etc.)
that works
even if both sides think they are the offerer or answerer.


I know about that. That mechanism is also used for TCP negotiation
in SDP. And that is one place where an intermediary sometimes sticks
its nose in explicitly to manipulate the roles, allowing both ends
to be active.

In the current case, ICE and possible TURN result in getting the
media path established without those games. So maybe there is less
motivation for an
intermediary. But still, they still seem to show
up because administrators think they need them. And once there,
couldn't the intermediary still end up making both ends think they
are active?

Well, it could but then they wouldn't be able to negotiate DTLS.

Couldn't it negotiation independently on each side - becoming a true MITM.

(I'm not advocating this as a good thing. But if it is possible, there 
will be someone who wants to do it, and somebody willing to sell them 
stuff to do it.)

 Thanks,
 Paul


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


-- 

Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------HVKEM7EFT0DL9F33YWH52FKDMOZGLG--


From lgeyser@gmail.com  Tue Oct 29 14:14:40 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB84411E81C9; Tue, 29 Oct 2013 14:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydJLtxM8hYlU; Tue, 29 Oct 2013 14:14:40 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 994D611E8297; Tue, 29 Oct 2013 14:14:38 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id u14so539665lbd.1 for ; Tue, 29 Oct 2013 14:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=skLYJiAZtq9ZtmYQ8tuWhjA6ZKsb9ZS+BN8fWxcpwXQ=; b=EV8OU8h/nwythqTisfxP9IgwGyAun8kblIEwO0g2eLCdj0ThQzRojmh6ImsQbaOCm3 Ueuo6J1SIndUqULN4ptMzDrLQyh12LI35a5Lj4jm+dkjv9WE69u562of8iJa1aK/cOx6 RA89dWouYIrcpHCl17rEz7t00OWdRzB9C8u8oKBV+D5S3pBGeWpAuBKtEMKf3OEW06kD F57qgEqoK0zX3uGPSLFbd+pj9iMFvPraTmoSAMJOIOMGQ2N89plab7ZizaiVaeVrvtjc +GI6dQpBVqEHxoFXR0TVDyqUAQFxXDiSCcrGtoOSqBE6o2mTp4jx8OdXYMgho4ZY4UsB /Chw==
MIME-Version: 1.0
X-Received: by 10.112.143.166 with SMTP id sf6mr1206966lbb.29.1383081277460; Tue, 29 Oct 2013 14:14:37 -0700 (PDT)
Received: by 10.114.168.70 with HTTP; Tue, 29 Oct 2013 14:14:37 -0700 (PDT)
In-Reply-To: 
References:  <52700D33.30102@nostrum.com> 
Date: Tue, 29 Oct 2013 23:14:37 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=089e012296f43d13da04e9e7b42f
Cc: "rmcat@ietf.org" 
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 21:14:41 -0000

--089e012296f43d13da04e9e7b42f
Content-Type: text/plain; charset=ISO-8859-1

Meanwhile where I live how long would it take to show one frame over a
256Kbit/s connection? :)
The MTI codec needs to be a lossy codec.


On 29 October 2013 22:01, Martin Thomson  wrote:

> On 29 October 2013 12:32, Adam Roach  wrote:
> > In theory, what you're looking for is this:
> > http://tools.ietf.org/html/rfc4175
>
> I'm surprised that this didn't come up in the codec discussions.  Of
> course, you'd want to use FEC so that you could reduce the need for
> loss concealment.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--089e012296f43d13da04e9e7b42f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Meanwhile where I live how long would it take to show=
 one frame over a 256Kbit/s connection? :)
The MTI codec needs to =
be a lossy codec.



On 29 October 2013 22:01, Martin Thomson <martin.thomson@gmail.com<=
/a>> wrote:


On 29 October 2013 12:32, Adam Roach <adam@nostrum.com> wrote:

> In theory, what you're looking for is this:

> http:=
//tools.ietf.org/html/rfc4175




I'm surprised that this didn't come up in the codec discussio=
ns. =A0Of

course, you'd want to use FEC so that you could reduce the need for

loss concealment.


___________________________________=
____________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e012296f43d13da04e9e7b42f--

From randell-ietf@jesup.org  Tue Oct 29 19:14:08 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7811E8310 for ; Tue, 29 Oct 2013 19:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv33PfxxkNDw for ; Tue, 29 Oct 2013 19:14:03 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C641811E8309 for ; Tue, 29 Oct 2013 19:14:03 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:2356 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VbLII-000DEu-Ee for rtcweb@ietf.org; Tue, 29 Oct 2013 21:14:02 -0500
Message-ID: <52706B42.1060201@jesup.org>
Date: Tue, 29 Oct 2013 22:13:22 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <526FD2D8.7000709@alum.mit.edu>  <526FFEBC.7090302@alum.mit.edu>  <527005A1.7000007@alum.mit.edu> <8cb687a9-17dc-46d3-b794-d22aff4c1212@email.android.com>
In-Reply-To: <8cb687a9-17dc-46d3-b794-d22aff4c1212@email.android.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 02:14:08 -0000

On 10/29/2013 4:54 PM, Harald Alvestrand wrote:
> If a mitm attack is being performed, one may perhaps assume that the 
> attacker will also terminate and reinitialize the data channels?

Yes they can set up independent SCTP/DTLS/DataChannel connections. If 
they do that, they're responsible for making sure they correctly handle 
both SCTP/DataChannel connections such that both sides are happy.

And also as to the security aspect/MITM:
Yes, which is the reason for identity verification being an option in 
the spec.

>
> Paul Kyzivat  wrote:
>
>     (trimming)
>
>     On 10/29/13 2:46 PM, Eric Rescorla wrote:
>
>         Well, it could but then they wouldn't be able to negotiate DTLS.
>
>
>     Couldn't it negotiation independently on each side - becoming a true MITM.
>
>     (I'm not advocating this as a good thing. But if it is possible, there
>     will be someone who wants to do it, and somebody willing to sell them
>     stuff to do it.)
>
>       Thanks,
>       Paul
>
>     ------------------------------------------------------------------------
>
>     rtcweb mailing list
>     rtcweb@ietf.org
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Randell Jesup -- rjesup a t mozilla d o t com


From randell-ietf@jesup.org  Tue Oct 29 19:40:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBBD21E80D4 for ; Tue, 29 Oct 2013 19:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level: 
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QTSwlpUJlrm for ; Tue, 29 Oct 2013 19:40:05 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 498C721E80EE for ; Tue, 29 Oct 2013 19:39:57 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:2444 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VbLhM-00037a-Va for rtcweb@ietf.org; Tue, 29 Oct 2013 21:39:57 -0500
Message-ID: <52707155.8090003@jesup.org>
Date: Tue, 29 Oct 2013 22:39:17 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>   <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com> <5269F3B5.2020308@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com> <526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D1B9@US70UWXCHMBA04.zam.alcatel-lucent.com> <526F3D5A.9010205@jesup.org> <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86D2BB@US70UWXCHMBA04.zam.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 02:40:10 -0000

On 10/29/2013 11:06 AM, Ejzak, Richard P (Richard) wrote:
> Hi Randell,
> There is clearly a problem with terminology here that is not allowing us to converge.  Even after your explanation, I believe my issues/questions remain valid.  I understand that we are discussing the data protocol draft, but we cannot ignore the pure external negotiation case when discussing compatibility issues.

I'm definitely not ignoring it.  I'm not specifying what the application 
does in the external negotiation; just how that affects the protocol 
stacks at either end.  See my pseudo-code below, which has the advantage 
of avoiding english vagueries.  I think part of the confusion comes from 
looking/thinking about the JS API, not the IETF protocol.

> When I refer to in-band negotiation, I mean the use of the data channel protocol Open message to inform the peer browser that a specific stream id has been allocated to a data channel.

Agreed.

> When I refer to external negotiation, I mean the case where the data channel protocol Open message is NOT used but instead both applications need to use the create data channel method on the API to each browser to create both ends of each data channel.

Agreed.  That's how I've been using it, with what happens to decide on 
what the two apps end up using to initialize the two ends being largely 
out-of-scope to this discussion.

> You apparently also use the term "external negotiation" to apply to the case where in-band negotiation needs to be augmented with additional communication (i.e., in addition to the Open message) between the applications.

No, I didn't mean that to be what the term meant.  Where do you think I 
implied that?

>    I consider this just a special case of in-band negotiation.  Clear terminology to separate these cases would be useful since they have very different characteristics.  Perhaps "augmented in-band negotiation" or "hybrid in-band/external negotiation"?
>
> The application can choose when creating a data channel via the API whether to select the stream id for the data channel or to request the browser to select the stream id.  Apparently there are cases when the application MUST use only one of these options to guarantee correct operation.

There are many ways the application can guarantee correct operation.  
Letting the first side of an external negotiation request the stack 
assign a free id of 'correct' oddness is merely an API helper at the JS 
level; it has no impact on the protocol per se, and the application can 
do it itself (with extra bookkeeping, as I stated).  As such, it's only 
mentioned in the JS API spec, not the IETF drafts.

> The application can also specifically request whether to send the data channel Open message once the SCTP association is established.  It is understood that if the browser does not send the Open message that the peer application must also use its API to create the other end of the data channel.

This is the external negotiation - both sides tell the stack that a 
channel has been agreed to.   "Agreed to" can be "one side send to the 
other a channel definition, and the second side installs it, completing 
the channel."  It also can be "both sides (same JS app) know a priori 
that channel id 0 is the reliable control channel used for Foo messages, 
and so inform the stack".

> Without going through all the cases again, I think it's fair to say that the situation warrants some additional explanation (in the drafts) to describe these various cases and under what circumstances each is allowed.  Your pseudo-code does not cover all the cases, and the situation is more subtle than you describe it to be.  The current drafts are far from adequate in this regard.

I think the pseudo-code does cover it - as that's also virtually what 
we've implemented (running code and all that). ;-)   The other 
properties discussed emerge from that design and the JS API on top of 
it.  You can see the actual (rather more messy!) code in 
netwerk/sctp/datachannel/DataChannel.cpp in Firefox.  (Need to handle 
failures, requirement to allocate more streams from SCTP, JS interface, 
etc).

Has my discussion above cleared up any of the confusion?  If it has, do 
you have any proposed way to help others avoid that confusion?

Thanks for looking at it before we're at the mics!

     Randell

>
> Please just answer one question: How does the application determine its DTLS role (i.e., whether to request even or odd numbers when choosing to select stream ids)?  Does this need to be inferred from allocated stream ids or can the application determine it directly?
>
> Thanks,
> Richard
>   
>
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Randell Jesup
>> Sent: Monday, October 28, 2013 11:45 PM
>> To: rtcweb@ietf.org
>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
>> 01.txt
>>
>> On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
>>> Hi Randell,
>>> Thanks for suggesting the stream id assignment algorithm below.
>> Please bear with me a little longer.  I agree that limited coexistence
>> of application and browser stream id selection is possible, but it
>> seems that there are some significant restrictions.
>>> Using in-band negotiation, I cannot see any way in which application
>> selection and browser selection of stream ids can co-exist before DTLS
>> roles are determined.  If application A selects an odd stream id, the
>> only way to communicate this selection to application B's browser is
>> via the in-band open message after the SCTP association has been
>> established.
>>
>> No, the application can tell the other end that in conjunction with the
>> offer (i.e. in application-specific signaling that accompanies the
>> offer).  Any application using external negotiation must, in fact,
>> handle external negotiation (even if that 'negotiation' is a set of
>> hard-coded channel ids).
>>
>> Any later non-external-negotiated channel creations will select an
>> unused id of the correct even/oddness (per DTLS role).  One SHOULD
>> create all initial-connection-time externally negotiated channels
>> before adding any new automatic (data-protocol) ones, in order to avoid
>> surprises -- though I'd be rather surprised that an application would
>> mix them in that way.  If the app does, it will work fine though.
>>
>> There is an implicit assumption that anything using external
>> negotiation is either two instances of the same JS app or a cooperating
>> app and server (those are by far the most common cases, and virtually
>> the only cases), or two different apps that nonetheless know how to
>> talk to each other and negotiate the channels on their own (I'll
>> believe this when I see it, but it might happen).  External negotiation
>> was added specifically for these pre-cooperating cases.
>>
>> Also, one point perhaps missed from the W3 spec:
>>
>>      7. If the value of the |id
>>      > id>|
>>      attribute is null, initialize it to a value generated by the user
>>      agent, according to the WebRTC DataChannel Protocol specification,
>>      and skip to the next step. Otherwise, if the value of the |id
>>      > id>|
>>      attribute is taken by an existing ||RTCDataChannel|
>>      > RTCDataChannel>|,
>>      throw a |TBD| exception and abort these steps.
>>
>> Note this means you can create a channel for external negotation and
>> let the browser select the id (which you then would tell the other
>> side, and
>> *they* would specify it to their end).  Note that the ID will not be
>> set until DTLS roles are decided (and that's when onopen should fire as
>> well).  This would not be very useful for setting up channels before
>> offer/answer, but once offer/answer has completed, it lets you get a
>> local channel id of correct oddness without having to scan all current
>> datachannels to find an unused id value (assuming you're mixing styles
>> of creation).
>>
>> (We may need to add a line to the IETF drafts to cover this case; need
>> to check).  The application *could* just scan all known channels
>> instead, that's just a pain.  And it really only matters if you mix
>> types, which is likely to be rare outside of "create these N hard-coded
>> channels at offer/answer time, then have some dynamic
>> (automatically-assigned-id) channels that get used later if needed."
>>
>>>     It doesn't help to tell application B since it can't report the
>> information to its browser.  So if application B creates another data
>> channel and requests browser selection of a stream id then B's browser
>> might end up selecting the same odd stream id, since it has no way to
>> know to avoid it.  Not unless we reserve id values exclusively for
>> application selection.  Do you agree?  If so, we should document this
>> restriction.
>>
>> When you tell the browser/protocol that a channel has been externally
>> negotiated, it will mark that as in-use of course. That's why
>> collisions can only happen when the other side creates an externally-
>> negotiated channel of the "wrong" oddness in a race with an automatic
>> creation from this side.  This is trivially avoided when building an
>> app.
>>
>> Much of this  discussion in the mail I'm replying to is moot, since
>> it's based on an incorrect assumption about mixing.
>>
>>> There is no problem if only browser selection of stream ids is
>> allowed before the SCTP association is established since both
>> applications can learn which side owns odd/even values after channel
>> open is reported to the peer (since there has to be at least one data
>> channel created to trigger the establishment of the SCTP association).
>> Now application and browser stream id selection can co-exist without a
>> hitch.
>>> If we assume only application selection of stream ids is allowed with
>> in-band negotiation before the SCTP association is established, then we
>> can also allow co-existence of application selection and browser
>> selection of stream ids after establishment of the SCTP association, as
>> long as there is a way for each application to determine DTLS role.
>> They can't use the trick in the last paragraph since the browsers
>> haven't been asked to assign any stream ids.  Is there an API mechanism
>> available to determine DTLS role?  Am I missing something here?
>>> With external negotiation, only application selection of stream ids
>> can be allowed before DTLS role is determined since the external
>> negotiation mechanism needs to be able to report to both peers (and
>> browsers) the stream id(s) selected.  Once DTLS role is determined then
>> application and browser selection of stream ids could co-exist, but
>> requires that the applications learn which DTLS roles were negotiated
>> (same issue as above).
>>> Interestingly, in-band and external negotiation can co-exist before
>> DTLS role is established as long as application selection of stream ids
>> is used exclusively.  All forms of in-band and external negotiation can
>> co-exist after the SCTP association is established as long as the
>> applications know the DTLS roles.
>>
>> I'm not going to reply line-by-line here, since I think much of this is
>> based on a slightly incorrect understanding.
>>
>>> In summary, the following combinations are allowed:
>>>
>>> 1) application selection with in-band negotiation before SCTP
>>> established and app determines DTLS role
>>> 2) browser selection with in-band negotiation before SCTP established
>>> 3) application selection with external negotiation before app
>>> determines DTLS role
>>> 4) application selection with in-band and external negotiation before
>>> SCTP established and app determines DTLS role
>>> 5) any combination of selection and negotiation after SCTP is
>>> established if DTLS role is available to app
>> I'd put it this way:
>>
>> 1)  You can create any number of DataChannels before
>> createOffer()/createAnswer() so long as all of them are automatically
>> assigned ids (what you call browser selection).  The actual ids are
>> assigned after the DTLS roles are known.
>>
>> 2)  You can create any number of externally-negotiated channels before
>> createOffer().  There is no need for them to match DTLS roles.
>>
>> 3) The answerer must create any externally-negotiated channels from its
>> side before the channels can be used, and also SHOULD do so before
>> creating automatic channels unless the application has made sure
>> somehow
>> a collision is impossible/unlikely.   In reality, there's no reason not
>> to install the externally-negotiated channels before trying to create
>> more, so the point is basically moot. (Note: you don't have to install
>> the externally-negotiated channels before createAnswer, though normally
>> I'd suggest doing so, just before creating automatically-generated
>> ones.)
>>
>> 4) You can create externally-negotiated channels and then automatically
>> negotiated channels before calling createOffer.  You can even mix them,
>> since the automatically-generated ones will be assigned ids later when
>> DTLS role is known (and will avoid any already in-use).  I'm not sure
>> this is behavior that anyone would *need*, so I see no reason to
>> promote mixing in that way - but it'll work.
>>
>> 5) Once the association is up, the application can use the method above
>> (negotiated=true but no id=N) to allocate ids without fear of collision
>> with automatic channels.
>>
>> This is all emergent from the even/odd selection and letting the
>> protocol choose ids when not externally negotiated.
>>
>> Pseudo-code:
>>
>> creation:
>>       externally-selected-id?
>>           yes-> mark channel in use
>>               if channel already in use complain and fail
>>           no-> dtls role known?
>>               yes-> assign unused channel of correct oddness; send OPEN
>>               no-> queue channel id selection
>>       fire onopen if association is up
>>
>> incoming OPEN message:
>>      if channel already in use
>>         yes-> complain (perhaps fire onerror TBD)
>>         no-> Mark channel in use; inform application (ondatachannel);
>> send ACK
>>
>> Pretty darn simple.
>>
>>> If DTLS exchange and SCTP establishment are associated with separate
>> offer/answer transactions, there might be a few more combinations to
>> consider.  The list also does not describe what is possible if DTLS
>> role is not available directly to the apps.
>>
>> DTLS and SCTP association establishment are async to offer/answer
>> (kicked off by successful offer/answer completion).
>>
>>> The above discussion might be an argument for segregating the stream
>> ids available for application and browser selection.  There sure are
>> plenty of them.  What do you think?  Then we wouldn't need to make DTLS
>> role available to the app and there would only be a few restrictions on
>> browser selection (it can't be used for external negotiation before
>> DTLS role is determined).  And you could always have an overflow rule.
>>> Please correct me if I have missed anything.  Thanks!
>>>
>>> BR, Richard
>>>
>>>> -----Original Message-----
>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>>> Behalf Of Randell Jesup
>>>> Sent: Sunday, October 27, 2013 4:46 AM
>>>> To: rtcweb@ietf.org
>>>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
>>>> 01.txt
>>>>
>>>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>>>> Richard,
>>>>>
>>>>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
>>>>>> Hi Harald,
>>>>>> You said: " I can't see a way to mix the two paradigms that
>>>>>> guarantees this never happening."  The two paradigms being browser
>>>>>> selection vs. application selection of data channel stream ids.
>>>> You can.  You just have to be careful.  For example, your
>> application
>>>> could define that pre-negotiated channels will use 100-110, and then
>>>> specify those to both ends before association/offer/answer.  Later
>> it
>>>> could use data-protocol to add dynamic channels (using even-odd).
>>>> Since we've told both ends about 100-110, there's no problem here.
>>>> Even/odd is ONLY to avoid glare when both sides decide to open a
>>>> channel "at the same time".  If you add a pre-negotiated channel
>>>> after initial establishment, it's up to you to avoid colliding with
>>>> any existing channels and to avoid colliding with any in-process-of-
>>>> creation dynamic
>>>> (data-protocol) channels.  There are a number of ways to avoid such
>> a
>>>> collision safely (never use dynamic channels; use the DTLS role or
>> an
>>>> existing dynamic channel id to determine even/odd, etc).
>>>>
>>>>>> My proposal has three elements, which together can guarantee that
>>>>>> there are no stream id allocation conflicts between peers:
>>>>>>       1. The browser and application select stream ids based on
>>>> initial
>>>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>>>> rule, the offering application knows its role immediately without
>>>>>> waiting for the DTLS or SDP handshake to occur.
>>>>> A similar issue has come up in the discussion of partial
>>>>> offers/answers. (Regarding how to assign a=mid values.) And a
>>>>> similar solution was proposed.
>>>>>
>>>>> It was then rejected on the basis that sometimes both "ends" think
>>>>> they are offerers or answerers. This comes about as a result of
>>>>> signaling-only B2BUAs that play games with O/A on two legs.
>>>> Exactly why we went with DTLS roles.
>>>>
>>>> --
>>>> Randell Jesup -- rjesup a t mozilla d o t com
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> Randell Jesup -- rjesup a t mozilla d o t com
>>
>> _______________________________________________
>> 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


-- 
Randell Jesup -- rjesup a t mozilla d o t com


From randell-ietf@jesup.org  Tue Oct 29 20:01:14 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6011E8318 for ; Tue, 29 Oct 2013 20:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.342
X-Spam-Level: 
X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVYtlZnzrf2F for ; Tue, 29 Oct 2013 20:01:10 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 91F1C11E81F2 for ; Tue, 29 Oct 2013 20:01:06 -0700 (PDT)
Received: from pool-173-59-53-40.phlapa.fios.verizon.net ([173.59.53.40]:2525 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VbM1h-0008VJ-K3; Tue, 29 Oct 2013 22:00:57 -0500
Message-ID: <52707641.6090501@jesup.org>
Date: Tue, 29 Oct 2013 23:00:17 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <52700D33.30102@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 03:01:14 -0000

On 10/29/2013 4:00 PM, Dave Taht wrote:
> On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach  wrote:
>> On 10/29/13 13:33, Dave Taht wrote:
>>
>> In having my eyes glaze over at the codec debate I found myself
>> wondering to what extent anyone was pursuing truly low latency video
>> and audio, along the lines of what the lola project has been doing for
>> collaborative concerts.
>>
>> See:
>>
>> http://www.conts.it/artistica/lola-project
>>
>> They ship raw audio and raw video, they actually use cameras where
>> they can get at scanlines and ship that (saving 16ms)

Yeah, such things are not the norm unless you build hardware at a low 
level; OS-level access is only at the frame level generally. Also, there 
are costs to pushing that many bits around, even in a local network.  
(Check your network interface overhead when pushing that many bits!)  
However: You could use slicing or equivalent to get almost the same 
delay characteristics at HUGELY lower datarates.

For example, use one-MB high slices with current-tech codecs or 
something very similar.  Compression will kinda suck (well, not so much 
if you let it reference previous slices in the same frame and later 
slices in previous frames), but for standard def (480/60p let's say) the 
inherent delay would be on the order of 0.5ms, perhaps with another 
0.5ms for encode time (max, otherwise we aren't keeping up with 60fps.  
For 30p it would be 2ms max.  I don't know about you, but I would have 
trouble seeing 2ms delay.  And how are you guaranteeeing you're not 
seeing a 16/33ms sync delay at the other end?  Are you somehow 
genlocking the displays?  Not *impossible*, but pretty unlikely.

Memory bandwidth >>> network bandwidth, even fiber, though realistic 
interfaces.   And display tech matters.  I think there must be some FUD 
out there about how compression delays everything and makes it 
problematic.  The one place where such tight latencies matter is audio 
(distributed bands, etc), and there speed-of-light (and 
speed-of-interfaces) are what trip you up generally.  There are video 
equivalents (coordinated remote dance, etc) - but you still have to 
solve the capture and display problems, and compression per se isn't the 
major problem (no new tech is needed, just correct use of current 
tech/codecs I think).

Brings to mind "Racing the beam".... ;-)

>>
>> So I'm ignorant of what webrtc can do is there a codec selection (yuv?
>> 48 bit audio? for the rawest video and audio possible?)
>>
>>
>> In theory, what you're looking for is this:
>> http://tools.ietf.org/html/rfc4175
> Thank you!
>
>> However, the caveats in that document are pretty huge:
>>
>>     It is important to note that uncompressed video can have immense
>>     bandwidth requirements (up to 270 Mbps for standard-definition video,
>>     and approximately 1 Gbps for high-definition video).  This is
>>     sufficient to cause potential for denial-of-service if transmitted
>>     onto most currently available Internet paths.
>>
>>
>> Given the risk of Destroying The Internet Forever[tm] if any major browser
>> vendor implemented this, I don't expect you'll see much deployment any time
>> soon.
> I don't see people doing videoconferences in the same qty as we do,
> say, torrents (famous last words!). Certainly the panopticon might
> take over the internet (but in that case delays from encoding should
> be acceptable to our new robotic panoptic overloads, it's just the
> pesky humans that have trouble with latency)
>
> So, maybe running at rates like this would trouble the "Internet" a
> bit now, but on internal networks, not so much.
>
> 270Mbits is a trivial amount of bandwidth for a modern switched
> network. Homes and businesses that are wired are probably close to
> universally switched GigE, so internal conversations could possibly
> run at max speed and minimal latency.
>
> Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
> above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.
>
> Removing a serious delay-inducing-encoding step makes things like echo
> cancellation unneeded, and live lola-like-collaboration possible.

-- 
Randell Jesup -- rjesup a t mozilla d o t com


From mzanaty@cisco.com  Tue Oct 29 22:16:06 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0351611E8212; Tue, 29 Oct 2013 22:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDH42nm9dfb2; Tue, 29 Oct 2013 22:16:01 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0707711E80E4; Tue, 29 Oct 2013 22:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1116; q=dns/txt; s=iport; t=1383110161; x=1384319761; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JxAjzWF5ki+lpQkLGN2zB0cacahkjupvFD0R216fI3g=; b=ESoqNj26EnYTtbFRoXkW5h/IpwsOSMVdVgvNEPNQZ8PMmea5cELz4mqy JR4aBpDqK5tYJz9Mv+iefQ6Qotb9AcD5/Dzl0AhQRmtG9pLeZ7OtxG4y3 X/YzHJS8k6rzQcKbIjWMnQk91pZ8WC7N9PwoR3Er9cpU3N+P4FQLMMIn7 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAPmUcFKtJXHA/2dsb2JhbABZgwc4VL9AgSMWdIInAQSBCwEIIgJDESUCBAEOBAgXh1YDDw2wbQ2Ja4xfgj8zBYMfgQ0DiQeNGI49hTeDJoIq
X-IronPort-AV: E=Sophos;i="4.93,598,1378857600"; d="scan'208";a="278302729"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 30 Oct 2013 05:16:00 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9U5G0a3013113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 05:16:00 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 00:16:00 -0500
From: "Mo Zanaty (mzanaty)" 
To: Dave Taht , "rmcat@ietf.org" , "rtcweb@ietf.org" 
Thread-Topic: [rmcat] compressed codec-free webrtc?
Thread-Index: AQHO1S8e0dJsxyD5uE+5M3ouy1NJZw==
Date: Wed, 30 Oct 2013 05:15:59 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91E1258DB@xmb-rcd-x14.cisco.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.82.215.127]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] [rmcat] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 05:16:06 -0000

Give app developers yuv, udp and native-speed js, and they won=B9t need all
the webrtc plumbing at all. No chance of negotiation failure as icing. :)

Mo


On 10/29/13, 2:33 PM, Dave Taht  wrote:

In having my eyes glaze over at the codec debate I found myself
wondering to what extent anyone was pursuing truly low latency video
and audio, along the lines of what the lola project has been doing for
collaborative concerts.

See:

http://www.conts.it/artistica/lola-project

They ship raw audio and raw video, they actually use cameras where
they can get at scanlines and ship that (saving 16ms)

So I'm ignorant of what webrtc can do is there a codec selection (yuv?
48 bit audio? for the rawest video and audio possible?) All the extra
encoding steps we take today induce extra latency, and available
bandwidth continues to increase... and from a cc perspective if you
drop some bits from a scanline that's not a problem, but from audio
it's a huge deal....


--=20
Dave T=E4ht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html


From harald@alvestrand.no  Tue Oct 29 22:19:33 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3360311E81CB for ; Tue, 29 Oct 2013 22:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1twLiyIyT0rQ for ; Tue, 29 Oct 2013 22:19:28 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6078711E80E4 for ; Tue, 29 Oct 2013 22:19:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BAD4739E18D for ; Wed, 30 Oct 2013 06:19:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPLP5jO0S4W9 for ; Wed, 30 Oct 2013 06:19:25 +0100 (CET)
Received: from [172.16.39.182] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5816A39E03A for ; Wed, 30 Oct 2013 06:19:25 +0100 (CET)
Message-ID: <527096D9.4040502@alvestrand.no>
Date: Wed, 30 Oct 2013 06:19:21 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 	<52700D33.30102@nostrum.com>	 <52707641.6090501@jesup.org>
In-Reply-To: <52707641.6090501@jesup.org>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------090809020207060003060403"
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 05:19:33 -0000

This is a multi-part message in MIME format.
--------------090809020207060003060403
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Here at the MPEG meeting, one of my colleagues waxed lyrical about the
prospects of redesigning the CPU/memory/screen interfaces in order to
support the bandwidth requirements of getting 8K video from the decoder
to the screen.

Seems we may need a codec that decompresses at the group-of-pixel level,
or some new way of designing this, because normal memory buses can't
keep up with the data rate.

(8K is 7680 pixels wide by 4320 pixels tall (33.2 megapixels) according
to Wikipedia; at uncompressed 4:4:4, 3 bytes per pixel and 60 Hz, that's
23 Gbits/second, unless my calculator slipped a digit).

I think compression is going to be with us for a while.


On 10/30/2013 04:00 AM, Randell Jesup wrote:
> On 10/29/2013 4:00 PM, Dave Taht wrote:
>> On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach  wrote:
>>> On 10/29/13 13:33, Dave Taht wrote:
>>>
>>> In having my eyes glaze over at the codec debate I found myself
>>> wondering to what extent anyone was pursuing truly low latency video
>>> and audio, along the lines of what the lola project has been doing for
>>> collaborative concerts.
>>>
>>> See:
>>>
>>> http://www.conts.it/artistica/lola-project
>>>
>>> They ship raw audio and raw video, they actually use cameras where
>>> they can get at scanlines and ship that (saving 16ms)
>
> Yeah, such things are not the norm unless you build hardware at a low
> level; OS-level access is only at the frame level generally. Also,
> there are costs to pushing that many bits around, even in a local
> network.  (Check your network interface overhead when pushing that
> many bits!)  However: You could use slicing or equivalent to get
> almost the same delay characteristics at HUGELY lower datarates.
>
> For example, use one-MB high slices with current-tech codecs or
> something very similar.  Compression will kinda suck (well, not so
> much if you let it reference previous slices in the same frame and
> later slices in previous frames), but for standard def (480/60p let's
> say) the inherent delay would be on the order of 0.5ms, perhaps with
> another 0.5ms for encode time (max, otherwise we aren't keeping up
> with 60fps.  For 30p it would be 2ms max.  I don't know about you, but
> I would have trouble seeing 2ms delay.  And how are you guaranteeeing
> you're not seeing a 16/33ms sync delay at the other end?  Are you
> somehow genlocking the displays?  Not *impossible*, but pretty unlikely.
>
> Memory bandwidth >>> network bandwidth, even fiber, though realistic
> interfaces.   And display tech matters.  I think there must be some
> FUD out there about how compression delays everything and makes it
> problematic.  The one place where such tight latencies matter is audio
> (distributed bands, etc), and there speed-of-light (and
> speed-of-interfaces) are what trip you up generally.  There are video
> equivalents (coordinated remote dance, etc) - but you still have to
> solve the capture and display problems, and compression per se isn't
> the major problem (no new tech is needed, just correct use of current
> tech/codecs I think).
>
> Brings to mind "Racing the beam".... ;-)
>
>>>
>>> So I'm ignorant of what webrtc can do is there a codec selection (yuv?
>>> 48 bit audio? for the rawest video and audio possible?)
>>>
>>>
>>> In theory, what you're looking for is this:
>>> http://tools.ietf.org/html/rfc4175
>> Thank you!
>>
>>> However, the caveats in that document are pretty huge:
>>>
>>>     It is important to note that uncompressed video can have immense
>>>     bandwidth requirements (up to 270 Mbps for standard-definition
>>> video,
>>>     and approximately 1 Gbps for high-definition video).  This is
>>>     sufficient to cause potential for denial-of-service if transmitted
>>>     onto most currently available Internet paths.
>>>
>>>
>>> Given the risk of Destroying The Internet Forever[tm] if any major
>>> browser
>>> vendor implemented this, I don't expect you'll see much deployment
>>> any time
>>> soon.
>> I don't see people doing videoconferences in the same qty as we do,
>> say, torrents (famous last words!). Certainly the panopticon might
>> take over the internet (but in that case delays from encoding should
>> be acceptable to our new robotic panoptic overloads, it's just the
>> pesky humans that have trouble with latency)
>>
>> So, maybe running at rates like this would trouble the "Internet" a
>> bit now, but on internal networks, not so much.
>>
>> 270Mbits is a trivial amount of bandwidth for a modern switched
>> network. Homes and businesses that are wired are probably close to
>> universally switched GigE, so internal conversations could possibly
>> run at max speed and minimal latency.
>>
>> Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
>> above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.
>>
>> Removing a serious delay-inducing-encoding step makes things like echo
>> cancellation unneeded, and live lola-like-collaboration possible.
>


-- 
Surveillance is pervasive. Go Dark.


--------------090809020207060003060403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Here at the MPEG meeting, one of my
      colleagues waxed lyrical about the prospects of redesigning the
      CPU/memory/screen interfaces in order to support the bandwidth
      requirements of getting 8K video from the decoder to the screen.

      

      Seems we may need a codec that decompresses at the group-of-pixel
      level, or some new way of designing this, because normal memory
      buses can't keep up with the data rate.

      

      
      (8K is 7680 pixels wide by 4320 pixels tall (33.2 megapixels)
      according to Wikipedia; at uncompressed 4:4:4, 3 bytes per pixel
      and 60 Hz, that's 23 Gbits/second, unless my calculator slipped a
      digit).

      

      I think compression is going to be with us for a while.

      

      

      On 10/30/2013 04:00 AM, Randell Jesup wrote:

    

    
On
      10/29/2013 4:00 PM, Dave Taht wrote:
      

      
On Tue, Oct 29, 2013 at 12:32 PM, Adam
        Roach <adam@nostrum.com> wrote:
        

        
On 10/29/13 13:33, Dave Taht wrote:
          

          

          In having my eyes glaze over at the codec debate I found
          myself
          

          wondering to what extent anyone was pursuing truly low latency
          video
          

          and audio, along the lines of what the lola project has been
          doing for
          

          collaborative concerts.
          

          

          See:
          

          

          http://www.conts.it/artistica/lola-project
          

          

          They ship raw audio and raw video, they actually use cameras
          where
          

          they can get at scanlines and ship that (saving 16ms)
          

        

      

      

      Yeah, such things are not the norm unless you build hardware at a
      low level; OS-level access is only at the frame level generally.
      Also, there are costs to pushing that many bits around, even in a
      local network.  (Check your network interface overhead when
      pushing that many bits!)  However: You could use slicing or
      equivalent to get almost the same delay characteristics at HUGELY
      lower datarates.
      

      

      For example, use one-MB high slices with current-tech codecs or
      something very similar.  Compression will kinda suck (well, not so
      much if you let it reference previous slices in the same frame and
      later slices in previous frames), but for standard def (480/60p
      let's say) the inherent delay would be on the order of 0.5ms,
      perhaps with another 0.5ms for encode time (max, otherwise we
      aren't keeping up with 60fps.  For 30p it would be 2ms max.  I
      don't know about you, but I would have trouble seeing 2ms delay. 
      And how are you guaranteeeing you're not seeing a 16/33ms sync
      delay at the other end?  Are you somehow genlocking the displays? 
      Not *impossible*, but pretty unlikely.
      

      

      Memory bandwidth >>> network bandwidth, even fiber,
      though realistic interfaces.   And display tech matters.  I think
      there must be some FUD out there about how compression delays
      everything and makes it problematic.  The one place where such
      tight latencies matter is audio (distributed bands, etc), and
      there speed-of-light (and speed-of-interfaces) are what trip you
      up generally.  There are video equivalents (coordinated remote
      dance, etc) - but you still have to solve the capture and display
      problems, and compression per se isn't the major problem (no new
      tech is needed, just correct use of current tech/codecs I think).
      

      

      Brings to mind "Racing the beam".... ;-)
      

      

      

        

          

          So I'm ignorant of what webrtc can do is there a codec
          selection (yuv?
          

          48 bit audio? for the rawest video and audio possible?)
          

          

          

          In theory, what you're looking for is this:
          

          http://tools.ietf.org/html/rfc4175
          

        

        Thank you!
        

        

        
However, the caveats in that document
          are pretty huge:
          

          

              It is important to note that uncompressed video can have
          immense
          

              bandwidth requirements (up to 270 Mbps for
          standard-definition video,
          

              and approximately 1 Gbps for high-definition video).  This
          is
          

              sufficient to cause potential for denial-of-service if
          transmitted
          

              onto most currently available Internet paths.
          

          

          

          Given the risk of Destroying The Internet Forever[tm] if any
          major browser
          

          vendor implemented this, I don't expect you'll see much
          deployment any time
          

          soon.
          

        

        I don't see people doing videoconferences in the same qty as we
        do,
        

        say, torrents (famous last words!). Certainly the panopticon
        might
        

        take over the internet (but in that case delays from encoding
        should
        

        be acceptable to our new robotic panoptic overloads, it's just
        the
        

        pesky humans that have trouble with latency)
        

        

        So, maybe running at rates like this would trouble the
        "Internet" a
        

        bit now, but on internal networks, not so much.
        

        

        270Mbits is a trivial amount of bandwidth for a modern switched
        

        network. Homes and businesses that are wired are probably close
        to
        

        universally switched GigE, so internal conversations could
        possibly
        

        run at max speed and minimal latency.
        

        

        Internet-wise, Gfiber delivers GigE, upcoming docsis standards
        go well
        

        above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.
        

        

        Removing a serious delay-inducing-encoding step makes things
        like echo
        

        cancellation unneeded, and live lola-like-collaboration
        possible.
        

      

      

    

    

    

    
-- 
Surveillance is pervasive. Go Dark.


  


--------------090809020207060003060403--

From magnus.westerlund@ericsson.com  Wed Oct 30 00:20:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFEA21F9FB7 for ; Wed, 30 Oct 2013 00:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.372
X-Spam-Level: 
X-Spam-Status: No, score=-105.372 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPJT5aZTMgAJ for ; Wed, 30 Oct 2013 00:20:05 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1E21F9FB6 for ; Wed, 30 Oct 2013 00:19:47 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-4f-5270b310d0cf
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 14.24.16099.013B0725; Wed, 30 Oct 2013 08:19:44 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Wed, 30 Oct 2013 08:19:44 +0100
Message-ID: <5270B349.4070603@ericsson.com>
Date: Wed, 30 Oct 2013 08:20:41 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Randell Jesup , 
References: 	<52700D33.30102@nostrum.com>	 <52707641.6090501@jesup.org>
In-Reply-To: <52707641.6090501@jesup.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rldgc0GQwbYnshZnt2VZrP3Xzu7A 5LFkyU8mjw/L17EFMEVx2aSk5mSWpRbp2yVwZex/t4ytoFmn4ltvL0sD42HlLkZODgkBE4nH 374wQ9hiEhfurWfrYuTiEBI4xCixdFYzE4SznFFiX88jVpAqXgFtie3//7KB2CwCqhI7P/Wx gNhsAhYSN380gsVFBYIlbiw7xAZRLyhxcuYTsBoRAVuJd382gMWFBYwlZrT2skAsOM8o8fDG B7AzOAU0JXZt+gFkcwCdJC7R0xgEEmYW0JOYcrWFEcKWl2jeOhusXAjonoamDtYJjIKzkKyb haRlFpKWBYzMqxjZcxMzc9LLDTcxAkPy4JbfujsYT50TOcQozcGiJM774a1zkJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQbGzGdPJio7Xl7yXC6CV+zn0d6te9YL7PG9XlPK/Yr7ac1Wrcdi 3P7+pvar1z5dsjg3b4fj3PPee5oYe/+vOr5d80jCH7fcUxXbluoLOn0JfHB/m3z+gruRthon Ozb8EppmnL5ams8lcMezlvVlTZc6L6pcE+m84b6hOn/vu0hdy6WN1psjnvZ8V2Ipzkg01GIu Kk4EAFGx3EgXAgAA
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 07:20:10 -0000

Hi,

I think using RAW video is completely out of the question for general
WebRTC usage, however I would note that the specification needed to
encapsulate RAW video is available as RTP payload formats, so you are
free to implement and offer them in signalling.

RTP Payload Format for Uncompressed Video
Which supports up to 32768 scan lines and pixels per line. It also
supports various samplings and color spaces.

http://tools.ietf.org/html/rfc4175
Data rate will depend on resolution, frame-rate and sampling.

RTP Payload Format for Society of Motion Picture and Television
Engineers (SMPTE) 292M Video

http://tools.ietf.org/html/rfc3497

Total data rate be either 1.485 Gbps or 1.485/1.001 Gbps.

Cheers

Magnus


On 2013-10-30 04:00, Randell Jesup wrote:
> On 10/29/2013 4:00 PM, Dave Taht wrote:
>> On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach  wrote:
>>> On 10/29/13 13:33, Dave Taht wrote:
>>>
>>> In having my eyes glaze over at the codec debate I found myself
>>> wondering to what extent anyone was pursuing truly low latency video
>>> and audio, along the lines of what the lola project has been doing for
>>> collaborative concerts.
>>>
>>> See:
>>>
>>> http://www.conts.it/artistica/lola-project
>>>
>>> They ship raw audio and raw video, they actually use cameras where
>>> they can get at scanlines and ship that (saving 16ms)
> 
> Yeah, such things are not the norm unless you build hardware at a low
> level; OS-level access is only at the frame level generally. Also, there
> are costs to pushing that many bits around, even in a local network. 
> (Check your network interface overhead when pushing that many bits!) 
> However: You could use slicing or equivalent to get almost the same
> delay characteristics at HUGELY lower datarates.
> 
> For example, use one-MB high slices with current-tech codecs or
> something very similar.  Compression will kinda suck (well, not so much
> if you let it reference previous slices in the same frame and later
> slices in previous frames), but for standard def (480/60p let's say) the
> inherent delay would be on the order of 0.5ms, perhaps with another
> 0.5ms for encode time (max, otherwise we aren't keeping up with 60fps. 
> For 30p it would be 2ms max.  I don't know about you, but I would have
> trouble seeing 2ms delay.  And how are you guaranteeeing you're not
> seeing a 16/33ms sync delay at the other end?  Are you somehow
> genlocking the displays?  Not *impossible*, but pretty unlikely.
> 
> Memory bandwidth >>> network bandwidth, even fiber, though realistic
> interfaces.   And display tech matters.  I think there must be some FUD
> out there about how compression delays everything and makes it
> problematic.  The one place where such tight latencies matter is audio
> (distributed bands, etc), and there speed-of-light (and
> speed-of-interfaces) are what trip you up generally.  There are video
> equivalents (coordinated remote dance, etc) - but you still have to
> solve the capture and display problems, and compression per se isn't the
> major problem (no new tech is needed, just correct use of current
> tech/codecs I think).
> 
> Brings to mind "Racing the beam".... ;-)
> 
>>>
>>> So I'm ignorant of what webrtc can do is there a codec selection (yuv?
>>> 48 bit audio? for the rawest video and audio possible?)
>>>
>>>
>>> In theory, what you're looking for is this:
>>> http://tools.ietf.org/html/rfc4175
>> Thank you!
>>
>>> However, the caveats in that document are pretty huge:
>>>
>>>     It is important to note that uncompressed video can have immense
>>>     bandwidth requirements (up to 270 Mbps for standard-definition
>>> video,
>>>     and approximately 1 Gbps for high-definition video).  This is
>>>     sufficient to cause potential for denial-of-service if transmitted
>>>     onto most currently available Internet paths.
>>>
>>>
>>> Given the risk of Destroying The Internet Forever[tm] if any major
>>> browser
>>> vendor implemented this, I don't expect you'll see much deployment
>>> any time
>>> soon.
>> I don't see people doing videoconferences in the same qty as we do,
>> say, torrents (famous last words!). Certainly the panopticon might
>> take over the internet (but in that case delays from encoding should
>> be acceptable to our new robotic panoptic overloads, it's just the
>> pesky humans that have trouble with latency)
>>
>> So, maybe running at rates like this would trouble the "Internet" a
>> bit now, but on internal networks, not so much.
>>
>> 270Mbits is a trivial amount of bandwidth for a modern switched
>> network. Homes and businesses that are wired are probably close to
>> universally switched GigE, so internal conversations could possibly
>> run at max speed and minimal latency.
>>
>> Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
>> above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.
>>
>> Removing a serious delay-inducing-encoding step makes things like echo
>> cancellation unneeded, and live lola-like-collaboration possible.
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From jdrosen@cisco.com  Wed Oct 30 05:28:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F0011E8147 for ; Wed, 30 Oct 2013 05:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRqIyR9UHnAH for ; Wed, 30 Oct 2013 05:28:51 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 80FBD11E80FA for ; Wed, 30 Oct 2013 05:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5608; q=dns/txt; s=iport; t=1383136131; x=1384345731; h=from:to:cc:subject:date:message-id:mime-version; bh=Mnenfux7wos5YbX4DzoRZwA+To3TUNlhk/GMEE2dbU4=; b=L9BGOOwg0ky+11hzPXorwH4WUhOn6/v3c7OoqSSTSd754FAxpc5fqZ4x P/qDMRmN84+yiLKMKxE2/lqakUR5BDjZRpomhjBMC8F+xdABjG3E6cfwv 3/KEfd/g5Wz53KfDwscxdGipFEBfJB0xODZJs2qK1wxbRhYhyyMjE17U8 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am4GAHj6cFKtJXHB/2dsb2JhbABZgkNEOFS/TYEmFm0HgicBBC1MEgEqViYBBA4FCAyHc7p9jx4xEIMWgQ0DqhODJoIq
X-IronPort-AV: E=Sophos;i="4.93,600,1378857600";  d="scan'208,217";a="278526412"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 30 Oct 2013 12:28:51 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9UCSol0001164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 12:28:50 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.33]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 07:28:50 -0500
From: "Jonathan Rosenberg (jdrosen)" 
To: "rtcweb@ietf.org" 
Thread-Topic: Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: Ac7Va44Tmf9gXRoQT1qWOAYOe51tPQ==
Date: Wed, 30 Oct 2013 12:28:50 +0000
Message-ID: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.255.238]
Content-Type: multipart/alternative; boundary="_000_186CE8D65BA3A741A81A543F936DD0D10A5803D8xmbrcdx07ciscoc_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 30 Oct 2013 05:37:40 -0700
Subject: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 12:28:56 -0000

--_000_186CE8D65BA3A741A81A543F936DD0D10A5803D8xmbrcdx07ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'd like to make an announcement material to the conversations around MTI v=
ideo codecs in rtcweb.

Cisco is announcing today that we will take our H.264 implementation, and o=
pen source it under BSD license terms. Development and maintenance will be =
overseen by a board from industry and the open source community.  Furthermo=
re, we will provide a binary form suitable for inclusion in applications ac=
ross a number of different operating systems (Windows, MacOS, Linux x86, Li=
nux ARM and Android ARM), and make this binary module available for downloa=
d from the Internet. We will not pass on our MPEG-LA licensing costs for th=
is module, and based on the current licensing environment, this will effect=
ively make H.264 free for use on supported platforms.

We believe that this contribution to the community can help address the con=
cerns many have raised around selection of H.264 as MTI. I firmly believe t=
hat with H.264 we can achieve maximal interoperability and now, do it with =
open source and for free (well, at least for others - its not free for Cisc=
o :))
More information on the open source project can be found at http://www.open=
h264.org, which is sparse now but more coming soon.


Thx,
Jonathan R.

--
Jonathan Rosenberg, PhD
VP, CTO Collaboration
Cisco Systems
jdrosen@cisco.com


--_000_186CE8D65BA3A741A81A543F936DD0D10A5803D8xmbrcdx07ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I’d like to make an announcement material to t=
he conversations around MTI video codecs in rtcweb.


 


Cisco is announcing today that we will take our H.26=
4 implementation, and open source it under BSD license terms. Development a=
nd maintenance will be overseen by a board from industry and the open sourc=
e community.  Furthermore, we will
 provide a binary form suitable for inclusion in applications across a numb=
er of different operating systems (Windows, MacOS, Linux x86, Linux ARM and=
 Android ARM), and make this binary module available for download from the =
Internet. We will not pass on our
 MPEG-LA licensing costs for this module, and based on the current licensin=
g environment, this will effectively make H.264 free for use on supported p=
latforms.



 


We believe that this contribution to the community c=
an help address the concerns many have raised around selection of H.264 as =
MTI. I firmly believe that with H.264 we can achieve maximal interoperabili=
ty and now, do it with open source
 and for free (well, at least for others – its not free for Cisco 
J)


More information on the open source project can be f=
ound at 
http://www.openh264.org, which is sparse now but more coming soon.=



 


 


Thx,


Jonathan R.


 


--


Jonathan Rosenberg, PhD


VP, CTO Collaboration


Cisco Systems


jdrosen@cisco.com


 






--_000_186CE8D65BA3A741A81A543F936DD0D10A5803D8xmbrcdx07ciscoc_--

From karl.stahl@intertex.se  Wed Oct 30 06:21:25 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E421E80F0 for ; Wed, 30 Oct 2013 06:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.97
X-Spam-Level: 
X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=-0.680,  BAYES_20=-0.74, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syNOgl2TkM24 for ; Wed, 30 Oct 2013 06:21:20 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A421E80F1 for ; Wed, 30 Oct 2013 06:20:50 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310301420475700; Wed, 30 Oct 2013 14:20:47 +0100
From: "Karl Stahl" 
To: "'Jonathan Rosenberg \(jdrosen\)'" , 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>
In-Reply-To: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>
Date: Wed, 30 Oct 2013 14:20:47 +0100
Message-ID: <079901ced572$d87be7b0$8973b710$@stahl@intertex.se>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_079A_01CED57B.3A404FB0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7Va44Tmf9gXRoQT1qWOAYOe51tPQABrV+Q
Content-Language: sv
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 13:21:25 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_079A_01CED57B.3A404FB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for this surprise!=20

=20

Hope that it will result in that we can keep codecs in the endpoints and =
can
avoid video transcoding in gateways.

=20

/Karl

=20

=20

=20

=20

=20

=20

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Jonathan
Rosenberg (jdrosen)
Skickat: den 30 oktober 2013 13:29
Till: rtcweb@ietf.org
=C4mne: [rtcweb] Cisco to open source its H.264 implementation and =
absorb
MPEG-LA licensing fees

=20

I=92d like to make an announcement material to the conversations around =
MTI
video codecs in rtcweb.

=20

Cisco is announcing today that we will take our H.264 implementation, =
and
open source it under BSD license terms. Development and maintenance will =
be
overseen by a board from industry and the open source community.
Furthermore, we will provide a binary form suitable for inclusion in
applications across a number of different operating systems (Windows, =
MacOS,
Linux x86, Linux ARM and Android ARM), and make this binary module =
available
for download from the Internet. We will not pass on our MPEG-LA =
licensing
costs for this module, and based on the current licensing environment, =
this
will effectively make H.264 free for use on supported platforms.=20

=20

We believe that this contribution to the community can help address the
concerns many have raised around selection of H.264 as MTI. I firmly =
believe
that with H.264 we can achieve maximal interoperability and now, do it =
with
open source and for free (well, at least for others =96 its not free for =
Cisco
J)

More information on the open source project can be found at
http://www.openh264.org, which is sparse now but more coming soon.

=20

=20

Thx,

Jonathan R.

=20

--

Jonathan Rosenberg, PhD

VP, CTO Collaboration

Cisco Systems

jdrosen@cisco.com

=20


------=_NextPart_000_079A_01CED57B.3A404FB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Th=
anks for this surprise! 
 
Ho=
pe that it will result in that we can keep codecs in the endpoints and =
can avoid video transcoding in gateways.
 
/K=
arl
 
 
 
 
 
 
Fr=E5n: =
rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r =
Jonathan Rosenberg (jdrosen)
Skickat: den 30 oktober 2013 =
13:29
Till: rtcweb@ietf.org
=C4mne: [rtcweb] Cisco =
to open source its H.264 implementation and absorb MPEG-LA licensing =
fees
 
I’d like to make an announcement material to the =
conversations around MTI video codecs in rtcweb.
 
Cisco is announcing today that we =
will take our H.264 implementation, and open source it under BSD license =
terms. Development and maintenance will be overseen by a board from =
industry and the open source community.  Furthermore, we will =
provide a binary form suitable for inclusion in applications across a =
number of different operating systems (Windows, MacOS, Linux x86, Linux =
ARM and Android ARM), and make this binary module available for download =
from the Internet. We will not pass on our MPEG-LA licensing costs for =
this module, and based on the current licensing environment, this will =
effectively make H.264 free for use on supported platforms. =

 
We believe that this contribution to the community can help =
address the concerns many have raised around selection of H.264 as MTI. =
I firmly believe that with H.264 we can achieve maximal interoperability =
and now, do it with open source and for free (well, at least for others =
– its not free for Cisco J)
More information on the open source project can be found at =
http://www.openh264.org, which =
is sparse now but more coming soon.
 
 
Thx,
Jonathan R.
 
--
Jonathan Rosenberg, =
PhD
VP, CTO =
Collaboration
Cisco Systems
jdrosen@cisco.com=

 

------=_NextPart_000_079A_01CED57B.3A404FB0--


From lgeyser@gmail.com  Wed Oct 30 06:43:26 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB44F21F9E36 for ; Wed, 30 Oct 2013 06:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5Nacpaqy3JX for ; Wed, 30 Oct 2013 06:43:25 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49A21F9928 for ; Wed, 30 Oct 2013 06:43:24 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id z5so1204762lbh.7 for ; Wed, 30 Oct 2013 06:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z6Bx7tUjTkJg20tDXu7lyzEHtfEtd2M+9TJ7Lovivg0=; b=y2EwR12qCR/62ak3OCkX9rKTjXCD9E2ryahqXtzASCPBEHqwQZCQ54/flQmoM39YjB uPI8RMk0R/iKE+z9Z/ZMtIP6ST3RMT8itTsnQzU6YC4wLf1StpQBRSI6CIkfwkEqw41c XLEEhGvWGJIL8txw993TrjMFPiPLWA50bWknGLeZJVMQsv8eDsjDytG+jRK5sbpsaDIW LJlH2VcnuqVKWcKF/TRCuPI+pNJnUkh+SzdI8Gry1CGog0mSZm/i9mBYUWaeM8+yfa9f sl1Obe8ynE4mwufmVINVmMIXm5P5/VKV25mlmjVpSn6kx5s5MYFSMVjuodh9rtAfFCw9 MuOA==
MIME-Version: 1.0
X-Received: by 10.112.168.170 with SMTP id zx10mr3574757lbb.0.1383140603311; Wed, 30 Oct 2013 06:43:23 -0700 (PDT)
Received: by 10.114.168.70 with HTTP; Wed, 30 Oct 2013 06:43:23 -0700 (PDT)
In-Reply-To: <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>
Date: Wed, 30 Oct 2013 15:43:23 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c23c8855bc0a04e9f5840d
Cc: "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 13:43:26 -0000

--001a11c23c8855bc0a04e9f5840d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Great news.

I see this in the Q/A:
*Q. iOS is noticeably absent from the list of platforms. Why is that?*
A: Unfortunately, iOS does not allow for applications to fetch and install
modules from the Internet once that application has been installed on the
device. Consequently, it is simply not feasible for us to provide a
distribution at this time.
--
Does the same apply to other platforms like Windows Phone 7/8, Windows RT?
Also if we want to use the module on a different platform not listed by you
and that allow fetch+install can we ask for the module to be compiled?


On 30 October 2013 15:20, Karl Stahl  wrote:

> Thanks for this surprise! ****
>
> ** **
>
> Hope that it will result in that we can keep codecs in the endpoints and
> can avoid video transcoding in gateways.****
>
> ** **
>
> /Karl****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *Fr=E5n:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *F=F6r=
 *Jonathan
> Rosenberg (jdrosen)
> *Skickat:* den 30 oktober 2013 13:29
> *Till:* rtcweb@ietf.org
> *=C4mne:* [rtcweb] Cisco to open source its H.264 implementation and abso=
rb
> MPEG-LA licensing fees****
>
> ** **
>
> I=92d like to make an announcement material to the conversations around M=
TI
> video codecs in rtcweb.****
>
> ** **
>
> Cisco is announcing today that we will take our H.264 implementation, and
> open source it under BSD license terms. Development and maintenance will =
be
> overseen by a board from industry and the open source community.
> Furthermore, we will provide a binary form suitable for inclusion in
> applications across a number of different operating systems (Windows,
> MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module
> available for download from the Internet. We will not pass on our MPEG-LA
> licensing costs for this module, and based on the current licensing
> environment, this will effectively make H.264 free for use on supported
> platforms. ****
>
> ** **
>
> We believe that this contribution to the community can help address the
> concerns many have raised around selection of H.264 as MTI. I firmly
> believe that with H.264 we can achieve maximal interoperability and now, =
do
> it with open source and for free (well, at least for others =96 its not f=
ree
> for Cisco J)****
>
> More information on the open source project can be found at
> http://www.openh264.org, which is sparse now but more coming soon.****
>
> ** **
>
> ** **
>
> Thx,****
>
> Jonathan R.****
>
> ** **
>
> --****
>
> Jonathan Rosenberg, PhD****
>
> VP, CTO Collaboration****
>
> Cisco Systems****
>
> jdrosen@cisco.com****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c23c8855bc0a04e9f5840d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Great news.

I see this in the Q/A:
Q. iOS is noticeably absent from the list of platforms. Why is that?

            A: Unfortunately, iOS does not allow for applications to=20
fetch and install modules from the Internet once that application has=20
been installed on the device. Consequently, it is simply not feasible=20
for us to provide a distribution at this time. 
--
Does the sam=
e apply to other platforms like Windows Phone 7/8, Windows RT?
Als=
o if we want to use the module on a different platform not listed by you an=
d that allow fetch+install can we ask for the module to be compiled?




On 30 O=
ctober 2013 15:20, Karl Stahl <karl.stahl@intertex.se> =
wrote:




Thanks for this surprise! <=
/u>


=A0
Ho=
pe that it will result in that we can keep codecs in the endpoints and can =
avoid video transcoding in gateways.


=A0
/K=
arl


=A0
=A0


=A0
=A0


<=
u>=A0


=A0
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] <=
b>F=F6r Jonathan Rosenberg (jdrosen)

Skickat: den 30 oktober 2013 13:29
Till: rtcweb@ietf.org
=C4mne: [=
rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA li=
censing fees


=A0
I=92d like to make an announcement material to the conversations around MT=
I video codecs in rtcweb.


=A0
Cisco is announcing today that we =
will take our H.264 implementation, and open source it under BSD license te=
rms. Development and maintenance will be overseen by a board from industry =
and the open source community.=A0 Furthermore, we will provide a binary for=
m suitable for inclusion in applications across a number of different opera=
ting systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and ma=
ke this binary module available for download from the Internet. We will not=
 pass on our MPEG-LA licensing costs for this module, and based on the curr=
ent licensing environment, this will effectively make H.264 free for use on=
 supported platforms. 


=A0
We believe that this contribution =
to the community can help address the concerns many have raised around sele=
ction of H.264 as MTI. I firmly believe that with H.264 we can achieve maxi=
mal interoperability and now, do it with open source and for free (well, at=
 least for others =96 its not free for Cisco J)<=
/span>


More information on the open so=
urce project can be found at http://www.openh264.org, which is sparse now but more coming so=
on.


=A0
=A0
Thx,

Jonathan R.
=A0
--
Jonathan Rosenberg, PhD


VP, CTO Collaboration=

Cisco Systems=

jdrosen@cisco.com


=A0

_______________________________________________
rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11c23c8855bc0a04e9f5840d--

From vsingh.ietf@gmail.com  Wed Oct 30 06:49:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8DE11E8167; Wed, 30 Oct 2013 06:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hghbUF61OJsO; Wed, 30 Oct 2013 06:49:54 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 092AD11E8174; Wed, 30 Oct 2013 06:49:53 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id e14so2252811iej.22 for ; Wed, 30 Oct 2013 06:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3wDQGBZXwBfou3hv2wsrPfdt81Bq5W/6wzhuIiqh0HA=; b=WsMNyZokkQJgTRQfcapxVwWUXPOZQcnOugCBsYsNo8Gktunxgx2jEw9CDnkQNF+a7F ND8olXhALot9piOGjJWdQN67zuNqjFceMwBqqU5EvKmwK/Z4dS/5ALSO/TNikh0T2ru4 joQpw5fwescwLx5j2erpLg/lZK/APbk9uIoAHg38sbX/Oy4FRY6CQ//UiqAyQsBiKSYn 8x2s3LonK3aS/l3Ybl8+LdNQEAD3ubynltuZsruj/3QoE/8s2S18msA5YhyWXDi2xRM/ q0djlqhMrRvgkGvtKRjAP9crH+kTI+GnE5iZUP8DHJwSucaNu0eQXMk9QoiQ2lDwsNMD zXPg==
X-Received: by 10.50.77.72 with SMTP id q8mr2534284igw.14.1383140993330; Wed, 30 Oct 2013 06:49:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.102.8 with HTTP; Wed, 30 Oct 2013 06:49:33 -0700 (PDT)
In-Reply-To: 
References: 
From: Varun Singh 
Date: Wed, 30 Oct 2013 15:49:33 +0200
Message-ID: 
To: "rtcweb@ietf.org" , "avt@ietf.org" , rmcat WG 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Colin Perkins 
Subject: Re: [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 13:49:56 -0000

Hi all,

Practical details for the meeting on **RMCAT Traffic models**

Date: 03.11. 2013
Time: 12:30 to 14:30.
Assigned Room: Regency A

Cheers,
Varun

On Sun, Oct 27, 2013 at 12:57 PM, Varun Singh  wrote:
> Hi all,
>
> In RMCAT WG there has been discussion surrounding the use
> of a media traffic generator and to facilitate discussion,
> RMCAT is hosting a side meeting on Sunday, 03 November
> at 1300-1500. I suppose the room details will be announced
> shortly.
>
> Below is a list of questions that will help design or choose
> an appropriate traffic generator for Interactive multimedia traffic.
> The list is an initial set and mainly to foster discussion both
> on the mailing list and at the meeting.
>
> Mirja and Lars are not available that day, hence on their behalf,
> the meeting is hosted by Colin and I .
>
> Cheers,
> Varun
> ---
>
> Traffic generator: to model the intrinsic variability of video:
>
> - what target bit rates can be achieved? (max?, min?)
> - how much variability in media bit rate for a given target bit rate
> - how to model motion? capturing high motion leads to bursty video
>   (higher than target bit rate), but by how much? can this even be done?
>
> Traffic generator: on responsiveness to a new target bitrate:
>
> - how quickly can the codec generate a lower bit rate?
> - immediately? does this depend on the new or requested bit rate?
> - what is immediately? is it next frame or a few frames later, until then
>   does it generates at the current rate?
> - if not immediately, what bitrates (and duration) will it generate before
>   meeting the target bitrate.
>
>
> - how quickly can the codec generate a higher bit rate?
> - immediately in the next frame? does this also depend on the new
>    or requested bit rate?
> - not immediately but in steps of intermediate bitrates, i.e., intermediate
>   bitrate for a short duration then an increase in step, repeating until
>   reaching the target bit rate.
>
> - If the target bit rate is achieved in steps, can they be announced to the
>   congestion controller, i.e., the congestion controller knows the ramp up
>   curve to meet the target bit rate.
>
> - If the media bit rate has not yet reached the requested target bit rate and
>   the congestion control requests a new target bit rate, how does the codec
>   respond?
>
> Application design related:
> - should the congestion control be able to change the frame rate (video) or
>   packetization time (audio) or is this something that the application controls.
> - should the congestion control be able to change video resolution?
> - should error-repair: NACKs, FEC be considered part of congestion control or
>   outside it, i.e., it is something that the application does and not
>   congestion control
> - If FEC is controlled by the congestion control, how quickly can the sending
>   rate be adapted by reducing/adding redundancy (FEC)? is something link this
>   done? Does this makes sense at all?
> - Apart from loss and RTT, what other congestion cues are currently used by
>   congestion control algorithms? e.g., Decoding rate/goodput, application
>   decode error rate, ECN, PCN, etc.
> - If the codec is data limited, i.e., producing a sending rate smaller than the
>   one calculated by the congestion control, can the congestion control probe
>   the bandwidth by sending additional data packets in a certain pattern (e.g.,
>   PathChirp)? would somehting link this help?
> - application input on prioritization: audio vs video (vs data)
>
>
>
>
>
> --
> http://www.netlab.tkk.fi/~varun/



-- 
http://www.netlab.tkk.fi/~varun/

From jdrosen@jdrosen.net  Wed Oct 30 07:08:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21B711E8222 for ; Wed, 30 Oct 2013 07:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.376
X-Spam-Level: 
X-Spam-Status: No, score=-101.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WN67fbDHRm5 for ; Wed, 30 Oct 2013 07:08:39 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD921F9F40 for ; Wed, 30 Oct 2013 07:08:38 -0700 (PDT)
Received: from mail-pa0-f45.google.com ([209.85.220.45]:65412) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VbWRS-0000VW-96 for rtcweb@ietf.org; Wed, 30 Oct 2013 10:08:14 -0400
Received: by mail-pa0-f45.google.com with SMTP id kp14so992864pab.32 for ; Wed, 30 Oct 2013 07:08:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9jL/sNuQ0Y52GlsD6AlOukePzEaDDbcwoiZyb8W+nOg=; b=dMIHRT45EJnKH3h3rgVvAVTYrA7yKb1FxAVfTf5CoCHajFA5A6mnoljF+zEaZX1CSr btD5qa8GKuPPJ98X25YziE4/NUDCf5yYJUjLikUvy+Ue1nsYLBLF4vmI+Ge/xRa6RglT 9HaRyTZUFTaSnj08CqHMViB6zCskvzbJT+sH9X/L09EKuqQ10GOzWbX3QWhmd/dVMCxG c3/gVHy+bzpKyscYZjYIufTs3axD3bRam87O3hHRfp3KIsOXP9p++bSi+6MhS5YIgusr dD+A97MyRM6YEYYhWX+Z8bSP0syCX71i7pIE2CL9z6+U+xB2ZgQiQ6fUM41u8m/gqW3M DAzg==
MIME-Version: 1.0
X-Received: by 10.68.40.169 with SMTP id y9mr1930887pbk.193.1383142093958; Wed, 30 Oct 2013 07:08:13 -0700 (PDT)
Received: by 10.70.49.48 with HTTP; Wed, 30 Oct 2013 07:08:13 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com> 
Date: Wed, 30 Oct 2013 10:08:13 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Leon Geyser 
Content-Type: multipart/alternative; boundary=bcaec51a75462f38f404e9f5dd4e
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
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 14:08:44 -0000

--bcaec51a75462f38f404e9f5dd4e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

One of the reasons we're open sourcing it is so that interested parties
could build the module for other platforms. So, yes. If the platform allows
for fetch+install the community can build for that and Cisco will not pass
on any MPEG-LA licensing costs for applications on that platform.

I believe neither WinRT nor Winphone 7/8 allow for apps to fetch/install so
that the fetch+install model won't work there.


On Wed, Oct 30, 2013 at 9:43 AM, Leon Geyser  wrote:

> Great news.
>
> I see this in the Q/A:
> *Q. iOS is noticeably absent from the list of platforms. Why is that?*
> A: Unfortunately, iOS does not allow for applications to fetch and instal=
l
> modules from the Internet once that application has been installed on the
> device. Consequently, it is simply not feasible for us to provide a
> distribution at this time.
> --
> Does the same apply to other platforms like Windows Phone 7/8, Windows RT=
?
> Also if we want to use the module on a different platform not listed by
> you and that allow fetch+install can we ask for the module to be compiled=
?
>
>
> On 30 October 2013 15:20, Karl Stahl  wrote:
>
>> Thanks for this surprise! ****
>>
>> ** **
>>
>> Hope that it will result in that we can keep codecs in the endpoints and
>> can avoid video transcoding in gateways.****
>>
>> ** **
>>
>> /Karl****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *Fr=E5n:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *F=F6=
r *Jonathan
>> Rosenberg (jdrosen)
>>
>> *Skickat:* den 30 oktober 2013 13:29
>> *Till:* rtcweb@ietf.org
>> *=C4mne:* [rtcweb] Cisco to open source its H.264 implementation and
>> absorb MPEG-LA licensing fees****
>>
>> ** **
>>
>> I=92d like to make an announcement material to the conversations around =
MTI
>> video codecs in rtcweb.****
>>
>> ** **
>>
>> Cisco is announcing today that we will take our H.264 implementation, an=
d
>> open source it under BSD license terms. Development and maintenance will=
 be
>> overseen by a board from industry and the open source community.
>> Furthermore, we will provide a binary form suitable for inclusion in
>> applications across a number of different operating systems (Windows,
>> MacOS, Linux x86, Linux ARM and Android ARM), and make this binary modul=
e
>> available for download from the Internet. We will not pass on our MPEG-L=
A
>> licensing costs for this module, and based on the current licensing
>> environment, this will effectively make H.264 free for use on supported
>> platforms. ****
>>
>> ** **
>>
>> We believe that this contribution to the community can help address the
>> concerns many have raised around selection of H.264 as MTI. I firmly
>> believe that with H.264 we can achieve maximal interoperability and now,=
 do
>> it with open source and for free (well, at least for others =96 its not =
free
>> for Cisco J)****
>>
>> More information on the open source project can be found at
>> http://www.openh264.org, which is sparse now but more coming soon.****
>>
>> ** **
>>
>> ** **
>>
>> Thx,****
>>
>> Jonathan R.****
>>
>> ** **
>>
>> --****
>>
>> Jonathan Rosenberg, PhD****
>>
>> VP, CTO Collaboration****
>>
>> Cisco Systems****
>>
>> jdrosen@cisco.com****
>>
>> ** **
>>
>> _______________________________________________
>> 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
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--bcaec51a75462f38f404e9f5dd4e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


One of the reasons we're open sourcing it is so that i=
nterested parties could build the module for other platforms. So, yes. If t=
he platform allows for fetch+install the community can build for that and C=
isco will not pass on any MPEG-LA licensing costs for applications on that =
platform.


I believe neither WinRT nor Winphone 7/8 allow for apps to f=
etch/install so that the fetch+install model won't work there.


On Wed, Oc=
t 30, 2013 at 9:43 AM, Leon Geyser <lgeyser@gmail.com> wrote=
:


Great news.
I see this in the Q/A:
Q. iOS is noticeably absent from the li=
st of platforms. Why is that?


            A: Unfortunately, iOS does not allow for applications to=20
fetch and install modules from the Internet once that application has=20
been installed on the device. Consequently, it is simply not feasible=20
for us to provide a distribution at this time. 
--
Does the sam=
e apply to other platforms like Windows Phone 7/8, Windows RT?
Als=
o if we want to use the module on a different platform not listed by you an=
d that allow fetch+install can we ask for the module to be compiled?





On 30 October 2013 15:20, Karl Stahl <karl.stahl@intertex.=
se> wrote:





Thanks for this sur=
prise! 



=A0
Ho=
pe that it will result in that we can keep codecs in the endpoints and can =
avoid video transcoding in gateways.



=A0
/K=
arl



=A0
=A0



=A0
=A0



=A0



=A0
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] <=
b>F=F6r Jonathan Rosenberg (jdrosen)




Skickat: den 30 oktober 2013 13:29
Till: rtcweb@ietf.org
=C4mne:=
 [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG=
-LA licensing fees




=A0
I=92d like to make an announcement material to the conversations=
 around MTI video codecs in rtcweb.



=A0
Cisco is announcing today that we =
will take our H.264 implementation, and open source it under BSD license te=
rms. Development and maintenance will be overseen by a board from industry =
and the open source community.=A0 Furthermore, we will provide a binary for=
m suitable for inclusion in applications across a number of different opera=
ting systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and ma=
ke this binary module available for download from the Internet. We will not=
 pass on our MPEG-LA licensing costs for this module, and based on the curr=
ent licensing environment, this will effectively make H.264 free for use on=
 supported platforms. 



=A0
We believe that this contribution =
to the community can help address the concerns many have raised around sele=
ction of H.264 as MTI. I firmly believe that with H.264 we can achieve maxi=
mal interoperability and now, do it with open source and for free (well, at=
 least for others =96 its not free for Cisco J)<=
/span>



More information on the open so=
urce project can be found at http://www.openh264.org, which is sparse now but more coming so=
on.



=A0
=A0
Thx,


Jonathan R.
=A0
--
Jonathan Rosenberg, PhD



VP, CTO Collaboration=

Cisco Systems=

jdrosen@cisco.com



=A0

____________________=
___________________________

rtcweb mailing list

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





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





-- 





--bcaec51a75462f38f404e9f5dd4e--

From creslin@digium.com  Wed Oct 30 08:09:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287B811E832C for ; Wed, 30 Oct 2013 08:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Level: 
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltLGjCPaV4WV for ; Wed, 30 Oct 2013 08:09:20 -0700 (PDT)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9611E8335 for ; Wed, 30 Oct 2013 08:08:52 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id eh20so1170097lab.25 for ; Wed, 30 Oct 2013 08:08:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uP8Fgt5+WNrxvosMzwt1/jXVUKONhJkc4qRjFcrAvMw=; b=mN69b6oTGAOHUK6sOdpT/yi4PjlXSVKNGMowvoujk0OY+iiOQzi0L0Y6yPSen1f3yu 6kxSelbZw/7Pi6/cNXBJ/KkCqOPKz14eYA8TheZlMAC4+9Vlneed+lXioYTtL6UdeG8L xjMlV8FCkyCoY7WGPeL/3o1EGSvFASHbxhxXt8WZw8ZQgJ0U7dViDU0HNbyT5CMw8LDZ E9Ve/fMf3kD5w425qKvBtqsMlre9paFUWialzzMlg4y70vYpg3Kd3FR6genEYz62SmxY kTR1euUL5he7+/DsuGuskAQFrenTmpx85hz+HcztGqMm4JooxZAy/ihU9BvewSR0XzFA kmnQ==
X-Gm-Message-State: ALoCoQmX2WvKMbjbKoyykSqV/teslsGtGAOoN841bnkTFF0L7TZQ35V/M/ndzToGMmwFhyRpzIOh
MIME-Version: 1.0
X-Received: by 10.152.45.42 with SMTP id j10mr3566302lam.15.1383145728510; Wed, 30 Oct 2013 08:08:48 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 08:08:48 -0700 (PDT)
In-Reply-To: 
References:  <52700D33.30102@nostrum.com> 
Date: Wed, 30 Oct 2013 10:08:48 -0500
Message-ID: 
From: Matt Fredrickson 
To: Dave Taht 
Content-Type: multipart/alternative; boundary=001a11c29f56d21d3904e9f6b589
Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] compressed codec-free webrtc?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:09:24 -0000

--001a11c29f56d21d3904e9f6b589
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Oct 29, 2013 at 3:00 PM, Dave Taht  wrote:

> On Tue, Oct 29, 2013 at 12:32 PM, Adam Roach  wrote:
> > On 10/29/13 13:33, Dave Taht wrote:
> >
> > In having my eyes glaze over at the codec debate I found myself
> > wondering to what extent anyone was pursuing truly low latency video
> > and audio, along the lines of what the lola project has been doing for
> > collaborative concerts.
> >
> > See:
> >
> > http://www.conts.it/artistica/lola-project
> >
> > They ship raw audio and raw video, they actually use cameras where
> > they can get at scanlines and ship that (saving 16ms)
> >
> > So I'm ignorant of what webrtc can do is there a codec selection (yuv?
> > 48 bit audio? for the rawest video and audio possible?)
> >
> >
> > In theory, what you're looking for is this:
> > http://tools.ietf.org/html/rfc4175
>
> Thank you!
>
> > However, the caveats in that document are pretty huge:
> >
> >    It is important to note that uncompressed video can have immense
> >    bandwidth requirements (up to 270 Mbps for standard-definition video,
> >    and approximately 1 Gbps for high-definition video).  This is
> >    sufficient to cause potential for denial-of-service if transmitted
> >    onto most currently available Internet paths.
> >
> >
> > Given the risk of Destroying The Internet Forever[tm] if any major
> browser
> > vendor implemented this, I don't expect you'll see much deployment any
> time
> > soon.
>
> I don't see people doing videoconferences in the same qty as we do,
> say, torrents (famous last words!). Certainly the panopticon might
> take over the internet (but in that case delays from encoding should
> be acceptable to our new robotic panoptic overloads, it's just the
> pesky humans that have trouble with latency)
>
> So, maybe running at rates like this would trouble the "Internet" a
> bit now, but on internal networks, not so much.
>
> 270Mbits is a trivial amount of bandwidth for a modern switched
> network. Homes and businesses that are wired are probably close to
> universally switched GigE, so internal conversations could possibly
> run at max speed and minimal latency.
>
> Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well
> above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.
>
> Removing a serious delay-inducing-encoding step makes things like echo
> cancellation unneeded, and live lola-like-collaboration possible.
>

Echo cancellation will probably still be needed.  Audio as exposed to
userspace in the operating system is usually not low enough latency to
remove the need to do echo cancellation.  Packetization also induces delays
in the audio/video stack the necessitate echo cancellation.

Matthew Fredrickson

--001a11c29f56d21d3904e9f6b589
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On T=
ue, Oct 29, 2013 at 3:00 PM, Dave Taht <dave.taht@gmail.com> wrote:


On Tue, Oct 29, 2013 at 12=
:32 PM, Adam Roach <adam@nostrum.com=
> wrote:


> On 10/29/13 13:33, Dave Taht wrote:

>

> In having my eyes glaze over at the codec debate I found myself

> wondering to what extent anyone was pursuing truly low latency video
> and audio, along the lines of what the lola project has been doing for=


> collaborative concerts.

>

> See:

>

> http://www.conts.it/artistica/lola-project

>

> They ship raw audio and raw video, they actually use cameras where

> they can get at scanlines and ship that (saving 16ms)

>

> So I'm ignorant of what webrtc can do is there a codec selection (=
yuv?

> 48 bit audio? for the rawest video and audio possible?)

>

>

> In theory, what you're looking for is this:

> http:=
//tools.ietf.org/html/rfc4175




Thank you!




> However, the caveats in that document are pretty huge:

>

> =A0 =A0It is important to note that uncompressed video can have immens=
e

> =A0 =A0bandwidth requirements (up to 270 Mbps for standard-definition =
video,

> =A0 =A0and approximately 1 Gbps for high-definition video). =A0This is=


> =A0 =A0sufficient to cause potential for denial-of-service if transmit=
ted

> =A0 =A0onto most currently available Internet paths.

>

>

> Given the risk of Destroying The Internet Forever[tm] if any major bro=
wser

> vendor implemented this, I don't expect you'll see much deploy=
ment any time

> soon.




I don't see people doing videoconferences in the same qty as we d=
o,

say, torrents (famous last words!). Certainly the panopticon might

take over the internet (but in that case delays from encoding should

be acceptable to our new robotic panoptic overloads, it's just the

pesky humans that have trouble with latency)



So, maybe running at rates like this would trouble the "Internet"=
 a

bit now, but on internal networks, not so much.



270Mbits is a trivial amount of bandwidth for a modern switched

network. Homes and businesses that are wired are probably close to

universally switched GigE, so internal conversations could possibly

run at max speed and minimal latency.



Internet-wise, Gfiber delivers GigE, upcoming docsis standards go well

above 200Mbit, 802.11ac goes past a gig, 802.11ad goes to 7gig.



Removing a serious delay-inducing-encoding step makes things like echo

cancellation unneeded, and live lola-like-collaboration possible.

Echo cancellation will probably still be needed.=
 =A0Audio as exposed to userspace in the operating system is usually not lo=
w enough latency to remove the need to do echo cancellation. =A0Packetizati=
on also induces delays in the audio/video stack the necessitate echo cancel=
lation.



Matthew Fredrickson



--001a11c29f56d21d3904e9f6b589--

From pthatcher@google.com  Wed Oct 30 08:15:57 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3904921E80FC for ; Wed, 30 Oct 2013 08:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUUNp6wGznSk for ; Wed, 30 Oct 2013 08:15:56 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id CD90411E8296 for ; Wed, 30 Oct 2013 08:14:39 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id ld10so1078082pab.38 for ; Wed, 30 Oct 2013 08:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LPq9eJXjMAN/7MR4lmp9lY/jKxSTA4iBYEC6VlUbE3A=; b=cGS4+ok2L+CfTi++rA798QrR1/5sAaMxm9lOJHc8ypsGapp9TPGitxjmOOA2yw/Zk7 oW8XczdUc/gFhd4JI0EMd+fjMm5/8qso/FQz9bIFanQPuE35K2qqtLF5vvJy8ji7Qptk 1gVRDcrE5K/nC3PhNL9YECrbiZZREeS1J+yt0cgjm+ZxeFxLaXULyBA67YreQyQ6AbBN iULRLeR9CdIESHsnqOvfbrIXN1sTePUq/sCOD21BWCnkffQ9pPmu9OOIi5aaU2A5hLBX 59/pqHTbGiskfoxCerXAg97PXz6NInI8XlcxkClgzt8UJVQhDqtRnUgw1vcvZnb8Irvs vEMA==
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=LPq9eJXjMAN/7MR4lmp9lY/jKxSTA4iBYEC6VlUbE3A=; b=W1I8S/BRwESt/cT56dKNQQmb5BqQjHNc/okXm5tjkPm8b9K8G3hxzY8f6KXILcOBHS ex6fa+d2ce/qetZsq6E1nsXTFyCTYthVX1iF9nOnLRFuG6nXNwSA8/iq7iDKD9iSv941 fH5MiRJiqqHqd+QRAEpANwu5pes6aH/8iSUxBx4Co0AApQ+OMhcHx5gtvnhqpGWQSIP+ 6NT7H0eCHdWjPOsMxcsrp56KCNZ96H4fL+SWsbwfeVf7IsfbpSEmAlu1rNwRmfcXestN A8Jiavg2AOPIhkUTbprAGC5xYUgbXmsIpagXOlCcVmWUhsnF/qsj0QHblR079cNiq54h TlHQ==
X-Gm-Message-State: ALoCoQmcsCy1POTpCb+4pANjw2Dg9KQEEImLvk+Lfxwzg2gg5FWkXVEGQ8538MlqvsPATgUSgWn3sKijAnJceeqKGfOrlBOgHVDKyQTvfuSwEEpk4M0O7/oOM683p3ZfHk63RAt4pRexVUErzJGqK9J4MeBEPXX4eekahClj/TMql87zBspG8ogOcfMPLHeM4CGc1rkPg5R8
X-Received: by 10.68.101.225 with SMTP id fj1mr5817365pbb.8.1383146078537; Wed, 30 Oct 2013 08:14:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.163.234 with HTTP; Wed, 30 Oct 2013 08:13:56 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>  
From: Peter Thatcher 
Date: Wed, 30 Oct 2013 08:13:56 -0700
Message-ID: 
To: Jonathan Rosenberg 
Content-Type: multipart/alternative; boundary=047d7b673288af40c904e9f6ca97
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:15:57 -0000

--047d7b673288af40c904e9f6ca97
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 30, 2013 at 7:08 AM, Jonathan Rosenberg wr=
ote:

> One of the reasons we're open sourcing it is so that interested parties
> could build the module for other platforms. So, yes. If the platform allo=
ws
> for fetch+install the community can build for that and Cisco will not pas=
s
> on any MPEG-LA licensing costs for applications on that platform.
>

You keep using the phrase "Cisco will not pass on any MPEG-LA licensing
costs for applications" in a careful way, which I'm sure you have to for
legal reasons, but it does leave some of us wondering what it really means.

As a specific example, what about a Linux distribution?   I think it's
clear that  Debian, for example, cannot make this source code part of their
distribution because of the patent implications.  Are you suggesting that a
linux distribution could take the Cisco source code, compile their own
binary module, and host it on Cisco servers as a way to distribute h264
functionality that avoids the need to pay the MPEG-LA?  You seem to be
implying that, but not outright saying it.


I believe neither WinRT nor Winphone 7/8 allow for apps to fetch/install so
> that the fetch+install model won't work there.
>
>
> On Wed, Oct 30, 2013 at 9:43 AM, Leon Geyser  wrote:
>
>> Great news.
>>
>> I see this in the Q/A:
>> *Q. iOS is noticeably absent from the list of platforms. Why is that?*
>> A: Unfortunately, iOS does not allow for applications to fetch and
>> install modules from the Internet once that application has been install=
ed
>> on the device. Consequently, it is simply not feasible for us to provide=
 a
>> distribution at this time.
>> --
>> Does the same apply to other platforms like Windows Phone 7/8, Windows R=
T?
>> Also if we want to use the module on a different platform not listed by
>> you and that allow fetch+install can we ask for the module to be compile=
d?
>>
>>
>> On 30 October 2013 15:20, Karl Stahl  wrote:
>>
>>> Thanks for this surprise! ****
>>>
>>> ** **
>>>
>>> Hope that it will result in that we can keep codecs in the endpoints an=
d
>>> can avoid video transcoding in gateways.****
>>>
>>> ** **
>>>
>>> /Karl****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *Fr=C3=A5n:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *=
F=C3=B6r *Jonathan
>>> Rosenberg (jdrosen)
>>>
>>> *Skickat:* den 30 oktober 2013 13:29
>>> *Till:* rtcweb@ietf.org
>>> *=C3=84mne:* [rtcweb] Cisco to open source its H.264 implementation and
>>> absorb MPEG-LA licensing fees****
>>>
>>>  ** **
>>>
>>> I=E2=80=99d like to make an announcement material to the conversations =
around
>>> MTI video codecs in rtcweb.****
>>>
>>> ** **
>>>
>>> Cisco is announcing today that we will take our H.264 implementation,
>>> and open source it under BSD license terms. Development and maintenance
>>> will be overseen by a board from industry and the open source community=
.
>>> Furthermore, we will provide a binary form suitable for inclusion in
>>> applications across a number of different operating systems (Windows,
>>> MacOS, Linux x86, Linux ARM and Android ARM), and make this binary modu=
le
>>> available for download from the Internet. We will not pass on our MPEG-=
LA
>>> licensing costs for this module, and based on the current licensing
>>> environment, this will effectively make H.264 free for use on supported
>>> platforms. ****
>>>
>>> ** **
>>>
>>> We believe that this contribution to the community can help address the
>>> concerns many have raised around selection of H.264 as MTI. I firmly
>>> believe that with H.264 we can achieve maximal interoperability and now=
, do
>>> it with open source and for free (well, at least for others =E2=80=93 i=
ts not free
>>> for Cisco J)****
>>>
>>> More information on the open source project can be found at
>>> http://www.openh264.org, which is sparse now but more coming soon.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Thx,****
>>>
>>> Jonathan R.****
>>>
>>> ** **
>>>
>>> --****
>>>
>>> Jonathan Rosenberg, PhD****
>>>
>>> VP, CTO Collaboration****
>>>
>>> Cisco Systems****
>>>
>>> jdrosen@cisco.com****
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--047d7b673288af40c904e9f6ca97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Oct 30, 2013 at 7:08 AM, Jonathan Rosenberg <jdrosen@jdr=
osen.net> wrote:



One of the reasons we're open sourcin=
g it is so that interested parties could build the module for other platfor=
ms. So, yes. If the platform allows for fetch+install the community can bui=
ld for that and Cisco will not pass on any MPEG-LA licensing costs for appl=
ications on that platform.




You keep using the phrase "Cisco will=
 not pass on any MPEG-LA licensing costs for applications" in a carefu=
l way, which I'm sure you have to for legal reasons, but it does leave =
some of us wondering what it really means.




As a specific example, what about a Linux distribution?=
 =C2=A0 I think it's clear that =C2=A0Debian, for example, cannot make =
this source code part of their distribution because of the patent implicati=
ons. =C2=A0Are you suggesting that a linux distribution could take the Cisc=
o source code, compile their own binary module, and host it on Cisco server=
s as a way to distribute h264 functionality that avoids the need to pay the=
 MPEG-LA? =C2=A0You seem to be implying that, but not outright saying it. =
=C2=A0





I beli=
eve neither WinRT nor Winphone 7/8 allow for apps to fetch/install so that =
the fetch+install model won't work there.





On Wed, Oct 30, 2013 at 9:43 AM, Leon Geyser <lgeyser@gma=
il.com> wrote:




Great news.

I see this i=
n the Q/A:


Q. iOS is noticeably absent from the list of platforms. Why is that=
?


            A: Unfortunately, iOS does not allow for applications to=20
fetch and install modules from the Internet once that application has=20
been installed on the device. Consequently, it is simply not feasible=20
for us to provide a distribution at this time. 
--
Does the sam=
e apply to other platforms like Windows Phone 7/8, Windows RT?
Als=
o if we want to use the module on a different platform not listed by you an=
d that allow fetch+install can we ask for the module to be compiled?







On=
 30 October 2013 15:20, Karl Stahl <karl.stahl@intertex.se> wrote:







Thanks for this surprise! 



=C2=A0
Hope that it will result in that we can keep code=
cs in the endpoints and can avoid video transcoding in gateways.<=
/u>





=C2=A0
/Karl





=C2=A0
=C2=A0





=C2=A0
=C2=A0





=C2=A0





=C2=A0
Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Jonathan Rosenberg (jdrosen)



=C3=84m=
ne: [rtcweb] Cisco to open source its H.264 implementation and absorb M=
PEG-LA licensing fees






=C2=A0
I=E2=80=99d like to make an announcement material to the conversations aro=
und MTI video codecs in rtcweb.





=C2=A0
=

Cisco is announcing today that =
we will take our H.264 implementation, and open source it under BSD license=
 terms. Development and maintenance will be overseen by a board from indust=
ry and the open source community.=C2=A0 Furthermore, we will provide a bina=
ry form suitable for inclusion in applications across a number of different=
 operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), =
and make this binary module available for download from the Internet. We wi=
ll not pass on our MPEG-LA licensing costs for this module, and based on th=
e current licensing environment, this will effectively make H.264 free for =
use on supported platforms. 





=C2=A0
=

We believe that this contributi=
on to the community can help address the concerns many have raised around s=
election of H.264 as MTI. I firmly believe that with H.264 we can achieve m=
aximal interoperability and now, do it with open source and for free (well,=
 at least for others =E2=80=93 its not free for Cisco J)





More information on the open so=
urce project can be found at http://www.openh264.org, which is sparse now but more coming so=
on.





=C2=A0
=

=C2=A0
=

Thx,




Jonathan R.
=C2=A0
--
Jonathan Rosenberg, PhD





VP, CTO Collaboration=

Cisco Systems=

jdrosen@cisco.com





=C2=A0
=


______________________________=
_________________

rtcweb mailing list

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





_______________________________________________

rtcweb mailing list

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





-- 





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7b673288af40c904e9f6ca97--

From creslin@digium.com  Wed Oct 30 08:20:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C9D11E8266 for ; Wed, 30 Oct 2013 08:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzZnmHMO19ki for ; Wed, 30 Oct 2013 08:20:35 -0700 (PDT)
Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6873111E8294 for ; Wed, 30 Oct 2013 08:20:19 -0700 (PDT)
Received: by mail-la0-f41.google.com with SMTP id el20so1214168lab.14 for ; Wed, 30 Oct 2013 08:20:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=64IT9I2zjJNe+18ffHIpRoOmsOAjQTbaa3a+AGe+gJs=; b=Wm96ZDh+9J4SDpoenj3vyZ70lAsNdRUbfv7IAtak+F1GMHCeLVbtSftHKIEI5/I8tw HdjZa9ilJzdRHed/NpW9juI4pTyjYBDmsjS8fukBrmM/IGc/G58ZuY1sge7WvQhq8kTv 5/rX3wDG41E0kEyGbU8iX0n4PZCs25/eqYx0u4Kv/zGukx2HTIwAwGzKHN9A2XIfMXGb GKUw1veHz/tC5QGbitOPWeZ6v2NAbVVM+e59/nPBdmfGAEaQE96T8VD9wbALRaWKnp7Y xU/yhXgQVevZejPPYsIOq2TEyGJ0UuFjOS1O0ROLRW5oSWpfFKBikJ5J88mbNOX2VXwN UvpQ==
X-Gm-Message-State: ALoCoQm6s4JcaLHl2o4PNMhX7doM4fR5KmeuRwecWSo+4xxVEUC6kjqP7JKsRg+1gGkglTs2zdD+
MIME-Version: 1.0
X-Received: by 10.112.164.38 with SMTP id yn6mr280126lbb.61.1383146418201; Wed, 30 Oct 2013 08:20:18 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 08:20:18 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>  
Date: Wed, 30 Oct 2013 10:20:18 -0500
Message-ID: 
From: Matt Fredrickson 
To: Jonathan Rosenberg 
Content-Type: multipart/alternative; boundary=001a11c259aeedf94104e9f6de9e
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:20:39 -0000

--001a11c259aeedf94104e9f6de9e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Does this mean that system information (for systems that this is installed
on) may be tracked and sent back to the Cisco servers for accurate license
usage count?  (ethernet MAC address, or some other system specific info) so
that redownloads of modules on the same system are not counted towards your
license usage accounting?

Matthew Fredrickson


On Wed, Oct 30, 2013 at 9:08 AM, Jonathan Rosenberg wr=
ote:

> One of the reasons we're open sourcing it is so that interested parties
> could build the module for other platforms. So, yes. If the platform allo=
ws
> for fetch+install the community can build for that and Cisco will not pas=
s
> on any MPEG-LA licensing costs for applications on that platform.
>
> I believe neither WinRT nor Winphone 7/8 allow for apps to fetch/install
> so that the fetch+install model won't work there.
>
>
> On Wed, Oct 30, 2013 at 9:43 AM, Leon Geyser  wrote:
>
>> Great news.
>>
>> I see this in the Q/A:
>> *Q. iOS is noticeably absent from the list of platforms. Why is that?*
>> A: Unfortunately, iOS does not allow for applications to fetch and
>> install modules from the Internet once that application has been install=
ed
>> on the device. Consequently, it is simply not feasible for us to provide=
 a
>> distribution at this time.
>> --
>> Does the same apply to other platforms like Windows Phone 7/8, Windows R=
T?
>> Also if we want to use the module on a different platform not listed by
>> you and that allow fetch+install can we ask for the module to be compile=
d?
>>
>>
>> On 30 October 2013 15:20, Karl Stahl  wrote:
>>
>>> Thanks for this surprise! ****
>>>
>>> ** **
>>>
>>> Hope that it will result in that we can keep codecs in the endpoints an=
d
>>> can avoid video transcoding in gateways.****
>>>
>>> ** **
>>>
>>> /Karl****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *Fr=E5n:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *F=
=F6r *Jonathan
>>> Rosenberg (jdrosen)
>>>
>>> *Skickat:* den 30 oktober 2013 13:29
>>> *Till:* rtcweb@ietf.org
>>> *=C4mne:* [rtcweb] Cisco to open source its H.264 implementation and
>>> absorb MPEG-LA licensing fees****
>>>
>>>  ** **
>>>
>>> I=92d like to make an announcement material to the conversations around
>>> MTI video codecs in rtcweb.****
>>>
>>> ** **
>>>
>>> Cisco is announcing today that we will take our H.264 implementation,
>>> and open source it under BSD license terms. Development and maintenance
>>> will be overseen by a board from industry and the open source community=
.
>>> Furthermore, we will provide a binary form suitable for inclusion in
>>> applications across a number of different operating systems (Windows,
>>> MacOS, Linux x86, Linux ARM and Android ARM), and make this binary modu=
le
>>> available for download from the Internet. We will not pass on our MPEG-=
LA
>>> licensing costs for this module, and based on the current licensing
>>> environment, this will effectively make H.264 free for use on supported
>>> platforms. ****
>>>
>>> ** **
>>>
>>> We believe that this contribution to the community can help address the
>>> concerns many have raised around selection of H.264 as MTI. I firmly
>>> believe that with H.264 we can achieve maximal interoperability and now=
, do
>>> it with open source and for free (well, at least for others =96 its not=
 free
>>> for Cisco J)****
>>>
>>> More information on the open source project can be found at
>>> http://www.openh264.org, which is sparse now but more coming soon.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Thx,****
>>>
>>> Jonathan R.****
>>>
>>> ** **
>>>
>>> --****
>>>
>>> Jonathan Rosenberg, PhD****
>>>
>>> VP, CTO Collaboration****
>>>
>>> Cisco Systems****
>>>
>>> jdrosen@cisco.com****
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c259aeedf94104e9f6de9e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Does this mean that system information (for systems that t=
his is installed on) may be tracked and sent back to the Cisco servers for =
accurate license usage count? =A0(ethernet MAC address, or some other syste=
m specific info) so that redownloads of modules on the same system are not =
counted towards your license usage accounting?


Matthew Fredrickson

On Wed, Oct 30, 2013 at 9:08 AM, Jonathan =
Rosenberg <jdrosen@jdrosen.net> wrote:


One of the reasons we'r=
e open sourcing it is so that interested parties could build the module for=
 other platforms. So, yes. If the platform allows for fetch+install the com=
munity can build for that and Cisco will not pass on any MPEG-LA licensing =
costs for applications on that platform.



I believe neither WinRT nor Winphone 7/8 allow for apps to f=
etch/install so that the fetch+install model won't work there.



On Wed, Oct 30, 2013 at 9:43 AM, Leon Geyser <lgeyser@gmail.com> wrote:


Great news.
I see this in the Q/A:
Q. iOS is noticeably absent from the li=
st of platforms. Why is that?



            A: Unfortunately, iOS does not allow for applications to=20
fetch and install modules from the Internet once that application has=20
been installed on the device. Consequently, it is simply not feasible=20
for us to provide a distribution at this time. 
--
Does the sam=
e apply to other platforms like Windows Phone 7/8, Windows RT?
Als=
o if we want to use the module on a different platform not listed by you an=
d that allow fetch+install can we ask for the module to be compiled?






On=
 30 October 2013 15:20, Karl Stahl <karl.stahl@intertex.se> wrote:






Thanks for this surprise! 




=A0
Ho=
pe that it will result in that we can keep codecs in the endpoints and can =
avoid video transcoding in gateways.




=A0
/K=
arl




=A0
=A0




=A0
=A0




=A0




=A0
Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] <=
b>F=F6r Jonathan Rosenberg (jdrosen)





Skickat: den 30 oktober 2013 13:29
Till: rtcweb@ietf.org
=C4mne:=
 [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG=
-LA licensing fees





=A0
I=
=92d like to make an announcement material to the conversations around MTI =
video codecs in rtcweb.




=A0
Cisco is announcing today that we =
will take our H.264 implementation, and open source it under BSD license te=
rms. Development and maintenance will be overseen by a board from industry =
and the open source community.=A0 Furthermore, we will provide a binary for=
m suitable for inclusion in applications across a number of different opera=
ting systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and ma=
ke this binary module available for download from the Internet. We will not=
 pass on our MPEG-LA licensing costs for this module, and based on the curr=
ent licensing environment, this will effectively make H.264 free for use on=
 supported platforms. 




=A0
We believe that this contribution =
to the community can help address the concerns many have raised around sele=
ction of H.264 as MTI. I firmly believe that with H.264 we can achieve maxi=
mal interoperability and now, do it with open source and for free (well, at=
 least for others =96 its not free for Cisco J)<=
/span>




More information on the open so=
urce project can be found at http://www.openh264.org, which is sparse now but more coming so=
on.




=A0
=A0
Thx,



Jonathan R.
=A0
--
Jonathan Rosenberg, PhD




VP, CTO Collaboration=

Cisco Systems=

jdrosen@cisco.com




=A0

_________________________________=
______________

rtcweb mailing list

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





_______________________________________________

rtcweb mailing list

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





-- 





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11c259aeedf94104e9f6de9e--

From mail@makk.es  Wed Oct 30 08:34:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4C311E8253 for ; Wed, 30 Oct 2013 08:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au+tDAT5d1az for ; Wed, 30 Oct 2013 08:34:44 -0700 (PDT)
Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id B107511E81D6 for ; Wed, 30 Oct 2013 08:34:43 -0700 (PDT)
Received: (qmail 12318 invoked from network); 30 Oct 2013 15:34:41 -0000
Received: from unknown (HELO ?141.22.28.178?) (141.22.28.178) by lupus.uberspace.de with SMTP; 30 Oct 2013 15:34:41 -0000
Message-ID: <5271270C.4000605@makk.es>
Date: Wed, 30 Oct 2013 16:34:36 +0100
From: Max Jonas Werner 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Matt Fredrickson ,  Paul Kyzivat 
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com>	<03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com>			<03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com>	<120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de>	<03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>	<5269F3B5.2020308@alvestrand.no>	<03FBA798AC24E3498B74F47FD082A92F3D86CD4C@US70UWXCHMBA04.zam.alcatel-lucent.com>	<526C4297.2000006@alum.mit.edu> <526CE0BE.90606@jesup.org>	<526FD2D8.7000709@alum.mit.edu> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KdEIvemPdTt4PBlmQgClWfcWdvD8RuwBK"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:34:53 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--KdEIvemPdTt4PBlmQgClWfcWdvD8RuwBK
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 29.10.2013 16:35, Matt Fredrickson wrote:
> On Tue, Oct 29, 2013 at 10:23 AM, Paul Kyzivat w=
rote:
[...]

>> Is it not possible for an intermediary on the signaling path to insert=

>> itself in the media path, manipulating the SDP such that the two ends =
both
>> establish the DTLS with the intermediary?
>=20
> Correct me if I'm wrong, but I thought that the SDP itself was supposed=
 to
> be signed and able to be validated (perhaps using the identity mechanis=
m),
> to explicitly catch nefarious man in the middle type scenarios such as =
this.

Remove the "perhaps" from the sentence in brackets and you got it. If
you want to verify you're communicating with whom you think you're
comunicating you _need_ the identity mechanism that's being standardized
here.

Max


--KdEIvemPdTt4PBlmQgClWfcWdvD8RuwBK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFScScO1IVn4/X13N8RAiUVAJ4jzO20DVcOrUrCy+pNOK8vuJDJuwCdFgnC
ERKsTZ6VF6+EcAhTF2JrvW8=
=DOwD
-----END PGP SIGNATURE-----

--KdEIvemPdTt4PBlmQgClWfcWdvD8RuwBK--

From adam@nostrum.com  Wed Oct 30 08:37:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB221E8120 for ; Wed, 30 Oct 2013 08:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.437
X-Spam-Level: 
X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9UfA4DbOLR7 for ; Wed, 30 Oct 2013 08:37:22 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6987521E8117 for ; Wed, 30 Oct 2013 08:37:12 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9UFb6tV020669 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 10:37:07 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5271279D.5090406@nostrum.com>
Date: Wed, 30 Oct 2013 10:37:01 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Peter Thatcher , Jonathan Rosenberg 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>	<527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>		 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:37:22 -0000

On 10/30/13 10:13, Peter Thatcher wrote:
> As a specific example, what about a Linux distribution?   I think it's 
> clear that  Debian, for example, cannot make this source code part of 
> their distribution because of the patent implications.  Are you 
> suggesting that a linux distribution could take the Cisco source code, 
> compile their own binary module, and host it on Cisco servers as a way 
> to distribute h264 functionality that avoids the need to pay the MPEG-LA?

I think you're looking for the third, fourth, and fifth questions on 
this page: http://www.openh264.org/faq.html

/a

From adam@nostrum.com  Wed Oct 30 08:41:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BC121E80FC for ; Wed, 30 Oct 2013 08:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level: 
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvvG7ur0wClM for ; Wed, 30 Oct 2013 08:41:39 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E502821E80B6 for ; Wed, 30 Oct 2013 08:41:36 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9UFfWLZ020849 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 10:41:32 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <527128A7.3050101@nostrum.com>
Date: Wed, 30 Oct 2013 10:41:27 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Matt Fredrickson , Jonathan Rosenberg 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>	<527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>		 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:41:39 -0000

On 10/30/13 10:20, Matt Fredrickson wrote:
> Does this mean that system information (for systems that this is 
> installed on) may be tracked and sent back to the Cisco servers for 
> accurate license usage count?  (ethernet MAC address, or some other 
> system specific info) so that redownloads of modules on the same 
> system are not counted towards your license usage accounting?

My understanding is that MPEG-LA has a per-organization royalty cap for 
H.264 (13 MUSD, if my memory serves), and that Cisco reaches that cap 
quite easily with their own products.

/a

From ted.ietf@gmail.com  Wed Oct 30 08:45:38 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF3811E82BC for ; Wed, 30 Oct 2013 08:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9uCOAh4zE7a for ; Wed, 30 Oct 2013 08:45:36 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3F11E8267 for ; Wed, 30 Oct 2013 08:44:34 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id tp5so2604443ieb.31 for ; Wed, 30 Oct 2013 08:44:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fU0Milal1XGFIv+kBA4lba4UjXqlUrKIf+1o8rHB30w=; b=WRujN3iumhnEK07xltuGmQ45I2mqJaNld7Ns2lBNcLlPZyG/orC4SFeIzPwVJOAfkJ LnJrqiy22JGC6CgljxcUvAKqtx9iJZgok+WbXb0ev9TXeYLNRSLaqJtcpul4kThU465U VES4oyuN63EAx81LcjzRM4V9NEdJid41l7VecYbjBpyhOayggIJ9fWrjQCza0RZJoNo4 yN5+sWYSXZIZbV175ofPjeNpF5121WWU6k87aqLIuVxrpT2UY+r3uZcn4RngshD8Kv5n /+qZ/NRkdRdDZRdjqc3zZj9hrOETRSAJYCAuIikqEcz3cHqrWfp4ncjRT4/s/TgN1VUB 2+Ew==
MIME-Version: 1.0
X-Received: by 10.50.130.46 with SMTP id ob14mr2965024igb.22.1383147848678; Wed, 30 Oct 2013 08:44:08 -0700 (PDT)
Received: by 10.43.115.72 with HTTP; Wed, 30 Oct 2013 08:44:08 -0700 (PDT)
In-Reply-To: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>
Date: Wed, 30 Oct 2013 08:44:08 -0700
Message-ID: 
From: Ted Hardie 
To: "Jonathan Rosenberg (jdrosen)" 
Content-Type: multipart/alternative; boundary=047d7b418bb33144f604e9f7349b
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:45:38 -0000

--047d7b418bb33144f604e9f7349b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Dr. Rosenberg, it's always good to have your contributions.

Thanks for today's announcement; I have a couple of questions.

In March, Cullen announced that Cisco would open source an H.264
implementation if the working group selected H.264 as the MTI.  I assume
that today's announcement is a follow-on to that intention, removing the
requirement for H.264 to be the MTI for this generous gift, since there is
no similar requirement in your statement.  Is that correct?  This will
remain available even in the case some other codec is selected as MTI?

The web site and your announcement say H.264, without naming specific
profiles.  Will the details of which will be included come when the source
code is available?  Do you have a timeline for when the source code might
become available?  Since the board will also name supported platforms, can
you give a timeline for when they might be disclosed?

The current announcement describes this as a single donation, but my read
is that it is really two, in that someone may *either* have the source code
under BSD license term* or* they may have the downloadable module with
Cisco paying the MPEG-LA license fees, but that these offers cannot be
combined.  This is based on my reading of this question and answer:

*Q. Why is Cisco making both source and binary versions available?*
A: The source code is available so that an implementation of H.264 is
available for the community to use across any project, and to leverage the
community to make the codec better for all. We will select licensing terms
that allow for this code to be used in commercial products as well as open
source projects. In order for Cisco to be responsible for the MPEG LA
licensing royalties for the module, Cisco must provide the packaging and
distribution of this code in a binary module format (think of it like a
plug-in, but not using the same APIs as existing plugins), in addition to
several other constraints. This gives the community the best of all worlds
- a team can choose to use the source code, in which case the team is
responsible for paying all applicable license fees, or the team can use the
binary module distributed by Cisco, in which case Cisco will cover the MPEG
LA licensing fees.

Can you confirm that understanding?  If so, I have to note that I find the
phrase "best of all worlds" a bit hyperbolic--a technology license that
applied to all implementations would seem a bit better.  This may, of
course, be the best of all worlds available to H.264.  I also note, by the
way, that your announcement says BSD license, but this Q & A discuss this
as if the licensing terms were still undefined.  Can you confirm that the
license is BSD and update the FAQ?

I also read it to say that Cisco will not indemnify users of either the
source code or module against other patent holder's assertions of license,
based on this question and answer:

*Q: Is Cisco guaranteeing that it will pay other licensing fees for H.264,
should additional patent holders assert claims in the future?
*A: Cisco is providing no such guarantee. We are only covering the
royalties that would apply to the binary module under MPEG LA's AVC/H.264
patent pool.

This seems quite clear to me, but I would appreciate your confirming it on
the list.

Many thanks again for your contribution,

regards,

Ted Hardie


On Wed, Oct 30, 2013 at 5:28 AM, Jonathan Rosenberg (jdrosen) <
jdrosen@cisco.com> wrote:

>  I=92d like to make an announcement material to the conversations around
> MTI video codecs in rtcweb.****
>
> ** **
>
> Cisco is announcing today that we will take our H.264 implementation, and
> open source it under BSD license terms. Development and maintenance will =
be
> overseen by a board from industry and the open source community.
> Furthermore, we will provide a binary form suitable for inclusion in
> applications across a number of different operating systems (Windows,
> MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module
> available for download from the Internet. We will not pass on our MPEG-LA
> licensing costs for this module, and based on the current licensing
> environment, this will effectively make H.264 free for use on supported
> platforms. ****
>
> ** **
>
> We believe that this contribution to the community can help address the
> concerns many have raised around selection of H.264 as MTI. I firmly
> believe that with H.264 we can achieve maximal interoperability and now, =
do
> it with open source and for free (well, at least for others =96 its not f=
ree
> for Cisco J)****
>
> More information on the open source project can be found at
> http://www.openh264.org, which is sparse now but more coming soon.****
>
> ** **
>
> ** **
>
> Thx,****
>
> Jonathan R.****
>
> ** **
>
> --****
>
> Jonathan Rosenberg, PhD****
>
> VP, CTO Collaboration****
>
> Cisco Systems****
>
> jdrosen@cisco.com****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--047d7b418bb33144f604e9f7349b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Dr. Rosenberg, it's always good to have your cont=
ributions.=A0 

Thanks for today's announcement; I have a couple =
of questions.

In March, Cullen announced that Cisco would=
 open source an H.264 implementation if the working group selected H.264 as=
 the MTI.=A0 I assume that today's announcement is a follow-on to that =
intention, removing the requirement for H.264 to be the MTI for this genero=
us gift, since there is no similar requirement in your statement.=A0 Is tha=
t correct?=A0 This will remain available even in the case some other codec =
is selected as MTI?


The web site and your announcement say H.264, without naming specific p=
rofiles.=A0 Will the details of which will be included come when the source=
 code is available?=A0 Do you have a timeline for when the source code migh=
t become available?=A0 Since the board will also name supported platforms, =
can you give a timeline for when they might be disclosed?


The current announcement describes this as a single donation=
, but my read is that it is really two, in that someone may either h=
ave the source code under BSD license term or they may have the down=
loadable module with Cisco paying the MPEG-LA license fees, but that these =
offers cannot be combined.=A0 This is based on my reading of this question =
and answer:


Q. Why is Cisco making both source a=
nd binary versions available?

            A: The source code is available so that an implementation of
 H.264 is available for the community to use across any project, and to=20
leverage the community to make the codec better for all. We will select=20
licensing terms that allow for this code to be used in commercial=20
products as well as open source projects. In order for Cisco to be=20
responsible for the MPEG LA licensing royalties for the module, Cisco=20
must provide the packaging and distribution of this code in a binary=20
module format (think of it like a plug-in, but not using the same APIs=20
as existing plugins), in addition to several other constraints. This=20
gives the community the best of all worlds - a team can choose to use=20
the source code, in which case the team is responsible for paying all=20
applicable license fees, or the team can use the binary module=20
distributed by Cisco, in which case Cisco will cover the MPEG LA=20
licensing fees. 

Can you confirm that understanding?=A0 If so,=
 I have to note that I find the phrase "best of all worlds" a bit=
 hyperbolic--a technology license that applied to all implementations would=
 seem a bit better.=A0 This may, of course, be the best of all worlds avail=
able to H.264.=A0 I also note, by the way, that your announcement says BSD =
license, but this Q & A discuss this as if the licensing terms were sti=
ll undefined.=A0 Can you confirm that the license is BSD and update the FAQ=
?



I also read it to say that Cisco will not indemni=
fy users of either the source code or module against other patent holder=
9;s assertions of license, based on this question and answer:

Q: =
Is Cisco guaranteeing that it will pay other licensing fees=20
for H.264, should additional patent holders assert claims in the future?
  =20
            A: Cisco is providing no such guarantee.  We are=20
only covering the royalties that would apply to the binary module under=20
MPEG LA's AVC/H.264 patent pool.

This seems quite cle=
ar to me, but I would appreciate your confirming it on the list.

Man=
y thanks again for your contribution,

regards,

Ted Hardie




On Wed,=
 Oct 30, 2013 at 5:28 AM, Jonathan Rosenberg (jdrosen) &l=
t;jdrosen@cisco.com<=
/a>> wrote:













I=92d like to make an announcement material to the c=
onversations around MTI video codecs in rtcweb.


=A0


Cisco is announcing today that we will take our H.26=
4 implementation, and open source it under BSD license terms. Development a=
nd maintenance will be overseen by a board from industry and the open sourc=
e community.=A0 Furthermore, we will
 provide a binary form suitable for inclusion in applications across a numb=
er of different operating systems (Windows, MacOS, Linux x86, Linux ARM and=
 Android ARM), and make this binary module available for download from the =
Internet. We will not pass on our
 MPEG-LA licensing costs for this module, and based on the current licensin=
g environment, this will effectively make H.264 free for use on supported p=
latforms.



=A0


We believe that this contribution to the community c=
an help address the concerns many have raised around selection of H.264 as =
MTI. I firmly believe that with H.264 we can achieve maximal interoperabili=
ty and now, do it with open source
 and for free (well, at least for others =96 its not free for Cisco 
J)


More information on the open source project can be f=
ound at 
http://www.openh264.org, which is sparse now but more coming soon.


=A0


=A0


Thx,


Jonathan R.


=A0


--


Jonathan Rosenberg, PhD


VP, CTO Collaboration


Cisco Systems


jdrosen@cisco.com


=A0







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7b418bb33144f604e9f7349b--

From lorenzo@meetecho.com  Wed Oct 30 08:47:53 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1BE11E821C for ; Wed, 30 Oct 2013 08:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDWKidOqX2sT for ; Wed, 30 Oct 2013 08:47:49 -0700 (PDT)
Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id E0CA211E826E for ; Wed, 30 Oct 2013 08:47:20 -0700 (PDT)
Received: from lminiero ([143.225.229.175]) by smtpcmd03.ad.aruba.it with bizsmtp id jTnG1m00w3niPy701TnGSV; Wed, 30 Oct 2013 16:47:18 +0100
Date: Wed, 30 Oct 2013 16:47:16 +0100
From: Lorenzo Miniero 
To: Adam Roach 
Message-ID: <20131030164716.3d3be136@lminiero>
In-Reply-To: <527128A7.3050101@nostrum.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@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=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:47:54 -0000

Il giorno Wed, 30 Oct 2013 10:41:27 -0500
Adam Roach  ha scritto:

> On 10/30/13 10:20, Matt Fredrickson wrote:
> > Does this mean that system information (for systems that this is 
> > installed on) may be tracked and sent back to the Cisco servers for 
> > accurate license usage count?  (ethernet MAC address, or some other 
> > system specific info) so that redownloads of modules on the same 
> > system are not counted towards your license usage accounting?
> 
> My understanding is that MPEG-LA has a per-organization royalty cap
> for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> cap quite easily with their own products.
> 
> /a


Which doesn't preclude the fact the module may do tracking anyway.

Lorenzo


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


From creslin@digium.com  Wed Oct 30 08:49:10 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8167A21F9CAD for ; Wed, 30 Oct 2013 08:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.826
X-Spam-Level: 
X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt92ygzTbWSu for ; Wed, 30 Oct 2013 08:49:04 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD0D11E8173 for ; Wed, 30 Oct 2013 08:48:18 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id ep20so1278580lab.3 for ; Wed, 30 Oct 2013 08:48:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=abNDCypa0pbwmCp9oe6BopWwUFqsySlANK8yWzjAj5c=; b=GcP1kOucUD9WyJn+Bkrsr8V39Gd7cNHgLfSDYTbTZvGA1YQ24MQO+scFaKf861wJGi /5dO9sqOrjvYLm6POw7N2OaPYTdJeel+8ytn8grZsLxRjicbtlU7CiZ3GjQE+Lbl7WLU RIPytwZeL5zHFpoByHRvXfsMedhNq8MPocihD1YatiGHsXtqY8d7VFAsEtr3Cbna2O0t wWiNYmTJTvZaXcvGmqSA/ppbozJuJ38R4WVBcSfFbnsNBd2BVkgyntFiF11xNIKQjpWl cT25IdppwnVS4ZbX2ziBeth+KjVE9VdE8itm9YBHDBRS/U+yrk+a+dbsb3r7ylUh9w3A xPLQ==
X-Gm-Message-State: ALoCoQl/KNmZvq1RjlWcntCgmFz6Dc59u2sw1sdQkjs3PLhrFy5U2nb7sb14pf4QpMxPY4UoV3Ce
MIME-Version: 1.0
X-Received: by 10.112.167.3 with SMTP id zk3mr3834363lbb.23.1383148098016; Wed, 30 Oct 2013 08:48:18 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 08:48:17 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> 
Date: Wed, 30 Oct 2013 10:48:17 -0500
Message-ID: 
From: Matt Fredrickson 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=001a11c264a40de98504e9f74336
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:49:10 -0000

--001a11c264a40de98504e9f74336
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 30, 2013 at 10:44 AM, Ted Hardie  wrote:

> Dr. Rosenberg, it's always good to have your contributions.
>
> Thanks for today's announcement; I have a couple of questions.
>
> In March, Cullen announced that Cisco would open source an H.264
> implementation if the working group selected H.264 as the MTI.  I assume
> that today's announcement is a follow-on to that intention, removing the
> requirement for H.264 to be the MTI for this generous gift, since there is
> no similar requirement in your statement.  Is that correct?  This will
> remain available even in the case some other codec is selected as MTI?
>
> The web site and your announcement say H.264, without naming specific
> profiles.  Will the details of which will be included come when the source
> code is available?  Do you have a timeline for when the source code might
> become available?  Since the board will also name supported platforms, can
> you give a timeline for when they might be disclosed?
>

I think the FAQ said the baseline profile will be initially included.

Matthew Fredrickson

--001a11c264a40de98504e9f74336
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Wed, Oct 30, 2013 at 10:44 AM, Ted Hardie <=
ted.ietf@gmail.com<=
/a>> wrote:


Dr. Rosenberg, it'=
s always good to have your contributions.=A0 

Thanks for today's=
 announcement; I have a couple of questions.


In March, Cullen announced that Cisco would open source an H=
.264 implementation if the working group selected H.264 as the MTI.=A0 I as=
sume that today's announcement is a follow-on to that intention, removi=
ng the requirement for H.264 to be the MTI for this generous gift, since th=
ere is no similar requirement in your statement.=A0 Is that correct?=A0 Thi=
s will remain available even in the case some other codec is selected as MT=
I?



The web site and your announcement say H.264, without naming specific p=
rofiles.=A0 Will the details of which will be included come when the source=
 code is available?=A0 Do you have a timeline for when the source code migh=
t become available?=A0 Since the board will also name supported platforms, =
can you give a timeline for when they might be disclosed?



I think the FAQ said the basel=
ine profile will be initially included.

Matthew Fr=
edrickson
=A0


--001a11c264a40de98504e9f74336--

From adam@nostrum.com  Wed Oct 30 08:50:24 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BCE21F9E14 for ; Wed, 30 Oct 2013 08:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+thZtDgHqza for ; Wed, 30 Oct 2013 08:50:23 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD0BA11E8253 for ; Wed, 30 Oct 2013 08:50:10 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9UFo9Tg021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 30 Oct 2013 10:50:10 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52712AAE.10401@nostrum.com>
Date: Wed, 30 Oct 2013 10:50:06 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040809070703020604060509"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:50:24 -0000

This is a multi-part message in MIME format.
--------------040809070703020604060509
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/30/13 10:44, Ted Hardie wrote:
>
> The web site and your announcement say H.264, without naming specific 
> profiles.  Will the details of which will be included come when the 
> source code is available?

You seem to have found the FAQ, but not read all the way to the bottom:

*Q. Which profiles of H.264 will be supported?*
A: The initial code has the baseline profile. We look forward to working 
with the open source community to add high profile and others.


> Do you have a timeline for when the source code might become available?


Or the top:

*Q. When will the H.264 source code and binary module be available?*
A: Shortly, Cisco will form a governance board for the open source 
initiative, establish the project, and make the source code and binary 
module available for download. We will move quickly to carry out these 
steps, but past experience suggests that it will take a few months 
before the entire process is complete.

/a

--------------040809070703020604060509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/30/13 10:44, Ted Hardie wrote:

    

    

      


        
The web site and your announcement say H.264, without
          naming specific profiles.  Will the details of which will be
          included come when the source code is available?

      

    

    

    You seem to have found the FAQ, but not read all the way to the
    bottom:

    

    Q. Which profiles of H.264 will be supported?

    A: The initial code has the baseline profile. We look forward to
    working with the open source community to add high profile and
    others. 

    

    

    

      

        
 Do you have a timeline for when the source code might
          become available?

        

      

    

    

    

    Or the top:

    

    
    Q. When will the H.264 source code and binary module be
      available?

    A: Shortly, Cisco will form a governance board for the open source
    initiative, establish the project, and make the source code and
    binary module available for download. We will move quickly to carry
    out these steps, but past experience suggests that it will take a
    few months before the entire process is complete. 

    

    /a

  


--------------040809070703020604060509--

From ethanhugg@gmail.com  Wed Oct 30 08:52:17 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578521E811C for ; Wed, 30 Oct 2013 08:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkFziYAd-XUu for ; Wed, 30 Oct 2013 08:52:15 -0700 (PDT)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D038221E80F3 for ; Wed, 30 Oct 2013 08:52:12 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id db12so1111879veb.23 for ; Wed, 30 Oct 2013 08:52:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I9V2FgMOOwWmn9yX7mq+vWkn2jibTaGco8V3EgKc7LI=; b=Iy5BdokkQzBESf0NlSG7rMqzzmzOxSmXaW9CkN4wFiJcC6JRNOviTXmFL5F931qxUw zUZvHJm/e2wM7qH4yb+4CVcQJndLW/3YFbxCL9hck4g9vypmtQaDzv52WoPPo/ibPZCE 3wgxWc4QYgfCWyo16kSCc1YW7r2QYD4LTiH28IQvNP/hfporLNyFFc61UIzPZ0P4AUhC cl24VodyDBtOy3K3nr0MTcvlLdY/qWBDWcpjZecyuYJztKXIDuXONJUpbAeQlmuCEqlp F2P4ldPsPHkq9NpPrNjqvPOtb0ieK12ZC8kW66FROSZhOHQOE6a8sprpVD2R/sNVVbh7 rlYQ==
MIME-Version: 1.0
X-Received: by 10.220.173.65 with SMTP id o1mr196331vcz.46.1383148332211; Wed, 30 Oct 2013 08:52:12 -0700 (PDT)
Received: by 10.59.10.232 with HTTP; Wed, 30 Oct 2013 08:52:12 -0700 (PDT)
In-Reply-To: <20131030164716.3d3be136@lminiero>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>
Date: Wed, 30 Oct 2013 08:52:12 -0700
Message-ID: 
From: Ethan Hugg 
To: Lorenzo Miniero 
Content-Type: multipart/alternative; boundary=089e0115ea04036ea804e9f75128
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:52:17 -0000

--089e0115ea04036ea804e9f75128
Content-Type: text/plain; charset=ISO-8859-1

Lorenzo,

You will be able to inspect the source yourself for nefarious things like
tracking as the code will be freely available.

-EH



On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero wrote:

> Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> Adam Roach  ha scritto:
>
> > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > Does this mean that system information (for systems that this is
> > > installed on) may be tracked and sent back to the Cisco servers for
> > > accurate license usage count?  (ethernet MAC address, or some other
> > > system specific info) so that redownloads of modules on the same
> > > system are not counted towards your license usage accounting?
> >
> > My understanding is that MPEG-LA has a per-organization royalty cap
> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> > cap quite easily with their own products.
> >
> > /a
>
>
> Which doesn't preclude the fact the module may do tracking anyway.
>
> Lorenzo
>
>
> > _______________________________________________
> > 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
>

--089e0115ea04036ea804e9f75128
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Lorenzo,=A0

You will be =
able to inspect the source yourself for nefarious things like tracking as t=
he code will be freely available.

-EH




O=
n Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:


Il giorno Wed, 30 Oct 2013 10:41:27 -0500
Adam Roach <adam@nostrum.com>=
 ha scritto:




> On 10/30/13 10:20, Matt Fredrickson wrote:

> > Does this mean that system information (for systems that this is<=
br>
> > installed on) may be tracked and sent back to the Cisco servers f=
or

> > accurate license usage count? =A0(ethernet MAC address, or some o=
ther

> > system specific info) so that redownloads of modules on the same<=
br>
> > system are not counted towards your license usage accounting?

>

> My understanding is that MPEG-LA has a per-organization royalty cap
> for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that<=
br>
> cap quite easily with their own products.

>

> /a






Which doesn't preclude the fact the module may do tracking anyway=
.



Lorenzo






> _______________________________________________

> 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





--089e0115ea04036ea804e9f75128--

From xiphmont@gmail.com  Wed Oct 30 08:53:28 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E307411E8266 for ; Wed, 30 Oct 2013 08:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level: 
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[AWL=1.040,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPfOfOC+FYVg for ; Wed, 30 Oct 2013 08:53:28 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6A07B21F9E99 for ; Wed, 30 Oct 2013 08:53:13 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id eh20so1230105lab.25 for ; Wed, 30 Oct 2013 08:53:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L9ay22uZpc3yEv+4btSIlcSpvIjNJN8EysE75f6D1oY=; b=dNlFZ8oxeZVWen8tr8zTLcjjbL3ufadWlKTzl4oHSK18viQWSv8fIWNH6M+rSBXG2N qM5e+OVIs3PRpVeJEEmB7qnPMFjH+oWHMLhLZe4DMUTWfyW9rogfJrOfGA+7l/ZiQ8nR mX0xStr6X+7XRdeGCfUbvP9QoTZcFl54Q/+WawnV8vtb9x3c3jQijiDp5vT499jAXQQP lHWAcUz5YtbojFexGel/FCHEYw98AUJMzYMHb7mzJzvjePh61J2ZrUcwChlGFCP68H1h C7E1DTKcbFt7z4K2NjOKKuZRaeGNVlY3QPqZVkQzGhZhAx0adhGj0MuMLsL9jTlbE+8d hy+g==
MIME-Version: 1.0
X-Received: by 10.152.29.38 with SMTP id g6mr3675844lah.25.1383148392098; Wed, 30 Oct 2013 08:53:12 -0700 (PDT)
Received: by 10.112.11.48 with HTTP; Wed, 30 Oct 2013 08:53:12 -0700 (PDT)
In-Reply-To: <527128A7.3050101@nostrum.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com>
Date: Wed, 30 Oct 2013 11:53:12 -0400
Message-ID: 
From: Monty Montgomery 
To: Adam Roach 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:53:30 -0000

I have been informed by several people that the $13M cap mentioned in
my blog post is wrong.  The licensing math is different from the older
MPEG codecs, and the correct number is $65.M until 2015.  I corrected
my post to reflect this.

On Wed, Oct 30, 2013 at 11:41 AM, Adam Roach  wrote:
> On 10/30/13 10:20, Matt Fredrickson wrote:
>>
>> Does this mean that system information (for systems that this is installed
>> on) may be tracked and sent back to the Cisco servers for accurate license
>> usage count?  (ethernet MAC address, or some other system specific info) so
>> that redownloads of modules on the same system are not counted towards your
>> license usage accounting?
>
>
> My understanding is that MPEG-LA has a per-organization royalty cap for
> H.264 (13 MUSD, if my memory serves), and that Cisco reaches that cap quite
> easily with their own products.
>
> /a
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From xiphmont@gmail.com  Wed Oct 30 08:54:56 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0EB21F9D7D for ; Wed, 30 Oct 2013 08:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.693,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvuGZBd-7z3G for ; Wed, 30 Oct 2013 08:54:56 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7815B11E81DB for ; Wed, 30 Oct 2013 08:54:50 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id ec20so1286253lab.9 for ; Wed, 30 Oct 2013 08:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zNx9jKYAj4xfhhdCM3x4gNBJCRa0bMSZYMyzhMqFQms=; b=IuK/iIeaIw9Fox8ejothj7kXLzqek6r2F2DHXCpnaP3BB1dFtFun3VXJYTT0r+Enze bcTkUgvvI9cUxQfOhHA0yo/nZ6F0bsfeNz9KT5OArWCHM0OTN5eL5Iq23i5mY+I9Dtyz Oi+xAFG9T2DRTO4pia6yUr8X6nfrs4kAFbyjSQkDzFWNhV7gEycWdo43gi3PAJEosflR vqUPMieEatHW8luzWZ7DoA68qUyPbq1qPbl7YFNPKX1cemVdQ3wJf5vXpLYrgB7meYJr CdBQPHx3CBSqCzDQ2h2BuFBslYh6aD9L2T4tPupX5C+u1eMvlqA2Is0FD4rqPr8KhpnM QMag==
MIME-Version: 1.0
X-Received: by 10.152.9.36 with SMTP id w4mr1968595laa.34.1383148489422; Wed, 30 Oct 2013 08:54:49 -0700 (PDT)
Received: by 10.112.11.48 with HTTP; Wed, 30 Oct 2013 08:54:49 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> 
Date: Wed, 30 Oct 2013 11:54:49 -0400
Message-ID: 
From: Monty Montgomery 
To: Adam Roach 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:54:57 -0000

Argh, $6.5M!

[I don't want to substitute conviction for truth.  I do wish I could
substitute conviction for sleep.]

Monty

On Wed, Oct 30, 2013 at 11:53 AM, Monty Montgomery  wrote:
> I have been informed by several people that the $13M cap mentioned in
> my blog post is wrong.  The licensing math is different from the older
> MPEG codecs, and the correct number is $65.M until 2015.  I corrected
> my post to reflect this.
>
> On Wed, Oct 30, 2013 at 11:41 AM, Adam Roach  wrote:
>> On 10/30/13 10:20, Matt Fredrickson wrote:
>>>
>>> Does this mean that system information (for systems that this is installed
>>> on) may be tracked and sent back to the Cisco servers for accurate license
>>> usage count?  (ethernet MAC address, or some other system specific info) so
>>> that redownloads of modules on the same system are not counted towards your
>>> license usage accounting?
>>
>>
>> My understanding is that MPEG-LA has a per-organization royalty cap for
>> H.264 (13 MUSD, if my memory serves), and that Cisco reaches that cap quite
>> easily with their own products.
>>
>> /a
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb

From lorenzo@meetecho.com  Wed Oct 30 08:54:58 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6CE11E824A for ; Wed, 30 Oct 2013 08:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhGKDxF3h5Jm for ; Wed, 30 Oct 2013 08:54:53 -0700 (PDT)
Received: from smtpdg94.aruba.it (smtpdg96.aruba.it [62.149.158.96]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25A21F9FE9 for ; Wed, 30 Oct 2013 08:54:49 -0700 (PDT)
Received: from lminiero ([143.225.229.175]) by smtpcmd05.ad.aruba.it with bizsmtp id jTul1m01V3niPy701TulSg; Wed, 30 Oct 2013 16:54:46 +0100
Date: Wed, 30 Oct 2013 16:54:45 +0100
From: Lorenzo Miniero 
To: Ethan Hugg 
Message-ID: <20131030165445.57468c86@lminiero>
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero> 
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
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:54:58 -0000

Il giorno Wed, 30 Oct 2013 08:52:12 -0700
Ethan Hugg  ha scritto:

> Lorenzo,
> 
> You will be able to inspect the source yourself for nefarious things
> like tracking as the code will be freely available.
> 
> -EH
> 


Considering we're to choose between either the source code (paying
licence fees ourselves) or a binary module (free as a bird) I hope I'm
allowed to have my doubts.

Lorenzo


> 
> 
> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero
> wrote:
> 
> > Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> > Adam Roach  ha scritto:
> >
> > > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > > Does this mean that system information (for systems that this is
> > > > installed on) may be tracked and sent back to the Cisco servers
> > > > for accurate license usage count?  (ethernet MAC address, or
> > > > some other system specific info) so that redownloads of modules
> > > > on the same system are not counted towards your license usage
> > > > accounting?
> > >
> > > My understanding is that MPEG-LA has a per-organization royalty
> > > cap for H.264 (13 MUSD, if my memory serves), and that Cisco
> > > reaches that cap quite easily with their own products.
> > >
> > > /a
> >
> >
> > Which doesn't preclude the fact the module may do tracking anyway.
> >
> > Lorenzo
> >
> >
> > > _______________________________________________
> > > 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 mail@makk.es  Wed Oct 30 08:55:30 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7811E81DB for ; Wed, 30 Oct 2013 08:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYpVevd-xPQ4 for ; Wed, 30 Oct 2013 08:55:24 -0700 (PDT)
Received: from lupus.uberspace.de (lupus.uberspace.de [95.143.172.176]) by ietfa.amsl.com (Postfix) with SMTP id 9475111E82B1 for ; Wed, 30 Oct 2013 08:55:18 -0700 (PDT)
Received: (qmail 10630 invoked from network); 30 Oct 2013 15:55:17 -0000
Received: from unknown (HELO ?141.22.28.178?) (141.22.28.178) by lupus.uberspace.de with SMTP; 30 Oct 2013 15:55:17 -0000
Message-ID: <52712BE4.5040003@makk.es>
Date: Wed, 30 Oct 2013 16:55:16 +0100
From: Max Jonas Werner 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Ethan Hugg , Lorenzo Miniero 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>	<527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>				<527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcUFxugnje3xOS7q381GjqNull7Q6cp41"
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:55:30 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HcUFxugnje3xOS7q381GjqNull7Q6cp41
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 30.10.2013 16:52, Ethan Hugg wrote:
> Lorenzo,
>=20
> You will be able to inspect the source yourself for nefarious things li=
ke
> tracking as the code will be freely available.

This implies there exists a way to verify that the code under review is
actually the exact same code used to compile the binary which is not
trivial IIRC.

Max

> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero =
wrote:
>=20
>> Il giorno Wed, 30 Oct 2013 10:41:27 -0500
>> Adam Roach  ha scritto:
>>
>>> On 10/30/13 10:20, Matt Fredrickson wrote:
>>>> Does this mean that system information (for systems that this is
>>>> installed on) may be tracked and sent back to the Cisco servers for
>>>> accurate license usage count?  (ethernet MAC address, or some other
>>>> system specific info) so that redownloads of modules on the same
>>>> system are not counted towards your license usage accounting?
>>>
>>> My understanding is that MPEG-LA has a per-organization royalty cap
>>> for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that=

>>> cap quite easily with their own products.
>>>
>>> /a
>>
>> Which doesn't preclude the fact the module may do tracking anyway.
>>
>> Lorenzo


--HcUFxugnje3xOS7q381GjqNull7Q6cp41
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFScSvk1IVn4/X13N8RAq2yAJ93mM/clHcwzZt+3fKvyewqOd2gTwCbBxNB
7VhmFr8mo1lmRuSJfex6Hkk=
=iQAH
-----END PGP SIGNATURE-----

--HcUFxugnje3xOS7q381GjqNull7Q6cp41--

From creslin@digium.com  Wed Oct 30 08:55:36 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAE111E82B2 for ; Wed, 30 Oct 2013 08:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.856
X-Spam-Level: 
X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaK7nlGuswNI for ; Wed, 30 Oct 2013 08:55:32 -0700 (PDT)
Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id A3FD311E8179 for ; Wed, 30 Oct 2013 08:55:20 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id eh20so1236284lab.8 for ; Wed, 30 Oct 2013 08:55:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=klvSo6Q1813ivDC8/twCobK+vl2jgYzuI1I4cvQGdNM=; b=QwkGUuBoSuKiSAMTKv4mA7gNpOtOh6Zr9WYnMiRgHVjBbAM3kO3R7ylRe4FzaAZfVI M3s9bHnLZ4BMAI5fgaeEogvrqbshyEbLlAWA+evkJR4/jAKTZ6pUeFl0CdsiXnQt5/LO qH5mNC9WuBwUnrDARGCjlAvSW4/EuOQqsNEAfMuOFZTsPQGPAd9YjW7SmGgrHsjqdSLZ +AF6pW0lkhOR9+xSSs6EG2lmof32R8MUTVuvdB1ZRJ1owAyFkaQJ2ftJP27TWX46jPk8 YAnCYPSbM1QpOfyCDuWP5NoY+fZrct4f5T+Cb7jxDtrVqG6CoPYH6WmVdlHQSMBliyvN aM7g==
X-Gm-Message-State: ALoCoQk5mnjYV36DCZP4N0Qgf8kbIcz4cFXkNWhuIhxOmF7blRd3zVnxXAG9a8izDVdQ7BFNwmCQ
MIME-Version: 1.0
X-Received: by 10.112.49.195 with SMTP id w3mr192872lbn.65.1383148519601; Wed, 30 Oct 2013 08:55:19 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 08:55:19 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero> 
Date: Wed, 30 Oct 2013 10:55:19 -0500
Message-ID: 
From: Matt Fredrickson 
To: Ethan Hugg 
Content-Type: multipart/alternative; boundary=001a1135fab42ec9bc04e9f75c7d
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:55:37 -0000

--001a1135fab42ec9bc04e9f75c7d
Content-Type: text/plain; charset=ISO-8859-1

That is only as long as the binary versions don't have any additions or
changes for such things.  Nothing says that the binary modules cannot be
built in this way.

Matthew Fredrickson


On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg  wrote:

>
> Lorenzo,
>
> You will be able to inspect the source yourself for nefarious things like
> tracking as the code will be freely available.
>
> -EH
>
>
>
> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero wrote:
>
>> Il giorno Wed, 30 Oct 2013 10:41:27 -0500
>> Adam Roach  ha scritto:
>>
>> > On 10/30/13 10:20, Matt Fredrickson wrote:
>> > > Does this mean that system information (for systems that this is
>> > > installed on) may be tracked and sent back to the Cisco servers for
>> > > accurate license usage count?  (ethernet MAC address, or some other
>> > > system specific info) so that redownloads of modules on the same
>> > > system are not counted towards your license usage accounting?
>> >
>> > My understanding is that MPEG-LA has a per-organization royalty cap
>> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
>> > cap quite easily with their own products.
>> >
>> > /a
>>
>>
>> Which doesn't preclude the fact the module may do tracking anyway.
>>
>> Lorenzo
>>
>>
>> > _______________________________________________
>> > 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
>
>

--001a1135fab42ec9bc04e9f75c7d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


That is only as long as the binary versions don't have=
 any additions or changes for such things. =A0Nothing says that the binary =
modules cannot be built in this way.

Matthew Fredrickson




On Wed, Oct 3=
0, 2013 at 10:52 AM, Ethan Hugg <ethanhugg@gmail.com> wrot=
e:



Lorenzo,=A0
<=
div>
You will be able to inspect the source yourself for nefa=
rious things like tracking as the code will be freely available.



-EH





On Wed, Oct 30, 2013 a=
t 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:<=
br>


Il giorno Wed, 30 Oct 2013 10:41:27 -0500
Adam Roach <adam@n=
ostrum.com> ha scritto:




> On 10/30/13 10:20, Matt Fredrickson wrote:

> > Does this mean that system information (for systems that this is<=
br>
> > installed on) may be tracked and sent back to the Cisco servers f=
or

> > accurate license usage count? =A0(ethernet MAC address, or some o=
ther

> > system specific info) so that redownloads of modules on the same<=
br>
> > system are not counted towards your license usage accounting?

>

> My understanding is that MPEG-LA has a per-organization royalty cap
> for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that<=
br>
> cap quite easily with their own products.

>

> /a






Which doesn't preclude the fact the module may do tracking anyway=
.



Lorenzo






> _______________________________________________

> 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





--001a1135fab42ec9bc04e9f75c7d--

From ted.ietf@gmail.com  Wed Oct 30 08:58:37 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA27911E8253 for ; Wed, 30 Oct 2013 08:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyiGG0voxmxQ for ; Wed, 30 Oct 2013 08:58:32 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 834E521F9EDA for ; Wed, 30 Oct 2013 08:58:32 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id tp5so2641346ieb.31 for ; Wed, 30 Oct 2013 08:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WL3+e4uGX4qp45X8lYC0QuyYP6EoZ2Cd8Fhbna01mds=; b=fHdFc/9W0i0RKCnTpFVm9yVMog86nhX0QPQXz0Abz+yLj/dM9mHTl3CMqjX2RlZdoY /CXL0+5FWHB+ZtktHAyPelVoJGCPohLpMHYON2dLCwB1Qr34vzIv9ntOpvUf40RQUZ53 +IjmzAqHRoxpNP260CWomm7y/ka05mOT+YcM1Fa/F5dm5Qr5ky9s/s1iJnyecsPPjhv1 DA0aYV/jLrxdvk+EF62hLLNUuKKzOPyJ9ZlV8aJvT5mzJ/nGZO/aZq5Z+tH5S93oP4Lz amnU0C0WWRF2Icz6fo2gPSsjy9n5yQb6R6nF8a+J5slsXiV6myhB/f79a5o7laH+AE9c Z77A==
MIME-Version: 1.0
X-Received: by 10.50.130.46 with SMTP id ob14mr3021135igb.22.1383148712141; Wed, 30 Oct 2013 08:58:32 -0700 (PDT)
Received: by 10.43.115.72 with HTTP; Wed, 30 Oct 2013 08:58:32 -0700 (PDT)
In-Reply-To: <52712AAE.10401@nostrum.com>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com>  <52712AAE.10401@nostrum.com>
Date: Wed, 30 Oct 2013 08:58:32 -0700
Message-ID: 
From: Ted Hardie 
To: Adam Roach , "Jonathan Rosenberg (jdrosen)" 
Content-Type: multipart/alternative; boundary=047d7b418bb3a8aba404e9f7677f
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 15:58:37 -0000

--047d7b418bb3a8aba404e9f7677f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 30, 2013 at 8:50 AM, Adam Roach  wrote:

>  On 10/30/13 10:44, Ted Hardie wrote:
>
>
> The web site and your announcement say H.264, without naming specific
> profiles.  Will the details of which will be included come when the source
> code is available?
>
>
> You seem to have found the FAQ, but not read all the way to the bottom:
>
> *Q. Which profiles of H.264 will be supported?*
> A: The initial code has the baseline profile. We look forward to working
> with the open source community to add high profile and others.
>
>
>
I did, but that didn't seem to use the  names I am used to; that is, are we
talking about the same constrained baseline that is in the MTI draft?

  Do you have a timeline for when the source code might become available?
>
>
>
> Or the top:
>
> *Q. When will the H.264 source code and binary module be available?*
> A: Shortly, Cisco will form a governance board for the open source
> initiative, establish the project, and make the source code and binary
> module available for download. We will move quickly to carry out these
> steps, but past experience suggests that it will take a few months before
> the entire process is complete.
>
>
I was hoping Jonathan might be willing to say something more (like "before
the London meeting"), and I still am, so I have explicitly cc'ed him on
this message.

In case this is not clear, these are neither chair questions nor questions
from my employer, just my own personal questions.

Ted



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

--047d7b418bb3a8aba404e9f7677f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Oct 30, 2013 at 8:50 AM, Adam Roach <adam@nostrum.=
com> wrote:


 =20
   =20
 =20
  

    
On 10/30/13 10:44, Ted Hardie wrote:

    

    

      


        
The web site and your announcement say H.264, without
          naming specific profiles.=A0 Will the details of which will be
          included come when the source code is available?

      

    

    

    You seem to have found the FAQ, but not read all the way to the
    bottom:

    

    Q. Which profiles of H.264 will be supported?

    A: The initial code has the baseline profile. We look forward to
    working with the open source community to add high profile and
    others. 

    

    

I did, but that didn&#=
39;t seem to use the=A0 names I am used to; that is, are we talking about t=
he same constrained baseline that is in the MTI draft?




    

      

        
 Do you have a timeline for when the source code might
          become available?

        

      

    

    

    

    Or the top:

    

   =20
    Q. When will the H.264 source code and binary module be
      available?

    A: Shortly, Cisco will form a governance board for the open source
    initiative, establish the project, and make the source code and
    binary module available for download. We will move quickly to carry
    out these steps, but past experience suggests that it will take a
    few months before the entire process is complete. 

    

I was hoping J=
onathan might be willing to say something more (like "before the Londo=
n meeting"), and I still am, so I have explicitly cc'ed him on thi=
s message.


In case this is not clear, these are neither chair questions=
 nor questions from my employer, just my own personal questions.
<=
div>
Ted

=A0



    /a

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7b418bb3a8aba404e9f7677f--

From fluffy@cisco.com  Wed Oct 30 09:12:23 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B07B21E80D9 for ; Wed, 30 Oct 2013 09:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.576
X-Spam-Level: 
X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfOJTMnuUUyh for ; Wed, 30 Oct 2013 09:12:16 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3948521E811D for ; Wed, 30 Oct 2013 09:12:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=729; q=dns/txt; s=iport; t=1383149533; x=1384359133; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2bV4hjHVmL7FGROYYCDuqder15AURk8N233JVXFEaqE=; b=k4vRgmT7gFSHcyY92dJZ8E9V1GQ1CiwFKVNLKWfYb8pvj4pC5kueD7Oj FoIu2GccJUG4P5D7AmgQJ0AqSQD8+iR7KmYEhBPxPguWZACf0smmVsq4q J9FN6o5B/GyVn4EJXkRCNRmBd2MxJX9NvzGvc9VpCuhMNWCzOAEHltMaB M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAHoucVKtJV2Z/2dsb2JhbABZgwc4VL9PgScWdIIlAQEBAwF5BQsCAQgOFCQyJQIEDgUIh3kGuwmPHAIxB4MfgQ0DqhOBaIE+gio
X-IronPort-AV: E=Sophos;i="4.93,602,1378857600"; d="scan'208";a="278351538"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 30 Oct 2013 16:12:12 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9UGCCrZ012859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 16:12:12 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 11:12:12 -0500
From: "Cullen Jennings (fluffy)" 
To: Matt Fredrickson 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1YrKmf9gXRoQT1qWOAYOe51tPQ==
Date: Wed, 30 Oct 2013 16:12:11 +0000
Message-ID: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5BEE166B20CF65488D22121DC58773B8@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 16:12:23 -0000

On Oct 30, 2013, at 9:20 AM, Matt Fredrickson  wrote:

> Does this mean that system information (for systems that this is installe=
d on) may be tracked and sent back to the Cisco servers for accurate licens=
e usage count?  (ethernet MAC address, or some other system specific info) =
so that redownloads of modules on the same system are not counted towards y=
our license usage accounting?
>=20
> Matthew Fredrickson
>=20

Good question Matt and wish that had been in the FAQ. No we don't need to t=
rack MAC or any systems specific stuff. The download can be just a HTTP get=
 with no identifying information other than of course Cisco will see the IP=
 address the HTTP get came from. =

From jdrosen@jdrosen.net  Wed Oct 30 09:17:44 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F4E11E8179 for ; Wed, 30 Oct 2013 09:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.676
X-Spam-Level: 
X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbdcEueOqvrz for ; Wed, 30 Oct 2013 09:17:39 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7C21E8138 for ; Wed, 30 Oct 2013 09:17:01 -0700 (PDT)
Received: from mail-pd0-f182.google.com ([209.85.192.182]:50871) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VbYS0-0007vu-47 for rtcweb@ietf.org; Wed, 30 Oct 2013 12:17:01 -0400
Received: by mail-pd0-f182.google.com with SMTP id q10so1180000pdj.13 for ; Wed, 30 Oct 2013 09:16:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+skpNM8UOfWvRV0F4sIis/nx1nipne/rbWoOPQEBGkg=; b=Wjs/88BW+6au8o4h8IaojKybaIO2JdxlLISYCAi1L9mUtuh27qYdxQbqxvdeQ4jNKe ONB00DVVelrXvy541FOx2eFhsTy2OiqoJQpnH2IEdlxDr1JmTAagVLrGH/uFAHJbEe87 vGlGtHLmxwvUKcRoJWAEj8iwA11sJIStBrMwANEUyAWbbfFFXj/qTtY4DIarBHjX649O aMSlmgrncid+eLmhRPzEp9H77DcPLslzn5g0cXBFbNwzP50dGEB+wO6lh2OSRzQCUHFp DDEEo6Gsh+veyj8uwxS894zT5XKONti+LI1roophPTWv4qfG5LiAp2dE2n6xt+zuqoj6 T3aA==
MIME-Version: 1.0
X-Received: by 10.66.142.193 with SMTP id ry1mr4038826pab.150.1383149815378; Wed, 30 Oct 2013 09:16:55 -0700 (PDT)
Received: by 10.70.49.48 with HTTP; Wed, 30 Oct 2013 09:16:55 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> 
Date: Wed, 30 Oct 2013 12:16:55 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=001a113450c26abdb204e9f7a95b
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
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 16:17:44 -0000

--001a113450c26abdb204e9f7a95b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Great questions Ted. My answers inline:

On Wed, Oct 30, 2013 at 11:44 AM, Ted Hardie  wrote:

> Dr. Rosenberg, it's always good to have your contributions.
>
> Thanks for today's announcement; I have a couple of questions.
>

> In March, Cullen announced that Cisco would open source an H.264
> implementation if the working group selected H.264 as the MTI.  I assume
> that today's announcement is a follow-on to that intention, removing the
> requirement for H.264 to be the MTI for this generous gift, since there i=
s
> no similar requirement in your statement.  Is that correct?  This will
> remain available even in the case some other codec is selected as MTI?
>

Correct. This is not contingent on IETF selecting H.264 as MTI. We will
proceed with this if VP8 is chosen or if no decision is made next week.
Though obviously we and I hope this helps get a decision made in favor of
H.264.



>
> The web site and your announcement say H.264, without naming specific
> profiles.  Will the details of which will be included come when the sourc=
e
> code is available?  Do you have a timeline for when the source code might
> become available?  Since the board will also name supported platforms, ca=
n
> you give a timeline for when they might be disclosed?
>

We'll start with constrained baseline profile. However part of the benefit
of open sourcing is that the community can help bring this to high profile.

As for timeline - we're not ready to say anything yet on that - but "soon".
We understand that if this doesnt show up for a long time it kind of
defeats the purpose, and that all eyes are on this to actually ship. Same
with supported platforms, though we hope the community can help with this
too.




>
> The current announcement describes this as a single donation, but my read
> is that it is really two, in that someone may *either* have the source
> code under BSD license term* or* they may have the downloadable module
> with Cisco paying the MPEG-LA license fees, but that these offers cannot =
be
> combined.  This is based on my reading of this question and answer:
>

Yes. There is a relationship in that the binary module is a compiled
version of that source code. So if the community makes changes to the
source code those would show up in our distribution. But in terms of
licenses you are correct. There will be a BSD license for the source code.
But if folks want to avoid the MPEG-LA license costs, they do that by
taking the compiled binary version from us, and most importantly it needs
to be distributed to the user's computer or device by us.


> *Q. Why is Cisco making both source and binary versions available?*
> A: The source code is available so that an implementation of H.264 is
> available for the community to use across any project, and to leverage th=
e
> community to make the codec better for all. We will select licensing term=
s
> that allow for this code to be used in commercial products as well as ope=
n
> source projects. In order for Cisco to be responsible for the MPEG LA
> licensing royalties for the module, Cisco must provide the packaging and
> distribution of this code in a binary module format (think of it like a
> plug-in, but not using the same APIs as existing plugins), in addition to
> several other constraints. This gives the community the best of all world=
s
> - a team can choose to use the source code, in which case the team is
> responsible for paying all applicable license fees, or the team can use t=
he
> binary module distributed by Cisco, in which case Cisco will cover the MP=
EG
> LA licensing fees.
>
> Can you confirm that understanding?
>

Yes.


> If so, I have to note that I find the phrase "best of all worlds" a bit
> hyperbolic--a technology license that applied to all implementations woul=
d
> seem a bit better.  This may, of course, be the best of all worlds
> available to H.264.  I also note, by the way, that your announcement says
> BSD license, but this Q & A discuss this as if the licensing terms were
> still undefined.  Can you confirm that the license is BSD and update the
> FAQ?
>

Hmm thats a bug. Should be BSD.


>
> I also read it to say that Cisco will not indemnify users of either the
> source code or module against other patent holder's assertions of license=
,
> based on this question and answer:
>
> *Q: Is Cisco guaranteeing that it will pay other licensing fees for
> H.264, should additional patent holders assert claims in the future?
> *A: Cisco is providing no such guarantee. We are only covering the
> royalties that would apply to the binary module under MPEG LA's AVC/H.264
> patent pool.
>
> This seems quite clear to me, but I would appreciate your confirming it o=
n
> the list.
>

Confirmed. This is why we're using words like "we won't pass on our MPEG-LA
licensing costs". Meaning - we cannot guarantee there won't be other future
unknown costs and we cannot make any guarantees that we'd absorb them. This
is legal 101 - you cannot indemnify against potentially unbounded costs.
You can form your own opinion on the risks of new patent holders showing up=
.


>
> Many thanks again for your contribution,
>
> regards,
>
> Ted Hardie
>
>
> On Wed, Oct 30, 2013 at 5:28 AM, Jonathan Rosenberg (jdrosen) <
> jdrosen@cisco.com> wrote:
>
>>  I=92d like to make an announcement material to the conversations around
>> MTI video codecs in rtcweb.****
>>
>> ** **
>>
>> Cisco is announcing today that we will take our H.264 implementation, an=
d
>> open source it under BSD license terms. Development and maintenance will=
 be
>> overseen by a board from industry and the open source community.
>> Furthermore, we will provide a binary form suitable for inclusion in
>> applications across a number of different operating systems (Windows,
>> MacOS, Linux x86, Linux ARM and Android ARM), and make this binary modul=
e
>> available for download from the Internet. We will not pass on our MPEG-L=
A
>> licensing costs for this module, and based on the current licensing
>> environment, this will effectively make H.264 free for use on supported
>> platforms. ****
>>
>> ** **
>>
>> We believe that this contribution to the community can help address the
>> concerns many have raised around selection of H.264 as MTI. I firmly
>> believe that with H.264 we can achieve maximal interoperability and now,=
 do
>> it with open source and for free (well, at least for others =96 its not =
free
>> for Cisco J)****
>>
>> More information on the open source project can be found at
>> http://www.openh264.org, which is sparse now but more coming soon.****
>>
>> ** **
>>
>> ** **
>>
>> Thx,****
>>
>> Jonathan R.****
>>
>> ** **
>>
>> --****
>>
>> Jonathan Rosenberg, PhD****
>>
>> VP, CTO Collaboration****
>>
>> Cisco Systems****
>>
>> jdrosen@cisco.com****
>>
>> ** **
>>
>> _______________________________________________
>> 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
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--001a113450c26abdb204e9f7a95b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



Great questions Ted. My ans=
wers inline:

On Wed, Oct 30, 2013 at 11:4=
4 AM, Ted Hardie <ted.ietf@gmail.com> wrote:


Dr. Rosenberg, it'=
s always good to have your contributions.=A0 

Thanks for today's=
 announcement; I have a couple of questions.


In March, Cullen announced that Cisco would open source an H.26=
4 implementation if the working group selected H.264 as the MTI.=A0 I assum=
e that today's announcement is a follow-on to that intention, removing =
the requirement for H.264 to be the MTI for this generous gift, since there=
 is no similar requirement in your statement.=A0 Is that correct?=A0 This w=
ill remain available even in the case some other codec is selected as MTI?<=
br>


Correct. This is not contingen=
t on IETF selecting H.264 as MTI. We will proceed with this if VP8 is chose=
n or if no decision is made next week. Though obviously we and I hope this =
helps get a decision made in favor of H.264.



=A0


The web site and your announcement say H.264, without naming specific p=
rofiles.=A0 Will the details of which will be included come when the source=
 code is available?=A0 Do you have a timeline for when the source code migh=
t become available?=A0 Since the board will also name supported platforms, =
can you give a timeline for when they might be disclosed?



We'll start with constrain=
ed baseline profile. However part of the benefit of open sourcing is that t=
he community can help bring this to high profile.=A0



As for timeline - we're not ready to say anything yet on that - bu=
t "soon". We understand that if this doesnt show up for a long ti=
me it kind of defeats the purpose, and that all eyes are on this to actuall=
y ship. Same with supported platforms, though we hope the community can hel=
p with this too.




=A0
=



The current announcement describes this as a single donation=
, but my read is that it is really two, in that someone may either h=
ave the source code under BSD license term or they may have the down=
loadable module with Cisco paying the MPEG-LA license fees, but that these =
offers cannot be combined.=A0 This is based on my reading of this question =
and answer:



Yes. There is a relationship i=
n that the binary module is a compiled version of that source code. So if t=
he community makes changes to the source code those would show up in our di=
stribution. But in terms of licenses you are correct. There will be a BSD l=
icense for the source code. But if folks want to avoid the MPEG-LA license =
costs, they do that by taking the compiled binary version from us, and most=
 importantly it needs to be distributed to the user's computer or devic=
e by us.=A0





Q. Why is Cisco making both source a=
nd binary versions available?

            A: The source code is available so that an implementation of
 H.264 is available for the community to use across any project, and to=20
leverage the community to make the codec better for all. We will select=20
licensing terms that allow for this code to be used in commercial=20
products as well as open source projects. In order for Cisco to be=20
responsible for the MPEG LA licensing royalties for the module, Cisco=20
must provide the packaging and distribution of this code in a binary=20
module format (think of it like a plug-in, but not using the same APIs=20
as existing plugins), in addition to several other constraints. This=20
gives the community the best of all worlds - a team can choose to use=20
the source code, in which case the team is responsible for paying all=20
applicable license fees, or the team can use the binary module=20
distributed by Cisco, in which case Cisco will cover the MPEG LA=20
licensing fees. 

Can you confirm that understanding?=A0
<=
/div>

Yes.
=A0


 If so, I have to note that I find the phrase "b=
est of all worlds" a bit hyperbolic--a technology license that applied=
 to all implementations would seem a bit better.=A0 This may, of course, be=
 the best of all worlds available to H.264.=A0 I also note, by the way, tha=
t your announcement says BSD license, but this Q & A discuss this as if=
 the licensing terms were still undefined.=A0 Can you confirm that the lice=
nse is BSD and update the FAQ?



Hmm thats a bug. Should be BSD=
.
=A0



I also read it to say that Cisco will not indemni=
fy users of either the source code or module against other patent holder=
9;s assertions of license, based on this question and answer:

Q: =
Is Cisco guaranteeing that it will pay other licensing fees=20
for H.264, should additional patent holders assert claims in the future?
  =20
            A: Cisco is providing no such guarantee.  We are=20
only covering the royalties that would apply to the binary module under=20
MPEG LA's AVC/H.264 patent pool.

This seems quite cle=
ar to me, but I would appreciate your confirming it on the list.
<=
/div>

Confirmed. This is why we're usin=
g words like "we won't pass on our MPEG-LA licensing costs". =
Meaning - we cannot guarantee there won't be other future unknown costs=
 and we cannot make any guarantees that we'd absorb them. This is legal=
 101 - you cannot indemnify against potentially unbounded costs. You can fo=
rm your own opinion on the risks of new patent holders showing up.


=A0

Many=
 thanks again for your contribution,

regards,

Ted Hardie




On Wed, Oct 30, 2013 at 5:28 AM, Jonathan Rosenberg (jdrose=
n) <jdrosen@cisco.com> wrote:














I=92d like to make an announcement material to the c=
onversations around MTI video codecs in rtcweb.


=A0


Cisco is announcing today that we will take our H.26=
4 implementation, and open source it under BSD license terms. Development a=
nd maintenance will be overseen by a board from industry and the open sourc=
e community.=A0 Furthermore, we will
 provide a binary form suitable for inclusion in applications across a numb=
er of different operating systems (Windows, MacOS, Linux x86, Linux ARM and=
 Android ARM), and make this binary module available for download from the =
Internet. We will not pass on our
 MPEG-LA licensing costs for this module, and based on the current licensin=
g environment, this will effectively make H.264 free for use on supported p=
latforms.



=A0


We believe that this contribution to the community c=
an help address the concerns many have raised around selection of H.264 as =
MTI. I firmly believe that with H.264 we can achieve maximal interoperabili=
ty and now, do it with open source
 and for free (well, at least for others =96 its not free for Cisco 
J)


More information on the open source project can be f=
ound at 
http://www.openh264.org, which is sparse now but more coming soon.


=A0


=A0


Thx,


Jonathan R.


=A0


--


Jonathan Rosenberg, PhD


VP, CTO Collaboration


Cisco Systems


jdrosen@cisco.com


=A0







_________________________________________=
______

rtcweb mailing list

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





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





-- 





--001a113450c26abdb204e9f7a95b--

From fluffy@cisco.com  Wed Oct 30 09:17:48 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F3321E8141 for ; Wed, 30 Oct 2013 09:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYSaAqPVliMX for ; Wed, 30 Oct 2013 09:17:44 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 425F521E8109 for ; Wed, 30 Oct 2013 09:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2389; q=dns/txt; s=iport; t=1383149823; x=1384359423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8MIhCHhUnVC4mvU/OKytCiZyoR9gyeT3DfjyezXwFrc=; b=Ace5EMYLW3wjF29W14SlKJoPKDebhSRHbSU+YSRT6gcUHMeazF9yqQau PhfIx/pEZAo06se1sHYblJjdINO8wd5KPqTLMRBFXB68zvEByXm1BZUVY INgMVDCbOUs/gnoIeOtRc3kFbBv9hG9ebP7Ku2rCxOeEwM1V0rov1tAMX 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAFkwcVKtJXHB/2dsb2JhbABZgwc4VL8ES4EnFnSCJQEBAQMBAQEBawsFCwIBCA4KCiQhBgslAgQOBQiHbQMJBg2xAg2JZwSMX4I9AjEHgx+BDQOJB40Yjj2FN4FogT6BaAc7
X-IronPort-AV: E=Sophos;i="4.93,602,1378857600"; d="scan'208";a="278630940"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 30 Oct 2013 16:17:02 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9UGH2PJ021498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 16:17:02 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 11:17:02 -0500
From: "Cullen Jennings (fluffy)" 
To: Matt Fredrickson 
Thread-Topic: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
Thread-Index: AQHO1Yt3mf9gXRoQT1qWOAYOe51tPQ==
Date: Wed, 30 Oct 2013 16:17:02 +0000
Message-ID: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <95FB279B4D136D4595573FC7B0B25D3B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 16:17:48 -0000

On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote:

> That is only as long as the binary versions don't have any additions or c=
hanges for such things.  Nothing says that the binary modules cannot be bui=
lt in this way.

The binary module will be build that way.=20

All the build scripts etc that Cisco uses will be part of the open source p=
roject so that anyone can build it them selves and check that their build m=
atches the Cisco binary and check the code does not have backdoors to send =
all your video to the NSA.


>=20
> Matthew Fredrickson
>=20
>=20
> On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg  wrote:
>=20
> Lorenzo,=20
>=20
> You will be able to inspect the source yourself for nefarious things like=
 tracking as the code will be freely available.
>=20
> -EH
>=20
>=20
>=20
> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero  w=
rote:
> Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> Adam Roach  ha scritto:
>=20
> > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > Does this mean that system information (for systems that this is
> > > installed on) may be tracked and sent back to the Cisco servers for
> > > accurate license usage count?  (ethernet MAC address, or some other
> > > system specific info) so that redownloads of modules on the same
> > > system are not counted towards your license usage accounting?
> >
> > My understanding is that MPEG-LA has a per-organization royalty cap
> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> > cap quite easily with their own products.
> >
> > /a
>=20
>=20
> Which doesn't preclude the fact the module may do tracking anyway.
>=20
> Lorenzo
>=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
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From creslin@digium.com  Wed Oct 30 09:43:03 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5736621E8113 for ; Wed, 30 Oct 2013 09:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.876
X-Spam-Level: 
X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDq2wS16W3rX for ; Wed, 30 Oct 2013 09:42:59 -0700 (PDT)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id F068921E811D for ; Wed, 30 Oct 2013 09:41:58 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id el20so1336463lab.30 for ; Wed, 30 Oct 2013 09:41:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qwXHeq3aB6yP820HNoDqiKn8YYgoBpjUh3eU7bRxLFM=; b=WFdZqdzg6b/v0iEnVyXm6n183Bu3luy43s91fNBDS/sqsAu9qBfS3H+Ro6/KQi0fIh MbnE5xRhh/SAlZLgpkn+VxcuMy26rawvqJay6m8ZAD50WBgt0wLne7SJcyNghYMtOxXS pLFjVnvXYDatCH21NOEFsRJDUR8gveZJ34h9ueb5h0L0IBjqPo/asWN311aN65g6qIMK I0+1AoOBYysCFBvBpU1WtICkJkNdsP+nlPB9R01vHJU8nzJRkNC1+uI3H3qkqgR9pAzX L97YhleU+K5939/gr+v6Y4MsqsxWSPedvzwXx2W43qZOphtdv47sX1QQyLKtFvUZnITd bd1g==
X-Gm-Message-State: ALoCoQnDsE5XFHhh/szBw7wOvHFspBiSp3J7xwmwKu6NF029UCpQg+HwaRvegk3p71MklrG5+QbR
MIME-Version: 1.0
X-Received: by 10.112.64.36 with SMTP id l4mr3989236lbs.15.1383151316722; Wed, 30 Oct 2013 09:41:56 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 09:41:56 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>   
Date: Wed, 30 Oct 2013 11:41:56 -0500
Message-ID: 
From: Matt Fredrickson 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=001a11c3eee4e77e3204e9f80218
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 16:43:03 -0000

--001a11c3eee4e77e3204e9f80218
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the clarification on both of my questions (about the tracking,
and how the module would be build).

Matthew Fredrickson


On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy)  wrote:

>
> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote:
>
> > That is only as long as the binary versions don't have any additions or
> changes for such things.  Nothing says that the binary modules cannot be
> built in this way.
>
> The binary module will be build that way.
>
> All the build scripts etc that Cisco uses will be part of the open source
> project so that anyone can build it them selves and check that their build
> matches the Cisco binary and check the code does not have backdoors to send
> all your video to the NSA.
>
>
> >
> > Matthew Fredrickson
> >
> >
> > On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg 
> wrote:
> >
> > Lorenzo,
> >
> > You will be able to inspect the source yourself for nefarious things
> like tracking as the code will be freely available.
> >
> > -EH
> >
> >
> >
> > On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero 
> wrote:
> > Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> > Adam Roach  ha scritto:
> >
> > > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > > Does this mean that system information (for systems that this is
> > > > installed on) may be tracked and sent back to the Cisco servers for
> > > > accurate license usage count?  (ethernet MAC address, or some other
> > > > system specific info) so that redownloads of modules on the same
> > > > system are not counted towards your license usage accounting?
> > >
> > > My understanding is that MPEG-LA has a per-organization royalty cap
> > > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> > > cap quite easily with their own products.
> > >
> > > /a
> >
> >
> > Which doesn't preclude the fact the module may do tracking anyway.
> >
> > Lorenzo
> >
> >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c3eee4e77e3204e9f80218
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Thanks for the clarification on both of my questions (abou=
t the tracking, and how the module would be build).

Matt=
hew Fredrickson



On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy) <fluffy@cisco.co=
m> wrote:




On Oct 30, 2013, at 9:55 AM, Matt Fredrickson <creslin@digium.com> wrote:



> That is only as long as the binary versions don't have any additio=
ns or changes for such things. =A0Nothing says that the binary modules cann=
ot be built in this way.




The binary module will be build that way.



All the build scripts etc that Cisco uses will be part of the open source p=
roject so that anyone can build it them selves and check that their build m=
atches the Cisco binary and check the code does not have backdoors to send =
all your video to the NSA.







>

> Matthew Fredrickson

>

>

> On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg <ethanhugg@gmail.com> wrote:

>

> Lorenzo,

>

> You will be able to inspect the source yourself for nefarious things l=
ike tracking as the code will be freely available.

>

> -EH

>

>

>

> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

> Il giorno Wed, 30 Oct 2013 10:41:27 -0500

> Adam Roach <adam@nostrum.com> ha scritto:

>

> > On 10/30/13 10:20, Matt Fredrickson wrote:

> > > Does this mean that system information (for systems that thi=
s is

> > > installed on) may be tracked and sent back to the Cisco serv=
ers for

> > > accurate license usage count? =A0(ethernet MAC address, or s=
ome other

> > > system specific info) so that redownloads of modules on the =
same

> > > system are not counted towards your license usage accounting=
?

> >

> > My understanding is that MPEG-LA has a per-organization royalty c=
ap

> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches =
that

> > cap quite easily with their own products.

> >

> > /a

>

>

> Which doesn't preclude the fact the module may do tracking anyway.=


>

> Lorenzo

>

>

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.org

> > https://www.ietf.org/mailman/listinfo/rtcweb

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb







--001a11c3eee4e77e3204e9f80218--

From ssokol@digium.com  Wed Oct 30 09:43:21 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3F921E813E for ; Wed, 30 Oct 2013 09:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HHGbI9RDzaO for ; Wed, 30 Oct 2013 09:43:05 -0700 (PDT)
Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF2011E8179 for ; Wed, 30 Oct 2013 09:42:15 -0700 (PDT)
Received: by mail-qe0-f47.google.com with SMTP id b4so979300qen.20 for ; Wed, 30 Oct 2013 09:42:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dlhGvJVrGaBEdQ04KJBTVsA6xL0gEmkuvfxQ2kHxl0Y=; b=kt/Y91289+FQKROdU4015zwNRf1POuPuDhuvIsI/9StyG9gFbiFHVz6V8GSKue/QeL L31UI1REcA5HMaB7iFrXotGrlqpJIsZRpoVWf99gjzmpAvUgFTjnTnTht0+eh7FFPViu DsqXeSfN2LoxvSkLbh/YA0pdSj/TZPxVgP2woCa+rUrU8mO4/YydjqhntOcml0+JMqwV rRuAnrZFdw90ZtTk3Qee0AzwVL4uvLH/RHyuic1JZP2CVGLqai1XD/WhYNWDvx9DjksP 3nTxBRYMl4+fO8f4+MVYANGGrpi0PKscmPM+LvcsoneODSkFt72Pb7r0WIYoxxXfoN1W Qk/w==
X-Gm-Message-State: ALoCoQktYJIPm5cuVhEyTW/pvo2df7vL+/OXYIm6G1Nbbf4I7UgUULyuhWpvE21iyDT+s6HoGnC4
MIME-Version: 1.0
X-Received: by 10.229.79.70 with SMTP id o6mr8056188qck.21.1383151326019; Wed, 30 Oct 2013 09:42:06 -0700 (PDT)
Received: by 10.224.141.212 with HTTP; Wed, 30 Oct 2013 09:42:05 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>   
Date: Wed, 30 Oct 2013 11:42:05 -0500
Message-ID: 
From: Steve Sokol 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/related; boundary=001a1133beb676a7da04e9f8035c
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 16:43:22 -0000

--001a1133beb676a7da04e9f8035c
Content-Type: multipart/alternative; boundary=001a1133beb676a7d704e9f8035b

--001a1133beb676a7d704e9f8035b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Jonathan and Fluffy,

In regards to Apple's restriction on the installation of binary modules the
prevents iOS from being included in the list of supported platforms: what
precludes Cisco from offering a binary static library built for iOS? If
it's because the licensing terms you've struck with MPEG LA require you
count downloads, could you offer an iOS version that simply does a one-time
"phone-home" to cover the count requirement? The phone-home call could be
anonymous and unique (hash of MAC or similar). Not necessarily ideal from a
privacy perspective, but better than leaving a large, affluent and vocal
part of the digital ecosystem out.



On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy)  wrote:

>
> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote:
>
> > That is only as long as the binary versions don't have any additions or
> changes for such things.  Nothing says that the binary modules cannot be
> built in this way.
>
> The binary module will be build that way.
>
> All the build scripts etc that Cisco uses will be part of the open source
> project so that anyone can build it them selves and check that their buil=
d
> matches the Cisco binary and check the code does not have backdoors to se=
nd
> all your video to the NSA.
>
>
> >
> > Matthew Fredrickson
> >
> >
> > On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg 
> wrote:
> >
> > Lorenzo,
> >
> > You will be able to inspect the source yourself for nefarious things
> like tracking as the code will be freely available.
> >
> > -EH
> >
> >
> >
> > On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero 
> wrote:
> > Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> > Adam Roach  ha scritto:
> >
> > > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > > Does this mean that system information (for systems that this is
> > > > installed on) may be tracked and sent back to the Cisco servers for
> > > > accurate license usage count?  (ethernet MAC address, or some other
> > > > system specific info) so that redownloads of modules on the same
> > > > system are not counted towards your license usage accounting?
> > >
> > > My understanding is that MPEG-LA has a per-organization royalty cap
> > > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> > > cap quite easily with their own products.
> > >
> > > /a
> >
> >
> > Which doesn't preclude the fact the module may do tracking anyway.
> >
> > Lorenzo
> >
> >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--=20

*Steven Sokol*
Digium, Inc. =B7 Director of Strategic Programs
445 Jan Davis Drive NW =B7 Huntsville, AL 35806 =B7 US

--001a1133beb676a7d704e9f8035b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Jonathan and Fluffy,

In regards to Appl=
e's restriction on the installation of binary modules the prevents iOS =
from being included in the list of supported platforms: what precludes Cisc=
o from offering a binary static library built for iOS? If it's because =
the licensing terms you've struck with MPEG LA require you count downlo=
ads, could you offer an iOS version that simply does a one-time "phone=
-home" to cover the count requirement? The phone-home call could be an=
onymous and unique (hash of MAC or similar). Not necessarily ideal from a p=
rivacy perspective, but better than leaving a large, affluent and vocal par=
t of the digital ecosystem out.





On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy) <fluffy@=
cisco.com> wrote:




On Oct 30, 2013, at 9:55 AM, Matt Fredrickson <creslin@digium.com> wrote:



> That is only as long as the binary versions don't have any additio=
ns or changes for such things. =A0Nothing says that the binary modules cann=
ot be built in this way.




The binary module will be build that way.



All the build scripts etc that Cisco uses will be part of the open source p=
roject so that anyone can build it them selves and check that their build m=
atches the Cisco binary and check the code does not have backdoors to send =
all your video to the NSA.







>

> Matthew Fredrickson

>

>

> On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg <ethanhugg@gmail.com> wrote:

>

> Lorenzo,

>

> You will be able to inspect the source yourself for nefarious things l=
ike tracking as the code will be freely available.

>

> -EH

>

>

>

> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

> Il giorno Wed, 30 Oct 2013 10:41:27 -0500

> Adam Roach <adam@nostrum.com> ha scritto:

>

> > On 10/30/13 10:20, Matt Fredrickson wrote:

> > > Does this mean that system information (for systems that thi=
s is

> > > installed on) may be tracked and sent back to the Cisco serv=
ers for

> > > accurate license usage count? =A0(ethernet MAC address, or s=
ome other

> > > system specific info) so that redownloads of modules on the =
same

> > > system are not counted towards your license usage accounting=
?

> >

> > My understanding is that MPEG-LA has a per-organization royalty c=
ap

> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches =
that

> > cap quite easily with their own products.

> >

> > /a

>

>

> Which doesn't preclude the fact the module may do tracking anyway.=


>

> Lorenzo

>

>

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.org

> > https://www.ietf.org/mailman/listinfo/rtcweb

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





-- 
=



Steven Sokol
Digium, In=
c.=A0=B7=A0Director of Strategic Programs

445 Jan Davis Drive NW=A0=B7=A0Huntsville, AL 35806=A0=B7=A0US




--001a1133beb676a7d704e9f8035b--
--001a1133beb676a7da04e9f8035c
Content-Type: image/gif; name="digium_RGB_signature.gif"
Content-Transfer-Encoding: base64
Content-ID: <4EBAC09F-2713-4F02-B5AA-78A0B1B26E46@digium.internal>
X-Attachment-Id: 3210e4384c7d091e_0.1.1

R0lGODlhIAEyANUhAObi34Cqz0B/tsDV5/ePHiBpqvD1+f/48jB0sPvHj9Df7fiWLBBfpPmrVuDq
86C/2/3jx/q5c2CUw3CfyfidOv7x5LDK4VCKvP7q1vvAgZC11f3cufqyZfmkSPzOnfzVqwBUnv//
/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACEALAAAAAAgATIAAAb/wJBw
SCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/9gFRkU
Cw2EHB6AiouMUAkLCRVDFRwEGY2YmY0YEREHGA2XQ5UQmqaneRgLERCtBA0hHgchGAQRqLi5bwcU
HAcLrwQUHZZCr7rIyWYJBBUHzATRwhvGsMrX2FwLHEIHEdIEpSEVxdnm51K1CSG84NG3zOLo8/RI
EOWGzA3MGxWF9QB1KdAwoMkBAgtmzboHy1mHBZICStQkAASIAE4a2JqU4IOQe9QmimxU8aITVQQ6
fFC4IUIhCuuwKAjgYKTNMiUxnqTgDmGE/wwPZ11hwEDAzaNhckbZkKBpgpBDhFopUEAC0qtYDAzY
6kBpEgUWHgwwEACBASwOthYUopXrWKxwpRiYYLFu3QAB7OpUUMAuA4sMJOgNUXetEKUWL1zw+4Du
4LiQmxhAYLcy3sEDKtuV4NgixsJEEGseXfdB5NNJOhfAW/LigAB9TcZmEMACZYtbYXsmjDv0brsX
Aiyuu3rCXxAFUCsn4qDuhbNCbuvMqaA029gTDv/uPUQ0CA3dLRaA/qDu8vMa6tYMbzJEzswWfYMw
6n47CMP1TYIWknf+EPggnLdcfwgU4RV1dVkwRGxW5fcZd9rpB2F/9IUAoIDKUWjgbg6GEP8bAhYM
IJhFpnW4X4QP3jeEhkJciOFpBG7YnlIWkDYeirypyF6KhrFooXkvRtYfCOvh2GEII9qFgAI75oif
dE6uaFGFLgYZV3UWmTUElB3WiBxetcmYok4hpGdfj1P+B6SVcbVW1ASxzbhbSQhIUJIAAUCn1G0g
XADnYCf6WCWbWClw3GjT7ZakZvTRSNqZUvrX4pqEYuXAogLElqhJBgw3nwCHMunVA3EWoIF3aEr6
Y3yVRqbAW0w4AN11EBqR1qyt5mqFAQwUUKIBZuqo67Bf8KlZcsQmy0WnNjKp7LNaKDBBSUWVCO21
2Gar7bbcdqsLAOCGK+645JZr7rnopqsi7rrstuvuu/DGK++89Narrrf45qvvvvz26++/AAcssBpB
AAA7
--001a1133beb676a7da04e9f8035c--

From lgeyser@gmail.com  Wed Oct 30 09:44:11 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1675021E8146 for ; Wed, 30 Oct 2013 09:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdp2FVr9PpCM for ; Wed, 30 Oct 2013 09:44:03 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1190821E812A for ; Wed, 30 Oct 2013 09:42:46 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id w7so1430181lbi.18 for ; Wed, 30 Oct 2013 09:42:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E5fPaLhmUHKjNAJZZOstSOmz5xMNDdtjoV37z4+Kbho=; b=n5xhR9nPdfMMsHolgfyITIjC/QapEyxtZvt+WNNEzfGlFOZ2eUeXYOxp2fn9qr1E// HztjhOg6E2xLP1jkJUmRtawiFVxr+uu9zv9ryatLLgfFRnR8OZGdOf5Q7/PY4aomLP/R m5TARk7PS/FSzZf3q2aknyqgsU/gBbNXywCsBnAzwLWqTY/eAlHeIs4b55SSa2a9U/m6 E/UNLhBUPneKb3g/YWlI9EP/fvR/2bhetqvxo3VUUD9q+iHWyrHbnEdpCuKVYzPYGe5B Gle91uXSK2HxJCVqtFbgm9BGjBxJBLLdTFxJjn0GJNgeOblc1gDdvSsrrEuCq7JmwAGu YPAw==
MIME-Version: 1.0
X-Received: by 10.112.146.200 with SMTP id te8mr3990287lbb.32.1383151365999; Wed, 30 Oct 2013 09:42:45 -0700 (PDT)
Received: by 10.114.168.70 with HTTP; Wed, 30 Oct 2013 09:42:45 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>   
Date: Wed, 30 Oct 2013 18:42:45 +0200
Message-ID: 
From: Leon Geyser 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b3a83d4d7577e04e9f80546
Cc: "Cullen Jennings \(fluffy\)" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 16:44:11 -0000

--047d7b3a83d4d7577e04e9f80546
Content-Type: text/plain; charset=ISO-8859-1

It is all great, but how do we solve the problem to support current or
future platforms that don't support downloading a BLOB onto the device and
then using it?


On 30 October 2013 18:17, Cullen Jennings (fluffy)  wrote:

>
> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote:
>
> > That is only as long as the binary versions don't have any additions or
> changes for such things.  Nothing says that the binary modules cannot be
> built in this way.
>
> The binary module will be build that way.
>
> All the build scripts etc that Cisco uses will be part of the open source
> project so that anyone can build it them selves and check that their build
> matches the Cisco binary and check the code does not have backdoors to send
> all your video to the NSA.
>
>
> >
> > Matthew Fredrickson
> >
> >
> > On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg 
> wrote:
> >
> > Lorenzo,
> >
> > You will be able to inspect the source yourself for nefarious things
> like tracking as the code will be freely available.
> >
> > -EH
> >
> >
> >
> > On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero 
> wrote:
> > Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> > Adam Roach  ha scritto:
> >
> > > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > > Does this mean that system information (for systems that this is
> > > > installed on) may be tracked and sent back to the Cisco servers for
> > > > accurate license usage count?  (ethernet MAC address, or some other
> > > > system specific info) so that redownloads of modules on the same
> > > > system are not counted towards your license usage accounting?
> > >
> > > My understanding is that MPEG-LA has a per-organization royalty cap
> > > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> > > cap quite easily with their own products.
> > >
> > > /a
> >
> >
> > Which doesn't preclude the fact the module may do tracking anyway.
> >
> > Lorenzo
> >
> >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7b3a83d4d7577e04e9f80546
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


It is all great, but how do we solve the problem to suppor=
t current or future platforms that don't support downloading a BLOB ont=
o the device and then using it?



On 30 October 2013 18:17, Cullen Jennings (fluff=
y) <fluffy@cisco.com> wrote:


On Oct 30, 2013, at 9:55 AM, Matt Fredrickson <creslin@digium.com> wrote:



> That is only as long as the binary versions don't have any additio=
ns or changes for such things. =A0Nothing says that the binary modules cann=
ot be built in this way.




The binary module will be build that way.



All the build scripts etc that Cisco uses will be part of the open source p=
roject so that anyone can build it them selves and check that their build m=
atches the Cisco binary and check the code does not have backdoors to send =
all your video to the NSA.







>

> Matthew Fredrickson

>

>

> On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg <ethanhugg@gmail.com> wrote:

>

> Lorenzo,

>

> You will be able to inspect the source yourself for nefarious things l=
ike tracking as the code will be freely available.

>

> -EH

>

>

>

> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

> Il giorno Wed, 30 Oct 2013 10:41:27 -0500

> Adam Roach <adam@nostrum.com> ha scritto:

>

> > On 10/30/13 10:20, Matt Fredrickson wrote:

> > > Does this mean that system information (for systems that thi=
s is

> > > installed on) may be tracked and sent back to the Cisco serv=
ers for

> > > accurate license usage count? =A0(ethernet MAC address, or s=
ome other

> > > system specific info) so that redownloads of modules on the =
same

> > > system are not counted towards your license usage accounting=
?

> >

> > My understanding is that MPEG-LA has a per-organization royalty c=
ap

> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches =
that

> > cap quite easily with their own products.

> >

> > /a

>

>

> Which doesn't preclude the fact the module may do tracking anyway.=


>

> Lorenzo

>

>

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.org

> > https://www.ietf.org/mailman/listinfo/rtcweb

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7b3a83d4d7577e04e9f80546--

From matthew@matthew.at  Wed Oct 30 09:53:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CA621E80F3 for ; Wed, 30 Oct 2013 09:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8VCg+RdhxHi for ; Wed, 30 Oct 2013 09:53:04 -0700 (PDT)
Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 3756621F9FF1 for ; Wed, 30 Oct 2013 09:52:52 -0700 (PDT)
Received: from [10.10.155.2] (unknown [10.10.155.2]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id F28FA3C9DE8 for ; Wed, 30 Oct 2013 09:52:49 -0700 (PDT)
Message-ID: <52713962.3010201@matthew.at>
Date: Wed, 30 Oct 2013 09:52:50 -0700
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <52681A96.2020904@alvestrand.no>
In-Reply-To: <52681A96.2020904@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 16:53:39 -0000

On 10/23/2013 11:51 AM, Harald Alvestrand wrote:
> The dominant video codec, H.264, is a royalty-required codec.
>
> Do we switch now, or do we give up and live with royalties forever?
>

This is a little dramatic. One can trivially prove that every technology 
required to implement H.264 will lose the protection of the patent 
system in a finite period of time. Much, much sooner than "forever".

Matthew Kaufman

From xiphmont@gmail.com  Wed Oct 30 10:08:07 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DCE11E82D3 for ; Wed, 30 Oct 2013 10:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level: 
X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.520,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+jcpZH-6oxI for ; Wed, 30 Oct 2013 10:08:05 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EA34A11E82CB for ; Wed, 30 Oct 2013 10:07:23 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id q8so1447043lbi.5 for ; Wed, 30 Oct 2013 10:07:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9+8QBHmRJ6j1j0IWRlHmrSPxRTFDwuKAReh2hbZUxZM=; b=krdzoGT1tGNwWzKK0KNQSplv6D8vk3tntXuLBJzEX8olM3MO2lL+W0rbDlffmalPe0 Ap2Qb8JheMmTxIIOc8SJdsdZnSTFhNUyde7foia4bCqsh1X2jmAywvyS9AWn85Nw1TlS M3+HyRFR3b4NpOiHDupNBPQNoA7UNFd9SfQfxThDqJC6k1VctSCjl9WXhZRLGCiElkMX OSxRoNQlr9KIF3zrW6cSGL72upjpzakth2SsB/Z/E98DeX8C47sVK+5Ateo27DFMpnkf fIf30aeL/8gsWjSU0x/743GxdDdMe+OuVekeC5luIoBBNvjvKesTdAmdddbhaL2qa1/y ATFg==
MIME-Version: 1.0
X-Received: by 10.112.14.3 with SMTP id l3mr4045341lbc.27.1383152837364; Wed, 30 Oct 2013 10:07:17 -0700 (PDT)
Received: by 10.112.11.48 with HTTP; Wed, 30 Oct 2013 10:07:17 -0700 (PDT)
In-Reply-To: <52713962.3010201@matthew.at>
References: <52681A96.2020904@alvestrand.no> <52713962.3010201@matthew.at>
Date: Wed, 30 Oct 2013 13:07:17 -0400
Message-ID: 
From: Monty Montgomery 
To: Matthew Kaufman 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:08:07 -0000

> This is a little dramatic. One can trivially prove that every technology
> required to implement H.264 will lose the protection of the patent system in
> a finite period of time. Much, much sooner than "forever".

Had the Web been patented, those patents would just now be starting to
expire.  I was a slender, handsome undergraduate back then.  Sure
feels like forever.

Monty

From creslin@digium.com  Wed Oct 30 10:08:22 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2957511E82DA for ; Wed, 30 Oct 2013 10:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.89
X-Spam-Level: 
X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lFk9xrWr9wy for ; Wed, 30 Oct 2013 10:08:16 -0700 (PDT)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0B011E82CA for ; Wed, 30 Oct 2013 10:07:33 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id ea20so1352326lab.15 for ; Wed, 30 Oct 2013 10:07:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/NqE3rIaLqb5/gU6lmGqBWL+YmjquiNUw8gFMZDVMNU=; b=g8HLLIoQ7wI8bzc3fjQMuudaXvEcJqXN3bqh26IipEbJJ3UX9Zf6GzKF0byhVwImBs 9xxsGZGkIFxYYtBr3rvS79QI+8TZqxnuaq2yFSjrb28CpFht00FYOOi9AUeMSOY+V6b6 OCXDpHFme2t1fwjhsfFf5HrHGDYf6pjC3CxAvIs39D2/OwfmMj3XqLWmX/0pPcXDkxCZ yVxr2TZwTZTcA9/hRas6uySGZlyHKnBGotOq9d8lCbiK9SSrLjiVRS+Y0qy01uTau3Fm kCsZsY3m/DIxt2lIyUwoaADqzyCAQ9AUw2OduH8jsfxcr+xBQEVCmU3XIgqosc3ETsL8 F8pg==
X-Gm-Message-State: ALoCoQnIZ6tupPonOKHM4Qm0LdV4U+5sT2GC93rqXiu+QtIDHjS8ZuMaFbrr59txfoD8oOshNbln
MIME-Version: 1.0
X-Received: by 10.112.159.166 with SMTP id xd6mr4159486lbb.22.1383152852904; Wed, 30 Oct 2013 10:07:32 -0700 (PDT)
Received: by 10.112.132.102 with HTTP; Wed, 30 Oct 2013 10:07:32 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>   
Date: Wed, 30 Oct 2013 12:07:32 -0500
Message-ID: 
From: Matt Fredrickson 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=001a11c3db7477c2a704e9f85e38
Cc: "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:08:22 -0000

--001a11c3db7477c2a704e9f85e38
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy)  wrote:

>
> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote:
>
> > That is only as long as the binary versions don't have any additions or
> changes for such things.  Nothing says that the binary modules cannot be
> built in this way.
>
> The binary module will be build that way.
>
> All the build scripts etc that Cisco uses will be part of the open source
> project so that anyone can build it them selves and check that their build
> matches the Cisco binary and check the code does not have backdoors to send
> all your video to the NSA.
>

:-)

Sorry, wasn't implying as such, but it's good to be reassured.  Thanks
again for the response.

Matthew Fredrickson


>
> >
> > Matthew Fredrickson
> >
> >
> > On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg 
> wrote:
> >
> > Lorenzo,
> >
> > You will be able to inspect the source yourself for nefarious things
> like tracking as the code will be freely available.
> >
> > -EH
> >
> >
> >
> > On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero 
> wrote:
> > Il giorno Wed, 30 Oct 2013 10:41:27 -0500
> > Adam Roach  ha scritto:
> >
> > > On 10/30/13 10:20, Matt Fredrickson wrote:
> > > > Does this mean that system information (for systems that this is
> > > > installed on) may be tracked and sent back to the Cisco servers for
> > > > accurate license usage count?  (ethernet MAC address, or some other
> > > > system specific info) so that redownloads of modules on the same
> > > > system are not counted towards your license usage accounting?
> > >
> > > My understanding is that MPEG-LA has a per-organization royalty cap
> > > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
> > > cap quite easily with their own products.
> > >
> > > /a
> >
> >
> > Which doesn't preclude the fact the module may do tracking anyway.
> >
> > Lorenzo
> >
> >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c3db7477c2a704e9f85e38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Wed, Oct 30, 2013 at 11:17 AM, Cullen Jennings (fluffy) <fluffy@=
cisco.com> wrote:




On Oct 30, 2013, at 9:55 AM, Matt Fredrickson <creslin@digium.com> wrote:



> That is only as long as the binary versions don't have any additio=
ns or changes for such things. =A0Nothing says that the binary modules cann=
ot be built in this way.




The binary module will be build that way.



All the build scripts etc that Cisco uses will be part of the open source p=
roject so that anyone can build it them selves and check that their build m=
atches the Cisco binary and check the code does not have backdoors to send =
all your video to the NSA.



:-)

Sorry, wasn&#=
39;t implying as such, but it's good to be reassured. =A0Thanks again f=
or the response.

Matthew Fredrickson=A0








>

> Matthew Fredrickson

>

>

> On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg <ethanhugg@gmail.com> wrote:

>

> Lorenzo,

>

> You will be able to inspect the source yourself for nefarious things l=
ike tracking as the code will be freely available.

>

> -EH

>

>

>

> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

> Il giorno Wed, 30 Oct 2013 10:41:27 -0500

> Adam Roach <adam@nostrum.com> ha scritto:

>

> > On 10/30/13 10:20, Matt Fredrickson wrote:

> > > Does this mean that system information (for systems that thi=
s is

> > > installed on) may be tracked and sent back to the Cisco serv=
ers for

> > > accurate license usage count? =A0(ethernet MAC address, or s=
ome other

> > > system specific info) so that redownloads of modules on the =
same

> > > system are not counted towards your license usage accounting=
?

> >

> > My understanding is that MPEG-LA has a per-organization royalty c=
ap

> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches =
that

> > cap quite easily with their own products.

> >

> > /a

>

>

> Which doesn't preclude the fact the module may do tracking anyway.=


>

> Lorenzo

>

>

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.org

> > https://www.ietf.org/mailman/listinfo/rtcweb

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb







--001a11c3db7477c2a704e9f85e38--

From metajack@gmail.com  Wed Oct 30 10:08:39 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A5911E82A3 for ; Wed, 30 Oct 2013 10:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5DWymLbmLVu for ; Wed, 30 Oct 2013 10:08:39 -0700 (PDT)
Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6211E82D4 for ; Wed, 30 Oct 2013 10:07:47 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id hu8so1126613vcb.14 for ; Wed, 30 Oct 2013 10:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vrKbx8p8R/ZL9OeX5yuwzprVoGW6EAp8DQR5gmk3PNw=; b=df6wVC76zasMOUQevP3p9YxeR/U2kuwI/5WHZ5DLRgARM73ukt5ihQPamSoD2P4SCC +xccr7H+OprsnDB5P90IqiEUnJYRi9ZUdbhJ54fi3YWUyt6vUcwUKyFd5M++PJeuCo/5 BgNHtxn0VUMt/FKVb9zWbelxANgZb+h2xMbKpTauveYUd4jBCNRktW7STd4IDL/RgH4s ib82lFTGBZVz/tEog+BarQIAxJQI6UKCWDhsnuyGRLWu5gulWeY67oavOYqlIgRGjqqU 4zf5K7KFuy7i0UAq/Xl43yc9g28mrat3/VPYPnH6fMi+tjDcGpWCzTZIxGTiLa7HZTKn OlXQ==
MIME-Version: 1.0
X-Received: by 10.52.165.131 with SMTP id yy3mr3105573vdb.25.1383152865241; Wed, 30 Oct 2013 10:07:45 -0700 (PDT)
Sender: metajack@gmail.com
Received: by 10.220.145.15 with HTTP; Wed, 30 Oct 2013 10:07:45 -0700 (PDT)
In-Reply-To: <52713962.3010201@matthew.at>
References: <52681A96.2020904@alvestrand.no> <52713962.3010201@matthew.at>
Date: Wed, 30 Oct 2013 11:07:45 -0600
X-Google-Sender-Auth: 6esdZn1gWDvpInJzkCra9hDJ8Wo
Message-ID: 
From: Jack Moffitt 
To: Matthew Kaufman 
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:08:40 -0000

>> Do we switch now, or do we give up and live with royalties forever?
>
> This is a little dramatic. One can trivially prove that every technology
> required to implement H.264 will lose the protection of the patent system in
> a finite period of time. Much, much sooner than "forever".

Selection of royalty-required codecs sets a precedent.

jack.

From derhoermi@gmx.net  Wed Oct 30 10:31:16 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7711E81F0 for ; Wed, 30 Oct 2013 10:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Level: 
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy7KllokbAO0 for ; Wed, 30 Oct 2013 10:30:43 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id A501F21E814E for ; Wed, 30 Oct 2013 10:30:17 -0700 (PDT)
Received: from netb.Speedport_W_700V ([91.35.15.221]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0M0QLp-1VwHRT3gTt-00ubDA for ; Wed, 30 Oct 2013 18:30:15 +0100
From: Bjoern Hoehrmann 
To: Matthew Kaufman 
Date: Wed, 30 Oct 2013 18:30:16 +0100
Message-ID: 
References: <52681A96.2020904@alvestrand.no> <52713962.3010201@matthew.at>
In-Reply-To: <52713962.3010201@matthew.at>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:GPem7uCj6NHgx6i6rHMLIycdSvkAYp1dI30rYFLKhRmVbITLmjR e6N5qLAh1FNkFzOn+CIDfTK5Wy9TgjKOqoouhIgXXufwMlt0SH8p08Z8T82gG82BY2ubAXN j5Ub9dTKtYVal+2emBiOouRe2omoNHpUc7qXKU8uh2LzylGoJfI7z5rjk0PSX0M4M1HNzFg 1hpW2PnBZVjqcbOjBHFfQ==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:31:16 -0000

* Matthew Kaufman wrote:
>On 10/23/2013 11:51 AM, Harald Alvestrand wrote:
>> The dominant video codec, H.264, is a royalty-required codec.
>>
>> Do we switch now, or do we give up and live with royalties forever?
>
>This is a little dramatic. One can trivially prove that every technology 
>required to implement H.264 will lose the protection of the patent 
>system in a finite period of time. Much, much sooner than "forever".

The patent systems that are enforced on this planet can trivially be
modified and term extensions are not exactly unheard of. And it seems
pretty clear to me that if we as a society switched from royality co-
decs to free ones then we would be pretty unlikely to switch back to
royality codecs in the forseeable future; if we stick with them we're
likely to pay royalities for whatever non-free codec becomes popular
next, and that process may well continue indefinitely. In this sense,
you would rather have to show that we would make "the switch" later.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From jdrosen@jdrosen.net  Wed Oct 30 10:38:05 2013
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2CC21E8133 for ; Wed, 30 Oct 2013 10:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.826
X-Spam-Level: 
X-Spam-Status: No, score=-101.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgHIWz07sPQB for ; Wed, 30 Oct 2013 10:37:56 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7B15E11E8238 for ; Wed, 30 Oct 2013 10:37:42 -0700 (PDT)
Received: from mail-pd0-f170.google.com ([209.85.192.170]:42050) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1VbZi1-0004ug-FU for rtcweb@ietf.org; Wed, 30 Oct 2013 13:37:40 -0400
Received: by mail-pd0-f170.google.com with SMTP id v10so1275126pde.15 for ; Wed, 30 Oct 2013 10:37:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NEN4IbWLS1LDIiWL/q+7qVjNx4mKjn+q2UFKbL/r0P4=; b=XNXOC5rL09foZm2KkN02/B0Pp+Ybl5QQhr8GLcUC/kTgGlkc2GVFw3spYYxgT6+o6U ob/v58X0SnmhT0RSYFxy+NBsrAh7794JKti1BbGkNrvB4a+uv0jTpkNfle6XP0PpHLht vx/RCoO/HYHh295M7wLNisuJkDu2XQ7oQ6Xu35IY94KDkix/MhvrSIWvQWqeb3LgecVZ XTcnRiaK+9Ko3EVQ/g6mycGrLHZ6Mt5tHVLdyTEQLynwaYZ8RLTGo1RWNexxf9+gVpq2 deR1pJOyLrAI+g0ac5/+LPqDE/M9iyv/G20SlFiaaLMDmvs/lZBnRexnaukG39yGE6hW biPQ==
MIME-Version: 1.0
X-Received: by 10.68.34.105 with SMTP id y9mr6389162pbi.15.1383154653763; Wed, 30 Oct 2013 10:37:33 -0700 (PDT)
Received: by 10.70.49.48 with HTTP; Wed, 30 Oct 2013 10:37:33 -0700 (PDT)
In-Reply-To: 
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <527107e5.0201430a.0aa1.ffff9b09SMTPIN_ADDED_BROKEN@mx.google.com>    <527128A7.3050101@nostrum.com> <20131030164716.3d3be136@lminiero>    
Date: Wed, 30 Oct 2013 13:37:33 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Leon Geyser 
Content-Type: multipart/alternative; boundary=bcaec520ef43cea2de04e9f8c931
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
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "Jonathan Rosenberg \(jdrosen\)" 
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 17:38:05 -0000

--bcaec520ef43cea2de04e9f8c931
Content-Type: text/plain; charset=ISO-8859-1

This covers all of the desktop platforms (Windows, Mac, Linux), and
Android, and probably others. I think thats a pretty solid set. For small
volume platforms where this doesnt work,  they can use the source code and
then we cannot cover any MPEG-LA licensing fees - but you should check the
MPEG-LA terms since they don't kick in until a certain volume is reached
anyway.


On Wed, Oct 30, 2013 at 12:42 PM, Leon Geyser  wrote:

> It is all great, but how do we solve the problem to support current or
> future platforms that don't support downloading a BLOB onto the device and
> then using it?
>
>
> On 30 October 2013 18:17, Cullen Jennings (fluffy) wrote:
>
>>
>> On Oct 30, 2013, at 9:55 AM, Matt Fredrickson  wrote:
>>
>> > That is only as long as the binary versions don't have any additions or
>> changes for such things.  Nothing says that the binary modules cannot be
>> built in this way.
>>
>> The binary module will be build that way.
>>
>> All the build scripts etc that Cisco uses will be part of the open source
>> project so that anyone can build it them selves and check that their build
>> matches the Cisco binary and check the code does not have backdoors to send
>> all your video to the NSA.
>>
>>
>> >
>> > Matthew Fredrickson
>> >
>> >
>> > On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg 
>> wrote:
>> >
>> > Lorenzo,
>> >
>> > You will be able to inspect the source yourself for nefarious things
>> like tracking as the code will be freely available.
>> >
>> > -EH
>> >
>> >
>> >
>> > On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero 
>> wrote:
>> > Il giorno Wed, 30 Oct 2013 10:41:27 -0500
>> > Adam Roach  ha scritto:
>> >
>> > > On 10/30/13 10:20, Matt Fredrickson wrote:
>> > > > Does this mean that system information (for systems that this is
>> > > > installed on) may be tracked and sent back to the Cisco servers for
>> > > > accurate license usage count?  (ethernet MAC address, or some other
>> > > > system specific info) so that redownloads of modules on the same
>> > > > system are not counted towards your license usage accounting?
>> > >
>> > > My understanding is that MPEG-LA has a per-organization royalty cap
>> > > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches that
>> > > cap quite easily with their own products.
>> > >
>> > > /a
>> >
>> >
>> > Which doesn't preclude the fact the module may do tracking anyway.
>> >
>> > Lorenzo
>> >
>> >
>> > > _______________________________________________
>> > > rtcweb mailing list
>> > > rtcweb@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> 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
>
>


-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--bcaec520ef43cea2de04e9f8c931
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


This covers all of the desktop platforms (Windows, Mac, Li=
nux), and Android, and probably others. I think thats a pretty solid set. F=
or small volume platforms where this doesnt work, =A0they can use the sourc=
e code and then we cannot cover any MPEG-LA licensing fees - but you should=
 check the MPEG-LA terms since they don't kick in until a certain volum=
e is reached anyway.=A0




On Wed, Oct 3=
0, 2013 at 12:42 PM, Leon Geyser <lgeyser@gmail.com> wrote:<=
br>


It is all great, but how do we solve the problem to suppor=
t current or future platforms that don't support downloading a BLOB ont=
o the device and then using it?






On 30 October 2013 18:17, Cullen Jennings (fluff=
y) <fluffy@cisco.com> wrote:
creslin@digium.com> wrote:



> That is only as long as the binary versions don't have any additio=
ns or changes for such things. =A0Nothing says that the binary modules cann=
ot be built in this way.




The binary module will be build that way.



All the build scripts etc that Cisco uses will be part of the open source p=
roject so that anyone can build it them selves and check that their build m=
atches the Cisco binary and check the code does not have backdoors to send =
all your video to the NSA.








>

> Matthew Fredrickson

>

>

> On Wed, Oct 30, 2013 at 10:52 AM, Ethan Hugg <ethanhugg@gmail.com> wrote:

>

> Lorenzo,

>

> You will be able to inspect the source yourself for nefarious things l=
ike tracking as the code will be freely available.

>

> -EH

>

>

>

> On Wed, Oct 30, 2013 at 8:47 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote=
:

> Il giorno Wed, 30 Oct 2013 10:41:27 -0500

> Adam Roach <a=
dam@nostrum.com> ha scritto:

>

> > On 10/30/13 10:20, Matt Fredrickson wrote:

> > > Does this mean that system information (for systems that thi=
s is

> > > installed on) may be tracked and sent back to the Cisco serv=
ers for

> > > accurate license usage count? =A0(ethernet MAC address, or s=
ome other

> > > system specific info) so that redownloads of modules on the =
same

> > > system are not counted towards your license usage accounting=
?

> >

> > My understanding is that MPEG-LA has a per-organization royalty c=
ap

> > for H.264 (13 MUSD, if my memory serves), and that Cisco reaches =
that

> > cap quite easily with their own products.

> >

> > /a

>

>

> Which doesn't preclude the fact the module may do tracking anyway.=


>

> Lorenzo

>

>

> > _______________________________________________

> > rtcweb mailing list

> > rtcweb@ietf.=
org

> > https://www.ietf.org/mailman/listinfo/rtcweb

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________

rtcweb mailing list

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