From nobody Tue Dec 1 12:47:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8691B3725 for ; Tue, 1 Dec 2015 12:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxZH-taa10Rp for ; Tue, 1 Dec 2015 12:47:24 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DDA1B3720 for ; Tue, 1 Dec 2015 12:47:24 -0800 (PST) Received: by qgea14 with SMTP id a14so16068712qge.0 for ; Tue, 01 Dec 2015 12:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Ut9A5CQeUGIvgrHBFCq3u65bDS0eZewlBs1M+3NLuMU=; b=l7/fqtXeUOnjRsYkSpyHm8shcavhyZqF5YCtY5XEJh6T34tvnf9CN5wt0lFokjAaYx ZCycLRypnJxLUK5FuBE0eS2UlrhuxdbN3YRkpQjdILHqTWZefpOtmAG/oB4qsjJxbnxm 6DwuWTbaiomRUNgfGlM/43AKKRB9qEA9v+5yKZLUvqE9SsPFzgt3f0h6EEvf1xUa8aWQ rcFWuVkCOOPKfShNo1kMJRQKKa0VARcVlEdXdXLa7Llh4xsbiq+gN9LYJhce+GPVHRbA a8QFAcNnJiYJDA4ACqriJYa9Amyz9z4uxoR2GGq5Y8EQW65Ta+LYJ5ErP8lxGo9etCXP RlCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Ut9A5CQeUGIvgrHBFCq3u65bDS0eZewlBs1M+3NLuMU=; b=LeP7o5youIyZjvhZlldbyFaFTILkOcB/U/z/YYJRAeTlO20YtOgJYHyo+9UbpNGszG GuORu2YODwJvp0/5Bk0RqV5ERom/JNLfiNi1RHEN6+jStHvinSDGBhy5iBrrfG/gWMPG xtoBrSJutZIjMqasRqLsWL43kxVcSeIocDxd+UCqK5BUoegggrz98u61fxB5as9RxPOc 7PBC8fq9bqmf4r31pMRp5b/bGtNViooxpzs3V4eaab/5kl0diZHBLp/fneEvzx0Rmza7 uk67y+pnwHN4ETc1g+D2XF87TaRbBwnGJZvsVA8PFMCROdRg62V9yo2rPtNzyY983MDt yOiw== X-Gm-Message-State: ALoCoQnfOqhtRBnyMxI13SVjOB8nb5aEJsva7KvOFCm+O63uL6WDpaGNIWSRfDZwTg394YdljQT3 X-Received: by 10.140.94.116 with SMTP id f107mr85937730qge.0.1449002843255; Tue, 01 Dec 2015 12:47:23 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id a15sm17737417qge.18.2015.12.01.12.47.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 12:47:22 -0800 (PST) To: Roman Shpount References: <564CE2F4.6060104@mozilla.com> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <565E0759.9050702@mozilla.com> Date: Tue, 1 Dec 2015 15:47:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [rtcweb] Comments regarding draft-ietf-rtcweb-audio-09 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 20:47:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Roman, On 11/19/2015 12:14 PM, Roman Shpount wrote: > My understanding was that G.711 and CN are primarily needed to > legacy interop. If browser is communicating with a legacy end point > through some sort of ICE/DTLS-SRTP gateway, then it needs to > support the same codecs as legacy endpoint. There are plenty of > legacy endpoints that support G.711 but do not support CN. Also, if > browser is communicating with some sort of non-browser service, > such as conference bridge, and if this bridge implements Opus > codec, there is no real reason to implement CN. So, what I want is > to see is that CN a MUST(or a SHOULD) for browsers only, with > gateways and non-browsers allowed to implement G.711 only, only > G.711 + CN, Opus + G.711, or all three codecs. The current text says that CN is required only for "WebRTC endpoints", i.e. the same as those who currently need to support Opus. Any legacy equipment is already excluded from the requirement. > Finally, if CN is not supported and not negotiated during call > setup, nothing bad will happen. I am not aware of any scenario > where audio call will fail to setup if CN fails to get negotiated. > So, this probably makes CN a SHOULD, not a MUST even for browsers. Lack of CN would not make call setup fail, but it seems like guaranteed presence would make it less likely to end up wasting bandwidth. Anyone else has an opinion on this? Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWXgdWAAoJEJ6/8sItn9q9YCUH/j+XwQROkVQXo+9UiG6NFztp dk+OxkZxzVxv4UUQ0XcAY/l4Y84xJbY0+bn0blMsD3KCYUqWtp4LT5u3BwMoe9b+ mfm2NyJEFh8vrY1ZUSImWO/cGbOiJV8FXqmihPJIP45KPBc9fz5fbKK5fezErayh mfSj+50lyL2mhBzS+ITC62QBSFF8fy7o0nEeuE7MsFu8wVWlvFRoinrZyb+PjsNE FGh9KZNRczyit4PIxMnJGs5EfOYxnP3k6N7NTGWRt1pcEdNCHLjqzTEAGl3+smvI hUHEctuFdNx+NETNPvkjulylEt6nXnj9NVTuN7SLIJedUvH/90O7Mhty1/8bBko= =l+Qg -----END PGP SIGNATURE----- From nobody Wed Dec 2 00:18:07 2015 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A52C1ACE10; Wed, 2 Dec 2015 00:18:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151202081805.10794.75915.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 00:18:05 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 08:18:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Additional WebRTC audio codecs for interoperability. Author : Stephane Proust Filename : draft-ietf-rtcweb-audio-codecs-for-interop-03.txt Pages : 11 Date : 2015-12-02 Abstract: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs is specified. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC clients to address the most relevant interoperability use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-codecs-for-interop-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-codecs-for-interop-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 2 06:14:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5B31A8AD6 for ; Wed, 2 Dec 2015 06:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjfGnCw48e45 for ; Wed, 2 Dec 2015 06:14:18 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47EA1A9060 for ; Wed, 2 Dec 2015 06:14:17 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-d1-565efcb74ddd Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.04.05041.7BCFE565; Wed, 2 Dec 2015 15:14:16 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Wed, 2 Dec 2015 15:13:41 +0100 To: "rtcweb@ietf.org" References: <20151202081805.10794.75915.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <565EFC94.5050707@ericsson.com> Date: Wed, 2 Dec 2015 15:13:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151202081805.10794.75915.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM2K7ru6OP3FhBnNmcVms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNdf5jEX7GWpmLwgooHxGnMXIyeHhICJxKSDB9khbDGJC/fW s3UxcnEICRxmlJj88RwLhLOMUWLvxEZWkCphAS+JU1sPgXWICKhLXH54AcwWEnCUOND9lAnE ZhOwkLj5o5ENxOYV0JY4sPgfmM0ioCLx//8DsHpRgRiJ95tWMULUCEqcnPmEBcTmFHCSWPjq BNAcDg5mAXuJB1vLQMLMAvISzVtnM0Os0pZoaOpgncAoMAtJ9yyEjllIOhYwMq9iFC1OLS7O TTcy0kstykwuLs7P08tLLdnECAy/g1t+W+1gPPjc8RCjAAejEg9vgVpcmBBrYllxZe4hRgkO ZiUR3vqnQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8zUwPQoUE0hNLUrNTUwtSi2CyTBycUg2M hjP+1/cvLag4k2C4nP2/3XZVveP/XC3lJ4kVbi1wb0kTWr48f9qbtkP5Iv2/ixU0mEy7dx7f z/+i5YuAxqqa/luB07JNDq5ef1j4WrbIoekC8stZouIMuO9bP5gRlSFZ2XwlNtUs/9OPoOiH Qfo6r94H7E3MkymtC/kT80hswu2eK+qBSwqUWIozEg21mIuKEwEetlWpOwIAAA== Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 14:14:21 -0000 Hi, I have reviewed the changes. I think they addresses the issues I raised. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Dec 2 10:06:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933781ACD36 for ; Wed, 2 Dec 2015 10:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWd_IiQIduPW for ; Wed, 2 Dec 2015 10:06:28 -0800 (PST) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D57E1ACDB9 for ; Wed, 2 Dec 2015 10:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1449079587; x=1480615587; h=from:to:cc:date:subject:message-id:mime-version; bh=H7NOA7xmiFs98cD9uoKWrSSjq4NRN0ImLoFVl/dIz8o=; b=gUB8s4J4ByW9FAIR7MJEjWPn0zqZEZoBOjCVyY1UqSNTVMvMmZCNVBZS h9ae7vTOg+XV/dqAX+BZrVmc5TNUxlg+gEA+SZocoiXD+2MyrRuEBR17s alhnTl2Fi53U1bEpTrJBrjIbLWh4/v2ty8LyuF5PEK1aIH8xtodypaBAN g=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 02 Dec 2015 18:06:19 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos; i="5.20,374,1444694400"; d="scan'208,217"; a="87658940" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 02 Dec 2015 18:06:18 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Wed, 2 Dec 2015 13:06:15 -0500 To: "stephane.proust@orange.com" Date: Wed, 2 Dec 2015 13:06:15 -0500 Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-03.txt Thread-Index: AdEtLBFuWfd/Q8siSeyXelWz1g3KzA== Message-ID: <900A1E2059ADB149B905E3C8FA0046A62CD5FFD4E6@FHDP1LUMXC7V23.us.one.verizon.com> 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_900A1E2059ADB149B905E3C8FA0046A62CD5FFD4E6FHDP1LUMXC7V2_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 18:06:30 -0000 --_000_900A1E2059ADB149B905E3C8FA0046A62CD5FFD4E6FHDP1LUMXC7V2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlcGhhbmUg4oCTIEkgcmV2aWV3ZWQgLTAzIGFuZCBoYXZlIGEgZmV3IG5pdHMuDQoNCg0K MS4gICAgICAgSW50cm9kdWN0aW9uDQoNCg0KLSAgICAgICAgICBDaGFuZ2Ug4oCcdHJhbnNjb2Rp bmdz4oCdIHRvIOKAnHRyYW5zY29kaW5n4oCdIChsYXN0IHNlbnRlbmNlKQ0KDQoNCjIuICAgICAg IFNlY3Rpb24gMw0KDQoNCi0gICAgICAgICAgQ2hhbmdlIHNlbnRlbmNlIOKAnFRoZSBkcmF3YmFj a3Mgb2Ygc3VjaCB0cmFuc2NvZGluZyBvcGVyYXRpb25zIGFyZSByZWNhbGxlZCBiZWxvd+KAnSB0 byDigJwgVGhlIGRyYXdiYWNrIG9mIHN1Y2ggdHJhbnNjb2Rpbmcgb3BlcmF0aW9ucyBhcmUgbGlz dGVkIGJlbG934oCdDQoNCi0gICAgICAgICAgMm5kIEJ1bGxldCAobGFzdCBzZW50ZW5jZSkNCg0K byAgICDigJzigKZlbmQgdG8gZW5kIGRlbGF5IGJleW9uZCBhY2NlcHRhYmxlIGxpbWl0cyBsaWtl IHdpdGggbW9yZSB0aGFuIDFzIGVuZCB0byBlbmQgbGF0ZW5jeS7igJ0gUmVtb3ZlIHVzZSBvZiDi gJxsaWtl4oCdIGluIHRoZSBzZW50ZW5jZSBhbmQgZXhwYW5kIHRoZSBzaG9ydC1oYW5kIG5vdGF0 aW9uIHdoZXJlIHlvdSB1c2Ug4oCcMXPigJ0uIElmIHlvdSBtZWFuIDEgc2Vjb25kLCBqdXN0IHNh eSBzby4NCg0KLSAgICAgICAgICAzcmQgYnVsbGV0DQoNCm8gICBDaGFuZ2Ug4oCcY29zdHMgaW4g bmV0d29ya3PigJ0gdG8g4oCcY29zdCBpbiBuZXR3b3Jrc+KAnSAodXNlZCBpbiB0d28gcGxhY2Vz KQ0KDQpvICAgQ2hhbmdlIOKAnGNvZGVjcyBsaWNlbnNl4oCdIHRvIOKAnGNvZGVjIGxpY2Vuc2Vz 4oCdDQoNCm8gICBDaGFuZ2Ug4oCcZGVwbG95bWVudHMsIHRlc3RpbmcgYW5kIHZhbGlkYXRpb24g Y29zdHPigJ0gdG8g4oCcZGVwbG95bWVudCwgdGVzdGluZyBhbmQgdmFsaWRhdGlvbiBjb3N04oCd DQoNCm8gICBDaGFuZ2Ug4oCc4oCmYmUgbW9yZSBjb3N0bHkgdGhhbiBiZXR3ZWVuIG5hcnJvd2Jh bmQgY29kZWNzLuKAnSB0byDigJxtb3JlIGNvc3RseSB0aGFuIHRyYW5zY29kaW5nIGJldHdlZW4g bmFycm93YmFuZCBjb2RlY3PigJ0NCg0KDQoNCjMuICAgICAgIFNlY3Rpb24gNA0KDQotICAgICAg ICAgIEluc3RlYWQgb2Ygd3JpdGluZyDigJzigKZyZWxldmFudCBzdWl0YWJsZeKApuKAnSwganVz dCB1c2UgZWl0aGVyIHJlbGV2YW50IG9yIHN1aXRhYmxlDQoNCg0KNC4gICAgICAgU2VjdGlvbiA0 LjEuMS4NCg0KDQotICAgICAgICAgIFJlbW92ZSDigJxsaWtl4oCdIGZyb20gdGhlIHNlbnRlbmNl IOKAnOKApnRlbGVwaG9ueSBzZXJ2aWNlcyBvdmVyIElQL0lNUyBsaWtlIGZvciB2b2ljZSBvdmVy IExUReKApuKAnQ0KDQotICAgICAgICAgIE1ha2Ug4oCcU291cmNlIGNvZGXigJ0gbG93ZXIgY2Fz ZQ0KDQoNCjUuICAgICAgIFNlY3Rpb24gNC4xLjINCg0KDQotICAgICAgICAgIENoYW5nZSDigJxo dW5kcmVkcyBvZiBkZXZpY2VzIG1vZGVsc+KAnSB0byDigJxodW5kcmVkcyBvZiBkZXZpY2UgbW9k ZWxz4oCdDQoNCi0gICAgICAgICAgQ2hhbmdlIOKAnDQ1MCBtaWxsaW9ucy7igJ0gdG8g4oCcNDUw IG1pbGxpb24u4oCdDQoNCg0KNi4gICAgICAgU2VjdGlvbiA0LjEuMw0KDQotICAgICAgICAgIDFz dCBidWxsZXQNCg0KbyAgIFBsYWNlbWVudCBvZiBjb21tYSBpcyBjb25mdXNpbmcgaW4g4oCcT2Zm ZXIgQU1SIGluIGFkZGl0aW9uIHRvIEFNUi1XQiB3aXRoIEFNUi1XQiwgYmVpbmcgYSB3aWRlYmFu ZCBjb2RlLCBsaXN0ZWQgZmlyc3TigKYg4oCcIFN1Z2dlc3QgdG8gY2hhbmdlIHNlbnRlbmNlIHRv IHNvbWV0aGluZyBsaWtlIOKAnE9mZmVyIEFNUiBpbiBhZGRpdGlvbiB0byBBTVItV0IgKEFNUi1X QiBiZWluZyBhIHdpZGViYW5kIGNvZGVjIGxpc3RlZCBmaXJzdOKApi7igJ0pDQoNCg0KNy4gICAg ICAgU2VjdGlvbiA0LjIuMQ0KDQoNCi0gICAgICAgICAgQ2hhbmdlIOKAnGkuZS7igJ0gdG8g4oCc aS5lLizigJ0NCg0KLSAgICAgICAgICBBZGQgY29tbWEgYWZ0ZXIg4oCcc3VjaCBhc+KAnSAtPiDi gJxzdWNoIGFzLCBHU01BIHZvaWNlIElNUyBwcm9maWxl4oCm4oCdDQoNCg0KOC4gICAgICAgU2Vj dGlvbiA0LjIuMg0KDQoNCi0gICAgICAgICAgQ2hhbmdlIOKAnHRoZXJlIGlz4oCdIHRvIOKAnHRo ZXJlIGFyZSBzdGlsbCBhIGhpZ2ggbnVtYmVyIG9mIGxlZ2FjeSB0ZXJtaW5hbHMg4oCm4oCdDQoN Ci0gICAgICAgICAgQ2hhbmdlIOKAnOKApm9ubHkgQU1SICh0ZXJtaW5hbHMgd2l0aCBubyB3aWRl YmFuZCAvIEhEIFZvaWNlIGNhcGFiaWxpdGllcykgYXJlIHN0aWxsIHVzZWQu4oCdIHRvIOKAnG9u bHkgQU1SICh0ZXJtaW5hbHMgd2l0aCBubyB3aWRlYmFuZC9IRCB2b2ljZSBjYXBhYmlsaXRpZXMp IHRoYXQgYXJlIHN0aWxsIGluIHVzZS7igJ0NCg0KDQo5LiAgICAgICBTZWN0aW9uIDQuMy4yDQoN Cg0KLSAgICAgICAgICBDaGFuZ2Ug4oCcMTUwIE1pbGxpb25zIHBlciB5ZWFy4oCdIHRvIOKAnDE1 MCBtaWxsaW9uIHBlciB5ZWFy4oCdDQoNCg0KMTAuICAgU2VjdGlvbiA0LjMuMw0KDQoNCi0gICAg ICAgICAgQ2hhbmdlIOKAnOKApk11bHRpbWVkaWEgVGVsZXBob255IHNlcnZpY2VzIG92ZXJzIElN U+KApuKAnSB0byDigJzigKZtdWx0aW1lZGlhIHRlbGVwaG9ueSBzZXJ2aWNlcyBvdmVyIElNU+KA puKAnQ0KDQpUaGFua3MNClNhbmpheQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAwMiwg MjAxNSAzOjE4IEFNDQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogcnRjd2ViQGlldGYu b3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRp by1jb2RlY3MtZm9yLWludGVyb3AtMDMudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0K VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUmVhbC1UaW1lIENvbW11bmljYXRpb24g aW4gV0VCLWJyb3dzZXJzIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0 bGUgICAgICAgICAgIDogQWRkaXRpb25hbCBXZWJSVEMgYXVkaW8gY29kZWNzIGZvciBpbnRlcm9w ZXJhYmlsaXR5Lg0KICAgICAgICBBdXRob3IgICAgICAgICAgOiBTdGVwaGFuZSBQcm91c3QNCiAg ICAgICAgICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby1j b2RlY3MtZm9yLWludGVyb3AtMDMudHh0DQogICAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAg IDogMTENCiAgICAgICAgICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE1LTEyLTAyDQoNCkFi c3RyYWN0Og0KICAgVG8gZW5zdXJlIGEgYmFzZWxpbmUgbGV2ZWwgb2YgaW50ZXJvcGVyYWJpbGl0 eSBiZXR3ZWVuIFdlYlJUQw0KICAgY2xpZW50cywgYSBtaW5pbXVtIHNldCBvZiByZXF1aXJlZCBj b2RlY3MgaXMgc3BlY2lmaWVkLiAgSG93ZXZlciwgdG8NCiAgIG1heGltaXplIHRoZSBwb3NzaWJp bGl0eSB0byBlc3RhYmxpc2ggdGhlIHNlc3Npb24gd2l0aG91dCB0aGUgbmVlZA0KICAgZm9yIGF1 ZGlvIHRyYW5zY29kaW5nLCBpdCBpcyBhbHNvIHJlY29tbWVuZGVkIHRvIGluY2x1ZGUgaW4gdGhl IG9mZmVyDQogICBvdGhlciBzdWl0YWJsZSBhdWRpbyBjb2RlY3MgdGhhdCBhcmUgYXZhaWxhYmxl IHRvIHRoZSBicm93c2VyLg0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIHNvbWUgZ3VpZGVs aW5lcyBvbiB0aGUgc3VpdGFibGUgY29kZWNzIHRvIGJlDQogICBjb25zaWRlcmVkIGZvciBXZWJS VEMgY2xpZW50cyB0byBhZGRyZXNzIHRoZSBtb3N0IHJlbGV2YW50DQogICBpbnRlcm9wZXJhYmls aXR5IHVzZSBjYXNlcy4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig dGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcnRjd2ViLWF1ZGlvLWNvZGVjcy1mb3ItaW50ZXJvcC8NCg0KVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tY29kZWNzLWZvci1pbnRlcm9wLTAzDQoNCkEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby1jb2RlY3MtZm9yLWlu dGVyb3AtMDMNCg== --_000_900A1E2059ADB149B905E3C8FA0046A62CD5FFD4E6FHDP1LUMXC7V2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLlRleHRl ZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHls ZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxs ZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1 bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDoxMTYzODExOTk5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczozOTk0MjYzMDYgMTc1NDAxNjM0NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxLjI1 aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuNzVpbjsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoyLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuNzVpbjsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMu NzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NC4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDo0Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNjQ4NTg1MjczOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTM0MTE2MDM4IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpIFN0ZXBoYW5lIOKAkyBJIHJldmlld2VkIC0w MyBhbmQgaGF2ZSBhIGZldyBuaXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwxIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEuPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JbnRyb2R1Y3Rpb24gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2lu LWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNo YW5nZSDigJx0cmFuc2NvZGluZ3PigJ0gdG8g4oCcdHJhbnNjb2RpbmfigJ0gKGxhc3Qgc2VudGVu Y2UpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEn PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+Mi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNlY3Rpb24gMzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHls ZT0nbWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkNoYW5nZSBzZW50ZW5jZSDigJxUaGUgZHJhd2JhY2tzIG9mIHN1Y2ggdHJhbnNjb2Rp bmcgb3BlcmF0aW9ucyBhcmUgcmVjYWxsZWQgYmVsb3figJ0gdG8g4oCcIFRoZSBkcmF3YmFjayBv ZiBzdWNoIHRyYW5zY29kaW5nIG9wZXJhdGlvbnMgYXJlIGxpc3RlZCBiZWxvd+KAnTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVm dDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1s aXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+MjxzdXA+ bmQ8L3N1cD4gQnVsbGV0IChsYXN0IHNlbnRlbmNlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjI1aW47dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPm88c3BhbiBzdHlsZT0n Zm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKg4oCc4oCmZW5kIHRvIGVu ZCBkZWxheSBiZXlvbmQgYWNjZXB0YWJsZSBsaW1pdHMgbGlrZSB3aXRoIG1vcmUgdGhhbiAxcyBl bmQgdG8gZW5kIGxhdGVuY3ku4oCdIFJlbW92ZSB1c2Ugb2Yg4oCcbGlrZeKAnSBpbiB0aGUgc2Vu dGVuY2UgYW5kIGV4cGFuZCB0aGUgc2hvcnQtaGFuZCBub3RhdGlvbiB3aGVyZSB5b3UgdXNlIOKA nDFz4oCdLiBJZiB5b3UgbWVhbiAxIHNlY29uZCwganVzdCBzYXkgc28uPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0Oi43NWlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdu b3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4zPHN1cD5yZDwvc3Vw PiBidWxsZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBz dHlsZT0nbWFyZ2luLWxlZnQ6MS4yNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz5vPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5DaGFuZ2Ug4oCcY29zdHMgaW4gbmV0d29ya3PigJ0gdG8g4oCcY29z dCBpbiBuZXR3b3Jrc+KAnSAodXNlZCBpbiB0d28gcGxhY2VzKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDoxLjI1aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPm88c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNoYW5nZSDigJxj b2RlY3MgbGljZW5zZeKAnSB0byDigJxjb2RlYyBsaWNlbnNlc+KAnSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4yNWlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5vPHNw YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyA8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DaGFuZ2Ug 4oCcZGVwbG95bWVudHMsIHRlc3RpbmcgYW5kIHZhbGlkYXRpb24gY29zdHPigJ0gdG8g4oCcZGVw bG95bWVudCwgdGVzdGluZyBhbmQgdmFsaWRhdGlvbiBjb3N04oCdPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjEuMjVpbjt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzInPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+bzxzcGFu IHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2hhbmdlIOKA nOKApmJlIG1vcmUgY29zdGx5IHRoYW4gYmV0d2VlbiBuYXJyb3diYW5kIGNvZGVjcy7igJ0gdG8g 4oCcbW9yZSBjb3N0bHkgdGhhbiB0cmFuc2NvZGluZyBiZXR3ZWVuIG5hcnJvd2JhbmQgY29kZWNz 4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9 J21hcmdpbi1sZWZ0OjEuMjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjMuPHNw YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5TZWN0aW9uIDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHls ZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkluc3RlYWQgb2Ygd3JpdGluZyDigJzigKZyZWxl dmFudCBzdWl0YWJsZeKApuKAnSwganVzdCB1c2UgZWl0aGVyIHJlbGV2YW50IG9yIHN1aXRhYmxl PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEnPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21z by1saXN0Oklnbm9yZSc+NC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNlY3Rpb24gNC4xLjEuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjI1 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0Oi43NWluO3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNw YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SZW1vdmUg4oCcbGlrZeKAnSBmcm9t IHRoZSBzZW50ZW5jZSDigJzigKZ0ZWxlcGhvbnkgc2VydmljZXMgb3ZlciBJUC9JTVMgbGlrZSBm b3Igdm9pY2Ugb3ZlciBMVEXigKbigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0n Zm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk1ha2Ug4oCcU291cmNlIGNvZGXigJ0gbG93ZXIgY2Fz ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFn cmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xJz48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPjUuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h biInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TZWN0aW9uIDQuMS4yPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0 eWxlPSdtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Q2hhbmdlIOKAnGh1bmRyZWRzIG9mIGRldmljZXMgbW9kZWxz4oCdIHRvIOKAnGh1 bmRyZWRzIG9mIGRldmljZSBtb2RlbHPigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHls ZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNoYW5nZSDigJw0NTAgbWlsbGlvbnMu4oCdIHRv IOKAnDQ1MCBtaWxsaW9uLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9y ZSc+Ni48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNlY3Rpb24gNC4xLjM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6Ljc1aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUn Pi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjE8c3VwPnN0PC9zdXA+IGJ1 bGxldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxl PSdtYXJnaW4tbGVmdDoxLjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPm88c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlBsYWNlbWVudCBvZiBjb21tYSBpcyBjb25mdXNpbmcgaW4g4oCcT2ZmZXIg QU1SIGluIGFkZGl0aW9uIHRvIEFNUi1XQiB3aXRoIEFNUi1XQiwgYmVpbmcgYSB3aWRlYmFuZCBj b2RlLCBsaXN0ZWQgZmlyc3TigKYg4oCcIFN1Z2dlc3QgdG8gY2hhbmdlIHNlbnRlbmNlIHRvIHNv bWV0aGluZyBsaWtlIOKAnE9mZmVyIEFNUiBpbiBhZGRpdGlvbiB0byBBTVItV0IgKEFNUi1XQiBi ZWluZyBhIHdpZGViYW5kIGNvZGVjIGxpc3RlZCBmaXJzdOKApi7igJ0pPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ Ny48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNlY3Rpb24gNC4yLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0 Oi43NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxp c3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DaGFuZ2Ug 4oCcaS5lLuKAnSB0byDigJxpLmUuLOKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxl PSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWRkIGNvbW1hIGFmdGVyIOKAnHN1Y2ggYXPigJ0g LSZndDsg4oCcc3VjaCBhcywgR1NNQSB2b2ljZSBJTVMgcHJvZmlsZeKApuKAnTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0n dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25v cmUnPjguPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TZWN0aW9uIDQuMi4yPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4t bGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21z by1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2hh bmdlIOKAnHRoZXJlIGlz4oCdIHRvIOKAnHRoZXJlIGFyZSBzdGlsbCBhIGhpZ2ggbnVtYmVyIG9m IGxlZ2FjeSB0ZXJtaW5hbHMg4oCm4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0Oi43NWluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DaGFuZ2Ug4oCc4oCmb25seSBBTVIgKHRlcm1pbmFs cyB3aXRoIG5vIHdpZGViYW5kIC8gSEQgVm9pY2UgY2FwYWJpbGl0aWVzKSBhcmUgc3RpbGwgdXNl ZC7igJ0gdG8g4oCcb25seSBBTVIgKHRlcm1pbmFscyB3aXRoIG5vIHdpZGViYW5kL0hEIHZvaWNl IGNhcGFiaWxpdGllcykgdGhhdCBhcmUgc3RpbGwgaW4gdXNlLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjku PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5TZWN0aW9uIDQuMy4yPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDou NzVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0 Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q2hhbmdlIOKA nDE1MCBNaWxsaW9ucyBwZXIgeWVhcuKAnSB0byDigJwxNTAgbWlsbGlvbiBwZXIgeWVhcuKAnTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFw aCBzdHlsZT0ndGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xJz48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28t bGlzdDpJZ25vcmUnPjEwLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+U2VjdGlvbiA0LjMuMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6Ljc1aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUn Pi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNoYW5nZSDigJzigKZNdWx0 aW1lZGlhIFRlbGVwaG9ueSBzZXJ2aWNlcyBvdmVycyBJTVPigKbigJ0gdG8g4oCc4oCmbXVsdGlt ZWRpYSB0ZWxlcGhvbnkgc2VydmljZXMgb3ZlciBJTVPigKbigJ08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5TYW5qYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Gcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5TZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDAyLCAyMDE1IDM6MTggQU08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VG86 IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DYzogcnRjd2ViQGlldGYub3JnPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlN1 YmplY3Q6IFtydGN3ZWJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLWNvZGVj cy1mb3ItaW50ZXJvcC0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbiBpbiBXRUItYnJvd3NlcnMgV29ya2luZyBHcm91cCBv ZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgIFRpdGxlwqDCoMKg wqDCoMKgwqDCoMKgwqAgOiBBZGRpdGlvbmFsIFdlYlJUQyBhdWRpbyBjb2RlY3MgZm9yIGludGVy b3BlcmFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgIEF1dGhvcsKgwqDCoMKgwqDCoMKgwqDC oCA6IFN0ZXBoYW5lIFByb3VzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg RmlsZW5hbWXCoMKgwqDCoMKgwqDCoCA6IGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLWNvZGVjcy1m b3ItaW50ZXJvcC0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFBh Z2VzwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAxMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgRGF0ZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAyMDE1LTEyLTAyPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoCBUbyBlbnN1cmUgYSBiYXNlbGluZSBsZXZl bCBvZiBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gV2ViUlRDPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqAgY2xpZW50cywg YSBtaW5pbXVtIHNldCBvZiByZXF1aXJlZCBjb2RlY3MgaXMgc3BlY2lmaWVkLsKgIEhvd2V2ZXIs IHRvPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPsKgwqAgbWF4aW1pemUgdGhlIHBvc3NpYmlsaXR5IHRvIGVzdGFibGlzaCB0aGUg c2Vzc2lvbiB3aXRob3V0IHRoZSBuZWVkPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqAgZm9yIGF1ZGlvIHRyYW5zY29kaW5n LCBpdCBpcyBhbHNvIHJlY29tbWVuZGVkIHRvIGluY2x1ZGUgaW4gdGhlIG9mZmVyPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKg wqAgb3RoZXIgc3VpdGFibGUgYXVkaW8gY29kZWNzIHRoYXQgYXJlIGF2YWlsYWJsZSB0byB0aGUg YnJvd3Nlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBz b21lIGd1aWRlbGluZXMgb24gdGhlIHN1aXRhYmxlIGNvZGVjcyB0byBiZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgIGNv bnNpZGVyZWQgZm9yIFdlYlJUQyBjbGllbnRzIHRvIGFkZHJlc3MgdGhlIG1vc3QgcmVsZXZhbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+wqDCoCBpbnRlcm9wZXJhYmlsaXR5IHVzZSBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1ydGN3ZWItYXVkaW8tY29kZWNzLWZvci1pbnRlcm9wLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby1jb2RlY3MtZm9yLWlu dGVyb3AtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLWNvZGVjcy1mb3ItaW50ZXJvcC0wMzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_900A1E2059ADB149B905E3C8FA0046A62CD5FFD4E6FHDP1LUMXC7V2_-- From nobody Thu Dec 3 13:46:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1515B1ACD85 for ; Thu, 3 Dec 2015 13:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA1K0nPmIKuR for ; Thu, 3 Dec 2015 13:46:24 -0800 (PST) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4581A88B8 for ; Thu, 3 Dec 2015 13:46:23 -0800 (PST) Received: from [192.168.1.43] ([38.88.216.99]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id tB3LlfPs010277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 3 Dec 2015 22:47:44 +0100 From: Philipp Hancke To: rtcweb@ietf.org Message-ID: <5660B824.7010807@goodadvice.pages.de> Date: Thu, 3 Dec 2015 13:46:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] JSEP: why is iceCandidatePoolSize an integer? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 21:46:26 -0000 I'm not sure where this has been discussed... so: why is the iceCandidatePoolSize an integer? Is the application supposed to guess (taking rtcp-mux and bundle-strategy into account) what is a good number of candidates to gather in advance? Do multiple local interfaces/candidates count toward this? Being able to specify a strategy (host/srflx/relay?) to indicate that candidates of a certain type shall be pre-gathered seems like a more direct way to accomplish the goal and would also be more transparent about the kind of resources that will be used. From nobody Thu Dec 3 20:48:37 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2E1B2D9B for ; Thu, 3 Dec 2015 20:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJeW3UFFHh5q for ; Thu, 3 Dec 2015 20:48:34 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4041B2D99 for ; Thu, 3 Dec 2015 20:48:34 -0800 (PST) Received: by ioc74 with SMTP id 74so104436565ioc.2 for ; Thu, 03 Dec 2015 20:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yjwcXYggNxvr8Pu4eRhOMMUYZ2yu38Q/l8HHMmTMOb4=; b=wFZiuNYspQ/5n8vZHRQBsmLyWeS4fUBs3UtluIRVNIkvE9kPVD1Wuthxe1OrtEybal Q2axly9ujEkegpAUJe1FdqRaN7/tmHcun6OG3EOVjH+ABdE6o+LgUrONB3zvIGisPSvH ooyMZ6OdPgFQ1tF6+9auJx89ajWfbJ0sytWQ3PwwU8TCCLZFOXs4OU8dltfzg+X04m4X MJgWXZD9J0d5gam6L7qeeSyejLiwPn1DWqzpcoK1mALEM9Q5JUlaiNTMSFA4ZFVU2d89 qhVO9BCntF3rZT+ql7LoxKJjYlGSVNXuyJudP4ptbhDijkpuFIeynyHhap1XLvCrTLE2 se0Q== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr11222696ioh.108.1449204514070; Thu, 03 Dec 2015 20:48:34 -0800 (PST) Received: by 10.36.155.139 with HTTP; Thu, 3 Dec 2015 20:48:34 -0800 (PST) In-Reply-To: <5660B824.7010807@goodadvice.pages.de> References: <5660B824.7010807@goodadvice.pages.de> Date: Fri, 4 Dec 2015 15:48:34 +1100 Message-ID: From: Martin Thomson To: Philipp Hancke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: why is iceCandidatePoolSize an integer? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 04:48:36 -0000 On 4 December 2015 at 08:46, Philipp Hancke wrote: > Is the application supposed to guess (taking rtcp-mux and bundle-strategy > into account) what is a good number of candidates to gather in advance? No, though it benefits most if it is able to make a good guess. Too high and there are candidates gathered that aren't used. Too low and gathering for those components is delayed. Note that in most cases, with trickle, aiming low is probably OK since you don't move on to a component until you have connected the first (**caveat on a bunch of things regarding trickle of course). > Do > multiple local interfaces/candidates count toward this? No, this counts components. From nobody Fri Dec 4 09:30:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7CE1A8BC1 for ; Fri, 4 Dec 2015 09:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sp2-ephZM9N for ; Fri, 4 Dec 2015 09:30:11 -0800 (PST) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5860E1A8BBF for ; Fri, 4 Dec 2015 09:30:11 -0800 (PST) Received: from [192.168.1.43] ([38.88.216.99]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id tB4HV3XV023968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Dec 2015 18:31:07 +0100 To: Martin Thomson References: <5660B824.7010807@goodadvice.pages.de> From: Philipp Hancke Message-ID: <5661CD94.2070209@goodadvice.pages.de> Date: Fri, 4 Dec 2015 09:29:56 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: why is iceCandidatePoolSize an integer? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 17:30:13 -0000 Am 03.12.2015 um 20:48 schrieb Martin Thomson: > On 4 December 2015 at 08:46, Philipp Hancke wrote: >> Is the application supposed to guess (taking rtcp-mux and bundle-strategy >> into account) what is a good number of candidates to gather in advance? > > No, though it benefits most if it is able to make a good guess. Too > high and there are candidates gathered that aren't used. Too low and > gathering for those components is delayed. Note that in most cases, > with trickle, aiming low is probably OK since you don't move on to a > component until you have connected the first (**caveat on a bunch of > things regarding trickle of course). That clears up things a bit, thanks. But if this is about components, how can the application make a decision whether to pre-gather and hold on to stun or relay candidates (which consumes resources)? >> Do >> multiple local interfaces/candidates count toward this? > > No, this counts components. Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;-) From nobody Sat Dec 5 01:40:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AD31ACEE0 for ; Sat, 5 Dec 2015 01:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRH42sRCWnWD for ; Sat, 5 Dec 2015 01:40:57 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036891ACE8E for ; Sat, 5 Dec 2015 01:40:57 -0800 (PST) Received: by igcph11 with SMTP id ph11so47883659igc.1 for ; Sat, 05 Dec 2015 01:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UKzJeLwN95u/7LmmMT1ovxM1A7E3i6Brt/R8yFul0pI=; b=v8SREmbqvHJlmdnEqlzhfM7cOFF8kwD+DUbFGNlfewBCOdOoZP9tmOVov5FgJ82i3z eQEbZYD+whbD6lpXjTdPJrMBoDNcbIXSI3aI1Wy67dQkAcUowtVb88kJqWsQG1+a6+eo MrDiUyBszc22jTQzQT4pRP8RfXtA6lL0HN0/ZFhoPEJyYzXB4ud6VcmyT8nJYG46/JJx /ww9RSRxv7DLTSBezMjIl5WIdd5fSigjwgnXQPSYXDcSZYB3MiJb8YYE9orTZpJV7MTw Stdwur7KaPElK/QB+YCxYNzmcQxicbTjNEzkjz5AgaZ88NhirZ5Cd+pEm6m/tbUE+Hxl Rsog== MIME-Version: 1.0 X-Received: by 10.50.43.234 with SMTP id z10mr8517972igl.58.1449308456446; Sat, 05 Dec 2015 01:40:56 -0800 (PST) Received: by 10.36.155.139 with HTTP; Sat, 5 Dec 2015 01:40:56 -0800 (PST) In-Reply-To: <5661CD94.2070209@goodadvice.pages.de> References: <5660B824.7010807@goodadvice.pages.de> <5661CD94.2070209@goodadvice.pages.de> Date: Sat, 5 Dec 2015 20:40:56 +1100 Message-ID: From: Martin Thomson To: Philipp Hancke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: why is iceCandidatePoolSize an integer? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 05 Dec 2015 09:40:58 -0000 On 5 December 2015 at 04:29, Philipp Hancke wrote: > But if this is about components, how can the application make a decision > whether to pre-gather and hold on to stun or relay candidates (which > consumes resources)? The application might be able to defer the gathering of candidates via relays (I don't think that STUN is a real resource concern) by only providing the relays as stun URIs, or not providing them at all, then updating the iceServers with setConfiguration. I don't know if this is something that would work, we'd have to spec that. I'm actually beginning to question the utility of the pre-warming thing. Maybe it's a performance gain, but it's certainly quite complex. >> No, this counts components. > > > Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;-) Yeah, I'm sure that - given it's current level of interoperability (i.e., zero) - the working group might be receptive to suggestions of a more accurate name. From nobody Thu Dec 10 14:14:19 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD0E1B2C93 for ; Thu, 10 Dec 2015 14:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9Y6kb_09Slw for ; Thu, 10 Dec 2015 14:14:16 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A96F1B2C95 for ; Thu, 10 Dec 2015 14:14:16 -0800 (PST) Received: by qgcc31 with SMTP id c31so167146237qgc.3 for ; Thu, 10 Dec 2015 14:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8slf4pPTM4/mAszTtRi7n5WraLbtsbK5XCOta/BvbV0=; b=bzsu5KewS835NNs+En1k/QBhweXRq6skJsTNKef1nKxcwhQdoNUol9xlcTkAh2BMF4 UDY0XCa0ujfEjy3C87HxMdlVwEqxzXw6vYd+3Ja7S0irDY0bZ5MI85fX2DuCQgTKt2Pq PlNPYyEXYQRScV5UVYljLdpGsOvabTVGH017QI3Efs8QD8G55pYjsY7gQqBKuZtX7HxX yfYoYwniOF2IbMZ9tTBFnSY2xxDrJ5VhbzG4XrDJLMeFzP7Bmpxg8uW5NlaugYnnbOMJ ZskxLKsxEOxJem5FcZZ82gApIvFD64AZgAFhz2HD1KV9CWwGqZ/IrHE4+IpB10uMGWiY Y3cA== MIME-Version: 1.0 X-Received: by 10.55.75.212 with SMTP id y203mr18588469qka.20.1449785655240; Thu, 10 Dec 2015 14:14:15 -0800 (PST) Received: by 10.55.14.211 with HTTP; Thu, 10 Dec 2015 14:14:15 -0800 (PST) Date: Thu, 10 Dec 2015 14:14:15 -0800 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114a980cfb32c805269286de Archived-At: Subject: [rtcweb] Proposed resolution on comfort noise X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 22:14:18 -0000 --001a114a980cfb32c805269286de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable After reading the discussion on the comfort noise issue, it appears that one way forward might be to adjust this language: "comfort noise (CN). Receivers MUST support RFC3389 CN for streams encoded with G.711 or any other supported codec that does not provide its own CN.= =E2=80=9D to say instead "comfort noise (CN). WebRTC endpoints MUST support RFC3389 CN for streams encoded with G.711 or any other supported codec that does not provide its own CN.=E2=80=9D This would still allow non-WebRTC endpoints to omit CN support, while retaining the mandate for WebRTC endpoints. Does this resolve the issue? regards, Ted --001a114a980cfb32c805269286de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After reading the discussion on the comfort nois= e issue, it appears that one way forward might be to adjust this language:<= br>
"comfort noise (CN).=C2=A0 Receivers MUST support RFC3389 CN fo= r streams encoded with G.711 or any other supported codec that =C2=A0does n= ot provide its own CN.=E2=80=9D

to say instead

"comf= ort noise (CN).=C2=A0 WebRTC endpoints MUST support RFC3389 CN for streams = encoded with G.711 or any other supported codec that =C2=A0does not provide= its own CN.=E2=80=9D

This would still allow non-Web= RTC endpoints to omit CN support, while retaining the mandate for WebRTC en= dpoints.

Does this resolve the issue?

<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz= e:small">regards,

Ted
--001a114a980cfb32c805269286de-- From nobody Thu Dec 10 14:25:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB3D1A86DD for ; Thu, 10 Dec 2015 14:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIB2JizV5qb1 for ; Thu, 10 Dec 2015 14:25:56 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BA21A6FF9 for ; Thu, 10 Dec 2015 14:25:56 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id g19so28042671igv.1 for ; Thu, 10 Dec 2015 14:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=35YyD2eOPkW9UayQI/shqn1OuHpbaMfVzd8pfpyoEek=; b=YVkJwaQzZomgm8pWuKOPRc9Tcegb6sQYjyg/FT4V4sHhR2PqzQGRrRfpDP4I4Z+poh 27+6u7TOwTT9W2C+AAdUhyJispGXoJE1EvAvoLkIBJhZAq/GNXqPxCAHj2yVVL/ecjkj 1rn7AXufokpDNsRfdJXVXxDpy0lroFFfOEhweV3rvJCXXhLswp/mRTmHRRUNQTjGXcFh PJ1vAcnD9JDZfV7WjYYOO5myA0oW7dACQdAjK2SsGrLh4mSWOyTlOwAngN1O4PR483z9 /7yOAIJ+F6BSAvprXlfTaRju3jcIF1HVqKzMBN6UM16+jQ7BWwb5hQN04hQHt36F46dV WbXw== 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=35YyD2eOPkW9UayQI/shqn1OuHpbaMfVzd8pfpyoEek=; b=RKgoCCF730IKLnfzCCquSpEiFerp9x07iue/OvaVvonbYVC+DJZm4nnFQD3NRZbA5q GTfyU60/cAyhxjEoMgZbEBUrY/JQzF3WRVjw3heQI5MmMm4DIQ5tuF9fN7f+jPBdtmbQ jv3TAEdNw7/Wo3u216pD5iiTnHq3pMKT4pXBJwvbuRqZX0JJbDRu6xpmyeDWRDqEegWB opYE7Nntmz8mdflBAwa9QRb+wciMG7s+p10SdxNfj1il+m/AGPusJORA2XnLBBC18Xk0 v6WZeJHwaXDc9LJTZHBvX4HhvME5Cs+p8zgXr+h/C74hOLJhjFIjMqjInXtMXjjxm8hP qEdQ== X-Gm-Message-State: ALoCoQnuBnZPnl/1guUv400lQw9o7Rw1aUmOcF0fHa4Ef6twjI50NZb8IPfhJR/0yeQnbIuGtFkKOs9g1GDzzPBIqc7d375WRg== X-Received: by 10.50.78.101 with SMTP id a5mr1478662igx.42.1449786355520; Thu, 10 Dec 2015 14:25:55 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id f78sm5883171iod.4.2015.12.10.14.25.54 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Dec 2015 14:25:54 -0800 (PST) Received: by igcto18 with SMTP id to18so26048044igc.0 for ; Thu, 10 Dec 2015 14:25:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.65.8 with SMTP id t8mr1522059igs.96.1449786354197; Thu, 10 Dec 2015 14:25:54 -0800 (PST) Received: by 10.36.205.4 with HTTP; Thu, 10 Dec 2015 14:25:54 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Dec 2015 17:25:54 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7b3a96c2a46eef052692b091 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed resolution on comfort noise X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 22:25:57 -0000 --047d7b3a96c2a46eef052692b091 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This resolves the CN issue for me. _____________ Roman Shpount On Thu, Dec 10, 2015 at 5:14 PM, Ted Hardie wrote: > After reading the discussion on the comfort noise issue, it appears that > one way forward might be to adjust this language: > > "comfort noise (CN). Receivers MUST support RFC3389 CN for streams > encoded with G.711 or any other supported codec that does not provide it= s > own CN.=E2=80=9D > > to say instead > > "comfort noise (CN). WebRTC endpoints MUST support RFC3389 CN for stream= s > encoded with G.711 or any other supported codec that does not provide it= s > own CN.=E2=80=9D > > This would still allow non-WebRTC endpoints to omit CN support, while > retaining the mandate for WebRTC endpoints. > > Does this resolve the issue? > > regards, > > Ted > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b3a96c2a46eef052692b091 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This resolves the CN issue for me.

____________= _
Roman Shpount

On Thu, Dec 10, 2015 at 5:14 PM, Ted Hardie = <ted.ietf@gmail.com> wrote:
After reading the discussion on the comfort n= oise issue, it appears that one way forward might be to adjust this languag= e:

"comfort noise (CN).=C2=A0 Receivers MUST support RFC3389 CN= for streams encoded with G.711 or any other supported codec that =C2=A0doe= s not provide its own CN.=E2=80=9D

to say instead

"com= fort noise (CN).=C2=A0 WebRTC endpoints MUST support RFC3389 CN for streams= encoded with G.711 or any other supported codec that =C2=A0does not provid= e its own CN.=E2=80=9D

This would still allow non-We= bRTC endpoints to omit CN support, while retaining the mandate for WebRTC e= ndpoints.

Does this resolve the issue?

=
regards,

Ted

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


--047d7b3a96c2a46eef052692b091-- From nobody Thu Dec 10 20:43:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F62A1A6F7C for ; Thu, 10 Dec 2015 20:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwMxpCOxtOpB for ; Thu, 10 Dec 2015 20:42:53 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0056.outbound.protection.outlook.com [65.55.169.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85831A6F8C for ; Thu, 10 Dec 2015 20:42:42 -0800 (PST) Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (10.161.161.153) by CY1PR0501MB1577.namprd05.prod.outlook.com (10.161.161.151) with Microsoft SMTP Server (TLS) id 15.1.355.16; Fri, 11 Dec 2015 04:42:40 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([10.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([10.161.161.153]) with mapi id 15.01.0355.012; Fri, 11 Dec 2015 04:42:40 +0000 From: "Wyss, Felix" To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Proposed resolution on comfort noise Thread-Index: AQHRM5gguMPNxxZdtkqRIybRsdSDNJ7FLhlQ Date: Fri, 11 Dec 2015 04:42:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Felix.Wyss@inin.com; x-originating-ip: [107.147.21.105] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1577; 5:NKGDooy7LOdJ5yQ8trStVpmVEhCj1c8oF6gDUAm2jBjtTEaxCj7cxDgYPsrmRYvxld7DAoygcJrCGi5fN8LP4Dqg3miChQEJzMliPh9jd5yHVY6XDe46BpQ3pHresosPbMnu64Pn9JqIXdB06JyImg==; 24:s7tsIpVpcv8NyhHCQL8vqsdxYTgvGmxrR9UVdEszeYaQTZiC+NOogAckD8Cr3hXibP0yhnqIsd90dMUESJW461cxWB94N6NjxHtSWuZgY+U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1577; inin-located: Inside the organization x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1577; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1577; x-forefront-prvs: 0787459938 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(164054003)(189002)(81156007)(2900100001)(19625215002)(77096005)(15975445007)(11100500001)(86362001)(50986999)(76176999)(33656002)(92566002)(54356999)(2950100001)(101416001)(106116001)(97736004)(87936001)(16236675004)(105586002)(40100003)(122556002)(66066001)(99286002)(106356001)(5004730100002)(74316001)(586003)(2501003)(5002640100001)(5003600100002)(790700001)(107886002)(3846002)(10400500002)(1220700001)(189998001)(5001770100001)(5008740100001)(6116002)(102836003)(5001960100002)(19580405001)(1096002)(76576001)(19300405004)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1577; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: inin.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB157912F2B664BE685D8B3AD7EBEA0CY1PR0501MB1579_" MIME-Version: 1.0 X-OriginatorOrg: inin.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2015 04:42:40.6930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8d07eb62-a903-4bae-bcc2-66c244e76b27 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1577 Archived-At: Subject: Re: [rtcweb] Proposed resolution on comfort noise X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 04:43:22 -0000 --_000_CY1PR0501MB157912F2B664BE685D8B3AD7EBEA0CY1PR0501MB1579_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFsbHkgZG9u4oCZdCBzZWUgd2h5IHRoaXMgbmVlZHMgdG8gYmUgYSBNVVNULiAgQXMgb2Zm ZXJlciBJIHNob3VsZCBiZSBhYmxlIHRvIG5vdCBvZmZlciBDTiBhbmQgYWxzbyByZWplY3QgaXQg YXMgYW5zd2VyZXIuICBXaGV0aGVyIHRvIHN1cHBvcnQgYW5kL29yIGVuYWJsZSBDTiBzaG91bGQg YmUgYXQgdGhlIGVhY2ggZW5kcG9pbnTigJlzIGRpc2NyZXRpb27igJR1c3VhbGx5IGJhc2VkIG9u IHN5c3RlbSBjb25maWd1cmF0aW9uL3VzZXIgcHJlZmVyZW5jZS4gIERUWCB0ZW5kcyB0byByZXN1 bHQgaW4gYSBwb29yZXIgdXNlciBleHBlcmllbmNlIGR1ZSB0byBub3RpY2VhYmxlIGRpc2NvbnRp bnVpdGllcyBhbmQgYXJ0aWZhY3RzIGF0IHRoZSB0cmFuc2l0aW9uIGJldHdlZW4gZ2VudWluZSBi YWNrZ3JvdW5kIG5vaXNlIGFuZCBjb21mb3J0IG5vaXNlIGFuZCBtYXkgbWlzcyBzcGVlY2ggb25z ZXQuICBTbyBhbiBlbmRwb2ludCB0aGF0IGRvZXNu4oCZdCB3YW50IHRvIHByb3ZpZGUgQ04gc3Vw cG9ydCBiZWNhdXNlIG9mIHVzZXIgcHJlZmVyZW5jZSBzaG91bGQgbm90IGF1dG9tYXRpY2FsbHkg YmUgbm9uLWNvbmZvcm1pbmcuICBJIGZyYW5rbHkgdGhpbmsgdGhlcmUgaXMgbGl0dGxlIHZhbHVl IHRvIENOIGFuZCB3b3VsZCByYXRoZXIgbWFrZSBpdCBvcHRpb25hbCBvciBsZWF2ZSBpdCBvdXQg YWx0b2dldGhlci4gIFNob3VsZCB0aGUgV2ViUlRDIHNwZWMgcmVhbGx5IGJlIGJ1cmRlbmVkIHdp dGggdGhpcyBraW5kIG9mIGxlZ2FjeSBjcnVmdD8gIElmIHNvbWVib2R5IGlzIGNvbmNlcm5lZCBh Ym91dCBiYW5kd2lkdGgsIHRoZXkgc2hvdWxkIGJlIHVzaW5nIE9wdXMgYW5kIG5vdCBHLjcxMS4N Cg0KVGhhbmtzLA0KLS1GZWxpeA0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciAxMCwgMjAxNSAxNzoxNA0KVG86IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogW3J0Y3dl Yl0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvbiBjb21mb3J0IG5vaXNlDQoNCkFmdGVyIHJlYWRpbmcg dGhlIGRpc2N1c3Npb24gb24gdGhlIGNvbWZvcnQgbm9pc2UgaXNzdWUsIGl0IGFwcGVhcnMgdGhh dCBvbmUgd2F5IGZvcndhcmQgbWlnaHQgYmUgdG8gYWRqdXN0IHRoaXMgbGFuZ3VhZ2U6DQoNCiJj b21mb3J0IG5vaXNlIChDTikuICBSZWNlaXZlcnMgTVVTVCBzdXBwb3J0IFJGQzMzODkgQ04gZm9y IHN0cmVhbXMgZW5jb2RlZCB3aXRoIEcuNzExIG9yIGFueSBvdGhlciBzdXBwb3J0ZWQgY29kZWMg dGhhdCAgZG9lcyBub3QgcHJvdmlkZSBpdHMgb3duIENOLuKAnQ0KDQp0byBzYXkgaW5zdGVhZA0K DQoiY29tZm9ydCBub2lzZSAoQ04pLiAgV2ViUlRDIGVuZHBvaW50cyBNVVNUIHN1cHBvcnQgUkZD MzM4OSBDTiBmb3Igc3RyZWFtcyBlbmNvZGVkIHdpdGggRy43MTEgb3IgYW55IG90aGVyIHN1cHBv cnRlZCBjb2RlYyB0aGF0ICBkb2VzIG5vdCBwcm92aWRlIGl0cyBvd24gQ04u4oCdDQpUaGlzIHdv dWxkIHN0aWxsIGFsbG93IG5vbi1XZWJSVEMgZW5kcG9pbnRzIHRvIG9taXQgQ04gc3VwcG9ydCwg d2hpbGUgcmV0YWluaW5nIHRoZSBtYW5kYXRlIGZvciBXZWJSVEMgZW5kcG9pbnRzLg0KRG9lcyB0 aGlzIHJlc29sdmUgdGhlIGlzc3VlPw0KcmVnYXJkcywNClRlZA0K --_000_CY1PR0501MB157912F2B664BE685D8B3AD7EBEA0CY1PR0501MB1579_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSByZWFs bHkgZG9u4oCZdCBzZWUgd2h5IHRoaXMgbmVlZHMgdG8gYmUgYSBNVVNULiZuYnNwOyBBcyBvZmZl cmVyIEkgc2hvdWxkIGJlIGFibGUgdG8gbm90IG9mZmVyIENOIGFuZCBhbHNvIHJlamVjdCBpdCBh cyBhbnN3ZXJlci4mbmJzcDsgV2hldGhlciB0byBzdXBwb3J0IGFuZC9vciBlbmFibGUNCiBDTiBz aG91bGQgYmUgYXQgdGhlIGVhY2ggZW5kcG9pbnTigJlzIGRpc2NyZXRpb27igJR1c3VhbGx5IGJh c2VkIG9uIHN5c3RlbSBjb25maWd1cmF0aW9uL3VzZXIgcHJlZmVyZW5jZS4mbmJzcDsgRFRYIHRl bmRzIHRvIHJlc3VsdCBpbiBhIHBvb3JlciB1c2VyIGV4cGVyaWVuY2UgZHVlIHRvIG5vdGljZWFi bGUgZGlzY29udGludWl0aWVzIGFuZCBhcnRpZmFjdHMgYXQgdGhlIHRyYW5zaXRpb24gYmV0d2Vl biBnZW51aW5lIGJhY2tncm91bmQgbm9pc2UgYW5kIGNvbWZvcnQNCiBub2lzZSBhbmQgbWF5IG1p c3Mgc3BlZWNoIG9uc2V0LiAmbmJzcDtTbyBhbiBlbmRwb2ludCB0aGF0IGRvZXNu4oCZdCB3YW50 IHRvIHByb3ZpZGUgQ04gc3VwcG9ydCBiZWNhdXNlIG9mIHVzZXIgcHJlZmVyZW5jZSBzaG91bGQg bm90IGF1dG9tYXRpY2FsbHkgYmUgbm9uLWNvbmZvcm1pbmcuICZuYnNwO0kgZnJhbmtseSB0aGlu ayB0aGVyZSBpcyBsaXR0bGUgdmFsdWUgdG8gQ04gYW5kIHdvdWxkIHJhdGhlciBtYWtlIGl0IG9w dGlvbmFsIG9yIGxlYXZlIGl0IG91dCBhbHRvZ2V0aGVyLiZuYnNwOw0KIFNob3VsZCB0aGUgV2Vi UlRDIHNwZWMgcmVhbGx5IGJlIGJ1cmRlbmVkIHdpdGggdGhpcyBraW5kIG9mIGxlZ2FjeSBjcnVm dD8mbmJzcDsgSWYgc29tZWJvZHkgaXMgY29uY2VybmVkIGFib3V0IGJhbmR3aWR0aCwgdGhleSBz aG91bGQgYmUgdXNpbmcgT3B1cyBhbmQgbm90IEcuNzExLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLUZlbGl4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlRlZCBIYXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2Vt YmVyIDEwLCAyMDE1IDE3OjE0PGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvbiBjb21mb3J0IG5v aXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+QWZ0ZXIgcmVhZGluZyB0aGUgZGlz Y3Vzc2lvbiBvbiB0aGUgY29tZm9ydCBub2lzZSBpc3N1ZSwgaXQgYXBwZWFycyB0aGF0IG9uZSB3 YXkgZm9yd2FyZCBtaWdodCBiZSB0byBhZGp1c3QgdGhpcyBsYW5ndWFnZTo8YnI+DQo8YnI+DQom cXVvdDtjb21mb3J0IG5vaXNlIChDTikuJm5ic3A7IFJlY2VpdmVycyBNVVNUIHN1cHBvcnQgUkZD MzM4OSBDTiBmb3Igc3RyZWFtcyBlbmNvZGVkIHdpdGggRy43MTEgb3IgYW55IG90aGVyIHN1cHBv cnRlZCBjb2RlYyB0aGF0ICZuYnNwO2RvZXMgbm90IHByb3ZpZGUgaXRzIG93biBDTi7igJ08YnI+ DQo8YnI+DQp0byBzYXkgaW5zdGVhZDxicj4NCjxicj4NCiZxdW90O2NvbWZvcnQgbm9pc2UgKENO KS4mbmJzcDsgV2ViUlRDIGVuZHBvaW50cyBNVVNUIHN1cHBvcnQgUkZDMzM4OSBDTiBmb3Igc3Ry ZWFtcyBlbmNvZGVkIHdpdGggRy43MTEgb3IgYW55IG90aGVyIHN1cHBvcnRlZCBjb2RlYyB0aGF0 ICZuYnNwO2RvZXMgbm90IHByb3ZpZGUgaXRzIG93biBDTi7igJ08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZiI+VGhpcyB3b3VsZCBzdGlsbCBhbGxvdyBub24tV2ViUlRDIGVuZHBvaW50cyB0 byBvbWl0IENOIHN1cHBvcnQsIHdoaWxlIHJldGFpbmluZyB0aGUgbWFuZGF0ZSBmb3IgV2ViUlRD IGVuZHBvaW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RG9lcyB0aGlzIHJlc29s dmUgdGhlIGlzc3VlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5yZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+VGVk PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0501MB157912F2B664BE685D8B3AD7EBEA0CY1PR0501MB1579_-- From nobody Thu Dec 10 21:13:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3331A8709 for ; Thu, 10 Dec 2015 21:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4FeH-StkmrU for ; Thu, 10 Dec 2015 21:13:47 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F15F1A86FC for ; Thu, 10 Dec 2015 21:13:47 -0800 (PST) Received: by qgec40 with SMTP id c40so182912636qge.2 for ; Thu, 10 Dec 2015 21:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=kgPIj2G0CD+YAh0+7sxYnWIse3SAOEI2pHfE6G9yCYU=; b=DJRFQSeNCItILpv0bmmH2LAsVOYjK9zJZ71/bHBV5moygJpiFq88j3R5k8yVQZANH0 w7fD4wZtIwt8I491SO8aP32tD+VcEl2+Oenx6WNjbrq3FQQQsR0pn5IkqDX3MpdS7Gqm RujWY+RqXH1Z42LuizyuKjy+sFXqppJsRn5QloCScRYfSPtes5haE1QMRvkfpOsmNlL3 8sh7SvjWG2h7Ixz/aVV+TNpZJ0Z3PMTDpwgIxeX8Zx/sb3BEqBxh/cTKzfze7eV3YmWf eM23EVhslsTeyfcNXwI5wUiD97WaRJ3y3fG9k/F9IBpckFVtEBeR4GUS0KG4/bghoq+e wGNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=kgPIj2G0CD+YAh0+7sxYnWIse3SAOEI2pHfE6G9yCYU=; b=Cjk+XKHppJh5OIaf/6NvmUiBlcxob6zX7WET83HFxsphSwvO1loM4It+jZsnhcC9ZQ a+hMS77KnnypTlwmKNDMRktm3Exdl0c1BexiT/YLkSB7ohwZ7gD4vow5KyTNTCWcT/X1 vFC43rSioHbT+nQzrNzT2+HE65cWJCWF6rfKOkFS/kHUqmzPsU8UzlpSGbDkKKME3Dgh 3TAoJK+Q+K7GyqHSRUuDJ/pNLDjvkZAOeCt0zh+Q00Zc/Nw12SiXI8ijr0SApUPPdzQK yXA8q0GPFwSDAg16J+QBctghyxlteqwNK9LKY42brnaEOuj3fds4Zp10ohZbJdoeZplM 93aQ== X-Gm-Message-State: ALoCoQkqci9CdPDH6bwjIMnlzffI46/IbjFDOS6wyU1/yRibLhqKt77mBD9jTCXK/jA1K7/xhOFXB4pW2irp0xfXHuwKLiPeXQ== X-Received: by 10.55.78.150 with SMTP id c144mr20619340qkb.72.1449810826578; Thu, 10 Dec 2015 21:13:46 -0800 (PST) Received: from panoramix.jmvalin.ca ([207.190.10.41]) by smtp.gmail.com with ESMTPSA id x129sm7519261qhc.33.2015.12.10.21.13.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Dec 2015 21:13:45 -0800 (PST) To: Ted Hardie , "rtcweb@ietf.org" References: From: Jean-Marc Valin Message-ID: <566A5B88.2090606@mozilla.com> Date: Fri, 11 Dec 2015 00:13:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Proposed resolution on comfort noise X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 05:13:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I agree with the proposed text. Cheers, Jean-Marc On 12/10/2015 05:14 PM, Ted Hardie wrote: > After reading the discussion on the comfort noise issue, it appears > that one way forward might be to adjust this language: > > "comfort noise (CN). Receivers MUST support RFC3389 CN for > streams encoded with G.711 or any other supported codec that does > not provide its own CN.” > > to say instead > > "comfort noise (CN). WebRTC endpoints MUST support RFC3389 CN for > streams encoded with G.711 or any other supported codec that does > not provide its own CN.” > > This would still allow non-WebRTC endpoints to omit CN support, > while retaining the mandate for WebRTC endpoints. > > Does this resolve the issue? > > regards, > > Ted > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWaluIAAoJEJ6/8sItn9q9asUIAJ9gUZOHNF27XZzLCGmgbV3O 8htGNqboo0UKkSgQdX2eJ9qWlcGr3e1MtfXSz3nSLsB4No4vnPgbdIxo/lpeT4lg tgxkZyfJB64O2QAfZ2wg3yWrW7A1xW3ne2Ru5UwTJtZMpe3Yl1u5df6GGeK/CbfI 7EfnwveegzEmAaO54K8GggNK82Y5gxeRb4tbuMFU+MXDgUtUoGENfRey8aZpG1Sl CZCwGXPG+cSdlzfzXdMT/ECPSsIuWDHmPlfqPMkf5xIKnawCfSvhtjDz5VDkkKik GZXAqu7trl1NYaR7DhAAQmjiFRLd9fPNq/e8dyvM+CM7DM65ujhSiJjzqN28Gqk= =NokM -----END PGP SIGNATURE----- From nobody Fri Dec 11 01:31:25 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59E71ACE87; Fri, 11 Dec 2015 01:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa53lEte44a9; Fri, 11 Dec 2015 01:31:21 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF49C1ACE88; Fri, 11 Dec 2015 01:31:20 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-d8-566a97e6e994 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F1.14.04914.6E79A665; Fri, 11 Dec 2015 10:31:19 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.248.2; Fri, 11 Dec 2015 10:30:48 +0100 To: IETF AVTCore WG References: <5638496B.3040009@ericsson.com> From: Magnus Westerlund Message-ID: <566A97C6.5020004@ericsson.com> Date: Fri, 11 Dec 2015 10:30:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5638496B.3040009@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2J7iO7z6VlhBl/mMFm87FnJbnFj8wIm i9U3P7BZrP3Xzu7A4rFkyU8mjy+XP7MFMEVx2aSk5mSWpRbp2yVwZby7tJW54CV/xeUr71kb GH/wdDFyckgImEj8XDmTDcIWk7hwbz2QzcUhJHCYUeLtqfWsEM5yRoltrV0sIFXCAiESK+6t BOsQEVCS2DFpGzOILSSgLbH/7QVWEJtZoFRi/d0pTCA2m4CFxM0fjWD1vEA1h162AsU5OFgE VCW2vI8GCYsKxEg8XryVFaJEUOLkzCdgqzgFdCS+XWlgAylnFrCXeLC1DGK6vETz1tlwWxua OlgnMArOQtI9C6FjFpKOBYzMqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECw/fglt+6OxhX v3Y8xCjAwajEw2tgkxUmxJpYVlyZe4hRgoNZSYT34hSgEG9KYmVValF+fFFpTmrxIUZpDhYl cd4WpgehQgLpiSWp2ampBalFMFkmDk6pBkaFMJ+f/y1Z3klP/++7QGzWC2uGpQ9inbR1Xus8 f7Qpa0J9vdbJyTEJfB9ZJGPvi2yaXHFzisMhPwuG2t7Yw4prWGsu6z7mf6sYdTo0dYnEv423 1t2/+pW/mTtZ1WjC4sM1nWFdZTqP/dNrtjWuigvunhf3zv1p0iUNhsLQ73cUVs4Lfim0aIcS S3FGoqEWc1FxIgABoQc1WwIAAA== Archived-At: Cc: rmcat@ietf.org, "rtcweb@ietf.org" , draft-ietf-avtcore-rtp-circuit-breakers@tools.ietf.org Subject: Re: [rtcweb] [AVTCORE] WG last call for draft-ietf-avtcore-rtp-circuit-breakers-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 09:31:23 -0000 Hi, There is now only 5 more days until this WG last call ends. Please provide your comments. Cheers Magnus Westerlund AVTCORE WG Chair Den 2015-11-03 kl. 06:43, skrev Magnus Westerlund: > WG, > (CC RMCAT and RTCWEB) > > This starts the 6 week WG last call on "Multimedia Congestion Control: > Circuit Breakers for Unicast RTP Sessions" > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > > We are doing a 6 week last call to give people time to review and > perform verification of the latest updates also in implementations and > simulations. > > Please provide feedback not later than 16th of December. We appreciate > all type of messages, even short, "read it, and have no comments". We > appreciate even more people that has performed any type of verification > of the solution. > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287" > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Dec 11 07:11:15 2015 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9BB1B2A17; Fri, 11 Dec 2015 07:11:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151211151108.7645.62729.idtracker@ietfa.amsl.com> Date: Fri, 11 Dec 2015 07:11:08 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 15:11:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Additional WebRTC audio codecs for interoperability. Author : Stephane Proust Filename : draft-ietf-rtcweb-audio-codecs-for-interop-04.txt Pages : 11 Date : 2015-12-11 Abstract: To ensure a baseline level of interoperability between WebRTC clients, a minimum set of required codecs is specified. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC clients to address the most relevant interoperability use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-codecs-for-interop-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-codecs-for-interop-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 11 08:36:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4331B2CFD for ; Fri, 11 Dec 2015 08:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjGeSn-Tiyzz for ; Fri, 11 Dec 2015 08:36:18 -0800 (PST) Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37B11B2CEF for ; Fri, 11 Dec 2015 08:36:17 -0800 (PST) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EFA62380CD7; Fri, 11 Dec 2015 11:36:16 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 38C7D380D43; Fri, 11 Dec 2015 11:36:16 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Fri, 11 Dec 2015 11:36:16 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Cullen Jennings In-Reply-To: Date: Fri, 11 Dec 2015 09:36:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <61F52659-1133-4C9A-A058-FC4326B3B9E7@iii.ca> References: To: "Wyss, Felix" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed resolution on comfort noise X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 16:36:22 -0000 Felix, just as background on this... one of the reasons people wanted CN = is that for many audio only calls, it roughly halfs the bandwidth. And = for conference calls it often cuts the upstream bandwidth by much more = than that. The text proposed here does not require and conference = bridge, endpoint, or GW to support this as they don't have to RTCWeb = Endpoints. > On Dec 10, 2015, at 9:42 PM, Wyss, Felix wrote: >=20 > I really don=E2=80=99t see why this needs to be a MUST. As offerer I = should be able to not offer CN and also reject it as answerer. Whether = to support and/or enable CN should be at the each endpoint=E2=80=99s = discretion=E2=80=94usually based on system configuration/user = preference. DTX tends to result in a poorer user experience due to = noticeable discontinuities and artifacts at the transition between = genuine background noise and comfort noise and may miss speech onset. = So an endpoint that doesn=E2=80=99t want to provide CN support because = of user preference should not automatically be non-conforming. I = frankly think there is little value to CN and would rather make it = optional or leave it out altogether. Should the WebRTC spec really be = burdened with this kind of legacy cruft? If somebody is concerned about = bandwidth, they should be using Opus and not G.711. > =20 > Thanks, > --Felix > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie > Sent: Thursday, December 10, 2015 17:14 > To: rtcweb@ietf.org > Subject: [rtcweb] Proposed resolution on comfort noise > =20 > After reading the discussion on the comfort noise issue, it appears = that one way forward might be to adjust this language: >=20 > "comfort noise (CN). Receivers MUST support RFC3389 CN for streams = encoded with G.711 or any other supported codec that does not provide = its own CN.=E2=80=9D >=20 > to say instead >=20 > "comfort noise (CN). WebRTC endpoints MUST support RFC3389 CN for = streams encoded with G.711 or any other supported codec that does not = provide its own CN.=E2=80=9D >=20 > This would still allow non-WebRTC endpoints to omit CN support, while = retaining the mandate for WebRTC endpoints. >=20 > Does this resolve the issue? >=20 > regards, >=20 > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 11 11:45:30 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70B91A0271 for ; Fri, 11 Dec 2015 11:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtvpZdklIFDk for ; Fri, 11 Dec 2015 11:45:24 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2361A024C for ; Fri, 11 Dec 2015 11:45:24 -0800 (PST) Received: by igbxm8 with SMTP id xm8so46165295igb.1 for ; Fri, 11 Dec 2015 11:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=11pnInCvyJhObcK7bfedtf7ZqjuSy8OQlX1l5IDyZjM=; b=JnJLQWK2172oCD2XFm7cpmX7AFfiaGryT8EbHlwRSos0My472rJHpi2QkQX6BA798g wgX0vNx7T/cm4hROaAqm3kFrfM8cfwQaF7SqFhQr3CJTJus0YyCm8Pn4krnLlh7vyvSo mFH7vN7S9JZxW40IXaTf3XZUVH/eFHdUDKIi+sQ0j+/DWAkOpjvfd40wr4t6FsiNhFxk Y97REKOFavOTbBm3F+B4aaYurViTzBYB8UG3zRd3L3aO13NmjfyHFqhhiWlPskGzknho BWuEQzBGsoC3o2X4X11pLnG9PCjTHoi72WP8H7NhK2QQSF48dJUom05hsg1ejAYSUb6f FYtg== 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=11pnInCvyJhObcK7bfedtf7ZqjuSy8OQlX1l5IDyZjM=; b=dQD/xfzqFTOUvOMGa0jcxGKXyS4F1woAGU2bPxyga2eAyH4K9G8Er9pws0oTG4pyab UfPcSDjFy5UWVmd96DF1oJAnhPQu/witcEilZyehrl2S4/fHCO6qJky8IdvfpeOy8eN8 ZXbzUbKjWIR2+uTGEidjbraxgZqYXKcq8oUY/UoTBO3wWEa1lPG/0+nFqzByczEu81I1 seFYEVZWQO824fKz5WVU+Lacbei4HtE7k5O/Ei53X119mw87sFSG7mLh+S6Z50Bf4rzM 0YyJvhAQwfTKjGwFP+o+6T3FWOFqgX7B5JbxxVJ36b8G5FVCZNQI+BPDSbaxbGAmSKtq dU/A== X-Gm-Message-State: ALoCoQnV8mlJyAjdJ2JLPKutLHEM/SRI8kyW4dOVj4XD+B8/EQ4KoGBn+/ysDuJzfnch3MvWUYgM5JIG9HiwjT3o0kYcGJFJng== X-Received: by 10.50.171.202 with SMTP id aw10mr6534835igc.26.1449863124165; Fri, 11 Dec 2015 11:45:24 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id 42sm7380567iol.44.2015.12.11.11.45.22 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Dec 2015 11:45:23 -0800 (PST) Received: by igcto18 with SMTP id to18so45558996igc.0 for ; Fri, 11 Dec 2015 11:45:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.23.73 with SMTP id k9mr2742248igf.2.1449863122556; Fri, 11 Dec 2015 11:45:22 -0800 (PST) Received: by 10.36.205.4 with HTTP; Fri, 11 Dec 2015 11:45:22 -0800 (PST) In-Reply-To: <61F52659-1133-4C9A-A058-FC4326B3B9E7@iii.ca> References: <61F52659-1133-4C9A-A058-FC4326B3B9E7@iii.ca> Date: Fri, 11 Dec 2015 14:45:22 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=089e0158a9c464a0e50526a490eb Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed resolution on comfort noise X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 19:45:28 -0000 --089e0158a9c464a0e50526a490eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a bit more background, CN is needed for legacy interop. I know of at least several VoIP PSTN providers who will only generate G.711 with CN. So, the options to interoperate with such providers would be to transcode or to support CN. Essentially each additional codec improves chances for someone to interoperate. CN helps here. Beyond that CN can be safely ignored. For any new application Opus without CN should be used which audio draft already recommends. Regards, _____________ Roman Shpount On Fri, Dec 11, 2015 at 11:36 AM, Cullen Jennings wrote: > > Felix, just as background on this... one of the reasons people wanted CN > is that for many audio only calls, it roughly halfs the bandwidth. And fo= r > conference calls it often cuts the upstream bandwidth by much more than > that. The text proposed here does not require and conference bridge, > endpoint, or GW to support this as they don't have to RTCWeb Endpoints. > > > > On Dec 10, 2015, at 9:42 PM, Wyss, Felix wrote: > > > > I really don=E2=80=99t see why this needs to be a MUST. As offerer I s= hould be > able to not offer CN and also reject it as answerer. Whether to support > and/or enable CN should be at the each endpoint=E2=80=99s discretion=E2= =80=94usually based > on system configuration/user preference. DTX tends to result in a poorer > user experience due to noticeable discontinuities and artifacts at the > transition between genuine background noise and comfort noise and may mis= s > speech onset. So an endpoint that doesn=E2=80=99t want to provide CN sup= port > because of user preference should not automatically be non-conforming. I > frankly think there is little value to CN and would rather make it option= al > or leave it out altogether. Should the WebRTC spec really be burdened wi= th > this kind of legacy cruft? If somebody is concerned about bandwidth, the= y > should be using Opus and not G.711. > --089e0158a9c464a0e50526a490eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a bit more background, CN is needed for legacy interop.= I know of at least several VoIP PSTN providers who will only generate G.71= 1 with CN. So, the options to interoperate with such providers would be to = transcode or to support CN. Essentially each additional codec improves chan= ces for someone to interoperate. CN helps here. Beyond that CN can be safel= y ignored. For any new application Opus without CN should be used which aud= io draft already recommends.

Regards,
____________= _
Roman Shpount

On Fri, Dec 11, 2015 at 11:36 AM, Cullen Jen= nings <fluffy@iii.ca> wrote:
<= br> Felix, just as background on this... one of the reasons people wanted CN is= that for many audio only calls, it roughly halfs the bandwidth. And for co= nference calls it often cuts the upstream bandwidth by much more than that.= The text proposed here does not require and conference bridge, endpoint, o= r GW to support this as they don't have to RTCWeb Endpoints.


> On Dec 10, 2015, at 9:42 PM, Wyss, Felix <Felix.Wyss@inin.com> wrote:
>
> I really don=E2=80=99t see why this needs to be a MUST.=C2=A0 As offer= er I should be able to not offer CN and also reject it as answerer.=C2=A0 W= hether to support and/or enable CN should be at the each endpoint=E2=80=99s= discretion=E2=80=94usually based on system configuration/user preference.= =C2=A0 DTX tends to result in a poorer user experience due to noticeable di= scontinuities and artifacts at the transition between genuine background no= ise and comfort noise and may miss speech onset.=C2=A0 So an endpoint that = doesn=E2=80=99t want to provide CN support because of user preference shoul= d not automatically be non-conforming.=C2=A0 I frankly think there is littl= e value to CN and would rather make it optional or leave it out altogether.= =C2=A0 Should the WebRTC spec really be burdened with this kind of legacy c= ruft?=C2=A0 If somebody is concerned about bandwidth, they should be using = Opus and not G.711.
--089e0158a9c464a0e50526a490eb-- From nobody Sun Dec 13 07:02:55 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746821AD09C for ; Sun, 13 Dec 2015 07:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUs34gdWsry1 for ; Sun, 13 Dec 2015 07:02:52 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9FB1AD09B for ; Sun, 13 Dec 2015 07:02:51 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-10-566d88995e31 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 22.7D.05041.9988D665; Sun, 13 Dec 2015 16:02:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Sun, 13 Dec 2015 16:02:49 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP: Usage of a=rtcp attribute Thread-Index: AdE1tk5+GgxwzrGpR6mZvYz9J4lNJQ== Date: Sun, 13 Dec 2015 15:02:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CC9AF8@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37CC9AF8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7hO7Mjtwwg9sTxSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuKe2UwF7XoVF+58Y2lgXK7RxcjJISFgInHvzCp2CFtM4sK9 9WwgtpDAYUaJSR/suxi5gOzFjBJvp05i6mLk4GATsJDo/qcNUiMioC5x+eEFsF5hAQ2JczcX sEDEdSU6O3uhbD2JBWvXMILYLAKqEjv7brOC2LwCvhK7ru5iBrEZgfZ+P7WGCcRmFhCXuPVk PhPEPQISS/acZ4awRSVePv7HCmErSSy6/RmqPl/i4q6b7BAzBSVOznzCMoFRaBaSUbOQlM1C UgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZs YgRGxMEtv612MB587niIUYCDUYmH98OynDAh1sSy4srcQ4wSHMxKIryN5rlhQrwpiZVVqUX5 8UWlOanFhxilOViUxHmbmR6ECgmkJ5akZqemFqQWwWSZODilGhjFN+3YmLgnveDhLrmu4LjF tUU7Z7sdZ5/273fHg3DzkMSX91V8pp7Ljf/cm5UcfZ3n/qbNXGtn3lpkOVv0nrPgz75mTtkJ sXfyNFhriw+IZbcyGRWcimYPk5gRuvxl6tKyNVMPePNfqGe0/ym10NTWeYag8+upshtndv64 ft1p8aGs8/ESqf1KLMUZiYZazEXFiQBJeJ/ThAIAAA== Archived-At: Subject: [rtcweb] JSEP: Usage of a=rtcp attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 15:02:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37CC9AF8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.2.1 of draft-jsep contains the following statement: "o An "a=3Drtcp" line, as specified in [RFC3605], Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered." ...i.e. the same port:address as in the associated c/m-line. The problem is that the currently suggested mechanism to indicate exclusive= support of RTP/RTCP-mux also says that the a=3Drtcp line shall be identica= l to the c/m-line. My question is: is there really a need to always include the rtcp attribute= in trickle offers? Isn't it enough to indicate port 9 in the m- line, and = address 0.0.0.0 in the c-line? In my opinion that would also apply to RTCP. Example: JSEP trickle offer *without* mux-exclusive indication: c=3DIN IP4 0.0.0.0 m=3Daudio 9... a=3Drtcp-mux JSEP trickle offer *with* mux-exclusive indication: c=3DIN IP4 0.0.0.0 m=3Daudio 9... a=3Drtcp: 9 IN IP4 0.0.0.0 a=3Drtcp-mux Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37CC9AF8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 5.2.1 of draft-jsep contains the following s= tatement:

 

   “o  An "a=3Drtcp" = line, as specified in [RFC3605], Section 2.1,

      containing the dummy = value "9 IN IP4 0.0.0.0", because no

      candidates have yet b= een gathered.”

 

…i.e. the same port:address as in the associat= ed c/m-line.

 

The problem is that the currently suggested mechanis= m to indicate exclusive support of RTP/RTCP-mux also says that the a=3Drtcp= line shall be identical to the c/m-line.

 

My question is: is there really a need to always inc= lude the rtcp attribute in trickle offers? Isn’t it enough to indicat= e port 9 in the m- line, and address 0.0.0.0 in the c-line? In my opinion t= hat would also apply to RTCP.

 

Example:

 

JSEP trickle offer *without* mux-exclusive in= dication:

 

c=3DIN IP4 0.0.0.0

m=3Daudio 9…=

a=3Drtcp-mux=

 

JSEP trickle offer *with* mux-exclusive indic= ation:

 

c=3DIN IP4 0.0.0.0

m=3Daudio 9…=

        &nbs= p;     a=3Drtcp: 9 IN IP4 0.0.0.0

        &nbs= p;     a=3Drtcp-mux

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37CC9AF8ESESSMB209erics_-- From nobody Mon Dec 14 04:31:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6AA1A6F8D for ; Mon, 14 Dec 2015 04:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L0tMufi7VEm for ; Mon, 14 Dec 2015 04:31:23 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1B05E1A903F for ; Mon, 14 Dec 2015 04:31:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5182C7C60AD for ; Mon, 14 Dec 2015 13:31:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyPkh1l9y0p6 for ; Mon, 14 Dec 2015 13:31:18 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:d8c0:e011:5c36:6b4f] (unknown [IPv6:2001:470:de0a:1:d8c0:e011:5c36:6b4f]) by mork.alvestrand.no (Postfix) with ESMTPSA id BB89A7C60AC for ; Mon, 14 Dec 2015 13:31:18 +0100 (CET) To: rtcweb@ietf.org References: From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <566EB695.4080607@alvestrand.no> Date: Mon, 14 Dec 2015 13:31:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000000070607070604080501" Archived-At: Subject: Re: [rtcweb] Proposed resolution on comfort noise X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 12:31:26 -0000 This is a multi-part message in MIME format. --------------000000070607070604080501 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support this resolution. I note that there's material in this discussion for an extensive treatise on the pros and cons of offering CN at gateways. If someone wishes to extract this as a PR against the -gateways draft, the draft is at https://github.com/rtcweb-wg/gateways. On 12/10/2015 11:14 PM, Ted Hardie wrote: > After reading the discussion on the comfort noise issue, it appears > that one way forward might be to adjust this language: > > "comfort noise (CN). Receivers MUST support RFC3389 CN for streams > encoded with G.711 or any other supported codec that does not provide > its own CN.=94 > > to say instead > > "comfort noise (CN). WebRTC endpoints MUST support RFC3389 CN for > streams encoded with G.711 or any other supported codec that does not > provide its own CN.=94 > > This would still allow non-WebRTC endpoints to omit CN support, while > retaining the mandate for WebRTC endpoints. > > Does this resolve the issue? > > regards, > > Ted > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. --------------000000070607070604080501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I support this resolution.

I note that there's material in this discussion for an extensive treatise on the pros and cons of offering CN at gateways. If someone wishes to extract this as a PR against the -gateways draft, the draft is at https://github.com/rtcweb-wg/gateways.


On 12/10/2015 11:14 PM, Ted Hardie wrote:
After reading the discussion on the comfort noise issue, it appears that one way forward might be to adjust this language:

"comfort noise (CN).  Receivers MUST support RFC3389 CN for streams encoded with G.711 or any other supported codec that  does not provide its own CN.”

to say instead

"comfort noise (CN).  WebRTC endpoints MUST support RFC3389 CN for streams encoded with G.711 or any other supported codec that  does not provide its own CN.”

This would still allow non-WebRTC endpoints to omit CN support, while retaining the mandate for WebRTC endpoints.

Does this resolve the issue?

regards,

Ted


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



-- 
Surveillance is pervasive. Go Dark.
--------------000000070607070604080501-- From nobody Mon Dec 14 06:24:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8561A1AE1 for ; Mon, 14 Dec 2015 06:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPuFiqeYZnp2 for ; Mon, 14 Dec 2015 06:24:24 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E726A1A1ADC for ; Mon, 14 Dec 2015 06:24:23 -0800 (PST) Received: by qkck189 with SMTP id k189so100748507qkc.0 for ; Mon, 14 Dec 2015 06:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=vP3qG24fyFRNutH3ECTwGx4dKym8xdyCWm2FxCyD/PI=; b=hCHpJMimadw0MRweEXMBpuUx5hXZBj01FUYIKKNpuEprBkH5Xe/CH5DJixLeionmON RL3ATh+Yz4hFh8NFcazX61B9YmvVvTEUsilyLnMFHTA0SMs4XbhGvJtHuvHVItgndWgY /OOEVEXMuJ+NYI2C2DtlPXazqw+sTGLPfzgBk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding:date :subject:to:message-id:mime-version; bh=vP3qG24fyFRNutH3ECTwGx4dKym8xdyCWm2FxCyD/PI=; b=AXS3icRa5dinRSxa/U5zTyN6kW3phFpguWOZlxlXXU4KeleeNXorMW6c3tY183mtzb Uhv3ShdRf35dhU4jcvlS9K+VY7wv6ldT3rUEHRfZ18s4OPjjrdVFeDXbP0/k339nRy2G vkwFJQjxKKxupcnszfwH+sUL9Cd0i8y0Hgqsb+5UTSvemW9YgX9S9SMcp4DlMv4wM9TF /lzhx/fWOWDOGxirAgzHYEt/hS1lBVyR+J5FSPdxJA6Es/Jw6UBm465M9YDjTZ9iiDoR e7W/8RKtwNaPjGqEzuseUjRI5gPhU21BW9GQaIB9I41fYLz+vDztmzFg5amxp/khP3T4 FWkw== X-Gm-Message-State: ALoCoQn4/5oPmcNockpdF+DOdARqHtkTDWSgmd4/wv6obvTDC0/yaWeFKHfnu4qYhqkeirsYJbkZTiIKpYwAu1/oXqwgCBtbLg== X-Received: by 10.55.215.156 with SMTP id t28mr41605108qkt.41.1450103062822; Mon, 14 Dec 2015 06:24:22 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id z72sm13973790qkz.46.2015.12.14.06.24.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Dec 2015 06:24:21 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Dec 2015 09:24:19 -0500 To: rtcweb@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 14:24:26 -0000 In August there was a thread "Do we have consensus on not requiring = rtcp-non-mux=E2=80=9D that resulted in proposed changes to = draft-ietf-rtcweb-rtp-usage, see = https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf. This = email is to confirm the consensus we had in the room at IETF 94 to make = the following change in s4.5 of draft-ietf-rtcweb-rtp-usage: Intro (for context): Such RTP and RTCP multiplexing MUST be negotiated in the signalling channel before it is used. If SDP is used for signalling, this negotiation MUST use the attributes defined in RFC5761. OLD: implementations are also REQUIRED to support RTP and RTCP sent on separate transport-layer flows. NEW: Implementations MAY support RTP and RTCP sent on separate transport-layer flows. They MAY also refuse to do so, in which case any negotiation that results in multiplexing not being negotiated is treated as a failure. If do not agree with this change please post a reply to this message = with a reason why by December 18th. Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=E2=80=99s = queue, to incorporate this change our AD is going to need to pull it = back from the RFC-editor=E2=80=99s queue and re-run the IETF LC but = that=E2=80=99s only going to happen once we confirm the room=E2=80=99s = consensus. the chairs, c/s/t= From nobody Mon Dec 14 06:37:21 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57FE1A1B91 for ; Mon, 14 Dec 2015 06:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT5c5Or2VwJH for ; Mon, 14 Dec 2015 06:37:18 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD401A1BAC for ; Mon, 14 Dec 2015 06:37:17 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-a3-566ed41b02e2 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FF.26.04590.B14DE665; Mon, 14 Dec 2015 15:37:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 15:36:14 +0100 From: Christer Holmberg To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage Thread-Index: AQHRNnsmf+GVoto4fkCtHjewEozIYp7Kil8A Date: Mon, 14 Dec 2015 14:36:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@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.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7va70lbwwg7bDihZr/7WzW1xZ1cjs wOSxZMlPJo+DBxkDmKK4bFJSczLLUov07RK4Mq50TmEpeCResWj3fqYGxiniXYycHBICJhIN 3+YyQthiEhfurWfrYuTiEBI4zCgxo3U5E4SzmFFiyq/PQBkODjYBC4nuf9ogDSICrhLLrjxh AgkLCwRJHL4mCBEOlpgy+QEbhG0kMbd9AROIzSKgKvG44T0jSDmvgK/E1yMWIGEhARuJ/Wu+ sILYnAK2EpuvrgFrZQQ65/upNWCtzALiEreezGeCOFNAYsme88wQtqjEy8f/WCFsRYn2pw1g 45kFNCXW79KHaFWUmNL9kB3E5hUQlDg58wnLBEbRWUimzkLomIWkYxaSjgWMLKsYRYtTi5Ny 042M9VKLMpOLi/Pz9PJSSzYxAqPj4JbfqjsYL79xPMQowMGoxMNrcCA3TIg1say4MvcQowQH s5IIb9alvDAh3pTEyqrUovz4otKc1OJDjNIcLErivM1MD0KFBNITS1KzU1MLUotgskwcnFIN jFnCTFoiK/rKN058YzJ7du/1VVseb6nzc77n8FN/RegLpolrHer27VbZtTTzT8mqkmOeVRtv cW899YKlwJorb6da4IGK9LoVTzYeX7N/1uIzlfs3Hxa96vu3zHLx65X/97X8WXLd4rjei19h b/q2Oen6GTlxRP3UNjpxmn+av6pB2M7AtXNdtVuUWIozEg21mIuKEwHBDSNaigIAAA== Archived-At: Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 14:37:21 -0000 SGksDQoNCkkgZG9uJ3QgZGlzYWdyZWUgd2l0aCB0aGUgY2hhbmdlLg0KDQpIb3dldmVyLCBpZiB5 b3UgZG8gdGhlIGNoYW5nZSwgdGhlbiB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCAoIkludHJvIikg aW4gdGhlIGRyYWZ0IGlzIG5vdCBjb3JyZWN0Og0KDQogICAiSWYgU0RQIGlzIHVzZWQgZm9yIHNp Z25hbGxpbmcsIHRoaXMgbmVnb3RpYXRpb24gTVVTVCB1c2UgdGhlIGF0dHJpYnV0ZXMgZGVmaW5l ZCBpbiBbUkZDNTc2MV0uIg0KDQpCZWNhdXNlLCBSRkMgNTc2MSByZXF1aXJlcyBzdXBwb3J0IG9m IGZhbGxiYWNrIHRvIG5vbi1tdXgsIGFuZCBpdCBhbHNvIHJlcXVpcmVzIElDRSBSVENQIGNhbmRp ZGF0ZXMgd2hlbiBSVENQIGlzIHVzZWQuDQoNCkkgaGF2ZSBzdWdnZXN0ZWQgYSBtZWNoYW5pc20g KGRyYWZ0LWhvbG1iZXJnLW1tdXNpYy1tdXgtZXhjbHVzaXZlKSBvbiBob3cgdG8gbmVnb3RpYXRl L2luZGljYXRlIHN1cHBvcnQgd2hlbiBmYWxsYmFjayB0byBub24tbXV4IGlzIE5PVCBzdXBwb3J0 ZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTZWFuIFR1cm5lcg0KU2VudDogMTQuIGpvdWx1a3V1dGEgMjAxNSAxNjoyNA0KVG86 IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gY29uZmlybWluZyBjb25zZW5zdXMg dG8gY2hhbmdlIGRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZQ0KDQpJbiBBdWd1c3QgdGhlcmUg d2FzIGEgdGhyZWFkICJEbyB3ZSBoYXZlIGNvbnNlbnN1cyBvbiBub3QgcmVxdWlyaW5nIHJ0Y3At bm9uLW11eOKAnSB0aGF0IHJlc3VsdGVkIGluIHByb3Bvc2VkIGNoYW5nZXMgdG8gZHJhZnQtaWV0 Zi1ydGN3ZWItcnRwLXVzYWdlLCBzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTQvc2xpZGVzL3NsaWRlcy05NC1ydGN3ZWItNC5wZGYuIFRoaXMgZW1haWwgaXMgdG8gY29uZmly bSB0aGUgY29uc2Vuc3VzIHdlIGhhZCBpbiB0aGUgcm9vbSBhdCBJRVRGIDk0IHRvIG1ha2UgdGhl IGZvbGxvd2luZyBjaGFuZ2UgaW4gczQuNSBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2U6 DQoNCkludHJvIChmb3IgY29udGV4dCk6DQoNClN1Y2ggUlRQIGFuZCBSVENQIG11bHRpcGxleGlu ZyBNVVNUIGJlIG5lZ290aWF0ZWQgaW4gdGhlIHNpZ25hbGxpbmcgY2hhbm5lbCBiZWZvcmUgaXQg aXMgdXNlZC4gSWYgU0RQIGlzIHVzZWQgIGZvciBzaWduYWxsaW5nLCB0aGlzIG5lZ290aWF0aW9u IE1VU1QgdXNlIHRoZSBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gUkZDNTc2MS4NCg0KT0xEOg0KDQpp bXBsZW1lbnRhdGlvbnMgYXJlIGFsc28gUkVRVUlSRUQgdG8gc3VwcG9ydCBSVFAgYW5kIFJUQ1Ag c2VudCBvbiBzZXBhcmF0ZSB0cmFuc3BvcnQtbGF5ZXIgZmxvd3MuDQoNCk5FVzoNCg0KSW1wbGVt ZW50YXRpb25zIE1BWSBzdXBwb3J0IFJUUCBhbmQgUlRDUCBzZW50IG9uIHNlcGFyYXRlIHRyYW5z cG9ydC1sYXllciBmbG93cy4gVGhleSBNQVkgYWxzbyByZWZ1c2UgdG8gZG8gc28sIGluIHdoaWNo IGNhc2UgYW55IG5lZ290aWF0aW9uIHRoYXQgcmVzdWx0cyBpbiBtdWx0aXBsZXhpbmcgbm90IGJl aW5nIG5lZ290aWF0ZWQgaXMgdHJlYXRlZCBhcyBhIGZhaWx1cmUuDQoNCklmIGRvIG5vdCBhZ3Jl ZSB3aXRoIHRoaXMgY2hhbmdlIHBsZWFzZSBwb3N0IGEgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIHdp dGggYSByZWFzb24gd2h5IGJ5IERlY2VtYmVyIDE4dGguDQoNCkJlY2F1c2UgZHJhZnQtaWV0Zi1y dGN3ZWItcnRwLXVzYWdlIGlzIGluIHRoZSBSRkMgZWRpdG9y4oCZcyBxdWV1ZSwgdG8gaW5jb3Jw b3JhdGUgdGhpcyBjaGFuZ2Ugb3VyIEFEIGlzIGdvaW5nIHRvIG5lZWQgdG8gcHVsbCBpdCBiYWNr IGZyb20gdGhlIFJGQy1lZGl0b3LigJlzIHF1ZXVlIGFuZCByZS1ydW4gdGhlIElFVEYgTEMgYnV0 IHRoYXTigJlzIG9ubHkgZ29pbmcgdG8gaGFwcGVuIG9uY2Ugd2UgY29uZmlybSB0aGUgcm9vbeKA mXMgY29uc2Vuc3VzLg0KDQp0aGUgY2hhaXJzLA0KYy9zL3QNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Mon Dec 14 14:35:57 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD71A00B0 for ; Mon, 14 Dec 2015 14:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oug3aWfASE-K for ; Mon, 14 Dec 2015 14:35:53 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EB11A0107 for ; Mon, 14 Dec 2015 14:35:46 -0800 (PST) Received: by qkfb125 with SMTP id b125so159890950qkf.2 for ; Mon, 14 Dec 2015 14:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z7z+suZ1ZKSYfiSasKcM4YPq7gLoWlBwSjjl+mgkutY=; b=gD5BLhy4OiJSozpwk/aLvm+7TP1g0YA21Xbmc76gvrZb4yZ6dB5253WM3a+UzrLcWP CQtIfuiimQcjIN23nq6YT5ToZmRbErswKPxQgxnKLjqb5xOuK76Kqg+GAoEP0v8KVIkA wrtghZlwlI47x8Ynx6POiRYF8zeRkoyobFFpeYUjjYEunJ53BKpETnH17+PekDEPIKUK p/4VubwW+7OBGrU201Y/tTVRmxuyIw8mkai899eBu92q7x1Q8/nsf9Epcj6tNhDT1TO/ mtcfqoPEQehfZxRIgUE/N0VKmPTmo8BXeR5veAHpK+Z5El0IqoNLWAzt7Mp13ygZBNeo qfCw== X-Received: by 10.129.92.3 with SMTP id q3mr20399466ywb.256.1450132545640; Mon, 14 Dec 2015 14:35:45 -0800 (PST) Received: from [10.127.39.133] (mobile-166-172-186-144.mycingular.net. [166.172.186.144]) by smtp.gmail.com with ESMTPSA id b186sm24334612ywc.50.2015.12.14.14.35.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Dec 2015 14:35:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13C75) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> Date: Mon, 14 Dec 2015 17:35:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> To: Christer Holmberg Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 22:35:55 -0000 I second Christer's suggestion. Only citing RFC 5761 and not draft-holmberg-= mmusic-mux-exclusive will have nasty side effects like having to gather both= RTP and RTCP ICE candidates in an Offer even if the Offerer exclusively sup= ports mux. We need the cleaner solution that his draft provides. > On Dec 14, 2015, at 9:36 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > I don't disagree with the change. >=20 > However, if you do the change, then the following statement ("Intro") in t= he draft is not correct: >=20 > "If SDP is used for signalling, this negotiation MUST use the attributes= defined in [RFC5761]." >=20 > Because, RFC 5761 requires support of fallback to non-mux, and it also req= uires ICE RTCP candidates when RTCP is used. >=20 > I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive) on how t= o negotiate/indicate support when fallback to non-mux is NOT supported. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean Turner > Sent: 14. joulukuuta 2015 16:24 > To: rtcweb@ietf.org > Subject: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usa= ge >=20 > In August there was a thread "Do we have consensus on not requiring rtcp-n= on-mux=E2=80=9D that resulted in proposed changes to draft-ietf-rtcweb-rtp-u= sage, see https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf.= This email is to confirm the consensus we had in the room at IETF 94 to mak= e the following change in s4.5 of draft-ietf-rtcweb-rtp-usage: >=20 > Intro (for context): >=20 > Such RTP and RTCP multiplexing MUST be negotiated in the signalling channe= l before it is used. If SDP is used for signalling, this negotiation MUST u= se the attributes defined in RFC5761. >=20 > OLD: >=20 > implementations are also REQUIRED to support RTP and RTCP sent on separate= transport-layer flows. >=20 > NEW: >=20 > Implementations MAY support RTP and RTCP sent on separate transport-layer f= lows. They MAY also refuse to do so, in which case any negotiation that resu= lts in multiplexing not being negotiated is treated as a failure. >=20 > If do not agree with this change please post a reply to this message with a= reason why by December 18th. >=20 > Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=E2=80=99s queue, t= o incorporate this change our AD is going to need to pull it back from the R= FC-editor=E2=80=99s queue and re-run the IETF LC but that=E2=80=99s only goi= ng to happen once we confirm the room=E2=80=99s consensus. >=20 > the chairs, > c/s/t > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Dec 14 14:49:52 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4956E1A035F for ; Mon, 14 Dec 2015 14:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2S6LKfA9s9j for ; Mon, 14 Dec 2015 14:49:48 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5061A0276 for ; Mon, 14 Dec 2015 14:49:48 -0800 (PST) Received: from [81.187.2.149] (port=36891 helo=[192.168.0.64]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1a8bw0-0005lY-8N; Mon, 14 Dec 2015 22:49:40 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com> Date: Mon, 14 Dec 2015 22:49:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 22:49:51 -0000 Can you suggest explicit text changes? Colin > On 14 Dec 2015, at 22:35, Bernard Aboba = wrote: >=20 > I second Christer's suggestion. Only citing RFC 5761 and not = draft-holmberg-mmusic-mux-exclusive will have nasty side effects like = having to gather both RTP and RTCP ICE candidates in an Offer even if = the Offerer exclusively supports mux. We need the cleaner solution that = his draft provides. >=20 >> On Dec 14, 2015, at 9:36 AM, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> I don't disagree with the change. >>=20 >> However, if you do the change, then the following statement ("Intro") = in the draft is not correct: >>=20 >> "If SDP is used for signalling, this negotiation MUST use the = attributes defined in [RFC5761]." >>=20 >> Because, RFC 5761 requires support of fallback to non-mux, and it = also requires ICE RTCP candidates when RTCP is used. >>=20 >> I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive) on = how to negotiate/indicate support when fallback to non-mux is NOT = supported. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean = Turner >> Sent: 14. joulukuuta 2015 16:24 >> To: rtcweb@ietf.org >> Subject: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage >>=20 >> In August there was a thread "Do we have consensus on not requiring = rtcp-non-mux=E2=80=9D that resulted in proposed changes to = draft-ietf-rtcweb-rtp-usage, see = https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf. This = email is to confirm the consensus we had in the room at IETF 94 to make = the following change in s4.5 of draft-ietf-rtcweb-rtp-usage: >>=20 >> Intro (for context): >>=20 >> Such RTP and RTCP multiplexing MUST be negotiated in the signalling = channel before it is used. If SDP is used for signalling, this = negotiation MUST use the attributes defined in RFC5761. >>=20 >> OLD: >>=20 >> implementations are also REQUIRED to support RTP and RTCP sent on = separate transport-layer flows. >>=20 >> NEW: >>=20 >> Implementations MAY support RTP and RTCP sent on separate = transport-layer flows. They MAY also refuse to do so, in which case any = negotiation that results in multiplexing not being negotiated is treated = as a failure. >>=20 >> If do not agree with this change please post a reply to this message = with a reason why by December 18th. >>=20 >> Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=E2=80=99s = queue, to incorporate this change our AD is going to need to pull it = back from the RFC-editor=E2=80=99s queue and re-run the IETF LC but = that=E2=80=99s only going to happen once we confirm the room=E2=80=99s = consensus. >>=20 >> the chairs, >> c/s/t >> _______________________________________________ >> 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 Colin Perkins https://csperkins.org/ From nobody Mon Dec 14 20:39:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E831B2AB9 for ; Mon, 14 Dec 2015 20:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfEdl6vU-tRk for ; Mon, 14 Dec 2015 20:38:59 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252021B2ABC for ; Mon, 14 Dec 2015 20:38:56 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-08-566f995fd395 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.DA.05149.F599F665; Tue, 15 Dec 2015 05:38:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 05:38:54 +0100 From: Christer Holmberg To: Colin Perkins , Bernard Aboba Thread-Topic: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage Thread-Index: AQHRNnsmf+GVoto4fkCtHjewEozIYp7Kil8AgAB3bACAAAPfAIAAcmFP Date: Tue, 15 Dec 2015 04:38:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CDB453@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37CDB453ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7rm78zPwwg9ZWfosN+/4zWyx/eYLR Yu2/dnYHZo9p9++zeeycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGV93BhQ8Dq64eGgtcwPj SfcuRk4OCQETic55a1ggbDGJC/fWs3UxcnEICRxmlNj74xWUs5hRYvW8mUAOBwebgIVE9z9t kAYRAT+Jlpm/GUFsZgF1iTuLz7GDlAgLBEkcviYIURIsMWXyAzYI202i4fJDVhCbRUBV4l7P JHYQm1fAV2J+0yZ2iFUvGCWufHkOluAUcJSYueIo2HGMQMd9P7WGCWKXuETTl5WsEEcLSCzZ c54ZwhaVePn4HytETb7Eia4tbBALBCVOznzCMoFRZBaS9llIymYhKYOIG0h8eX8bytaWWLbw NTOErS/R/f40E7L4Akb2VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBkXZwy2+DHYwvnzse YhTgYFTi4d0gmB8mxJpYVlyZe4hRgoNZSYR3QS9QiDclsbIqtSg/vqg0J7X4EKM0B4uSOG8z 04NQIYH0xJLU7NTUgtQimCwTB6dUA2PdHo4ts76u9bPyN1Gy2n+uddnWaZFRgd/NfZnNHubo +bBVuT9umvu8wG2Lb8Mk3+Z9GxIvBzS/PvKTY52OgSmH3alMt+ms/3ymrTQPusOuvKHi9KaO UysPOWewFlTNFrrJYtZmeFjsD+fZ6B8rJDn9P4T6XfkldTv6h2fw/W3c8b9W/1fT9VFiKc5I NNRiLipOBACSuHELsAIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 04:39:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37CDB453ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I'll think of some text, but we'd need to reference draft-mux-exclusive for= the case when fallback to non-mux is not supported. Regards, Christer Regards, Christer Sent from my Windows Phone ________________________________ From: Colin Perkins Sent: =FD15/=FD12/=FD2015 00:49 To: Bernard Aboba Cc: Christer Holmberg; rtcweb@ietf.o= rg Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-= usage Can you suggest explicit text changes? Colin > On 14 Dec 2015, at 22:35, Bernard Aboba wrote: > > I second Christer's suggestion. Only citing RFC 5761 and not draft-holmbe= rg-mmusic-mux-exclusive will have nasty side effects like having to gather = both RTP and RTCP ICE candidates in an Offer even if the Offerer exclusivel= y supports mux. We need the cleaner solution that his draft provides. > >> On Dec 14, 2015, at 9:36 AM, Christer Holmberg wrote: >> >> Hi, >> >> I don't disagree with the change. >> >> However, if you do the change, then the following statement ("Intro") in= the draft is not correct: >> >> "If SDP is used for signalling, this negotiation MUST use the attribute= s defined in [RFC5761]." >> >> Because, RFC 5761 requires support of fallback to non-mux, and it also r= equires ICE RTCP candidates when RTCP is used. >> >> I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive) on ho= w to negotiate/indicate support when fallback to non-mux is NOT supported. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean Turner >> Sent: 14. joulukuuta 2015 16:24 >> To: rtcweb@ietf.org >> Subject: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-u= sage >> >> In August there was a thread "Do we have consensus on not requiring rtcp= -non-mux=94 that resulted in proposed changes to draft-ietf-rtcweb-rtp-usag= e, see https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf. T= his email is to confirm the consensus we had in the room at IETF 94 to make= the following change in s4.5 of draft-ietf-rtcweb-rtp-usage: >> >> Intro (for context): >> >> Such RTP and RTCP multiplexing MUST be negotiated in the signalling chan= nel before it is used. If SDP is used for signalling, this negotiation MUS= T use the attributes defined in RFC5761. >> >> OLD: >> >> implementations are also REQUIRED to support RTP and RTCP sent on separa= te transport-layer flows. >> >> NEW: >> >> Implementations MAY support RTP and RTCP sent on separate transport-laye= r flows. They MAY also refuse to do so, in which case any negotiation that = results in multiplexing not being negotiated is treated as a failure. >> >> If do not agree with this change please post a reply to this message wit= h a reason why by December 18th. >> >> Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=92s queue, to i= ncorporate this change our AD is going to need to pull it back from the RFC= -editor=92s queue and re-run the IETF LC but that=92s only going to happen = once we confirm the room=92s consensus. >> >> the chairs, >> c/s/t >> _______________________________________________ >> 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 -- Colin Perkins https://csperkins.org/ --_000_7594FB04B1934943A5C02806D1A2204B37CDB453ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I'll think of some text, but we'd need to reference draft-mux-exclusive for= the case when fallback to non-mux is not supported.

Regards,

Christer

Regards,

Christer

Sent from my Windows Phone
From: Colin Perkins
Sent: =FD15= /=FD12/=FD2015 00:49
To: Bernard Aboba
Cc: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [= rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage
Can you suggest explicit text changes?

Colin



> On 14 Dec 2015, at 22:35, Bernard Aboba <bernard.aboba@gmail.com>= ; wrote:
>
> I second Christer's suggestion. Only citing RFC 5761 and not draft-hol= mberg-mmusic-mux-exclusive will have nasty side effects like having to gath= er both RTP and RTCP ICE candidates in an Offer even if the Offerer exclusi= vely supports mux. We need the cleaner solution that his draft provides.
>
>> On Dec 14, 2015, at 9:36 AM, Christer Holmberg <christer.holmbe= rg@ericsson.com> wrote:
>>
>> Hi,
>>
>> I don't disagree with the change.
>>
>> However, if you do the change, then the following statement ("= ;Intro") in the draft is not correct:
>>
>>  "If SDP is used for signalling, this negotiation MUST u= se the attributes defined in [RFC5761]."
>>
>> Because, RFC 5761 requires support of fallback to non-mux, and it = also requires ICE RTCP candidates when RTCP is used.
>>
>> I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive)= on how to negotiate/indicate support when fallback to non-mux is NOT suppo= rted.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> -----Original Message-----
>> From: rtcweb [mailto:rt= cweb-bounces@ietf.org] On Behalf Of Sean Turner
>> Sent: 14. joulukuuta 2015 16:24
>> To: rtcweb@ietf.org
>> Subject: [rtcweb] confirming consensus to change draft-ietf-rtcweb= -rtp-usage
>>
>> In August there was a thread "Do we have consensus on not req= uiring rtcp-non-mux=94 that resulted in proposed changes to draft-ietf-rtcw= eb-rtp-usage, see https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf. T= his email is to confirm the consensus we had in the room at IETF 94 to make= the following change in s4.5 of draft-ietf-rtcweb-rtp-usage:
>>
>> Intro (for context):
>>
>> Such RTP and RTCP multiplexing MUST be negotiated in the signallin= g channel before it is used. If SDP is used  for signalling, this nego= tiation MUST use the attributes defined in RFC5761.
>>
>> OLD:
>>
>> implementations are also REQUIRED to support RTP and RTCP sent on = separate transport-layer flows.
>>
>> NEW:
>>
>> Implementations MAY support RTP and RTCP sent on separate transpor= t-layer flows. They MAY also refuse to do so, in which case any negotiation= that results in multiplexing not being negotiated is treated as a failure.=
>>
>> If do not agree with this change please post a reply to this messa= ge with a reason why by December 18th.
>>
>> Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=92s queue= , to incorporate this change our AD is going to need to pull it back from t= he RFC-editor=92s queue and re-run the IETF LC but that=92s only going to h= appen once we confirm the room=92s consensus.
>>
>> the chairs,
>> c/s/t
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> 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



--
Colin Perkins
https://csperkins.org/




 --_000_7594FB04B1934943A5C02806D1A2204B37CDB453ESESSMB209erics_-- From nobody Tue Dec 15 02:22:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7BB1A1B6C for ; Tue, 15 Dec 2015 02:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWLZ5X2aJ6IR for ; Tue, 15 Dec 2015 02:22:23 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24351A1B65 for ; Tue, 15 Dec 2015 02:22:22 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-18-566fe9dcb92e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5D.2A.05149.CD9EF665; Tue, 15 Dec 2015 11:22:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 11:22:20 +0100 From: Christer Holmberg To: Christer Holmberg , Colin Perkins , Bernard Aboba Thread-Topic: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage Thread-Index: AQHRNnsmf+GVoto4fkCtHjewEozIYp7Kil8AgAB3bACAAAPfAIAAcmFPgABczMA= Date: Tue, 15 Dec 2015 10:22:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CDD271@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com>, <7594FB04B1934943A5C02806D1A2204B37CDB453@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CDB453@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37CDD271ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2J7uO6dl/lhBrs7LS027PvPbLH85QlG i7X/2tkdmD2m3b/P5rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZez+9Ia54NIRxoq3T8+z NzB+W8vYxcjJISFgInHu1HMoW0ziwr31bF2MXBxCAocZJVaevc8K4SxmlDg5t4Gli5GDg03A QqL7nzZIXESgBSj+ahcrSDezgLrEncXn2EFqhAWCJA5fEwQJiwgES0yZ/IANwvaT+Nn/GWwZ i4CqxIIb/cwgNq+Ar8TXl++hFq9nkriw7ABYAydQw8qfd8AaGIGu+35qDRPELnGJW0/mM0Fc LSCxZM95ZghbVOLl43+sELaixM6z7cwg9zAL5EvM2WEPsUtQ4uTMJywTGEVnIZk0C6FqFpIq iBIDiXPbN7JD2NoSyxa+Zoaw9SW2357Jiiy+gJF9FaNocWpxUm66kZFealFmcnFxfp5eXmrJ JkZgFB7c8ttgB+PL546HGAU4GJV4eDcI5ocJsSaWFVfmHmKU4GBWEuHNvgUU4k1JrKxKLcqP LyrNSS0+xCjNwaIkztvM9CBUSCA9sSQ1OzW1ILUIJsvEwSnVwBh8yEvu0OeKmeeqcpbvKM/O Fz2YM+X+TFbNRM/wY1Guf86ckfIsV5/R9WSXY9sW3oMfTlyf6KY2cYVWTV73Q71bOZv/Hy7v mLPAesGmBco72T4ejpu08OyGsl+N4VaHDEsCOr8ccV5VkNXe9FvC2OpkPPu6Z37nRXJkH8Qt 8o+3et4T/iiwol6JpTgj0VCLuag4EQDXUweMvgIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 10:22:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37CDD271ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Text proposal() Regards, Christer --------------------------------- 4.5. RTP and RTCP Multiplexing Historically, RTP and RTCP have been run on separate transport layer flows (e.g., two UDP ports for each RTP session, one port for RTP and one port for RTCP). With the increased use of Network Address/Port Translation (NAT/NAPT) this has become problematic, since maintaining multiple NAT bindings can be costly. It also complicates firewall administration, since multiple ports need to be opened to allow RTP traffic. To reduce these costs and session set-up times, implementations are REQUIRED to support multiplexing RTP data packets and RTCP control packets on a single transport-layer flow [RFC5761]. Such RTP and RTCP multiplexing MUST be negotiated in the signalling channel before it is used. If SDP is used for signalling, this negotiation MUST use the attributes defined in [RFC5761]. If an implementation does not support RTP and RTCP sent on separate transport-layer flows, it MUST indicate that using the mechanis= m defined in [reference-to-draft-mux-exclusive]. For backwards compatibility, implementations MAY support RTP and RTCP sent on separate transport-layer flows. They MAY also refuse to do so, i= n which case any negotiation that results in multiplexing not being negoti= ated is treated as a failure. Note that the use of RTP and RTCP multiplexed onto a single transport-layer flow ensures that there is occasional traffic sent on that port, even if there is no active media traffic. This can be useful to keep NAT bindings alive [RFC6263]. --------------------------------- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 15. joulukuuta 2015 6:39 To: Colin Perkins; Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-= usage Hi, I'll think of some text, but we'd need to reference draft-mux-exclusive for= the case when fallback to non-mux is not supported. Regards, Christer Regards, Christer Sent from my Windows Phone ________________________________ From: Colin Perkins Sent: =FD15/=FD12/=FD2015 00:49 To: Bernard Aboba Cc: Christer Holmberg; rtcweb@ietf.o= rg Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-= usage Can you suggest explicit text changes? Colin > On 14 Dec 2015, at 22:35, Bernard Aboba > wrote: > > I second Christer's suggestion. Only citing RFC 5761 and not draft-holmbe= rg-mmusic-mux-exclusive will have nasty side effects like having to gather = both RTP and RTCP ICE candidates in an Offer even if the Offerer exclusivel= y supports mux. We need the cleaner solution that his draft provides. > >> On Dec 14, 2015, at 9:36 AM, Christer Holmberg > wrote: >> >> Hi, >> >> I don't disagree with the change. >> >> However, if you do the change, then the following statement ("Intro") in= the draft is not correct: >> >> "If SDP is used for signalling, this negotiation MUST use the attribute= s defined in [RFC5761]." >> >> Because, RFC 5761 requires support of fallback to non-mux, and it also r= equires ICE RTCP candidates when RTCP is used. >> >> I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive) on ho= w to negotiate/indicate support when fallback to non-mux is NOT supported. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean Turner >> Sent: 14. joulukuuta 2015 16:24 >> To: rtcweb@ietf.org >> Subject: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-u= sage >> >> In August there was a thread "Do we have consensus on not requiring rtcp= -non-mux=94 that resulted in proposed changes to draft-ietf-rtcweb-rtp-usag= e, see https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf. T= his email is to confirm the consensus we had in the room at IETF 94 to make= the following change in s4.5 of draft-ietf-rtcweb-rtp-usage: >> >> Intro (for context): >> >> Such RTP and RTCP multiplexing MUST be negotiated in the signalling chan= nel before it is used. If SDP is used for signalling, this negotiation MUS= T use the attributes defined in RFC5761. >> >> OLD: >> >> implementations are also REQUIRED to support RTP and RTCP sent on separa= te transport-layer flows. >> >> NEW: >> >> Implementations MAY support RTP and RTCP sent on separate transport-laye= r flows. They MAY also refuse to do so, in which case any negotiation that = results in multiplexing not being negotiated is treated as a failure. >> >> If do not agree with this change please post a reply to this message wit= h a reason why by December 18th. >> >> Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=92s queue, to i= ncorporate this change our AD is going to need to pull it back from the RFC= -editor=92s queue and re-run the IETF LC but that=92s only going to happen = once we confirm the room=92s consensus. >> >> the chairs, >> c/s/t >> _______________________________________________ >> 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 -- Colin Perkins https://csperkins.org/ --_000_7594FB04B1934943A5C02806D1A2204B37CDD271ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Text propo= sal(<new></new>)

 = ;

Regards,

 = ;

Christer

 = ;

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

 = ;

4.5. = RTP and RTCP Multiplexing

 = ;

 &nbs= p; Historically, RTP and RTCP have been run on separate transport layer

 &nbs= p; flows (e.g., two UDP ports for each RTP session, one port for RTP and

 &nbs= p; one port for RTCP).  With the increased use of Network Address/Port=

 &nbs= p; Translation (NAT/NAPT) this has become problematic, since maintaining

 &nbs= p; multiple NAT bindings can be costly.  It also complicates firewall<= o:p>

 &nbs= p; administration, since multiple ports need to be opened to allow RTP=

 &nbs= p; traffic.  To reduce these costs and session set-up times,

 &nbs= p; implementations are REQUIRED to support multiplexing RTP data packets

 &nbs= p; and RTCP control packets on a single transport-layer flow [RFC5761].

 &nbs= p; Such RTP and RTCP multiplexing MUST be negotiated in the signalling=

 &nbs= p; channel before it is used.  If SDP is used for signalling, this

 &nbs= p; negotiation MUST use the attributes defined in [RFC5761].

  &n= bsp;<new>If an implementation does not  support RTP and RTCP sen= t on

  &n= bsp;separate transport-layer flows, it MUST indicate that using the mechani= sm

  &n= bsp;defined in [reference-to-draft-mux-exclusive]</new>. For

 &nbs= p; backwards compatibility, implementations MAY support RTP and RTCP

 &nbs= p; sent on separate transport-layer flows. They MAY also refuse to do = so, in

 &nbs= p; which case any negotiation that results in multiplexing not being n= egotiated

 &nbs= p; is treated as a failure.

 &nbs= p;

 &nbs= p; Note that the use of RTP and RTCP multiplexed onto a single

 &nbs= p; transport-layer flow ensures that there is occasional traffic sent on

 &nbs= p; that port, even if there is no active media traffic.  This can be

 &nbs= p; useful to keep NAT bindings alive [RFC6263].

 = ;

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

 = ;

 = ;

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 15. joulukuuta 2015 6:39
To: Colin Perkins; Bernard Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcw= eb-rtp-usage

 

Hi,

I'll think of some text, but we'd need to reference draft-mux-exclusive for= the case when fallback to non-mux is not supported.

Regards,

Christer

Regards,

Christer

Sent from my Windows Phone

From: Colin Perkins<= /a>
Sent: =FD15/=FD12/=FD2015 00:49
To: Bernard Aboba
Cc: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtc= web-rtp-usage

Can you suggest explicit text changes?

Colin



> On 14 Dec 2015, at 22:35, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>
> I second Christer's suggestion. Only citing RFC 5761 and not draft-hol= mberg-mmusic-mux-exclusive will have nasty side effects like having to gath= er both RTP and RTCP ICE candidates in an Offer even if the Offerer exclusi= vely supports mux. We need the cleaner solution that his draft provides.
>
>> On Dec 14, 2015, at 9:36 AM, Christer Holmberg <christer.holmberg@ericsson.com> w= rote:
>>
>> Hi,
>>
>> I don't disagree with the change.
>>
>> However, if you do the change, then the following statement ("= ;Intro") in the draft is not correct:
>>
>>  "If SDP is used for signalling, this negotiation MUST u= se the attributes defined in [RFC5761]."
>>
>> Because, RFC 5761 requires support of fallback to non-mux, and it = also requires ICE RTCP candidates when RTCP is used.
>>
>> I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive)= on how to negotiate/indicate support when fallback to non-mux is NOT suppo= rted.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> -----Original Message-----
>> From: rtcweb [mailto:rt= cweb-bounces@ietf.org] On Behalf Of Sean Turner
>> Sent: 14. joulukuuta 2015 16:24
>> To: rtcweb@ietf.org
>> Subject: [rtcweb] confirming consensus to change draft-ietf-rtcweb= -rtp-usage
>>
>> In August there was a thread "Do we have consensus on not req= uiring rtcp-non-mux=94 that resulted in proposed changes to draft-ietf-rtcw= eb-rtp-usage, see https://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf. T= his email is to confirm the consensus we had in the room at IETF 94 to make= the following change in s4.5 of draft-ietf-rtcweb-rtp-usage:
>>
>> Intro (for context):
>>
>> Such RTP and RTCP multiplexing MUST be negotiated in the signallin= g channel before it is used. If SDP is used  for signalling, this nego= tiation MUST use the attributes defined in RFC5761.
>>
>> OLD:
>>
>> implementations are also REQUIRED to support RTP and RTCP sent on = separate transport-layer flows.
>>
>> NEW:
>>
>> Implementations MAY support RTP and RTCP sent on separate transpor= t-layer flows. They MAY also refuse to do so, in which case any negotiation= that results in multiplexing not being negotiated is treated as a failure.=
>>
>> If do not agree with this change please post a reply to this messa= ge with a reason why by December 18th.
>>
>> Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=92s queue= , to incorporate this change our AD is going to need to pull it back from t= he RFC-editor=92s queue and re-run the IETF LC but that=92s only going to h= appen once we confirm the room=92s consensus.
>>
>> the chairs,
>> c/s/t
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> 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



--
Colin Perkins
https://csperkins.org/



--_000_7594FB04B1934943A5C02806D1A2204B37CDD271ESESSMB209erics_-- From nobody Thu Dec 17 01:54:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94A81A87B9 for ; Thu, 17 Dec 2015 01:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a0EacHOfDCO for ; Thu, 17 Dec 2015 01:54:03 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8071A87BB for ; Thu, 17 Dec 2015 01:53:52 -0800 (PST) Received: from [176.12.107.137] (port=59441 helo=[10.101.1.101]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1a9VFj-0005NC-1o; Thu, 17 Dec 2015 09:53:49 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_4FDF4DA5-6F72-4CC3-9023-D277C2DA7D2C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CDD271@ESESSMB209.ericsson.se> Date: Thu, 17 Dec 2015 09:53:33 +0000 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com> <7594FB04B1934943A5C02806D1A2204B37CDB453@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37CDD271@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 09:54:06 -0000 --Apple-Mail=_4FDF4DA5-6F72-4CC3-9023-D277C2DA7D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That text is fine with me - any other views? Colin > On 15 Dec 2015, at 10:22, Christer Holmberg = wrote: >=20 > Text proposal() > =20 > Regards, > =20 > Christer > =20 > --------------------------------- > =20 > 4.5. RTP and RTCP Multiplexing > =20 > Historically, RTP and RTCP have been run on separate transport = layer > flows (e.g., two UDP ports for each RTP session, one port for RTP = and > one port for RTCP). With the increased use of Network Address/Port > Translation (NAT/NAPT) this has become problematic, since = maintaining > multiple NAT bindings can be costly. It also complicates firewall > administration, since multiple ports need to be opened to allow RTP > traffic. To reduce these costs and session set-up times, > implementations are REQUIRED to support multiplexing RTP data = packets > and RTCP control packets on a single transport-layer flow = [RFC5761]. > Such RTP and RTCP multiplexing MUST be negotiated in the signalling > channel before it is used. If SDP is used for signalling, this > negotiation MUST use the attributes defined in [RFC5761]. > If an implementation does not support RTP and RTCP sent on > separate transport-layer flows, it MUST indicate that using the = mechanism > defined in [reference-to-draft-mux-exclusive]. For > backwards compatibility, implementations MAY support RTP and RTCP > sent on separate transport-layer flows. They MAY also refuse to do = so, in > which case any negotiation that results in multiplexing not being = negotiated > is treated as a failure. > =20 > Note that the use of RTP and RTCP multiplexed onto a single > transport-layer flow ensures that there is occasional traffic sent = on > that port, even if there is no active media traffic. This can be > useful to keep NAT bindings alive [RFC6263]. > =20 > --------------------------------- > =20 > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org = ] On Behalf Of Christer Holmberg > Sent: 15. joulukuuta 2015 6:39 > To: Colin Perkins; Bernard Aboba > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage > =20 > Hi, >=20 > I'll think of some text, but we'd need to reference = draft-mux-exclusive for the case when fallback to non-mux is not = supported. >=20 > Regards, >=20 > Christer >=20 > Regards, >=20 > Christer >=20 > Sent from my Windows Phone > From: Colin Perkins > Sent: =E2=80=8E15/=E2=80=8E12/=E2=80=8E2015 00:49 > To: Bernard Aboba > Cc: Christer Holmberg ; = rtcweb@ietf.org > Subject: Re: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage >=20 > Can you suggest explicit text changes? >=20 > Colin >=20 >=20 >=20 > > On 14 Dec 2015, at 22:35, Bernard Aboba > wrote: > >=20 > > I second Christer's suggestion. Only citing RFC 5761 and not = draft-holmberg-mmusic-mux-exclusive will have nasty side effects like = having to gather both RTP and RTCP ICE candidates in an Offer even if = the Offerer exclusively supports mux. We need the cleaner solution that = his draft provides. > >=20 > >> On Dec 14, 2015, at 9:36 AM, Christer Holmberg = > = wrote: > >>=20 > >> Hi, > >>=20 > >> I don't disagree with the change. > >>=20 > >> However, if you do the change, then the following statement = ("Intro") in the draft is not correct: > >>=20 > >> "If SDP is used for signalling, this negotiation MUST use the = attributes defined in [RFC5761]." > >>=20 > >> Because, RFC 5761 requires support of fallback to non-mux, and it = also requires ICE RTCP candidates when RTCP is used. > >>=20 > >> I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive) = on how to negotiate/indicate support when fallback to non-mux is NOT = supported. > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >>=20 > >>=20 > >> -----Original Message----- > >> From: rtcweb [mailto:rtcweb-bounces@ietf.org = ] On Behalf Of Sean Turner > >> Sent: 14. joulukuuta 2015 16:24 > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage > >>=20 > >> In August there was a thread "Do we have consensus on not requiring = rtcp-non-mux=E2=80=9D that resulted in proposed changes to = draft-ietf-rtcweb-rtp-usage, = seehttps://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf = . = This email is to confirm the consensus we had in the room at IETF 94 to = make the following change in s4.5 of draft-ietf-rtcweb-rtp-usage: > >>=20 > >> Intro (for context): > >>=20 > >> Such RTP and RTCP multiplexing MUST be negotiated in the signalling = channel before it is used. If SDP is used for signalling, this = negotiation MUST use the attributes defined in RFC5761. > >>=20 > >> OLD: > >>=20 > >> implementations are also REQUIRED to support RTP and RTCP sent on = separate transport-layer flows. > >>=20 > >> NEW: > >>=20 > >> Implementations MAY support RTP and RTCP sent on separate = transport-layer flows. They MAY also refuse to do so, in which case any = negotiation that results in multiplexing not being negotiated is treated = as a failure. > >>=20 > >> If do not agree with this change please post a reply to this = message with a reason why by December 18th. > >>=20 > >> Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=E2=80=99s = queue, to incorporate this change our AD is going to need to pull it = back from the RFC-editor=E2=80=99s queue and re-run the IETF LC but = that=E2=80=99s only going to happen once we confirm the room=E2=80=99s = consensus. > >>=20 > >> the chairs, > >> c/s/t > >> _______________________________________________ > >> 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 > Colin Perkins > https://csperkins.org/ --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_4FDF4DA5-6F72-4CC3-9023-D277C2DA7D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That text is fine with me - any other views?
Colin


On 15 Dec 2015, at 10:22, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Text proposal(<new></new>)
 
Regards,
 
Christer
 
---------------------------------
 
4.5.  RTP = and RTCP Multiplexing
 
   Historically, RTP and RTCP have been run on = separate transport layer
   flows (e.g., two UDP ports for each RTP session, = one port for RTP and
   one port for RTCP).  With the increased use = of Network Address/Port
   Translation (NAT/NAPT) this has become = problematic, since maintaining
   multiple NAT bindings can be costly.  It = also complicates firewall
   administration, since multiple ports need to be = opened to allow RTP
   traffic.  To reduce these costs and session = set-up times,
   implementations are REQUIRED to support = multiplexing RTP data packets
   and RTCP control packets on a single = transport-layer flow [RFC5761].
   Such RTP and RTCP multiplexing MUST be = negotiated in the signalling
   channel before it is used.  If SDP is used = for signalling, this
   negotiation MUST use the attributes defined in = [RFC5761].
   <new>If an implementation does not =  support RTP and RTCP sent on
   separate transport-layer flows, it MUST = indicate that using the mechanism
   defined in = [reference-to-draft-mux-exclusive]</new>. For
   backwards compatibility, implementations MAY = support RTP and RTCP
   sent on separate transport-layer flows. = They MAY also refuse to do so, in
   which case any negotiation that results in = multiplexing not being negotiated
   is treated as a failure.
  
   Note = that the use of RTP and RTCP multiplexed onto a single
   = transport-layer flow ensures that there is occasional traffic sent = on
   = that port, even if there is no active media traffic.  This can = be
   = useful to keep NAT bindings alive [RFC6263].
 
---------------------------------
 
 
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: 15. joulukuuta 2015 6:39
To: Colin Perkins; Bernard = Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming = consensus to change draft-ietf-rtcweb-rtp-usage
 
Hi,

I'll think of some text, but = we'd need to reference draft-mux-exclusive for the case when fallback to = non-mux is not supported.

Regards,

Christer

Regards,

Christer

Sent from my Windows Phone

From: Colin Perkins
Sent: =E2=80=8E15/=E2=80=8E12/=E2=80=8E2015 00:49
To: Bernard Aboba
Cc: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage

Can you = suggest explicit text changes?

Colin



> On 14 Dec = 2015, at 22:35, Bernard Aboba <bernard.aboba@gmail.com> = wrote:
> 
> I = second Christer's suggestion. Only citing RFC 5761 and not = draft-holmberg-mmusic-mux-exclusive will have nasty side effects like = having to gather both RTP and RTCP ICE candidates in an Offer even if = the Offerer exclusively supports mux. We need the cleaner solution that = his draft provides.
> 
>> On = Dec 14, 2015, at 9:36 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>> 
>> Hi,
>> 
>> I = don't disagree with the change.
>> 
>> = However, if you do the change, then the following statement ("Intro") in = the draft is not correct:
>> 
>> = "If SDP is used for signalling, this negotiation MUST use the = attributes defined in [RFC5761]."
>> 
>> = Because, RFC 5761 requires support of fallback to non-mux, and it also = requires ICE RTCP candidates when RTCP is used.
>> 
>> I have suggested a mechanism = (draft-holmberg-mmusic-mux-exclusive) on how to negotiate/indicate = support when fallback to non-mux is NOT supported.
>> 
>> Regards,
>> 
>> = Christer
>> 
>> 
>> 
>> = -----Original Message-----
>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean = Turner
>> Sent: 14. joulukuuta 2015 16:24
>> To: rtcweb@ietf.org
>> = Subject: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage
>> 
>> In = August there was a thread "Do we have consensus on not requiring = rtcp-non-mux=E2=80=9D that resulted in proposed changes to = draft-ietf-rtcweb-rtp-usage, seehttps://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.p= df. This email is to confirm the consensus we had in the room at = IETF 94 to make the following change in s4.5 of = draft-ietf-rtcweb-rtp-usage:
>> 
>> = Intro (for context):
>> 
>> = Such RTP and RTCP multiplexing MUST be negotiated in the signalling = channel before it is used. If SDP is used  for signalling, this = negotiation MUST use the attributes defined in RFC5761.
>> 
>> OLD:
>> 
>> = implementations are also REQUIRED to support RTP and RTCP sent on = separate transport-layer flows.
>> 
>> = NEW:
>> 
>> = Implementations MAY support RTP and RTCP sent on separate = transport-layer flows. They MAY also refuse to do so, in which case any = negotiation that results in multiplexing not being negotiated is treated = as a failure.
>> 
>> If = do not agree with this change please post a reply to this message with a = reason why by December 18th.
>> 
>> = Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=E2=80=99s = queue, to incorporate this change our AD is going to need to pull it = back from the RFC-editor=E2=80=99s queue and re-run the IETF LC but = that=E2=80=99s only going to happen once we confirm the room=E2=80=99s = consensus.
>> 
>> the = chairs,
>> c/s/t
>> = _______________________________________________
>> = 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



-- 
Colin = Perkins
https://csperkins.org/




-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_4FDF4DA5-6F72-4CC3-9023-D277C2DA7D2C-- From nobody Thu Dec 17 02:01:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD851A8716 for ; Thu, 17 Dec 2015 02:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leJGY4cxXFRM for ; Thu, 17 Dec 2015 02:01:07 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDB51A87A8 for ; Thu, 17 Dec 2015 02:01:06 -0800 (PST) Received: from [176.12.107.137] (port=59554 helo=[10.101.1.101]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1a9VMp-0007DP-SN; Thu, 17 Dec 2015 10:01:04 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_88F3C0DB-2812-40B2-9877-76413494FE77" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Thu, 17 Dec 2015 10:00:45 +0000 Message-Id: <3F5DBD22-AB47-4796-83FE-7B924115AD61@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com> <7594FB04B1934943A5C02806D1A2204B37CDB453@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37CDD271@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 10:01:11 -0000 --Apple-Mail=_88F3C0DB-2812-40B2-9877-76413494FE77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To confirm, this would give the following change to the rtp-usage draft: --- draft-ietf-rtcweb-rtp-usage.xml (revision 1071) +++ draft-ietf-rtcweb-rtp-usage.xml (working copy) @@ -10,7 +10,7 @@ - + Web Real-Time Communication = (WebRTC): Media Transport and Use of RTP @@ -71,7 +71,7 @@ =20 - + =20 RTCWEB Working Group =20 @@ -483,9 +483,13 @@ target=3D"RFC5761">. Such RTP and RTCP multiplexing MUST = be negotiated in the signalling channel before it is used. If SDP = is used for signalling, this negotiation MUST use the attributes = defined in - . For backwards compatibility, - implementations are also REQUIRED to support RTP and RTCP sent = on - separate transport-layer flows. + . Implementations MAY support = RTP and + RTCP sent on separate transport-layer flows. They MAY also = refuse to + do so, in which case any negotiation that results in = multiplexing not + being negotiated is treated as a failure. If an implementation = does=20 + not support RTP and RTCP sent on separate transport-layer = flows, it=20 + MUST indicate that using the mechanism defined in=20 + . =20 Note that the use of RTP and RTCP multiplexed onto a single transport-layer flow ensures that there is occasional traffic = sent on @@ -2037,6 +2041,8 @@ =20 =20 + + =20 > On 17 Dec 2015, at 09:53, Colin Perkins wrote: >=20 > That text is fine with me - any other views? > Colin >=20 >=20 >> On 15 Dec 2015, at 10:22, Christer Holmberg = > = wrote: >>=20 >> Text proposal() >> =20 >> Regards, >> =20 >> Christer >> =20 >> --------------------------------- >> =20 >> 4.5. RTP and RTCP Multiplexing >> =20 >> Historically, RTP and RTCP have been run on separate transport = layer >> flows (e.g., two UDP ports for each RTP session, one port for RTP = and >> one port for RTCP). With the increased use of Network = Address/Port >> Translation (NAT/NAPT) this has become problematic, since = maintaining >> multiple NAT bindings can be costly. It also complicates firewall >> administration, since multiple ports need to be opened to allow = RTP >> traffic. To reduce these costs and session set-up times, >> implementations are REQUIRED to support multiplexing RTP data = packets >> and RTCP control packets on a single transport-layer flow = [RFC5761]. >> Such RTP and RTCP multiplexing MUST be negotiated in the = signalling >> channel before it is used. If SDP is used for signalling, this >> negotiation MUST use the attributes defined in [RFC5761]. >> If an implementation does not support RTP and RTCP sent on >> separate transport-layer flows, it MUST indicate that using the = mechanism >> defined in [reference-to-draft-mux-exclusive]. For >> backwards compatibility, implementations MAY support RTP and RTCP >> sent on separate transport-layer flows. They MAY also refuse to do = so, in >> which case any negotiation that results in multiplexing not being = negotiated >> is treated as a failure. >> =20 >> Note that the use of RTP and RTCP multiplexed onto a single >> transport-layer flow ensures that there is occasional traffic sent = on >> that port, even if there is no active media traffic. This can be >> useful to keep NAT bindings alive [RFC6263]. >> =20 >> --------------------------------- >> =20 >> =20 >> From: rtcweb [mailto:rtcweb-bounces@ietf.org = ] On Behalf Of Christer Holmberg >> Sent: 15. joulukuuta 2015 6:39 >> To: Colin Perkins; Bernard Aboba >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage >> =20 >> Hi, >>=20 >> I'll think of some text, but we'd need to reference = draft-mux-exclusive for the case when fallback to non-mux is not = supported. >>=20 >> Regards, >>=20 >> Christer >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >> From: Colin Perkins >> Sent: =E2=80=8E15/=E2=80=8E12/=E2=80=8E2015 00:49 >> To: Bernard Aboba >> Cc: Christer Holmberg ; = rtcweb@ietf.org >> Subject: Re: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage >>=20 >> Can you suggest explicit text changes? >>=20 >> Colin >>=20 >>=20 >>=20 >> > On 14 Dec 2015, at 22:35, Bernard Aboba > wrote: >> >=20 >> > I second Christer's suggestion. Only citing RFC 5761 and not = draft-holmberg-mmusic-mux-exclusive will have nasty side effects like = having to gather both RTP and RTCP ICE candidates in an Offer even if = the Offerer exclusively supports mux. We need the cleaner solution that = his draft provides. >> >=20 >> >> On Dec 14, 2015, at 9:36 AM, Christer Holmberg = > = wrote: >> >>=20 >> >> Hi, >> >>=20 >> >> I don't disagree with the change. >> >>=20 >> >> However, if you do the change, then the following statement = ("Intro") in the draft is not correct: >> >>=20 >> >> "If SDP is used for signalling, this negotiation MUST use the = attributes defined in [RFC5761]." >> >>=20 >> >> Because, RFC 5761 requires support of fallback to non-mux, and it = also requires ICE RTCP candidates when RTCP is used. >> >>=20 >> >> I have suggested a mechanism (draft-holmberg-mmusic-mux-exclusive) = on how to negotiate/indicate support when fallback to non-mux is NOT = supported. >> >>=20 >> >> Regards, >> >>=20 >> >> Christer >> >>=20 >> >>=20 >> >>=20 >> >> -----Original Message----- >> >> From: rtcweb [mailto:rtcweb-bounces@ietf.org = ] On Behalf Of Sean Turner >> >> Sent: 14. joulukuuta 2015 16:24 >> >> To: rtcweb@ietf.org >> >> Subject: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage >> >>=20 >> >> In August there was a thread "Do we have consensus on not = requiring rtcp-non-mux=E2=80=9D that resulted in proposed changes to = draft-ietf-rtcweb-rtp-usage, = seehttps://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.pdf = . = This email is to confirm the consensus we had in the room at IETF 94 to = make the following change in s4.5 of draft-ietf-rtcweb-rtp-usage: >> >>=20 >> >> Intro (for context): >> >>=20 >> >> Such RTP and RTCP multiplexing MUST be negotiated in the = signalling channel before it is used. If SDP is used for signalling, = this negotiation MUST use the attributes defined in RFC5761. >> >>=20 >> >> OLD: >> >>=20 >> >> implementations are also REQUIRED to support RTP and RTCP sent on = separate transport-layer flows. >> >>=20 >> >> NEW: >> >>=20 >> >> Implementations MAY support RTP and RTCP sent on separate = transport-layer flows. They MAY also refuse to do so, in which case any = negotiation that results in multiplexing not being negotiated is treated = as a failure. >> >>=20 >> >> If do not agree with this change please post a reply to this = message with a reason why by December 18th. >> >>=20 >> >> Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=E2=80=99s = queue, to incorporate this change our AD is going to need to pull it = back from the RFC-editor=E2=80=99s queue and re-run the IETF LC but = that=E2=80=99s only going to happen once we confirm the room=E2=80=99s = consensus. >> >>=20 >> >> the chairs, >> >> c/s/t >> >> _______________________________________________ >> >> 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 >> Colin Perkins >> https://csperkins.org/ >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_88F3C0DB-2812-40B2-9877-76413494FE77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
To confirm, this would give the following = change to the rtp-usage draft:

--- draft-ietf-rtcweb-rtp-usage.xml (revision = 1071)
+++= draft-ietf-rtcweb-rtp-usage.xml (working copy)
@@ -10,7 +10,7 = @@
 <?rfc inline=3D"yes"?>
 <?rfc = compact=3D"yes"?>
 <?rfc subcompact=3D"no"?>
-<rfc = category=3D"std" docName=3D"draft-ietf-rtcweb-rtp-usage-25" = ipr=3D"trust200902">
+<rfc category=3D"std" = docName=3D"draft-ietf-rtcweb-rtp-usage-26" = ipr=3D"trust200902">
   <front>
     <title = abbrev=3D"RTP for WebRTC">Web Real-Time Communication (WebRTC): = Media
     Transport and Use of = RTP</title>
@@ -71,7 +71,7 @@
       = </address>
     </author>

 

-    <date day=3D"12" = month=3D"June" year=3D"2015" />
+    <date day=3D"21" = month=3D"December" year=3D"2015" />

 

     = <workgroup>RTCWEB Working Group</workgroup>

 

@@ -483,9 +483,13 = @@
         = target=3D"RFC5761"></xref>. Such RTP and RTCP multiplexing MUST = be
         negotiated in the = signalling channel before it is used. If SDP is used
   =       for signalling, this negotiation MUST use the = attributes defined in
-        <xref = target=3D"RFC5761"></xref>. For backwards = compatibility,
-        implementations are also = REQUIRED to support RTP and RTCP sent on
-        separate = transport-layer flows.</t>
+        <xref = target=3D"RFC5761"></xref>.  Implementations MAY support = RTP and
+        RTCP sent on separate = transport-layer flows. They MAY also refuse to
+        do = so, in which case any negotiation that results in multiplexing = not
+        being negotiated is treated as a = failure. If an implementation does 
+        not = support RTP and RTCP sent on separate transport-layer flows, = it 
+        MUST indicate that using the = mechanism defined in 
+        <xref = target=3D"I-D.holmberg-mmusic-mux-exclusive"/>.</t>

 

   =       <t>Note that the use of RTP and RTCP = multiplexed onto a single
         transport-layer = flow ensures that there is occasional traffic sent on
@@ -2037,6 = +2041,8 @@

 

       <?rfc = include=3D'reference.I-D.ietf-avtcore-rtp-topologies-update'?>

 

+    =   <?rfc = include=3D'reference.I-D.holmberg-mmusic-mux-exclusive'?>
+
   =     <?rfc = include=3D'reference.W3C.WD-webrtc-20130910'?>

 

       <?rfc = include=3D'reference.W3C.WD-mediacapture-streams-20130903'?>



On 17 Dec 2015, at 09:53, Colin Perkins = <csp@csperkins.org> wrote:

That text is = fine with me - any other views?
Colin


On 15 = Dec 2015, at 10:22, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Text proposal(<new></new>)
 
Regards,
 
Christer
 
---------------------------------
 
4.5.  RTP = and RTCP Multiplexing
 
   Historically, RTP and RTCP have been run on = separate transport layer
   flows (e.g., two UDP ports for each RTP session, = one port for RTP and
   one port for RTCP).  With the increased use = of Network Address/Port
   Translation (NAT/NAPT) this has become = problematic, since maintaining
   multiple NAT bindings can be costly.  It = also complicates firewall
   administration, since multiple ports need to be = opened to allow RTP
   traffic.  To reduce these costs and session = set-up times,
   implementations are REQUIRED to support = multiplexing RTP data packets
   and RTCP control packets on a single = transport-layer flow [RFC5761].
   Such RTP and RTCP multiplexing MUST be = negotiated in the signalling
   channel before it is used.  If SDP is used = for signalling, this
   negotiation MUST use the attributes defined in = [RFC5761].
   <new>If an implementation does not =  support RTP and RTCP sent on
   separate transport-layer flows, it MUST = indicate that using the mechanism
   defined in = [reference-to-draft-mux-exclusive]</new>. For
   backwards compatibility, implementations MAY = support RTP and RTCP
   sent on separate transport-layer flows. = They MAY also refuse to do so, in
   which case any negotiation that results in = multiplexing not being negotiated
   is treated as a failure.
  
   Note = that the use of RTP and RTCP multiplexed onto a single
   = transport-layer flow ensures that there is occasional traffic sent = on
   = that port, even if there is no active media traffic.  This can = be
   = useful to keep NAT bindings alive [RFC6263].
 
---------------------------------
 
 
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: 15. joulukuuta 2015 6:39
To: Colin Perkins; Bernard = Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming = consensus to change draft-ietf-rtcweb-rtp-usage
 
Hi,

I'll think of some text, but = we'd need to reference draft-mux-exclusive for the case when fallback to = non-mux is not supported.

Regards,

Christer

Regards,

Christer

Sent from my Windows Phone

From: Colin Perkins
Sent: =E2=80=8E15/=E2=80=8E12/=E2=80=8E2015 00:49
To: Bernard Aboba
Cc: Christer Holmberg; rtcweb@ietf.org
Subject: Re: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage

Can you = suggest explicit text changes?

Colin



> On 14 Dec = 2015, at 22:35, Bernard Aboba <bernard.aboba@gmail.com> = wrote:
> 
> I = second Christer's suggestion. Only citing RFC 5761 and not = draft-holmberg-mmusic-mux-exclusive will have nasty side effects like = having to gather both RTP and RTCP ICE candidates in an Offer even if = the Offerer exclusively supports mux. We need the cleaner solution that = his draft provides.
> 
>> On = Dec 14, 2015, at 9:36 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>> 
>> Hi,
>> 
>> I = don't disagree with the change.
>> 
>> = However, if you do the change, then the following statement ("Intro") in = the draft is not correct:
>> 
>> = "If SDP is used for signalling, this negotiation MUST use the = attributes defined in [RFC5761]."
>> 
>> = Because, RFC 5761 requires support of fallback to non-mux, and it also = requires ICE RTCP candidates when RTCP is used.
>> 
>> I have suggested a mechanism = (draft-holmberg-mmusic-mux-exclusive) on how to negotiate/indicate = support when fallback to non-mux is NOT supported.
>> 
>> Regards,
>> 
>> = Christer
>> 
>> 
>> 
>> = -----Original Message-----
>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sean = Turner
>> Sent: 14. joulukuuta 2015 16:24
>> To: rtcweb@ietf.org
>> = Subject: [rtcweb] confirming consensus to change = draft-ietf-rtcweb-rtp-usage
>> 
>> In = August there was a thread "Do we have consensus on not requiring = rtcp-non-mux=E2=80=9D that resulted in proposed changes to = draft-ietf-rtcweb-rtp-usage, seehttps://www.ietf.org/proceedings/94/slides/slides-94-rtcweb-4.p= df. This email is to confirm the consensus we had in the room at = IETF 94 to make the following change in s4.5 of = draft-ietf-rtcweb-rtp-usage:
>> 
>> = Intro (for context):
>> 
>> = Such RTP and RTCP multiplexing MUST be negotiated in the signalling = channel before it is used. If SDP is used  for signalling, this = negotiation MUST use the attributes defined in RFC5761.
>> 
>> OLD:
>> 
>> = implementations are also REQUIRED to support RTP and RTCP sent on = separate transport-layer flows.
>> 
>> = NEW:
>> 
>> = Implementations MAY support RTP and RTCP sent on separate = transport-layer flows. They MAY also refuse to do so, in which case any = negotiation that results in multiplexing not being negotiated is treated = as a failure.
>> 
>> If = do not agree with this change please post a reply to this message with a = reason why by December 18th.
>> 
>> = Because draft-ietf-rtcweb-rtp-usage is in the RFC editor=E2=80=99s = queue, to incorporate this change our AD is going to need to pull it = back from the RFC-editor=E2=80=99s queue and re-run the IETF LC but = that=E2=80=99s only going to happen once we confirm the room=E2=80=99s = consensus.
>> 
>> the = chairs,
>> c/s/t
>> = _______________________________________________
>> = 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



-- 
Colin = Perkins
https://csperkins.org/




-- 
Colin Perkins
https://csperkins.org/






-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_88F3C0DB-2812-40B2-9877-76413494FE77-- From nobody Thu Dec 17 05:17:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC951B2CE9 for ; Thu, 17 Dec 2015 05:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.152 X-Spam-Level: X-Spam-Status: No, score=-5.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhr9JJNxwt8t for ; Thu, 17 Dec 2015 05:17:22 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B291B2CE8 for ; Thu, 17 Dec 2015 05:17:21 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 59CFA3A5353EF; Thu, 17 Dec 2015 13:17:16 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tBHDHACS005560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Dec 2015 14:17:18 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 17 Dec 2015 14:17:15 +0100 From: "DRAGE, Keith (Keith)" To: Colin Perkins , Christer Holmberg Thread-Topic: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage Thread-Index: AQHROLDrbqnv+x4WL02Mdo1W/4cBC57O4XKAgABG9LA= Date: Thu, 17 Dec 2015 13:17:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE25722@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B37CD6CF7@ESESSMB209.ericsson.se> <91DC5AB0-37FD-4867-BCAE-C670FE2BF89E@gmail.com> <7594FB04B1934943A5C02806D1A2204B37CDB453@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37CDD271@ESESSMB209.ericsson.se> <3F5DBD22-AB47-4796-83FE-7B924115AD61@csperkins.org> In-Reply-To: <3F5DBD22-AB47-4796-83FE-7B924115AD61@csperkins.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.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADE25722FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming consensus to change draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 13:17:26 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADE25722FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpZiB0aGUgd29yZCDigJxmYWlsdXJl4oCdIGlzIHVzZWQsIHlvdSBuZWVkIHRvIHF1 YW50aWZ5IHdoYXQgaXQgbWVhbnMuIEZvciBleGFtcGxlLCBldmVuIHdpdGggdGhlc2Ugd29yZHMs IEkgYXNzdW1lIHRoZSBzZXNzaW9uIGRvZXMgbm90IChhbmQgaXMgbm90IGludGVuZGVkIHRvKSBm YWlsLCBhbmQgdGhlIFNEUCBuZWdvdGlhdGlvbiBhcyBhIHdob2xlIGRvZXMgbm90IGZhaWwuIE5v dCBldmVuIHN1cmUgdGhlIGVudGlyZSBtZWRpYSBsaW5lIG5lZ290aWF0aW9uIGZhaWxzLg0KDQpL ZWl0aA0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIENvbGluIFBlcmtpbnMNClNlbnQ6IDE3IERlY2VtYmVyIDIwMTUgMTA6MDENClRv OiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFty dGN3ZWJdIGNvbmZpcm1pbmcgY29uc2Vuc3VzIHRvIGNoYW5nZSBkcmFmdC1pZXRmLXJ0Y3dlYi1y dHAtdXNhZ2UNCg0KVG8gY29uZmlybSwgdGhpcyB3b3VsZCBnaXZlIHRoZSBmb2xsb3dpbmcgY2hh bmdlIHRvIHRoZSBydHAtdXNhZ2UgZHJhZnQ6DQoNCi0tLSBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAt dXNhZ2UueG1sICAgICAocmV2aXNpb24gMTA3MSkNCisrKyBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAt dXNhZ2UueG1sICAod29ya2luZyBjb3B5KQ0KQEAgLTEwLDcgKzEwLDcgQEANCiA8P3JmYyBpbmxp bmU9InllcyI/Pg0KIDw/cmZjIGNvbXBhY3Q9InllcyI/Pg0KIDw/cmZjIHN1YmNvbXBhY3Q9Im5v Ij8+DQotPHJmYyBjYXRlZ29yeT0ic3RkIiBkb2NOYW1lPSJkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAt dXNhZ2UtMjUiIGlwcj0idHJ1c3QyMDA5MDIiPg0KKzxyZmMgY2F0ZWdvcnk9InN0ZCIgZG9jTmFt ZT0iZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlLTI2IiBpcHI9InRydXN0MjAwOTAyIj4NCiAg IDxmcm9udD4NCiAgICAgPHRpdGxlIGFiYnJldj0iUlRQIGZvciBXZWJSVEMiPldlYiBSZWFsLVRp bWUgQ29tbXVuaWNhdGlvbiAoV2ViUlRDKTogTWVkaWENCiAgICAgVHJhbnNwb3J0IGFuZCBVc2Ug b2YgUlRQPC90aXRsZT4NCkBAIC03MSw3ICs3MSw3IEBADQogICAgICAgPC9hZGRyZXNzPg0KICAg ICA8L2F1dGhvcj4NCg0KLSAgICA8ZGF0ZSBkYXk9IjEyIiBtb250aD0iSnVuZSIgeWVhcj0iMjAx NSIgLz4NCisgICAgPGRhdGUgZGF5PSIyMSIgbW9udGg9IkRlY2VtYmVyIiB5ZWFyPSIyMDE1IiAv Pg0KDQogICAgIDx3b3JrZ3JvdXA+UlRDV0VCIFdvcmtpbmcgR3JvdXA8L3dvcmtncm91cD4NCg0K QEAgLTQ4Myw5ICs0ODMsMTMgQEANCiAgICAgICAgIHRhcmdldD0iUkZDNTc2MSI+PC94cmVmPi4g U3VjaCBSVFAgYW5kIFJUQ1AgbXVsdGlwbGV4aW5nIE1VU1QgYmUNCiAgICAgICAgIG5lZ290aWF0 ZWQgaW4gdGhlIHNpZ25hbGxpbmcgY2hhbm5lbCBiZWZvcmUgaXQgaXMgdXNlZC4gSWYgU0RQIGlz IHVzZWQNCiAgICAgICAgIGZvciBzaWduYWxsaW5nLCB0aGlzIG5lZ290aWF0aW9uIE1VU1QgdXNl IHRoZSBhdHRyaWJ1dGVzIGRlZmluZWQgaW4NCi0gICAgICAgIDx4cmVmIHRhcmdldD0iUkZDNTc2 MSI+PC94cmVmPi4gRm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LA0KLSAgICAgICAgaW1wbGVt ZW50YXRpb25zIGFyZSBhbHNvIFJFUVVJUkVEIHRvIHN1cHBvcnQgUlRQIGFuZCBSVENQIHNlbnQg b24NCi0gICAgICAgIHNlcGFyYXRlIHRyYW5zcG9ydC1sYXllciBmbG93cy48L3Q+DQorICAgICAg ICA8eHJlZiB0YXJnZXQ9IlJGQzU3NjEiPjwveHJlZj4uICBJbXBsZW1lbnRhdGlvbnMgTUFZIHN1 cHBvcnQgUlRQIGFuZA0KKyAgICAgICAgUlRDUCBzZW50IG9uIHNlcGFyYXRlIHRyYW5zcG9ydC1s YXllciBmbG93cy4gVGhleSBNQVkgYWxzbyByZWZ1c2UgdG8NCisgICAgICAgIGRvIHNvLCBpbiB3 aGljaCBjYXNlIGFueSBuZWdvdGlhdGlvbiB0aGF0IHJlc3VsdHMgaW4gbXVsdGlwbGV4aW5nIG5v dA0KKyAgICAgICAgYmVpbmcgbmVnb3RpYXRlZCBpcyB0cmVhdGVkIGFzIGEgZmFpbHVyZS4gSWYg YW4gaW1wbGVtZW50YXRpb24gZG9lcw0KKyAgICAgICAgbm90IHN1cHBvcnQgUlRQIGFuZCBSVENQ IHNlbnQgb24gc2VwYXJhdGUgdHJhbnNwb3J0LWxheWVyIGZsb3dzLCBpdA0KKyAgICAgICAgTVVT VCBpbmRpY2F0ZSB0aGF0IHVzaW5nIHRoZSBtZWNoYW5pc20gZGVmaW5lZCBpbg0KKyAgICAgICAg PHhyZWYgdGFyZ2V0PSJJLUQuaG9sbWJlcmctbW11c2ljLW11eC1leGNsdXNpdmUiLz4uPC90Pg0K DQogICAgICAgICA8dD5Ob3RlIHRoYXQgdGhlIHVzZSBvZiBSVFAgYW5kIFJUQ1AgbXVsdGlwbGV4 ZWQgb250byBhIHNpbmdsZQ0KICAgICAgICAgdHJhbnNwb3J0LWxheWVyIGZsb3cgZW5zdXJlcyB0 aGF0IHRoZXJlIGlzIG9jY2FzaW9uYWwgdHJhZmZpYyBzZW50IG9uDQpAQCAtMjAzNyw2ICsyMDQx LDggQEANCg0KICAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5JLUQuaWV0Zi1hdnRjb3Jl LXJ0cC10b3BvbG9naWVzLXVwZGF0ZSc/Pg0KDQorICAgICAgPD9yZmMgaW5jbHVkZT0ncmVmZXJl bmNlLkktRC5ob2xtYmVyZy1tbXVzaWMtbXV4LWV4Y2x1c2l2ZSc/Pg0KKw0KICAgICAgIDw/cmZj IGluY2x1ZGU9J3JlZmVyZW5jZS5XM0MuV0Qtd2VicnRjLTIwMTMwOTEwJz8+DQoNCiAgICAgICA8 P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuVzNDLldELW1lZGlhY2FwdHVyZS1zdHJlYW1zLTIwMTMw OTAzJz8+DQoNCg0KDQpPbiAxNyBEZWMgMjAxNSwgYXQgMDk6NTMsIENvbGluIFBlcmtpbnMgPGNz cEBjc3BlcmtpbnMub3JnPG1haWx0bzpjc3BAY3NwZXJraW5zLm9yZz4+IHdyb3RlOg0KDQpUaGF0 IHRleHQgaXMgZmluZSB3aXRoIG1lIC0gYW55IG90aGVyIHZpZXdzPw0KQ29saW4NCg0KDQpPbiAx NSBEZWMgMjAxNSwgYXQgMTA6MjIsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KDQpUZXh0IHByb3Bvc2FsKDxuZXc+PC9uZXc+KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KNC41LiAgUlRQIGFuZCBS VENQIE11bHRpcGxleGluZw0KDQogICBIaXN0b3JpY2FsbHksIFJUUCBhbmQgUlRDUCBoYXZlIGJl ZW4gcnVuIG9uIHNlcGFyYXRlIHRyYW5zcG9ydCBsYXllcg0KICAgZmxvd3MgKGUuZy4sIHR3byBV RFAgcG9ydHMgZm9yIGVhY2ggUlRQIHNlc3Npb24sIG9uZSBwb3J0IGZvciBSVFAgYW5kDQogICBv bmUgcG9ydCBmb3IgUlRDUCkuICBXaXRoIHRoZSBpbmNyZWFzZWQgdXNlIG9mIE5ldHdvcmsgQWRk cmVzcy9Qb3J0DQogICBUcmFuc2xhdGlvbiAoTkFUL05BUFQpIHRoaXMgaGFzIGJlY29tZSBwcm9i bGVtYXRpYywgc2luY2UgbWFpbnRhaW5pbmcNCiAgIG11bHRpcGxlIE5BVCBiaW5kaW5ncyBjYW4g YmUgY29zdGx5LiAgSXQgYWxzbyBjb21wbGljYXRlcyBmaXJld2FsbA0KICAgYWRtaW5pc3RyYXRp b24sIHNpbmNlIG11bHRpcGxlIHBvcnRzIG5lZWQgdG8gYmUgb3BlbmVkIHRvIGFsbG93IFJUUA0K ICAgdHJhZmZpYy4gIFRvIHJlZHVjZSB0aGVzZSBjb3N0cyBhbmQgc2Vzc2lvbiBzZXQtdXAgdGlt ZXMsDQogICBpbXBsZW1lbnRhdGlvbnMgYXJlIFJFUVVJUkVEIHRvIHN1cHBvcnQgbXVsdGlwbGV4 aW5nIFJUUCBkYXRhIHBhY2tldHMNCiAgIGFuZCBSVENQIGNvbnRyb2wgcGFja2V0cyBvbiBhIHNp bmdsZSB0cmFuc3BvcnQtbGF5ZXIgZmxvdyBbUkZDNTc2MV0uDQogICBTdWNoIFJUUCBhbmQgUlRD UCBtdWx0aXBsZXhpbmcgTVVTVCBiZSBuZWdvdGlhdGVkIGluIHRoZSBzaWduYWxsaW5nDQogICBj aGFubmVsIGJlZm9yZSBpdCBpcyB1c2VkLiAgSWYgU0RQIGlzIHVzZWQgZm9yIHNpZ25hbGxpbmcs IHRoaXMNCiAgIG5lZ290aWF0aW9uIE1VU1QgdXNlIHRoZSBhdHRyaWJ1dGVzIGRlZmluZWQgaW4g W1JGQzU3NjFdLg0KICAgPG5ldz5JZiBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCAgc3VwcG9y dCBSVFAgYW5kIFJUQ1Agc2VudCBvbg0KICAgc2VwYXJhdGUgdHJhbnNwb3J0LWxheWVyIGZsb3dz LCBpdCBNVVNUIGluZGljYXRlIHRoYXQgdXNpbmcgdGhlIG1lY2hhbmlzbQ0KICAgZGVmaW5lZCBp biBbcmVmZXJlbmNlLXRvLWRyYWZ0LW11eC1leGNsdXNpdmVdPC9uZXc+LiBGb3INCiAgIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5LCBpbXBsZW1lbnRhdGlvbnMgTUFZIHN1cHBvcnQgUlRQIGFuZCBS VENQDQogICBzZW50IG9uIHNlcGFyYXRlIHRyYW5zcG9ydC1sYXllciBmbG93cy4gVGhleSBNQVkg YWxzbyByZWZ1c2UgdG8gZG8gc28sIGluDQogICB3aGljaCBjYXNlIGFueSBuZWdvdGlhdGlvbiB0 aGF0IHJlc3VsdHMgaW4gbXVsdGlwbGV4aW5nIG5vdCBiZWluZyBuZWdvdGlhdGVkDQogICBpcyB0 cmVhdGVkIGFzIGEgZmFpbHVyZS4NCg0KICAgTm90ZSB0aGF0IHRoZSB1c2Ugb2YgUlRQIGFuZCBS VENQIG11bHRpcGxleGVkIG9udG8gYSBzaW5nbGUNCiAgIHRyYW5zcG9ydC1sYXllciBmbG93IGVu c3VyZXMgdGhhdCB0aGVyZSBpcyBvY2Nhc2lvbmFsIHRyYWZmaWMgc2VudCBvbg0KICAgdGhhdCBw b3J0LCBldmVuIGlmIHRoZXJlIGlzIG5vIGFjdGl2ZSBtZWRpYSB0cmFmZmljLiAgVGhpcyBjYW4g YmUNCiAgIHVzZWZ1bCB0byBrZWVwIE5BVCBiaW5kaW5ncyBhbGl2ZSBbUkZDNjI2M10uDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcN ClNlbnQ6IDE1LiBqb3VsdWt1dXRhIDIwMTUgNjozOQ0KVG86IENvbGluIFBlcmtpbnM7IEJlcm5h cmQgQWJvYmENCkNjOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBjb25maXJtaW5nIGNvbnNlbnN1cyB0byBjaGFuZ2UgZHJhZnQt aWV0Zi1ydGN3ZWItcnRwLXVzYWdlDQoNCkhpLA0KDQpJJ2xsIHRoaW5rIG9mIHNvbWUgdGV4dCwg YnV0IHdlJ2QgbmVlZCB0byByZWZlcmVuY2UgZHJhZnQtbXV4LWV4Y2x1c2l2ZSBmb3IgdGhlIGNh c2Ugd2hlbiBmYWxsYmFjayB0byBub24tbXV4IGlzIG5vdCBzdXBwb3J0ZWQuDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5k b3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQ29saW4g UGVya2luczxtYWlsdG86Y3NwQGNzcGVya2lucy5vcmc+DQpTZW50OiDigI4xNS/igI4xMi/igI4y MDE1IDAwOjQ5DQpUbzogQmVybmFyZCBBYm9iYTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5j b20+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtydGN3ZWJdIGNvbmZpcm1pbmcgY29uc2Vuc3VzIHRvIGNoYW5nZSBkcmFmdC1pZXRm LXJ0Y3dlYi1ydHAtdXNhZ2UNCkNhbiB5b3Ugc3VnZ2VzdCBleHBsaWNpdCB0ZXh0IGNoYW5nZXM/ DQoNCkNvbGluDQoNCg0KDQo+IE9uIDE0IERlYyAyMDE1LCBhdCAyMjozNSwgQmVybmFyZCBBYm9i YSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29t Pj4gd3JvdGU6DQo+DQo+IEkgc2Vjb25kIENocmlzdGVyJ3Mgc3VnZ2VzdGlvbi4gT25seSBjaXRp bmcgUkZDIDU3NjEgYW5kIG5vdCBkcmFmdC1ob2xtYmVyZy1tbXVzaWMtbXV4LWV4Y2x1c2l2ZSB3 aWxsIGhhdmUgbmFzdHkgc2lkZSBlZmZlY3RzIGxpa2UgaGF2aW5nIHRvIGdhdGhlciBib3RoIFJU UCBhbmQgUlRDUCBJQ0UgY2FuZGlkYXRlcyBpbiBhbiBPZmZlciBldmVuIGlmIHRoZSBPZmZlcmVy IGV4Y2x1c2l2ZWx5IHN1cHBvcnRzIG11eC4gV2UgbmVlZCB0aGUgY2xlYW5lciBzb2x1dGlvbiB0 aGF0IGhpcyBkcmFmdCBwcm92aWRlcy4NCj4NCj4+IE9uIERlYyAxNCwgMjAxNSwgYXQgOTozNiBB TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+Pg0KPj4gSGksDQo+ Pg0KPj4gSSBkb24ndCBkaXNhZ3JlZSB3aXRoIHRoZSBjaGFuZ2UuDQo+Pg0KPj4gSG93ZXZlciwg aWYgeW91IGRvIHRoZSBjaGFuZ2UsIHRoZW4gdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgKCJJbnRy byIpIGluIHRoZSBkcmFmdCBpcyBub3QgY29ycmVjdDoNCj4+DQo+PiAgIklmIFNEUCBpcyB1c2Vk IGZvciBzaWduYWxsaW5nLCB0aGlzIG5lZ290aWF0aW9uIE1VU1QgdXNlIHRoZSBhdHRyaWJ1dGVz IGRlZmluZWQgaW4gW1JGQzU3NjFdLiINCj4+DQo+PiBCZWNhdXNlLCBSRkMgNTc2MSByZXF1aXJl cyBzdXBwb3J0IG9mIGZhbGxiYWNrIHRvIG5vbi1tdXgsIGFuZCBpdCBhbHNvIHJlcXVpcmVzIElD RSBSVENQIGNhbmRpZGF0ZXMgd2hlbiBSVENQIGlzIHVzZWQuDQo+Pg0KPj4gSSBoYXZlIHN1Z2dl c3RlZCBhIG1lY2hhbmlzbSAoZHJhZnQtaG9sbWJlcmctbW11c2ljLW11eC1leGNsdXNpdmUpIG9u IGhvdyB0byBuZWdvdGlhdGUvaW5kaWNhdGUgc3VwcG9ydCB3aGVuIGZhbGxiYWNrIHRvIG5vbi1t dXggaXMgTk9UIHN1cHBvcnRlZC4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+ Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogcnRjd2Vi IFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTZWFuIFR1cm5l cg0KPj4gU2VudDogMTQuIGpvdWx1a3V1dGEgMjAxNSAxNjoyNA0KPj4gVG86IHJ0Y3dlYkBpZXRm Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KPj4gU3ViamVjdDogW3J0Y3dlYl0gY29uZmly bWluZyBjb25zZW5zdXMgdG8gY2hhbmdlIGRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZQ0KPj4N Cj4+IEluIEF1Z3VzdCB0aGVyZSB3YXMgYSB0aHJlYWQgIkRvIHdlIGhhdmUgY29uc2Vuc3VzIG9u IG5vdCByZXF1aXJpbmcgcnRjcC1ub24tbXV44oCdIHRoYXQgcmVzdWx0ZWQgaW4gcHJvcG9zZWQg Y2hhbmdlcyB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UsIHNlZWh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzk0L3NsaWRlcy9zbGlkZXMtOTQtcnRjd2ViLTQucGRmLiBUaGlz IGVtYWlsIGlzIHRvIGNvbmZpcm0gdGhlIGNvbnNlbnN1cyB3ZSBoYWQgaW4gdGhlIHJvb20gYXQg SUVURiA5NCB0byBtYWtlIHRoZSBmb2xsb3dpbmcgY2hhbmdlIGluIHM0LjUgb2YgZHJhZnQtaWV0 Zi1ydGN3ZWItcnRwLXVzYWdlOg0KPj4NCj4+IEludHJvIChmb3IgY29udGV4dCk6DQo+Pg0KPj4g U3VjaCBSVFAgYW5kIFJUQ1AgbXVsdGlwbGV4aW5nIE1VU1QgYmUgbmVnb3RpYXRlZCBpbiB0aGUg c2lnbmFsbGluZyBjaGFubmVsIGJlZm9yZSBpdCBpcyB1c2VkLiBJZiBTRFAgaXMgdXNlZCAgZm9y IHNpZ25hbGxpbmcsIHRoaXMgbmVnb3RpYXRpb24gTVVTVCB1c2UgdGhlIGF0dHJpYnV0ZXMgZGVm aW5lZCBpbiBSRkM1NzYxLg0KPj4NCj4+IE9MRDoNCj4+DQo+PiBpbXBsZW1lbnRhdGlvbnMgYXJl IGFsc28gUkVRVUlSRUQgdG8gc3VwcG9ydCBSVFAgYW5kIFJUQ1Agc2VudCBvbiBzZXBhcmF0ZSB0 cmFuc3BvcnQtbGF5ZXIgZmxvd3MuDQo+Pg0KPj4gTkVXOg0KPj4NCj4+IEltcGxlbWVudGF0aW9u cyBNQVkgc3VwcG9ydCBSVFAgYW5kIFJUQ1Agc2VudCBvbiBzZXBhcmF0ZSB0cmFuc3BvcnQtbGF5 ZXIgZmxvd3MuIFRoZXkgTUFZIGFsc28gcmVmdXNlIHRvIGRvIHNvLCBpbiB3aGljaCBjYXNlIGFu eSBuZWdvdGlhdGlvbiB0aGF0IHJlc3VsdHMgaW4gbXVsdGlwbGV4aW5nIG5vdCBiZWluZyBuZWdv dGlhdGVkIGlzIHRyZWF0ZWQgYXMgYSBmYWlsdXJlLg0KPj4NCj4+IElmIGRvIG5vdCBhZ3JlZSB3 aXRoIHRoaXMgY2hhbmdlIHBsZWFzZSBwb3N0IGEgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIHdpdGgg YSByZWFzb24gd2h5IGJ5IERlY2VtYmVyIDE4dGguDQo+Pg0KPj4gQmVjYXVzZSBkcmFmdC1pZXRm LXJ0Y3dlYi1ydHAtdXNhZ2UgaXMgaW4gdGhlIFJGQyBlZGl0b3LigJlzIHF1ZXVlLCB0byBpbmNv cnBvcmF0ZSB0aGlzIGNoYW5nZSBvdXIgQUQgaXMgZ29pbmcgdG8gbmVlZCB0byBwdWxsIGl0IGJh Y2sgZnJvbSB0aGUgUkZDLWVkaXRvcuKAmXMgcXVldWUgYW5kIHJlLXJ1biB0aGUgSUVURiBMQyBi dXQgdGhhdOKAmXMgb25seSBnb2luZyB0byBoYXBwZW4gb25jZSB3ZSBjb25maXJtIHRoZSByb29t 4oCZcyBjb25zZW5zdXMuDQo+Pg0KPj4gdGhlIGNoYWlycywNCj4+IGMvcy90DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRjd2ViIG1haWxp bmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHJ0Y3dlYiBtYWlsaW5n IGxpc3QNCj4+IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcg bGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQoNCi0tDQpDb2xpbiBQ ZXJraW5zDQpodHRwczovL2NzcGVya2lucy5vcmcvDQoNCg0KLS0NCkNvbGluIFBlcmtpbnMNCmh0 dHBzOi8vY3NwZXJraW5zLm9yZy8NCg0KDQoNCg0KDQotLQ0KQ29saW4gUGVya2lucw0KaHR0cHM6 Ly9jc3BlcmtpbnMub3JnLw0KDQoNCg0K --_000_949EF20990823C4C85C18D59AA11AD8BADE25722FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNp ZGEgU2FucyBUeXBld3JpdGVyIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWIt c3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBs ZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1u YW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIHRoaW5rIGlmIHRoZSB3b3JkIOKAnGZhaWx1cmXigJ0gaXMgdXNlZCwgeW91IG5l ZWQgdG8gcXVhbnRpZnkgd2hhdCBpdCBtZWFucy4gRm9yIGV4YW1wbGUsIGV2ZW4gd2l0aCB0aGVz ZSB3b3JkcywgSSBhc3N1bWUgdGhlIHNlc3Npb24gZG9lcyBub3QgKGFuZCBpcyBub3QgaW50ZW5k ZWQNCiB0bykgZmFpbCwgYW5kIHRoZSBTRFAgbmVnb3RpYXRpb24gYXMgYSB3aG9sZSBkb2VzIG5v dCBmYWlsLiBOb3QgZXZlbiBzdXJlIHRoZSBlbnRpcmUgbWVkaWEgbGluZSBuZWdvdGlhdGlvbiBm YWlscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNvbGluIFBlcmtp bnM8YnI+DQo8Yj5TZW50OjwvYj4gMTcgRGVjZW1iZXIgMjAxNSAxMDowMTxicj4NCjxiPlRvOjwv Yj4gQ2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gY29uZmlybWluZyBjb25zZW5zdXMgdG8gY2hh bmdlIGRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBjb25maXJtLCB0aGlzIHdvdWxkIGdpdmUg dGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIHJ0cC11c2FnZSBkcmFmdDo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLSBkcmFm dC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UueG1sPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4ocmV2aXNpb24gMTA3MSk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7JiM0MzsmIzQz OyBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UueG1sPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsNCjwvc3Bhbj4od29ya2luZyBjb3B5KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QEAgLTEwLDcgJiM0MzsxMCw3IEBAPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbHQ7 P3JmYyBpbmxpbmU9JnF1b3Q7eWVzJnF1b3Q7PyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZsdDs/cmZjIGNvbXBhY3Q9JnF1b3Q7 eWVzJnF1b3Q7PyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZsdDs/cmZjIHN1YmNvbXBhY3Q9JnF1b3Q7bm8mcXVvdDs/Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZsdDty ZmMgY2F0ZWdvcnk9JnF1b3Q7c3RkJnF1b3Q7IGRvY05hbWU9JnF1b3Q7ZHJhZnQtaWV0Zi1ydGN3 ZWItcnRwLXVzYWdlLTI1JnF1b3Q7IGlwcj0mcXVvdDt0cnVzdDIwMDkwMiZxdW90OyZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7Jmx0 O3JmYyBjYXRlZ29yeT0mcXVvdDtzdGQmcXVvdDsgZG9jTmFtZT0mcXVvdDtkcmFmdC1pZXRmLXJ0 Y3dlYi1ydHAtdXNhZ2UtMjYmcXVvdDsgaXByPSZxdW90O3RydXN0MjAwOTAyJnF1b3Q7Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7ICZsdDtmcm9udCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsgJmx0O3RpdGxlIGFiYnJldj0mcXVv dDtSVFAgZm9yIFdlYlJUQyZxdW90OyZndDtXZWIgUmVhbC1UaW1lIENvbW11bmljYXRpb24gKFdl YlJUQyk6IE1lZGlhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7IFRyYW5zcG9ydCBhbmQgVXNlIG9mIFJUUCZsdDsv dGl0bGUmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5AQCAtNzEsNyAmIzQzOzcxLDcgQEA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDsvYWRk cmVzcyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsgJmx0Oy9hdXRob3ImZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtaW4taGVpZ2h0OiAxMXB4Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJm5ic3A7ICZu YnNwOyAmbHQ7ZGF0ZSBkYXk9JnF1b3Q7MTImcXVvdDsgbW9udGg9JnF1b3Q7SnVuZSZxdW90OyB5 ZWFyPSZxdW90OzIwMTUmcXVvdDsgLyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7Jm5ic3A7ICZuYnNwOyAmbHQ7ZGF0ZSBkYXk9JnF1 b3Q7MjEmcXVvdDsgbW9udGg9JnF1b3Q7RGVjZW1iZXImcXVvdDsgeWVhcj0mcXVvdDsyMDE1JnF1 b3Q7IC8mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtaW4taGVpZ2h0OiAxMXB4Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZsdDt3b3JrZ3JvdXAmZ3Q7UlRD V0VCIFdvcmtpbmcgR3JvdXAmbHQ7L3dvcmtncm91cCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1pbi1oZWlnaHQ6IDExcHgiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBAIC00ODMsOSAmIzQz OzQ4MywxMyBAQDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRhcmdldD0mcXVvdDtSRkM1 NzYxJnF1b3Q7Jmd0OyZsdDsveHJlZiZndDsuIFN1Y2ggUlRQIGFuZCBSVENQIG11bHRpcGxleGlu ZyBNVVNUIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmVnb3RpYXRlZCBpbiB0aGUg c2lnbmFsbGluZyBjaGFubmVsIGJlZm9yZSBpdCBpcyB1c2VkLiBJZiBTRFAgaXMgdXNlZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvciBzaWduYWxsaW5nLCB0aGlzIG5lZ290aWF0aW9u IE1VU1QgdXNlIHRoZSBhdHRyaWJ1dGVzIGRlZmluZWQgaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0O3hyZWYgdGFyZ2V0PSZxdW90O1JGQzU3NjEmcXVvdDsmZ3Q7Jmx0Oy94cmVmJmd0Oy4g Rm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbXBs ZW1lbnRhdGlvbnMgYXJlIGFsc28gUkVRVUlSRUQgdG8gc3VwcG9ydCBSVFAgYW5kIFJUQ1Agc2Vu dCBvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzZXBhcmF0ZSB0cmFuc3BvcnQtbGF5ZXIgZmxv d3MuJmx0Oy90Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+JiM0MzsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3hyZWYgdGFyZ2V0 PSZxdW90O1JGQzU3NjEmcXVvdDsmZ3Q7Jmx0Oy94cmVmJmd0Oy4mbmJzcDsgSW1wbGVtZW50YXRp b25zIE1BWSBzdXBwb3J0IFJUUCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJUQ1Ag c2VudCBvbiBzZXBhcmF0ZSB0cmFuc3BvcnQtbGF5ZXIgZmxvd3MuIFRoZXkgTUFZIGFsc28gcmVm dXNlIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mIzQzOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkbyBzbywgaW4gd2hpY2ggY2FzZSBh bnkgbmVnb3RpYXRpb24gdGhhdCByZXN1bHRzIGluIG11bHRpcGxleGluZyBub3Q8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGJlaW5nIG5lZ290aWF0ZWQgaXMgdHJlYXRlZCBhcyBhIGZhaWx1 cmUuIElmIGFuIGltcGxlbWVudGF0aW9uIGRvZXMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IG5vdCBzdXBwb3J0IFJUUCBhbmQgUlRDUCBzZW50IG9uIHNlcGFyYXRlIHRyYW5zcG9y dC1sYXllciBmbG93cywgaXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1VU1Qg aW5kaWNhdGUgdGhhdCB1c2luZyB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt4cmVmIHRhcmdldD0mcXVvdDtJLUQuaG9sbWJlcmct bW11c2ljLW11eC1leGNsdXNpdmUmcXVvdDsvJmd0Oy4mbHQ7L3QmZ3Q7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtaW4taGVpZ2h0OiAxMXB4Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3QmZ3Q7Tm90ZSB0aGF0IHRoZSB1c2Ugb2Yg UlRQIGFuZCBSVENQIG11bHRpcGxleGVkIG9udG8gYSBzaW5nbGU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB0cmFuc3BvcnQtbGF5ZXIgZmxvdyBlbnN1cmVzIHRoYXQgdGhlcmUgaXMgb2Nj YXNpb25hbCB0cmFmZmljIHNlbnQgb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkBAIC0yMDM3LDYgJiM0MzsyMDQxLDggQEA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1pbi1oZWlnaHQ6IDExcHgi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5JLUQuaWV0 Zi1hdnRjb3JlLXJ0cC10b3BvbG9naWVzLXVwZGF0ZSc/Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWluLWhlaWdodDogMTFweCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbHQ7P3JmYyBpbmNsdWRlPSdyZWZlcmVuY2UuSS1ELmhvbG1iZXJnLW1t dXNpYy1tdXgtZXhjbHVzaXZlJz8mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oz9yZmMg aW5jbHVkZT0ncmVmZXJlbmNlLlczQy5XRC13ZWJydGMtMjAxMzA5MTAnPyZndDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1pbi1oZWlnaHQ6IDEx cHgiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5XM0Mu V0QtbWVkaWFjYXB0dXJlLXN0cmVhbXMtMjAxMzA5MDMnPyZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgRGVjIDIwMTUs IGF0IDA5OjUzLCBDb2xpbiBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lu cy5vcmciPmNzcEBjc3BlcmtpbnMub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHRleHQgaXMgZmluZSB3aXRoIG1lIC0g YW55IG90aGVyIHZpZXdzPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNvbGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDE1IERlYyAyMDE1LCBhdCAxMDoyMiwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRleHQgcHJvcG9zYWwoJmx0O25ldyZndDsmbHQ7L25ldyZndDspPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NC41LiZuYnNwOyBSVFAgYW5kIFJU Q1AgTXVsdGlwbGV4aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsgSGlzdG9yaWNhbGx5LCBSVFAgYW5kIFJUQ1AgaGF2ZSBiZWVuIHJ1biBvbiBz ZXBhcmF0ZSB0cmFuc3BvcnQgbGF5ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGZsb3dzIChlLmcuLCB0d28gVURQIHBvcnRzIGZvciBl YWNoIFJUUCBzZXNzaW9uLCBvbmUgcG9ydCBmb3IgUlRQIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgb25lIHBvcnQgZm9yIFJUQ1Ap LiZuYnNwOyBXaXRoIHRoZSBpbmNyZWFzZWQgdXNlIG9mIE5ldHdvcmsgQWRkcmVzcy9Qb3J0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBU cmFuc2xhdGlvbiAoTkFUL05BUFQpIHRoaXMgaGFzIGJlY29tZSBwcm9ibGVtYXRpYywgc2luY2Ug bWFpbnRhaW5pbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7IG11bHRpcGxlIE5BVCBiaW5kaW5ncyBjYW4gYmUgY29zdGx5LiZuYnNwOyBJ dCBhbHNvIGNvbXBsaWNhdGVzIGZpcmV3YWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBhZG1pbmlzdHJhdGlvbiwgc2luY2UgbXVsdGlw bGUgcG9ydHMgbmVlZCB0byBiZSBvcGVuZWQgdG8gYWxsb3cgUlRQPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB0cmFmZmljLiZuYnNwOyBU byByZWR1Y2UgdGhlc2UgY29zdHMgYW5kIHNlc3Npb24gc2V0LXVwIHRpbWVzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50 YXRpb25zIGFyZSBSRVFVSVJFRCB0byBzdXBwb3J0IG11bHRpcGxleGluZyBSVFAgZGF0YSBwYWNr ZXRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBhbmQgUlRDUCBjb250cm9sIHBhY2tldHMgb24gYSBzaW5nbGUgdHJhbnNwb3J0LWxheWVy IGZsb3cgW1JGQzU3NjFdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsgU3VjaCBSVFAgYW5kIFJUQ1AgbXVsdGlwbGV4aW5nIE1VU1QgYmUg bmVnb3RpYXRlZCBpbiB0aGUgc2lnbmFsbGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgY2hhbm5lbCBiZWZvcmUgaXQgaXMgdXNlZC4m bmJzcDsgSWYgU0RQIGlzIHVzZWQgZm9yIHNpZ25hbGxpbmcsIHRoaXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG5lZ290aWF0aW9uIE1V U1QgdXNlIHRoZSBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gW1JGQzU3NjFdLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZsdDtuZXcmZ3Q7 SWYgYW4gaW1wbGVtZW50YXRpb24gZG9lcyBub3QgJm5ic3A7c3VwcG9ydCBSVFAgYW5kIFJUQ1Ag c2VudCBvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZu YnNwOyZuYnNwO3NlcGFyYXRlIHRyYW5zcG9ydC1sYXllciBmbG93cywgaXQgTVVTVCBpbmRpY2F0 ZSB0aGF0IHVzaW5nIHRoZSBtZWNoYW5pc208L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDtkZWZpbmVkIGluIFtyZWZlcmVuY2UtdG8tZHJh ZnQtbXV4LWV4Y2x1c2l2ZV0mbHQ7L25ldyZndDsuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Rm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgaW1wbGVtZW50YXRp b25zIE1BWSBzdXBwb3J0IFJUUCBhbmQgUlRDUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDtzZW50IG9uIHNlcGFyYXRlIHRyYW5z cG9ydC1sYXllciBmbG93cy4gVGhleSBNQVkgYWxzbyByZWZ1c2UgdG8gZG8gc28sIGluPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw O3doaWNoIGNhc2UgYW55IG5lZ290aWF0aW9uIHRoYXQgcmVzdWx0cyBpbiBtdWx0aXBsZXhpbmcg bm90IGJlaW5nIG5lZ290aWF0ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7aXMgdHJlYXRlZCBhcyBhIGZhaWx1cmUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDtOb3RlIHRoYXQgdGhlIHVzZSBvZiBSVFAgYW5kIFJUQ1AgbXVsdGlwbGV4ZWQgb250byBhIHNp bmdsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgdHJhbnNwb3J0LWxheWVyIGZsb3cgZW5zdXJlcyB0aGF0IHRoZXJlIGlzIG9jY2FzaW9u YWwgdHJhZmZpYyBzZW50IG9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyB0aGF0IHBvcnQsIGV2ZW4gaWYgdGhlcmUgaXMgbm8gYWN0aXZl IG1lZGlhIHRyYWZmaWMuJm5ic3A7IFRoaXMgY2FuIGJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB1c2VmdWwgdG8ga2VlcCBOQVQgYmlu ZGluZ3MgYWxpdmUgW1JGQzYyNjNdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cnRj d2ViDQogWzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9u IEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MTUuIGpvdWx1a3V1dGEgMjAxNSA2OjM5 PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5Db2xpbiBQZXJraW5zOyBCZXJuYXJkIEFib2JhPGJyPg0KPGI+Q2M6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3ZWJAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3J0Y3dlYl0gY29uZmlybWluZyBjb25z ZW5zdXMgdG8gY2hhbmdlIGRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SGksPGJyPg0KPGJyPg0KSSdsbCB0aGluayBvZiBzb21lIHRleHQsIGJ1dCB3ZSdkIG5lZWQgdG8g cmVmZXJlbmNlIGRyYWZ0LW11eC1leGNsdXNpdmUgZm9yIHRoZSBjYXNlIHdoZW4gZmFsbGJhY2sg dG8gbm9uLW11eCBpcyBub3Qgc3VwcG9ydGVkLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJy Pg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0K PGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86Y3Nw QGNzcGVya2lucy5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkNvbGluDQogUGVya2lu czwvc3Bhbj48L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ U2VudDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAjjE1L+KAjjEyL+KAjjIwMTUg MDA6NDk8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ubzo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+QmVybmFyZA0KIEFib2JhPC9z cGFuPjwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DYzo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkNocmlzdGVy DQogSG9sbWJlcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UmU6IFtydGN3ZWJdIGNvbmZpcm1pbmcgY29uc2Vuc3VzIHRvIGNoYW5n ZSBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkNhbiB5b3Ugc3VnZ2Vz dCBleHBsaWNpdCB0ZXh0IGNoYW5nZXM/PGJyPg0KPGJyPg0KQ29saW48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQomZ3Q7IE9uIDE0IERlYyAyMDE1LCBhdCAyMjozNSwgQmVybmFyZCBBYm9iYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjxicj4NCiZndDsgSSBzZWNvbmQgQ2hyaXN0ZXIncyBzdWdnZXN0aW9uLiBPbmx5IGNpdGluZyBS RkMgNTc2MSBhbmQgbm90IGRyYWZ0LWhvbG1iZXJnLW1tdXNpYy1tdXgtZXhjbHVzaXZlIHdpbGwg aGF2ZSBuYXN0eSBzaWRlIGVmZmVjdHMgbGlrZSBoYXZpbmcgdG8gZ2F0aGVyIGJvdGggUlRQIGFu ZCBSVENQIElDRSBjYW5kaWRhdGVzIGluIGFuIE9mZmVyIGV2ZW4gaWYgdGhlIE9mZmVyZXIgZXhj bHVzaXZlbHkgc3VwcG9ydHMgbXV4LiBXZSBuZWVkIHRoZSBjbGVhbmVyDQogc29sdXRpb24gdGhh dCBoaXMgZHJhZnQgcHJvdmlkZXMuPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyBPbiBEZWMgMTQsIDIwMTUsIGF0 IDk6MzYgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZn dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0K Jmd0OyZndDsgSGksPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgSSBkb24ndCBkaXNhZ3JlZSB3aXRoIHRo ZSBjaGFuZ2UuPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgSG93ZXZlciwgaWYgeW91IGRvIHRoZSBjaGFu Z2UsIHRoZW4gdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgKCZxdW90O0ludHJvJnF1b3Q7KSBpbiB0 aGUgZHJhZnQgaXMgbm90IGNvcnJlY3Q6PGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmbmJzcDsgJnF1b3Q7 SWYgU0RQIGlzIHVzZWQgZm9yIHNpZ25hbGxpbmcsIHRoaXMgbmVnb3RpYXRpb24gTVVTVCB1c2Ug dGhlIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiBbUkZDNTc2MV0uJnF1b3Q7PGJyPg0KJmd0OyZndDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0 OyZndDsgQmVjYXVzZSwgUkZDIDU3NjEgcmVxdWlyZXMgc3VwcG9ydCBvZiBmYWxsYmFjayB0byBu b24tbXV4LCBhbmQgaXQgYWxzbyByZXF1aXJlcyBJQ0UgUlRDUCBjYW5kaWRhdGVzIHdoZW4gUlRD UCBpcyB1c2VkLjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IEkgaGF2ZSBzdWdnZXN0ZWQgYSBtZWNoYW5p c20gKGRyYWZ0LWhvbG1iZXJnLW1tdXNpYy1tdXgtZXhjbHVzaXZlKSBvbiBob3cgdG8gbmVnb3Rp YXRlL2luZGljYXRlIHN1cHBvcnQgd2hlbiBmYWxsYmFjayB0byBub24tbXV4IGlzIE5PVCBzdXBw b3J0ZWQuPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyBD aHJpc3Rlcjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhhbGYgT2YgU2VhbiBUdXJu ZXI8YnI+DQomZ3Q7Jmd0OyBTZW50OiAxNC4gam91bHVrdXV0YSAyMDE1IDE2OjI0PGJyPg0KJmd0 OyZndDsgVG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KJmd0OyZndDsgU3ViamVjdDogW3J0 Y3dlYl0gY29uZmlybWluZyBjb25zZW5zdXMgdG8gY2hhbmdlIGRyYWZ0LWlldGYtcnRjd2ViLXJ0 cC11c2FnZTxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IEluIEF1Z3VzdCB0aGVyZSB3YXMgYSB0aHJlYWQg JnF1b3Q7RG8gd2UgaGF2ZSBjb25zZW5zdXMgb24gbm90IHJlcXVpcmluZyBydGNwLW5vbi1tdXji gJ0gdGhhdCByZXN1bHRlZCBpbiBwcm9wb3NlZCBjaGFuZ2VzIHRvIGRyYWZ0LWlldGYtcnRjd2Vi LXJ0cC11c2FnZSwgc2VlPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTQvc2xpZGVzL3NsaWRlcy05NC1ydGN3ZWItNC5wZGYiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L3NsaWRlcy9zbGlkZXMtOTQt cnRjd2ViLTQucGRmPC9zcGFuPjwvYT4uDQogVGhpcyBlbWFpbCBpcyB0byBjb25maXJtIHRoZSBj b25zZW5zdXMgd2UgaGFkIGluIHRoZSByb29tIGF0IElFVEYgOTQgdG8gbWFrZSB0aGUgZm9sbG93 aW5nIGNoYW5nZSBpbiBzNC41IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZTo8YnI+DQom Z3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQomZ3Q7Jmd0OyBJbnRybyAoZm9yIGNvbnRleHQpOjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IFN1 Y2ggUlRQIGFuZCBSVENQIG11bHRpcGxleGluZyBNVVNUIGJlIG5lZ290aWF0ZWQgaW4gdGhlIHNp Z25hbGxpbmcgY2hhbm5lbCBiZWZvcmUgaXQgaXMgdXNlZC4gSWYgU0RQIGlzIHVzZWQmbmJzcDsg Zm9yIHNpZ25hbGxpbmcsIHRoaXMgbmVnb3RpYXRpb24gTVVTVCB1c2UgdGhlIGF0dHJpYnV0ZXMg ZGVmaW5lZCBpbiBSRkM1NzYxLjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IE9MRDo8YnI+DQomZ3Q7Jmd0 OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQom Z3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbnMgYXJlIGFsc28gUkVRVUlSRUQgdG8gc3VwcG9ydCBSVFAg YW5kIFJUQ1Agc2VudCBvbiBzZXBhcmF0ZSB0cmFuc3BvcnQtbGF5ZXIgZmxvd3MuPGJyPg0KJmd0 OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KJmd0OyZndDsgTkVXOjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IEltcGxlbWVudGF0aW9ucyBNQVkg c3VwcG9ydCBSVFAgYW5kIFJUQ1Agc2VudCBvbiBzZXBhcmF0ZSB0cmFuc3BvcnQtbGF5ZXIgZmxv d3MuIFRoZXkgTUFZIGFsc28gcmVmdXNlIHRvIGRvIHNvLCBpbiB3aGljaCBjYXNlIGFueSBuZWdv dGlhdGlvbiB0aGF0IHJlc3VsdHMgaW4gbXVsdGlwbGV4aW5nIG5vdCBiZWluZyBuZWdvdGlhdGVk IGlzIHRyZWF0ZWQgYXMgYSBmYWlsdXJlLjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IElmIGRvIG5vdCBh Z3JlZSB3aXRoIHRoaXMgY2hhbmdlIHBsZWFzZSBwb3N0IGEgcmVwbHkgdG8gdGhpcyBtZXNzYWdl IHdpdGggYSByZWFzb24gd2h5IGJ5IERlY2VtYmVyIDE4dGguPGJyPg0KJmd0OyZndDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsg QmVjYXVzZSBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UgaXMgaW4gdGhlIFJGQyBlZGl0b3Li gJlzIHF1ZXVlLCB0byBpbmNvcnBvcmF0ZSB0aGlzIGNoYW5nZSBvdXIgQUQgaXMgZ29pbmcgdG8g bmVlZCB0byBwdWxsIGl0IGJhY2sgZnJvbSB0aGUgUkZDLWVkaXRvcuKAmXMgcXVldWUgYW5kIHJl LXJ1biB0aGUgSUVURiBMQyBidXQgdGhhdOKAmXMgb25seSBnb2luZyB0byBoYXBwZW4gb25jZSB3 ZSBjb25maXJtIHRoZSByb29t4oCZcyBjb25zZW5zdXMuPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgdGhl IGNoYWlycyw8YnI+DQomZ3Q7Jmd0OyBjL3MvdDxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgcnRjd2ViIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KJmd0OyZn dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViPC9zcGFuPjwvYT48YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvc3Bh bj48L2E+PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyBydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3ZWJAaWV0Zi5v cmc8L3NwYW4+PC9hPjxicj4NCiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9zcGFuPjwvYT48YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQotLTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQpDb2xpbiBQZXJraW5zPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jc3BlcmtpbnMub3JnLyI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9jc3BlcmtpbnMub3JnLzwvc3Bhbj48 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEg U2FucyBUeXBld3JpdGVyJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBTYW5zIFR5cGV3 cml0ZXImcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgU2FucyBUeXBld3JpdGVyJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Db2xpbiBQZXJraW5zPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgU2FucyBUeXBld3JpdGVyJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2NzcGVya2lucy5vcmcvIj5odHRw czovL2NzcGVya2lucy5vcmcvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7THVjaWRhIFNhbnMgVHlwZXdyaXRlciZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgU2FucyBUeXBld3JpdGVyJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXImcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0tJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgU2FucyBUeXBld3JpdGVy JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Db2xpbiBQZXJraW5zPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgU2FucyBU eXBld3JpdGVyJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwczovL2NzcGVya2lucy5vcmcvIj5odHRwczovL2NzcGVya2lucy5vcmcvPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIFNhbnMgVHlw ZXdyaXRlciZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_949EF20990823C4C85C18D59AA11AD8BADE25722FR712WXCHMBA11z_-- From nobody Thu Dec 17 06:45:56 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E7E1B2E5F; Thu, 17 Dec 2015 06:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Fv6WYqxJC2W; Thu, 17 Dec 2015 06:45:49 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274411B2E5D; Thu, 17 Dec 2015 06:45:48 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-fa-5672ca9bc3fb Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 51.07.05149.B9AC2765; Thu, 17 Dec 2015 15:45:47 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Thu, 17 Dec 2015 15:45:47 +0100 To: IETF AVTCore WG References: <5638496B.3040009@ericsson.com> From: Magnus Westerlund Message-ID: <5672CA9A.4080502@ericsson.com> Date: Thu, 17 Dec 2015 15:45:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5638496B.3040009@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7je7sU0VhBg2rpS1e9qxkt7ixeQGT xeqbH9gs1v5rZ3dg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mrr37WIs2CZY8eniGvYG xtl8XYycHBICJhL3phxhgrDFJC7cW8/WxcjFISRwmFFi5ZJzLBDOckaJ3UvPMIJUCQuESKy4 t5INxBYRUJLYMWkbM4gtJKAtsf/tBVYQm1mgVGL93SlgU9kELCRu/mgEq+cFqun88gVsDouA qkTPstVgcVGBGInHi7eyQtQISpyc+YQFxOYU0JH4dqUBqIYDaKa9xIOtZRDj5SWat86GW9vQ 1ME6gVFwFpLuWQgds5B0LGBkXsUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGMAHt/w22MH4 8rnjIUYBDkYlHt4PbwrDhFgTy4orcw8xSnAwK4nwbjxaFCbEm5JYWZValB9fVJqTWnyIUZqD RUmct5npQaiQQHpiSWp2ampBahFMlomDU6qBMfbFip1PGiUazSYEJPHpvzlYG7jT4+mXHfqz b84tvFS49MZDZ3vOd831LzKnFp04dOLv+v8XqqpWpRxZufn7BLnNrUkfO0/ezHr02yQmMTEx 7oC676e7NTWs8kbKZ6eU2sfG3bb51v5LInWD8I+ct//jVzg7x8ftTHNXvDDl272TTx0urtVr TVdiKc5INNRiLipOBACSGjtkXAIAAA== Archived-At: Cc: rmcat@ietf.org, "rtcweb@ietf.org" , draft-ietf-avtcore-rtp-circuit-breakers@tools.ietf.org Subject: Re: [rtcweb] [AVTCORE] WG last call for draft-ietf-avtcore-rtp-circuit-breakers-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:45:54 -0000 Hi, The WG last call has concluded. There has been some feedback that needs to be addressed. Thanks to all that has commented. When the feedback has been addressed I will review the changes to see if there is need for additional last call on the changes, or if I can request publication immediately. Cheers Magnus Westerlund WG chair Den 2015-11-03 kl. 06:43, skrev Magnus Westerlund: > WG, > (CC RMCAT and RTCWEB) > > This starts the 6 week WG last call on "Multimedia Congestion Control: > Circuit Breakers for Unicast RTP Sessions" > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > > We are doing a 6 week last call to give people time to review and > perform verification of the latest updates also in implementations and > simulations. > > Please provide feedback not later than 16th of December. We appreciate > all type of messages, even short, "read it, and have no comments". We > appreciate even more people that has performed any type of verification > of the solution. > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287" > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Dec 18 10:14:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64EE1A6FF6 for ; Fri, 18 Dec 2015 10:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tACR6kmfnrxF for ; Fri, 18 Dec 2015 10:14:00 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572BC1B3006 for ; Fri, 18 Dec 2015 10:14:00 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id c96so39538691qgd.3 for ; Fri, 18 Dec 2015 10:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1Df48EFPLmZFYcgaxvuOncsT96eun58eUYrTpDX7V6c=; b=osOOrSHuU92bsHxCRw1ZJRy5Vrn9TJ4fnHS3UKz2uk8B338eGdeVgbGcI9IgPv9xsx W0VdtxiHh+smKuTUoCO1j10IpGu3/CWUwNzhWR6XYmPT+iX6Gph/tfuN/gG4qkdEZYJg AKG3xytNM4YJYy2Rtmr+pQuCY2Jp/7rkGNqfrHqr7JGOT/O83/bk6Laju89ddYG3DeU7 LJbtGdnqC0HeqgFeyMZBBgyKoGBlTwd0aDcPOpCVVXBfaUnp5dutFwm20/3L6EGi05of Pu1QfmFFIia+kfjdpf24rR5NsBaUWsyVr5WelzbDCodPMKmvL4o8Ng45i+R/tYAyE/1N OuvA== MIME-Version: 1.0 X-Received: by 10.140.104.167 with SMTP id a36mr6893512qgf.19.1450462439504; Fri, 18 Dec 2015 10:13:59 -0800 (PST) Received: by 10.55.14.211 with HTTP; Fri, 18 Dec 2015 10:13:59 -0800 (PST) Date: Fri, 18 Dec 2015 10:13:59 -0800 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a1134ee5c777f910527301a1f Archived-At: Subject: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 18:14:02 -0000 --001a1134ee5c777f910527301a1f Content-Type: text/plain; charset=UTF-8 The two issues that surfaced during this last call that needed resolution were DTMF and comfort noise. Based on the discussion, we believe that the comfort noise requirement will be shifted to "WebRTC endpoints". The DTMF language will aligned with the W3C specification and clarified that A-D are not supported (as they will not be supported in the JavaScript). After the document is updated, the chairs plan to submit it to IETF last call. regards, Ted, Cullen, Sean --001a1134ee5c777f910527301a1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The two issues that surfaced during this last ca= ll that needed resolution were DTMF and comfort noise.=C2=A0 Based on the d= iscussion, we believe that the comfort noise requirement will be shifted to= "WebRTC endpoints". The DTMF language will aligned with the W3C = specification and clarified that A-D are not supported (as they will not be= supported in the JavaScript).

After the document is= updated, the chairs plan to submit it to IETF last call.

regards,

Ted, Cullen, Sean
--001a1134ee5c777f910527301a1f-- From nobody Fri Dec 18 10:32:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182BA1B37F4 for ; Fri, 18 Dec 2015 10:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYS4jqEXaC28 for ; Fri, 18 Dec 2015 10:32:45 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449231B3767 for ; Fri, 18 Dec 2015 10:32:45 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id o67so98375694iof.3 for ; Fri, 18 Dec 2015 10:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m9dr/0Fu9VIzi25FnYazmjAlMKY94GB59tkSE7MBTkk=; b=Hne5ZUfyswb8P0DnGgksPXsZ8F6SwKvR8eUQTjJhRHAyzSbFsoTqR5YKpsk1ns5BVo OPsh2NZ04iUIoXBcir9qz2SeE6bE2owqI80ClpVe7ZOOnM9p3lecRSR/ZjxG9DhpDLHI bDobvLocRgK+N1ze1y6tlx3MgwEe0+6dTet/JuBXM0RBdXVw+JViHHbnqtzeRj1dkELi mQ1fD+qTfqAQvitderE1xOm2k2Yfar+4XgJ487uPXjf284sqKbOQ8bh6ikzbVdwqZ82w hgpzitKX48fZzmk/kf0fljXJuviDqXkKx6fE+I+MCFUTwbDN5Q3qIawIw2BCdf0Vk+uA 9ZpQ== 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=m9dr/0Fu9VIzi25FnYazmjAlMKY94GB59tkSE7MBTkk=; b=Zm/XzmT0wKTl1+lgzQ+drB1LUE9F0G2t3x9XO4LA3d1QAmLy4CByuSgpHN8skSrnFl 4LqJUyOgWMODPB2PlPnA86TWEBjtNz9RoWUmklYHtZgLfy/1T4buCicJ+gG+FBuGRS/3 FrUQVuAAmjgBcubVafwFA6kHctYYhS9sVQ7cC+X5FqneQstWSwDv9gA20s9DVgHH/c6n lPcne0j3GPrCADBRCgUXZd5gOukNKR4XuDyWus9Chm98qUuQGun+phBmgbrJbZnCULH4 sVXDa6UND1H670d8V4N/lhVq7Q8aqnHO0XCLZa+NCRbuojf6V2P5knFOm4SZr5bw09kk KqxQ== X-Gm-Message-State: ALoCoQm/Qv7j5bSj9uhDS8DVjcYqo4rINUH8yYh8T779/TR8xtNx0timKnF66275TWbR2VLBO/QGZFFnFkpoC+mDiF0LlSYHlA== X-Received: by 10.107.39.130 with SMTP id n124mr7161836ion.159.1450463564713; Fri, 18 Dec 2015 10:32:44 -0800 (PST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id z6sm3085452ign.1.2015.12.18.10.32.43 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 10:32:43 -0800 (PST) Received: by mail-io0-f172.google.com with SMTP id o67so98374768iof.3 for ; Fri, 18 Dec 2015 10:32:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.166.15 with SMTP id p15mr5957665ioe.38.1450463562696; Fri, 18 Dec 2015 10:32:42 -0800 (PST) Received: by 10.36.105.15 with HTTP; Fri, 18 Dec 2015 10:32:42 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 13:32:42 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=001a1141cf946a12b40527305d74 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 18:32:47 -0000 --001a1141cf946a12b40527305d74 Content-Type: text/plain; charset=UTF-8 Hi All, Since the decision not to support A-D DTMF digits was never made on the IETF list (I have looked through the archive and cannot find it), I do not think they should be removed. Minimal DTMF tone duration and gap duration should be added to the document. The meaning of "consuming" RFC 4733 events by WebRTC endpoints is unclear. I suggest to change the following section of the document: OLD TEXT: The audio/telephone-event media format as specified in [RFC4733]. WebRTC endpoints are REQUIRED to be able to generate and consume the following events: +------------+--------------------------------+-----------+ |Event Code | Event Name | Reference | +------------+--------------------------------+-----------+ | 0 | DTMF digit "0" | RFC4733 | | 1 | DTMF digit "1" | RFC4733 | | 2 | DTMF digit "2" | RFC4733 | | 3 | DTMF digit "3" | RFC4733 | | 4 | DTMF digit "4" | RFC4733 | | 5 | DTMF digit "5" | RFC4733 | | 6 | DTMF digit "6" | RFC4733 | | 7 | DTMF digit "7" | RFC4733 | | 8 | DTMF digit "8" | RFC4733 | | 9 | DTMF digit "9" | RFC4733 | | 10 | DTMF digit "*" | RFC4733 | | 11 | DTMF digit "#" | RFC4733 | +------------+--------------------------------+-----------+ _____________ Roman Shpount On Fri, Dec 18, 2015 at 1:13 PM, Ted Hardie wrote: > The two issues that surfaced during this last call that needed resolution > were DTMF and comfort noise. Based on the discussion, we believe that the > comfort noise requirement will be shifted to "WebRTC endpoints". The DTMF > language will aligned with the W3C specification and clarified that A-D are > not supported (as they will not be supported in the JavaScript). > > After the document is updated, the chairs plan to submit it to IETF last > call. > > regards, > > Ted, Cullen, Sean > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1141cf946a12b40527305d74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

Since the decision not to suppo= rt A-D DTMF digits was never made on the IETF list (I have looked through t= he archive and cannot find it), I do not think they should be removed.

Minimal DTMF tone duration and gap duration should be = added to the document.

The meaning of "consum= ing" RFC 4733 events by WebRTC endpoints is unclear.

I suggest to change the following section of the document:

OLD TEXT:
The audio/telephone-event media format= as specified in [RFC4733].
=C2=A0 =C2=A0 =C2=A0 WebRTC endpoints are RE= QUIRED to be able to generate and consume
=C2=A0 =C2=A0 =C2=A0 the follo= wing events:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+-------= -------------------------+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|Event Code =C2=A0| Event Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Reference |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+------------+--------------------------------+-----------+
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF di= git "0" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 1 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "1" =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit &quo= t;2" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0R= FC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 3 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| DTMF digit "3" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "4&quo= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 5 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| DTMF digit "5" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "6" =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0= |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| DTMF digit "7" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 8= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "8" =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 9 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF= digit "9" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 10 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "*" =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0| 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "#&= quot; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC47= 33 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+-------------= -------------------+-----------+


_____________
= Roman Shpount

On Fri, Dec 18, 2015 at 1:13 PM, Ted Hardie = <ted.ietf@gmail.com> wrote:
The two issues that surfaced during this last= call that needed resolution were DTMF and comfort noise.=C2=A0 Based on th= e discussion, we believe that the comfort noise requirement will be shifted= to "WebRTC endpoints". The DTMF language will aligned with the W= 3C specification and clarified that A-D are not supported (as they will not= be supported in the JavaScript).

After the document= is updated, the chairs plan to submit it to IETF last call.

<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz= e:small">regards,

Ted, Cullen, Sean

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


--001a1141cf946a12b40527305d74-- From nobody Fri Dec 18 10:57:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B5A1B37C8 for ; Fri, 18 Dec 2015 10:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsOabmKY_T1G for ; Fri, 18 Dec 2015 10:57:43 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5E31B37A0 for ; Fri, 18 Dec 2015 10:57:42 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id ph11so43335618igc.1 for ; Fri, 18 Dec 2015 10:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XEcvCSX8IEk+Rw7RYB4vQL+ZWXtxzs3KpLSxw9sGQ4A=; b=G2PPowJ70RhiZT/iZ2TIYDyZU23wEyFz4Fp5A9sgjv1yVPbJiDI2dYDX/XX6SewBTW lySSnhEvM75wamCCrP5aae8dqIAewSyfL1Fls57c1joI9+GrF+0F7y50MkESaTAgwRTg N0DOVkLsPm/4g7jXuRbRb4Eb21EWCntF0/SKvC0QCiqCq+8wBVFtfFzTm68+zouHdZ1h 7+vKNtbAn3ZNDnKfYq+8hd9VQNIUBd+7JbeiXoSrkvyxqUlia60IqmF+EoPqZItbXAX4 a3hNSOVH/8WpzwNuNrEPKuuroOD6kgQBBszj/XHs3nUJYRUBTECsJIglOlRot5tQIwkE Zq5Q== 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=XEcvCSX8IEk+Rw7RYB4vQL+ZWXtxzs3KpLSxw9sGQ4A=; b=LBPLVmq0NsGErYJxxQlTxYwgxKr/o5HiG4kgekL5N1gIT6sMeCoEehRqbmmGryqfs2 GtkEmPU5BhPLuCoO5QKk1Z/X4Sj7qGev52vMbLkyp7Ga6Rbb7zPEo8COWS3hDC3dO3xS 4FsTza+tWtj1iDqjgopOzkPWCGM+G+KJk0fM5GSuPhcbWiPTUXIF92KTLhjSAF8sbaOJ p5nCrqAWEU5ShhpGqVDz/uILKhHzwQ1LQ/G1V6FpHBJWQ4USE0lXwolIx1hyeNrdvgYz hM1vakT5gERqdcgLpmEW4qEnflmD5npptDkDgvJqDCR6SuHFqw5VJprQFTSjpjji7sJe Zk4A== X-Gm-Message-State: ALoCoQn+yRVutcdiJCe9LLZrnKBUgtkCsiawqlxmnDLrT3tIhlsaI+nrhMy7HNguP810CdAFQPzqe+ZWJSc6XJMNi0eKurJ4bw== X-Received: by 10.50.79.196 with SMTP id l4mr5030848igx.77.1450465062210; Fri, 18 Dec 2015 10:57:42 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id a191sm6971455ioe.7.2015.12.18.10.57.40 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 10:57:41 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id jw2so41339027igc.1 for ; Fri, 18 Dec 2015 10:57:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.62.178 with SMTP id z18mr4896792igr.2.1450465060439; Fri, 18 Dec 2015 10:57:40 -0800 (PST) Received: by 10.36.105.15 with HTTP; Fri, 18 Dec 2015 10:57:40 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 13:57:40 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7bd760c2aff225052730b68b Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 18:57:45 -0000 --047d7bd760c2aff225052730b68b Content-Type: text/plain; charset=UTF-8 Sorry,due to a finger slip the email went out too early. Here is the proposed change: OLD TEXT: The audio/telephone-event media format as specified in [RFC4733]. WebRTC endpoints are REQUIRED to be able to generate and consume the following events: +------------+--------------------------------+-----------+ |Event Code | Event Name | Reference | +------------+--------------------------------+-----------+ | 0 | DTMF digit "0" | RFC4733 | | 1 | DTMF digit "1" | RFC4733 | | 2 | DTMF digit "2" | RFC4733 | | 3 | DTMF digit "3" | RFC4733 | | 4 | DTMF digit "4" | RFC4733 | | 5 | DTMF digit "5" | RFC4733 | | 6 | DTMF digit "6" | RFC4733 | | 7 | DTMF digit "7" | RFC4733 | | 8 | DTMF digit "8" | RFC4733 | | 9 | DTMF digit "9" | RFC4733 | | 10 | DTMF digit "*" | RFC4733 | | 11 | DTMF digit "#" | RFC4733 | +------------+--------------------------------+-----------+ NEW TEXT: The audio/telephone-event media format as specified in [RFC4733]. WebRTC endpoints are REQUIRED to be able to generate the following events: +------------+--------------------------------+-----------+ |Event Code | Event Name | Reference | +------------+--------------------------------+-----------+ | 0 | DTMF digit "0" | RFC4733 | | 1 | DTMF digit "1" | RFC4733 | | 2 | DTMF digit "2" | RFC4733 | | 3 | DTMF digit "3" | RFC4733 | | 4 | DTMF digit "4" | RFC4733 | | 5 | DTMF digit "5" | RFC4733 | | 6 | DTMF digit "6" | RFC4733 | | 7 | DTMF digit "7" | RFC4733 | | 8 | DTMF digit "8" | RFC4733 | | 9 | DTMF digit "9" | RFC4733 | | 10 | DTMF digit "*" | RFC4733 | | 11 | DTMF digit "#" | RFC4733 | | 12 | DTMF digit "A" | RFC4733 | | 13 | DTMF digit "B" | RFC4733 | | 14 | DTMF digit "C" | RFC4733 | | 15 | DTMF digit "D" | RFC4733 | +------------+--------------------------------+-----------+ Generated events MUST have duration of no more than 6000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms. Event SHOULD start on a regular audio packet border and event and gap duration SHOULD be rounded up to the next regular audio packet border. During the time events are generated no audio SHOULD be sent for the same audio stream. When gaps between events are generated, silence SHOULD and not the background audio should be sent using regular audio encoding. If multiple audio sampling rates are supported, audio/telephone-event payload SHOULD be present for each supported sampling rate. Endpoints SHOULD use audio/telephone-event format parameters during the offer/answer to indicate which events are supported. Receivers MUST be able to consume any audio/telephone-event events in such a way that it will not generate audio artifacts, jitter buffer adjustments, payload mismatches, or invalid RTCP statistics calculation. Receivers MAY generate audio corresponding to the received events but are also allowed to discard them in a manner that does not affect regular audio processing. _____________ Roman Shpount On Fri, Dec 18, 2015 at 1:32 PM, Roman Shpount wrote: > Hi All, > > Since the decision not to support A-D DTMF digits was never made on the > IETF list (I have looked through the archive and cannot find it), I do not > think they should be removed. > > Minimal DTMF tone duration and gap duration should be added to the > document. > > The meaning of "consuming" RFC 4733 events by WebRTC endpoints is unclear. > > I suggest to change the following section of the document: > > OLD TEXT: > The audio/telephone-event media format as specified in [RFC4733]. > WebRTC endpoints are REQUIRED to be able to generate and consume > the following events: > > +------------+--------------------------------+-----------+ > |Event Code | Event Name | Reference | > +------------+--------------------------------+-----------+ > | 0 | DTMF digit "0" | RFC4733 | > | 1 | DTMF digit "1" | RFC4733 | > | 2 | DTMF digit "2" | RFC4733 | > | 3 | DTMF digit "3" | RFC4733 | > | 4 | DTMF digit "4" | RFC4733 | > | 5 | DTMF digit "5" | RFC4733 | > | 6 | DTMF digit "6" | RFC4733 | > | 7 | DTMF digit "7" | RFC4733 | > | 8 | DTMF digit "8" | RFC4733 | > | 9 | DTMF digit "9" | RFC4733 | > | 10 | DTMF digit "*" | RFC4733 | > | 11 | DTMF digit "#" | RFC4733 | > +------------+--------------------------------+-----------+ > > > _____________ > Roman Shpount > > On Fri, Dec 18, 2015 at 1:13 PM, Ted Hardie wrote: > >> The two issues that surfaced during this last call that needed resolution >> were DTMF and comfort noise. Based on the discussion, we believe that the >> comfort noise requirement will be shifted to "WebRTC endpoints". The DTMF >> language will aligned with the W3C specification and clarified that A-D are >> not supported (as they will not be supported in the JavaScript). >> >> After the document is updated, the chairs plan to submit it to IETF last >> call. >> >> regards, >> >> Ted, Cullen, Sean >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --047d7bd760c2aff225052730b68b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry,due to a finger slip the email went out too early. H= ere is the proposed change:

OLD TEXT:
The audio/telephone-event media format as specified in [RFC4733].
WebRTC endpoints are REQUIRED = to be able to generate and consume
the following events:

=C2= =A0 =C2=A0 =C2=A0+------------+--------------------------------+-----------= +
=C2=A0 =C2=A0 =C2=A0= |Event Code =C2=A0| Event Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Reference |
=C2=A0 =C2=A0 =C2=A0+------------+---------------------= -----------+-----------+
=C2=A0 =C2=A0 =C2=A0| 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit &= quot;0" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0RFC4733 =C2=A0|
=C2= =A0 =C2=A0 =C2=A0| 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "1= " =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4= 733 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0| 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "2" = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2= =A0|
=C2=A0 =C2=A0 =C2= =A0| 3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "3" =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 4 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "4" =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 5 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "5" =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 6 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| DTMF digit "6" =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 7 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| DTMF digit "7" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 8 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| DTMF digit "8" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 9 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= DTMF digit "9" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 10 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit = "*" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0RFC4733 =C2=A0|
=C2= =A0 =C2=A0 =C2=A0| 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "#"= ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0+------------+--------------------------------+-----------+

NEW TEXT:

Th= e audio/telephone-event media format as specified in [RFC4733].
WebRTC endpoints are REQUIRED to = be able to generate the following
events:
=C2=A0 =C2=A0 =C2= =A0+------------+--------------------------------+-----------+
=
=C2=A0 =C2=A0 =C2=A0|Event Code = =C2=A0| Event Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | Reference |
=C2=A0 =C2=A0 =C2=A0+------------+--------------------------------+--= ---------+
=C2=A0 =C2= =A0 =C2=A0| 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "0" = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2= =A0|
=C2=A0 =C2=A0 =C2= =A0| 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "1" =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 2 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "2" =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 3 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "3" =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 4 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| DTMF digit "4" =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 5 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| DTMF digit "5" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| DTMF digit "6" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= DTMF digit "7" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 8 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF d= igit "8" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = | =C2=A0RFC4733 =C2=A0|
=C2= =A0 =C2=A0 =C2=A0| 10 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "*"= ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 = =C2=A0|
=C2=A0 =C2=A0 = =C2=A0| 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "#" =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 12= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "A" =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=
=C2=A0 =C2=A0 =C2=A0| 13 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | DTMF digit "B" =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 14 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | DTMF digit "C" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | DTMF digit "D" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+------------+----------------------------= ----+-----------+

=
Generated events MUST= have duration of no more than 6000 ms and no less
than 40 ms with the recommended default durati= on of 100 ms for each tone.=C2=A0
The gap between events MUST be no less then 30 ms with the reco= mmended
default durati= on of 70 ms. Event SHOULD start on a regular audio packet
= border and event and gap duration SHOUL= D be rounded up to the next regular
audio=C2=A0packet border.
During the time eve= nts are generated no audio SHOULD be sent for the same
audio stream. When gaps between events are= generated, silence SHOULD=C2=A0
and not the background audio should be sent using re= gular audio encoding.

If multiple a= udio sampling rates are supported, audio/telephone-event payload
SHOULD be present for each suppo= rted sampling rate. Endpoints SHOULD use
audio/telephone-event format parameters during the offer= /answer to=C2=A0
indic= ate which events are supported.

Receive= rs MUST be able to consume any audio/telephone-event events
in such a way that it will not genera= te audio artifacts, jitter buffer
adjustments, payload mismatches, or invalid RTCP statistics cal= culation.
Receivers MA= Y generate audio=C2=A0corresponding to the received events=C2=A0
but are also allowed to discard them= =C2=A0in a manner th= at does not affect=C2=A0
regular audio processing.

___________= __
Roman Shpount

On Fri, Dec 18, 2015 at 1:32 PM, Roman Shpou= nt <roman@telurix.com> wrote:
Hi All,

Since the decision not to support A-D D= TMF digits was never made on the IETF list (I have looked through the archi= ve and cannot find it), I do not think they should be removed.
Minimal DTMF tone duration and gap duration should be added to= the document.

The meaning of "consuming"= ; RFC 4733 events by WebRTC endpoints is unclear.

= I suggest to change the following section of the document:

OLD TEXT:
The audio/telephone-event media format as spec= ified in [RFC4733].
=C2=A0 =C2=A0 =C2=A0 WebRTC endpoints are REQUIRED t= o be able to generate and consume
=C2=A0 =C2=A0 =C2=A0 the following eve= nts:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+---------------= -----------------+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|Event = Code =C2=A0| Event Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | Reference |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--= ----------+--------------------------------+-----------+
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit &quo= t;0" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0R= FC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 1 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| DTMF digit "1" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "2&quo= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 3 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| DTMF digit "3" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "4" =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0= |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| DTMF digit "5" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 6= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "6" =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF= digit "7" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 8 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "8" =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| 9 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit = "9" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 10 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | DTMF digit "*" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "#" =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0= |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+----------------------= ----------+-----------+


_____________
Roman Shpount

On Fri, Dec 18, 2015 = at 1:13 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
The two issues that surf= aced during this last call that needed resolution were DTMF and comfort noi= se.=C2=A0 Based on the discussion, we believe that the comfort noise requir= ement will be shifted to "WebRTC endpoints". The DTMF language wi= ll aligned with the W3C specification and clarified that A-D are not suppor= ted (as they will not be supported in the JavaScript).

After the document is= updated, the chairs plan to submit it to IETF last call.

regards,

Ted, Culle= n, Sean

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



--047d7bd760c2aff225052730b68b-- From nobody Fri Dec 18 11:34:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6695D1B386A for ; Fri, 18 Dec 2015 11:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBkWdLBbMsE4 for ; Fri, 18 Dec 2015 11:34:37 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660041B3872 for ; Fri, 18 Dec 2015 11:34:35 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u65so96169316qkh.2 for ; Fri, 18 Dec 2015 11:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rom8mYOEpeoQvVuCxBXGBe1qxrE0XFPICUjuRk2eXe0=; b=taXk0IK2ZcInFiXETOldN798Vkb1d9jz7wI/3uEJASojn/42C2poDN0/sjB79Q7AmF FoFcnRf0EjbyaHiAjbM7/byL+SoX44zTc3o690qAVAGsoOV9ZZw2DX3rVTGY56+WMajB H1gMk8t/kafUBabHLjK1CvPGhW0ECt2FeLvfx0zNkr5XbdlUYqAWQqKJVDps7lzvpzd9 Qy81NOW8qwJfhUzuJ2FH2MinxH+a/cor0HopoqWzr9nlHjHoQfNBkeS0xDWOWxXF1QXx KfQcjQwMcqwtV3xrbGNO+YplvmgzdxCY9ymhXnXXJA4qClb9PYkUxIKtabQGvccLDDEu JKEw== MIME-Version: 1.0 X-Received: by 10.55.20.196 with SMTP id 65mr7381173qku.67.1450467274532; Fri, 18 Dec 2015 11:34:34 -0800 (PST) Received: by 10.55.14.211 with HTTP; Fri, 18 Dec 2015 11:34:34 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 11:34:34 -0800 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: multipart/alternative; boundary=001a1144d2a2a82c310527313ade Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 19:34:39 -0000 --001a1144d2a2a82c310527313ade Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount wrote: > Hi All, > > Since the decision not to support A-D DTMF digits was never made on the > IETF list (I have looked through the archive and cannot find it), I do no= t > think they should be removed. > > =E2=80=8BCan you say more about what use there would be in supporting them? regards, Ted=E2=80=8B > Minimal DTMF tone duration and gap duration should be added to the > document. > > The meaning of "consuming" RFC 4733 events by WebRTC endpoints is unclear= . > > I suggest to change the following section of the document: > > OLD TEXT: > The audio/telephone-event media format as specified in [RFC4733]. > WebRTC endpoints are REQUIRED to be able to generate and consume > the following events: > > +------------+--------------------------------+-----------+ > |Event Code | Event Name | Reference | > +------------+--------------------------------+-----------+ > | 0 | DTMF digit "0" | RFC4733 | > | 1 | DTMF digit "1" | RFC4733 | > | 2 | DTMF digit "2" | RFC4733 | > | 3 | DTMF digit "3" | RFC4733 | > | 4 | DTMF digit "4" | RFC4733 | > | 5 | DTMF digit "5" | RFC4733 | > | 6 | DTMF digit "6" | RFC4733 | > | 7 | DTMF digit "7" | RFC4733 | > | 8 | DTMF digit "8" | RFC4733 | > | 9 | DTMF digit "9" | RFC4733 | > | 10 | DTMF digit "*" | RFC4733 | > | 11 | DTMF digit "#" | RFC4733 | > +------------+--------------------------------+-----------+ > > > _____________ > Roman Shpount > > On Fri, Dec 18, 2015 at 1:13 PM, Ted Hardie wrote: > >> The two issues that surfaced during this last call that needed resolutio= n >> were DTMF and comfort noise. Based on the discussion, we believe that t= he >> comfort noise requirement will be shifted to "WebRTC endpoints". The DTM= F >> language will aligned with the W3C specification and clarified that A-D = are >> not supported (as they will not be supported in the JavaScript). >> >> After the document is updated, the chairs plan to submit it to IETF last >> call. >> >> regards, >> >> Ted, Cullen, Sean >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a1144d2a2a82c310527313ade Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2015 at 10:32 A= M, Roman Shpount <roman@telurix.com> wrote:
Hi All,
<= br>
Since the decision not to support A-D DTMF digits was never m= ade on the IETF list (I have looked through the archive and cannot find it)= , I do not think they should be removed.


=E2=80=8BCan you say more about what use there woul= d be in supporting them?

regards,

Ted=E2=80=8B


=C2=A0
<= div dir=3D"ltr">
Minimal DTMF tone duration and gap duration= should be added to the document.

The meaning of &= quot;consuming" RFC 4733 events by WebRTC endpoints is unclear.
<= div>
I suggest to change the following section of the documen= t:

OLD TEXT:
The audio/telephone-event m= edia format as specified in [RFC4733].
=C2=A0 =C2=A0 =C2=A0 WebRTC endpo= ints are REQUIRED to be able to generate and consume
=C2=A0 =C2=A0 =C2= =A0 the following events:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------= -----+--------------------------------+-----------+
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|Event Code =C2=A0| Event Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Reference |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+------------+--------------------------------+--------= ---+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| DTMF digit "0" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "1" =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| D= TMF digit "2" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 3 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "3" =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF dig= it "4" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 5 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "5" =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit &quo= t;6" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0R= FC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 7 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| DTMF digit "7" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| 8 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| DTMF digit "8&quo= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 9 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| DTMF digit "9" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| 10 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF digit "*" =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0RFC4733 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | DTMF = digit "#" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0RFC4733 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------= +--------------------------------+-----------+


_____________
Roman Shpoun= t

On Fri, Dec 18, 2015 = at 1:13 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
The two iss= ues that surfaced during this last call that needed resolution were DTMF an= d comfort noise.=C2=A0 Based on the discussion, we believe that the comfort= noise requirement will be shifted to "WebRTC endpoints". The DTM= F language will aligned with the W3C specification and clarified that A-D a= re not supported (as they will not be supported in the JavaScript).

=
After th= e document is updated, the chairs plan to submit it to IETF last call.
<= br>
regar= ds,

Ted, Cullen, Sean

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



--001a1144d2a2a82c310527313ade-- From nobody Fri Dec 18 11:54:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8713C1B3886 for ; Fri, 18 Dec 2015 11:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGt0VnnmNF9b for ; Fri, 18 Dec 2015 11:54:38 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2501C1B3885 for ; Fri, 18 Dec 2015 11:54:37 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id x184so70731876yka.3 for ; Fri, 18 Dec 2015 11:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3kgfAmquiW2zoHqf9n0gAzbxAPC6h5BhLzeudpPw4aU=; b=018tMsbyQE5zZEeBggnsgCEtW1ejvPgVnQRjvtwuzDYc8CGcFaZfMIuxVKLPgZdYnv Zo/YQuL1thYAlLEX3Ewmg7XoTOZXIJVxO0MtCTTaX5DkHXjNlReaG20nU5mtpgfMH0Tx uqfwWG2rrgutUIBjbvhYYOaGErFIwBPEydzPhBiWNx7wImR7GNT58h45fp0pk1FX68h+ RjaWsSNMNHZYQtXGy15DlMGlgDCce95D1GwPIEbcNCoI4VhU8ZZw3tu9CEBLH1g0LeTc V8h1vVaLGEVxOCOzLjIiW7nAZWuUmN8cyby0cdYzsE2yVOACH1D6xBrZWF0q4LjzLHyk F4AQ== X-Received: by 10.129.51.210 with SMTP id z201mr5110246ywz.202.1450468477112; Fri, 18 Dec 2015 11:54:37 -0800 (PST) Received: from [192.168.4.135] (ip-64-134-188-160.public.wayport.net. [64.134.188.160]) by smtp.gmail.com with ESMTPSA id h130sm17336524ywb.24.2015.12.18.11.54.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 11:54:35 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-EDA88B73-A361-486D-9309-95B52041D7B0 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Fri, 18 Dec 2015 14:54:34 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: To: Ted Hardie Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 19:54:39 -0000 --Apple-Mail-EDA88B73-A361-486D-9309-95B52041D7B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The DTMF language will aligned with the W3C specification and clarified that= A-D are not supported (as they will not be supported in the JavaScript). [BA] I am not sure what "aligning the text" means. The W3C WEBRTC specificat= ion does not dictate that A-D be supported - it only describes how implement= ations should behave for supported tones, referencing the Audio document for= DTMF requirements. If a tone is unsupported it is considered "unrecognized"= in the API. It is the Audio document that provides the requirements, and as= long as A-D aren't a MUST NOT, the API needs to allow implementations to se= nd A-D if they choose to do so.= --Apple-Mail-EDA88B73-A361-486D-9309-95B52041D7B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
The DTMF language will aligned with the W3C specification and clarified that A-D are not supported (as they will not be supported in the JavaScript).

[BA] I am not sure what "aligning the text" means. The W3C WEBRTC specification does not dictate that A-D be supported - it only describes how implementations should behave for supported tones, referencing the Audio document for DTMF requirements. If a tone is unsupported it is considered "unrecognized" in the API. It is the Audio document that provides the requirements, and as long as A-D aren't a MUST NOT, the API needs to allow implementations to send A-D if they choose to do so.
--Apple-Mail-EDA88B73-A361-486D-9309-95B52041D7B0-- From nobody Fri Dec 18 13:10:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BB81B390E for ; Fri, 18 Dec 2015 13:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZx7ehkBO9ni for ; Fri, 18 Dec 2015 13:10:17 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DF11B3910 for ; Fri, 18 Dec 2015 13:10:16 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id jw2so456542igc.1 for ; Fri, 18 Dec 2015 13:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PFTFq05u9lV5E2bNKZK/k1L2atAy76lwAfcRSA5PA34=; b=nHwmynaQKehMpcSGyXmQlumMSPwdEmImF5IH/NxSCgAGB2qITsFi/8lBwXg5qAPM/o aKqW2zge2XyuWkiwxRREzj51RDCS+4h21/5MFEgqIx2WTrHxZKJNZQgGQ1tzhUY81LI7 x6+HKikI9atpdlwNLOQep6xP+e3EJDBJpyZHKlIPZxfDKufROQGpe3Vbv1m8jL6rlhD8 ZorvGHiahczl1esH+ePlAu1k9S/XRdcgQQuJXdi/O6anUfgGb5v2H5Y8idT7QK1hYNuu RLzDXJEZF9saYcN5WYApcg6zgI8d4sy9+Li5eZXDa5pX0dxzmiksDhHYcxA2ZWJ01sLZ QcRA== 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=PFTFq05u9lV5E2bNKZK/k1L2atAy76lwAfcRSA5PA34=; b=HNY5eOsoB2gq9XOrxjBsyLr32c5giuuWlNfw1L17+DKKCZqT91ew+0iFbukBxyMXgW Srjnb98NoxYWqw14bdsT13cmy5BR/eUk/wEb3EbvYBK/m6ktmyprZUDeOL/jNH5vFZq/ Q/h8sPC+IROMza1C4nqfky9wegSFFYUlUUrXrdnV5vEVXGk0zW99fRSn8gWghA9qw5ir +RtGMDRcG3iAHCNGRu8Ag/ETdIxIbFXQlxbaIlh3ix25hWqedkRx5JdtqxId/UzjWXbb GkMmrjBR+Rl1P1oelRURk/eJoojuJaVrXV4pw4PnI1VWb0sA7fv5YMf2yyTtY6mmmIoU W8Iw== X-Gm-Message-State: ALoCoQn0aKr0JA+vskSX6bjO0g4klycH9GxffHASXQpMm3kMra0Hy4Zc/A2q7Wm/Q9jXVlqCMX6sL4Yl/8nSdxNziQn4WGtptw== X-Received: by 10.50.153.69 with SMTP id ve5mr5198201igb.80.1450473015627; Fri, 18 Dec 2015 13:10:15 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id rq10sm3315539igb.22.2015.12.18.13.10.14 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 13:10:14 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id jw2so455866igc.1 for ; Fri, 18 Dec 2015 13:10:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.124.9 with SMTP id me9mr5548756igb.24.1450473013576; Fri, 18 Dec 2015 13:10:13 -0800 (PST) Received: by 10.36.105.15 with HTTP; Fri, 18 Dec 2015 13:10:13 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 16:10:13 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=089e0111c356bb0db60527329021 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 21:10:20 -0000 --089e0111c356bb0db60527329021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 2:34 PM, Ted Hardie wrote: > On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount wrote= : > >> Hi All, >> >> Since the decision not to support A-D DTMF digits was never made on the >> IETF list (I have looked through the archive and cannot find it), I do n= ot >> think they should be removed. >> >> > =E2=80=8BCan you say more about what use there would be in supporting the= m? > First of all, DTMF support is there for legacy support. I generally dislike when features are removed from an established capability set without a good reason. Can anyone name me a single commercial PSTN VoIP gateway which does not support A-D DTMF tones? I cannot think of one. I believe it would generally make sense to implement whole set defined in https://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. From what I know there is no extra implementation to support A-D DTMF tone. It looks like these tones are removed for aesthetic reasons only. As far as more specific examples are concerned: DTMF tones A-D are used to provide a way to access hidden flows in IVR systems. For instance, when inbound call center is integrated with an external auto-dialer, auto-dialer places a call to call center IVR and uses a hidden flow accessible via one of those tones to connect directly to a waiting agent. DTMF tones A-D are also commonly used by ham radio operators to integrate with PSTN, such as http://www.echolink.org/Help/dtmf_functions.htm DTMF tone A-D are used to provide prioritized call handling service in ITU Q.955.3 specification which is still used by some PBX and phone systems. Finally, some calling card like systems allow remote control of functions such as flash by mapping them to extended DTMF tones. Regards, _____________ Roman Shpount --089e0111c356bb0db60527329021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2015 at 2:34 PM, Ted Hardie <ted.ietf@gmail.com&= gt; wrote:
On Fri, Dec = 18, 2015 at 10:32 AM, Roman Shpount <roman@telurix.com> wrot= e:
=
Hi All,

Since the decision not to suppo= rt A-D DTMF digits was never made on the IETF list (I have looked through t= he archive and cannot find it), I do not think they should be removed.


=E2=80=8BCan you say more about what u= se there would be in supporting them?

First of all, DTMF support is there for legacy= support. I generally dislike when features are removed from an established= capability set without a good reason. Can anyone name me a single commerci= al PSTN VoIP gateway which does not support A-D DTMF tones? I cannot think = of one. I believe it would generally make sense to implement whole set defi= ned in=C2=A0htt= ps://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. From = what I know there is no extra implementation to support A-D DTMF tone. It l= ooks like these tones are removed for aesthetic reasons only.
As far as more specific examples are concerned:

<= /div>
DTMF tones A-D are used to provide a way to access hidden flows i= n IVR systems. For instance, when inbound call center is integrated with an= external auto-dialer, auto-dialer places a call to call center IVR and use= s a hidden flow accessible via one of those tones to connect directly to a = waiting agent.

DTMF tones A-D are also commonly us= ed by ham radio operators to integrate with PSTN, such as=C2=A0http://www.echolink.org/Hel= p/dtmf_functions.htm

DTMF tone A-D are used to prov= ide prioritized call handling service in ITU Q.955.3 specification which is= still used by some PBX and phone systems.
=
Finally, some calling card like systems allow remote control of fu= nctions such as flash by mapping them to extended DTMF tones.
Regards,
_____________=
Roman Shpount
=C2=A0
--089e0111c356bb0db60527329021-- From nobody Fri Dec 18 13:19:57 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDFC1B391B for ; Fri, 18 Dec 2015 13:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJLHOqCmrq8M for ; Fri, 18 Dec 2015 13:19:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753781B3906 for ; Fri, 18 Dec 2015 13:19:53 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBILJmDY049124 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 18 Dec 2015 15:19:49 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Bernard Aboba , Ted Hardie References: From: Adam Roach Message-ID: <56747874.2050508@nostrum.com> Date: Fri, 18 Dec 2015 15:19:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020305010608060904070606" Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 21:19:56 -0000 This is a multi-part message in MIME format. --------------020305010608060904070606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/18/15 13:54, Bernard Aboba wrote: > The DTMF language will aligned with the W3C specification and > clarified that A-D are not supported (as they will not be supported in > the JavaScript). > > [BA] I am not sure what "aligning the text" means. The W3C WEBRTC > specification does not dictate that A-D be supported - it only > describes how implementations should behave for supported tones, > referencing the Audio document for DTMF requirements. If a tone is > unsupported it is considered "unrecognized" in the API. I'm a little confused about where this leaves the state of play. You're proposing the the W3C spec leave it open as to whether sending an "A" through the API will work or throw an exception? That seems to be begging for unnecessary pain. And, in this case, it's pushing the pain down to the authors, who will likely (accidentally) pass that along to users. It goes pretty well against the W3 priority of constituencies: http://www.w3.org/TR/html-design-principles/#priority-of-constituencies > It is the Audio document that provides the requirements, and as long > as A-D aren't a MUST NOT, the API needs to allow implementations to > send A-D if they choose to do so. Does this rationale apply to RFC5244 tones also? If so, we have a bit more work to do on the W3C API. If the rationale does not apply to RFC5244 tones, I'd be curious to hear about the criteria you're using to draw this line. To be clear, what we need is to have a list of events that are mandatory to implement in both W3C and IETF, and none that are optional (at least, with the current, exception-throwing API). And we need this list to be identical. I personally have absolutely zero interest in whether A-D are included, but we need the list to be the same. /a --------------020305010608060904070606 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 12/18/15 13:54, Bernard Aboba wrote:
The DTMF language will aligned with the W3C specification and clarified that A-D are not supported (as they will not be supported in the JavaScript).

[BA] I am not sure what "aligning the text" means. The W3C WEBRTC specification does not dictate that A-D be supported - it only describes how implementations should behave for supported tones, referencing the Audio document for DTMF requirements. If a tone is unsupported it is considered "unrecognized" in the API.

I'm a little confused about where this leaves the state of play. You're proposing the the W3C spec leave it open as to whether sending an "A" through the API will work or throw an exception? That seems to be begging for unnecessary pain. And, in this case, it's pushing the pain down to the authors, who will likely (accidentally) pass that along to users. It goes pretty well against the W3 priority of constituencies: http://www.w3.org/TR/html-design-principles/#priority-of-constituencies


It is the Audio document that provides the requirements, and as long as A-D aren't a MUST NOT, the API needs to allow implementations to send A-D if they choose to do so.

Does this rationale apply to RFC5244 tones also? If so, we have a bit more work to do on the W3C API.

If the rationale does not apply to RFC5244 tones, I'd be curious to hear about the criteria you're using to draw this line.

To be clear, what we need is to have a list of events that are mandatory to implement in both W3C and IETF, and none that are optional (at least, with the current, exception-throwing API). And we need this list to be identical. I personally have absolutely zero interest in whether A-D are included, but we need the list to be the same.

/a
--------------020305010608060904070606-- From nobody Fri Dec 18 13:24:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BB71B38F9 for ; Fri, 18 Dec 2015 13:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fot-9iARKipl for ; Fri, 18 Dec 2015 13:24:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5701B391B for ; Fri, 18 Dec 2015 13:24:13 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBILOAXh049558 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 18 Dec 2015 15:24:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Roman Shpount , Ted Hardie References: From: Adam Roach Message-ID: <5674797A.9020102@nostrum.com> Date: Fri, 18 Dec 2015 15:24:10 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 21:24:15 -0000 On 12/18/15 15:10, Roman Shpount wrote: > It looks like these tones are removed for aesthetic reasons only. I think it would be better if you directly disagreed with Cullen's rationale rather than simply ignoring it. Since it was made in a different forum, I'll copy it here. On 12/9/15 12:48, Cullen Jennings wrote: > I want to be clear I don't care that much one way or the other about this but I want to try again to explain the issue... > > A to D will often be blocked by the system that sends them from one side to the other. So if you write JS applications that use theses, they will work some times and not others. That is just inviting developers to shoot themselves in the foot and no one has identified any benefit of adding A to D yet. > > 100% agree that the IETF and W3C specs need to align on this and we should change the ietf audio draft if we are including A-D. > To be clear, this is speaking to operational aspects of the system's behavior that I haven't had much visibility into. We have one implementor effectively asserting that all commercial gateways support these tones, and another saying that they tend to be blocked by intermediaries. I suppose both assertions could be true, but the net effect of both being true is that these tones are broadly unusable. But I'm in the same boat as Cullen: I don't care much whether these tones are supported, as long as the W3C and IETF documents agree with each other. /a From nobody Fri Dec 18 13:44:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1DA1B393E for ; Fri, 18 Dec 2015 13:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMMH9uvQW79U for ; Fri, 18 Dec 2015 13:44:19 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074321B393D for ; Fri, 18 Dec 2015 13:44:19 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id v36so43481073qgd.2 for ; Fri, 18 Dec 2015 13:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PiMWMZlj832CieM+28dtu0DmLrMR1fH2g2dI1HgBQSo=; b=CRTQ8f6Dhm7j1Re6VtsHph53VotoBP7t9KNVXceaZRmzWyXHNK62JzE70GLFmsWpb1 2h2v1ct6BGTu2DNMr+KRWP+kXNGl7Ct0FV+pZq/+0rq3H1abj6+i5zUTyLp4jvMVGm4/ 109x7iyUUFqn9aj2WkcP8f1HaZ6/1ubmnm9zyeshHXpILVEd61iBF9YYBGDqWwlhU4yc pCe94T6MyOMWkgyTyJ0zGVPC1uRpg6tayxmbW24IZbT9FFUMYkp3XgkPuHQV7da47lC9 ALb2Th9MzHq4WPqbkOPtX5vKE5P6lfZ0VKOn3eyc2WyF965VyQnx/aua8T0jj/zgzmJt aAnA== MIME-Version: 1.0 X-Received: by 10.141.28.149 with SMTP id f143mr8762277qhe.66.1450475058160; Fri, 18 Dec 2015 13:44:18 -0800 (PST) Received: by 10.55.14.211 with HTTP; Fri, 18 Dec 2015 13:44:18 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 13:44:18 -0800 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11422e8e98e8fe0527330a9a Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 21:44:21 -0000 --001a11422e8e98e8fe0527330a9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 1:10 PM, Roman Shpount wrote: > On Fri, Dec 18, 2015 at 2:34 PM, Ted Hardie wrote: > >> On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount >> wrote: >> >>> Hi All, >>> >>> Since the decision not to support A-D DTMF digits was never made on the >>> IETF list (I have looked through the archive and cannot find it), I do = not >>> think they should be removed. >>> >>> >> =E2=80=8BCan you say more about what use there would be in supporting th= em? >> > > First of all, DTMF support is there for legacy support. > =E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8BI generally dislike when features a= re removed from an established > capability set without a good reason. > =E2=80=8BWe have stretched very far in many directions to be reasonable in = our support of WebRTC to legacy use cases, but =E2=80=8BI don't think we can ar= gue that WebRTC has an established capability set that includes these, nor has anyone given flows where a legacy system would reasonably emit them toward a WebRTC client. > > =E2=80=8BCan anyone name me a single commercial PSTN VoIP gateway which d= oes not > support A-D DTMF tones? I cannot think of one. I believe it would general= ly > make sense to implement whole set defined in > https://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. From > what I know there is no extra implementation to support A-D DTMF tone. It > looks like these tones are removed for aesthetic reasons only. > =E2=80=8BNo, the point Cullen made was that they were sufficiently hit-or-m= iss in terms of system blocking that they were effectively unreliable *in the contexts where WebRTC and legacy might interact*.=E2=80=8B > As far as more specific examples are concerned: > > DTMF tones A-D are used to provide a way to access hidden flows in IVR > systems. For instance, when inbound call center is integrated with an > external auto-dialer, auto-dialer places a call to call center IVR and us= es > a hidden flow accessible via one of those tones to connect directly to a > waiting agent. > > =E2=80=8BGiven that they likely would block the receipt of those tones fr= om external clients in order to avoid this access from outside, this seems like one of the cases that Cullen alluded to; it is permitted only part of the time and the access it provides is not standard.=E2=80=8B > DTMF tones A-D are also commonly used by ham radio operators to integrate > with PSTN, such as http://www.echolink.org/Help/dtmf_functions.htm > > =E2=80=8BThis seems far outside our remit.=E2=80=8B > DTMF tone A-D are used to provide prioritized call handling service in IT= U > Q.955.3 specification which is still used by some PBX and phone systems. > > =E2=80=8BAgain, not at all clear that a WebRTC client would ever expect to = use these features of a PBX. Finally, some calling card like systems allow remote control of functions > such as flash by mapping them to extended DTMF tones. > > =E2=80=8BIf there is a calling card system using WebRTC, I have not heard o= f it. Can you provide a pointer?=E2=80=8B =E2=80=8BThe main point here is that we need a consistent set. I take it y= ou do agree with that point, and disagree only on whether the set should include A-D. Do I have that right? Ted Regards, > _____________ > Roman Shpount > > --001a11422e8e98e8fe0527330a9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2015 at 1:10 PM= , Roman Shpount <roman@telurix.com> wrote:
On Fri, Dec 18, = 2015 at 2:34 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
=
On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount <roman@teluri= x.com> wrote:
Hi All,
=
Since the decision not to support A-D DTMF digits was never = made on the IETF list (I have looked through the archive and cannot find it= ), I do not think they should be removed.


=E2=80=8BCan you say more about what use there would be in supporti= ng them?

First of all, DTMF support is there for legacy support.
=E2=80=8B=C2=A0 =E2=80=8B=E2=80=8B=E2=80=8BI generally dislike = when features are removed from an established capability set without a good= reason.

=E2= =80=8BWe have stretched very far in many directions to be reasonable in our= support of WebRTC to legacy use cases, but =E2=80=8BI don't think we c= an argue that WebRTC has an established capability set that includes these,= nor has anyone given flows where a legacy system would reasonably emit the= m toward a WebRTC client.=C2=A0

=C2=A0
=E2=80=8BCan anyone name me a single commer= cial PSTN VoIP gateway which does not support A-D DTMF tones? I cannot thin= k of one. I believe it would generally make sense to implement whole set de= fined in https:= //tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. From wha= t I know there is no extra implementation to support A-D DTMF tone. It look= s like these tones are removed for aesthetic reasons only.

=E2=80=8BNo, the point Cullen made was that they= were sufficiently hit-or-miss in terms of system blocking that they were e= ffectively unreliable *in the contexts where WebRTC and legacy might intera= ct*.=E2=80=8B

=C2=A0
As far as more specific examples are concerned:

DTMF tones A-D are used to provide a way to access hid= den flows in IVR systems. For instance, when inbound call center is integra= ted with an external auto-dialer, auto-dialer places a call to call center = IVR and uses a hidden flow accessible via one of those tones to connect dir= ectly to a waiting agent.

=E2=80=8BGiven that they likely would block the receipt of= those tones from external clients in order to avoid this access from outsi= de, this seems like one of the cases that Cullen alluded to; it is permitte= d only part of the time and the access it provides is not standard.=E2=80= =8B

=C2=A0
=
DTMF tones A-D are also commonly used by ham radio operator= s to integrate with PSTN, such as=C2=A0http://www.echolink.org/Help/dtmf= _functions.htm

=
=E2=80=8BThis seems far outside our remit.=E2=80=8B
=C2= =A0
DTMF tone= A-D are used to provide prioritized call handling service in ITU Q.955.3 s= pecification which is still used by some PBX and phone systems.


= =E2=80=8BAgain, not at all clear that a WebRTC client would ever expect to = use these features of a PBX.

Finally, some calling card like systems allow remote = control of functions such as flash by mapping them to extended DTMF tones.<= /div>


=E2= =80=8BIf there is a calling card system using WebRTC, I have not heard of i= t.=C2=A0 Can you provide a pointer?=E2=80=8B

=E2=80=8BThe main point here is that we need a consistent set.=C2=A0 I = take it you do agree with that point, and disagree only on whether the set = should include A-D.=C2=A0 Do I have that right?

Ted


Regards,
=
_____________
Roman Shpoun= t
=C2=A0

--001a11422e8e98e8fe0527330a9a-- From nobody Fri Dec 18 13:47:13 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3361B393F for ; Fri, 18 Dec 2015 13:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BrBNfZEPw4U for ; Fri, 18 Dec 2015 13:47:10 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4421B393A for ; Fri, 18 Dec 2015 13:47:10 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id o67so103359705iof.3 for ; Fri, 18 Dec 2015 13:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tgroDG0g/ctOYsPirZkqhmUtvt4qdbgCrlpobN4OFI8=; b=UMzpYVFWrNbFLKSaYCKRAj4ekGI36sVEWy1LH+CKxd7w2qf0yOQD6loNQ4XuDpAPyk 1xRuP0Kfm6z9UiseiLazlpvTi9MPrxQyWLk1IXXV8TFFIpUdorF/qnhf1zt95511kih0 jhndWmkV+toKqMvqd79QFqQztpa4R5XPm1tYrg1soIi+5k0sMc4OLwrY2oDFXvNtm7V8 vu9tH0ZBe95qB0wp5nWuPK9qeKiko12LhcO0WVg4UBK6JGVcF971WQRG77pgLRR1MEsU MNHI11ZZ0AQbA4MbjuSisovhr1I+YMN1gtdhrKpMJzvKvPVaiub1NItDHPjoYHF+wsRm 9B6A== 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=tgroDG0g/ctOYsPirZkqhmUtvt4qdbgCrlpobN4OFI8=; b=HESLNXU+Jnxcr/jMgfnWewvF07p/yLnq/pYhhJJ2mulgs5m4n6MV0r8xl85ccxojtP d1anY4keKMqa0l8vyJ9ZJQwDIPOAG9f2Nb0/vMPdQvfUV1OTWBdR1mFoFdNFq2UwwJAM 8QLqp7n92Jx1UhlHyElf3yURFJAOFNzjgfZnjqLAPc8uo2mzesP2ZHqaPyOOR5px/llq 7uRwsU94I14siBmW9n+exCTLtRB2ntY8vjB2ZmNaP6iwFIPwbn4F1797hmAug+5dnlCQ rCP+oQBnfbw0xcIPYp6i3bi8mLZoG7a8HkzY7Yi3logmCJIkqF/qWoBeZVLYGXLc+KCg HCTw== X-Gm-Message-State: ALoCoQnXGkFob3AtGvo7yN5mizM2MAoJ7R6riaoj9cvChxzcMTcUma08B041DBTyCTbhypKZPcZNZcphmGsTIuMVBfTSUT9/6w== X-Received: by 10.107.163.6 with SMTP id m6mr7574500ioe.1.1450475229870; Fri, 18 Dec 2015 13:47:09 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by smtp.gmail.com with ESMTPSA id u24sm7248297ioi.14.2015.12.18.13.47.07 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 13:47:08 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id ph11so1063955igc.1 for ; Fri, 18 Dec 2015 13:47:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.115.103 with SMTP id jn7mr5734106igb.2.1450475227443; Fri, 18 Dec 2015 13:47:07 -0800 (PST) Received: by 10.36.105.15 with HTTP; Fri, 18 Dec 2015 13:47:07 -0800 (PST) In-Reply-To: <5674797A.9020102@nostrum.com> References: <5674797A.9020102@nostrum.com> Date: Fri, 18 Dec 2015 16:47:07 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=089e01176f6db0260e0527331469 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 21:47:12 -0000 --089e01176f6db0260e0527331469 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 18, 2015 at 4:24 PM, Adam Roach wrote: > On 12/18/15 15:10, Roman Shpount wrote: > >> It looks like these tones are removed for aesthetic reasons only. >> > > I think it would be better if you directly disagreed with Cullen's > rationale rather than simply ignoring it. Since it was made in a different > forum, I'll copy it here. > I was reminded multiple times that here is the right forum to discuss this issue. I am mostly looking for a consensus made here and then propagated to W3C. > On 12/9/15 12:48, Cullen Jennings wrote: > >> I want to be clear I don't care that much one way or the other about this >> but I want to try again to explain the issue... >> >> A to D will often be blocked by the system that sends them from one side >> to the other. So if you write JS applications that use theses, they will >> work some times and not others. That is just inviting developers to shoot >> themselves in the foot and no one has identified any benefit of adding A to >> D yet. >> >> 100% agree that the IETF and W3C specs need to align on this and we >> should change the ietf audio draft if we are including A-D. >> >> > To be clear, this is speaking to operational aspects of the system's > behavior that I haven't had much visibility into. We have one implementor > effectively asserting that all commercial gateways support these tones, and > another saying that they tend to be blocked by intermediaries. I suppose > both assertions could be true, but the net effect of both being true is > that these tones are broadly unusable. > > But I'm in the same boat as Cullen: I don't care much whether these tones > are supported, as long as the W3C and IETF documents agree with each other. > DTMF tones A-D can be tricky and might not work in 100% of cases. Unfortunately this applies to all DTMF tones. For instance, DTMF tones from the party receiving the call do not work in a fair number of cases. If developer is using DTMF tones, they should be prepared to deal with consequences. For instance, as a part of operating a conferencing service with traditional PSTN access we need to deal with 2-3 tickets per day which are related to DTMF transmission over various telephone networks. At the same time WebRTC application can be connected to a legacy PSTN system under developer control (i.e. through the gateway to a PBX which uses tone A-D for special purpose such as to trigger phone line flash). In such application these tones will work every time with 100% certainty. In my previous email I have listed examples of legacy applications that still use DTMF tones A-D. I think this is reason enough to keep them. My main point is that it is probably easier to leave the legacy things alone instead of improving them. DTMF should not be used for any new applications. Datachannels are a much better option. DTMF should be left for legacy interop only, so there is no reason to redesign them or make them easier to use. They worked fine for the past 50 years. _____________ Roman Shpount --089e01176f6db0260e0527331469 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2015 at 4:24 PM, Adam Roach <adam@nostrum.com><= /span> wrote:
= On 12/18/15 15:10, Roman Shpount wrote:
It looks like these tones are removed for aesthetic reasons only.

 I think it would be better if you directly disagreed with Cullen's rati= onale rather than simply ignoring it. Since it was made in a different foru= m, I'll copy it here.

I was reminde= d multiple times that here is the right forum to discuss this issue. I am m= ostly looking for a consensus made here and then propagated to W3C.
=C2=A0
On 12/9/15 12:48, Cullen Jennings wrote:
I want to be clear I don't care that much one way or the other about th= is but I want to try again to explain the issue...

A to D will often be blocked by the system that sends them from one side to= the other. So if you write JS applications that use theses, they will work= some times and not others. That is just inviting developers to shoot thems= elves in the foot and no one has identified any benefit of adding A to D ye= t.

100% agree that the IETF and W3C specs need to align on this and we should = change the ietf audio draft if we are including A-D.


To be clear, this is speaking to operational aspects of the system's be= havior that I haven't had much visibility into. We have one implementor= effectively asserting that all commercial gateways support these tones, an= d another saying that they tend to be blocked by intermediaries. I suppose = both assertions could be true, but the net effect of both being true is tha= t these tones are broadly unusable.

But I'm in the same boat as Cullen: I don't care much whether these= tones are supported, as long as the W3C and IETF documents agree with each= other.

DTMF tones A-D can be tricky and might not work in = 100% of cases. Unfortunately this applies to all DTMF tones. For instance, = DTMF tones from the party receiving the call do not work in a fair number o= f cases. If developer is using DTMF tones, they should be prepared to deal = with consequences. For instance, as a part of operating a conferencing serv= ice with traditional PSTN access we need to deal with 2-3 tickets per day w= hich are related to DTMF transmission over various telephone networks.

At the same time WebRTC application can be connected t= o a legacy PSTN system under developer control (i.e. through the gateway to= a PBX which uses tone A-D for special purpose such as to trigger phone lin= e flash). In such application these tones will work every time with 100% ce= rtainty.

In my previous email I have listed exampl= es of legacy applications that still use DTMF tones A-D. I think this is re= ason enough to keep them.

My main point is that it= is probably easier to leave the legacy things alone instead of improving t= hem. DTMF should not be used for any new applications. Datachannels are a m= uch better option. DTMF should be left for legacy interop only, so there is= no reason to redesign them or make them easier to use. They worked fine fo= r the past 50 years.
_____________=
Roman Shpount
=C2=A0

--089e01176f6db0260e0527331469-- From nobody Fri Dec 18 14:10:39 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37091B396F for ; Fri, 18 Dec 2015 14:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5InaoD5lhkkw for ; Fri, 18 Dec 2015 14:10:35 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42E41B396C for ; Fri, 18 Dec 2015 14:10:34 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id mv3so1420637igc.0 for ; Fri, 18 Dec 2015 14:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bF37ee3k0TZTU4jv1WhmKIBLZdsom5U6JHJqEOzN/5o=; b=XNqvd0e+MdSGrenlUiXTJX6MemsTWqKP7oBSiLFoRWXZKSQ5S8km5SyvmllFU5ClUB 4laD07oJl66SH2nbHVE+AcINV7fr3Ylvz85/m+BnIlqnuFcFGTyCYDQol/cUPbNPBxXX pmzosCKyUms6XwQOKEwCDoALaURyUQjh+bczxYGWw9vhYCD+y3oJI0/4rGiStVa3PVCA CGnqQuzaqoFQax4jL5tzqOXtbohZm7mbHcGhoiAs1pyAxB5Jzt5Zr6+oLsMMx0Ek86e3 0qEtIEaxGa+LEhXTL09N3wVL+JPIWSnSMIlbDsqJlYMSTnYOkQU+VAsVpLa0O+CIXObw V/4A== 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=bF37ee3k0TZTU4jv1WhmKIBLZdsom5U6JHJqEOzN/5o=; b=F2JrNBkvZtE38d6zoA4uJGbHJVdTTs4/mx5OqbN8VljY6AzxC5UvKLGSlAl7MBiFxj O3Ihy3yLgi2iKhtij/Tdo629hxZGnUpTZgifxMzaJ/giyXRaTaJ166sROQ75J59IlFQt uIpfXkc37y3InBIEUCyou6ZWgcSiQB3X0mNuUbhvHzLXdo1kyobD3L+hiIGo/aNZIbfX V9wEunH1toLeqZbGyMEUp3Nkor0+NzFU4lFyuVPzL7HcKjFOPMpjlRvQw6lc2YaLDHm3 e6lj+ZdUscqOnn0LzOML/bI8j7C2YQZYTdLoqzoadquuFRyjo8qzL8YRe6umvmlTHZN6 qwUg== X-Gm-Message-State: ALoCoQk00l5lB9TkJaWAG87Y+kXyF9jNhZyGSdRSRJmxSNMLtBTTwvShIKpht1jp3Z7vf1j+OIecb8l5fJCcrf5rJPN7iJ74lA== X-Received: by 10.50.107.3 with SMTP id gy3mr5554846igb.48.1450476634098; Fri, 18 Dec 2015 14:10:34 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id jc1sm3442414igb.7.2015.12.18.14.10.31 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 14:10:32 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id e126so103986583ioa.1 for ; Fri, 18 Dec 2015 14:10:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.155.149 with SMTP id d143mr7586515ioe.145.1450476631544; Fri, 18 Dec 2015 14:10:31 -0800 (PST) Received: by 10.36.105.15 with HTTP; Fri, 18 Dec 2015 14:10:31 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 17:10:31 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=001a11409fc260e04f0527336849 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 22:10:38 -0000 --001a11409fc260e04f0527336849 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 4:44 PM, Ted Hardie wrote: > On Fri, Dec 18, 2015 at 1:10 PM, Roman Shpount wrote: > >> On Fri, Dec 18, 2015 at 2:34 PM, Ted Hardie wrote: >> >>> On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount >>> wrote: >>> >>>> Hi All, >>>> >>>> Since the decision not to support A-D DTMF digits was never made on th= e >>>> IETF list (I have looked through the archive and cannot find it), I do= not >>>> think they should be removed. >>>> >>>> >>> =E2=80=8BCan you say more about what use there would be in supporting t= hem? >>> >> >> First of all, DTMF support is there for legacy support. >> =E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8BI generally dislike when features = are removed from an established >> capability set without a good reason. >> > > =E2=80=8BWe have stretched very far in many directions to be reasonable i= n our > support of WebRTC to legacy use cases, but =E2=80=8BI don't think we can = argue that > WebRTC has an established capability set that includes these, nor has > anyone given flows where a legacy system would reasonably emit them towar= d > a WebRTC client. > There is no additional implementation burden to support DTMF tones A-D, so there is no stretching as far as any additional work is concerned. I can guarantee you that legacy systems will generate DTMF tones towards WebRTC client. Offer/answer telephone event negotiation is normally by directional. This normally enabled DTMF detection in PSTN gateways. So, if you have any system that connects WebRTC client to PSTN network, and if the person on PSTN network will press a keypad digit, this digit will be sent to WebRTC client. Furthermore, it is common for DTMF digit detection to be caused by talk off, i.e. some voice periodically triggers DTMF detection. Finally, some gateways will also send ANS tones if the call hits a fax machine, so WebRTC end point will get not only DTMF events, but events for tone that someone just happened to enable on the gateway. Unless we want to transcode media coming from PSTN, WebRTC client will need to deal with any incoming telephone-events. All of this being said, it is up to WebRTC client to decide what to do with the received events. I am fine with these tones being discard as long as they are being discarded in a manner which does not disrupt normal audio processing. This means no unexpected jitter buffer adjustments, packet loss correction for the audio segment covered by telephone-event, treating these packets as lost, or payload mismatch. > =E2=80=8BCan anyone name me a single commercial PSTN VoIP gateway which d= oes not >> support A-D DTMF tones? I cannot think of one. I believe it would genera= lly >> make sense to implement whole set defined in >> https://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. >> From what I know there is no extra implementation to support A-D DTMF to= ne. >> It looks like these tones are removed for aesthetic reasons only. >> > > =E2=80=8BNo, the point Cullen made was that they were sufficiently hit-or= -miss in > terms of system blocking that they were effectively unreliable *in the > contexts where WebRTC and legacy might interact*.=E2=80=8B > All DTMF are often unreliable. There are also enough cases when they are absolutely reliable. In places where they have been used, they can continue to be used for legacy interop. In cases where they were unreliable they will continue to be unreliable. It is not our job to fix or change this. > As far as more specific examples are concerned: >> >> DTMF tones A-D are used to provide a way to access hidden flows in IVR >> systems. For instance, when inbound call center is integrated with an >> external auto-dialer, auto-dialer places a call to call center IVR and u= ses >> a hidden flow accessible via one of those tones to connect directly to a >> waiting agent. >> >> =E2=80=8BGiven that they likely would block the receipt of those tones f= rom > external clients in order to avoid this access from outside, this seems > like one of the cases that Cullen alluded to; it is permitted only part o= f > the time and the access it provides is not standard.=E2=80=8B > This is absolutely incorrect. In this particular example auto-dialer is running on a hosted platform and accesses the inbound call center over public PSTN. > DTMF tones A-D are also commonly used by ham radio operators to integrate >> with PSTN, such as http://www.echolink.org/Help/dtmf_functions.htm >> >> > =E2=80=8BThis seems far outside our remit.=E2=80=8B > Why? I have already seen a few virtual ham radio stations with WebRTC interface DTMF tone A-D are used to provide prioritized call handling service in ITU >> Q.955.3 specification which is still used by some PBX and phone systems. >> >> > =E2=80=8BAgain, not at all clear that a WebRTC client would ever expect t= o use > these features of a PBX. > There are intranet WebRTC applications that access in-company legacy PBX via a private gateway. Finally, some calling card like systems allow remote control of functions >> such as flash by mapping them to extended DTMF tones. >> >> > =E2=80=8BIf there is a calling card system using WebRTC, I have not heard= of it. > Can you provide a pointer?=E2=80=8B > Once again, this would be a private WebRTC application used to place calls through a gateway which is under control of the person who developer the app. =E2=80=8BThe main point here is that we need a consistent set. I take it y= ou do > agree with that point, and disagree only on whether the set should includ= e > A-D. Do I have that right? > I agree that we need a consistent set. I would also like that this set would be defined once and will have no optional components. I do not want to spent any more time discussion they API to discover which DTMF tones are supported by a particular implementation. Including tones A-D removes any excuses for such options. Regards, _____________ Roman Shpount --001a11409fc260e04f0527336849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2015 at 4:44 PM, Ted Hardie <ted.ietf@gmail.com&= gt; wrote:
On Fri, Dec = 18, 2015 at 1:10 PM, Roman Shpount <roman@telurix.com> wrote= :
=
On Fri, Dec 18,= 2015 at 2:34 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Fri, Dec 18, 2015 at 10:32 = AM, Roman Shpount <roman@telurix.com> wrote:
Hi All,
<= br>
Since the decision not to support A-D DTMF digits was never m= ade on the IETF list (I have looked through the archive and cannot find it)= , I do not think they should be removed.


=E2=80=8BCan you say more about what use there would be in supportin= g them?

First of all, DTMF support is there for legacy support.
=E2=80=8B=C2= =A0 =E2=80=8B=E2=80=8B=E2=80=8BI generally dislike when features are remove= d from an established capability set without a good reason.

=E2=80=8BWe have stretched very far in many di= rections to be reasonable in our support of WebRTC to legacy use cases, but= =E2=80=8BI don't think we can argue that WebRTC has an established cap= ability set that includes these, nor has anyone given flows where a legacy = system would reasonably emit them toward a WebRTC client.=C2=A0
<= /div>

There is no additio= nal implementation burden to support DTMF tones A-D, so there is no stretch= ing as far as any additional work is concerned.

I = can guarantee you that legacy systems will generate DTMF tones towards WebR= TC client. Offer/answer telephone event negotiation is normally by directio= nal. This normally enabled DTMF detection in PSTN gateways. So, if you have= any system that connects WebRTC client to PSTN network, and if the person = on PSTN network will press a keypad digit, this digit will be sent to WebRT= C client. Furthermore, it is common for DTMF digit detection to be caused b= y talk off, i.e. some voice periodically triggers DTMF detection. Finally, = some gateways will also send ANS tones if the call hits a fax machine, so W= ebRTC end point will get not only DTMF events, but events for tone that som= eone just happened to enable on the gateway. Unless we want to transcode me= dia coming from PSTN, WebRTC client will need to deal with any incoming tel= ephone-events. All of this being said, it is up to WebRTC client to decide = what to do with the received events. I am fine with these tones being disca= rd as long as they are being discarded in a manner which does not disrupt n= ormal audio processing. This means no unexpected jitter buffer adjustments,= packet loss correction for the audio segment covered by telephone-event, t= reating these packets as lost, or payload mismatch.=C2=A0
=C2=A0<= /div>
=E2=80=8BCan anyone n= ame me a single commercial PSTN VoIP gateway which does not support A-D DTM= F tones? I cannot think of one. I believe it would generally make sense to = implement whole set defined in https://tools.ietf.org/html/rfc4733#secti= on-3.2 instead of just 3/4. From what I know there is no extra implemen= tation to support A-D DTMF tone. It looks like these tones are removed for = aesthetic reasons only.

=E2=80=8BNo, the point C= ullen made was that they were sufficiently hit-or-miss in terms of system b= locking that they were effectively unreliable *in the contexts where WebRTC= and legacy might interact*.=E2=80=8B

All DTMF are often unreliable. There are also enou= gh cases when they are absolutely reliable. In places where they have been = used, they can continue to be used for legacy interop. In cases where they = were unreliable they will continue to be unreliable. It is not our job to f= ix or change this.
=C2=A0
=
As far as more specific examples are concerned:
DTMF tones A-D are used to provide a way to access hidden flows= in IVR systems. For instance, when inbound call center is integrated with = an external auto-dialer, auto-dialer places a call to call center IVR and u= ses a hidden flow accessible via one of those tones to connect directly to = a waiting agent.

=
=E2=80=8B= Given that they likely would block the receipt of those tones from external= clients in order to avoid this access from outside, this seems like one of= the cases that Cullen alluded to; it is permitted only part of the time an= d the access it provides is not standard.=E2=80=8B
<= /div>

This is absolutely incorrect. In this= particular example auto-dialer is running on a hosted platform and accesse= s the inbound call center over public PSTN.
=C2=A0
DTMF tones A-D are also commonly use= d by ham radio operators to integrate with PSTN, such as=C2=A0http://www= .echolink.org/Help/dtmf_functions.htm

<= /div>

=E2=80=8BThis seems far outside our remit.=E2=80=8B

Why? I have alre= ady seen a few virtual ham radio stations with WebRTC interface=C2=A0
=

DTMF tone A-D are= used to provide prioritized call handling service in ITU Q.955.3 specifica= tion which is still used by some PBX and phone systems.


=E2=80=8BAgain, not at a= ll clear that a WebRTC client would ever expect to use these features of a = PBX.

There ar= e intranet WebRTC applications that access in-company legacy PBX via a priv= ate gateway.

Finally, some calling card like systems allow remote control of funct= ions such as flash by mapping them to extended DTMF tones.


=E2=80=8BIf there is a calling card sy= stem using WebRTC, I have not heard of it.=C2=A0 Can you provide a pointer?= =E2=80=8B

Onc= e again, this would be a private WebRTC application used to place calls thr= ough a gateway which is under control of the person who developer the app.<= /div>

=E2=80=8BThe main point here is that= we need a consistent set.=C2=A0 I take it you do agree with that point, an= d disagree only on whether the set should include A-D.=C2=A0 Do I have that= right?

I= agree that we need a consistent set. I would also like that this set would= be defined once and will have no optional components. I do not want to spe= nt any more time discussion they API to discover which DTMF tones are suppo= rted by a particular implementation. Including tones A-D removes any excuse= s for such options.

Regards,
_____________
Roman Shpount
=C2=A0<= /div>
--001a11409fc260e04f0527336849-- From nobody Fri Dec 18 14:22:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129011B397A for ; Fri, 18 Dec 2015 14:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dilIvGXQD2cw for ; Fri, 18 Dec 2015 14:22:11 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1C61B3976 for ; Fri, 18 Dec 2015 14:22:11 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id v36so44128494qgd.2 for ; Fri, 18 Dec 2015 14:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H6tuUz5zFRgNQgc2pnpfFYG0onE29aGNSo2LSIStMrc=; b=jzrZAHNb7acT0BZLsizOn0MxHZhPe3V7UEfNMTYTRdBeZKOewg6FOdy7/4DaLuhO8V lTZb8s+wz/oNfSLzy4qxwxSF7UA/8kktGH37MAuojyriLviyYuZGG4+BOFTgUlWfdK6r cJF8OtmYnypHlDIVkoXac+Nesl9qsFbu8RsGgHCYEY9b5wjObHYTm43FVmqjmTWfKEWi 2CcX0/UPiDMVXk63i0Wp0UswDdbxdqEA74D25htjiNKDiRfIgIDdRGQncKnY2hndQOR5 H8rcf8Hnljpo2toyMhi0HfzOZlJpP3if8coTyX6WOFkeJsRfhwFVN/92jfO8JyV86DSQ ozWw== MIME-Version: 1.0 X-Received: by 10.140.141.210 with SMTP id 201mr8980181qhn.74.1450477330405; Fri, 18 Dec 2015 14:22:10 -0800 (PST) Received: by 10.55.14.211 with HTTP; Fri, 18 Dec 2015 14:22:10 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 14:22:10 -0800 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: multipart/alternative; boundary=001a1137595c089f3f052733923c Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 22:22:15 -0000 --001a1137595c089f3f052733923c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 2:10 PM, Roman Shpount wrote: > On Fri, Dec 18, 2015 at 4:44 PM, Ted Hardie wrote: > >> On Fri, Dec 18, 2015 at 1:10 PM, Roman Shpount wrote= : >> >>> On Fri, Dec 18, 2015 at 2:34 PM, Ted Hardie wrote: >>> >>>> On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> Since the decision not to support A-D DTMF digits was never made on >>>>> the IETF list (I have looked through the archive and cannot find it),= I do >>>>> not think they should be removed. >>>>> >>>>> >>>> =E2=80=8BCan you say more about what use there would be in supporting = them? >>>> >>> >>> First of all, DTMF support is there for legacy support. >>> =E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8BI generally dislike when features= are removed from an established >>> capability set without a good reason. >>> >> >> =E2=80=8BWe have stretched very far in many directions to be reasonable = in our >> support of WebRTC to legacy use cases, but =E2=80=8BI don't think we can= argue that >> WebRTC has an established capability set that includes these, nor has >> anyone given flows where a legacy system would reasonably emit them towa= rd >> a WebRTC client. >> > > There is no additional implementation burden to support DTMF tones A-D, s= o > there is no stretching as far as any additional work is concerned. > > I can guarantee you that legacy systems will generate DTMF tones towards > WebRTC client. > =E2=80=8BSorry that this was not clear; I meant specifically A-D.=E2=80=8B Offer/answer telephone event negotiation is normally by directional. This > normally enabled DTMF detection in PSTN gateways. So, if you have any > system that connects WebRTC client to PSTN network, and if the person on > PSTN network will press a keypad digit, this digit will be sent to WebRTC > client. Furthermore, it is common for DTMF digit detection to be caused b= y > talk off, i.e. some voice periodically triggers DTMF detection. Finally, > some gateways will also send ANS tones if the call hits a fax machine, so > WebRTC end point will get not only DTMF events, but events for tone that > someone just happened to enable on the gateway. Unless we want to transco= de > media coming from PSTN, WebRTC client will need to deal with any incoming > telephone-events. All of this being said, it is up to WebRTC client to > decide what to do with the received events. I am fine with these tones > being discard as long as they are being discarded in a manner which does > not disrupt normal audio processing. > =E2=80=8BThis seems to result in exactly the case Cullen was concerned abou= t; if they may be discarded their functionality remains completely unreliable.=E2= =80=8B But more to the point, you are not pointing to uses of A-D, but number detection and events which would still be covered. This means no unexpected jitter buffer adjustments, packet loss correction > for the audio segment covered by telephone-event, treating these packets = as > lost, or payload mismatch. > > > =E2=80=8BCan anyone name me a single commercial PSTN VoIP gateway which doe= s not >>> support A-D DTMF tones? I cannot think of one. I believe it would gener= ally >>> make sense to implement whole set defined in >>> https://tools.ietf.org/html/rfc4733#section-3.2 instead of just 3/4. >>> From what I know there is no extra implementation to support A-D DTMF t= one. >>> It looks like these tones are removed for aesthetic reasons only. >>> >> >> =E2=80=8BNo, the point Cullen made was that they were sufficiently hit-o= r-miss in >> terms of system blocking that they were effectively unreliable *in the >> contexts where WebRTC and legacy might interact*.=E2=80=8B >> > > All DTMF are often unreliable. There are also enough cases when they are > absolutely reliable. In places where they have been used, they can contin= ue > to be used for legacy interop. In cases where they were unreliable they > will continue to be unreliable. It is not our job to fix or change this. > =E2=80=8BWhile this is no doubt not your intent, I must say your message re= ads as "Sure it's broken now, but we must make sure it remains broken to be backwards compatible."=E2=80=8B > > >> As far as more specific examples are concerned: >>> >>> DTMF tones A-D are used to provide a way to access hidden flows in IVR >>> systems. For instance, when inbound call center is integrated with an >>> external auto-dialer, auto-dialer places a call to call center IVR and = uses >>> a hidden flow accessible via one of those tones to connect directly to = a >>> waiting agent. >>> >>> =E2=80=8BGiven that they likely would block the receipt of those tones = from >> external clients in order to avoid this access from outside, this seems >> like one of the cases that Cullen alluded to; it is permitted only part = of >> the time and the access it provides is not standard.=E2=80=8B >> > > This is absolutely incorrect. In this particular example auto-dialer is > running on a hosted platform and accesses the inbound call center over > public PSTN. > > >> DTMF tones A-D are also commonly used by ham radio operators to integrat= e >>> with PSTN, such as http://www.echolink.org/Help/dtmf_functions.htm >>> >>> >> =E2=80=8BThis seems far outside our remit.=E2=80=8B >> > > Why? I have already seen a few virtual ham radio stations with WebRTC > interface > > =E2=80=8BThe only A-D tone in the one example you gave (echolink) was to pu= ll up a different stored configuration. > DTMF tone A-D are used to provide prioritized call handling service in IT= U >>> Q.955.3 specification which is still used by some PBX and phone systems= . >>> >>> >> =E2=80=8BAgain, not at all clear that a WebRTC client would ever expect = to use >> these features of a PBX. >> > > There are intranet WebRTC applications that access in-company legacy PBX > via a private gateway. > =E2=80=8BAnd they are using the A-D set? =E2=80=8B > > Finally, some calling card like systems allow remote control of functions >>> such as flash by mapping them to extended DTMF tones. >>> >>> >> =E2=80=8BIf there is a calling card system using WebRTC, I have not hear= d of it. >> Can you provide a pointer?=E2=80=8B >> > > Once again, this would be a private WebRTC application used to place call= s > through a gateway which is under control of the person who developer the > app. > > =E2=80=8BSo this is theoretical.=E2=80=8B > =E2=80=8BThe main point here is that we need a consistent set. I take it= you do >> agree with that point, and disagree only on whether the set should inclu= de >> A-D. Do I have that right? >> > > I agree that we need a consistent set. I would also like that this set > would be defined once and will have no optional components. I do not want > to spent any more time discussion they API to discover which DTMF tones a= re > supported by a particular implementation. Including tones A-D removes any > excuses for such options. > > =E2=80=8BRemoving them from the set does as well, at least as far as I can = tell. No one has suggested that they be the subject of discovery or negotiation.= =E2=80=8B =E2=80=8BTed =E2=80=8B > Regards, > _____________ > Roman Shpount > > --001a1137595c089f3f052733923c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec= 18, 2015 at 2:10 PM, Roman Shpount <roman@telurix.com> wrot= e:
On Fri, Dec 18,= 2015 at 4:44 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Fri, Dec 18, 201= 5 at 1:10 PM, Roman Shpount <roman@telurix.com> wrote:
On Fri, Dec 18, 2015 at 2:34 PM, Te= d Hardie <ted.ietf@gmail.com> wrote:
=
On Fri, Dec 18, 2015 at 10:32 AM, Roman Shpount <= roman@telurix.com> wrote:
Hi All,

Since = the decision not to support A-D DTMF digits was never made on the IETF list= (I have looked through the archive and cannot find it), I do not think the= y should be removed.

=E2=80=8BCan = you say more about what use there would be in supporting them?

First of all, = DTMF support is there for legacy support.
=E2=80=8B=C2=A0 =E2=80=8B=E2=80= =8B=E2=80=8BI generally dislike when features are removed from an establish= ed capability set without a good reason.

=E2=80=8BWe have stretched very far in many directions to be reas= onable in our support of WebRTC to legacy use cases, but =E2=80=8BI don'= ;t think we can argue that WebRTC has an established capability set that in= cludes these, nor has anyone given flows where a legacy system would reason= ably emit them toward a WebRTC client.=C2=A0

There is no additional implemen= tation burden to support DTMF tones A-D, so there is no stretching as far a= s any additional work is concerned.

I can guarante= e you that legacy systems will generate DTMF tones towards WebRTC client. <= /div>

=E2=80=8BSorry that = this was not clear; I meant specifically A-D.=E2=80=8B

Offer/answer telephone event negotiation is norm= ally by directional. This normally enabled DTMF detection in PSTN gateways.= So, if you have any system that connects WebRTC client to PSTN network, an= d if the person on PSTN network will press a keypad digit, this digit will = be sent to WebRTC client. Furthermore, it is common for DTMF digit detectio= n to be caused by talk off, i.e. some voice periodically triggers DTMF dete= ction. Finally, some gateways will also send ANS tones if the call hits a f= ax machine, so WebRTC end point will get not only DTMF events, but events f= or tone that someone just happened to enable on the gateway. Unless we want= to transcode media coming from PSTN, WebRTC client will need to deal with = any incoming telephone-events. All of this being said, it is up to WebRTC c= lient to decide what to do with the received events. I am fine with these t= ones being discard as long as they are being discarded in a manner which do= es not disrupt normal audio processing.

=E2=80=8BThis seems to result in exactly the case Cull= en was concerned about; if they may be discarded their functionality remain= s completely unreliable.=E2=80=8B=C2=A0 But more to the point, you are not = pointing to uses of A-D, but number detection and events which would still = be covered.

This means n= o unexpected jitter buffer adjustments, packet loss correction for the audi= o segment covered by telephone-event, treating these packets as lost, or pa= yload mismatch.=C2=A0
=C2=A0
=C2=A0
=E2=80=8BCan anyone name me a s= ingle commercial PSTN VoIP gateway which does not support A-D DTMF tones? I= cannot think of one. I believe it would generally make sense to implement = whole set defined in https://tools.ietf.org/html/rfc4733#section-3.2= instead of just 3/4. From what I know there is no extra implementation to = support A-D DTMF tone. It looks like these tones are removed for aesthetic = reasons only.

=E2=80=8BNo, the point Cullen made = was that they were sufficiently hit-or-miss in terms of system blocking tha= t they were effectively unreliable *in the contexts where WebRTC and legacy= might interact*.=E2=80=8B
<= br>
All DTMF are often unreliable. There are also enough c= ases when they are absolutely reliable. In places where they have been used= , they can continue to be used for legacy interop. In cases where they were= unreliable they will continue to be unreliable. It is not our job to fix o= r change this.

=E2=80=8BWhile this is no doubt not your inte= nt, I must say your message reads as "Sure it's broken now, but we= must make sure it remains broken to be backwards compatible."=E2=80= =8B

=C2=A0
= =C2=A0
As far as more specific ex= amples are concerned:

DTMF tones A-D are used to p= rovide a way to access hidden flows in IVR systems. For instance, when inbo= und call center is integrated with an external auto-dialer, auto-dialer pla= ces a call to call center IVR and uses a hidden flow accessible via one of = those tones to connect directly to a waiting agent.

=E2=80=8BGiven that they likely would block the r= eceipt of those tones from external clients in order to avoid this access f= rom outside, this seems like one of the cases that Cullen alluded to; it is= permitted only part of the time and the access it provides is not standard= .=E2=80=8B

=
This is absolutely incorrect. In this particular example auto-dialer i= s running on a hosted platform and accesses the inbound call center over pu= blic PSTN.
=C2=A0
DTMF tones A-D are also commonly used by ham radio operators to= integrate with PSTN, such as=C2=A0http://www.echolink.org/Help/dtmf_fun= ctions.htm


=E2=80= =8BThis seems far outside our remit.=E2=80=8B
=

Why? I have already seen a few virt= ual ham radio stations with WebRTC interface=C2=A0


=E2= =80=8BThe only A-D tone in the one example you gave (echolink) was to pull = up a different stored configuration.

=C2=A0
=
DTMF= tone A-D are used to provide prioritized call handling service in ITU Q.95= 5.3 specification which is still used by some PBX and phone systems.
<= div class=3D"gmail_quote">
=E2=80=8BAga= in, not at all clear that a WebRTC client would ever expect to use these fe= atures of a PBX.

<= /span>
There are intranet WebRTC applications that access in-company le= gacy PBX via a private gateway.
=E2=80=8BAnd they are using the A-D set?
=E2= =80=8B
=C2=A0
Finally, some calling card lik= e systems allow remote control of functions such as flash by mapping them t= o extended DTMF tones.

<= /span>

=E2=80=8BIf there is a calling card system using WebRTC, I have not heard = of it.=C2=A0 Can you provide a pointer?=E2=80=8B

Once again, this would be a priv= ate WebRTC application used to place calls through a gateway which is under= control of the person who developer the app.

=E2=80=8BS= o this is theoretical.=E2=80=8B

=C2=A0
=E2=80=8BThe main point= here is that we need a consistent set.=C2=A0 I take it you do agree with t= hat point, and disagree only on whether the set should include A-D.=C2=A0 D= o I have that right?
I agree that we need a consistent set. I would also like= that this set would be defined once and will have no optional components. = I do not want to spent any more time discussion they API to discover which = DTMF tones are supported by a particular implementation. Including tones A-= D removes any excuses for such options.


=E2=80=8BRemoving them from the set does= as well, at least as far as I can tell.=C2=A0 No one has suggested that th= ey be the subject of discovery or negotiation.=E2=80=8B

=C2=A0=E2=80=8BTed
=E2=80=8B
Regards,
_____________
Roman Shpount
=C2=A0

--001a1137595c089f3f052733923c-- From nobody Fri Dec 18 15:24:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9091A004C for ; Fri, 18 Dec 2015 15:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAR9gsRduzdC for ; Fri, 18 Dec 2015 15:24:19 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5351B1A0049 for ; Fri, 18 Dec 2015 15:24:19 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id to18so2377310igc.0 for ; Fri, 18 Dec 2015 15:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o0ksi5511coOPhn6UNViAskski+Jzkd9Cb54z0HJwJg=; b=QtPyySZ2tyOAG+a912HJesL4kmCP2DNHuSbGd7AvRnpfgkU1ccbSia/wnnxHxlObVq XHaVqMF70V3gpk+d/XZjtWA9XtIOiSe1znrYGhYjwuRIfQKx5A/SIGpaVut9uh6FHfqz 6mM8Wq+hRvqfOnmvmsnJFFgKz8T45+vSaEAcBMajGkgwFuUBRsMjCqqhwT23uzJaBL6Q yRYchFhf5MvHINOvuWEcgmEYd3Qyv4QMoCf9xTor3IEZH89VAmGKh8CUK0SIgCj5fPzp YH7kapRxzdpskoduZg/DNAS07TlMNzNURMeozoGtCbjKy4OEqwS/qyrRji5GPxT+r39A NoQA== 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=o0ksi5511coOPhn6UNViAskski+Jzkd9Cb54z0HJwJg=; b=jVGJqvG6rMHv/V9qDr+iul9wJVBMeuuJbNHqxk13n7qN7xuaXhzh6rEhiKAjazGUc+ /BtLy8h94Nwl9xkN7UMRSGxgeK/VCgtb7SVOo3cFGoi8a4kjoF4IMvgVZtxVhiZwrV+c avIbTlNyky5mWVK39IEk8cQ0r9BiRRCg77zMwdDEJXw8EIxOHiK6feijgDKOfZ7PCvet RwfUFVSmGOvI4JA6Qb+g62IMO+0uPJYfYiyMr3AyjsQZKJzjQ+gYUGciv9E52hl2rx46 7z11ViZ54GTL6ftV4JfpSjz7mH6+pSnQ/DGQl8lT/qvwkUKuEgczuXg5Ep559ZyeB13M g5BQ== X-Gm-Message-State: ALoCoQmEY0sRE5/VjjDstL9kcUQCVqFgUtZ27crKztSBnQ0pAxJ5/k/sNQ9P9qZU4r9aYkZCowlkXG9HL2uJMZ3AqGbQDgGNKw== X-Received: by 10.50.73.1 with SMTP id h1mr6191467igv.88.1450481057857; Fri, 18 Dec 2015 15:24:17 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id q74sm7408147ioe.42.2015.12.18.15.24.16 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 15:24:16 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id jw2so2372634igc.1 for ; Fri, 18 Dec 2015 15:24:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.62.178 with SMTP id z18mr6192683igr.2.1450481056062; Fri, 18 Dec 2015 15:24:16 -0800 (PST) Received: by 10.36.105.15 with HTTP; Fri, 18 Dec 2015 15:24:15 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 18:24:15 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7bd760c219a5320527347058 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 23:24:22 -0000 --047d7bd760c219a5320527347058 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 5:22 PM, Ted Hardie wrote: > > =E2=80=8BSorry that this was not clear; I meant specifically A-D.=E2=80= =8B > > Offer/answer telephone event negotiation is normally by directional. This >> normally enabled DTMF detection in PSTN gateways. So, if you have any >> system that connects WebRTC client to PSTN network, and if the person on >> PSTN network will press a keypad digit, this digit will be sent to WebRT= C >> client. Furthermore, it is common for DTMF digit detection to be caused = by >> talk off, i.e. some voice periodically triggers DTMF detection. Finally, >> some gateways will also send ANS tones if the call hits a fax machine, s= o >> WebRTC end point will get not only DTMF events, but events for tone that >> someone just happened to enable on the gateway. Unless we want to transc= ode >> media coming from PSTN, WebRTC client will need to deal with any incomin= g >> telephone-events. All of this being said, it is up to WebRTC client to >> decide what to do with the received events. I am fine with these tones >> being discard as long as they are being discarded in a manner which does >> not disrupt normal audio processing. >> > > =E2=80=8BThis seems to result in exactly the case Cullen was concerned ab= out; if > they may be discarded their functionality remains completely unreliable.= =E2=80=8B > But more to the point, you are not pointing to uses of A-D, but number > detection and events which would still be covered. > This is completely unrelated. This applies to all DTMF tones, not A-D specifically. What I am saying is that WebRTC endpoints must be able to generate all DTMF tones including A-D and send them to legacy PSTN (gateway). Legacy PSTN will receive and handle them. If legacy PSTN (gateway) sends DTMF tones to WebRTC end point (and it will, even though they are not expected there), WebRTC endpoint can discard them, as long as it does it nicely. > =E2=80=8BWhile this is no doubt not your intent, I must say your message = reads as >> "Sure it's broken now, but we must make sure it remains broken to be >> backwards compatible."=E2=80=8B >> > My intent is that there is an existing well understood functionality set with its benefits (wide support) and faults (unreliability). This functionality set is called DTMF. Why WebRTC needs to redefine this set is beyond my understanding. > =E2=80=8BThe only A-D tone in the one example you gave (echolink) was to = pull up a > different stored configuration. > So, one out of four tones is used in this example. DTMF tone A-D are used to provide prioritized call handling service in ITU >>>> Q.955.3 specification which is still used by some PBX and phone system= s. >>>> >>>> >>> =E2=80=8BAgain, not at all clear that a WebRTC client would ever expect= to use >>> these features of a PBX. >>> >> >> There are intranet WebRTC applications that access in-company legacy PBX >> via a private gateway. >> > > =E2=80=8BAnd they are using the A-D set? > Yes, they are using A-D set to provide priority dialing. > Finally, some calling card like systems allow remote control of functions >>>> such as flash by mapping them to extended DTMF tones. >>>> >>>> >>> =E2=80=8BIf there is a calling card system using WebRTC, I have not hea= rd of >>> it. Can you provide a pointer?=E2=80=8B >>> >> >> Once again, this would be a private WebRTC application used to place >> calls through a gateway which is under control of the person who develop= er >> the app. >> >> > =E2=80=8BSo this is theoretical.=E2=80=8B > This is real with existing SIP interface being replaced by WebRTC. > =E2=80=8BRemoving them from the set does as well, at least as far as I ca= n tell. > No one has suggested that they be the subject of discovery or negotiation= .=E2=80=8B > And then they will be added back by some vendor who got a critical customer who is using these tones for something. Despite many words exchanged, I think our entire argument can be boiled down to "let's remove these tones since they sometimes do not work and they are ugly" vs "let's keep these tones since they are sometimes used and do work on occasion." P.S. I have proposed several other things in addition to tones A-D. Are there any comments regarding adding the following: Generated events MUST have duration of no more than 6000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms. Event SHOULD start on a regular audio packet border. Event and gap duration SHOULD be rounded up to the next regular audio packet border. During the time events are generated audio SHOULD NOT be sent for the same audio stream. When gaps between events are generated, silence and not the background audio SHOULD be sent using regular audio encoding. If multiple audio sampling rates are supported, audio/telephone-event payload SHOULD be present for each supported sampling rate. Endpoints SHOULD use audio/telephone-event format parameters during the offer/answer exchange to indicate which events are supported. Receivers MUST be able to consume any audio/telephone-event events in such a way that it will not generate audio artifacts, unexpected packet loss concealment, jitter buffer adjustments, payload mismatches, or invalid RTCP statistics calculation. Receivers MAY generate audio corresponding to the received events but are also allowed to discard them in a manner that does not affect regular audio processing. _____________ Roman Shpount --047d7bd760c219a5320527347058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2015 at 5:22 PM, Ted Hardie <ted.ietf@gmail.com&= gt; wrote:

<= div style=3D"font-family:tahoma,sans-serif;font-size:small">=E2=80=8BSorry = that this was not clear; I meant specifically A-D.=E2=80=8B

=
Offer/answer telephone event negotiation= is normally by directional. This normally enabled DTMF detection in PSTN g= ateways. So, if you have any system that connects WebRTC client to PSTN net= work, and if the person on PSTN network will press a keypad digit, this dig= it will be sent to WebRTC client. Furthermore, it is common for DTMF digit = detection to be caused by talk off, i.e. some voice periodically triggers D= TMF detection. Finally, some gateways will also send ANS tones if the call = hits a fax machine, so WebRTC end point will get not only DTMF events, but = events for tone that someone just happened to enable on the gateway. Unless= we want to transcode media coming from PSTN, WebRTC client will need to de= al with any incoming telephone-events. All of this being said, it is up to = WebRTC client to decide what to do with the received events. I am fine with= these tones being discard as long as they are being discarded in a manner = which does not disrupt normal audio processing.

=E2=80=8BThis seems to result in exactly the case Cullen was co= ncerned about; if they may be discarded their functionality remains complet= ely unreliable.=E2=80=8B=C2=A0 But more to the point, you are not pointing = to uses of A-D, but number detection and events which would still be covere= d.

This i= s completely unrelated. This applies to all DTMF tones, not A-D specificall= y. What I am saying is that WebRTC endpoints must be able to generate all D= TMF tones including A-D and send them to legacy PSTN (gateway). Legacy PSTN= will receive and handle them. If legacy PSTN (gateway) sends DTMF tones to= WebRTC end point (and it will, even though they are not expected there), W= ebRTC endpoint can discard them, as long as it does it nicely.
=C2=A0
=
=E2=80=8BWhile this is no do= ubt not your intent, I must say your message reads as "Sure it's b= roken now, but we must make sure it remains broken to be backwards compatib= le."=E2=80=8B
=

My intent is that there is an = existing well understood functionality set with its benefits (wide support)= and faults (unreliability). This functionality set is called DTMF. Why Web= RTC needs to redefine this set is beyond my understanding.=C2=A0
= =C2=A0
=E2=80=8BThe only A-D tone in the one example you gave (echolink) was to p= ull up a different stored configuration.

So, one out of four tones is used in this exam= ple.=C2=A0

<= span>
DTMF tone A-D are used to provide prio= ritized call handling service in ITU Q.955.3 specification which is still u= sed by some PBX and phone systems.


=E2=80=8BAgain, not at all clear that a WebRTC= client would ever expect to use these features of a PBX.
=

There are intranet WebR= TC applications that access in-company legacy PBX via a private gateway.

=E2=80=8BAnd they are us= ing the A-D set?

Yes, they are using A-D set to provide priority dialing.
= =C2=A0
<= span>
Finally, some calling card like systems allow remote= control of functions such as flash by mapping them to extended DTMF tones.=


=E2=80=8BIf there is = a calling card system using WebRTC, I have not heard of it.=C2=A0 Can you p= rovide a pointer?=E2=80=8B
<= br>
Once again, this would be a private WebRTC application= used to place calls through a gateway which is under control of the person= who developer the app.

=

=E2=80=8BSo this is theoretical.=E2=80=8B
<= /div>

This is real with existing SIP = interface being replaced by WebRTC.
=C2=A0
=
=E2=80=8BRemoving them from = the set does as well, at least as far as I can tell.=C2=A0 No one has sugge= sted that they be the subject of discovery or negotiation.=E2=80=8B<= br>

And then they will be added back by some vendor who got a critical = customer who is using these tones for something.

Despite many words exchanged, I = think our entire argument can be boiled down to "let's remove thes= e tones since they sometimes do not work and they are ugly" vs "l= et's keep these tones since they are sometimes used and do work on occa= sion."

P.S. I have proposed several other things in addition to tones A-D. A= re there any comments regarding adding the following:

Generated events MUST have duration of no more than 60= 00 ms and no less=C2=A0than 40 ms with the recommended default duration of = 100 ms for each tone. The gap between events MUST be no less then 30 ms wit= h the recommended=C2=A0default duration of 70 ms. Event SHOULD start on a r= egular audio packet=C2=A0border. Event and gap duration SHOULD be rounded u= p to the next regular=C2=A0audio packet border.

During the time even= ts are generated audio SHOULD NOT be sent for the same=C2=A0audio stream. W= hen gaps between events are generated, silence=C2=A0and not the background = audio SHOULD be sent using regular audio encoding.

If multiple audio= sampling rates are supported, audio/telephone-event payload=C2=A0SHOULD be= present for each supported sampling rate. Endpoints SHOULD use=C2=A0audio/= telephone-event format parameters during the offer/answer exchange to indic= ate which events are supported.

Receivers MUST be able to consume an= y audio/telephone-event events=C2=A0in such a way that it will not generate= audio artifacts, unexpected packet loss concealment, jitter buffer adjustm= ents, payload mismatches,=C2=A0or invalid RTCP statistics calculation. Rece= ivers MAY generate audio=C2=A0corresponding to the received events but are = also allowed to discard=C2=A0them in a manner that does not affect regular = audio processing.
_____________
Roman Shpount

--047d7bd760c219a5320527347058-- From nobody Fri Dec 18 16:01:49 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B241A00CD for ; Fri, 18 Dec 2015 16:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyulNkBdDxy5 for ; Fri, 18 Dec 2015 16:01:47 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0EC1A00CA for ; Fri, 18 Dec 2015 16:01:47 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id 140so76650541ykp.0 for ; Fri, 18 Dec 2015 16:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Enyhcf1EMJgm9LBqpyD7v23gltbe7tl+Tf3ab+7Koo=; b=UYU+3xjVBLw7ZO2TZZVtwqeRvtIST8NIzmlhG0ATuXZ3mNP6MOytAXzrje4juGIvxU 02OvCk/bo3vD3bIltdy2SzH5PJYD9JHfqpFGQYJsctHbXzZQuqVMKdcz5B7PKBwnNZZm DmCT00CG1L+3pjZPm93i07qTKZbicNSasA0hnH6rcvdpOlwXD91/p+b+BIIoDRwVE9C9 5d7RlJOlC2fjyuxtc6+UdUVUlnd+XGaq8gIQTlPHjMImcxaY7GvBnld1fq035WarBua9 QGG5t20BK+10k2jwfEnuGcva7E0kO5VPQGSAwlkA1BqtC9o33ULDKePRGFyOuWqy5Y1w MbJg== X-Received: by 10.129.117.84 with SMTP id q81mr5417184ywc.190.1450483307039; Fri, 18 Dec 2015 16:01:47 -0800 (PST) Received: from [10.0.1.2] (c-73-49-202-70.hsd1.fl.comcast.net. [73.49.202.70]) by smtp.gmail.com with ESMTPSA id i125sm18438941ywi.28.2015.12.18.16.01.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 16:01:45 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-442E72A8-0D2C-435B-9263-003708CE35BE Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13C75) In-Reply-To: Date: Fri, 18 Dec 2015 19:01:43 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4A049C42-6DBC-4C70-A704-8ECDB1CBA719@gmail.com> References: <5674797A.9020102@nostrum.com> To: Roman Shpount Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 00:01:49 -0000 --Apple-Mail-442E72A8-0D2C-435B-9263-003708CE35BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Dec 18, 2015, at 16:47, Roman Shpount wrote: >=20 > I was reminded multiple times that here is the right forum to discuss this= issue. I am mostly looking for a consensus made here and then propagated to= W3C. [BA] Right. However, unless we are prepared to outlaw tones A-D in the audio= document (which I would not suggest), the situation will remain much as it i= s now - the W3C API will need to accommodate implementations that can send t= hose tones.= --Apple-Mail-442E72A8-0D2C-435B-9263-003708CE35BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On Dec 18, 2015, at 16:47, Roman Shpount <roman@telurix.com> wrote:


I was reminded multiple times that here is the right forum to discuss this issue. I am mostly looking for a consensus made here and then propagated to W3C.

[BA] Right. However, unless we are prepared to outlaw tones A-D in the audio document (which I would not suggest), the situation will remain much as it is now - the W3C API will need to accommodate implementations that can send those tones.
--Apple-Mail-442E72A8-0D2C-435B-9263-003708CE35BE-- From nobody Fri Dec 18 16:10:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AF41A00ED for ; Fri, 18 Dec 2015 16:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhStV7LZI_rY for ; Fri, 18 Dec 2015 16:10:38 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4101A00EA for ; Fri, 18 Dec 2015 16:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2818; q=dns/txt; s=iport; t=1450483837; x=1451693437; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XTHwXZzD5FNQZgg8xlyIugOu0PZSD7g3jgJ9h/bng7g=; b=XYfxeuCxPN2vrRXKGKYAnaEweppPqeXp5pcJWONCTvwnPzHT79GNe9lF lRTnkZ+iAbELae+dAx7J+AvCmSKtCbjDfdmGMp5SUZhSUbTykFBugtevo vOyO2KUBYbmGrqTaVszptFqmTNrdNT3JiaXZqy03r4ECm56ixtpvtahfe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBtn3RW/5NdJa1egm5MgT8GvVcBD?= =?us-ascii?q?YFjhg0CHIEZOBQBAQEBAQEBgQqENQEBBB0GVhACAQgEAToDAgICMBQRAgQOBYg?= =?us-ascii?q?vq3ySAwEBAQEBAQEBAQEBAQEBAQEBAQEBARiIZYJvh3cvgRoFln8BjUmdKAEgA?= =?us-ascii?q?QFChARyhBGBCAEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,448,1444694400"; d="scan'208,217"; a="55047709" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2015 00:10:37 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tBJ0Aa6x030405 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 19 Dec 2015 00:10:37 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Dec 2015 19:10:36 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Fri, 18 Dec 2015 19:10:36 -0500 From: "Cullen Jennings (fluffy)" To: Roman Shpount Thread-Topic: [rtcweb] Working group last call for draft-ietf-rtcweb-audio Thread-Index: AQHROb/f1JspZ+M0ik+ShWOkxZul4p7RZUcAgAARSQCAABq6gIAACYYAgAAHU4CAAANBAIAAEVmAgAAM8oA= Date: Sat, 19 Dec 2015 00:10:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.64.117] Content-Type: multipart/alternative; boundary="_000_F9264ABCE85644B49E7E8359B5D39A55ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 00:10:39 -0000 --_000_F9264ABCE85644B49E7E8359B5D39A55ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBEZWMgMTgsIDIwMTUsIGF0IDM6MjQgUE0sIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVy aXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpUaGlzIGFwcGxpZXMg dG8gYWxsIERUTUYgdG9uZXMsIG5vdCBBLUQgc3BlY2lmaWNhbGx5LiBXaGF0IEkgYW0gc2F5aW5n IGlzIHRoYXQgV2ViUlRDIGVuZHBvaW50cyBtdXN0IGJlIGFibGUgdG8gZ2VuZXJhdGUgYWxsIERU TUYgdG9uZXMgaW5jbHVkaW5nIEEtRCBhbmQgc2VuZCB0aGVtIHRvIGxlZ2FjeSBQU1ROIChnYXRl d2F5KS4NCg0KVGhlIHRoaW5nIHBlb3BsZSBrZWVwIGFza2luZyBpcyB3aHk/IHdoYXQgaXMgdGhl IHVzZSBjYXNlID8NCg0KSSBkb27igJl0IGZlZWwgbGlrZSBJIGhhdmUgc2VlbiBhbiBhbnN3ZXIg dG8gdGhpcy4NCg0KDQo= --_000_F9264ABCE85644B49E7E8359B5D39A55ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMg MTgsIDIwMTUsIGF0IDM6MjQgUE0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpy b21hbkB0ZWx1cml4LmNvbSIgY2xhc3M9IiI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsg ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGlzDQogYXBwbGllcyB0byBh bGwgRFRNRiB0b25lcywgbm90IEEtRCBzcGVjaWZpY2FsbHkuIFdoYXQgSSBhbSBzYXlpbmcgaXMg dGhhdCBXZWJSVEMgZW5kcG9pbnRzIG11c3QgYmUgYWJsZSB0byBnZW5lcmF0ZSBhbGwgRFRNRiB0 b25lcyBpbmNsdWRpbmcgQS1EIGFuZCBzZW5kIHRoZW0gdG8gbGVnYWN5IFBTVE4gKGdhdGV3YXkp Ljwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5UaGUgdGhpbmcgcGVvcGxlIGtlZXAgYXNraW5nIGlzIHdoeT8gd2hhdCBpcyB0 aGUgdXNlIGNhc2UgPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SSBkb27igJl0IGZlZWwgbGlrZSBJIGhhdmUgc2VlbiBhbiBhbnN3ZXIg dG8gdGhpcy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F9264ABCE85644B49E7E8359B5D39A55ciscocom_-- From nobody Fri Dec 18 16:24:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25EA1A0110 for ; Fri, 18 Dec 2015 16:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w8zW3MuHNtX for ; Fri, 18 Dec 2015 16:24:18 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964631A0114 for ; Fri, 18 Dec 2015 16:24:18 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id p130so77141873yka.1 for ; Fri, 18 Dec 2015 16:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LI/DNBiBilyGdh4btfpOWLGmDIeM8eLzhpaiYLpDGik=; b=chPWnw4FkBMXLNiSeG/hTsYxk1SW9aS5Gi9MMf+q+Zq0fTveN/OPJZYvw3B8ZIM270 QNboARmCrT/FzDwAH7V2Yjy9bSCac139eQUdiLpq0vlBicRfndEqXc9/RJngfKnd01RU XtJZ9qSYJn9MwueAMc6bXPuwRg8AxZsR4ifCpi1MimH56MtgDHBnWO+9eePy8c3UHFbR a/HSNEotXKRfnTM8tSXTa5EKFsnrLkn0AM1sP97fCy4NHdSq2CHZoj6aw/XXnXv8JGJn Ug6HHg7encVf7tykCY5di+EtOUJx5yGDz/Yhaajqfb41kzac+VhcYmI2eaI7qQuhbSvh +Dpw== X-Received: by 10.13.253.7 with SMTP id n7mr5447843ywf.74.1450484657887; Fri, 18 Dec 2015 16:24:17 -0800 (PST) Received: from [10.0.1.2] (c-73-49-202-70.hsd1.fl.comcast.net. [73.49.202.70]) by smtp.gmail.com with ESMTPSA id c67sm18530621ywe.31.2015.12.18.16.24.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 16:24:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13C75) In-Reply-To: <56747874.2050508@nostrum.com> Date: Fri, 18 Dec 2015 19:24:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <64791609-0D32-4202-AAC1-4CBD053FD0A3@gmail.com> References: <56747874.2050508@nostrum.com> To: Adam Roach Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 00:24:21 -0000 On Dec 18, 2015, at 16:19, Adam Roach wrote: >=20 > I'm a little confused about where this leaves the state of play. You're pr= oposing the the W3C spec leave it open as to whether sending an "A" through t= he API will work or throw an exception?=20 [BA] Today this depends on whether an implementation supports sending "A" or= not. As long as the audio document does not prohibit or mandate support for= A-D, there may be some implementations that will recognize A-D and others t= hat won't. The W3C API leaves it open to accommodate the options provided by= the audio document. =20 In the absence of a prohibition or requirement to support A-D, the best we c= an do is make it possible in the API for the application to discover what to= nes are supported, so it can adjust. RFC 4733 describes SDP that provides th= at information, and similar capabilities have been discussed in ORTC (though= they are not currently in the spec since all existing implementations suppo= rt the full range of tones).=20= From nobody Fri Dec 18 16:53:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A131A0181 for ; Fri, 18 Dec 2015 16:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwHGV1nIp4CR for ; Fri, 18 Dec 2015 16:53:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41021A0180 for ; Fri, 18 Dec 2015 16:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1630; q=dns/txt; s=iport; t=1450486418; x=1451696018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CL/K4e4Z839AEfYYKR5r6PTStypDyUFhkmd70seHADs=; b=SskSe0WVzwvpxADaBvX2TraJ3726bDhCT0CSIMKn0PdRmfpn7u95FYdS 3wdf368MFYZWBxVRWqL/eA6Kxc3uGMsjpL9Y4/qykpFgzunn2s8sfSIau llKqwI+k49F5qXxJ0gJWgkq+7AvE6IBuciWr+CW76uGAbZUo1KNyJtuFH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgCQqXRW/4oNJK1egzqBPwa9VwENg?= =?us-ascii?q?WOGDQIcgRk4FAEBAQEBAQGBCoQ0AQEBAwEdBhFFBQsCAQgYAgImAgICHxEVEAI?= =?us-ascii?q?EDgWIGgMKCKt4jWANhBcBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgQGHZIJvglOFJ?= =?us-ascii?q?C+BGgEEln8Bi1GBeJVOh1oBIAEBQoQEcoQRgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,448,1444694400"; d="scan'208";a="56856809" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2015 00:53:38 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tBJ0rbXg014112 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 19 Dec 2015 00:53:38 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Dec 2015 19:53:37 -0500 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Fri, 18 Dec 2015 19:53:36 -0500 From: "Cullen Jennings (fluffy)" To: Bernard Aboba Thread-Topic: [rtcweb] Working group last call for draft-ietf-rtcweb-audio Thread-Index: AQHROb/f1JspZ+M0ik+ShWOkxZul4p7RfCcAgAAX0ACAADOJgIAACDMA Date: Sat, 19 Dec 2015 00:53:36 +0000 Message-ID: References: <56747874.2050508@nostrum.com> <64791609-0D32-4202-AAC1-4CBD053FD0A3@gmail.com> In-Reply-To: <64791609-0D32-4202-AAC1-4CBD053FD0A3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.64.117] Content-Type: text/plain; charset="utf-8" Content-ID: <103F5EB97EEC3845843CF6AE61602B99@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 00:53:40 -0000 DQpJ4oCZbSBhc3N1bWluZyB3ZSB3aWxsIGJyaW5nIHRoZSBXM0Mgc3BlY3MgaW4gbGluZSB3aXRo IHdoYXRldmVyIHdlIGRlY2lkZSBoZXJlLg0KDQoNCj4gT24gRGVjIDE4LCAyMDE1LCBhdCA0OjI0 IFBNLCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0K PiBPbiBEZWMgMTgsIDIwMTUsIGF0IDE2OjE5LCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29t PiB3cm90ZToNCj4+IA0KPj4gSSdtIGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0IHdoZXJlIHRoaXMg bGVhdmVzIHRoZSBzdGF0ZSBvZiBwbGF5LiBZb3UncmUgcHJvcG9zaW5nIHRoZSB0aGUgVzNDIHNw ZWMgbGVhdmUgaXQgb3BlbiBhcyB0byB3aGV0aGVyIHNlbmRpbmcgYW4gIkEiIHRocm91Z2ggdGhl IEFQSSB3aWxsIHdvcmsgb3IgdGhyb3cgYW4gZXhjZXB0aW9uPyANCj4gDQo+IFtCQV0gVG9kYXkg dGhpcyBkZXBlbmRzIG9uIHdoZXRoZXIgYW4gaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgc2VuZGlu ZyAiQSIgb3Igbm90LiBBcyBsb25nIGFzIHRoZSBhdWRpbyBkb2N1bWVudCBkb2VzIG5vdCBwcm9o aWJpdCBvciBtYW5kYXRlIHN1cHBvcnQgZm9yIEEtRCwgdGhlcmUgbWF5IGJlIHNvbWUgaW1wbGVt ZW50YXRpb25zIHRoYXQgd2lsbCByZWNvZ25pemUgQS1EIGFuZCBvdGhlcnMgdGhhdCB3b24ndC4g VGhlIFczQyBBUEkgbGVhdmVzIGl0IG9wZW4gdG8gYWNjb21tb2RhdGUgdGhlIG9wdGlvbnMgcHJv dmlkZWQgYnkgdGhlIGF1ZGlvIGRvY3VtZW50LiAgDQo+IA0KPiBJbiB0aGUgYWJzZW5jZSBvZiBh IHByb2hpYml0aW9uIG9yIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQgQS1ELCB0aGUgYmVzdCB3ZSBj YW4gZG8gaXMgbWFrZSBpdCBwb3NzaWJsZSBpbiB0aGUgQVBJIGZvciB0aGUgYXBwbGljYXRpb24g dG8gZGlzY292ZXIgd2hhdCB0b25lcyBhcmUgc3VwcG9ydGVkLCBzbyBpdCBjYW4gYWRqdXN0LiBS RkMgNDczMyBkZXNjcmliZXMgU0RQIHRoYXQgcHJvdmlkZXMgdGhhdCBpbmZvcm1hdGlvbiwgYW5k IHNpbWlsYXIgY2FwYWJpbGl0aWVzIGhhdmUgYmVlbiBkaXNjdXNzZWQgaW4gT1JUQyAodGhvdWdo IHRoZXkgYXJlIG5vdCBjdXJyZW50bHkgaW4gdGhlIHNwZWMgc2luY2UgYWxsIGV4aXN0aW5nIGlt cGxlbWVudGF0aW9ucyBzdXBwb3J0IHRoZSBmdWxsIHJhbmdlIG9mIHRvbmVzKS4NCg0K From nobody Fri Dec 18 17:12:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707161A024E for ; Fri, 18 Dec 2015 17:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe7xohnbeivF for ; Fri, 18 Dec 2015 17:12:24 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F358C1A0250 for ; Fri, 18 Dec 2015 17:12:23 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id m11so3264892igk.1 for ; Fri, 18 Dec 2015 17:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7s/pW/T02qBoRkoIvmolk3HZsQk5TBl3Pj54fkYVf+E=; b=Ru8wN4qVSb/BSGWIF4I7hVrxqBU/AVIZxnvpI0s7PJkR2ons7F9r4oy1Z4bHWb0Iqj ul+lcNeG+HzWoTfRkWPdYaYkLJWwUpvb4HEOuvgIGAYJEqRcB7HOm6IkEhpb1JTHoDdO kWZJc1rxFB5rjArur3qgJQuhh9WhYR30dZC3MFABL6KC3D8bwFzGVZo5263p3djjZo2F +AbIii/vbBTRcwpkso/DSs9OLqNJ1TbbRMNb7PEAez8HdypeivbJHn+lVgg9QFPaDVkQ RaPaNfYiEa1HffI/U0hlohAT2Mo4h/ooEabfNWeiUWEzgT1a1EMxN+WQc0vRlvUuleUx NgaQ== 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=7s/pW/T02qBoRkoIvmolk3HZsQk5TBl3Pj54fkYVf+E=; b=V3zmhNh325Qs6s4fcA0p9W/lAY7hvNMeqIheUMP841aJ7dHXwPPf6hTtQfdKfvXgpp 7HNuQv1xkPwb0F8T/ZICusc8oNrWW6A4BIt6zQ1cNHsARO7VGDgLOr658iWs8x1nTitP X9mtbyM1FdXugtfEtnHM/jZ3Q7dFPSoZGRFCekOkesKemWR7VIGlGYxhZomZsV2WHTRZ qbQHJbvPem3h+vfYzIYwYpu5uQmsjqke/8Iu2VV2Ss3mADUyZk/ZaVgi+GOwx2tYOFYp 9REAhP7l0yQEQ774eXXefXHR/9j5IMELhJF01pdNhebTyBIqmzohZ4gcfxbA+SfwNdZP Qpww== X-Gm-Message-State: ALoCoQmOTKYmU3JbcYCgBbjQIa4fGZtXXN9NmJDNeV5+8E6n7WSO0sDZHctsW9nThQ6ZhOjFqDtiOKA3WYoiMtXAbcMQ3Wi99w== X-Received: by 10.50.73.199 with SMTP id n7mr6218854igv.1.1450487543434; Fri, 18 Dec 2015 17:12:23 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id n14sm3652797igx.17.2015.12.18.17.12.21 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Dec 2015 17:12:22 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id jw2so3522874igc.1 for ; Fri, 18 Dec 2015 17:12:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.126.35 with SMTP id mv3mr6615169igb.24.1450487541564; Fri, 18 Dec 2015 17:12:21 -0800 (PST) Received: by 10.36.105.15 with HTTP; Fri, 18 Dec 2015 17:12:21 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 20:12:21 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b1635d5aa9542052735f2d2 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 01:12:25 -0000 --047d7b1635d5aa9542052735f2d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) wrote: > > On Dec 18, 2015, at 3:24 PM, Roman Shpount wrote: > > This applies to all DTMF tones, not A-D specifically. What I am saying is > that WebRTC endpoints must be able to generate all DTMF tones including A= -D > and send them to legacy PSTN (gateway). > > > The thing people keep asking is why? what is the use case ? > > I don=E2=80=99t feel like I have seen an answer to this. > > Because there are IVR systems that use them. They are much less common then IVR systems that use 0-9 * and # but they do exist. I have provided 4 examples of real IVR systems that use these tones. How many do you need to keep the extra tones? All these systems can probably be re-engineered not to use A-D tones, but since this is all legacy no one will spend the time. Your argument that these tones should be removed since they are sometimes blocked (When exactly? The only places I see them blocked are some international carriers) and would not work. The same applies to all DTMF tones. We should remove all telephone-events based on this logic. Most importantly I do not want optional tones. So, if we decide to remove A-D, they should not be allowed in the WebRTC API. If these tones are allowed in WebRTC API, everyone must implement them. _____________ Roman Shpount --047d7b1635d5aa9542052735f2d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) <fluffy@cisc= o.com> wrote:

On Dec 18, 2015, at 3:24 PM, Roman Shpount <roman@telurix.com> wrote:

This applies to all DTMF tones, not A-D specifically. What I am saying is that = WebRTC endpoints must be able to generate all DTMF tones including A-D and = send them to legacy PSTN (gateway).

The thing people keep asking is why? what is the use case ?

I don=E2=80=99t feel like I have seen an answer to this.=C2=A0


Because there are IVR= systems that use them. They are much less common then IVR systems that use= 0-9 * and # but they do exist. I have provided 4 examples of real IVR syst= ems that use these tones. How many do you need to keep the extra tones? All= these systems can probably be re-engineered not to use A-D tones, but sinc= e this is all legacy no one will spend the time.=C2=A0

=
Your argument that these tones should be removed since they are someti= mes blocked (When exactly? The only places I see them blocked are some inte= rnational carriers) and would not work. The same applies to all DTMF tones.= We should remove all telephone-events based on this logic.

<= /div>
Most importantly I do not want optional tones. So, if we decide t= o remove A-D, they should not be allowed in the WebRTC API. If these tones = are allowed in WebRTC API, everyone must implement them.
_____________
Roman Shpount
=C2= =A0
--047d7b1635d5aa9542052735f2d2-- From nobody Fri Dec 18 17:26:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D705F1A0369 for ; Fri, 18 Dec 2015 17:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huQxo-bWlQlP for ; Fri, 18 Dec 2015 17:26:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0511A036A for ; Fri, 18 Dec 2015 17:26:30 -0800 (PST) Received: from [172.17.0.14] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBJ1QPal072903 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Dec 2015 19:26:28 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be [172.17.0.14] References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13C75) From: Adam Roach Date: Fri, 18 Dec 2015 19:26:25 -0600 To: Roman Shpount Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 01:26:32 -0000 +1=20 Actually, plus however many I have left in my account. This is the crux of t= he matter, IMO.=20 /a > On Dec 18, 2015, at 19:12, Roman Shpount wrote: >=20 > Most importantly I do not want optional tones. So, if we decide to remove A= -D, they should not be allowed in the WebRTC API. If these tones are allowed= in WebRTC API, everyone must implement them. > _____________ From nobody Fri Dec 18 17:43:39 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD381A038A for ; Fri, 18 Dec 2015 17:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95Fcl01l_vOL for ; Fri, 18 Dec 2015 17:43:35 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353BB1A0382 for ; Fri, 18 Dec 2015 17:43:35 -0800 (PST) Received: by mail-pa0-x229.google.com with SMTP id q3so48423764pav.3 for ; Fri, 18 Dec 2015 17:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cmH9QeWON6MOPa3Ca+gTBpUCfMM+N9IDikrvK+yOUMw=; b=ijfBKzX62Z+5bMNN6hCVv/GniRAi72U7zDKhVMKNekahWdIFYWfrsfrm0jYGFoIOz7 QN40Hrq6aSROMeDegm4MDGlwGhS+HDix1725eUTrpq8psYPmCEvdCPdR9uLSAfKEHOTE MqtKXLFcGq5rsfba/t/LasePkkOUgPotNsQZ1pE8sicIS7WCi1oicDEzo3WuxX84zGDa CmY0ixTZ+t7M9CtrPpu99/tLQrPPtDpkPK5ghwseXrHmV3wwbo0UdMLvTKKKLm2idm39 vehcfZJDnGfy9Y1yFH+L1aVQnEI+vln019nbOu0gjqvSeYE9cpqHarnuAReRXclCO8Qb OmTw== X-Received: by 10.66.148.99 with SMTP id tr3mr9883848pab.19.1450489414748; Fri, 18 Dec 2015 17:43:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.190.232 with HTTP; Fri, 18 Dec 2015 17:43:15 -0800 (PST) In-Reply-To: References: From: Barry Dingle Date: Sat, 19 Dec 2015 12:43:15 +1100 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7b6d9fb6510e74052736623f Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 01:43:37 -0000 --047d7b6d9fb6510e74052736623f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 The Use Case is "IVR systems that support RFC 4733". It is irrelevant that some systems may not support 'A-D'. Barry Dingle Fixed - 03-9725-3937 Mob - 041-911-7578 Fellow of University of Melbourne, Australia On Sat, Dec 19, 2015 at 12:12 PM, Roman Shpount wrote: > On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > >> >> On Dec 18, 2015, at 3:24 PM, Roman Shpount wrote: >> >> This applies to all DTMF tones, not A-D specifically. What I am saying i= s >> that WebRTC endpoints must be able to generate all DTMF tones including = A-D >> and send them to legacy PSTN (gateway). >> >> >> The thing people keep asking is why? what is the use case ? >> >> I don=E2=80=99t feel like I have seen an answer to this. >> >> > Because there are IVR systems that use them. They are much less common > then IVR systems that use 0-9 * and # but they do exist. I have provided = 4 > examples of real IVR systems that use these tones. How many do you need t= o > keep the extra tones? All these systems can probably be re-engineered not > to use A-D tones, but since this is all legacy no one will spend the time= . > > Your argument that these tones should be removed since they are sometimes > blocked (When exactly? The only places I see them blocked are some > international carriers) and would not work. The same applies to all DTMF > tones. We should remove all telephone-events based on this logic. > > Most importantly I do not want optional tones. So, if we decide to remove > A-D, they should not be allowed in the WebRTC API. If these tones are > allowed in WebRTC API, everyone must implement them. > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b6d9fb6510e74052736623f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

The Use Case is "IVR system= s that support RFC 4733".

It is irrelevant that some syst= ems may not support 'A-D'.=C2=A0

Barry Dingle
Fixed - 03-9725-3937=C2=A0 =C2=A0 Mob - = 041-911-7578=C2=A0=C2=A0
Fellow of University of Melbourne, Australia <= br>

On Sat, Dec 19, 2015 at 12:12 PM, Roman Shpo= unt <roman@telurix.com> wrote:
On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) <fluffy@c= isco.com> wrote:

On Dec 18, 2015, at 3:24 PM, Roman Shpount <roman@telurix.com> wrote:

This applies to all DTMF tones, not A-D specifically. What I am saying is that = WebRTC endpoints must be able to generate all DTMF tones including A-D and = send them to legacy PSTN (gateway).

The thing people keep asking is why? what is the use case ?

I don=E2=80=99t feel like I have seen an answer to this.=C2=A0


Because t= here are IVR systems that use them. They are much less common then IVR syst= ems that use 0-9 * and # but they do exist. I have provided 4 examples of r= eal IVR systems that use these tones. How many do you need to keep the extr= a tones? All these systems can probably be re-engineered not to use A-D ton= es, but since this is all legacy no one will spend the time.=C2=A0

Your argument that these tones should be removed since the= y are sometimes blocked (When exactly? The only places I see them blocked a= re some international carriers) and would not work. The same applies to all= DTMF tones. We should remove all telephone-events based on this logic.

Most importantly I do not want optional tones. So, if= we decide to remove A-D, they should not be allowed in the WebRTC API. If = these tones are allowed in WebRTC API, everyone must implement them.
<= div>
_____________
Ro= man Shpount
=C2=A0

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


--047d7b6d9fb6510e74052736623f-- From nobody Sat Dec 19 03:43:57 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6D81A889F for ; Sat, 19 Dec 2015 03:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmqEyGdebeil for ; Sat, 19 Dec 2015 03:43:55 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212081A889D for ; Sat, 19 Dec 2015 03:43:55 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id v6so86686827ykc.2 for ; Sat, 19 Dec 2015 03:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q2Xu+w2VsWRPAFvRXswTpEcj6ZAHzdQjFM8vjVtLaNI=; b=Jl8NQHJd+yLZgzFtxSbhVEVpaV5+rXoVR1Ek8bnSaFEMcyZkqcHZ5jSSR3+/DPFe+L jUznGij0zEdmqxrYv6MJB2lH59zA7u0fFXVAr6fHNKWeIsZGATPha2jGAJiZH5lY+J64 3YZGjNxr/gC29QqGNjVNEDUNN2okdI1QzHhoJYPtG6ydZ77/K2aiE4gyAmq1ckjouAdQ 4DetC6wqXqsyKgJkDZCcEcWyRG7Plkcq7KyH72cDe2JKcrIfYwAPh5Mt+mRdyWglsYA/ ByRHUe14LdQsHgILByEeBagHxftyuxEm2Xq/jLoO4ECFqvn5RrmOgdIABGIDqHEJQ/dV bFRA== X-Received: by 10.129.78.81 with SMTP id c78mr7152477ywb.248.1450525434437; Sat, 19 Dec 2015 03:43:54 -0800 (PST) Received: from [10.0.1.2] (c-73-49-202-70.hsd1.fl.comcast.net. [73.49.202.70]) by smtp.gmail.com with ESMTPSA id b186sm20783449ywc.50.2015.12.19.03.43.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Dec 2015 03:43:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13C75) In-Reply-To: Date: Sat, 19 Dec 2015 06:43:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Roman Shpount Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 11:43:56 -0000 On Dec 18, 2015, at 20:12, Roman Shpount wrote: >=20 > Because there are IVR systems that use them. They are much less common the= n IVR systems that use 0-9 * and # but they do exist. I have provided 4 exam= ples of real IVR systems that use these tones. How many do you need to keep t= he extra tones? All these systems can probably be re-engineered not to use A= -D tones, but since this is all legacy no one will spend the time.=20 >=20 > Your argument that these tones should be removed since they are sometimes b= locked (When exactly? The only places I see them blocked are some internatio= nal carriers) and would not work. The same applies to all DTMF tones. We sho= uld remove all telephone-events based on this logic. >=20 > Most importantly I do not want optional tones. So, if we decide to remove A= -D, they should not be allowed in the WebRTC API. If these tones are allowed= in WebRTC API, everyone must implement them. [BA] Bingo. To remove optional tones and discovery of tone capability, we ei= ther have to prohibit A-D or mandate that these tones be supported.=20= From nobody Sat Dec 19 06:12:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9971A89F9 for ; Sat, 19 Dec 2015 06:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGZqgm_4yiJb for ; Sat, 19 Dec 2015 06:12:19 -0800 (PST) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id DDCDF1A89F6 for ; Sat, 19 Dec 2015 06:12:19 -0800 (PST) Received: from [172.20.15.234] (unknown [201.229.38.3]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 91E75502755; Sat, 19 Dec 2015 06:12:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Matthew Kaufman X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Sat, 19 Dec 2015 10:12:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E00F6CA-B7F7-4D2E-BEA5-C9BEA392A48F@matthew.at> References: To: Bernard Aboba Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 14:12:21 -0000 Two-way radio system gateways would benefit from having these tones availabl= e. Matthew Kaufman (Sent from my iPhone) > On Dec 19, 2015, at 7:43 AM, Bernard Aboba wrote= : >=20 >> On Dec 18, 2015, at 20:12, Roman Shpount wrote: >>=20 >> Because there are IVR systems that use them. They are much less common th= en IVR systems that use 0-9 * and # but they do exist. I have provided 4 exa= mples of real IVR systems that use these tones. How many do you need to keep= the extra tones? All these systems can probably be re-engineered not to use= A-D tones, but since this is all legacy no one will spend the time.=20 >>=20 >> Your argument that these tones should be removed since they are sometimes= blocked (When exactly? The only places I see them blocked are some internat= ional carriers) and would not work. The same applies to all DTMF tones. We s= hould remove all telephone-events based on this logic. >>=20 >> Most importantly I do not want optional tones. So, if we decide to remove= A-D, they should not be allowed in the WebRTC API. If these tones are allow= ed in WebRTC API, everyone must implement them. >=20 > [BA] Bingo. To remove optional tones and discovery of tone capability, we e= ither have to prohibit A-D or mandate that these tones be supported.=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sat Dec 19 14:26:55 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AE31ACD87 for ; Sat, 19 Dec 2015 14:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNvQKhH8RavK for ; Sat, 19 Dec 2015 14:26:52 -0800 (PST) Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B6A1ACD7F for ; Sat, 19 Dec 2015 14:26:51 -0800 (PST) X-Halon-ID: a5d122cb-a69f-11e5-8d6c-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [83.209.226.9]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 19 Dec 2015 23:27:11 +0100 (CET) To: rtcweb@ietf.org References: <0E00F6CA-B7F7-4D2E-BEA5-C9BEA392A48F@matthew.at> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5675D99B.1080700@omnitor.se> Date: Sat, 19 Dec 2015 23:26:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <0E00F6CA-B7F7-4D2E-BEA5-C9BEA392A48F@matthew.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 22:26:54 -0000 There has been sufficient indications that A-D has applications. It would be odd to delete a small part of the RFC 4733 interoperability. In RFC 4733, all are optional, and can be specified in SDP. But if no fmtp is provided, then the whole set of DTMF tones shall be supported. This is part of what RFC 4733 says about sdp: If the "events" parameter is omitted, support for events 0-15 (the DTMF tones) is assumed. I suggest to stick to that and support the full set. /Gunnar Den 2015-12-19 kl. 15:12, skrev Matthew Kaufman: > Two-way radio system gateways would benefit from having these tones available. > > Matthew Kaufman > > (Sent from my iPhone) > >> On Dec 19, 2015, at 7:43 AM, Bernard Aboba wrote: >> >>> On Dec 18, 2015, at 20:12, Roman Shpount wrote: >>> >>> Because there are IVR systems that use them. They are much less common then IVR systems that use 0-9 * and # but they do exist. I have provided 4 examples of real IVR systems that use these tones. How many do you need to keep the extra tones? All these systems can probably be re-engineered not to use A-D tones, but since this is all legacy no one will spend the time. >>> >>> Your argument that these tones should be removed since they are sometimes blocked (When exactly? The only places I see them blocked are some international carriers) and would not work. The same applies to all DTMF tones. We should remove all telephone-events based on this logic. >>> >>> Most importantly I do not want optional tones. So, if we decide to remove A-D, they should not be allowed in the WebRTC API. If these tones are allowed in WebRTC API, everyone must implement them. >> [BA] Bingo. To remove optional tones and discovery of tone capability, we either have to prohibit A-D or mandate that these tones be supported. >> _______________________________________________ >> 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 -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sun Dec 20 03:54:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D531B2C9A for ; Sun, 20 Dec 2015 03:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T4z1sX3pkBc for ; Sun, 20 Dec 2015 03:54:11 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547FE1B2C98 for ; Sun, 20 Dec 2015 03:54:11 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5E78D5058967; Sun, 20 Dec 2015 11:54:06 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tBKBs7CE032689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Dec 2015 12:54:07 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 20 Dec 2015 12:54:07 +0100 From: "DRAGE, Keith (Keith)" To: Roman Shpount , Ted Hardie Thread-Topic: [rtcweb] Working group last call for draft-ietf-rtcweb-audio Thread-Index: AQHROb/m0JZd2tvJAUGJKJJIm+7DEZ7RALIAgAARSQCAABq6gIAACYUAgAAHVICAAANBAIAAEViAgAJyagA= Date: Sun, 20 Dec 2015 11:54:06 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE2686D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADE2686DFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 11:54:15 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADE2686DFR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHByaW9yaXR5LCBRLjk1NS4zIGRvZXMgbm90IHNwZWNpZnkgdGhlIHVzZSBvZiBhbnkga2V5 IHNlcXVlbmNlcyBmb3Igc3VwcG9ydCBvZiB0aGUgc2VydmljZS4gUS45NTUuMyBpcyB0aGUgSVNE TiBEU1MxIHNpZ25hbGxpbmcgc3BlY2lmaWNhdGlvbiBhbmQgZG9lcyBub3QgdXNlIERUTUYuIEZ1 cnRoZXIgaXQgaXMgYSBmdW5jdGlvbmFsIHNpZ25hbGluZyBzeXN0ZW0sIGkuZS4gYW55IGtleSBw cmVzc2VzIGFyZSBpZGVudGlmaWVkIGluIHRoZSB0ZXJtaW5hbCBhbmQgY29udmVydGVkIGludG8g cmVhbCBzaWduYWxzLCBzdWNoIGFzIOKAnGZsYXNoIG92ZXJyaWRl4oCdLg0KDQpJIGFzc3VtZSB5 b3UgYXJlIHJlZmVycmluZyB0byBzb21lIHByb3ByaWV0YXJ5IFBTVE4gZXF1aXZhbGVudC4NCg0K SeKAmWQgbm90ZSB0aGF0IHRoZSBQU1ROIGVxdWl2YWxlbnQgY29kZXMgb3JpZ2luYWxseSBzcGVj aWZpZWQgYnkgQ0VQVCBhbmQgcHJvdmlkZWQgaW4gYW4gRVRTSSBUUiBmb3Igb3RoZXIgc2Vydmlj ZXMgZG8gbm90IHVzZSBBIHRocm91Z2ggRCwgcGVyZm9ybWluZyBhbGwgc2VxdWVuY2Ugc2VwYXJh dG9ycyBhbmQgdGVybWluYXRpb25zIHdpdGgg4oCcKuKAnSBhbmQg4oCcI+KAnS4gVGhlcmUgaXMg bm90IGFuIEVUU0kgdmVyc2lvbiBvZiBNTFBQLg0KDQpSZWdhcmRzDQoNCktlaXRoIERyYWdlDQoN CkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUm9tYW4gU2hwb3VudA0KU2VudDogMTggRGVjZW1iZXIgMjAxNSAyMzoyNA0KVG86IFRlZCBI YXJkaWUNCkNjOiBDdWxsZW4gSmVubmluZ3M7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtydGN3ZWJdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXJ0Y3dlYi1h dWRpbw0KDQpPbiBGcmksIERlYyAxOCwgMjAxNSBhdCA1OjIyIFBNLCBUZWQgSGFyZGllIDx0ZWQu aWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQrigItT b3JyeSB0aGF0IHRoaXMgd2FzIG5vdCBjbGVhcjsgSSBtZWFudCBzcGVjaWZpY2FsbHkgQS1ELuKA iw0KDQpPZmZlci9hbnN3ZXIgdGVsZXBob25lIGV2ZW50IG5lZ290aWF0aW9uIGlzIG5vcm1hbGx5 IGJ5IGRpcmVjdGlvbmFsLiBUaGlzIG5vcm1hbGx5IGVuYWJsZWQgRFRNRiBkZXRlY3Rpb24gaW4g UFNUTiBnYXRld2F5cy4gU28sIGlmIHlvdSBoYXZlIGFueSBzeXN0ZW0gdGhhdCBjb25uZWN0cyBX ZWJSVEMgY2xpZW50IHRvIFBTVE4gbmV0d29yaywgYW5kIGlmIHRoZSBwZXJzb24gb24gUFNUTiBu ZXR3b3JrIHdpbGwgcHJlc3MgYSBrZXlwYWQgZGlnaXQsIHRoaXMgZGlnaXQgd2lsbCBiZSBzZW50 IHRvIFdlYlJUQyBjbGllbnQuIEZ1cnRoZXJtb3JlLCBpdCBpcyBjb21tb24gZm9yIERUTUYgZGln aXQgZGV0ZWN0aW9uIHRvIGJlIGNhdXNlZCBieSB0YWxrIG9mZiwgaS5lLiBzb21lIHZvaWNlIHBl cmlvZGljYWxseSB0cmlnZ2VycyBEVE1GIGRldGVjdGlvbi4gRmluYWxseSwgc29tZSBnYXRld2F5 cyB3aWxsIGFsc28gc2VuZCBBTlMgdG9uZXMgaWYgdGhlIGNhbGwgaGl0cyBhIGZheCBtYWNoaW5l LCBzbyBXZWJSVEMgZW5kIHBvaW50IHdpbGwgZ2V0IG5vdCBvbmx5IERUTUYgZXZlbnRzLCBidXQg ZXZlbnRzIGZvciB0b25lIHRoYXQgc29tZW9uZSBqdXN0IGhhcHBlbmVkIHRvIGVuYWJsZSBvbiB0 aGUgZ2F0ZXdheS4gVW5sZXNzIHdlIHdhbnQgdG8gdHJhbnNjb2RlIG1lZGlhIGNvbWluZyBmcm9t IFBTVE4sIFdlYlJUQyBjbGllbnQgd2lsbCBuZWVkIHRvIGRlYWwgd2l0aCBhbnkgaW5jb21pbmcg dGVsZXBob25lLWV2ZW50cy4gQWxsIG9mIHRoaXMgYmVpbmcgc2FpZCwgaXQgaXMgdXAgdG8gV2Vi UlRDIGNsaWVudCB0byBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIHRoZSByZWNlaXZlZCBldmVudHMu IEkgYW0gZmluZSB3aXRoIHRoZXNlIHRvbmVzIGJlaW5nIGRpc2NhcmQgYXMgbG9uZyBhcyB0aGV5 IGFyZSBiZWluZyBkaXNjYXJkZWQgaW4gYSBtYW5uZXIgd2hpY2ggZG9lcyBub3QgZGlzcnVwdCBu b3JtYWwgYXVkaW8gcHJvY2Vzc2luZy4NCg0K4oCLVGhpcyBzZWVtcyB0byByZXN1bHQgaW4gZXhh Y3RseSB0aGUgY2FzZSBDdWxsZW4gd2FzIGNvbmNlcm5lZCBhYm91dDsgaWYgdGhleSBtYXkgYmUg ZGlzY2FyZGVkIHRoZWlyIGZ1bmN0aW9uYWxpdHkgcmVtYWlucyBjb21wbGV0ZWx5IHVucmVsaWFi bGUu4oCLICBCdXQgbW9yZSB0byB0aGUgcG9pbnQsIHlvdSBhcmUgbm90IHBvaW50aW5nIHRvIHVz ZXMgb2YgQS1ELCBidXQgbnVtYmVyIGRldGVjdGlvbiBhbmQgZXZlbnRzIHdoaWNoIHdvdWxkIHN0 aWxsIGJlIGNvdmVyZWQuDQoNClRoaXMgaXMgY29tcGxldGVseSB1bnJlbGF0ZWQuIFRoaXMgYXBw bGllcyB0byBhbGwgRFRNRiB0b25lcywgbm90IEEtRCBzcGVjaWZpY2FsbHkuIFdoYXQgSSBhbSBz YXlpbmcgaXMgdGhhdCBXZWJSVEMgZW5kcG9pbnRzIG11c3QgYmUgYWJsZSB0byBnZW5lcmF0ZSBh bGwgRFRNRiB0b25lcyBpbmNsdWRpbmcgQS1EIGFuZCBzZW5kIHRoZW0gdG8gbGVnYWN5IFBTVE4g KGdhdGV3YXkpLiBMZWdhY3kgUFNUTiB3aWxsIHJlY2VpdmUgYW5kIGhhbmRsZSB0aGVtLiBJZiBs ZWdhY3kgUFNUTiAoZ2F0ZXdheSkgc2VuZHMgRFRNRiB0b25lcyB0byBXZWJSVEMgZW5kIHBvaW50 IChhbmQgaXQgd2lsbCwgZXZlbiB0aG91Z2ggdGhleSBhcmUgbm90IGV4cGVjdGVkIHRoZXJlKSwg V2ViUlRDIGVuZHBvaW50IGNhbiBkaXNjYXJkIHRoZW0sIGFzIGxvbmcgYXMgaXQgZG9lcyBpdCBu aWNlbHkuDQoNCg0K4oCLV2hpbGUgdGhpcyBpcyBubyBkb3VidCBub3QgeW91ciBpbnRlbnQsIEkg bXVzdCBzYXkgeW91ciBtZXNzYWdlIHJlYWRzIGFzICJTdXJlIGl0J3MgYnJva2VuIG5vdywgYnV0 IHdlIG11c3QgbWFrZSBzdXJlIGl0IHJlbWFpbnMgYnJva2VuIHRvIGJlIGJhY2t3YXJkcyBjb21w YXRpYmxlLiLigIsNCg0KTXkgaW50ZW50IGlzIHRoYXQgdGhlcmUgaXMgYW4gZXhpc3Rpbmcgd2Vs bCB1bmRlcnN0b29kIGZ1bmN0aW9uYWxpdHkgc2V0IHdpdGggaXRzIGJlbmVmaXRzICh3aWRlIHN1 cHBvcnQpIGFuZCBmYXVsdHMgKHVucmVsaWFiaWxpdHkpLiBUaGlzIGZ1bmN0aW9uYWxpdHkgc2V0 IGlzIGNhbGxlZCBEVE1GLiBXaHkgV2ViUlRDIG5lZWRzIHRvIHJlZGVmaW5lIHRoaXMgc2V0IGlz IGJleW9uZCBteSB1bmRlcnN0YW5kaW5nLg0KDQrigItUaGUgb25seSBBLUQgdG9uZSBpbiB0aGUg b25lIGV4YW1wbGUgeW91IGdhdmUgKGVjaG9saW5rKSB3YXMgdG8gcHVsbCB1cCBhIGRpZmZlcmVu dCBzdG9yZWQgY29uZmlndXJhdGlvbi4NCg0KU28sIG9uZSBvdXQgb2YgZm91ciB0b25lcyBpcyB1 c2VkIGluIHRoaXMgZXhhbXBsZS4NCg0KRFRNRiB0b25lIEEtRCBhcmUgdXNlZCB0byBwcm92aWRl IHByaW9yaXRpemVkIGNhbGwgaGFuZGxpbmcgc2VydmljZSBpbiBJVFUgUS45NTUuMyBzcGVjaWZp Y2F0aW9uIHdoaWNoIGlzIHN0aWxsIHVzZWQgYnkgc29tZSBQQlggYW5kIHBob25lIHN5c3RlbXMu DQoNCg0K4oCLQWdhaW4sIG5vdCBhdCBhbGwgY2xlYXIgdGhhdCBhIFdlYlJUQyBjbGllbnQgd291 bGQgZXZlciBleHBlY3QgdG8gdXNlIHRoZXNlIGZlYXR1cmVzIG9mIGEgUEJYLg0KDQpUaGVyZSBh cmUgaW50cmFuZXQgV2ViUlRDIGFwcGxpY2F0aW9ucyB0aGF0IGFjY2VzcyBpbi1jb21wYW55IGxl Z2FjeSBQQlggdmlhIGEgcHJpdmF0ZSBnYXRld2F5Lg0KDQrigItBbmQgdGhleSBhcmUgdXNpbmcg dGhlIEEtRCBzZXQ/DQoNClllcywgdGhleSBhcmUgdXNpbmcgQS1EIHNldCB0byBwcm92aWRlIHBy aW9yaXR5IGRpYWxpbmcuDQoNCkZpbmFsbHksIHNvbWUgY2FsbGluZyBjYXJkIGxpa2Ugc3lzdGVt cyBhbGxvdyByZW1vdGUgY29udHJvbCBvZiBmdW5jdGlvbnMgc3VjaCBhcyBmbGFzaCBieSBtYXBw aW5nIHRoZW0gdG8gZXh0ZW5kZWQgRFRNRiB0b25lcy4NCg0KDQrigItJZiB0aGVyZSBpcyBhIGNh bGxpbmcgY2FyZCBzeXN0ZW0gdXNpbmcgV2ViUlRDLCBJIGhhdmUgbm90IGhlYXJkIG9mIGl0LiAg Q2FuIHlvdSBwcm92aWRlIGEgcG9pbnRlcj/igIsNCg0KT25jZSBhZ2FpbiwgdGhpcyB3b3VsZCBi ZSBhIHByaXZhdGUgV2ViUlRDIGFwcGxpY2F0aW9uIHVzZWQgdG8gcGxhY2UgY2FsbHMgdGhyb3Vn aCBhIGdhdGV3YXkgd2hpY2ggaXMgdW5kZXIgY29udHJvbCBvZiB0aGUgcGVyc29uIHdobyBkZXZl bG9wZXIgdGhlIGFwcC4NCg0KDQrigItTbyB0aGlzIGlzIHRoZW9yZXRpY2FsLuKAiw0KDQpUaGlz IGlzIHJlYWwgd2l0aCBleGlzdGluZyBTSVAgaW50ZXJmYWNlIGJlaW5nIHJlcGxhY2VkIGJ5IFdl YlJUQy4NCg0K4oCLUmVtb3ZpbmcgdGhlbSBmcm9tIHRoZSBzZXQgZG9lcyBhcyB3ZWxsLCBhdCBs ZWFzdCBhcyBmYXIgYXMgSSBjYW4gdGVsbC4gIE5vIG9uZSBoYXMgc3VnZ2VzdGVkIHRoYXQgdGhl eSBiZSB0aGUgc3ViamVjdCBvZiBkaXNjb3Zlcnkgb3IgbmVnb3RpYXRpb24u4oCLDQoNCkFuZCB0 aGVuIHRoZXkgd2lsbCBiZSBhZGRlZCBiYWNrIGJ5IHNvbWUgdmVuZG9yIHdobyBnb3QgYSBjcml0 aWNhbCBjdXN0b21lciB3aG8gaXMgdXNpbmcgdGhlc2UgdG9uZXMgZm9yIHNvbWV0aGluZy4NCg0K RGVzcGl0ZSBtYW55IHdvcmRzIGV4Y2hhbmdlZCwgSSB0aGluayBvdXIgZW50aXJlIGFyZ3VtZW50 IGNhbiBiZSBib2lsZWQgZG93biB0byAibGV0J3MgcmVtb3ZlIHRoZXNlIHRvbmVzIHNpbmNlIHRo ZXkgc29tZXRpbWVzIGRvIG5vdCB3b3JrIGFuZCB0aGV5IGFyZSB1Z2x5IiB2cyAibGV0J3Mga2Vl cCB0aGVzZSB0b25lcyBzaW5jZSB0aGV5IGFyZSBzb21ldGltZXMgdXNlZCBhbmQgZG8gd29yayBv biBvY2Nhc2lvbi4iDQoNClAuUy4gSSBoYXZlIHByb3Bvc2VkIHNldmVyYWwgb3RoZXIgdGhpbmdz IGluIGFkZGl0aW9uIHRvIHRvbmVzIEEtRC4gQXJlIHRoZXJlIGFueSBjb21tZW50cyByZWdhcmRp bmcgYWRkaW5nIHRoZSBmb2xsb3dpbmc6DQoNCkdlbmVyYXRlZCBldmVudHMgTVVTVCBoYXZlIGR1 cmF0aW9uIG9mIG5vIG1vcmUgdGhhbiA2MDAwIG1zIGFuZCBubyBsZXNzIHRoYW4gNDAgbXMgd2l0 aCB0aGUgcmVjb21tZW5kZWQgZGVmYXVsdCBkdXJhdGlvbiBvZiAxMDAgbXMgZm9yIGVhY2ggdG9u ZS4gVGhlIGdhcCBiZXR3ZWVuIGV2ZW50cyBNVVNUIGJlIG5vIGxlc3MgdGhlbiAzMCBtcyB3aXRo IHRoZSByZWNvbW1lbmRlZCBkZWZhdWx0IGR1cmF0aW9uIG9mIDcwIG1zLiBFdmVudCBTSE9VTEQg c3RhcnQgb24gYSByZWd1bGFyIGF1ZGlvIHBhY2tldCBib3JkZXIuIEV2ZW50IGFuZCBnYXAgZHVy YXRpb24gU0hPVUxEIGJlIHJvdW5kZWQgdXAgdG8gdGhlIG5leHQgcmVndWxhciBhdWRpbyBwYWNr ZXQgYm9yZGVyLg0KDQpEdXJpbmcgdGhlIHRpbWUgZXZlbnRzIGFyZSBnZW5lcmF0ZWQgYXVkaW8g U0hPVUxEIE5PVCBiZSBzZW50IGZvciB0aGUgc2FtZSBhdWRpbyBzdHJlYW0uIFdoZW4gZ2FwcyBi ZXR3ZWVuIGV2ZW50cyBhcmUgZ2VuZXJhdGVkLCBzaWxlbmNlIGFuZCBub3QgdGhlIGJhY2tncm91 bmQgYXVkaW8gU0hPVUxEIGJlIHNlbnQgdXNpbmcgcmVndWxhciBhdWRpbyBlbmNvZGluZy4NCg0K SWYgbXVsdGlwbGUgYXVkaW8gc2FtcGxpbmcgcmF0ZXMgYXJlIHN1cHBvcnRlZCwgYXVkaW8vdGVs ZXBob25lLWV2ZW50IHBheWxvYWQgU0hPVUxEIGJlIHByZXNlbnQgZm9yIGVhY2ggc3VwcG9ydGVk IHNhbXBsaW5nIHJhdGUuIEVuZHBvaW50cyBTSE9VTEQgdXNlIGF1ZGlvL3RlbGVwaG9uZS1ldmVu dCBmb3JtYXQgcGFyYW1ldGVycyBkdXJpbmcgdGhlIG9mZmVyL2Fuc3dlciBleGNoYW5nZSB0byBp bmRpY2F0ZSB3aGljaCBldmVudHMgYXJlIHN1cHBvcnRlZC4NCg0KUmVjZWl2ZXJzIE1VU1QgYmUg YWJsZSB0byBjb25zdW1lIGFueSBhdWRpby90ZWxlcGhvbmUtZXZlbnQgZXZlbnRzIGluIHN1Y2gg YSB3YXkgdGhhdCBpdCB3aWxsIG5vdCBnZW5lcmF0ZSBhdWRpbyBhcnRpZmFjdHMsIHVuZXhwZWN0 ZWQgcGFja2V0IGxvc3MgY29uY2VhbG1lbnQsIGppdHRlciBidWZmZXIgYWRqdXN0bWVudHMsIHBh eWxvYWQgbWlzbWF0Y2hlcywgb3IgaW52YWxpZCBSVENQIHN0YXRpc3RpY3MgY2FsY3VsYXRpb24u IFJlY2VpdmVycyBNQVkgZ2VuZXJhdGUgYXVkaW8gY29ycmVzcG9uZGluZyB0byB0aGUgcmVjZWl2 ZWQgZXZlbnRzIGJ1dCBhcmUgYWxzbyBhbGxvd2VkIHRvIGRpc2NhcmQgdGhlbSBpbiBhIG1hbm5l ciB0aGF0IGRvZXMgbm90IGFmZmVjdCByZWd1bGFyIGF1ZGlvIHByb2Nlc3NpbmcuDQpfX19fX19f X19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_949EF20990823C4C85C18D59AA11AD8BADE2686DFR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBwcmlvcml0eSwgUS45NTUuMyBkb2VzIG5vdCBzcGVj aWZ5IHRoZSB1c2Ugb2YgYW55IGtleSBzZXF1ZW5jZXMgZm9yIHN1cHBvcnQgb2YgdGhlIHNlcnZp Y2UuIFEuOTU1LjMgaXMgdGhlIElTRE4gRFNTMSBzaWduYWxsaW5nIHNwZWNpZmljYXRpb24gYW5k IGRvZXMgbm90DQogdXNlIERUTUYuIEZ1cnRoZXIgaXQgaXMgYSBmdW5jdGlvbmFsIHNpZ25hbGlu ZyBzeXN0ZW0sIGkuZS4gYW55IGtleSBwcmVzc2VzIGFyZSBpZGVudGlmaWVkIGluIHRoZSB0ZXJt aW5hbCBhbmQgY29udmVydGVkIGludG8gcmVhbCBzaWduYWxzLCBzdWNoIGFzIOKAnGZsYXNoIG92 ZXJyaWRl4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhc3N1bWUgeW91IGFyZSByZWZlcnJpbmcgdG8gc29tZSBw cm9wcmlldGFyeSBQU1ROIGVxdWl2YWxlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZZCBub3RlIHRoYXQgdGhl IFBTVE4gZXF1aXZhbGVudCBjb2RlcyBvcmlnaW5hbGx5IHNwZWNpZmllZCBieSBDRVBUIGFuZCBw cm92aWRlZCBpbiBhbiBFVFNJIFRSIGZvciBvdGhlciBzZXJ2aWNlcyBkbyBub3QgdXNlIEEgdGhy b3VnaCBELCBwZXJmb3JtaW5nIGFsbCBzZXF1ZW5jZQ0KIHNlcGFyYXRvcnMgYW5kIHRlcm1pbmF0 aW9ucyB3aXRoIOKAnCrigJ0gYW5kIOKAnCPigJ0uIFRoZXJlIGlzIG5vdCBhbiBFVFNJIHZlcnNp b24gb2YgTUxQUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktlaXRoIERyYWdlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+Um9tYW4gU2hwb3VudDxicj4NCjxiPlNlbnQ6PC9iPiAxOCBEZWNlbWJlciAy MDE1IDIzOjI0PGJyPg0KPGI+VG86PC9iPiBUZWQgSGFyZGllPGJyPg0KPGI+Q2M6PC9iPiBDdWxs ZW4gSmVubmluZ3M7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0 Y3dlYl0gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlv PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGcmksIERlYyAxOCwgMjAxNSBhdCA1OjIyIFBNLCBUZWQgSGFyZGllICZs dDs8YSBocmVmPSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGVk LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7i gItTb3JyeSB0aGF0IHRoaXMgd2FzIG5vdCBjbGVhcjsgSSBtZWFudCBzcGVjaWZpY2FsbHkgQS1E LuKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2ZmZXIvYW5zd2VyIHRlbGVwaG9u ZSBldmVudCBuZWdvdGlhdGlvbiBpcyBub3JtYWxseSBieSBkaXJlY3Rpb25hbC4gVGhpcyBub3Jt YWxseSBlbmFibGVkIERUTUYgZGV0ZWN0aW9uIGluIFBTVE4gZ2F0ZXdheXMuIFNvLCBpZiB5b3Ug aGF2ZSBhbnkgc3lzdGVtIHRoYXQgY29ubmVjdHMgV2ViUlRDIGNsaWVudCB0byBQU1ROIG5ldHdv cmssIGFuZCBpZiB0aGUgcGVyc29uIG9uIFBTVE4gbmV0d29yayB3aWxsIHByZXNzDQogYSBrZXlw YWQgZGlnaXQsIHRoaXMgZGlnaXQgd2lsbCBiZSBzZW50IHRvIFdlYlJUQyBjbGllbnQuIEZ1cnRo ZXJtb3JlLCBpdCBpcyBjb21tb24gZm9yIERUTUYgZGlnaXQgZGV0ZWN0aW9uIHRvIGJlIGNhdXNl ZCBieSB0YWxrIG9mZiwgaS5lLiBzb21lIHZvaWNlIHBlcmlvZGljYWxseSB0cmlnZ2VycyBEVE1G IGRldGVjdGlvbi4gRmluYWxseSwgc29tZSBnYXRld2F5cyB3aWxsIGFsc28gc2VuZCBBTlMgdG9u ZXMgaWYgdGhlIGNhbGwgaGl0cyBhDQogZmF4IG1hY2hpbmUsIHNvIFdlYlJUQyBlbmQgcG9pbnQg d2lsbCBnZXQgbm90IG9ubHkgRFRNRiBldmVudHMsIGJ1dCBldmVudHMgZm9yIHRvbmUgdGhhdCBz b21lb25lIGp1c3QgaGFwcGVuZWQgdG8gZW5hYmxlIG9uIHRoZSBnYXRld2F5LiBVbmxlc3Mgd2Ug d2FudCB0byB0cmFuc2NvZGUgbWVkaWEgY29taW5nIGZyb20gUFNUTiwgV2ViUlRDIGNsaWVudCB3 aWxsIG5lZWQgdG8gZGVhbCB3aXRoIGFueSBpbmNvbWluZyB0ZWxlcGhvbmUtZXZlbnRzLg0KIEFs bCBvZiB0aGlzIGJlaW5nIHNhaWQsIGl0IGlzIHVwIHRvIFdlYlJUQyBjbGllbnQgdG8gZGVjaWRl IHdoYXQgdG8gZG8gd2l0aCB0aGUgcmVjZWl2ZWQgZXZlbnRzLiBJIGFtIGZpbmUgd2l0aCB0aGVz ZSB0b25lcyBiZWluZyBkaXNjYXJkIGFzIGxvbmcgYXMgdGhleSBhcmUgYmVpbmcgZGlzY2FyZGVk IGluIGEgbWFubmVyIHdoaWNoIGRvZXMgbm90IGRpc3J1cHQgbm9ybWFsIGF1ZGlvIHByb2Nlc3Np bmcuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLVGhpcyBzZWVt cyB0byByZXN1bHQgaW4gZXhhY3RseSB0aGUgY2FzZSBDdWxsZW4gd2FzIGNvbmNlcm5lZCBhYm91 dDsgaWYgdGhleSBtYXkgYmUgZGlzY2FyZGVkIHRoZWlyIGZ1bmN0aW9uYWxpdHkgcmVtYWlucyBj b21wbGV0ZWx5IHVucmVsaWFibGUu4oCLJm5ic3A7IEJ1dCBtb3JlIHRvIHRoZSBwb2ludCwgeW91 IGFyZSBub3QgcG9pbnRpbmcNCiB0byB1c2VzIG9mIEEtRCwgYnV0IG51bWJlciBkZXRlY3Rpb24g YW5kIGV2ZW50cyB3aGljaCB3b3VsZCBzdGlsbCBiZSBjb3ZlcmVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGNvbXBsZXRlbHkgdW5y ZWxhdGVkLiBUaGlzIGFwcGxpZXMgdG8gYWxsIERUTUYgdG9uZXMsIG5vdCBBLUQgc3BlY2lmaWNh bGx5LiBXaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQgV2ViUlRDIGVuZHBvaW50cyBtdXN0IGJlIGFi bGUgdG8gZ2VuZXJhdGUgYWxsIERUTUYgdG9uZXMgaW5jbHVkaW5nIEEtRCBhbmQgc2VuZCB0aGVt IHRvIGxlZ2FjeSBQU1ROIChnYXRld2F5KS4gTGVnYWN5IFBTVE4gd2lsbA0KIHJlY2VpdmUgYW5k IGhhbmRsZSB0aGVtLiBJZiBsZWdhY3kgUFNUTiAoZ2F0ZXdheSkgc2VuZHMgRFRNRiB0b25lcyB0 byBXZWJSVEMgZW5kIHBvaW50IChhbmQgaXQgd2lsbCwgZXZlbiB0aG91Z2ggdGhleSBhcmUgbm90 IGV4cGVjdGVkIHRoZXJlKSwgV2ViUlRDIGVuZHBvaW50IGNhbiBkaXNjYXJkIHRoZW0sIGFzIGxv bmcgYXMgaXQgZG9lcyBpdCBuaWNlbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi1doaWxlIHRo aXMgaXMgbm8gZG91YnQgbm90IHlvdXIgaW50ZW50LCBJIG11c3Qgc2F5IHlvdXIgbWVzc2FnZSBy ZWFkcyBhcyAmcXVvdDtTdXJlIGl0J3MgYnJva2VuIG5vdywgYnV0IHdlIG11c3QgbWFrZSBzdXJl IGl0IHJlbWFpbnMgYnJva2VuIHRvIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlLiZxdW90O+KAizwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgaW50ZW50IGlzIHRoYXQgdGhlcmUgaXMgYW4gZXhp c3Rpbmcgd2VsbCB1bmRlcnN0b29kIGZ1bmN0aW9uYWxpdHkgc2V0IHdpdGggaXRzIGJlbmVmaXRz ICh3aWRlIHN1cHBvcnQpIGFuZCBmYXVsdHMgKHVucmVsaWFiaWxpdHkpLiBUaGlzIGZ1bmN0aW9u YWxpdHkgc2V0IGlzIGNhbGxlZCBEVE1GLiBXaHkgV2ViUlRDIG5lZWRzIHRvIHJlZGVmaW5lIHRo aXMgc2V0IGlzIGJleW9uZCBteSB1bmRlcnN0YW5kaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItUaGUgb25seSBBLUQgdG9uZSBpbiB0aGUgb25l IGV4YW1wbGUgeW91IGdhdmUgKGVjaG9saW5rKSB3YXMgdG8gcHVsbCB1cCBhIGRpZmZlcmVudCBz dG9yZWQgY29uZmlndXJhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvLCBvbmUgb3V0IG9mIGZvdXIgdG9uZXMgaXMgdXNlZCBpbiB0aGlzIGV4YW1wbGUu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkRUTUYgdG9uZSBBLUQgYXJlIHVzZWQgdG8gcHJvdmlkZSBwcmlv cml0aXplZCBjYWxsIGhhbmRsaW5nIHNlcnZpY2UgaW4gSVRVIFEuOTU1LjMgc3BlY2lmaWNhdGlv biB3aGljaCBpcyBzdGlsbCB1c2VkIGJ5IHNvbWUgUEJYIGFuZCBwaG9uZSBzeXN0ZW1zLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItBZ2Fpbiwgbm90IGF0IGFsbCBjbGVhciB0 aGF0IGEgV2ViUlRDIGNsaWVudCB3b3VsZCBldmVyIGV4cGVjdCB0byB1c2UgdGhlc2UgZmVhdHVy ZXMgb2YgYSBQQlguPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZXJlIGFyZSBpbnRyYW5ldCBXZWJSVEMgYXBwbGljYXRpb25zIHRoYXQgYWNjZXNz IGluLWNvbXBhbnkgbGVnYWN5IFBCWCB2aWEgYSBwcml2YXRlIGdhdGV3YXkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi0FuZCB0aGV5IGFyZSB1c2luZyB0aGUgQS1E IHNldD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WWVzLCB0aGV5IGFyZSB1c2luZyBBLUQgc2V0IHRvIHByb3ZpZGUgcHJpb3JpdHkgZGlhbGluZy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZpbmFsbHksIHNvbWUgY2FsbGluZyBjYXJkIGxpa2Ugc3lzdGVt cyBhbGxvdyByZW1vdGUgY29udHJvbCBvZiBmdW5jdGlvbnMgc3VjaCBhcyBmbGFzaCBieSBtYXBw aW5nIHRoZW0gdG8gZXh0ZW5kZWQgRFRNRiB0b25lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij7igItJZiB0aGVyZSBpcyBhIGNhbGxpbmcgY2FyZCBzeXN0ZW0gdXNp bmcgV2ViUlRDLCBJIGhhdmUgbm90IGhlYXJkIG9mIGl0LiZuYnNwOyBDYW4geW91IHByb3ZpZGUg YSBwb2ludGVyP+KAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbmNlIGFnYWluLCB0aGlzIHdvdWxkIGJlIGEgcHJpdmF0ZSBXZWJSVEMgYXBwbGlj YXRpb24gdXNlZCB0byBwbGFjZSBjYWxscyB0aHJvdWdoIGEgZ2F0ZXdheSB3aGljaCBpcyB1bmRl ciBjb250cm9sIG9mIHRoZSBwZXJzb24gd2hvIGRldmVsb3BlciB0aGUgYXBwLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi1NvIHRoaXMgaXMgdGhlb3JldGljYWwu 4oCLPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgaXMgcmVhbCB3aXRoIGV4aXN0aW5nIFNJUCBpbnRlcmZhY2UgYmVpbmcgcmVwbGFjZWQgYnkg V2ViUlRDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItSZW1v dmluZyB0aGVtIGZyb20gdGhlIHNldCBkb2VzIGFzIHdlbGwsIGF0IGxlYXN0IGFzIGZhciBhcyBJ IGNhbiB0ZWxsLiZuYnNwOyBObyBvbmUgaGFzIHN1Z2dlc3RlZCB0aGF0IHRoZXkgYmUgdGhlIHN1 YmplY3Qgb2YgZGlzY292ZXJ5IG9yIG5lZ290aWF0aW9uLuKAizwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGVuIHRoZXkgd2lsbCBiZSBhZGRlZCBiYWNr IGJ5IHNvbWUgdmVuZG9yIHdobyBnb3QgYSBjcml0aWNhbCBjdXN0b21lciB3aG8gaXMgdXNpbmcg dGhlc2UgdG9uZXMgZm9yIHNvbWV0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVzcGl0ZSBtYW55IHdvcmRzIGV4Y2hhbmdlZCwgSSB0 aGluayBvdXIgZW50aXJlIGFyZ3VtZW50IGNhbiBiZSBib2lsZWQgZG93biB0byAmcXVvdDtsZXQn cyByZW1vdmUgdGhlc2UgdG9uZXMgc2luY2UgdGhleSBzb21ldGltZXMgZG8gbm90IHdvcmsgYW5k IHRoZXkgYXJlIHVnbHkmcXVvdDsgdnMgJnF1b3Q7bGV0J3Mga2VlcCB0aGVzZSB0b25lcyBzaW5j ZSB0aGV5IGFyZSBzb21ldGltZXMgdXNlZCBhbmQgZG8gd29yayBvbiBvY2Nhc2lvbi4mcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UC5T LiBJIGhhdmUgcHJvcG9zZWQgc2V2ZXJhbCBvdGhlciB0aGluZ3MgaW4gYWRkaXRpb24gdG8gdG9u ZXMgQS1ELiBBcmUgdGhlcmUgYW55IGNvbW1lbnRzIHJlZ2FyZGluZyBhZGRpbmcgdGhlIGZvbGxv d2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HZW5l cmF0ZWQgZXZlbnRzIE1VU1QgaGF2ZSBkdXJhdGlvbiBvZiBubyBtb3JlIHRoYW4gNjAwMCBtcyBh bmQgbm8gbGVzcyZuYnNwO3RoYW4gNDAgbXMgd2l0aCB0aGUgcmVjb21tZW5kZWQgZGVmYXVsdCBk dXJhdGlvbiBvZiAxMDAgbXMgZm9yIGVhY2ggdG9uZS4gVGhlIGdhcCBiZXR3ZWVuIGV2ZW50cyBN VVNUIGJlIG5vIGxlc3MgdGhlbiAzMCBtcyB3aXRoIHRoZSByZWNvbW1lbmRlZCZuYnNwO2RlZmF1 bHQgZHVyYXRpb24gb2YNCiA3MCBtcy4gRXZlbnQgU0hPVUxEIHN0YXJ0IG9uIGEgcmVndWxhciBh dWRpbyBwYWNrZXQmbmJzcDtib3JkZXIuIEV2ZW50IGFuZCBnYXAgZHVyYXRpb24gU0hPVUxEIGJl IHJvdW5kZWQgdXAgdG8gdGhlIG5leHQgcmVndWxhciZuYnNwO2F1ZGlvIHBhY2tldCBib3JkZXIu PGJyPg0KPGJyPg0KRHVyaW5nIHRoZSB0aW1lIGV2ZW50cyBhcmUgZ2VuZXJhdGVkIGF1ZGlvIFNI T1VMRCBOT1QgYmUgc2VudCBmb3IgdGhlIHNhbWUmbmJzcDthdWRpbyBzdHJlYW0uIFdoZW4gZ2Fw cyBiZXR3ZWVuIGV2ZW50cyBhcmUgZ2VuZXJhdGVkLCBzaWxlbmNlJm5ic3A7YW5kIG5vdCB0aGUg YmFja2dyb3VuZCBhdWRpbyBTSE9VTEQgYmUgc2VudCB1c2luZyByZWd1bGFyIGF1ZGlvIGVuY29k aW5nLjxicj4NCjxicj4NCklmIG11bHRpcGxlIGF1ZGlvIHNhbXBsaW5nIHJhdGVzIGFyZSBzdXBw b3J0ZWQsIGF1ZGlvL3RlbGVwaG9uZS1ldmVudCBwYXlsb2FkJm5ic3A7U0hPVUxEIGJlIHByZXNl bnQgZm9yIGVhY2ggc3VwcG9ydGVkIHNhbXBsaW5nIHJhdGUuIEVuZHBvaW50cyBTSE9VTEQgdXNl Jm5ic3A7YXVkaW8vdGVsZXBob25lLWV2ZW50IGZvcm1hdCBwYXJhbWV0ZXJzIGR1cmluZyB0aGUg b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIHRvIGluZGljYXRlIHdoaWNoIGV2ZW50cyBhcmUgc3VwcG9y dGVkLjxicj4NCjxicj4NClJlY2VpdmVycyBNVVNUIGJlIGFibGUgdG8gY29uc3VtZSBhbnkgYXVk aW8vdGVsZXBob25lLWV2ZW50IGV2ZW50cyZuYnNwO2luIHN1Y2ggYSB3YXkgdGhhdCBpdCB3aWxs IG5vdCBnZW5lcmF0ZSBhdWRpbyBhcnRpZmFjdHMsIHVuZXhwZWN0ZWQgcGFja2V0IGxvc3MgY29u Y2VhbG1lbnQsIGppdHRlciBidWZmZXIgYWRqdXN0bWVudHMsIHBheWxvYWQgbWlzbWF0Y2hlcywm bmJzcDtvciBpbnZhbGlkIFJUQ1Agc3RhdGlzdGljcyBjYWxjdWxhdGlvbi4gUmVjZWl2ZXJzDQog TUFZIGdlbmVyYXRlIGF1ZGlvJm5ic3A7Y29ycmVzcG9uZGluZyB0byB0aGUgcmVjZWl2ZWQgZXZl bnRzIGJ1dCBhcmUgYWxzbyBhbGxvd2VkIHRvIGRpc2NhcmQmbmJzcDt0aGVtIGluIGEgbWFubmVy IHRoYXQgZG9lcyBub3QgYWZmZWN0IHJlZ3VsYXIgYXVkaW8gcHJvY2Vzc2luZy48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_949EF20990823C4C85C18D59AA11AD8BADE2686DFR712WXCHMBA11z_-- From nobody Mon Dec 21 11:52:19 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E141AC444 for ; Mon, 21 Dec 2015 11:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O6B3gZYMNpR for ; Mon, 21 Dec 2015 11:52:15 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978111AC43A for ; Mon, 21 Dec 2015 11:52:15 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id e126so165289362ioa.1 for ; Mon, 21 Dec 2015 11:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kFWvW/FNO5cqLXAvrIeh5ihcZsLAlJjtMFlGe+t8NRo=; b=rQrev1n+hGLFAb198MmGC1Ij8xjsx48EWzXIdwO4W3p2p51QajzsH4EJ6hXjsz1mUD yTKbIo5NpwHYjA8hCwtPcvT+dTQKxX4WCFXZ128H0xXt5tmpI9qktlU4X9rUH+Q0vMkm FpNAWN6ToafqU+9K8JjxD+prH8AFqbosDcJv4MEr14s6pLEtLE3qv3R1ktmHKlBH/g/S sa3PZSdvdPvcg/EyKXneqxAOQtORWSd489uCYGEvI5D49a3hkHqx+BWb2IcNTg3cgFxC WnFPw7WWw1VZwGfRJW3aoGzBJnPgEhJVfiXwiElnYQXXsz3OKIgu7bdHA0zEI1h8eu0j KUKg== 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=kFWvW/FNO5cqLXAvrIeh5ihcZsLAlJjtMFlGe+t8NRo=; b=AMEVRL3t5RWRgC/DwwdONi4p8BMK4YpvnHSyiXObNnANmB7zxmDmQtQoGeH7dxTeG8 TjS5EAa348++EiKFTarfusDQsmGh9XwwEG87yGMRneWaHRqtjJ4N1VJ4z8hetP7XpqMC MsTzRF1wuYzV1yEWxA2xh9BQvBoaQ2kRbYOlb02qu19cCrbPC4EnLHU79Mkj3vmkqOB8 DauYtJqD2aiH1lJn/0FgEj5mpbST9U4SfxxiTMAKwW256NGAnAhKlwYc57h6mybzHtl0 3T/noZAa8WEk+K1F9LC3uq66h923wSu3+PcRdTapirr582g8peqtEXfEZJkPzmbNpjF2 cDvw== X-Gm-Message-State: ALoCoQlyshLoUY1kvfzp5YQFC35PTaTpI3K4/xym9uLsmWBYPAUeZr+xESNVfLufVVhuD9TTA2rYGqcfsjuRxc94dhpOsddXpA== X-Received: by 10.107.18.71 with SMTP id a68mr23823162ioj.107.1450727534967; Mon, 21 Dec 2015 11:52:14 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id eg1sm8736369igb.18.2015.12.21.11.52.13 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Dec 2015 11:52:13 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id ph11so45089470igc.1 for ; Mon, 21 Dec 2015 11:52:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.129.99 with SMTP id nv3mr9897410igb.96.1450727532898; Mon, 21 Dec 2015 11:52:12 -0800 (PST) Received: by 10.36.105.15 with HTTP; Mon, 21 Dec 2015 11:52:12 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE2686D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADE2686D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 21 Dec 2015 14:52:12 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=047d7b3a91e643b16e05276dd3c1 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 19:52:18 -0000 --047d7b3a91e643b16e05276dd3c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was referring to AUTOVON like implementations of of MLPP, which use DTMF tone A through D for priority. Regards, _____________ Roman Shpount On Sun, Dec 20, 2015 at 6:54 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > For priority, Q.955.3 does not specify the use of any key sequences for > support of the service. Q.955.3 is the ISDN DSS1 signalling specification > and does not use DTMF. Further it is a functional signaling system, i.e. > any key presses are identified in the terminal and converted into real > signals, such as =E2=80=9Cflash override=E2=80=9D. > > > > I assume you are referring to some proprietary PSTN equivalent. > > > > I=E2=80=99d note that the PSTN equivalent codes originally specified by C= EPT and > provided in an ETSI TR for other services do not use A through D, > performing all sequence separators and terminations with =E2=80=9C*=E2=80= =9D and =E2=80=9C#=E2=80=9D. There > is not an ETSI version of MLPP. > > > > Regards > > > > Keith Drage > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Roman > Shpount > *Sent:* 18 December 2015 23:24 > *To:* Ted Hardie > *Cc:* Cullen Jennings; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Working group last call for > draft-ietf-rtcweb-audio > > > > On Fri, Dec 18, 2015 at 5:22 PM, Ted Hardie wrote: > > > > =E2=80=8BSorry that this was not clear; I meant specifically A-D.=E2=80= =8B > > > > Offer/answer telephone event negotiation is normally by directional. This > normally enabled DTMF detection in PSTN gateways. So, if you have any > system that connects WebRTC client to PSTN network, and if the person on > PSTN network will press a keypad digit, this digit will be sent to WebRTC > client. Furthermore, it is common for DTMF digit detection to be caused b= y > talk off, i.e. some voice periodically triggers DTMF detection. Finally, > some gateways will also send ANS tones if the call hits a fax machine, so > WebRTC end point will get not only DTMF events, but events for tone that > someone just happened to enable on the gateway. Unless we want to transco= de > media coming from PSTN, WebRTC client will need to deal with any incoming > telephone-events. All of this being said, it is up to WebRTC client to > decide what to do with the received events. I am fine with these tones > being discard as long as they are being discarded in a manner which does > not disrupt normal audio processing. > > > > =E2=80=8BThis seems to result in exactly the case Cullen was concerned ab= out; if > they may be discarded their functionality remains completely unreliable.= =E2=80=8B > But more to the point, you are not pointing to uses of A-D, but number > detection and events which would still be covered. > > > > This is completely unrelated. This applies to all DTMF tones, not A-D > specifically. What I am saying is that WebRTC endpoints must be able to > generate all DTMF tones including A-D and send them to legacy PSTN > (gateway). Legacy PSTN will receive and handle them. If legacy PSTN > (gateway) sends DTMF tones to WebRTC end point (and it will, even though > they are not expected there), WebRTC endpoint can discard them, as long a= s > it does it nicely. > > > > > > =E2=80=8BWhile this is no doubt not your intent, I must say your message = reads as > "Sure it's broken now, but we must make sure it remains broken to be > backwards compatible."=E2=80=8B > > > > My intent is that there is an existing well understood functionality set > with its benefits (wide support) and faults (unreliability). This > functionality set is called DTMF. Why WebRTC needs to redefine this set i= s > beyond my understanding. > > > > =E2=80=8BThe only A-D tone in the one example you gave (echolink) was to = pull up a > different stored configuration. > > > > So, one out of four tones is used in this example. > > > > DTMF tone A-D are used to provide prioritized call handling service in IT= U > Q.955.3 specification which is still used by some PBX and phone systems. > > > > > > =E2=80=8BAgain, not at all clear that a WebRTC client would ever expect t= o use > these features of a PBX. > > > > There are intranet WebRTC applications that access in-company legacy PBX > via a private gateway. > > > > =E2=80=8BAnd they are using the A-D set? > > > > Yes, they are using A-D set to provide priority dialing. > > > > Finally, some calling card like systems allow remote control of functions > such as flash by mapping them to extended DTMF tones. > > > > > > =E2=80=8BIf there is a calling card system using WebRTC, I have not heard= of it. > Can you provide a pointer?=E2=80=8B > > > > Once again, this would be a private WebRTC application used to place call= s > through a gateway which is under control of the person who developer the > app. > > > > > > =E2=80=8BSo this is theoretical.=E2=80=8B > > > > This is real with existing SIP interface being replaced by WebRTC. > > > > =E2=80=8BRemoving them from the set does as well, at least as far as I ca= n tell. > No one has suggested that they be the subject of discovery or negotiation= .=E2=80=8B > > > > And then they will be added back by some vendor who got a critical > customer who is using these tones for something. > > > > Despite many words exchanged, I think our entire argument can be boiled > down to "let's remove these tones since they sometimes do not work and th= ey > are ugly" vs "let's keep these tones since they are sometimes used and do > work on occasion." > > > > P.S. I have proposed several other things in addition to tones A-D. Are > there any comments regarding adding the following: > > > > Generated events MUST have duration of no more than 6000 ms and no > less than 40 ms with the recommended default duration of 100 ms for each > tone. The gap between events MUST be no less then 30 ms with the > recommended default duration of 70 ms. Event SHOULD start on a regular > audio packet border. Event and gap duration SHOULD be rounded up to the > next regular audio packet border. > > During the time events are generated audio SHOULD NOT be sent for the > same audio stream. When gaps between events are generated, silence and no= t > the background audio SHOULD be sent using regular audio encoding. > > If multiple audio sampling rates are supported, audio/telephone-event > payload SHOULD be present for each supported sampling rate. Endpoints > SHOULD use audio/telephone-event format parameters during the offer/answe= r > exchange to indicate which events are supported. > > Receivers MUST be able to consume any audio/telephone-event events in suc= h > a way that it will not generate audio artifacts, unexpected packet loss > concealment, jitter buffer adjustments, payload mismatches, or invalid RT= CP > statistics calculation. Receivers MAY generate audio corresponding to the > received events but are also allowed to discard them in a manner that doe= s > not affect regular audio processing. > > _____________ > Roman Shpount > > > --047d7b3a91e643b16e05276dd3c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was referring to AUTOVON like implementations of of MLPP= , which use DTMF tone A through D for priority.

Regards,
_____________
Roman Shpount

On Sun, Dec 20, 2015 at 6:54 AM, DRAGE, Keit= h (Keith) <keith.drage@alcatel-lucent.com> wrot= e:

For priority, Q.955.3 does not specify the u= se of any key sequences for support of the service. Q.955.3 is the ISDN DSS= 1 signalling specification and does not use DTMF. Further it is a functional signaling system, i.e. any key presse= s are identified in the terminal and converted into real signals, such as = =E2=80=9Cflash override=E2=80=9D.

=C2=A0

I assume you are referring to some proprieta= ry PSTN equivalent.

=C2=A0

I=E2=80=99d note that the PSTN equivalent co= des originally specified by CEPT and provided in an ETSI TR for other servi= ces do not use A through D, performing all sequence separators and terminations with =E2=80=9C*=E2=80=9D and =E2=80=9C#=E2=80= =9D. There is not an ETSI version of MLPP.

=C2=A0

Regards

=C2=A0

Keith Drage

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 18 December 2015 23:24
To: Ted Hardie
Cc: Cullen Jennings; rtcweb@ietf.org
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-= audio

=C2=A0

On Fri, Dec 18, 2015 at 5:22 PM, Ted Hardie <ted.ietf@gmail.com&= gt; wrote:

=C2=A0

=E2=80= =8BSorry that this was not clear; I meant specifically A-D.=E2=80=8B=

=C2=A0

Offer/answer telephone event negotiation is normally= by directional. This normally enabled DTMF detection in PSTN gateways. So,= if you have any system that connects WebRTC client to PSTN network, and if= the person on PSTN network will press a keypad digit, this digit will be sent to WebRTC client. Furthermore, it = is common for DTMF digit detection to be caused by talk off, i.e. some voic= e periodically triggers DTMF detection. Finally, some gateways will also se= nd ANS tones if the call hits a fax machine, so WebRTC end point will get not only DTMF events, but events= for tone that someone just happened to enable on the gateway. Unless we wa= nt to transcode media coming from PSTN, WebRTC client will need to deal wit= h any incoming telephone-events. All of this being said, it is up to WebRTC client to decide what to do wit= h the received events. I am fine with these tones being discard as long as = they are being discarded in a manner which does not disrupt normal audio pr= ocessing.

=C2=A0

=E2=80= =8BThis seems to result in exactly the case Cullen was concerned about; if = they may be discarded their functionality remains completely unreliable.=E2= =80=8B=C2=A0 But more to the point, you are not pointing to uses of A-D, but number detection and events which would still be cover= ed.

=C2=A0

This is completely unrelated. This applies to all DT= MF tones, not A-D specifically. What I am saying is that WebRTC endpoints m= ust be able to generate all DTMF tones including A-D and send them to legac= y PSTN (gateway). Legacy PSTN will receive and handle them. If legacy PSTN (gateway) sends DTMF tones to WebR= TC end point (and it will, even though they are not expected there), WebRTC= endpoint can discard them, as long as it does it nicely.

=C2=A0

=C2=A0

=E2=80= =8BWhile this is no doubt not your intent, I must say your message reads as= "Sure it's broken now, but we must make sure it remains broken to= be backwards compatible."=E2=80=8B

=C2=A0

My intent is that there is an existing well understo= od functionality set with its benefits (wide support) and faults (unreliabi= lity). This functionality set is called DTMF. Why WebRTC needs to redefine = this set is beyond my understanding.=C2=A0

=C2=A0

=E2=80= =8BThe only A-D tone in the one example you gave (echolink) was to pull up = a different stored configuration.

=C2=A0

So, one out of four tones is used in this example.= =C2=A0

=C2=A0

DTMF tone A-D are used to provide prioritized call h= andling service in ITU Q.955.3 specification which is still used by some PB= X and phone systems.

=C2=A0

=C2=A0

=E2=80= =8BAgain, not at all clear that a WebRTC client would ever expect to use th= ese features of a PBX.

=C2=A0

There are intranet WebRTC applications that access i= n-company legacy PBX via a private gateway.

=C2=A0

=E2=80= =8BAnd they are using the A-D set?

=C2=A0

Yes, they are using A-D set to provide priority dial= ing.

=C2=A0

Finally, some calling card like systems allow remote= control of functions such as flash by mapping them to extended DTMF tones.=

=C2=A0

=C2=A0

=E2=80= =8BIf there is a calling card system using WebRTC, I have not heard of it.= =C2=A0 Can you provide a pointer?=E2=80=8B

=C2=A0

Once again, this would be a private WebRTC applicati= on used to place calls through a gateway which is under control of the pers= on who developer the app.

=C2=A0

=C2=A0

=E2=80= =8BSo this is theoretical.=E2=80=8B

=C2=A0

This is real with existing SIP interface being repla= ced by WebRTC.

=C2=A0

=E2=80= =8BRemoving them from the set does as well, at least as far as I can tell.= =C2=A0 No one has suggested that they be the subject of discovery or negoti= ation.=E2=80=8B

=C2=A0

And then they will be added back by some vendor who = got a critical customer who is using these tones for something.

=C2=A0

Despite many words exchanged, I think our entire arg= ument can be boiled down to "let's remove these tones since they s= ometimes do not work and they are ugly" vs "let's keep these = tones since they are sometimes used and do work on occasion."

=C2=A0

P.S. I have proposed several other things in additio= n to tones A-D. Are there any comments regarding adding the following:

=C2=A0

Generated events MUST have duration of no more than = 6000 ms and no less=C2=A0than 40 ms with the recommended default duration o= f 100 ms for each tone. The gap between events MUST be no less then 30 ms w= ith the recommended=C2=A0default duration of 70 ms. Event SHOULD start on a regular audio packet=C2=A0border. Event and= gap duration SHOULD be rounded up to the next regular=C2=A0audio packet bo= rder.

During the time events are generated audio SHOULD NOT be sent for the same= =C2=A0audio stream. When gaps between events are generated, silence=C2=A0an= d not the background audio SHOULD be sent using regular audio encoding.

If multiple audio sampling rates are supported, audio/telephone-event paylo= ad=C2=A0SHOULD be present for each supported sampling rate. Endpoints SHOUL= D use=C2=A0audio/telephone-event format parameters during the offer/answer = exchange to indicate which events are supported.

Receivers MUST be able to consume any audio/telephone-event events=C2=A0in = such a way that it will not generate audio artifacts, unexpected packet los= s concealment, jitter buffer adjustments, payload mismatches,=C2=A0or inval= id RTCP statistics calculation. Receivers MAY generate audio=C2=A0corresponding to the received events but are also = allowed to discard=C2=A0them in a manner that does not affect regular audio= processing.

_____________
Roman Shpount

=C2=A0


--047d7b3a91e643b16e05276dd3c1-- From nobody Mon Dec 21 15:25:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4E21ACE80 for ; Mon, 21 Dec 2015 15:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rjyb9VTw2jY for ; Mon, 21 Dec 2015 15:25:24 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813E31ACE7A for ; Mon, 21 Dec 2015 15:25:22 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 8032FF2CDB0DA; Mon, 21 Dec 2015 23:25:16 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tBLNPHME013476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Dec 2015 00:25:17 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 22 Dec 2015 00:25:17 +0100 From: "DRAGE, Keith (Keith)" To: Roman Shpount Thread-Topic: [rtcweb] Working group last call for draft-ietf-rtcweb-audio Thread-Index: AQHROb/m0JZd2tvJAUGJKJJIm+7DEZ7RALIAgAARSQCAABq6gIAACYUAgAAHVICAAANBAIAAEViAgAJyagCAAglWAIAAQ/Vw Date: Mon, 21 Dec 2015 23:25:16 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE27108@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADE2686D@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.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADE27108FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 23:25:28 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADE27108FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIGFzIEkgaW5kaWNhdGVkLCB0aGF0IGlzIGEgcHJvcHJpZXRhcnkgaW1wbGVtZW50aW9uLCBh bmQgbm90aGluZyB3aGF0c29ldmVyIHRvIGRvIHdpdGggUS45NTUuMy4NCg0KSSBkbyBub3Qga25v dyB3aGF0IGlzIGluIGFsbCB0aGUgTkFSIHN0YW5kYXJkcywgYnV0IEkgYW0gcHJldHR5IGNlcnRh aW4gdGhlcmUgaXMgbm8gc3RhbmRhcmRpemVkIHVzYWdlIChpLmUuIHJlcHJlc2VudGVkIGluIGEg cHVibGlzaGVkIHN0YW5kYXJkKSBlaXRoZXIgZ2xvYmFsbHkgb3IgaW4gRXVyb3BlLCBpbiByZXNw ZWN0IG9mIEEgdGhyb3VnaCBEIHVzYWdlLiBJbmRlZWQgbWF5IHNpZ25hbGluZyBzY2hlbWVzIHVz aW5nIERUTUYgZG8gbm90IGV2ZW4gZGVmaW5lIHRoZWlyIHVzYWdlIChGLjIzIGFuZCBRLjIzIGFs bG9jYXRlIHRoZSB0b25lcyBidXQgZXNzZW50aWFsbHkgbGVhdmUgdGhlIGV4dHJhIGNvbWJpbmF0 aW9ucyByZXNlcnZlZCkuDQoNCklmIHdlIGFyZSBnb2luZyB0byBzdGF0ZSB1c2UgY2FzZXMsIEkg d291bGQgcHJlZmVyIHRvIGtlZXAgdGhlbSBhY2N1cmF0ZS4NCg0KTm90ZSB0aGF0IFdpa2lwZWRp YSBpbmRpY2F0ZXMgdGhhdCB0aGUgQVVUT1ZPTiB1c2UgY2FzZSBpcyBub3cgb2Jzb2xldGUuDQoN CknigJlkIGFsc28gbm90ZSB0aGF0IHNvbWUgb2YgdGhlc2UgYXJndW1lbnRzIGFib3V0IHVzZSBj YXNlcyBzZWVtIHRvIGJlIGdvaW5nIGludG8gc2VuZGluZyBEVE1GIHRvIHdlYnJ0YyBlbmRwb2lu dCwgd2hpY2ggd291bGQgc2VlbSB0byBicmluZyB1cyBpbnRvIHVzZSBjYXNlcyBvZiB3ZWJSVEMg Z2F0ZXdheSB0byB3ZWJSVEMgZ2F0ZXdheSBzaWduYWxpbmcsIHdoaWNoIGF0IGxlYXN0IGlzIG5v dCBjb3ZlcmVkIGluIG91ciBjdXJyZW50IGdhdGV3YXlzIGRvY3VtZW50Lg0KDQpSZWdhcmRzDQoN CktlaXRoDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0N ClNlbnQ6IDIxIERlY2VtYmVyIDIwMTUgMTk6NTINClRvOiBEUkFHRSwgS2VpdGggKEtlaXRoKQ0K Q2M6IFRlZCBIYXJkaWU7IEN1bGxlbiBKZW5uaW5nczsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtcnRj d2ViLWF1ZGlvDQoNCkkgd2FzIHJlZmVycmluZyB0byBBVVRPVk9OIGxpa2UgaW1wbGVtZW50YXRp b25zIG9mIG9mIE1MUFAsIHdoaWNoIHVzZSBEVE1GIHRvbmUgQSB0aHJvdWdoIEQgZm9yIHByaW9y aXR5Lg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBTdW4s IERlYyAyMCwgMjAxNSBhdCA2OjU0IEFNLCBEUkFHRSwgS2VpdGggKEtlaXRoKSA8a2VpdGguZHJh Z2VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5j b20+PiB3cm90ZToNCkZvciBwcmlvcml0eSwgUS45NTUuMyBkb2VzIG5vdCBzcGVjaWZ5IHRoZSB1 c2Ugb2YgYW55IGtleSBzZXF1ZW5jZXMgZm9yIHN1cHBvcnQgb2YgdGhlIHNlcnZpY2UuIFEuOTU1 LjMgaXMgdGhlIElTRE4gRFNTMSBzaWduYWxsaW5nIHNwZWNpZmljYXRpb24gYW5kIGRvZXMgbm90 IHVzZSBEVE1GLiBGdXJ0aGVyIGl0IGlzIGEgZnVuY3Rpb25hbCBzaWduYWxpbmcgc3lzdGVtLCBp LmUuIGFueSBrZXkgcHJlc3NlcyBhcmUgaWRlbnRpZmllZCBpbiB0aGUgdGVybWluYWwgYW5kIGNv bnZlcnRlZCBpbnRvIHJlYWwgc2lnbmFscywgc3VjaCBhcyDigJxmbGFzaCBvdmVycmlkZeKAnS4N Cg0KSSBhc3N1bWUgeW91IGFyZSByZWZlcnJpbmcgdG8gc29tZSBwcm9wcmlldGFyeSBQU1ROIGVx dWl2YWxlbnQuDQoNCknigJlkIG5vdGUgdGhhdCB0aGUgUFNUTiBlcXVpdmFsZW50IGNvZGVzIG9y aWdpbmFsbHkgc3BlY2lmaWVkIGJ5IENFUFQgYW5kIHByb3ZpZGVkIGluIGFuIEVUU0kgVFIgZm9y IG90aGVyIHNlcnZpY2VzIGRvIG5vdCB1c2UgQSB0aHJvdWdoIEQsIHBlcmZvcm1pbmcgYWxsIHNl cXVlbmNlIHNlcGFyYXRvcnMgYW5kIHRlcm1pbmF0aW9ucyB3aXRoIOKAnCrigJ0gYW5kIOKAnCPi gJ0uIFRoZXJlIGlzIG5vdCBhbiBFVFNJIHZlcnNpb24gb2YgTUxQUC4NCg0KUmVnYXJkcw0KDQpL ZWl0aCBEcmFnZQ0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hw b3VudA0KU2VudDogMTggRGVjZW1iZXIgMjAxNSAyMzoyNA0KVG86IFRlZCBIYXJkaWUNCkNjOiBD dWxsZW4gSmVubmluZ3M7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtydGN3ZWJdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1p ZXRmLXJ0Y3dlYi1hdWRpbw0KDQpPbiBGcmksIERlYyAxOCwgMjAxNSBhdCA1OjIyIFBNLCBUZWQg SGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+IHdy b3RlOg0KDQrigItTb3JyeSB0aGF0IHRoaXMgd2FzIG5vdCBjbGVhcjsgSSBtZWFudCBzcGVjaWZp Y2FsbHkgQS1ELuKAiw0KDQpPZmZlci9hbnN3ZXIgdGVsZXBob25lIGV2ZW50IG5lZ290aWF0aW9u IGlzIG5vcm1hbGx5IGJ5IGRpcmVjdGlvbmFsLiBUaGlzIG5vcm1hbGx5IGVuYWJsZWQgRFRNRiBk ZXRlY3Rpb24gaW4gUFNUTiBnYXRld2F5cy4gU28sIGlmIHlvdSBoYXZlIGFueSBzeXN0ZW0gdGhh dCBjb25uZWN0cyBXZWJSVEMgY2xpZW50IHRvIFBTVE4gbmV0d29yaywgYW5kIGlmIHRoZSBwZXJz b24gb24gUFNUTiBuZXR3b3JrIHdpbGwgcHJlc3MgYSBrZXlwYWQgZGlnaXQsIHRoaXMgZGlnaXQg d2lsbCBiZSBzZW50IHRvIFdlYlJUQyBjbGllbnQuIEZ1cnRoZXJtb3JlLCBpdCBpcyBjb21tb24g Zm9yIERUTUYgZGlnaXQgZGV0ZWN0aW9uIHRvIGJlIGNhdXNlZCBieSB0YWxrIG9mZiwgaS5lLiBz b21lIHZvaWNlIHBlcmlvZGljYWxseSB0cmlnZ2VycyBEVE1GIGRldGVjdGlvbi4gRmluYWxseSwg c29tZSBnYXRld2F5cyB3aWxsIGFsc28gc2VuZCBBTlMgdG9uZXMgaWYgdGhlIGNhbGwgaGl0cyBh IGZheCBtYWNoaW5lLCBzbyBXZWJSVEMgZW5kIHBvaW50IHdpbGwgZ2V0IG5vdCBvbmx5IERUTUYg ZXZlbnRzLCBidXQgZXZlbnRzIGZvciB0b25lIHRoYXQgc29tZW9uZSBqdXN0IGhhcHBlbmVkIHRv IGVuYWJsZSBvbiB0aGUgZ2F0ZXdheS4gVW5sZXNzIHdlIHdhbnQgdG8gdHJhbnNjb2RlIG1lZGlh IGNvbWluZyBmcm9tIFBTVE4sIFdlYlJUQyBjbGllbnQgd2lsbCBuZWVkIHRvIGRlYWwgd2l0aCBh bnkgaW5jb21pbmcgdGVsZXBob25lLWV2ZW50cy4gQWxsIG9mIHRoaXMgYmVpbmcgc2FpZCwgaXQg aXMgdXAgdG8gV2ViUlRDIGNsaWVudCB0byBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIHRoZSByZWNl aXZlZCBldmVudHMuIEkgYW0gZmluZSB3aXRoIHRoZXNlIHRvbmVzIGJlaW5nIGRpc2NhcmQgYXMg bG9uZyBhcyB0aGV5IGFyZSBiZWluZyBkaXNjYXJkZWQgaW4gYSBtYW5uZXIgd2hpY2ggZG9lcyBu b3QgZGlzcnVwdCBub3JtYWwgYXVkaW8gcHJvY2Vzc2luZy4NCg0K4oCLVGhpcyBzZWVtcyB0byBy ZXN1bHQgaW4gZXhhY3RseSB0aGUgY2FzZSBDdWxsZW4gd2FzIGNvbmNlcm5lZCBhYm91dDsgaWYg dGhleSBtYXkgYmUgZGlzY2FyZGVkIHRoZWlyIGZ1bmN0aW9uYWxpdHkgcmVtYWlucyBjb21wbGV0 ZWx5IHVucmVsaWFibGUu4oCLICBCdXQgbW9yZSB0byB0aGUgcG9pbnQsIHlvdSBhcmUgbm90IHBv aW50aW5nIHRvIHVzZXMgb2YgQS1ELCBidXQgbnVtYmVyIGRldGVjdGlvbiBhbmQgZXZlbnRzIHdo aWNoIHdvdWxkIHN0aWxsIGJlIGNvdmVyZWQuDQoNClRoaXMgaXMgY29tcGxldGVseSB1bnJlbGF0 ZWQuIFRoaXMgYXBwbGllcyB0byBhbGwgRFRNRiB0b25lcywgbm90IEEtRCBzcGVjaWZpY2FsbHku IFdoYXQgSSBhbSBzYXlpbmcgaXMgdGhhdCBXZWJSVEMgZW5kcG9pbnRzIG11c3QgYmUgYWJsZSB0 byBnZW5lcmF0ZSBhbGwgRFRNRiB0b25lcyBpbmNsdWRpbmcgQS1EIGFuZCBzZW5kIHRoZW0gdG8g bGVnYWN5IFBTVE4gKGdhdGV3YXkpLiBMZWdhY3kgUFNUTiB3aWxsIHJlY2VpdmUgYW5kIGhhbmRs ZSB0aGVtLiBJZiBsZWdhY3kgUFNUTiAoZ2F0ZXdheSkgc2VuZHMgRFRNRiB0b25lcyB0byBXZWJS VEMgZW5kIHBvaW50IChhbmQgaXQgd2lsbCwgZXZlbiB0aG91Z2ggdGhleSBhcmUgbm90IGV4cGVj dGVkIHRoZXJlKSwgV2ViUlRDIGVuZHBvaW50IGNhbiBkaXNjYXJkIHRoZW0sIGFzIGxvbmcgYXMg aXQgZG9lcyBpdCBuaWNlbHkuDQoNCg0K4oCLV2hpbGUgdGhpcyBpcyBubyBkb3VidCBub3QgeW91 ciBpbnRlbnQsIEkgbXVzdCBzYXkgeW91ciBtZXNzYWdlIHJlYWRzIGFzICJTdXJlIGl0J3MgYnJv a2VuIG5vdywgYnV0IHdlIG11c3QgbWFrZSBzdXJlIGl0IHJlbWFpbnMgYnJva2VuIHRvIGJlIGJh Y2t3YXJkcyBjb21wYXRpYmxlLiLigIsNCg0KTXkgaW50ZW50IGlzIHRoYXQgdGhlcmUgaXMgYW4g ZXhpc3Rpbmcgd2VsbCB1bmRlcnN0b29kIGZ1bmN0aW9uYWxpdHkgc2V0IHdpdGggaXRzIGJlbmVm aXRzICh3aWRlIHN1cHBvcnQpIGFuZCBmYXVsdHMgKHVucmVsaWFiaWxpdHkpLiBUaGlzIGZ1bmN0 aW9uYWxpdHkgc2V0IGlzIGNhbGxlZCBEVE1GLiBXaHkgV2ViUlRDIG5lZWRzIHRvIHJlZGVmaW5l IHRoaXMgc2V0IGlzIGJleW9uZCBteSB1bmRlcnN0YW5kaW5nLg0KDQrigItUaGUgb25seSBBLUQg dG9uZSBpbiB0aGUgb25lIGV4YW1wbGUgeW91IGdhdmUgKGVjaG9saW5rKSB3YXMgdG8gcHVsbCB1 cCBhIGRpZmZlcmVudCBzdG9yZWQgY29uZmlndXJhdGlvbi4NCg0KU28sIG9uZSBvdXQgb2YgZm91 ciB0b25lcyBpcyB1c2VkIGluIHRoaXMgZXhhbXBsZS4NCg0KRFRNRiB0b25lIEEtRCBhcmUgdXNl ZCB0byBwcm92aWRlIHByaW9yaXRpemVkIGNhbGwgaGFuZGxpbmcgc2VydmljZSBpbiBJVFUgUS45 NTUuMyBzcGVjaWZpY2F0aW9uIHdoaWNoIGlzIHN0aWxsIHVzZWQgYnkgc29tZSBQQlggYW5kIHBo b25lIHN5c3RlbXMuDQoNCg0K4oCLQWdhaW4sIG5vdCBhdCBhbGwgY2xlYXIgdGhhdCBhIFdlYlJU QyBjbGllbnQgd291bGQgZXZlciBleHBlY3QgdG8gdXNlIHRoZXNlIGZlYXR1cmVzIG9mIGEgUEJY Lg0KDQpUaGVyZSBhcmUgaW50cmFuZXQgV2ViUlRDIGFwcGxpY2F0aW9ucyB0aGF0IGFjY2VzcyBp bi1jb21wYW55IGxlZ2FjeSBQQlggdmlhIGEgcHJpdmF0ZSBnYXRld2F5Lg0KDQrigItBbmQgdGhl eSBhcmUgdXNpbmcgdGhlIEEtRCBzZXQ/DQoNClllcywgdGhleSBhcmUgdXNpbmcgQS1EIHNldCB0 byBwcm92aWRlIHByaW9yaXR5IGRpYWxpbmcuDQoNCkZpbmFsbHksIHNvbWUgY2FsbGluZyBjYXJk IGxpa2Ugc3lzdGVtcyBhbGxvdyByZW1vdGUgY29udHJvbCBvZiBmdW5jdGlvbnMgc3VjaCBhcyBm bGFzaCBieSBtYXBwaW5nIHRoZW0gdG8gZXh0ZW5kZWQgRFRNRiB0b25lcy4NCg0KDQrigItJZiB0 aGVyZSBpcyBhIGNhbGxpbmcgY2FyZCBzeXN0ZW0gdXNpbmcgV2ViUlRDLCBJIGhhdmUgbm90IGhl YXJkIG9mIGl0LiAgQ2FuIHlvdSBwcm92aWRlIGEgcG9pbnRlcj/igIsNCg0KT25jZSBhZ2Fpbiwg dGhpcyB3b3VsZCBiZSBhIHByaXZhdGUgV2ViUlRDIGFwcGxpY2F0aW9uIHVzZWQgdG8gcGxhY2Ug Y2FsbHMgdGhyb3VnaCBhIGdhdGV3YXkgd2hpY2ggaXMgdW5kZXIgY29udHJvbCBvZiB0aGUgcGVy c29uIHdobyBkZXZlbG9wZXIgdGhlIGFwcC4NCg0KDQrigItTbyB0aGlzIGlzIHRoZW9yZXRpY2Fs LuKAiw0KDQpUaGlzIGlzIHJlYWwgd2l0aCBleGlzdGluZyBTSVAgaW50ZXJmYWNlIGJlaW5nIHJl cGxhY2VkIGJ5IFdlYlJUQy4NCg0K4oCLUmVtb3ZpbmcgdGhlbSBmcm9tIHRoZSBzZXQgZG9lcyBh cyB3ZWxsLCBhdCBsZWFzdCBhcyBmYXIgYXMgSSBjYW4gdGVsbC4gIE5vIG9uZSBoYXMgc3VnZ2Vz dGVkIHRoYXQgdGhleSBiZSB0aGUgc3ViamVjdCBvZiBkaXNjb3Zlcnkgb3IgbmVnb3RpYXRpb24u 4oCLDQoNCkFuZCB0aGVuIHRoZXkgd2lsbCBiZSBhZGRlZCBiYWNrIGJ5IHNvbWUgdmVuZG9yIHdo byBnb3QgYSBjcml0aWNhbCBjdXN0b21lciB3aG8gaXMgdXNpbmcgdGhlc2UgdG9uZXMgZm9yIHNv bWV0aGluZy4NCg0KRGVzcGl0ZSBtYW55IHdvcmRzIGV4Y2hhbmdlZCwgSSB0aGluayBvdXIgZW50 aXJlIGFyZ3VtZW50IGNhbiBiZSBib2lsZWQgZG93biB0byAibGV0J3MgcmVtb3ZlIHRoZXNlIHRv bmVzIHNpbmNlIHRoZXkgc29tZXRpbWVzIGRvIG5vdCB3b3JrIGFuZCB0aGV5IGFyZSB1Z2x5IiB2 cyAibGV0J3Mga2VlcCB0aGVzZSB0b25lcyBzaW5jZSB0aGV5IGFyZSBzb21ldGltZXMgdXNlZCBh bmQgZG8gd29yayBvbiBvY2Nhc2lvbi4iDQoNClAuUy4gSSBoYXZlIHByb3Bvc2VkIHNldmVyYWwg b3RoZXIgdGhpbmdzIGluIGFkZGl0aW9uIHRvIHRvbmVzIEEtRC4gQXJlIHRoZXJlIGFueSBjb21t ZW50cyByZWdhcmRpbmcgYWRkaW5nIHRoZSBmb2xsb3dpbmc6DQoNCkdlbmVyYXRlZCBldmVudHMg TVVTVCBoYXZlIGR1cmF0aW9uIG9mIG5vIG1vcmUgdGhhbiA2MDAwIG1zIGFuZCBubyBsZXNzIHRo YW4gNDAgbXMgd2l0aCB0aGUgcmVjb21tZW5kZWQgZGVmYXVsdCBkdXJhdGlvbiBvZiAxMDAgbXMg Zm9yIGVhY2ggdG9uZS4gVGhlIGdhcCBiZXR3ZWVuIGV2ZW50cyBNVVNUIGJlIG5vIGxlc3MgdGhl biAzMCBtcyB3aXRoIHRoZSByZWNvbW1lbmRlZCBkZWZhdWx0IGR1cmF0aW9uIG9mIDcwIG1zLiBF dmVudCBTSE9VTEQgc3RhcnQgb24gYSByZWd1bGFyIGF1ZGlvIHBhY2tldCBib3JkZXIuIEV2ZW50 IGFuZCBnYXAgZHVyYXRpb24gU0hPVUxEIGJlIHJvdW5kZWQgdXAgdG8gdGhlIG5leHQgcmVndWxh ciBhdWRpbyBwYWNrZXQgYm9yZGVyLg0KDQpEdXJpbmcgdGhlIHRpbWUgZXZlbnRzIGFyZSBnZW5l cmF0ZWQgYXVkaW8gU0hPVUxEIE5PVCBiZSBzZW50IGZvciB0aGUgc2FtZSBhdWRpbyBzdHJlYW0u IFdoZW4gZ2FwcyBiZXR3ZWVuIGV2ZW50cyBhcmUgZ2VuZXJhdGVkLCBzaWxlbmNlIGFuZCBub3Qg dGhlIGJhY2tncm91bmQgYXVkaW8gU0hPVUxEIGJlIHNlbnQgdXNpbmcgcmVndWxhciBhdWRpbyBl bmNvZGluZy4NCg0KSWYgbXVsdGlwbGUgYXVkaW8gc2FtcGxpbmcgcmF0ZXMgYXJlIHN1cHBvcnRl ZCwgYXVkaW8vdGVsZXBob25lLWV2ZW50IHBheWxvYWQgU0hPVUxEIGJlIHByZXNlbnQgZm9yIGVh Y2ggc3VwcG9ydGVkIHNhbXBsaW5nIHJhdGUuIEVuZHBvaW50cyBTSE9VTEQgdXNlIGF1ZGlvL3Rl bGVwaG9uZS1ldmVudCBmb3JtYXQgcGFyYW1ldGVycyBkdXJpbmcgdGhlIG9mZmVyL2Fuc3dlciBl eGNoYW5nZSB0byBpbmRpY2F0ZSB3aGljaCBldmVudHMgYXJlIHN1cHBvcnRlZC4NCg0KUmVjZWl2 ZXJzIE1VU1QgYmUgYWJsZSB0byBjb25zdW1lIGFueSBhdWRpby90ZWxlcGhvbmUtZXZlbnQgZXZl bnRzIGluIHN1Y2ggYSB3YXkgdGhhdCBpdCB3aWxsIG5vdCBnZW5lcmF0ZSBhdWRpbyBhcnRpZmFj dHMsIHVuZXhwZWN0ZWQgcGFja2V0IGxvc3MgY29uY2VhbG1lbnQsIGppdHRlciBidWZmZXIgYWRq dXN0bWVudHMsIHBheWxvYWQgbWlzbWF0Y2hlcywgb3IgaW52YWxpZCBSVENQIHN0YXRpc3RpY3Mg Y2FsY3VsYXRpb24uIFJlY2VpdmVycyBNQVkgZ2VuZXJhdGUgYXVkaW8gY29ycmVzcG9uZGluZyB0 byB0aGUgcmVjZWl2ZWQgZXZlbnRzIGJ1dCBhcmUgYWxzbyBhbGxvd2VkIHRvIGRpc2NhcmQgdGhl bSBpbiBhIG1hbm5lciB0aGF0IGRvZXMgbm90IGFmZmVjdCByZWd1bGFyIGF1ZGlvIHByb2Nlc3Np bmcuDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0K --_000_949EF20990823C4C85C18D59AA11AD8BADE27108FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGFzIEkgaW5kaWNh dGVkLCB0aGF0IGlzIGEgcHJvcHJpZXRhcnkgaW1wbGVtZW50aW9uLCBhbmQgbm90aGluZyB3aGF0 c29ldmVyIHRvIGRvIHdpdGggUS45NTUuMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG8gbm90IGtub3cgd2hhdCBp cyBpbiBhbGwgdGhlIE5BUiBzdGFuZGFyZHMsIGJ1dCBJIGFtIHByZXR0eSBjZXJ0YWluIHRoZXJl IGlzIG5vIHN0YW5kYXJkaXplZCB1c2FnZSAoaS5lLiByZXByZXNlbnRlZCBpbiBhIHB1Ymxpc2hl ZCBzdGFuZGFyZCkgZWl0aGVyIGdsb2JhbGx5DQogb3IgaW4gRXVyb3BlLCBpbiByZXNwZWN0IG9m IEEgdGhyb3VnaCBEIHVzYWdlLiBJbmRlZWQgbWF5IHNpZ25hbGluZyBzY2hlbWVzIHVzaW5nIERU TUYgZG8gbm90IGV2ZW4gZGVmaW5lIHRoZWlyIHVzYWdlIChGLjIzIGFuZCBRLjIzIGFsbG9jYXRl IHRoZSB0b25lcyBidXQgZXNzZW50aWFsbHkgbGVhdmUgdGhlIGV4dHJhIGNvbWJpbmF0aW9ucyBy ZXNlcnZlZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JZiB3ZSBhcmUgZ29pbmcgdG8gc3RhdGUgdXNlIGNhc2VzLCBJ IHdvdWxkIHByZWZlciB0byBrZWVwIHRoZW0gYWNjdXJhdGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3RlIHRoYXQg V2lraXBlZGlhIGluZGljYXRlcyB0aGF0IHRoZSBBVVRPVk9OIHVzZSBjYXNlIGlzIG5vdyBvYnNv bGV0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPknigJlkIGFsc28gbm90ZSB0aGF0IHNvbWUgb2YgdGhlc2UgYXJndW1l bnRzIGFib3V0IHVzZSBjYXNlcyBzZWVtIHRvIGJlIGdvaW5nIGludG8gc2VuZGluZyBEVE1GIHRv IHdlYnJ0YyBlbmRwb2ludCwgd2hpY2ggd291bGQgc2VlbSB0byBicmluZyB1cyBpbnRvIHVzZSBj YXNlcw0KIG9mIHdlYlJUQyBnYXRld2F5IHRvIHdlYlJUQyBnYXRld2F5IHNpZ25hbGluZywgd2hp Y2ggYXQgbGVhc3QgaXMgbm90IGNvdmVyZWQgaW4gb3VyIGN1cnJlbnQgZ2F0ZXdheXMgZG9jdW1l bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LZWl0aDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9tYW4g U2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIx IERlY2VtYmVyIDIwMTUgMTk6NTI8YnI+DQo8Yj5Ubzo8L2I+IERSQUdFLCBLZWl0aCAoS2VpdGgp PGJyPg0KPGI+Q2M6PC9iPiBUZWQgSGFyZGllOyBDdWxsZW4gSmVubmluZ3M7IHJ0Y3dlYkBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV29ya2luZyBncm91cCBsYXN0 IGNhbGwgZm9yIGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyByZWZlcnJpbmcgdG8gQVVUT1ZPTiBsaWtlIGlt cGxlbWVudGF0aW9ucyBvZiBvZiBNTFBQLCB3aGljaCB1c2UgRFRNRiB0b25lIEEgdGhyb3VnaCBE IGZvciBwcmlvcml0eS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlJlZ2FyZHMsPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBE ZWMgMjAsIDIwMTUgYXQgNjo1NCBBTSwgRFJBR0UsIEtlaXRoIChLZWl0aCkgJmx0OzxhIGhyZWY9 Im1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5r ZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIHByaW9yaXR5LCBRLjk1NS4zIGRvZXMgbm90 IHNwZWNpZnkgdGhlIHVzZSBvZiBhbnkga2V5IHNlcXVlbmNlcyBmb3Igc3VwcG9ydCBvZiB0aGUg c2VydmljZS4gUS45NTUuMw0KIGlzIHRoZSBJU0ROIERTUzEgc2lnbmFsbGluZyBzcGVjaWZpY2F0 aW9uIGFuZCBkb2VzIG5vdCB1c2UgRFRNRi4gRnVydGhlciBpdCBpcyBhIGZ1bmN0aW9uYWwgc2ln bmFsaW5nIHN5c3RlbSwgaS5lLiBhbnkga2V5IHByZXNzZXMgYXJlIGlkZW50aWZpZWQgaW4gdGhl IHRlcm1pbmFsIGFuZCBjb252ZXJ0ZWQgaW50byByZWFsIHNpZ25hbHMsIHN1Y2ggYXMg4oCcZmxh c2ggb3ZlcnJpZGXigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhc3N1bWUgeW91IGFyZSByZWZlcnJpbmcg dG8gc29tZSBwcm9wcmlldGFyeSBQU1ROIGVxdWl2YWxlbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQg bm90ZSB0aGF0IHRoZSBQU1ROIGVxdWl2YWxlbnQgY29kZXMgb3JpZ2luYWxseSBzcGVjaWZpZWQg YnkgQ0VQVCBhbmQgcHJvdmlkZWQgaW4gYW4gRVRTSSBUUiBmb3INCiBvdGhlciBzZXJ2aWNlcyBk byBub3QgdXNlIEEgdGhyb3VnaCBELCBwZXJmb3JtaW5nIGFsbCBzZXF1ZW5jZSBzZXBhcmF0b3Jz IGFuZCB0ZXJtaW5hdGlvbnMgd2l0aCDigJwq4oCdIGFuZCDigJwj4oCdLiBUaGVyZSBpcyBub3Qg YW4gRVRTSSB2ZXJzaW9uIG9mIE1MUFAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPktlaXRoIERyYWdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb21hbiBTaHBvdW50PGJy Pg0KPGI+U2VudDo8L2I+IDE4IERlY2VtYmVyIDIwMTUgMjM6MjQ8YnI+DQo8Yj5Ubzo8L2I+IFRl ZCBIYXJkaWU8YnI+DQo8Yj5DYzo8L2I+IEN1bGxlbiBKZW5uaW5nczsgPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZv ciBkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g RnJpLCBEZWMgMTgsIDIwMTUgYXQgNToyMiBQTSwgVGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRlZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItTb3JyeSB0aGF0IHRoaXMgd2FzIG5vdCBjbGVh cjsgSSBtZWFudCBzcGVjaWZpY2FsbHkgQS1ELuKAizwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PZmZlci9hbnN3 ZXIgdGVsZXBob25lIGV2ZW50IG5lZ290aWF0aW9uIGlzIG5vcm1hbGx5IGJ5IGRpcmVjdGlvbmFs LiBUaGlzIG5vcm1hbGx5IGVuYWJsZWQgRFRNRiBkZXRlY3Rpb24gaW4gUFNUTiBnYXRld2F5cy4g U28sIGlmIHlvdSBoYXZlIGFueSBzeXN0ZW0gdGhhdCBjb25uZWN0cyBXZWJSVEMgY2xpZW50DQog dG8gUFNUTiBuZXR3b3JrLCBhbmQgaWYgdGhlIHBlcnNvbiBvbiBQU1ROIG5ldHdvcmsgd2lsbCBw cmVzcyBhIGtleXBhZCBkaWdpdCwgdGhpcyBkaWdpdCB3aWxsIGJlIHNlbnQgdG8gV2ViUlRDIGNs aWVudC4gRnVydGhlcm1vcmUsIGl0IGlzIGNvbW1vbiBmb3IgRFRNRiBkaWdpdCBkZXRlY3Rpb24g dG8gYmUgY2F1c2VkIGJ5IHRhbGsgb2ZmLCBpLmUuIHNvbWUgdm9pY2UgcGVyaW9kaWNhbGx5IHRy aWdnZXJzIERUTUYgZGV0ZWN0aW9uLiBGaW5hbGx5LA0KIHNvbWUgZ2F0ZXdheXMgd2lsbCBhbHNv IHNlbmQgQU5TIHRvbmVzIGlmIHRoZSBjYWxsIGhpdHMgYSBmYXggbWFjaGluZSwgc28gV2ViUlRD IGVuZCBwb2ludCB3aWxsIGdldCBub3Qgb25seSBEVE1GIGV2ZW50cywgYnV0IGV2ZW50cyBmb3Ig dG9uZSB0aGF0IHNvbWVvbmUganVzdCBoYXBwZW5lZCB0byBlbmFibGUgb24gdGhlIGdhdGV3YXku IFVubGVzcyB3ZSB3YW50IHRvIHRyYW5zY29kZSBtZWRpYSBjb21pbmcgZnJvbSBQU1ROLCBXZWJS VEMgY2xpZW50DQogd2lsbCBuZWVkIHRvIGRlYWwgd2l0aCBhbnkgaW5jb21pbmcgdGVsZXBob25l LWV2ZW50cy4gQWxsIG9mIHRoaXMgYmVpbmcgc2FpZCwgaXQgaXMgdXAgdG8gV2ViUlRDIGNsaWVu dCB0byBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIHRoZSByZWNlaXZlZCBldmVudHMuIEkgYW0gZmlu ZSB3aXRoIHRoZXNlIHRvbmVzIGJlaW5nIGRpc2NhcmQgYXMgbG9uZyBhcyB0aGV5IGFyZSBiZWlu ZyBkaXNjYXJkZWQgaW4gYSBtYW5uZXIgd2hpY2ggZG9lcyBub3QgZGlzcnVwdA0KIG5vcm1hbCBh dWRpbyBwcm9jZXNzaW5nLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPuKAi1RoaXMgc2VlbXMgdG8gcmVzdWx0IGluIGV4YWN0bHkgdGhlIGNhc2UgQ3VsbGVuIHdh cyBjb25jZXJuZWQgYWJvdXQ7IGlmIHRoZXkgbWF5IGJlIGRpc2NhcmRlZCB0aGVpciBmdW5jdGlv bmFsaXR5IHJlbWFpbnMgY29tcGxldGVseQ0KIHVucmVsaWFibGUu4oCLJm5ic3A7IEJ1dCBtb3Jl IHRvIHRoZSBwb2ludCwgeW91IGFyZSBub3QgcG9pbnRpbmcgdG8gdXNlcyBvZiBBLUQsIGJ1dCBu dW1iZXIgZGV0ZWN0aW9uIGFuZCBldmVudHMgd2hpY2ggd291bGQgc3RpbGwgYmUgY292ZXJlZC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo aXMgaXMgY29tcGxldGVseSB1bnJlbGF0ZWQuIFRoaXMgYXBwbGllcyB0byBhbGwgRFRNRiB0b25l cywgbm90IEEtRCBzcGVjaWZpY2FsbHkuIFdoYXQgSSBhbSBzYXlpbmcgaXMgdGhhdCBXZWJSVEMg ZW5kcG9pbnRzIG11c3QgYmUgYWJsZSB0byBnZW5lcmF0ZSBhbGwgRFRNRiB0b25lcyBpbmNsdWRp bmcgQS1EDQogYW5kIHNlbmQgdGhlbSB0byBsZWdhY3kgUFNUTiAoZ2F0ZXdheSkuIExlZ2FjeSBQ U1ROIHdpbGwgcmVjZWl2ZSBhbmQgaGFuZGxlIHRoZW0uIElmIGxlZ2FjeSBQU1ROIChnYXRld2F5 KSBzZW5kcyBEVE1GIHRvbmVzIHRvIFdlYlJUQyBlbmQgcG9pbnQgKGFuZCBpdCB3aWxsLCBldmVu IHRob3VnaCB0aGV5IGFyZSBub3QgZXhwZWN0ZWQgdGhlcmUpLCBXZWJSVEMgZW5kcG9pbnQgY2Fu IGRpc2NhcmQgdGhlbSwgYXMgbG9uZyBhcyBpdCBkb2VzIGl0DQogbmljZWx5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi1doaWxlIHRoaXMgaXMgbm8gZG91 YnQgbm90IHlvdXIgaW50ZW50LCBJIG11c3Qgc2F5IHlvdXIgbWVzc2FnZSByZWFkcyBhcyAmcXVv dDtTdXJlIGl0J3MgYnJva2VuIG5vdywgYnV0IHdlIG11c3QgbWFrZSBzdXJlIGl0IHJlbWFpbnMN CiBicm9rZW4gdG8gYmUgYmFja3dhcmRzIGNvbXBhdGlibGUuJnF1b3Q74oCLPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+TXkgaW50ZW50IGlzIHRoYXQgdGhlcmUgaXMgYW4gZXhpc3Rpbmcg d2VsbCB1bmRlcnN0b29kIGZ1bmN0aW9uYWxpdHkgc2V0IHdpdGggaXRzIGJlbmVmaXRzICh3aWRl IHN1cHBvcnQpIGFuZCBmYXVsdHMgKHVucmVsaWFiaWxpdHkpLiBUaGlzIGZ1bmN0aW9uYWxpdHkg c2V0IGlzIGNhbGxlZCBEVE1GLiBXaHkNCiBXZWJSVEMgbmVlZHMgdG8gcmVkZWZpbmUgdGhpcyBz ZXQgaXMgYmV5b25kIG15IHVuZGVyc3RhbmRpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+4oCLVGhlIG9ubHkgQS1EIHRvbmUgaW4gdGhlIG9uZSBleGFtcGxlIHlvdSBnYXZlIChl Y2hvbGluaykgd2FzIHRvIHB1bGwgdXAgYSBkaWZmZXJlbnQgc3RvcmVkIGNvbmZpZ3VyYXRpb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28sIG9uZSBv dXQgb2YgZm91ciB0b25lcyBpcyB1c2VkIGluIHRoaXMgZXhhbXBsZS4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EVE1GIHRvbmUgQS1EIGFy ZSB1c2VkIHRvIHByb3ZpZGUgcHJpb3JpdGl6ZWQgY2FsbCBoYW5kbGluZyBzZXJ2aWNlIGluIElU VSBRLjk1NS4zIHNwZWNpZmljYXRpb24gd2hpY2ggaXMgc3RpbGwgdXNlZCBieSBzb21lIFBCWCBh bmQgcGhvbmUgc3lzdGVtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ 4oCLQWdhaW4sIG5vdCBhdCBhbGwgY2xlYXIgdGhhdCBhIFdlYlJUQyBjbGllbnQgd291bGQgZXZl ciBleHBlY3QgdG8gdXNlIHRoZXNlIGZlYXR1cmVzIG9mIGEgUEJYLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgYXJlIGludHJhbmV0 IFdlYlJUQyBhcHBsaWNhdGlvbnMgdGhhdCBhY2Nlc3MgaW4tY29tcGFueSBsZWdhY3kgUEJYIHZp YSBhIHByaXZhdGUgZ2F0ZXdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPuKAi0FuZCB0aGV5IGFyZSB1c2luZyB0aGUgQS1EIHNldD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlllcywgdGhleSBhcmUgdXNp bmcgQS1EIHNldCB0byBwcm92aWRlIHByaW9yaXR5IGRpYWxpbmcuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZpbmFsbHksIHNvbWUgY2Fs bGluZyBjYXJkIGxpa2Ugc3lzdGVtcyBhbGxvdyByZW1vdGUgY29udHJvbCBvZiBmdW5jdGlvbnMg c3VjaCBhcyBmbGFzaCBieSBtYXBwaW5nIHRoZW0gdG8gZXh0ZW5kZWQgRFRNRiB0b25lcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItJZiB0aGVyZSBp cyBhIGNhbGxpbmcgY2FyZCBzeXN0ZW0gdXNpbmcgV2ViUlRDLCBJIGhhdmUgbm90IGhlYXJkIG9m IGl0LiZuYnNwOyBDYW4geW91IHByb3ZpZGUgYSBwb2ludGVyP+KAizwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25jZSBhZ2FpbiwgdGhpcyB3 b3VsZCBiZSBhIHByaXZhdGUgV2ViUlRDIGFwcGxpY2F0aW9uIHVzZWQgdG8gcGxhY2UgY2FsbHMg dGhyb3VnaCBhIGdhdGV3YXkgd2hpY2ggaXMgdW5kZXIgY29udHJvbCBvZiB0aGUgcGVyc29uIHdo byBkZXZlbG9wZXIgdGhlIGFwcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij7igItTbyB0aGlzIGlzIHRoZW9yZXRpY2FsLuKAizwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBpcyByZWFsIHdpdGgg ZXhpc3RpbmcgU0lQIGludGVyZmFjZSBiZWluZyByZXBsYWNlZCBieSBXZWJSVEMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+4oCLUmVtb3ZpbmcgdGhlbSBmcm9tIHRoZSBzZXQgZG9lcyBhcyB3 ZWxsLCBhdCBsZWFzdCBhcyBmYXIgYXMgSSBjYW4gdGVsbC4mbmJzcDsgTm8gb25lIGhhcyBzdWdn ZXN0ZWQgdGhhdCB0aGV5IGJlIHRoZSBzdWJqZWN0IG9mIGRpc2NvdmVyeQ0KIG9yIG5lZ290aWF0 aW9uLuKAizwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5B bmQgdGhlbiB0aGV5IHdpbGwgYmUgYWRkZWQgYmFjayBieSBzb21lIHZlbmRvciB3aG8gZ290IGEg Y3JpdGljYWwgY3VzdG9tZXIgd2hvIGlzIHVzaW5nIHRoZXNlIHRvbmVzIGZvciBzb21ldGhpbmcu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5EZXNwaXRlIG1hbnkgd29yZHMgZXhjaGFuZ2VkLCBJIHRoaW5rIG91ciBlbnRpcmUgYXJndW1l bnQgY2FuIGJlIGJvaWxlZCBkb3duIHRvICZxdW90O2xldCdzIHJlbW92ZSB0aGVzZSB0b25lcyBz aW5jZSB0aGV5IHNvbWV0aW1lcyBkbyBub3Qgd29yayBhbmQgdGhleSBhcmUgdWdseSZxdW90OyB2 cyAmcXVvdDtsZXQncyBrZWVwIHRoZXNlDQogdG9uZXMgc2luY2UgdGhleSBhcmUgc29tZXRpbWVz IHVzZWQgYW5kIGRvIHdvcmsgb24gb2NjYXNpb24uJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QLlMuIEkgaGF2ZSBwcm9wb3Nl ZCBzZXZlcmFsIG90aGVyIHRoaW5ncyBpbiBhZGRpdGlvbiB0byB0b25lcyBBLUQuIEFyZSB0aGVy ZSBhbnkgY29tbWVudHMgcmVnYXJkaW5nIGFkZGluZyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HZW5lcmF0ZWQgZXZlbnRz IE1VU1QgaGF2ZSBkdXJhdGlvbiBvZiBubyBtb3JlIHRoYW4gNjAwMCBtcyBhbmQgbm8gbGVzcyZu YnNwO3RoYW4gNDAgbXMgd2l0aCB0aGUgcmVjb21tZW5kZWQgZGVmYXVsdCBkdXJhdGlvbiBvZiAx MDAgbXMgZm9yIGVhY2ggdG9uZS4gVGhlIGdhcCBiZXR3ZWVuIGV2ZW50cyBNVVNUIGJlDQogbm8g bGVzcyB0aGVuIDMwIG1zIHdpdGggdGhlIHJlY29tbWVuZGVkJm5ic3A7ZGVmYXVsdCBkdXJhdGlv biBvZiA3MCBtcy4gRXZlbnQgU0hPVUxEIHN0YXJ0IG9uIGEgcmVndWxhciBhdWRpbyBwYWNrZXQm bmJzcDtib3JkZXIuIEV2ZW50IGFuZCBnYXAgZHVyYXRpb24gU0hPVUxEIGJlIHJvdW5kZWQgdXAg dG8gdGhlIG5leHQgcmVndWxhciZuYnNwO2F1ZGlvIHBhY2tldCBib3JkZXIuPGJyPg0KPGJyPg0K RHVyaW5nIHRoZSB0aW1lIGV2ZW50cyBhcmUgZ2VuZXJhdGVkIGF1ZGlvIFNIT1VMRCBOT1QgYmUg c2VudCBmb3IgdGhlIHNhbWUmbmJzcDthdWRpbyBzdHJlYW0uIFdoZW4gZ2FwcyBiZXR3ZWVuIGV2 ZW50cyBhcmUgZ2VuZXJhdGVkLCBzaWxlbmNlJm5ic3A7YW5kIG5vdCB0aGUgYmFja2dyb3VuZCBh dWRpbyBTSE9VTEQgYmUgc2VudCB1c2luZyByZWd1bGFyIGF1ZGlvIGVuY29kaW5nLjxicj4NCjxi cj4NCklmIG11bHRpcGxlIGF1ZGlvIHNhbXBsaW5nIHJhdGVzIGFyZSBzdXBwb3J0ZWQsIGF1ZGlv L3RlbGVwaG9uZS1ldmVudCBwYXlsb2FkJm5ic3A7U0hPVUxEIGJlIHByZXNlbnQgZm9yIGVhY2gg c3VwcG9ydGVkIHNhbXBsaW5nIHJhdGUuIEVuZHBvaW50cyBTSE9VTEQgdXNlJm5ic3A7YXVkaW8v dGVsZXBob25lLWV2ZW50IGZvcm1hdCBwYXJhbWV0ZXJzIGR1cmluZyB0aGUgb2ZmZXIvYW5zd2Vy IGV4Y2hhbmdlIHRvIGluZGljYXRlIHdoaWNoIGV2ZW50cyBhcmUgc3VwcG9ydGVkLjxicj4NCjxi cj4NClJlY2VpdmVycyBNVVNUIGJlIGFibGUgdG8gY29uc3VtZSBhbnkgYXVkaW8vdGVsZXBob25l LWV2ZW50IGV2ZW50cyZuYnNwO2luIHN1Y2ggYSB3YXkgdGhhdCBpdCB3aWxsIG5vdCBnZW5lcmF0 ZSBhdWRpbyBhcnRpZmFjdHMsIHVuZXhwZWN0ZWQgcGFja2V0IGxvc3MgY29uY2VhbG1lbnQsIGpp dHRlciBidWZmZXIgYWRqdXN0bWVudHMsIHBheWxvYWQgbWlzbWF0Y2hlcywmbmJzcDtvciBpbnZh bGlkIFJUQ1Agc3RhdGlzdGljcyBjYWxjdWxhdGlvbi4gUmVjZWl2ZXJzDQogTUFZIGdlbmVyYXRl IGF1ZGlvJm5ic3A7Y29ycmVzcG9uZGluZyB0byB0aGUgcmVjZWl2ZWQgZXZlbnRzIGJ1dCBhcmUg YWxzbyBhbGxvd2VkIHRvIGRpc2NhcmQmbmJzcDt0aGVtIGluIGEgbWFubmVyIHRoYXQgZG9lcyBu b3QgYWZmZWN0IHJlZ3VsYXIgYXVkaW8gcHJvY2Vzc2luZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fXzxicj4N ClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADE27108FR712WXCHMBA11z_-- From nobody Mon Dec 21 15:28:05 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB111ACE7B for ; Mon, 21 Dec 2015 15:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Bq58lYsrh5 for ; Mon, 21 Dec 2015 15:28:03 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE311ACE7A for ; Mon, 21 Dec 2015 15:28:03 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id ph11so48664196igc.1 for ; Mon, 21 Dec 2015 15:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dNMa+oSKC20QjLHFO2AeT7y5tI/3hy/TocQrWPdyv2k=; b=WrXce9oM3c9yaqkRSP73nZDZDyY6CLYkWUUsO6jZxB8kiuNquWEa3wsgKQiFHd3BHK ya4hqaAeL+/RqA7TrqFl31Og20/GRO2+EOMt2UYccNZybZyVt3gC2jhfvYeM4mC5Wvgd 46ex1/7+3UCOqwW1F1BAk7FXwGMdKnteFQLnlbzb/nfs5uoWNipFmaWCgp1UF9p710xk HUjawtYry92y1e1tWDM68WMHJUbITbVigh0yKMRC6TXNB/BwCxh+E/JrWRJ8pOOLc2Or 2ieZNPLwbnE4x4867tSMVTF3IjEuaSSUA3DU//apQAfJ9sM9psMBHV1j7sTbHc/e7ocj 5vTQ== MIME-Version: 1.0 X-Received: by 10.50.20.8 with SMTP id j8mr22128518ige.94.1450740482921; Mon, 21 Dec 2015 15:28:02 -0800 (PST) Received: by 10.36.149.130 with HTTP; Mon, 21 Dec 2015 15:28:02 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE27108@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADE2686D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADE27108@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 22 Dec 2015 10:28:02 +1100 Message-ID: From: Martin Thomson To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 23:28:04 -0000 On 22 December 2015 at 10:25, DRAGE, Keith (Keith) wrote: > I=E2=80=99d also note that some of these arguments about use cases seem t= o be going > into sending DTMF to webrtc endpoint, which would seem to bring us into u= se > cases of webRTC gateway to webRTC gateway signaling, which at least is no= t > covered in our current gateways document. I don't believe that there is any plan to have browsers accept DTMF, if anyone was considering that possibility. From nobody Mon Dec 21 15:46:55 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA381ACE9C for ; Mon, 21 Dec 2015 15:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB6o1Bkg8FxT for ; Mon, 21 Dec 2015 15:46:52 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850A21ACE9A for ; Mon, 21 Dec 2015 15:46:52 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id e126so170686935ioa.1 for ; Mon, 21 Dec 2015 15:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pxyVBUUNHF15yYcdMHmzTIeB4tcJTCE1y8CHSrAgilg=; b=sRUYV23yDHrEMR+ix3T9/T2mXNoryKUeEmp5YUs3grwIMRNgivF38EZuj1sMI683u9 P8/pcYcw1gSLHntP46Cev5g6zvcfTNRBiqRXkCfXJRzCQCS+WqU/Rm2CNVlhkN3YNAjj BerAA84RyMf3dXf5WO5YTMG9ezUQ9WkFMKNE+9tVa5G9dpC3q9cFH8837uXvV7i9TtbG qeV6kcFTFLU+ntAtAhSr2dfjZ+M11SygdCXy1eBenzUqAqbIDxGo39VOc+sDa23ok86Q xQFCduUQjyVdXnmpEu2FBFjwd3VS7kBPM33dTDs/HUo1qQAzvKEcsbCRisJMR9cO2RBf PTzA== 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=pxyVBUUNHF15yYcdMHmzTIeB4tcJTCE1y8CHSrAgilg=; b=CEkg6bMHltvAXkzvcj97GA+dqr2J5qQhXky/zmB3cXZbs6GXuqX1lMTCuzjHcwf2x0 JYrbAnNsnfbt07Xuw0JIiJipcKyyMWetzFA4ActiiD+H3hd+s4uYF4Cy5Ts0/4teCh6v HTkfooowKhcK2Hp+pr6V/6sLYyQ45kWDcm3vHnLf7rjFgm9f1KE8/H9pD6n2bzxt+oAd aDMj1/Pcywdgl+w9MEp229R/9P4HZSY9m7tQG/Hnn5O7+4+XzDd2Nhhl7P9F/5DnSUES Yb28ABxzChAtcJlbMi4oHsF+xZ3r3Y6DpaI5bDwIHCLbSTuRhZZLPrnqlL2nCGJlmwA5 quZA== X-Gm-Message-State: ALoCoQkS4dMbl+HvhaEf6mtB4cnafXTpTm4ffFdWXuaLU7bTxzp/sidKeskecpxbelft0n9bqn8xRQ0VKzkOhmOrG+Qz67ZHlA== X-Received: by 10.107.166.78 with SMTP id p75mr20992164ioe.59.1450741611880; Mon, 21 Dec 2015 15:46:51 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id qr1sm9131369igb.21.2015.12.21.15.46.49 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Dec 2015 15:46:50 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id mv3so40394814igc.0 for ; Mon, 21 Dec 2015 15:46:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.114.3 with SMTP id jc3mr14266059igb.2.1450741609245; Mon, 21 Dec 2015 15:46:49 -0800 (PST) Received: by 10.36.105.15 with HTTP; Mon, 21 Dec 2015 15:46:49 -0800 (PST) In-Reply-To: References: <949EF20990823C4C85C18D59AA11AD8BADE2686D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADE27108@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 21 Dec 2015 18:46:49 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0153844847b5790527711abd Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 23:46:54 -0000 --089e0153844847b5790527711abd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 21, 2015 at 6:28 PM, Martin Thomson wrote: > On 22 December 2015 at 10:25, DRAGE, Keith (Keith) > wrote: > > I=E2=80=99d also note that some of these arguments about use cases seem= to be > going > > into sending DTMF to webrtc endpoint, which would seem to bring us into > use > > cases of webRTC gateway to webRTC gateway signaling, which at least is > not > > covered in our current gateways document. > > I don't believe that there is any plan to have browsers accept DTMF, > if anyone was considering that possibility. > All I wrote, and I am not sure how to state this any clearer, that since offer/answer normally negotiates codecs in both direction, PSTN gateways will send RFC 4733 tones to WebRTC endpoints. WebRTC endpoints should be able to receive and safely discard them. This is completely unrelated to A-D tones and should cover all telephone-events. P.S. Does anyone have any comments regarding the rest of the text that I proposed? I would think it is much more important then A-D tone support. _____________ Roman Shpount --089e0153844847b5790527711abd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 21, 2015 at 6:2= 8 PM, Martin Thomson <martin.thomson@gmail.com> wrote= :
On 22 December 2015 at 10:25, DRAGE, Keith (Keith) <keit= h.drage@alcatel-lucent.com> wrote:
> I=E2=80=99d also note that some of these arguments about use cases see= m to be going
> into sending DTMF to webrtc endpoint, which would seem to bring us int= o use
> cases of webRTC gateway to webRTC gateway signaling, which at least is= not
> covered in our current gateways document.

I don't believe that there is any plan to have browsers accept D= TMF,
if anyone was considering that possibility.

All I wrote, and I = am not sure how to state this any clearer, that since offer/answer normally= negotiates codecs in both direction, PSTN gateways will send RFC 4733 tone= s to WebRTC endpoints. WebRTC endpoints should be able to receive and safel= y discard them. This is completely unrelated to A-D tones and should cover = all telephone-events.

P.S. Does anyone have any comments regarding the rest of t= he text that I proposed? I would think it is much more important then A-D t= one support.
_____________
Roman Shpount
=

--089e0153844847b5790527711abd-- From nobody Mon Dec 21 16:15:49 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B761ACEBF for ; Mon, 21 Dec 2015 16:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYJStolIid3t for ; Mon, 21 Dec 2015 16:15:45 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314471ACE7F for ; Mon, 21 Dec 2015 16:15:45 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 186so173407972iow.0 for ; Mon, 21 Dec 2015 16:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Js7uBABxnkgGP8zFZJ86C+wFJumcGYRS7dwCp1mo+eA=; b=mh9SBBfsXUCMPb2YBkJ0qkupSbnaTxa4U6PbzFsxC7Nk9FpuwdvkbLCkZAewVU48Ao FetZyEARHSTgxId0rDfnTd2/S4cRSFS4+A4gzvH5JQW0lmBaKHq7A/+aaE/R+3JB5jZ8 0JYVpGsgj1UpBOclKhzi8fQV58j022Ee+6C+zVR7gSeG4uJsiGKObTJzNPKw/4eGvOA8 kQS1Nbu/H2WOyVH18Bignr057wpurvVQnLwqhRX9O79NTS5HuTzGgezHqtuCkXaccW04 jRBQIB2hgWUHeAh2RXGIjcfojjxBIgc0DrKN4DfpN8/fp1376kSZPOvf/si9R6g/reqc AMRQ== 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:content-type; bh=Js7uBABxnkgGP8zFZJ86C+wFJumcGYRS7dwCp1mo+eA=; b=lMEWmH+Ll9xWxCU2hGOLExXrpiJBCHlkgLRwOrTUxVpT+9P2BTW88YaceWebnE6NQP 7gus59XtbzA9ILtkN+VLxAf9C82KKxtSuAI1qanb/fFhpEJvkVCJacY3ereO87gc6Qii 8Q276B2g3CF2MT5uBp0uJWEn3lT/jTl6OgXa5keZ1dTs8OI1sDxBaCtz/pnZR4+d89JF TQF8nPbAINQkGv5aeJYv/6VFRcT6ABPoQkzyAZsBIl+/0sn2HNiICHi1pHQ8jPFuQNu8 5Hq4e4gIT85rbY33i/utrrvlhE0kF7/hYiz1lG1pBnPslLK1VMf/GWB9oUdXF003tmuC WAxw== X-Gm-Message-State: ALoCoQniyURRd0+PmAiVQTV00sishj+bqix5ibpY9VSpCR+XdFxFiGonP9iBDvkv+Xmsij52aAQwubowuRY8z9eO4tb3USbBug== X-Received: by 10.107.25.81 with SMTP id 78mr24131987ioz.127.1450743344586; Mon, 21 Dec 2015 16:15:44 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id 39sm4996684iom.25.2015.12.21.16.15.43 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Dec 2015 16:15:43 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id jw2so47370711igc.1 for ; Mon, 21 Dec 2015 16:15:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.124.9 with SMTP id me9mr21455950igb.24.1450743342657; Mon, 21 Dec 2015 16:15:42 -0800 (PST) Received: by 10.36.105.15 with HTTP; Mon, 21 Dec 2015 16:15:42 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Dec 2015 19:15:42 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0111c356997c1f05277181b2 Archived-At: Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 00:15:46 -0000 --089e0111c356997c1f05277181b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also, some might find interesting what ham radio receivers typically look like: http://img3.ph.126.net/snBYUz0aHL9x7Fy2mh85MA=3D=3D/1133499731230960393.jpg and here is the microphone at higher resolution: http://i.ebayimg.com/images/i/371238765810-0-1/s-l1000.jpg As you can see it is designed to send A-D tones. _____________ Roman Shpount On Fri, Dec 18, 2015 at 8:12 PM, Roman Shpount wrote: > On Fri, Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > >> >> On Dec 18, 2015, at 3:24 PM, Roman Shpount wrote: >> >> This applies to all DTMF tones, not A-D specifically. What I am saying i= s >> that WebRTC endpoints must be able to generate all DTMF tones including = A-D >> and send them to legacy PSTN (gateway). >> >> >> The thing people keep asking is why? what is the use case ? >> >> I don=E2=80=99t feel like I have seen an answer to this. >> >> > Because there are IVR systems that use them. They are much less common > then IVR systems that use 0-9 * and # but they do exist. I have provided = 4 > examples of real IVR systems that use these tones. How many do you need t= o > keep the extra tones? All these systems can probably be re-engineered not > to use A-D tones, but since this is all legacy no one will spend the time= . > > Your argument that these tones should be removed since they are sometimes > blocked (When exactly? The only places I see them blocked are some > international carriers) and would not work. The same applies to all DTMF > tones. We should remove all telephone-events based on this logic. > > Most importantly I do not want optional tones. So, if we decide to remove > A-D, they should not be allowed in the WebRTC API. If these tones are > allowed in WebRTC API, everyone must implement them. > _____________ > Roman Shpount > > --089e0111c356997c1f05277181b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Also, some might find interesting what ham radio receivers= typically look like:

ht= tp://i.ebayimg.com/images/i/371238765810-0-1/s-l1000.jpg

=
As you can see it is designed to send A-D tones.
_____________
Roman Shpou= nt

On Fri, Dec 18, 2015 at 8:12 PM, Roman Shpou= nt <roman@telurix.com> wrote:
On Fri= , Dec 18, 2015 at 7:10 PM, Cullen Jennings (fluffy) <<= a href=3D"mailto:fluffy@cisco.com" target=3D"_blank">fluffy@cisco.com&g= t; wrote:

On Dec 18, 2015, at 3:24 PM, Roman Shpount <roman@telurix.com> wrote:

This applies to all DTMF tones, not A-D specifically. What I am saying is that = WebRTC endpoints must be able to generate all DTMF tones including A-D and = send them to legacy PSTN (gateway).

The thing people keep asking is why? what is the use case ?

I don=E2=80=99t feel like I have seen an answer to this.=C2=A0


Because t= here are IVR systems that use them. They are much less common then IVR syst= ems that use 0-9 * and # but they do exist. I have provided 4 examples of r= eal IVR systems that use these tones. How many do you need to keep the extr= a tones? All these systems can probably be re-engineered not to use A-D ton= es, but since this is all legacy no one will spend the time.=C2=A0

Your argument that these tones should be removed since the= y are sometimes blocked (When exactly? The only places I see them blocked a= re some international carriers) and would not work. The same applies to all= DTMF tones. We should remove all telephone-events based on this logic.

Most importantly I do not want optional tones. So, if= we decide to remove A-D, they should not be allowed in the WebRTC API. If = these tones are allowed in WebRTC API, everyone must implement them.
<= div>
_____________
Roman Sh= pount
=C2=A0

--089e0111c356997c1f05277181b2-- From nobody Mon Dec 21 16:24:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377C71ACEC8 for ; Mon, 21 Dec 2015 16:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtjgvxcG78V8 for ; Mon, 21 Dec 2015 16:24:29 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5561A6F84 for ; Mon, 21 Dec 2015 16:24:28 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 93E96A9C35A15; Tue, 22 Dec 2015 00:24:22 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tBM0OQrE002337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Dec 2015 01:24:26 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 22 Dec 2015 01:24:26 +0100 From: "DRAGE, Keith (Keith)" To: Roman Shpount , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Working group last call for draft-ietf-rtcweb-audio Thread-Index: AQHRPE3k0JZd2tvJAUGJKJJIm+7DEZ7WJQYA Date: Tue, 22 Dec 2015 00:24:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE271B9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADE271B9FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 00:24:32 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADE271B9FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIHRoZSBvbmx5IHdheSBJIGNhbiBpbnRlcnByZXQgdGhpcyBhcyBhIHVzZSBjYXNlIGlzIHdo ZXJlIHRoZSBoYW0gcmFkaW8gcmVtb3RlIHBvaW50IGlzIGFsc28gdGhlIHdlYnJ0YyBlbmRwb2lu dC4gSXMgdGhhdCB3aGF0IHlvdSBhcmUgcHJvcG9zaW5nPw0KDQpLZWl0aA0KDQpGcm9tOiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFuIFNo cG91bnQNClNlbnQ6IDIyIERlY2VtYmVyIDIwMTUgMDA6MTYNClRvOiBydGN3ZWJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQt aWV0Zi1ydGN3ZWItYXVkaW8NCg0KQWxzbywgc29tZSBtaWdodCBmaW5kIGludGVyZXN0aW5nIHdo YXQgaGFtIHJhZGlvIHJlY2VpdmVycyB0eXBpY2FsbHkgbG9vayBsaWtlOg0KDQpodHRwOi8vaW1n My5waC4xMjYubmV0L3NuQllVejBhSEw5eDdGeTJtaDg1TUE9PS8xMTMzNDk5NzMxMjMwOTYwMzkz LmpwZw0KDQphbmQgaGVyZSBpcyB0aGUgbWljcm9waG9uZSBhdCBoaWdoZXIgcmVzb2x1dGlvbjoN Cg0KaHR0cDovL2kuZWJheWltZy5jb20vaW1hZ2VzL2kvMzcxMjM4NzY1ODEwLTAtMS9zLWwxMDAw LmpwZw0KDQpBcyB5b3UgY2FuIHNlZSBpdCBpcyBkZXNpZ25lZCB0byBzZW5kIEEtRCB0b25lcy4N Cl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gRnJpLCBEZWMgMTgsIDIwMTUgYXQg ODoxMiBQTSwgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRl bHVyaXguY29tPj4gd3JvdGU6DQpPbiBGcmksIERlYyAxOCwgMjAxNSBhdCA3OjEwIFBNLCBDdWxs ZW4gSmVubmluZ3MgKGZsdWZmeSkgPGZsdWZmeUBjaXNjby5jb208bWFpbHRvOmZsdWZmeUBjaXNj by5jb20+PiB3cm90ZToNCg0KT24gRGVjIDE4LCAyMDE1LCBhdCAzOjI0IFBNLCBSb21hbiBTaHBv dW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToN Cg0KVGhpcyBhcHBsaWVzIHRvIGFsbCBEVE1GIHRvbmVzLCBub3QgQS1EIHNwZWNpZmljYWxseS4g V2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IFdlYlJUQyBlbmRwb2ludHMgbXVzdCBiZSBhYmxlIHRv IGdlbmVyYXRlIGFsbCBEVE1GIHRvbmVzIGluY2x1ZGluZyBBLUQgYW5kIHNlbmQgdGhlbSB0byBs ZWdhY3kgUFNUTiAoZ2F0ZXdheSkuDQoNClRoZSB0aGluZyBwZW9wbGUga2VlcCBhc2tpbmcgaXMg d2h5PyB3aGF0IGlzIHRoZSB1c2UgY2FzZSA/DQoNCkkgZG9u4oCZdCBmZWVsIGxpa2UgSSBoYXZl IHNlZW4gYW4gYW5zd2VyIHRvIHRoaXMuDQoNCg0KQmVjYXVzZSB0aGVyZSBhcmUgSVZSIHN5c3Rl bXMgdGhhdCB1c2UgdGhlbS4gVGhleSBhcmUgbXVjaCBsZXNzIGNvbW1vbiB0aGVuIElWUiBzeXN0 ZW1zIHRoYXQgdXNlIDAtOSAqIGFuZCAjIGJ1dCB0aGV5IGRvIGV4aXN0LiBJIGhhdmUgcHJvdmlk ZWQgNCBleGFtcGxlcyBvZiByZWFsIElWUiBzeXN0ZW1zIHRoYXQgdXNlIHRoZXNlIHRvbmVzLiBI b3cgbWFueSBkbyB5b3UgbmVlZCB0byBrZWVwIHRoZSBleHRyYSB0b25lcz8gQWxsIHRoZXNlIHN5 c3RlbXMgY2FuIHByb2JhYmx5IGJlIHJlLWVuZ2luZWVyZWQgbm90IHRvIHVzZSBBLUQgdG9uZXMs IGJ1dCBzaW5jZSB0aGlzIGlzIGFsbCBsZWdhY3kgbm8gb25lIHdpbGwgc3BlbmQgdGhlIHRpbWUu DQoNCllvdXIgYXJndW1lbnQgdGhhdCB0aGVzZSB0b25lcyBzaG91bGQgYmUgcmVtb3ZlZCBzaW5j ZSB0aGV5IGFyZSBzb21ldGltZXMgYmxvY2tlZCAoV2hlbiBleGFjdGx5PyBUaGUgb25seSBwbGFj ZXMgSSBzZWUgdGhlbSBibG9ja2VkIGFyZSBzb21lIGludGVybmF0aW9uYWwgY2FycmllcnMpIGFu ZCB3b3VsZCBub3Qgd29yay4gVGhlIHNhbWUgYXBwbGllcyB0byBhbGwgRFRNRiB0b25lcy4gV2Ug c2hvdWxkIHJlbW92ZSBhbGwgdGVsZXBob25lLWV2ZW50cyBiYXNlZCBvbiB0aGlzIGxvZ2ljLg0K DQpNb3N0IGltcG9ydGFudGx5IEkgZG8gbm90IHdhbnQgb3B0aW9uYWwgdG9uZXMuIFNvLCBpZiB3 ZSBkZWNpZGUgdG8gcmVtb3ZlIEEtRCwgdGhleSBzaG91bGQgbm90IGJlIGFsbG93ZWQgaW4gdGhl IFdlYlJUQyBBUEkuIElmIHRoZXNlIHRvbmVzIGFyZSBhbGxvd2VkIGluIFdlYlJUQyBBUEksIGV2 ZXJ5b25lIG11c3QgaW1wbGVtZW50IHRoZW0uDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50 DQoNCg0K --_000_949EF20990823C4C85C18D59AA11AD8BADE271B9FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGlj YTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCB0aGUgb25seSB3YXkgSSBj YW4gaW50ZXJwcmV0IHRoaXMgYXMgYSB1c2UgY2FzZSBpcyB3aGVyZSB0aGUgaGFtIHJhZGlvIHJl bW90ZSBwb2ludCBpcyBhbHNvIHRoZSB3ZWJydGMgZW5kcG9pbnQuIElzIHRoYXQgd2hhdCB5b3Ug YXJlIHByb3Bvc2luZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYW4gU2hw b3VudDxicj4NCjxiPlNlbnQ6PC9iPiAyMiBEZWNlbWJlciAyMDE1IDAwOjE2PGJyPg0KPGI+VG86 PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpbzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgc29tZSBtaWdodCBm aW5kIGludGVyZXN0aW5nIHdoYXQgaGFtIHJhZGlvIHJlY2VpdmVycyB0eXBpY2FsbHkgbG9vayBs aWtlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6 Ly9pbWczLnBoLjEyNi5uZXQvc25CWVV6MGFITDl4N0Z5Mm1oODVNQT09LzExMzM0OTk3MzEyMzA5 NjAzOTMuanBnIj5odHRwOi8vaW1nMy5waC4xMjYubmV0L3NuQllVejBhSEw5eDdGeTJtaDg1TUE9 PS8xMTMzNDk5NzMxMjMwOTYwMzkzLmpwZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIGhlcmUgaXMgdGhlIG1pY3JvcGhvbmUgYXQg aGlnaGVyIHJlc29sdXRpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9pLmViYXlpbWcuY29tL2ltYWdlcy9pLzM3 MTIzODc2NTgxMC0wLTEvcy1sMTAwMC5qcGciPmh0dHA6Ly9pLmViYXlpbWcuY29tL2ltYWdlcy9p LzM3MTIzODc2NTgxMC0wLTEvcy1sMTAwMC5qcGc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHlvdSBjYW4gc2VlIGl0IGlzIGRlc2ln bmVkIHRvIHNlbmQgQS1EIHRvbmVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIERl YyAxOCwgMjAxNSBhdCA4OjEyIFBNLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBEZWMgMTgsIDIwMTUgYXQg NzoxMCBQTSwgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1 ZmZ5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZsdWZmeUBjaXNjby5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBEZWMgMTgsIDIwMTUsIGF0IDM6MjQgUE0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhy ZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVy aXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGlzIGFwcGxpZXMgdG8gYWxsIERU TUYgdG9uZXMsIG5vdCBBLUQgc3BlY2lmaWNhbGx5LiBXaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQg V2ViUlRDIGVuZHBvaW50cyBtdXN0IGJlIGFibGUgdG8gZ2VuZXJhdGUgYWxsIERUTUYgdG9uZXMg aW5jbHVkaW5nIEEtRCBhbmQgc2VuZCB0aGVtIHRvIGxlZ2FjeQ0KIFBTVE4gKGdhdGV3YXkpLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgdGhpbmcgcGVvcGxlIGtlZXAgYXNraW5nIGlzIHdoeT8gd2hhdCBpcyB0 aGUgdXNlIGNhc2UgPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRvbuKAmXQgZmVlbCBsaWtlIEkgaGF2ZSBzZWVuIGFuIGFuc3dlciB0byB0 aGlzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2Ug dGhlcmUgYXJlIElWUiBzeXN0ZW1zIHRoYXQgdXNlIHRoZW0uIFRoZXkgYXJlIG11Y2ggbGVzcyBj b21tb24gdGhlbiBJVlIgc3lzdGVtcyB0aGF0IHVzZSAwLTkgKiBhbmQgIyBidXQgdGhleSBkbyBl eGlzdC4gSSBoYXZlIHByb3ZpZGVkIDQgZXhhbXBsZXMgb2YgcmVhbCBJVlIgc3lzdGVtcyB0aGF0 IHVzZSB0aGVzZSB0b25lcy4gSG93IG1hbnkgZG8geW91IG5lZWQgdG8ga2VlcCB0aGUgZXh0cmEN CiB0b25lcz8gQWxsIHRoZXNlIHN5c3RlbXMgY2FuIHByb2JhYmx5IGJlIHJlLWVuZ2luZWVyZWQg bm90IHRvIHVzZSBBLUQgdG9uZXMsIGJ1dCBzaW5jZSB0aGlzIGlzIGFsbCBsZWdhY3kgbm8gb25l IHdpbGwgc3BlbmQgdGhlIHRpbWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXIgYXJndW1lbnQgdGhhdCB0aGVzZSB0b25lcyBz aG91bGQgYmUgcmVtb3ZlZCBzaW5jZSB0aGV5IGFyZSBzb21ldGltZXMgYmxvY2tlZCAoV2hlbiBl eGFjdGx5PyBUaGUgb25seSBwbGFjZXMgSSBzZWUgdGhlbSBibG9ja2VkIGFyZSBzb21lIGludGVy bmF0aW9uYWwgY2FycmllcnMpIGFuZCB3b3VsZCBub3Qgd29yay4gVGhlIHNhbWUgYXBwbGllcyB0 byBhbGwgRFRNRiB0b25lcy4gV2Ugc2hvdWxkIHJlbW92ZQ0KIGFsbCB0ZWxlcGhvbmUtZXZlbnRz IGJhc2VkIG9uIHRoaXMgbG9naWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1vc3QgaW1wb3J0YW50bHkgSSBkbyBub3Qgd2FudCBvcHRpb25h bCB0b25lcy4gU28sIGlmIHdlIGRlY2lkZSB0byByZW1vdmUgQS1ELCB0aGV5IHNob3VsZCBub3Qg YmUgYWxsb3dlZCBpbiB0aGUgV2ViUlRDIEFQSS4gSWYgdGhlc2UgdG9uZXMgYXJlIGFsbG93ZWQg aW4gV2ViUlRDIEFQSSwgZXZlcnlvbmUgbXVzdCBpbXBsZW1lbnQgdGhlbS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19f X19fPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NClJvbWFuIFNocG91bnQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADE271B9FR712WXCHMBA11z_-- From nobody Mon Dec 21 16:39:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A51ACDDD for ; Mon, 21 Dec 2015 16:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bKr_HKWiqFS for ; Mon, 21 Dec 2015 16:39:18 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEFF1ACDC1 for ; Mon, 21 Dec 2015 16:39:17 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id o67so171356776iof.3 for ; Mon, 21 Dec 2015 16:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ozk+yQ++Ls74oudJJeaK0LNKlhIODeyVHg2hHHGUPyk=; b=WDnaHm+8w+qnK4orq8WliIIjlD5YiylO1zvsgBrDHS0oolQH6ynE7WxCXEIFpBzJpD GFfhzchiH8ls3v99DeEjDH54k9axeN5MgFOSoITKOqDPeg96iz1w+DY0xnER6LIXoYkX JNT+VaO906s/w5qj5nskVJ7v/XAzKYKfaqmFXMb6iPHyosCKvwMVCdb/DSZe40afiQ8Q gMgLm7UsgnNCbw+G552UyGeVTSjlcu4elBcL9Gbd8DNsoOdy8EjYesUqizycox1g3vTk yicUE6fx3IXwfaTd0qPg8ifzPz9IiBS8aGSkimbuCqVQ7+HB25nHNMSaxvnsg2s5sQIV hSvA== 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=ozk+yQ++Ls74oudJJeaK0LNKlhIODeyVHg2hHHGUPyk=; b=DxmljfHgjudgq0wQi20lDFqqrRr2f+XPjAicccfNLWo0FOVeI/nB3CfXL/HCONkOFK wR/VcxdTV2esn0Sc1hopjx9rhuZOXaTsDYvwotKFnAfrqbLluCM+Wa8EGOayMTjMwDxF X+WmXtgIfS/Mf8fiL0L3DjQzzz9C8ZaFBqUyknMMaeueOSGlfR8VypiHT4ZyZ0qkyMkj qwP8XBskJJl9bdWKbo4lZmW9RAipm6sdY7V6WdEIDTWpKrrlaklae0gE87ziAx3Zcnl5 VSE5zSM6+lhcy5B4+j8DXjO/NuaNVEDFY8udSbVOfNv+s4Kuja7tlsvU54MILHrUton9 pZyw== X-Gm-Message-State: ALoCoQny2nm7sEoyvVBiqOA4jaV7Z1S0h+qCxla9Rx/iTgNnb/8d+8flby+1B18oFmpQwUUoDWNf6e0W3BIDrsOryH6d4GGLtw== X-Received: by 10.107.34.7 with SMTP id i7mr23316764ioi.32.1450744757277; Mon, 21 Dec 2015 16:39:17 -0800 (PST) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id g4sm1193234igt.2.2015.12.21.16.39.15 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Dec 2015 16:39:15 -0800 (PST) Received: by mail-io0-f176.google.com with SMTP id o67so171356128iof.3 for ; Mon, 21 Dec 2015 16:39:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.155.149 with SMTP id d143mr22876385ioe.145.1450744755174; Mon, 21 Dec 2015 16:39:15 -0800 (PST) Received: by 10.36.105.15 with HTTP; Mon, 21 Dec 2015 16:39:15 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE271B9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADE271B9@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 21 Dec 2015 19:39:15 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=001a11409fc2cac4c0052771d5d5 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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 Dec 2015 00:39:18 -0000 --001a11409fc2cac4c0052771d5d5 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 21, 2015 at 7:24 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > And the only way I can interpret this as a use case is where the ham radio > remote point is also the webrtc endpoint. Is that what you are proposing? > > > The usage example is where ham radio microphone is replaced with a gateway to which WebRTC endpoint is connected. WebRTC based application in this example acts as a remote microphone. _____________ Roman Shpount --001a11409fc2cac4c0052771d5d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 21, 2015 at 7:24 PM, DRAGE, Keith (Keith) <k= eith.drage@alcatel-lucent.com> wrote:

And the only way I can interpret this as a u= se case is where the ham radio remote point is also the webrtc endpoint. Is= that what you are proposing?=C2=A0



The usage example is where ham radio microphone is replaced with a gateway= to which WebRTC endpoint is connected. WebRTC based application in this ex= ample acts as a remote microphone.
_____________
Roman Shpount
=C2=A0
--001a11409fc2cac4c0052771d5d5--