From nobody Wed Oct 4 09:29:01 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64C1124F57 for ; Wed, 4 Oct 2017 09:28:59 -0700 (PDT) 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=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpouu8voPTrz for ; Wed, 4 Oct 2017 09:28:58 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674B0132941 for ; Wed, 4 Oct 2017 09:28:58 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id f15so20300467qtf.7 for ; Wed, 04 Oct 2017 09:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2jUjZYY/A/ucOqTU03j3TsZ0pOEkCtWAOCGdwPR8YL0=; b=sHD8KOmbUKea3IL3HXMFRorZTCY56Jz4lYtY6va6sCTUc1SXFdiSzAuiZ29FZbBiC6 ERYmhpXpgc+uWnJBS2DocgbXyAKtB76iEEhWDWmcK5Q+mfVmqviW3bJ2Pr7DEKMNuEWp 3AlwWdCnJcBX77bavq0inHnPGrG2QQzJGsfw7Cdw/0KOmtsjNW2YQqoZrE2Pben61KyS FDsiTJgpUL3f+wnLeSRKeH96Oif7W4RWp32eb+GaAwwoA9ZLLF1+OVaXgEcIaiXuRBEq vZnSSc8/PiF+G9XEzUNjCyUmh2Chi+ukxLaM7L5LVGcwLcTjZ6xWt6a3DQ1QgEzodt6i p2zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2jUjZYY/A/ucOqTU03j3TsZ0pOEkCtWAOCGdwPR8YL0=; b=FPeNZeLJa+kyUDWWRgE2rxVAK9PNuhNWRSGaxER6iHfKHUruqfFl/OsFexUDhaGDrd f1gCu7EAXjT6LjQ7gN22Vf07/YZIZkr266L104Ru7wqDHNu7kCTa1/LUob9tzRBDglqB Hs61aRLGLaz4h8l2M37IzKpLhAstvDcRMgixKfRSKKYDK7T+YliRLh/Xyu7FIXOWpMFF 52iAYY/+6ACyQSsKO3astD77fTxUnyZWEJsoAXB3mjVlAcKFir5Ab40X3G2zbFNMsb6g nsaxOC7J3zI4V4jiqg6X7kUBt/NoXKmU8xfzM9WC8GmowN0kxtDHNsYUZFypD/QeBV2j q5sA== X-Gm-Message-State: AMCzsaWQutlZSSDZxl/Lof929CNPAqa5adzGj0NnoU1rU/xTeg5JnV2A j14lRsHVZrzlnqN8kPxFfe7xSoCQdNJDT2bqhTXVJw== X-Google-Smtp-Source: AOwi7QCcr+bDO8DrZWL56g1/TqqR2OVnwTWYg47LaYBrvPK8+SJ90YbuFRf9bl31gPMf5E3IoSrwZJKl6Z5rkZ1MYqM= X-Received: by 10.200.46.146 with SMTP id h18mr11259219qta.100.1507134537229; Wed, 04 Oct 2017 09:28:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.55.53 with HTTP; Wed, 4 Oct 2017 09:28:26 -0700 (PDT) From: Ted Hardie Date: Wed, 4 Oct 2017 09:28:26 -0700 Message-ID: To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary="001a1142ab48b86c8e055abb1a1f" Archived-At: Subject: [rtcweb] Volunteer needed to review draft-ietf-ice-rfc5245bis-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 16:29:00 -0000 --001a1142ab48b86c8e055abb1a1f Content-Type: text/plain; charset="UTF-8" Howdy, We need a volunteer to review draft-ietf-ice-rfc5245bis-12, specifically to check for any inconsistency with our docs' expected use of ICE. Please let the chairs know if you are willing to volunteer. thanks, Ted, Sean, and Cullen --001a1142ab48b86c8e055abb1a1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

We need a volunteer to = review draft-ietf-ice-rfc5245bis-12, specifically to check for any inconsis= tency with our docs' expected use of ICE.=C2=A0 Please let the chairs k= now if you are willing to volunteer.

thanks,

Ted,= Sean, and Cullen
--001a1142ab48b86c8e055abb1a1f-- From nobody Fri Oct 6 00:09:21 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9349E134472 for ; Fri, 6 Oct 2017 00:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 2g2oA13Bl-43 for ; Fri, 6 Oct 2017 00:09:18 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E87513446C for ; Fri, 6 Oct 2017 00:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5FFD37C0D41; Fri, 6 Oct 2017 09:09:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVh6qHUbB31o; Fri, 6 Oct 2017 09:09:15 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:12:75c4:37b3:5435:ab0]) by mork.alvestrand.no (Postfix) with ESMTPSA id 558CB7C03A2; Fri, 6 Oct 2017 09:09:15 +0200 (CEST) To: Ted Hardie , "rtcweb@ietf.org" , Sean Turner , Cullen Jennings References: From: Harald Alvestrand Message-ID: Date: Fri, 6 Oct 2017 09:09:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E57CD51F8814EFB42A3311D1" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Volunteer needed to review draft-ietf-ice-rfc5245bis-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Oct 2017 07:09:20 -0000 This is a multi-part message in MIME format. --------------E57CD51F8814EFB42A3311D1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/04/2017 06:28 PM, Ted Hardie wrote: > Howdy, > > We need a volunteer to review draft-ietf-ice-rfc5245bis-12, > specifically to check for any inconsistency with our docs' expected > use of ICE.  Please let the chairs know if you are willing to volunteer. I'll take a stab at that. (And yes, I'm back at work now.) > > thanks, > > Ted, Sean, and Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------E57CD51F8814EFB42A3311D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/04/2017 06:28 PM, Ted Hardie wrote:
Howdy,

We need a volunteer to review draft-ietf-ice-rfc5245bis-12, specifically to check for any inconsistency with our docs' expected use of ICE.  Please let the chairs know if you are willing to volunteer.

I'll take a stab at that. (And yes, I'm back at work now.)


thanks,

Ted, Sean, and Cullen


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


--------------E57CD51F8814EFB42A3311D1-- From nobody Fri Oct 6 05:35:15 2017 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 BC7181349A5; Fri, 6 Oct 2017 05:35:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker To: Cc: draft-ietf-rtcweb-jsep.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150729330872.6204.16821957868857533343@ietfa.amsl.com> Date: Fri, 06 Oct 2017 05:35:08 -0700 Archived-At: Subject: [rtcweb] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-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, 06 Oct 2017 12:35:09 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready Given the design constraints in which the protocol operates, it is hard to see how this could be done differently. I have two sets of security concerns. One is that implementations need to be designed so as to avoid buffer overrun conditions and also to prevent such conditions leading to a breach. Compression formats such as are inevitably used in video and image applications tend to make promiscuous use of nested length encoding formats that commonly lead to security vulnerabilities. This document does not have such a warning, having a reference on most of the security issues, a warning on this issue should appear in: https://tools.ietf.org/html/draft-ietf-rtcweb-security-08 The other security concern is that giving control over the host browser to run pretty much arbitrary code was always going to be a security disaster but there isn't much that can be done at this point. From nobody Sat Oct 7 19:22:36 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24981133085; Sat, 7 Oct 2017 19:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tq5hjdexzSLz; Sat, 7 Oct 2017 19:22:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EF6132944; Sat, 7 Oct 2017 19:22:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 51A8F7C3243; Sun, 8 Oct 2017 04:22:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeBkjCEruGCx; Sun, 8 Oct 2017 04:22:12 +0200 (CEST) Received: from [192.168.8.111] (149-222-232.connect.netcom.no [178.232.222.149]) by mork.alvestrand.no (Postfix) with ESMTPSA id 502407C0D41; Sun, 8 Oct 2017 04:22:12 +0200 (CEST) To: Phillip Hallam-Baker , secdir@ietf.org Cc: draft-ietf-rtcweb-jsep.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org References: <150729330872.6204.16821957868857533343@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> Date: Sun, 8 Oct 2017 04:22:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150729330872.6204.16821957868857533343@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Oct 2017 02:22:21 -0000 On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote: > Reviewer: Phillip Hallam-Baker > Review result: Ready > > Given the design constraints in which the protocol operates, it is hard= to see > how this could be done differently. > > I have two sets of security concerns. One is that implementations need = to be > designed so as to avoid buffer overrun conditions and also to prevent s= uch > conditions leading to a breach. Compression formats such as are inevita= bly used > in video and image applications tend to make promiscuous use of nested = length > encoding formats that commonly lead to security vulnerabilities. > > This document does not have such a warning, having a reference on most = of the > security issues, a warning on this issue should appear in: > https://tools.ietf.org/html/draft-ietf-rtcweb-security-08 > > The other security concern is that giving control over the host browser= to run > pretty much arbitrary code was always going to be a security disaster b= ut there > isn't much that can be done at this point. > Participant pushback, I'm neither a WG chair or a document editor: Was this intended as a review of a different document? The concern about compression formats seems to be something that belongs in compression format specifications, such as those referenced by PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security, which pulls in security concerns from a number of fields. The generic concern about running Javascript in the browser seems to belong to rtcweb-overview if it belongs anywhere except in a generic architecture critique of the browser ecosystem. If there are concerns specific to JSEP, and the handling of SDP that is described in JSEP, it seems appropriate to document them here. Generic architectural issues and common security best practices don't seem to have the right home in this document. --=20 Surveillance is pervasive. Go Dark. From nobody Sat Oct 7 20:18:57 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046B4133078; Sat, 7 Oct 2017 20:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x41vmVNkXSAS; Sat, 7 Oct 2017 20:18:52 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB321342E1; Sat, 7 Oct 2017 20:18:52 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id q4so17369091oic.7; Sat, 07 Oct 2017 20:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lx+A0lkljzweP+G5+OilpW8DEDlFKejkf5LHEdXup6c=; b=EESgRA3Zr5kLAXWqC+yQwsPfOv6zirWKbDzo3QrnqaOoou3vcRU1tMkwZNPnBa72p4 RA+gL5Sd1/tCzq+k0P79qgeGgrGSJXGJrneqMY3qlKsZQ1fAYENEpO9FbqPj1g+AQhYT 4oLsg8Di6MeXpWl9+y0je98SnpsTusdzlloyIUsuY5oN1wqNHJWEYVNM6AKOERIDXduc 9tv5htEL9jsFm80qpRkOIe9dkCT2k63R4es+e1T+Cu2ACawQ5/wj/4qxh//+tu7PwyIx QkePZc6yJRjIXYH3sjWWtEsKXG57iKbhIejJmh41GiNzRlQoBJPOeXQ6NWfm5yEnF8s/ gozw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lx+A0lkljzweP+G5+OilpW8DEDlFKejkf5LHEdXup6c=; b=shSaJcsLHad0MIot9AZf+q9XEGB7LrTmf/z0dZkAZSin8fGXc7JMI21Ecif3EEwpMx HBx7ZGbyrlh0pNO+CbNJvmOu2HxmGGV0gkrEHFVKWWPROL5/zyDLa2eL3vZVF6FphVRX NxGlfXQsg5vkc7AvqZi0WtSIlYu+FyJFY/97BeAf0iqWO6qZR68pIpB+kP1VcjJRlJ+S sCblncZMbR05WiJKsM9hEjcAqfQtJySq7BIexK7Y0ll6qfDXk61L09X+h7FV1CquxYWe dMt8meZwbR42tA9gLTGUw8W5hJMMmxvVv3wCjZSuZfIKxQehBYtaDLP60y5T0Od9BmRn 6dFw== X-Gm-Message-State: AMCzsaVuLSMPg4ASTBgeOJER+Ha3D3uBcKQY7m87PL3C3639+cnmZsiN 6DFTkJKqli2/sKF+cnxu+fDBa4TfIxOXGCjXMlk= X-Google-Smtp-Source: AOwi7QAbnhNYHDAyax1uc6/u5Ob0c7PGLUZFc9UY5uEpfoK2MVDTQyq5DshoEjrm2fpXV50JYJYuXJgFs8d+GHRqEgI= X-Received: by 10.157.17.6 with SMTP id g6mr4021245ote.305.1507432731823; Sat, 07 Oct 2017 20:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.80.42 with HTTP; Sat, 7 Oct 2017 20:18:51 -0700 (PDT) In-Reply-To: <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> References: <150729330872.6204.16821957868857533343@ietfa.amsl.com> <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> From: Phillip Hallam-Baker Date: Sat, 7 Oct 2017 23:18:51 -0400 Message-ID: To: Harald Alvestrand Cc: "secdir@ietf.org" , draft-ietf-rtcweb-jsep.all@ietf.org, "rtcweb@ietf.org" , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="001a1146208680d4c9055b00882a" Archived-At: Subject: Re: [rtcweb] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Oct 2017 03:18:55 -0000 --001a1146208680d4c9055b00882a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 7, 2017 at 10:22 PM, Harald Alvestrand wrote: > On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote: > > Reviewer: Phillip Hallam-Baker > > Review result: Ready > > > > Given the design constraints in which the protocol operates, it is hard > to see > > how this could be done differently. > > > > I have two sets of security concerns. One is that implementations need > to be > > designed so as to avoid buffer overrun conditions and also to prevent > such > > conditions leading to a breach. Compression formats such as are > inevitably used > > in video and image applications tend to make promiscuous use of nested > length > > encoding formats that commonly lead to security vulnerabilities. > > > > This document does not have such a warning, having a reference on most > of the > > security issues, a warning on this issue should appear in: > > https://tools.ietf.org/html/draft-ietf-rtcweb-security-08 > > > > The other security concern is that giving control over the host browser > to run > > pretty much arbitrary code was always going to be a security disaster > but there > > isn't much that can be done at this point. > > > Participant pushback, I'm neither a WG chair or a document editor: > > > Was this intended as a review of a different document? > =E2=80=8BNo, I just didn't have any comments on the security considerations= in this one as they are handled in rtcweb-security. and that is the place to address the one addressable concern I did have. The concern about compression formats seems to be something that belongs > in compression format specifications, such as those referenced by > PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security, > which pulls in security concerns from a number of fields. > =E2=80=8BThat is where I suggested it go. =E2=80=8B > The generic concern about running Javascript in the browser seems to > belong to rtcweb-overview if it belongs anywhere except in a generic > architecture critique of the browser ecosystem. > =E2=80=8BI wasn't suggesting a change. Just pointing out that we are dealin= g with the =E2=80=8Battack model in which the attacker has control of a turing com= plete mechanism in the communication channel. Given that one of the authors is a Security AD, just pointing out that is the set of vectors that would cause me most concern. > If there are concerns specific to JSEP, and the handling of SDP that is > described in JSEP, it seems appropriate to document them here. Generic > architectural issues and common security best practices don't seem to > have the right home in this document. > > -- > Surveillance is pervasive. Go Dark. > > > --=20 Website: http://hallambaker.com/ --001a1146208680d4c9055b00882a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Oc= t 7, 2017 at 10:22 PM, Harald Alvestrand <harald@alvestrand.no><= /span> wrote:
On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote:
> Reviewer: Phillip Hallam-Baker
> Review result: Ready
>
> Given the design constraints in which the protocol operates, it is har= d to see
> how this could be done differently.
>
> I have two sets of security concerns. One is that implementations need= to be
> designed so as to avoid buffer overrun conditions and also to prevent = such
> conditions leading to a breach. Compression formats such as are inevit= ably used
> in video and image applications tend to make promiscuous use of nested= length
> encoding formats that commonly lead to security vulnerabilities.
>
> This document does not have such a warning, having a reference on most= of the
> security issues, a warning on this issue should appear in:
> https://tools.ietf.org/html/draft= -ietf-rtcweb-security-08
>
> The other security concern is that giving control over the host browse= r to run
> pretty much arbitrary code was always going to be a security disaster = but there
> isn't much that can be done at this point.
>
Participant pushback, I'm neither a WG chair or a document = editor:


Was this intended as a review of a different document?

=E2= =80=8BNo, I just didn't have any comments on the security consideration= s in this one as they are handled in rtcweb-security. and that is the place= to address the one addressable concern I did have.



The concern about compression formats seems to be something that belongs in compression format specifications, such as those referenced by
PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security,
which pulls in security concerns from a number of fields.
<= div>
=E2=80= =8BThat is where I suggested it go.
=E2=80=8B
The generic concern about running Javascript in the browser seems to
belong to rtcweb-overview if it belongs anywhere except in a generic
architecture critique of the browser ecosystem.

=E2=80=8BI = wasn't suggesting a change. Just pointing out that we are dealing with = the =E2=80=8Battack model in which the attacker has control of a turing com= plete mechanism in the communication channel. Given that one of the authors= is a Security AD, just pointing out that is the set of vectors that would = cause me most concern.

=C2=A0
If there are concerns specific to JSEP, and the handling of SDP that is
described in JSEP, it seems appropriate to document them here. Generic
architectural issues and common security best practices don't seem to have the right home in this document.

--
Surveillance is pervasive. Go Dark.





--
Website= : http://hallambaker.= com/
--001a1146208680d4c9055b00882a-- From nobody Sun Oct 8 00:49:55 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117EF134D51; Sun, 8 Oct 2017 00:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IlRav9wpTFCC; Sun, 8 Oct 2017 00:49:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9032134C42; Sun, 8 Oct 2017 00:49:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 104187C09FC; Sun, 8 Oct 2017 09:49:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ1vgOWDi6_p; Sun, 8 Oct 2017 09:49:41 +0200 (CEST) Received: from [192.168.8.103] (149-222-232.connect.netcom.no [178.232.222.149]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7C38D7C03BD; Sun, 8 Oct 2017 09:49:40 +0200 (CEST) Date: Sun, 08 Oct 2017 09:49:30 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <150729330872.6204.16821957868857533343@ietfa.amsl.com> <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----VFWW9V971VU85Q8MQZY4R6WTQGWAJY" Content-Transfer-Encoding: 7bit To: ietf@ietf.org,Phillip Hallam-Baker CC: draft-ietf-rtcweb-jsep.all@ietf.org, "rtcweb@ietf.org" , IETF Discussion Mailing List , "secdir@ietf.org" From: Harald Alvestrand Message-ID: Archived-At: Subject: Re: [rtcweb] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Oct 2017 07:49:48 -0000 ------VFWW9V971VU85Q8MQZY4R6WTQGWAJY Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, sounds like we're in agreement on what needs to be done to this documen= t based on the review (nothing)=2E Good=2E Den 8=2E oktober 2017 05:18:51 CEST, skrev Phillip Hallam-Baker : >On Sat, Oct 7, 2017 at 10:22 PM, Harald Alvestrand > >wrote: > >> On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote: >> > Reviewer: Phillip Hallam-Baker >> > Review result: Ready >> > >> > Given the design constraints in which the protocol operates, it is >hard >> to see >> > how this could be done differently=2E >> > >> > I have two sets of security concerns=2E One is that implementations >need >> to be >> > designed so as to avoid buffer overrun conditions and also to >prevent >> such >> > conditions leading to a breach=2E Compression formats such as are >> inevitably used >> > in video and image applications tend to make promiscuous use of >nested >> length >> > encoding formats that commonly lead to security vulnerabilities=2E >> > >> > This document does not have such a warning, having a reference on >most >> of the >> > security issues, a warning on this issue should appear in: >> > https://tools=2Eietf=2Eorg/html/draft-ietf-rtcweb-security-08 >> > >> > The other security concern is that giving control over the host >browser >> to run >> > pretty much arbitrary code was always going to be a security >disaster >> but there >> > isn't much that can be done at this point=2E >> > >> Participant pushback, I'm neither a WG chair or a document editor: >> >> >> Was this intended as a review of a different document? >> > >=E2=80=8BNo, I just didn't have any comments on the security consideratio= ns in >this >one as they are handled in rtcweb-security=2E and that is the place to >address the one addressable concern I did have=2E > > > >The concern about compression formats seems to be something that >belongs >> in compression format specifications, such as those referenced by >> PAYLOAD et al=2E As such, it would reasonably belong in >-rtcweb-security, >> which pulls in security concerns from a number of fields=2E >> > >=E2=80=8BThat is where I suggested it go=2E >=E2=80=8B > >> The generic concern about running Javascript in the browser seems to >> belong to rtcweb-overview if it belongs anywhere except in a generic >> architecture critique of the browser ecosystem=2E >> > >=E2=80=8BI wasn't suggesting a change=2E Just pointing out that we are de= aling >with >the =E2=80=8Battack model in which the attacker has control of a turing >complete >mechanism in the communication channel=2E Given that one of the authors >is a >Security AD, just pointing out that is the set of vectors that would >cause >me most concern=2E > > > >> If there are concerns specific to JSEP, and the handling of SDP that >is >> described in JSEP, it seems appropriate to document them here=2E >Generic >> architectural issues and common security best practices don't seem to >> have the right home in this document=2E >> >> -- >> Surveillance is pervasive=2E Go Dark=2E >> >> >> > > >--=20 >Website: http://hallambaker=2Ecom/ --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------VFWW9V971VU85Q8MQZY4R6WTQGWAJY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, sounds like we're in agreement on what nee= ds to be done to this document based on the review (nothing)=2E Good=2E
=
Den 8=2E oktober 2017 05:18:51 CEST, skrev P= hillip Hallam-Baker <hallam@gmail=2Ecom>:

On Sa= t, Oct 7, 2017 at 10:22 PM, Harald Alvestrand <harald@alvestrand=2Eno= > wrote:
On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrot= e:
> Reviewer: Phillip Hallam-Baker
> Review result: Ready
>
> Given the design constraints in which the protocol operates, it is ha= rd to see
> how this could be done differently=2E
>
> I have two sets of security concerns=2E One is that implementations n= eed to be
> designed so as to avoid buffer overrun conditions and also to prevent= such
> conditions leading to a breach=2E Compression formats such as are ine= vitably used
> in video and image applications tend to make promiscuous use of neste= d length
> encoding formats that commonly lead to security vulnerabilities=2E >
> This document does not have such a warning, having a reference on mos= t of the
> security issues, a warning on this issue should appear in:
> https://tools=2Eietf=2Eorg/html/<= wbr />draft-ietf-rtcweb-security-08
>
> The other security concern is that giving control over the host brows= er to run
> pretty much arbitrary code was always going to be a security disaster= but there
> isn't much that can be done at this point=2E
>
Participant pushback, I'm neither a WG chair or a document edi= tor:


Was this intended as a review of a different document?
<= div>
=E2=80=8BNo, I just didn't have any comments on the security consideration= s in this one as they are handled in rtcweb-security=2E and that is the pla= ce to address the one addressable concern I did have=2E



The concern about compression formats seems to be something that belongs in compression format specifications, such as those referenced by
PAYLOAD et al=2E As such, it would reasonably belong in -rtcweb-security,<= br /> which pulls in security concerns from a number of fields=2E

=E2=80=8BThat is where I suggested it go=2E
=E2=80=8B
The generic concern about running Javascript in the browser seems to
belong to rtcweb-overview if it belongs anywhere except in a generic
architecture critique of the browser ecosystem=2E
<= br />
=E2= =80=8BI wasn't suggesting a change=2E Just pointing out that we are dealing= with the =E2=80=8Battack model in which the attacker has control of a turi= ng complete mechanism in the communication channel=2E Given that one of the= authors is a Security AD, just pointing out that is the set of vectors tha= t would cause me most concern=2E

 
If there are concerns specific to JSEP, and the handling of SDP that is described in JSEP, it seems appropriate to document them here=2E Generic architectural issues and common security best practices don't seem to
have the right home in this document=2E

--
Surveillance is pervasive=2E Go Dark=2E





--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------VFWW9V971VU85Q8MQZY4R6WTQGWAJY-- From nobody Mon Oct 9 09:20:29 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187DD134682; Mon, 9 Oct 2017 09:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham autolearn_force=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 AyL24gRmfi2Y; Mon, 9 Oct 2017 09:20:26 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6F2134760; Mon, 9 Oct 2017 09:19:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5A85B7C0E4B; Mon, 9 Oct 2017 18:19:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMhuUexCNjIM; Mon, 9 Oct 2017 18:19:57 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0A6F37C0D41; Mon, 9 Oct 2017 18:19:57 +0200 (CEST) To: "ice@ietf.org" Cc: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no> Date: Mon, 9 Oct 2017 18:19:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------18C28708872D5CF21DF03049" Content-Language: en-US Archived-At: Subject: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Oct 2017 16:20:29 -0000 This is a multi-part message in MIME format. --------------18C28708872D5CF21DF03049 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I have read through draft-ietf-ice-rfc5245bis-12 - both as a generic reviewer and with the perspective of "does this do what RTCWEB requires". I believe this document is good enough to publish, but could be improved somewhat (usually, all documents can). Most important points: * The protocol has been designed and revised to be usable with non-media data, but the introduction and abstract do not reflect this. Expunging the media bias from the body of the document is probably not worth it, but the intro and abstract should mention it. * Security considerations should mention the problem that ICE reveals addresses that might otherwise remain hidden, and that this is a privacy concern. * The document has removed all the SDP specific parts (good), but the requirements it places on the negotiation mechanism aren’t collectively documented anywhere. A section describing this would help comprehension for people developing signalling protocols for use with ICE. * The definition of “component” talks about a component having one address. I believe that in current usage, it should be defined to have an address pair. (non-symmetric RTP is dead). The rest of my suggested changes are nits, I think. I enclose the full text of my review as PDF; apart from the stuff above, I don't think those comments needs much WG discussion. Editor: Please raise issues if you think some do need it! Hope this is helpful. Harald --------------18C28708872D5CF21DF03049 Content-Type: application/pdf; name="ICE BIS rfc5245bis-12 review.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ICE BIS rfc5245bis-12 review.pdf" JVBERi0xLjUKJb/3ov4KMTAgMCBvYmoKPDwgL0xpbmVhcml6ZWQgMSAvTCA4OTU2NyAvSCBb IDcyNiAxNTggXSAvTyAxNCAvRSA0MTI4MCAvTiA1IC9UIDg5MjQwID4+CmVuZG9iagogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK MTEgMCBvYmoKPDwgL1R5cGUgL1hSZWYgL0xlbmd0aCA1OCAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvRGVjb2RlUGFybXMgPDwgL0NvbHVtbnMgNCAvUHJlZGljdG9yIDEyID4+IC9XIFsgMSAy IDEgXSAvSW5kZXggWyAxMCAyMCBdIC9JbmZvIDIxIDAgUiAvUm9vdCAxMiAwIFIgL1NpemUg MzAgL1ByZXYgODkyNDEgICAgICAgICAgICAgICAgIC9JRCBbPDA5ZjBlZWMwNmMwZWMwNzI5 MjY3MzNjYWQ2ODEzNzlkPjwwOWYwZWVjMDZjMGVjMDcyOTI2NzMzY2FkNjgxMzc5ZD5dID4+ CnN0cmVhbQp4nGNiZOBnYGJgOAkkmE6DWMZAgnEeiLsJSCj7AoksGRB3JpDg2AxiaTMwMSbx gRQzMBJBAACyDwZHCmVuZHN0cmVhbQplbmRvYmoKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKMTIgMCBvYmoKPDwgL1BhZ2VzIDIyIDAgUiAv VHlwZSAvQ2F0YWxvZyA+PgplbmRvYmoKMTMgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL1MgNjggL0xlbmd0aCA4MCA+PgpzdHJlYW0KeJxjYGBgAqJrDMwMDFq7GfgZoADMZgaJ MrAsYHimxP0jvYGBgf+B2C2/mDk7LYuKHiDEGBCAHYoZGLUZ+Bn5OrrdO9gefARy2RsYAA2T FLcKZW5kc3RyZWFtCmVuZG9iagoxNCAwIG9iago8PCAvQW5ub3RzIFsgPDwgL0EgPDwgL1Mg L1VSSSAvVHlwZSAvQWN0aW9uIC9VUkkgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTEyKSA+PiAvQm9yZGVyIFsgMCAwIDAgXSAvRiA0 IC9SZWN0IFsgNzIuMDYwNDU1IDc0Mi40MTU2NSAzMjAuNTE4ODkgNzU0LjQyNTY2IF0gL1N1 YnR5cGUgL0xpbmsgL1R5cGUgL0Fubm90ID4+IF0gL0NvbnRlbnRzIDE1IDAgUiAvTWVkaWFC b3ggWyAwIDAgNTk2IDg0MyBdIC9QYXJlbnQgMjIgMCBSIC9SZXNvdXJjZXMgPDwgL0V4dEdT dGF0ZSA8PCAvRzAgMjMgMCBSID4+IC9Gb250IDw8IC9GMCAyNCAwIFIgL0YxIDI3IDAgUiA+ PiAvUHJvY1NldHMgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gPj4g L1R5cGUgL1BhZ2UgPj4KZW5kb2JqCjE1IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggODk2NCA+PgpzdHJlYW0KeJzlnduqJclxhu/7Kfa1wak8H8AYpkczurZp8APY lsAgg+X3B0euXbW7VuX6a2X8uXbPCGtAGvXq+ior8hQZGQf3ZuWff3TyXzWGt3//65f/+dL/ JLUsf+BNS8Wlt7/955d/+4e3/5bfTEk2+1b87bn7/ycPu7f+z7/+6e39X/72ly9/+JN9+8v/ 3pilxTfnfOi4P1/8Scrvr3z8d6Rhtz+yvnz/S7a/8/1f5J1fv335w6/2zUWTU5P/1Ldvf/7i vn+pc/bt21+/CEn+9z/e/skK65/fvv3XF2dNkq8uIon9l+Rvv1TjkjxW6scPMd9+KCb46nz6 /kAFDyT7/g5vvK2l2AMKPuLQD+/t/eXb+7e6p9/qsjellVTKzvBf8x3jubxGhrVB3Y5sam4p hZV2nBk2/npjBONl8MR2+OFn8AMUbfzlcb+6P2qb2WT6eFfrA2kZm8ubCSG8mdqH7t3/nxnB 4TyC49froRKNLa533sQPAaHAkN9EM5Kc1/6AG4XmIZ6gaEzAz3Dg3XAQ4YmLPiM2JBH0cvzh aXuiVptjOnz4T+AJKHVi8ODFDIkdv718f7ttx6X0+IUlH+QewRN34m3u8XdkG783yiIhHvs8 xMdd7sPzN6Amzb05x8MUB+P22KQ7acBX4KEDGote7YA0XAJ/XsCfA04EHCgjOLeRKBwaStsn yGItq6wL7i0Ea4orMXbFhlQ83pft6LMpNrjv33PaR68Q6bzyD88KPefTYzJLT4+Fd0m5Ykpp 6TBV3rtCGlC9TN/UznPe9zkfa07Pf9jm6SPW3rG15BLagfXz/Nd40ddEjIdOm5ejj+6sA743 tok8kkxgP7GRwEUQL9pIa5xW6LaGuyijsbkSGEUKMhQK3QdDOjeHw8cz7TgzLjZQtFXhvRgu duiJbS9WCKF6E6LLK31xRhBdUbOJLuSVRtwT8JxIWdk4b4NJa8N1QOhF5G2RE14LbqUVJ4RN P6HDIz59PBneii8KQf6Cr37hi84IQq5BthEfS1tpxQlxp+VNHot/1rY7OxNSciuj8owgpJeT kYHjVvrwjLjQqj34Ycqi4We2P6iR3vXcjPZsf1XKUs7QfS+JCyNxQOh7NMhgFn1nrRUnBDyS qHWHEJPxOeSFVXBAEDKKzQSZOYxFCiHwGPZg4KGDx1HnuzuEqYVdowkl+IUlZkAQwq7VxJjc yoA8I/DprCpbF200JfajFd26AaGXUbRyHHFtqRH3hItzKj46BLR2Ij0WLuipPTcY3PUbOp07 rRxKEEbmDmb5fDALv8kx670ZzotWIn+B02wQQzM2N0ZwpgbXUlpox8C4UFCnxuecIRYPXKgF 6zU/dcferPNppVtPBKJTWzYyLCp1dAYIon/0dyTYLHx9QzD/XT5a48rjy5OniHpeQeafDXab svZ726324cMmFPYltSWfvTvMvCd2jIlRtL8uN+m5WJl9CyEUY3lHyJIffK6MTokQF2N5Zi+c HLLqC94nF07zMvNeDm3yvQs9NyD0Ped9Myla6vSJEBfDGy7t0xal/aVJlIxiI2PvQghCeqkY H31k1HuEeKZYPzi6PzlwK76nNlNlRK1I9YwgpNqCabL6r4zJMwKqt/BKD923oavBn647YfrF 82fM7VuDjONoW1notAGh77Qg4zhWVxgVFSHwVe9RqPdzQS296rqlxa5I74wgpFezsbbYhSE/ IC5u0OGCgc6MyPg0cSm9NLZj6O8McUEuA0LfOzH0L0yBUdURAls9NxVD0bzYN+C6shcOCEJI soZkb5e66ox4gZFpR4uS27zPjL0RIQgZiZLbWqSuChECW+jR5IxApkjW0Bqq7YTkinE1xIVj woDQd0LyTj4lhYWhMCBO14D16JsHrYDQaWj6GnBvTpROdrWtyPWMIOSanAnN1hW5nhH4zgiZ 9MHfv3MBcumwSR5tXdW6aQVt3i1pm3DzkpQ10OQYKHs9Quj7M/toinzjgkY3ILDwwKKEJwl4 YP7OcG9j6iPfU9cPCEEIu18k16VGnAhwPYf7RdG+UfTewlj5gx9MZbTLz4yIt9flfpEWHbdM Ioamq3dGv0rLjlonAeKlZly1ee1uUt+9AzlZQfMaHAbw+6DNb9744TerczTelUopZwChHx0+ ViP6A2dKBYjJKxXuoLa9s3hTYqB8aRCCEF7JpsqnUGcQgLjwN0/ghycXkKODOnRSRKr68g3n 9rXyvGmxeepkCxD6bus+N9bLBrrQijMCahqK47X/7mfiOacihCBkJGfj0FKktDGAmNKu70e2 eoDJcbXklleafUYQwivF1OgonyeEmHMtngpQuTthT4SbvGz6xx4AkHxeGNoDQt87UU7T1ceV MTIgnp6uXxBVolUwouzLxYa2sNgOCELayXeHbsrTCSGsfx+pD1zFv4KhCh2d0OkEaSo/abvz GjQvyOS9kU9NC4IcEPrulKlnnFvZFs4EYupoj2IpZhNrLQvr8YAgRJeskdHK2YQB4uQ7FQ/X Mb+FPWlrZbMmlroy5QcEIe4WjchrYa85E/QRgtDMNO9/4DfLljMxcE6rCKEXafbJiDyWGnFP uNdR7q6l0G3inbKYB8uq4mtSDxXkrJ6PCYREUzW1Bc4DAiCWF9SJd5ZmfE44gOwK8RGH93he zbkRQhPQdFTO3o6STKnkjgYQmnGwI5qp7MUzQFxIr2mb10RxKPl75C7RvDOCEFITzSHWSCm0 APG5luAtXsplk9jLYIDQS8970R0aeewBiIt5+INT2WgivxQyq9E00UVWZHZGED1XWw89t9S+ CxDPfGwUrWvNZEfl2AEEvYSCDSbX4qm9HCAmg2OgajJlul1yjjj2mnbbC6mZZgvnPwcQRL/l YFppZWFkDwjsrPcKM+MhSC4F7moPIAjp9SA5LqwEEE5+JccfoOymAm6O1sd5d5MtwMvHrmza BWEPCL2wo68mhMxZ0wCCcNZR+BtsLw3NlFA4h1OAIKQXg6m2cQ6nALHqcTDR6hy79xcVTosQ hOxy7d5f3EEVID7V6La9U9aW7FtYafYZQQhPjh3FurCwzw0IvbEXO98+USXmP/TmIyjvXNhK B4Re3Mkn4ysXoPKYgG1o674E2xvjbXlbOZ4NCEJy6ba8cb66AKFWL6c8CeD4Pfo5fqIrwfvH ZptMi4GKlUYIfa/lnhXMpRU1ekBgT2qwNH9WvomJtsuI82RyuZBHr7zXZ639wa5d3wOlXXRU /imE0IzNLazZWlnOVxpxJhA5pubTOezvdM5k2wK8cr5CvAdjkwHVdRiPW9rCB1n61I6G+oRx alErbAD1Y4w1OZRQKgNAaIZp3QaZk/UvcuGXAKGPp8bryExg5l2eXmQSJZIGqr3UoWIKj+/Q WDJvB9w6oSUjGmSltkKAIEZTaybJ6rEwpgfE1IYMLU3qHfnokTWvFdXN80/OKtVz1liA0HdC iNnUFNPClB4Qs8oBOCE8sveNpilkE38yexSSadW0llYmyYDQ90+0oSeB55y+AeJTLQrbO30w MXrOiAQQhPB8McmRbnUAcZ985DiE1Xm42LDK8dXz/hTbV1VrYo5L3XNGEN1To0khc9ZigCDG 9vXOPf85ycpsr7In8p8zIPRClcFqbIpc8hiAsP5nIFT/zn4Q3Oq1S0YKPcdDapT1GyAI8UVn UiorS8aAuDC9oAmtzdCHTDhoJVGrjKlWU23kEh0ABNE7zffM8JzlFCCw8JD3JQofUfcyOvko c2eoOzNnWbtbbguqzYDQd2bOsnZnMjYdID5t+Z9oS4XGyYuH45gb7kJ7hgdZVNrlWQWXid7a W9h91kJzTG8hhGLM7Ijaszc5ylUYIYjkcC+sNsBkib9eH+al6eXklkOmgnwQQt+nPlkjozwz Gz9CENUdLqYdDPN8crmokEE3p9hCJb1GCKInujmlNMokgRBzUVWjIQUm8JrP04ZsCvOOGdtH hVhMzt2hmpbLgND3TkjOFPmvhTEyIKaubMk0avs7Szaucq7ACEEIT46rXvSBFeGdEc/8pq59 CEm3tq0xt7zmdmXNPBP0Mu1pzUupaakRJ8TrozMV3xPk4Fa5+EeEIKQakvwF6rIcEF4pItnu feQicRCCEJFs98FFKv8QQihi5z4Q1cSc/MKSMiAIWWRvUiiU4xtC6G2c0ByPDBlan5PpC9Pt m26WtGwpHx2E0HfOzZIWOL9fhNDXMkHeV1ozA7JvwMxq0w4F+7f2fOPhwkJ0hfALDgX7wz8o Q/v+uoUM7QihGaMbYiFDO0L8foKNXl0mYvviXpUsN+eZCxSE0Hedj6LOy6FioREnwmSCdsr4 uL8yJxNaoCqWIAQhOpk4svNS994IQeR9wTkml6r3sCe2PW9TT6BQqLRGCKHvoV5XN4kmvTBO BoT+omS+eMP+zl4BzXsq1ylCEMKLsi+0SAWrI8Rnug3s75QplXOjwicRghBeTysVnaV0R4C4 c1BM5ZAf2JejAfh4hRq0De+eHrVQYcOAoBdetMXIqFlZPAYEvikD5xRteiycFQTlvHhWjV0h sJTZ8nKAQHRatqY2rkYwQuDOQZqENjxRrXrEFkwskcrvjRCEsFsxKWbK2xshrP2KVA9YfQQd F8GfI/O7/fnw5mNclMLMviduCqZVmf28YAaEvnvkNGVkaK2s/gPiE+Mf91f2vL/BUokyEYKQ XfEm2ZVT0ZnwA5SOzSNkRXInAiG4m3N+XVmABwThkIJWZrSdQrvyVH2ZMSPUk1z7d0+o4ze1 u0WuvhcdWjleDwj9yMg1yxkmUHl4EeJpMLuC3brCyKR6j2NyKVjX7+54duf4gtJXTxk3uTpz e8NFqiHLesV0DEBohseeJcn2VHHUlvmY8Irgug3tbTYlNMrDCyH0IvJytKrOVepEAhCfmotq f2lwRkaIpWY+QBDSC0lmXaWSUiAENsTiaD21GqsOvPpxIVzz0g8y/FvxVFYrhNCPgeCcEfFw ZhmAIIKE4Jqud7dAV2LaTM/zkRe7HGqS3qhUqg2EIDpU1nxpO+XNjRAX0p7RBmduLLdGPlVb ngsgetlWpCMXNu8Boe8GOW2ZUiPnGgUQ6uvhZ6bv+TCkqdItcwuoNv4BxjnM+w1siTmsMwJo CwrVgNAPjGSTjK3aKBsEQDwrezHfnddRaJ95hluvHrpLp2veNeWF+T8giG7uqncqaWH+Dwh1 Ep5tiozdjOsWXlte1gNj5usnxD25SZWxUjm3NIDQd2fOXr7Ecm5pAGF91CKKM827SjnRPEj0 oj1I/64KeO0ftHBKfkzQjI6dEHs+dSp3FUIwGSxQf6JuU2c9gSnC9ZXo5itvbBLyvdShi5x6 DRD6rr75p9TMqdcAQTibL6cN3ttSBd5CobQRgCCE2nxPDMrZ2wBiLonqj0kLsrVxye0FIPTC DkH+QnBUEQuEuBiparVe/T2yr4ZoOUskQBBSzdlER6W+BoSp0x72OLszu+idvqHHmVZBRKqp 1l3jiQv0fE9FkXP2gYuvAQj9eInFmtzIUwpAXJRxQcJL2mbXYkprVCJXhCCE15ypxVG5AhBC 7XAEZYo4T2wu85+fQpIJG6iCpwih74QUmmkpcXcYAKEPBH2ZNUnbm59XaW4TTs9IWlNY0XcH hL6XRZuXI2damfADQr/4o3p/UNikL/CDHxb7eUI8JfeiIB6uh1eIMVsmvGjXV/jGOS7VkR7w AXT7rzjJ7Nkng4mZVK4BQjNddkT33nNU6m2EuN/Wp/pBsa9vL/XyF2JylFIEEIT0fDXFFaqe OEJcRBmt59rY3pn68aFwAegAQQgv9fNDWxp6Z8SVpVhdNGO+5MjenJuLlecubACCkOvNxSpy FzYAsZB1bUyDrIjF3HJXumRkqabMyGnLtEPFYu4P/6BYzP11C7GYCKEYRjtiIRYTIQgbMdxL CAuuOjf2Z14HbDLqblGtRaoUAELoO9sH0elypsyqCPGKQpI7O1Yja8vKWBwQhJD6npcdlQ4D IezXgCxa2tB6WNIZGtMmgvShbVRTOXHcNb5OJ7jYBPduwa15YQQMCP0ICKEra5ZKjYUQF/qH +lD4Cxgy02eTvZG5mhozFf2CEIS0izfNVSr6BSGmattMlv9bjpdJe+Khnjk+UlV8EUIv7eiC yZm7KEQIRSKbHeGdqW5lNzwTCEn4bmts1PEIIRaXc3Q3Mud+jCw/2isQ9cBu1cTumLkgyDNC 353JypGq5LawbQ8IfQpXZPf9PLPs3vaYZFImyuEEIYhOeC91tqJgDgh2wCtaXaJxXJ5ZQCAk V0RxzYEKekCIv5880/Pud9u3ZtHyZKqubGMDQt9p8rCR4zd14YcQuw1G0YroTfYry++ZQEii J+Vt3i8M3wGBq1WoS9fBCxzu/k7xUS0Y7g4ljQnCiAgwFKyo2OT3tF+yQ8dMpYJFCM0w29N+ eZNcpUpNIMRTE5OieT3Rt08rrTsRCBHVYlor3MoIEC+sXEdkyV5PoZb2/GdycHGeSuWOEPoO umVhI3NOIARxmwQzjIM7bbRUzufc2BtfnTSeyhMFCEQf1GRKtlQeYYSYDnGfaJ7sGlY+cGEO DwhCSK0Yl+1aK06Iv4dqeWnPRmZNkO1gYZ4OCH0nhChaqufyJCEEtoIpjk577jNrig+cqRQg CCHlaEpLVBUBhFD7fOkTd+kt8OpBHF3PE9OoOgIIoe+f6LJpIq2FUTIgLtKueG3zfDOuRO7w AhCEkES18DFTqYwQ4nUGLO3CEHMy1peyMvDOCEKmuRnbuAgohHgW7qhonagQ0bq20uNnBCGj 2kwUZX9hmx8Qv1vL07xYek29/saFPWVA6DvnZpOthQozRQh1msS5pFvH3lHY8/YkbN2AWqlk cghBSLtbUAtVoxQQ7rMkHjNR3G3+xwh1pbV7c3N68AI0E1D0NfYsgL/AWQj3ZpiYYzK76fMu yIVP6Z/GDGHhvcUPqqVBH7H5LLr7+7oH1aEvNOPuMUEz9neCjAgyMwhCPC0op2het0nlyl0Z AwQhpOaNjZa73wIIxlsO5qBDqLuUqUez27yXZtpTawWT5EhL2bTfQwtwtdyrZ+v52U/10dwi GLy7OVhyRgDE0Iy7nZHeXSypgYcYjDH2OtWC4ov6NW+qmVPNEYOQbAqmBvn6FckOjJc4RW7w nI3ttZKo0yliEIIqtt9krXTXiXDl/DJ/B7qxa8/BvySjE4GQUAumhLgkojMCT7iZtIWTP5CT /cE9JGyUdnm4pcQgw6YQQt+jPSVGjC5SRgyAmMopOGWqgdZDlLhyvZr39lHB3wI4OasiQOh7 J/hbACdnVQQIfakAtU4RYjbOkv6uAEEIL8liXC131gWIiyGpjspCa4/iunFrpRxKrCisK+I+ IwhxV2dc4BJxIITGU2hHJNlqA3fQBAhGFnJAL2lp9TgjXlnEFbkVArd7xQmqbncF0fh2Gecm RwYZbfdP5/D08PTwsRpPj2353aSZXr69HUqBbveCzpkqMrkLuPyI/8s52jwqA6mvo/mYw2pb MYusVD6GcUN78Jb47C1Tn+qKfJnjUsQXOUaepHUMiSyjZjYx7jeoaEQmdoMdM/AhQzH/doZI PhZvC6MtQ8bTuDtNA6vp+8qSoAYGISjfbz69o5yqIYM4dWN7D6xSABMYTO8Z+wekYmpLkUoJ BBlEZ4g633KJlGMbZOhTQ7zQs+1J3sp52dxKFqRGacIIoe+hW8mC4KhkpAjxNNmHonk+iBYX qQs9hCCE5GVD7ObKlVacEHNF5uZCoadPM3tjYjOiGVOedAhBSDXJp8gMZK4PEWLS3RqplFT6 y70tpZfXow4LgECItMpUrJGqYYIQF0FtU1mApm4YtbnFUeDnfB3W7XNDkNXBZ7ewQQ0Ifb+F IIfVVtdacUJcFFrQDu2QvEmlUOnDEIIQUsomRy5fIELow1U+Lyhwb2PrsQ52RY8eEISwWzZy 9KXy5SCEPihwvV7D1hbZ/k3MNS0IdUDohRp9T8dlqehlhPjMRJ37O6P8BS4GHhAI0cWemyFT PlUIcXWXBZ154ZDUVy+Zqmz0yJV4flVClnGvVcSTjLviW1lQ1gaEfhSk4Ey1K0emMwEX3Iax CijWRhmDM3VRp64jNuV99kel2LNtxjtPeTkjhL7zRT03vsYVJWlAEL6q6pS8yEETnf+mw1X3 j+p3ppFz7inhbDqFSY/mFsvJjJz6rF5zZeCm/KpwSQpkspvPibQJ1JX3rN7UdgUQmhmzIep7 Vm/qnA8QpzSOR99KwnIxncZxa86S0Qwg9HJdMpoBxGK2sTtrJ56p+jmsvx6GC9sPK5w5/rBN 4NGFed7pfeu4IMcA7xvl1IcQ+hEYRJcK1lFR0Qhx75sZ8g+xnW1tSdG0ymVzQQhCqKkZUQKW GnFPeFopVNG43HpKZM4GAxCEiEroKZE5GwxAPLWpKJpXk3E+5pXJeUYQQqrNyEqWVrrqjHhl Vvn564L3xvRgUlkoVzbdAaGXag8mtbJlLvTtgPiNclLvzYneuMh5UyMEIdeYu+fFypwZENCs OpUAYKm6rOIedmt87a7+mbu4AQiiF2p39K+UlxdCWKc9tojSbmLh0icgBCGLVkxKjvL+Qwh8 xTTt27+hk+22okj5FyOEXkbybT2H60pPDYi5Ip6fU8l5uSLX/lHZ3iw8lKkKIIjeydEE4VCm KoCwDqyp6lme+pk+1ZX5NSAIGdVoSrAr6+6AONcPmGmF6MRyCFowkQwIQhayaObqqaQCCHFv ULgL2z3GGuQJk6c2SS2MF1ZnzYbrxR+VKxW4OLmzC1wEwz+Xf67dtHyZNvCR+2upZwPsdiHx yNP3/eMYH9zR0zfuLrIl1BjC4LzxyJ/4vBhffJDLxTg5xVxVAVI9Pk6qq8fljNmNaOTLz0+P S+zV07WHp+QrTU7ztO67Ww/QubokVTw8LqaXDxfTUrzaUzRPq76619qqpV35Kmie3r3HH3jH Ozg11A71eJpta9X2SzlUkk2rC0A6bA/rC8ClWHthoL44wy69WFKrTPuHi+JYsIi5MILXP9Ax G2ZknXal2D7JRWtKjYly44cMhcLxwZAtT8ZDYjQOyHiF4+8OT0UgLVM59CCDEFR2vdc5qzBk MFmBp612+1urM8kn5ggCCIT0ajKplbLUiBPiIrAioWkKb8pmSr4eH5h3ndia770cDqwPC8Nn QOj74ZYBt0TqrIUQF0FW04f2nR2Tqa1QxgyEIITUXdoz51+KEERIykwKy0du2IoPFR3T1UCd eRGCEHetstEm6syLEPfr6lFz0u4/wdpuxuTbdgLo5RNsNClZqjYKQkzGO4GDMyyxdO8XMOfX NCEAmUwhU26ngEB0QgomhkzVskUIIuxZLTo5wVZnV5SnAUEIrxQZZz6s9OAZgW3UM14yM358 Wlnfktw21xjPWITQy7qX1rKZ8g4AhBfcmOzknuG2clWeEIKQUJCxkWpb2N4HxKfkhfkMp+L5 DBz7p7Zsunvfgko2IPR9lmQTbS5SqfsQYi470493+FZIJXnjY4kLK86AIPomZROWlr0z4WUJ iD8xSGtrepZRFYKjfNERQt8FojuYaANVWQchXpGifWe77sHMJUdHCEJIvnswc7GVCPEDVLgc ZTsufmVHHxCE8ORY7WJcORMPCP09o3aBzLndbEYrA++MIGRXesnVRpViQYhZpWwCXbvBxGI/ xytEONvnP9We+f42J0tBKNF9P9Vr5IkYmm7dGLIY9IpolNseZDwtaPbAggSN7VNx+VOhMji0 Z8b1Zy6yB1rI0IefjLDPxe2tfXY3jxHpPNZhoAaR23g91fbWPuerSbnmSO0XiKGZHRsjeHN/ A0m0Y2Bg3TlcLy/zAxffCjbtiJ4KgJmayfSkme8w30Mim+f0eIDQDxvvSrfUcWs7QFxdAcOe mE4ssL9VtBvpDc6KDRCE+GLrQQtU3heEwNdpiq17Y/d8ur5QTpkIQQhJVLrYGuWUiRDQaDDj SktWCdvaEqyTTc1yN/gAoRdqsMmE5KnEGgiBS92pEwvNx2TsjQndG6jUle85IwiphmJabJz1 DSDuN7LxbmzpYnF7Z+orWaBK+iEEIbzUV7K0ogkNiP8/qULm5dzL57VeZJCX84DQ93YMsed5 piqhIYQ6EOJJAbNrZXMllYf6nCD6kbGVPEQDBNFpLcmXhLqwvg0I/d2KdsdNrjviFKreGULo ZZd8d8RZmXVnAr2taiMCFB/ZXfcql24cIQhR3xz3ChX4ihAX9nVU4+36pnp9TUgtG1cLlSwY IfTC7vchPjXOYREgXmEu3dCy98arOmRXiHI2If1+UnpMJsb57S0aD8yADrzjlK3nec/0EIDk 0pUt/JGne/PATd39ncbubB/Exu7Ax+eiOfbHudgd9LR15+Xw6mkudgc9rftuKnYHPDwXu/Px MBW7g55WfTUZu4Oe3m3wrqfkrbaM0Y2P5gaM0dnW1mKKzM026O8PJiCOEMLxPr+qZ/Pmr/Do NT/PSy/0IodkzY0m6+03sipkN0p8m6wKCfcweMelj/vBN2zwvgwmtoNPoEJuSOubjzTYxNkz tRXbf9brTwih0OI+EDKO5XDIXP8gBL5x8x975zkXHaNJobskvWqChy06x6NDwV2A8l0NWO34 EPGYUKmMhICgHx2+VCMfURm/ZIS4GB3TFq2d3YJxvWcWmndGEEKSDVVWZcucOhFC7x49NU3m jPMT6QPmsvjNe0pucugZz4rlguAQQt+ht4xnJVKFLhDiFZnldnbtmUZqZaz2CEEIqcq8DpYK uUEIhU17R2w56xdWgAGhl0W0PbsKZx5FCGxGghcCyqw/89fCextDMrk56roIIQhhB5ngOVDX RQjxgtiJHZ2caTVT9YkRgpBR6rWo61JPnRH6yRlzlN2oUemMEYKQRa7dmYyyliLE7+yCb2tm sgKXXxdmxoDQyzt1oRRXF04UA0KffB/nNDr2z9HcgG6jpjNU7Y3v9xhcHgRAIPqg32KERBUM Qwi9SBMSqbpWD0z6/3mBI5sYshNG5iKaEELfn9nLhAh55TA4IPTrSw5WzpOlLqykA4KQRYhy oGxUjgqEIC7+tQGAT/KiKhpfvOFMgO1sxtN7pOMLJGiT03oCE0VB54+Z7yIQ/dPUUAoV4QoZ mqG8M4ppVvqV2isR4yLhCqywAeMJ1PVWta4186U6tg/28hdacCsyGxD6rvOumW4Hp9ZCgFBk w9wRPvTij1QiFoQgZOH7jVIOlL0EIPZsNYpWBN/vkKjsBQhByCJk4+SxlUbcE5hYrambk+Pu 9Iv2M3Ppp0NuEwYIQtil66iWKnKGEIQT1Qsse+3DGN1C5ezZAEFItVUjSxFnzwYIrGABoWIn Z7X77rzf4Nb6EGVMdDdXXgADQt8NISY5BNuVfW5APCufqmidHA8Tdyp6CCDkk1OvUUllxUKI i6JOWjUllGrklLwwic4EQkRVjgqxcgY4gPj9HJWef/8tRU70cWGXGhD6Xog+Gecilf4DIfDt AErJ8cS2ovic2ExKVIYBQCBEKoevTIaMIMQr7gA2tCwrNVbuDgAgCBnlZpq33B0AQEzaW5HF AN4aT8VmgBH/pGzyaK5UmwtuhXBT5Uy6AKHvz1sl3GBXzjcD4mUZfPRlWbUROEoOLBQwn1lr E1q2tWfc4WzpAKHv/Zs/e+HyPyPECyqO72jZn5ItK2NzQBAy8rKvlOYXtvsBoY/mgLck2hRz aL1Tf5OocDLzqWwarpfevjcaY8ufNjnzfO6DvRmuL6NVFCGmizFEMdQ+IH0pTSFSwWUYchEE suzF8fHWlEysoWRGhcMQRoipK4KJst9AxqfmNvp4a+maUWuMcgUZjASrfKbl/J8g4+KeAGZp USdd0fvizttx9i+72XNrohRxyCB66WbSTbL1LrXjxLgY56wTvuaTen6Pwhm6IYMRbc/7Fr1l NA/I0Nf2nollht5Ak2W6kUoOD1ggt7p+tbvlplicRwOD6GzZKY18FqWKQwZ2kIaSnXNUOY4b HBYwXbfs4wOKzJrw8O7yX+Sf/wMc+JzmZW5kc3RyZWFtCmVuZG9iagoxNiAwIG9iago8PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoMSA0ODYzNiAvTGVuZ3RoIDI3MDc1ID4+CnN0 cmVhbQp4nOy8B3hUVdc/unY503syyWQymZLJDJAACQkQApEMJSC9Q4IEQm8iJYCiKEF6qDYE VJqoVBkSwFAURBRBEV8LFhBQwY6gIipJZv5rn5lE4PN73+9+997nuc99mJPfXruevffaa629 9jkzAQIAWigFBhnDJwydNHp3t+UA1k8BYpYNnz7VvXLSB9MBWtoAFBmjJo2ecH+9Lb8DNBgD IAVH3ztj1O/ff9IFoO9PAN1hzMihI07kXF+BdzyIaD4GMywTzFsxfg2RMmbC1AdObCwJAJAW ALHr7504fCiZ5bMDBO7G9KYJQx+YpH5P9wSWY3/gvm/ohJGvk9G5ABvx/on6SVNGTvpxx+Sv ANKxXFMDYuz0Xz89NP/i6iHG3N9ViSoQn41f10sVdM9d5W/f2Fkz2tRS1RWTaqxP5AoYKluH ukM7E9zYGcoytYzm132k+iJHqo9BHgwHCSiYIB3aAnAd9suAKqJNaE4dgvQTGMxLwIropEyC +6X+UEAWwEC6FWYKsCQI8O0wBetuxXQbpPtFW6zfD3EekYvoj7BH87ohhiL6iDTW3Sfa4j0m ifvItAQGqlwwUeofrsH+VkrHYBRiLcY38q9hsyIHJmB6E7Y7xAGyRR1ss1KxFVZh/rNYPhzz 1iItwPQGjA/CdhnRuFq5FBIERSgwvwHeZ3F0vvXY69Ccl4S/xLkU4j07I+ZjHz2RdkB0wTox SNsiFpBjsJAcC2/EcqQwB/tfIPIR7aP0brzPPCzPw3YpmJ6DcTuOQ4HUiPAg6tPtkENj4SDS dJz/gMi8EcdgjJhz3Zxw/NEx/VdExtjlZmCfryK8NCd8Can6prHdjjm3oRPLglKk4xGJiF70 JEzgXYEgv1ZLl4AJoGQKPp1D3MVHQHdMExxnH2k3rBFpRDcZJeEa/iysZ9egBZY9qFiJ8xiB /G6CuA7p9CdopPDBLJSv9nj/2Yi1eM/vZHkYAX2x/8ZIs/glWYbmI5ZgX1dq+SR4g+nZuK69 sa9qoTHYvg+iI65LKeJeMR7sP13wXKw76R/KwboXsc4gAcyPl4FzFzIp2oj2eC9fVA43/k1h I9ZZiny9gJQjrGIMtZDlLAosewvvk4BQIJIQjRGXEBsR4xEtEa8g6mPfgP0yWV5RZoRsyvKB siEdQx7i2GSZjcxhrbyeEZ3ZEL2X6Mej2A7jo/CIewp9ETKLY9lVe2+hU0Jmaqks3+OF3JNf xDyFTNVR1D3+I3QUY5B1EGWrlgq9wzELfVhJ+8FCpGtQjucImRXjq6WCL0LWZJ6gTkRp7k1z zZB1BCkD8EZlfU4treVFHR0Dm/CexYphaFPWw918KtzNHoNh/Cq0Zw2gsZSBeTgfrBukP0Jv 1WHIwrXsgenVt9FVAsqPyTjpMM5zG/LzY3gOeTqZf0yT+cdEkraFv5eAHJe20Ufk+H+ht4Mc jpQJKnBz2f/V/P8N6GlpG9rMbeEfpI/DYZzP40InlD+SDIS7lmJ+OaIUkapKI6tU40mlsh+Y FLi3ISbyALSUApDND+P6WNHOoy5gfj/pSzjElsIi/nH4M1IKpfRjmK+0wlC6Em0a9kVPwxwB cX+kk26So1tk7nZZqqW18no7FTY/KlMupArUv/eiuBjFdcTvKEfPk0gf2cI+y/sD2mjE/Ii8 hm/UyedxeAHp4lr5vE1Ox98mn7rb5fJ2Ku8taN9r9RTHsah2/sI+ChsnbKSwc8LO1Na/nd7U voxuRTkWdvgkDIzqdXIUnXGMX0V1H+0wrveAcFjRIfySYnd4M7OENysyMf4pQgq/hPN+oG5P LQiHovtpg9q9NJIP2tp9VMqCCVF7tkm2N7/Ck/I+2l8en1qxE2ZJVbjuaAPl8a6P6iDyE8c9 nhcjz9fAEpxHAluA+oj5iEGCJ/JaANjEviD2RPYU8lnsRUthDjuD/oJomwVmeb/IgwE49uNy Hu6pgoo8aQBsVPwImbwf2trDMEKslZiHGI9Ye9U00KusaCc+hiZ8C9axggbrrZd5EICXZLkQ bcejX4S8UA4HJcpsd6wj7rdBbhMAS5Qfm2ReyO3RFxHyJXiB91RYobfsT/wI66R+MAB1aIOy FDYo+qHOWWEz3uMFbNdPjAXb2eX9+im4B/VrIdqmhWhzQJb/geEqtg3n8wDadQQrRR5tA5tU ijwcL8+9PY/Y2AVCf9hW8AsZUTyFdlj4E09BGU+DfMV4WIp5SyW0k9jvYsybi/qbgbq7CNu7 onYbsO9FmC/a5glfRvgIQl+UAYhRlMp+AMhjEH4K9s++hw2sMyxEOW6jegr5MA8a4X5BUPac iCYRyOlHolgSgZxnilDiYSZ4WM7Pgg/oVqZFuRV76D4+G8by/pDJmkACN0Mj/i/U1b/gGWaE IfwEPMMrYYlI8xioz4I4/93oW4r8U9BT5NMPML0KBvJcbL8Q7uNDoITtQtn7CDR8FK41tpOW oZykYPtf8b5RkK9hIOuPujUf43+Ft4t6ch+7wwME+N3QSG53E+Sx1uK2MVM8PSCfQIxXxG8Z L461bpy1Y/yH8cnzFPfFdqIOfwbwzBA+i/BFaKgXXQrbEOvp59COdYMZZDMamGehA7mEeDaK HXC3THcheuEe34zMRDTmzeAVxGyMN0T6GmJnJI2+WzM4g5iH934daYU4FwjQttBcUMxbi1iF eKe27GaIvv4p/2ZIiXBreg+UCpBr4RqB2+sjn5tjf835XchPBMriCgHFLBionI7rVw/znXjP 29LYTybfA+P+03j+E8gpyJB5GEHg5jnWrgfSuP8Bzt5E3YJG94b/W+P73wDXdxaiSObvz2CN ypCBnIZkpP2R9mfT4AEBTDfCdGEtPwmefmVshifk/Lr1i+SjrOCREu66Pf/29O3r+p/StAJe uBm1clAnD4/DXAGeh/URt6dVx2GugOJNLHvzv6b5S/8BAyGVrZHHBLKM3ZZW9MA9E0FTcKx2 uc0Sgbr0KdRlhKgrt9fDUgFZdxF0N4wVqCtvhvYbcRNfmwu+Yp9yee361K7L7euD4wvw9xAD ca94DzKQ9kHappbWyXfUXtwi870i8l6XFrbk0m11/taJv3XjlNhr/vme/38C6s4JxDHEW/9v 9yWsjLARJmEnzqIfkod+5Mfon9wDcwBq0JZUpyNeRDvUF+knmIe7d6gBQo9xM+aNRvocQNXv GJ+C+R9HEKY8EdZH/coEzNsbbauK3q9PpH3V2wA3UKJu7Iy0r9qKGIfxXxAPY/wLpK8jXYX1 f8B2c5EeiZTXDMH0dMRBTP+I6XsRBRhfgdSKtCEiBmHB9isFhD/yX86h/4/Tfz5//E8p+izD cZwu8cwL6czbzxD/Y1q7nv+B3n7WqF3//0RvemZwG43wAc9MX6HfF7z57PPvzji1FNczdDN4 v3AN+pQ64UcLX1b4z7L/GKXy+U32Y7FfgNhaKnxn4b8K31n4r0g3IF2okOTx9BPnfDEukLcU GQ5ZIUDdG1MY0xQAVzcXz2DFY1BoAY+QWWQ5eZxsIEFyloRpIT1Gj9MvGGGMqZmXPcLK2BK2 gb3HdbwHH8SH8Cf40/w5/jyv4Af4Z/x7aZ/0hvSDdE2hUyQqXIqWit6K8YoJismKRxTzFasU mxRbFDsV7yo+VvzlnOf8y210W91Od7Lb727sznBnuVu6c92t3e3dE92z3JvcL7m3eyRPjCfO k+zxexp7+noGe57ybE6myYpkY7Il2ZpsT3YlN0hOS747eWjySC/1mrweH/ioT+cz+WJ9Np/D l+Jr6Gvqy/Xd6yv1zfUt9C3xPeHb4NvuK/ft9x30HfW94zvl+8z3jT/XH/C39Rf7h/tH+cd/ J31n+67lVXq1SRWtclc1r8qtal3Vpqp9VY+qwqqHqxZXPVUVrh5Wk1fza6g6XB0OiyfUsF7m 3Hqyk5wkN5BzbyHnPmVQx7m5yLll7HlOuIH34oP5Cr6Sr+Eb+cu8kn/Kv5OC0gHpfelqlHMe RUBR/I+cu+osda5369wx7ni3GzmXipzLdOdEOTcOOfc8cm7rLZzr47nHs6KOc2bkXEKyM8q5 4uQRMufc/w3netZxboVvvW9rHedOIOc+Rc61rOPcSP+474jMOXKVVxHkXGpVC+RcoKpdVYeq /lUPVpVVLauqrh5c0xo5Vyo4F/4aBfOpcCw9QV9l6eGz9F3UCCNK5OPkfjKeTKlej+mxQmZD aaHUUINQfYzOhAdhOtwLY6ArtK7+ovps9fvV71RfqP6g+pSoWb26elX19uoNeD1RPat6bvWj 1WOrswC+LgL46mzkqf6FeYinvrznwtwLf325+cL9mHoFgXb1QtmFh7+cdn7c+RkX9n/d8MKy 85vPrzy38tzGc4sBzr0o2p6PPzf5HFrmcxnnAueyzqWc7XA2/2zu2Zyzzc9mnc042+Bs8tnE s7FnyZmfz/x45rszl858JVqdeevMoTOvncFezrx55oUzO8/kn2l7ps2ZlDPJZzxnnPbD9hv2 L02voaf3mvJF5XPKZ5XPKNcoVytXKY8rdyg3KNfh/vW9orWEp1M2XOguaX7rewr6TQS3pK+y uNo0GwH/5sO6o6X555JliLXoEXXnvXkx0mE3l/LBiFER/Hcf3lOA946muv+7cdzW0s/r18VT /m1NzX9b0vWWJIPnYS7MY4NhJXwD82EZLIbnYAtsQhehDNk6B56Aq/ALLIWnYSEcgbNwBdbC VvgNfoVrsBG2w9vwFuyAYTAcVsAIOAEj4Rgch/fgHXgXTsK3MAr+BafgfXgZRsPP8Bh8BB/A hyir38OPsAjGwVgYDxNQeu+D9TARJsMkmAIlMA2mokzfD9/BAyjdM+AheBjl/BXYALPgESiF 2fAD/AT7yEryNKGEEU4kqIJqsoqsJmvIM1ADIaIgSqKCMHmWPEfWknVoizYQNdEQLdGRjeR5 uA5/kE3kBfIieYlsJlvIVrKNbCc7yMtos4JkFyknFfAnfEzKyGKym+whe8krpJLoiYHsI/uJ kZiImVjgAnxJYkgsOUAOEiuJI0vIq+Q1cogcJq+TIySe2GAnBEkCsZM3yFGSSBwkiTjJm+Qt +AtuwFfwNXERN/GQZHKMvE2OkxPkHfIu2sz3iJekEB/xk1PkffIv8gH5kHyEHkI9Up80IKlw ES6Rj+E0nIfP4HM4A+fgE/iCXCFXyS+4V/1KfiPXyHXyB/mT/EVukDRSRapJDQmRhriPASWU UkY5laiCKqmKqqmGNKJaqqN6aqBGaqJmaqExNJY0plYaR9JJBo2nNppA7TSROmgSdVIXddMl 1EOTSROSSb0ki6ZQH/XTerQ+bUBTaRpdSBdJJslMr7DZbA6bxxawRWwpW86eYE+x1ew53Dlf YFvYNraD7WS72B62j73KXmdvsuPsJOrqv9jH7DP2BfuSXWLfs8vsCvuF/kJ/pb/Ra/R3ep3+ Qf+kf9EbtIpWMw3TMh3uLgQntYm/wF/kL/HNfAvfyrfx7XwH7io7eZDv4uW4M+/me/he/gru M/v4ftynD/JX+Wv8ED/MX+dH+Bv8KH+Tv8WP8bf5cX6Cv8Pf5Sf5e/wUf5//i3/AP+Qf8Y/5 af4J7lKf8c/5GX6Wf8HP8fP8Av+Sf8W/5hf5Jf4N/5Z/x7/nP/Af+U/8Mv+ZX+FX+S/8V/4b v8Z/J1+Ti/w6/4P/yf/iN3gV7IJyWkaawh7YC2/g6agCdsNReBRehwVoi3qw3qwn68X6sf5s ACtgfVhf+J18Sw/zR+AgrIbLqJkvwOMkD5aTNmQ6eQz3iyfI/VBJZpLL5Gc+mU/hs3kJK2QD 2T1sECvic/k0fj+fx6fz+XwGX8AX8kW8jC/mS/gD/Em+lC/jy3FHfkzek5/hz6JPsxY9m1V8 NX+Yr+Pr+QbcqZ9nzVhz9hsTZ0QFQO2LYkIxoLeZHSxkXFIoVWqNVqc3GE1mS0ysNS7elmBP dCQ5XW5PsjfF569Xv0FqWsNGjdMzmmRmNW3WPLtFTstWuXe1zgu0aduufX6Hjnd36tyla7fu PXr26t2nb7/+AwoKB94zqGjwkOKhMGz4iJGjRo8ZO278vRPumzhp8pSSqdOm3//AjAcfmvnw I7NKZz86Z+68+QsWLipbvGTpsuUrHnv8iSefWvn0qtVrnnn2ubXr1m/Y+PymF158afOWrdvY 9h0v7wzuKq/YvWfvK5X79h84+Oprhw6/fuSNo2++dezt4yfeeffke6feh3998OFHH5/+5NPP Pj9z9otz5+/4jnd8xzu+4x3f8Y7veMd3vOM73vEd7/iO/zPfMdCmTSCv9V25rVrmtMhu1jQr s0lGeuNGDdNSG9Sv5/eleJM9bpczyZFoT7DFx1ljYyxmk9Gg12k1apVSIXFGCTTM93Yodgf9 xUHu9959dyOR9g7FjKE3ZRQH3ZjV4dY6QXexXM19a80A1hx1W81ApGagriYxuXMht1FDd77X HTzZ3uuuJAN7FWB8aXtvoTt4WY53k+Mr5Lge4x4PNnDn28a0dwdJsTs/2GH6mLL84vZ4u11a TTtvu5GaRg1hl0aLUS3GgvHeSbtIfGsiR2h8fstdFFR6HFTQ7m2fH0zwthcjCDJf/tARwZ69 CvLbJ3o8hY0aBkm74d5hQfC2DRrT5CrQTu4mqGgXVMrduMeK2cBi966Gh8uWVJpgWHGaboR3 xNBBBUE2tFD0YU7DftsH4x+8aPs7iTe3tCtYcHNpIivLt411i2RZ2QJ3cH2vgptLPSIsLMR7 YFvq61Bc1gG7XoJM7NLHjb3ReYUFQTIPu3SLmYhZReY30psvcorHuYNqb1vvmLJxxbg09rIg 9J7hKbfbA/vCF8Ce7y7rW+D1BPMSvYVD2zt2xUJZ7xkVCQF3wq0ljRruMpkjjN1lMEYjOv3N kZF1ZXJMri5iXXrXcZaIEXk7oUAE3cPdOJICL86phQhGtoCy4S2wGn4KCbYKjsAVGRtUtysu M7UU+aJ9UPKhj1j2O9r2Yu/ln27NGRrNUfhMv4OICjmpEzUsr40H09KCqalCRJTtcE1xjK3l dLNGDadXUq93ksmNBNkHPZG3QwtbpiP7PR6xwIsrAzAME8HSXgWRtBuGJZZDID2tMEiLRcnh 2hJrP1FSWltS17zYi5K8Wz71WYMqf92f0RQXkz+mZZDE/ZvikZHyLn28XXoNLHDnlxVHedul 7y2pSHmLurJoLBjTroAl0miMJjK5FIVyUF1lkSjQBbkP/xSyUI+oVKpQKuUc4u4QNBXfHQkL NR7P/7BRZfiqaCWTv5tFhxlsmXZrutUt6VuGpytjOGDup136Diwr09xShqIW6bBTlKDEQ98C j7tdEPqhZvrwrzJ8uIVAYWIwgCxrJyqg/EWyoslbKiZG44X4EdLZqGEHNHRlZR287g5lxWVD K8Olw7xuk7dsHz1Cj5RNyi+uFZzK8P7FicEOSwqRV2NIy0ZtvGBk8XAFEUYwcGGYjuiBGIJY jliHUMj1RM5ExCzEIcRVuSTA4ssfzwpUIlksk4px92bKyaGR5KAiOVkxoDBCu/WK0PadItVa Rqo1aRrJbtw2Qus1jFCLL7NUUI0+83CbOHTd30dQmIQhoUfBSAi4YD2zQhBBmSKaE2CWihR/ 5rpDjAO6A4ygW+oKH2akXG/ObKOhYXoFLOCiP9PLkRJ6ucJgzlzXpjP9CnYiDiEY/QqvL+mX MIteQA0wYpiHWIc4hDiFuIJQ0At4ncfrHD2Htb6AdEQeYghiHeIQ4gpCSb/A0ETPCn2SQxHP Q1B6FkMTPYPTOoOhkX6Osc/p5zi0D8uzczL3yZG09GjE5YtG4hOjEUtcZiX9oPyvBq5K+nWF O821vk0G/QiCCIqdfYQ3/wjciJ6IYsQkhAJjpzF2GkoRKxDrEUGEAtucxjansc0JxLuI05CB CCB6IlT0/XLsppKeKve3dbWJo+/RYxCPTD1J35bpu/Qtmb5D35TpcaROpCfoW+VOF7TRYjlg GxNSE9J0LJfo6xUpFle4jZkeQva4MExH5CF6IIYgliMU9BBNLh/hsuBNDsAJFWDNcvhepi/C RhUExrkC/nYoY24R+FvehTEM1rnX+WnAv3I1JkXgX/Y4xkTgn7sEYyLwPzgbYyLw3zsdYyLw jxiHMRH4Bw7BmAj8PfpiDINKuvaVlHqu7B7jibuNkd6PXLofuXQ/cul+4PR+ccFfXIztmfLU VOTYmkBag1RX6X5SepCU9ialG0npSFL6CCmdTUpzSelgUppGSh2k1ElKA6T0AGmBrCglgd23 JHMCNlJ6gpTuIKUlpNRPSn2kNIWUukl2oJJ6yjtlySRfJhVthF4hvat1phHH6EGOelCsPaj2 hzA8hQjLqQBWcidHKic4BU2uSM2LpBu3zJzY5m76BjZ8A5fhDTiP4LhAb6AYvYE3eQNvYMQw DzEEcRhxBRFGKLB2Mg58uRwaMUxH5CGGIGYhriAU8nCuIChMjA5xpzyw9Oige4gUfQOvZLw8 1BNIMjlMaaa72XIHMTpJD2fYSbMhTpzyLWaVGU9re//Q//mHHtRt1HQZXQ5JuBAronR5+V9J rkqyqtx/wNXGSp4GJ0epIzngJz6kLaBETjcDh0rQpuCg25Bmljv6YzNjub+haz8xiFZ7XX85 Lrq+d1RSjH7nOOD6xF3JSbnrY8zZttf1kWOR63h6pQpzDvorCZL9brnqPkcL144TctXZWLCm 3PWIIHtdDzs6usY75IKRkYLBJZgKGF29/QNdd+P92juGuQIleM+9rjzHYFdupFYz0WavKwOH kBaJpuJgGzjkTr1O+Yb9sivJmEBD5UplgbKHsrkyU9lQ6VG6lEnKRGWsyqIyqQwqnUqjUqkU Kq6iKlDFVoYvBNLEA+BYhUkQ8Z0BAlyOm6gIxbNiYdeIikJnCMawLrRLn7akS/DwcOgyzB28 3sdbSTS4gUretiRo6QJd+rYNtkjrUqkM9w5mp3UJKnveU7CLkGWFmBukCysJ7n6VJCyy5iUK V3UfEGKetzRR0PrzlhYWgi1uep4tz9LanNOh/T8ExdEw7e+P7ZZ4UnBllz4Fwa1JhcFMEQkn FXYJPiF82X14fr6a334fHqWRFBbsY63Jr/m9RT5r3b6wsEsl6S/XAzf5BeuhxPwi11M5wS3q gVvljNRbE6nnw/ZYL0UQrKdWg0+u51Or5XqciHq7SlLy2+9KSZHrxLuhRK5TEu++uc4JH9bx +eQ6caVwQq5zIq5U1Am2lqs4HFjF6ZCrEDs45CoOYper9P+7Snq0yqK6Kovknhj5u44jUkd/ obaO/gLWSfuffka2TUsjFa0Khw8S54Bib/5IRHFw8fQxtmDpMLd71/DC6AHBXzxs+BhBh44M FnpHtg8O97Z372o16B+KB4niVt72u2BQft+CXYMCI9uXtwq0yvcObV9Y0bFn0+xb+lpU11fT nv9ws57iZk1FXx2z/6E4WxR3FH1li76yRV8dAx3lvkCW8Z4Fu1TQthDdTplWUK0G5bU40VPY Ns40qbUsvK08tkcS93PxxT4teuE6PNHpEaKoUZtGbUQR6pQoMojDXrTI9kgrT+J+sjlaZMJs s7ctpE2dVjINbPlj20f+SvCDWVOnCYZHwrSS/+6DZfl4bmtfMhWgSzC1T5dgHvq5u5RKzC0W Uwq2rM3TavPR3YxkNsbMliKTsbqKIi9X5KnV0Yr/df2nRWk7oQWl9EAFCTjJVCgpZEFnl74U TUHfqFe9H90lsT2UFOIES0gaKam9hzxsiMRBzLcWU6dFY1E+TI3SSCtsUlLLjroPtkFTJe2H BIRdegkSuB9sAOFvEd8JGhob/k6UC0p/wMqVUQBshh1kLOyAQ3CEXAXxZG8f7Abh8bSHZ2Em PAkLcBcbiDmLoDdeEuY/SRLCuyEdNuA+tgFOYt0B8AjshzhiC38Ps2Ae+xBbzQM9JEMb6AkT YSnpGp4Gg+A8nwPZ0BXug0mkNFwQXhZ+PLwJXoB97O1wDWjBDsPxOhn+Wfo0fBYaYYunYDWc J4+r90AAeynFms/BFFjDijgJjw7fwBF44H4cA4ducJIcpml495HwLbGRmawd3uX5cDB8FGs5 oAjGwBrYT5qRjtQjDQp3C5+EOOzjAbzraiiHvXhVwqvwOdFJV8ObwlchARpCJ5zPbniPHGah mtmhPMFo5FIDyMGSifAaHIP3iZe8TidKOilTCkgPhj+CWGgC/XC0L2HLb8gf9BG8ZrG3eIdw WzAgXx4T3IY34UtiJ+mkB+lPG9CJdC2bAirssQleI2As8nsV3v0cSs1eqqOn2PN8G69SJIUu hA24In54Bp6D14keZ+omJeRRcpp8TdvRIfQZ+hV7km/hHyiH4qwHwwRYCtvgD2IhLUgvcg8Z Q2aSBeQxspqcJO+T72gb2peOp1fYGDaZvcrb4tWHl/A50nxpseK7UEHoaOhfoT/CmeH50Avl YTaO/ilYizPbB6fgM7zOw1dEIlpiwEs89e1HHsLrEbKUbJSfQe/GXt4nX5HvcQf6nVRR3Fip giaKp6x4eekUdCifpM/SU3i9T3+if7F4lszSWDOWywrZRBzVArYCrz3sS27np3gY+ZwprZTW SZulbdIR8T5N+Shu6e9WP1+TWnMuBKGFoZWh8tDu8JdgxTXEzQKPULk4+qF4jcP1XokStxM+ JDrknZ2kktakK3JmCBlHJpMHkJNzyRrygjz2l8lB5NIn5AqOWU8d8pgb02a0Le2B12A6kk5G 3+txupuepjeYkmmZkVlZKuvIithINpXNYCtZkL3LvmBfseusGq8w13AXT+Z+nsY78iF8Gl/L v+XfSoOkd6RLCo1igmK+olLxCzoxrZU9lb2URcrlyr3Kj1TF4ikq7IFXbn7VQS6w2Syf7YFl NIsn4InlPZTnITCCdaMoqXQzWUgfJrtpivSAohVtRbrDVTzaP0nfouvoddqKdSNdSB8YJ36p Kj6KWC5++Z3L34DL/CDO7T288wMKHXmEXlHooJzIv5smb7IMnsbegc/ZeaLkG+AM15B4cpm+ xHqiFLzKW0sF4GHPwstsMnkY9tB8AE2VagnKcXeyFe1CX5JJ/mRh9Hq7oxRls69hDoynn8Jl 1OOF8DQZwUfDMsgiM+FbeBG1ooF0nyJVYSXH6VheRmPIbqB8i/g9M0khTIqFuaSIrVFcoZ/B NDjFNXCObcfRn6Ivs278qtSbjEENeBjmw+TwbJghFfAPyGhgpD/4+AW0bjNZJvcgnYVWZRDa tL2o3fvRDrRh3TDHhpLTFeWiH1qINXitQjvBUYLGoo4PQCv2HuxW9KWVMFoyELQ6APydUG8Y GH4RVodHw33hx6ER2oMF4Zl4x81wCZbDZjIv9BBMwpPjZ6jbXaUO9JTUIdyIltHPaB+68tb1 RW77iA1+wOtl6ACtpQNQxj+BPpAXXhL+GKW7PlrY1TAM/dOLOMufsYe72WHICnWnu8Id2CSc 73noFX4p7CIaGBO+F3rAQXhBKcFQZVq0g3v/PWjsTXgSgFluQhniffELe8RMNIyrUIZaACgf BVCdxlUXe3xvAN0SAD3mG7ZGYMTDuPHo3zB1BjDnRmB5FiBmI0DsYQDrZoC4TMSLAPHVALbH ARJaR2DHdGJXgCQ8IzudeBYVZ+XyCDz3AXhx+F50B1IyAHwDAep1jqD+/n+PVJxHWhCgIY6/ sQYgvS9ARneAJq8BZOK9s/pH0KwAgWPITgVogePJwbyW8wFabUIFGgHQ+j2AvDUAARx7W5x7 fnOADtcB7j4H0HntHfxv0EXx79EV17rboAjEK+g7uIM7uIM7uIM7uIM7uIM7uIM7uIM7uIM7 +P88qPiinoQXMFBC292UXFQoK+nqQAxI/CIDjZJfJJCgUkgXKTtIm4CarCaNwZZmup5bk9vd dC23W00u5GHcVI1BkwyP2WP2YUCAQ7WbHa4OiC/Zu/lh0c394ROKddKHoIV4SIR6kEWUAc2K hBV2OkZlT0wUX3Qx2hJibbYEW6LVmGBvkmY5SNdhnyNBR9cFtMyekMBIos3mqy/yXZjfmK4r 92kdB+kaSMO5NKFrKpK3N1OItBXTRryl2g0EpjUdMFCMuujytcum6xhA3uWay6ZcU24ewoRx Yrbk5AgsaJz2sOlokwxbuxmB3iSrgTPNBVnuJi7SyI+x9BSM6anRBfHc6iJmDcZiVBhLTarv IpkeDBrWa+yCDC8GBqJzkTgJA5PW4oJYJQZQ+1qR1EZmk6KYps2zMuOssQpvsp8kK6yxcVmZ zZs19TOSRch/U3b/2pVle16ZP28XyWlXOLBtewRLfrz6S3Jp7dNYsAALWorM/MKBfOBzZ988 tP/4W+TNqc8sLZm6ZlnJjRKF+q8/yLK1Z0TBMXJ06jNLpooCZNbMUC9ajOtkgrsCmnpGAiaL UmUyVZKsClhnUCENmJXrDIOBmZibMbbd/NwSmbk11wVzUR7yUBRIEfFTc9Ps5tlZCiVeVhMh 5596r9vAg7Nn1LvLi/MP9TpI/iSGnz+vqXq/sGzlgVdDrpD7tv519Wl9E1VrTAQsajECzTpG xAiMsI4NNhpcBmrYbvnn/mO8YG5az49XVlx8nNVEa2Yj05Pvqvfg7IMDu50K9SIXyJcH960s G/hBVc3nP4d+Damw962hc2QOnAQNdN+jQbXYpqgkPQN+wnIpJRqSCxrKMAGKFsqWPWAITIRZ sB6le712wyocxbWiaxdNl1GoUMJk0TJFZKtJRlazLFxFZb3mzbP3nuw5IDOnOTt5cvJif7eE ofdgv21IJR1HJ6AmNgwkTKKTGO1GumGXXqB2aRJWSOCTltrSupsuFpm+gfRul5tkwGScZDOP tQ1tQCr37BHfp9mPwQIcPQNfwEbFYHMjQ9wJfD2Wr+fyKK8XFQkViAxq/8mTJ+Xv4oS/pTnI dwZ99gELnyuPzaGV4XMBd2zO04xQto7tZJRNBxIrfu5JsJ6GfQf0O1yPLdg5r3gQ75xrQg2L rMECqXFakaxLpCgtzSpkecuKUEGC9NMN8boD+oW/5WbpMK5zEuzZrXAnmByV4avl1K19LXwB 4hAWhDF8ITCMKxbQhdqFxuMGSa3U2mh+TFdr54R2iX1jBlkHJfROHK8crx0ec691fEJx4gx6 v2K69kHjAsUq5UrTcdvn9LTitPaM0W53cinWqdfHl6gDHm/TDDUBtUlN1Stc5hKoDB8OGDDX DQEc2grnscUym9JQooompwlmCXaRoslQBC3EhyBiTBahnHEWFC7Uz3r+GJPQTrPJ701WKvqN /3D99PKpbcd9uOGjGY/t2zJz5pYtj8zsXEQ/JJzctX1IRSj8eSgUemPHqlfIc6Gnr1wlY8i4 n8fOF2txHhlUhbzRQEnAzQJ6c9PxfBZdTler+HZO1KCQKFNLREfJCY08douYERChP3adFNAb m0q1U8qQiFsKSFRK0O4nuWQeRKRoclqaPLeIDc+LzyHmHDFDKErzeM0KhbIZSmoWrdrd5sO+ T3+VPpU/1Hqm6+WOJ4aI8eXieitxfE74NtC8ldRKcUA6pDigPKY67lB20hXq+hrG60YYHrQ8 GLPIctByyX4p8apdd0j7SgxNNDlMSSanSfFa+CoocYFVSNXhqwG7U2NSKRQnHPZYh8OucthR 5lR2B9M7TZV0U0UPMzFXEtsevTNWAmclPRAwEqrTlMR/iOMR60kO0NngBhNpEdCZ9+TRIXQi nUU53U9TcK9YviuyoML+pwkhlbct3AWKLpotYu4YLDA0TjOgwEb0FWpXuQUUkaIpPqvHn40c aS6MrzdZVuSIYUbjplByZXU2jfc9v+bK5tUPPfos2Rfz578+vH73S0c2DnLu2NEmd/jhR45e GjX+iWfLYk599sOOgq0HNy0c2gQ52T/8DY9DTqbBh4H6kj5On6+fr+f55gHm6Ymsd9y9pnGx I+Km6WfEzteXxS5KfEGvkdxMfL1OK35SzZXEq9cRwaAA3uwAEV+e0JNmu3U6K7ftp5sggY4J pFidDok7G+gtJUPcE93UXaos8cs64CfgN/mpf0UjWyVpUZ7wIdkv/hc5So72b2VoWEke31Wr D9eiGnGtKKIUNci/nHQ0c4KRET6iFCHnUJDI5JjsuOh+hRqRXRet5Z5gn1KEgLtb/92up8bP 2rnx4ayusRZtSeX8cWOXxO72/PDyAyfGjxrx6IrQd6dfD5M5ttULgo/O3BC7lj7w8PBH5851 7zk2unzEkGcbO19ddjj0+zc4YvG/0kzSftQePVwLNLcU6Mbo1ui26I7rpK6sq/5JziwoW6BT MKWk0TIl6HR6/QnGYxnjTA9Up+dKdoAeABW6SOsDGvEvQXU6OKHhlXTUK5KkCSS5mmoqSXZA rwwke5sqSz3NlCuMVGicXh/bFKiJuimjewyVZInMuZ+KkHtpaddQ9L4xyfqGztP1XHNODok6 HRwFz2g0Iu/kLz7p0f5acvSV4Y8C2qwcltwoh/GkpFzhMBQiZ7FOIFYX0OboSnvm6AL+HF2y A2mjHNmlKEQXrBnJMmdZvWZmJnRlzVz63BNvvbU71IwMeYHtre78QmgDqsZTNeNRaIQd9kgv oi7/EEjqYp+RVJa0MualmDd0p3VnElXqGJsh1c7UGVKGdj+qK0PRM8VorJaYmBMGY6whJtZg 1KP8BWIMGqc1YFiPO7LBGLASq9VhQTV9xcjJh0I2UXkDXu506M1DTBNNs0zLTdyEcmiT5dBG wGayUdsKt+UgaQZG8hRKcYtyw55/kkfXrfL4t0SKTRflMO8ySmSRGYHb78UFqsZpEjIXZK2W FZpMLrpZMFEaYzxWD0OJBGusUnha/V61rr730d07lgxYUn/LMvpZzSs95j52mKimLr32dg0p NZUtPrpxTXmPvDj6y/bQ9EGh6/869lj5BbGrdUNuWlGfkyAVygP1xieQ9sqAtX1Ce/dAS1/3 eDZCOUI1zjLCPVU1zTFPNd9xWvVRnFmJCr27ntvr9gjNNtd3BvQ99RRFKZF8OETwDpVYLTkT pWRnrB732xYBK+zxlZhk3qFvZDKZqGlFQ41glpPkBDR58UPiJ8bPiufxlTSlIi26m12u5VRU dWWVTS+6XMsWobJKdJjE7qVQCg21CPvmTQazKVvoK4m9iWusqsLWsNP4/m36DaNtDo7eXXP/ +3O/DF18btF3O76oye6xrPuUTRsfenAr72MYl9Eto/XPZ4cXh/74oOzyI6QLmUm2vL75SPUX RVsLK9eu2rlT7ClDUWvjpJdQZycFDEf1hOMfVXE1aqQw9xmUcLVOX8IYFdPuIRt4Ru1GVYn6 R+hBhpAhlOUhmUhm4QabYIhKCR5Tiibndrt2ubvputjthHcibH+OOSdi6IU0oBelAKZQeptb LNlD2Z4loctdmhv3sUd/W8Rv7FjyVMgSqqo8s4P8QI49K05LfXCVE3CV48ELGXA+kN0sjjSI 6xTXyf+N7vsMSZ1BHoaHyUw+VTVZO0U3Tf9g/GIoI0v4fNVs7VzdfP3S+HfNb8VYknG5yx1u uyBud7ogjdx+IQPOBm4dOG2gS3Q2Xt+YNLZ4nAqpvtOid5YcUhN1JR0dMKWVGANuFAB00Y0m IzVWksf2ZtpKguifYnl5Som1zquxBqzUuqJJnVeD1luw5W8zbskpSr8ctUZRcYiIxJTJ6Gb6 /c1qjyG15howJyb2Jmm4WTTIuEn3fnPo8A/jJyxYGrr+2Weh648Nmz9+zLxFo0YvbNlpRZ/Z m3c8Ousllthg1bj1n59fP+rpBg2PLjwYBkIOL3+d9B0zd86Q4QvmVoe7rejxYumjWzejXu1D EZnP/fJJtUXAzSVQKNVUkctZLlFw9HPTIQ+o8H82qKKe+GSx0uiNypOS5xWD7i5D7EOXlxWe PFn9Erq+NOLzy/c2wLxAeol2jvYJ7fPaq1oJtMSvydZ00PTXjNTs0XylUWo1BqXoU5mrUEgG rt2mEecDr5TL5WHMxpOuQpnLNS20LaV0nsepmxO+wVg7pFw8HtTIBwOxB9REDqGm6CDBdFyI I0yZXDvQugPDyeiRoXbUtQcHnO8k+Iq34uI3EwMDulK6nKNlJ7iz0QN0oPjSPR1YLgXQjvYE CUdqhW2KbXhsy1WAXeWWiDRNKZ+NvylC/cjtdhkS0u2X8WOzR0cl9nO0C6SZ+OOtqpsxUh1m 79DZoaEVJI/kVoRGCbs3UHxTCU8PTkiGuYH0JfbFiXSmfWYiHWYfmUjH64Ya6EB0C2lzQ3sD TUxQKTmY6pnNoG8QS5yo4DsDXk+yJ9elceUmJ7tzPR4nDHbepxkcPy7FNNiNzt84b+0ZXj7B C67lmmrkY9b1XNnkXzTLvkcRfqAIj5/NxOmzNb3Z4+CCowaqFLwlnxJnXJOUAy023V+yxrYv 4Y93PiEwcE5BczutPEnGpljGdWvZKu2FYS3HrluxOu7k5z+8WLxxavfOxfeGnhZSE67BpS5E L0OJB31nYHi6KcM0WjVGXWxayFaYjktvKQ6brpq0KqmQ9Kc9TWO0QdNvut/0vxnUXMf13MC0 GrXEOTpxKoVSqcO4SqFT4jHMrdTFYgZlzM11sVhD7ZQklVPBFJV0UkANKt33AfFz/P1Eiwqj DVh0bhipZL178lP8PGcrUN4qCQloe+oOK8/r2Aod0Ym0yag8paSzlKVKqnzCePqTiDwmIPDP hmttTzBdvgy2vFz75byLMncviyMcbp0LGtvSon4xWs2cBaajRw1Hjy6QIhRZ3iWo7dMl6Ow1 sGA3NzKVcj/69BD+U1iQQjJlcpEXD39e5mExHuavp1AymvUvWvDFtppnNnxGflndIdmRJe2/ 0YEcDLWnA8nKffcvXYy6uBIl6nvkr1neS2cHenLewdvfO8pbop6rVoy1T5MmqVFVpTlaRb04 NbPVS3XGJanVMRZnamqDBuBIciKXXE6nGVQ2v6Kvz6+zN0xyuuUzUlFaq0GyMMnPsa53u1x7 IECgJKFg5eakm8UDIRJxaFGissyemzxWA/UST2bkOOD3osOVGRE1jK+k/s3vlIwaPW/5gNLX l4SeIHfNbtG5S4dH14bOkAmD/e0Gtuz71JLQDml/4b6Rg1/MqnewdPSu4iastzluVLdOExtU rVfqWozv0HtGE6Hdo8LfStNRr5KgMlA8nI5LQhuXqR+OWj81qRTmJq2ANdI29oJ+H9utP6Z/ Hy4m/ZZkNliSzElJLFVR35zqcLs66vvHDrD2TxgjjU96yLLYsoatNqxxbCab6Gbzx4YYiAW7 KdZk5+K4X14/h4hto179HJMRCE+McepYopOrTX5jZ/C7CSF2V7zfrSKqBOfwQZH9tZvYXIu6 1ToWET1MSysSx2UyhcQruDc5BbljSUEVjFf6hUJSa6xF7Bh895G7Qm9cuhz65JmdpN2Rs6Rh q0NZR57Y8vWgCd/Mf/4rSptcqXqd3PfBJdJv14V3Gq1/fGPoymMHQt+XHUSrsxZ1cCDKiBH5 Mzfgd7tIO1Vk4c0mpxFUOFDcLe2uJFN03Z1/r7swJXWL3iSj3YxAc5aoVClUkoqruCLBZrdR hVaj0+g1TGGNi42LiWOKRBbvIRYDBjaVw0PiNGYPyA/zUvEzm8hCEh8XH4eOE0UR8Xkyo0dG 9Ko8a8lf2wY+Uji1pPuDj52cF9pFch57oUl+t6fv7b4j9K6035rUdVjo1NGXQqEtQzN3NG+S //2L3/yR6hRSsBF1QfzGQAv3BKwKyalSKZXAuJioRu3Ugkop1sxhsjRV9mWd3Rq3nmrseq6O zlrX6p7IQonDvrxU1y6m3S7wTTJw8FZPFBt5SvVallb9MZsr7d8Rytse0u8QI9mMI5mHI1FD l0CqPJLlSlI3GBzIs3i+1FJq19b1rmk16LbeL0ZcMOF83t7zZvZF9SUarOkpem25o2YU3mEC 6sA+1AEffBrIT4xNtNLiemSwKoZYWEoKeCzx1AfYO1HEOw0MHSU1If56vhTc5XAs9YrRS5xS Wo/US/K7NUST4B9+T63UdjMVoSh0wyEIRzjqCKXnysnIaTZHeIgoGu25N9FhdyQ4mELnN/ms fpdf5eN+r8+mT/JAnDHGg5VjY9xKTCVLPg9xaFFGYs0YONUeD6QwDCD64Ffs+XW/LxFSg1rS zGe+RUvi4pWNKaqJeHQaa+GoKNlm1pVOWB56f/2noXW7K0jPM+sIedy/0zNs78R5R+73tFhA 6GOPXG1N87aTmgtTSvaRwZ+eJiW7R1c+mTGptFuvuT0Wrjsa+rN0aDYxi5XchLqTLMvUGHHe RJWPsTblzKnWrNe8r6EaiVKtCpXBrVQqikr1RE+1kQUVombFuihXbj1x41GlWD9Jz1sV2tKK JuMxV1auouu58kEXJQxdS1nDSBoeSc0ehBfDTUfojSNHahTS/poX6cAbHWhFTTe8+SEc2mwc FYMn9wh5ouI5VkWLu+TnWRVZTSO0UUaE1m8QoV5fhCY5I9Rmjzz/StebmrqlFdJOCWUB99bl sB6CwNPxINkTzsNVkCxuzFyB3W3kpwtl04Bn6/JS3FmLCidPya0pql0ncWgXgpplPnRE7FY4 VtyhpN6Cg2ReoAlLzs5RqVvW0zRTNNd01Axg89knTDld8xn7TMPqS0t4mbSV/6CSNJw046c5 VQs3X23xNGVuEaDprdDlWERuBaZVUcoFTZLp4QpLnMg/F7grAXvy+e5SqRMS7kIJUWvUKo3E OHdLmlhJwhQumgKdCIVGAxLlhCq1KlBpGNWiP1hJWwaMGRJZLwWlw9IFiUudVSJPm6EkbnQP gkqmrKTzA1qtO2o8Nsu+Ap4XJ18WXrUQ31yxtLm5Aqgxwk8QT86Q2uQnGUqVKVeVi36BDf2C RPQL9gEPf9qiUN4Wan/eFTCrk3EmDRNyuEByYg6u2bm9cRiNy1GIiWotOark2BweiM0RE9/j w6g156YfZxUKlSKTpxTBZFwosTjEQ/BPaV55hH5KlDWr6aNhqLl+FaWsAf2k5uXqVfSbH0Ly r1GFf5GKqydBVkBHKEq+BCrhrVfSlwIGJWVR86W4acv4pihiNSOC4LFiLx+gMPy2AyuK7+cb 8X4mMi0wC6hRFUsTVXy6br7ubR1T6zrpOhlZA+7TNzQUsHv4dP0DhgV6lZZKqhx9c0MP2oW1 VwZU3fRtDZpVdDVbqVyp2sxeUios1GgwZEgUF5aqdHp9hqTCqErX29ibBNANVIn/rqjV6w0G E6jUtNhSaqGW/XQz6EmTcsmtqiRNAhqdWuMO6GZpiXY/7Y/+qhZLaCU6j2o8PLqNk0zEVEn7 v+KWiqVSiUmVdHOFWehzgnihUZRrw6nL/iHG7XWJi0XoLaIEmG668NQge40LHpa9RiR4evjb PXwVdOEqUIVPo/98WvYOuwR1WFZfFhF9+M9dBo3IjT4D+2ivJ8fQ0CM/B9ubnWPIzJajexph bvRZV1oh+pe4+vLWS+Lim2cTD9oX4iXmVSSF3JMRl9CMDCHSgVD/naECaX/Vr4/d3fMZVn2j A3+nqhm/UOUWsoCHeskl72o/7LJoheVohgZOJXxwpQoVSYVHBqZSc0rVShVnbjz7Fbm1xK3t qS3WTtKWaiWtCrc72TTqsGV034sYlDTZHk6+VmcQLeKgjX40bxxhEBHasFsV6JCDZuDw3g45 qkBmJJqZo0QVEX7Z3gSMZkaiItcbeTmj9eYoDbGIGJG+tjcGo0mRaBJGrSL65646nYlqn7wR FaIIE2GMifnZY4zuP1YdQvbM5rOQNaVVpehdDcd99wvpIzwVJ8KsQLHdSGJNsbGJ8YmJnJt4 rDZem8i3xO81vGVg8fG2ROpOCph7xPSID9gLpAL1AFM/85CYgfFDbP3tAxIXx6+mpgQnYxan Vm31u9FpsJcmkSSjX/AqwXGzK1kkfMmbX7mgIxljAk8mF26VvEtmmyArE8xNKbqSMJwsJM3f IR227Q7tPXQqtH/z2yTpkzMkccb3j70X+oSeIBPIc0dCL5w9H1q/520y8LXQH6FTpClJrCDa J0KXIOJH8hpcfz3YYECg2Ujz+FjaxdQl9h7TPbFcq3OiCkK8LeLhWPwqu9tO8M9u00dtRMLN x4nJRde7Xa7zcCJbX/T8EO9Et5d6PGaM13mFtMHj3e59vPDn0PHQQvLQwbVFXZvMDS2S9hss I/dOOBCqqdnOyJJZg+ZY9TjSDSipeHTAcSaTrgGjRWsgluaOga5RqgkubqkMf1VhsTdFerUi uV5Ts0gn1WtqilJjlGL5pxVJ/kg51jdFqSgPlGDEZ+js6Ozuox3kmOCYon7AMMM4T7PQ+LR+ i7HS+J3hW6PJoNO5zcZYs9loNurUlkTqscdpFBazSa+TbGp1XLw9wRkfD55kmWc2m9FoUDn9 hmcVRe6USSmlKSwl2RblnVfsL7XuIa59wkWb8Msjb+dlFooHJjnp8muayFsaqe61YvQTeSKu UQWMOUZTS7OlpZBvMlk2IwZUE3tCjhkVyYIwBBw5JtxUTMkuRJ1mFN50vEMHPsbLGlNcHa+8 UvJjLc8GWnb03QdPfNitfr+u4WtH+t03oJGny5dkw7yV3Z9+PpQh7e/x9oxnTyf5UrpPC00m TeYuaaFV1kxjWdkzOo6R3+oNCn/Lf0Q/NgNCgWeHs+G8hE3l3FevGctxtGOdlF2T8l3tUzrU 68MKlYOSBtRfFGOor/en0BRWz9fc2NTb3pefPtDd39vPd692nH68YVTsSNsM7YP6B40Pm6al lPjmszLtIn2ZcalpXsoc3+P6lcaVVqcvxaDXSh48FSWqlArOqIL4UpIxD533xEbLUYovx0Ej E3GTnqSYTCIriIJUkmDA18jpjGOSs5E60W/vrPZDA9LAnunxW4jf0lfW2SZ1jvTFy6ZbT4Di dRDimnh8hGsmHhyQ6JOkyajRMdlOmpUZPRel1JMfL8rvg6JnQ2tsfByPl1dDgdruH/SKfsjb D0/c2qfnoFahe3uNHf3Ir08+/9d8ab9xx5bghpwW5LOC0gfnVz13LPTbavKJ6b6lA9qWtM8f 7Y0fmpb9/MiJr48Y++5sw+Jls+/pkZU1vn6rPdOnnSqZ+j3OIQP1fr/8DKdHQC9RJ7IH5H8w p66kJRXuyKOUVxRuQtPFU1VC9pCIC4ylqr2rIzovRNdUc7HoG5P83j+v9qswzcR5hsaEknhZ KFHS79hx4zchBRvQqgq/OxYmBzR+YwEvUB1X8TixdcTh1tGUt1J14J1V040vSt8ZlTqgZvH4 26FQx/ppkTuOuON6xtHiuElxpXEsTi+faURbNbbVFFnFnoNrklYkDjdFk69HDKlsglBLSJY5 akCboeWPPLI18+IjI0JVH70XujHpSMcdD5/eK+2v3vVFqPr5ZUT/PetRXX5oz7Aj8lt/3B9B 6iC/Wfs9cHe6RFKhPvNp0nUZumLdItUi9QrdYd1Vndat66mjHI8PeDpVu1VSLJ4j0KN2UymW UklNqPS9W4PeykgVGUlVYvTa+jk9VaRUtUKFaUICehqonzOEkuV0HaVU5JjdUk+JZqCHsgLd 1quShF7Kwgpt8eaIlzJZvNEWsJkiX0CwJ1y2Rb6EcNMTrIgnEoveRjkYkW2/lKstRBB01irD P0ceegunpD5Way47JSD+f5a8D6EN95CsiI+RRWibmrc/IA83diU3IkveqsEzQdUnpZMeeIA3 kM8GCQDK6cJOkyWB9g3Ab25g8dtyoLk5x9Lc1gk6mjtZOtoKYIC5wDLAZlqlWmWkjKOLp1Ai rzRanU6tNxiNutgYi0X8x2ybtTKcWyGBzS2ozmIWNDDQil4HevgUXY9YQsAmqVROqy3WarVZ dGq102rBqMWsMxrdJnOsyWS2qHUqm1Uymk0oV5JVJzGbyWhU44GBop22WSxmM6js8fF2Uxs1 6QVu0GFoRQRAIr32usXjn4SESrJ4V9Rm2xO61aBHWGNPqLF1zx/Z/ps6y13rEQqzHf1uVe3z w243+4e3ErTECwymo0cxyD1aG7s5wLUx4tqYxRJaNLbK8PXIgvkwM/XvBYv6nAbMqdAFpEAL eQ2niAWMiSxgjAVJTBY6iuKRJCFrQw8dO59ib6Eh8T980MPraPTNG6H7DoTeqaeMjw0dR5XI e/qpH1PYuRp76KffFu9mL6ObVLTEPbJj1fPyf7iJaoaONN2Lx0DGW+FR7tsKS7w4sn0bMGCE J2DARKAW+69NPuV9GuiAEV4fA4ufN1ClatINfAwZoxijPafgEmdMoVKqFQq1gqndGm2sRqNV MIWauSlBXSIKnVZB0GgRbSVNCKg1GjWjaMIMldQWUOvUvQOaUjzKV5I9Ab1Wq3MD692DLpc1 ak85EXbMtldvOOIRWpR2XViyy+L1hCDfCEuGzv21XHNkCRc0TlOhDklipURkgXgGbMKgSzAe We0QT39VOrWO7w9fAxa+Jr9EKpRfHsi7s1o+7SHwLHtuV4LYeP/+9x8e89+aZaatat75iXh6 5rcdTBxf1bxCJ7BuoQ4zZ5asIDurK2qeEB5b5/B33MFbQ33IJkmBZWq9OjVBb09toE9NxfOU NTuxZWqn1CJ9Ueo4/djU4owy/fwGa+KesW/RW19M2Fp/b8KB+kcTTtX/wPpFfVX7OOKKd9nS GqY2zeE5DTvxuxv2VxWmjVKNTZuuW6A7rvtL/1eaObupgXBTekrT+ExPrG1Ig4kNaANHuiHP sNywzhA2SOsMOw1XDMxgcLD4Sro1EGd7KtbhUEJ+PU2mg2kbDDUNBZ8npZLeEzDVC4ivXbj9 Gf6dfsnfJEdYQJfT2zQj53AOXZ9DcuJ9tuT0lEOKUwrqUuQpqKJJC/HqVrz3QBMnvseYW3Pp krDsF2u/goGlkyOPrXL+fmsjjkY+sYfKO2y2fDVrWi/yQqQ1lbfcOKs1Ni7e62fizUjk+4VY ieWO2Ddu58GOJXc3G//5aJKVv3DWjKSg7b73Fy3c2tOkjk8+6IgfdnTioMwJY8ds9CfN6ddh 27zus7vHGvT2FJ/mvkZ3FU62TV7cJTC0c+MHrlbNu6sF+aK+w1S/W/rdxff0uOt+XMH5uILi zCW+/3U6sJ1IOmOK1EzKl6Q8V9BFXa5kR5ajrWOSa4VL0TImNy7X3jWuq71IVaQvMBbFDbaP U92rH2O8L+4++2HXZ7rP4z9P+Crmp/ifEr5OuuAKuxLcUroxPTZDyjMGpK7GntIo6fOk3/kN k85kNXAFhUQHar3G6jBobSnva4lJG8CjXKmWa6fioQiymI/SwwS9ofUkSK4S7iJ5pAdhJMHZ MTv6UnmKeHIo3ufJbxov5+Gf/MogIvKTp8Bkjxd3WXRs0Os3gTe5HkO/5u+XpI1e2j1l17Cd kwOhX189OJ427ffY9O0vTJu+Xdpf8/vyHstPlISuhE4/R1Ye6rf45Dvvv3USrUzP8HfsMkq9 HU4GOqp1xOVoF9Muvk9Mn/jimOL4Z+gzbI1+k2mTXafSJ2jG0bFsnDRNN0lfqn9Rt0e9V7NH p4vTzdd9TZkheYhxonGWkRmJENZOGfITsWKYBCtgPVyAq7jVG41adI8sDq3S5uBah5EYUwzJ iTiKFG2aC40H7gWdHNaUU0riUuYpqbJJYtOjskc0WXzPYEr0H2LuAyIM8uUp1y5PqX3Cas5J N6GDWHSx1iEk8ZGvGTSVv1BX5wUKZrHcXUlXXv489MeU7xftOOvamTBr4MKtm+aOW0bmxb9y iiQRzXZCZ+/ckDj+3jc+PH3kUZSsDsil89E3R6cD2zSU6336pvr2eqlZbDPHANpX0zu2j2M0 HSGNVA+PLXYcdn0kfRzzRcKlmEuxV+J/TLgkS1Ccy5VmF2LXxS5kUNmYpugbx7WkzfRdaL6+ Q2wnxwBNf/1o/SXFt3E3yDWDiViZQWsyomRplWZA0WJaWxYBn9noM5neNxOTOWAuNpeauXmq JeWQ8pTyvDKs5IJ3PZRMmeBs2jMqWN3Eozb5u6O5F2XvTeBv0RJK7WkmlBq1OsIw8eDr5pfx LUYenfXxtHEfzSlemV5R494+bfoLmx96YMP8tUuqnl9HWFmvNtRwowO1vHvi9bc+f/co8qwL aqMTJcuKPDsXGOECh5X2Y0VSkbqfdiQbL01Uj9SqTGAiJlrP8pl0I/a6XdnE0jKhiaONpZu9 jaOXZVBCb8dQywT7UMcDiges1+l1mwniiFEfH98zTrirLM5hXGFab6ImE090aJQgBE9NnopB 4YoP6GUf9v+09iXgbVTnoufMjGbTSBot1uJ1vMh2Ysd2bCWOjcEK2QghcYidgEMMUWTZViJb tiTbMQQIZQkUCim9vYQuL2xlubTN5pAFKG5LuS1LE26hvcAD0o/QAm1Kbm+aV5rafv85M5IV Qtt737tRZuafM2f71/P/c84ZV8wO7LVgS24Red3pLw+Qa7CAWMYiXORuUMuEYNnsQBbJDF2s Wjl5EgJvGMOGqqjHO2msAmqZHGox5v/1KBwPJdLCpr9CcAnF1A3GxXTlC89ee7T6D0c+nvoU u/73m9iK//qRvP/28D2TbzNXKgvW3bXtKbzO8+g4LgJboODKqfemPlO1PUf78NfvWNT3OPEE nDA8bYcoz4MOBAtdErb5an11vqBv0PdN5VuWpyxirqXSstc34eN8BLvK3KJAgWhhFVu+jHOY KpeTY3kk73Zh17QzyHn8HGKZ+zF9t3Rg7oIAfcck5xcFdkJbj3p9z+GjqBidxTIiQziExGTI VlvACT7VpQ/hZJ1jk12fx3Cpdl4SeBGGFBXCdmTnbXm4ClfNvuUWXAWClWiwl85rIDPnIFeg h0QNc8g6sv27dztzbx25YkPegvo1i48dY79xz9CWwNKrHN+Wl27cdM9fe0CGLp26kv0EZKgQ zUangxvNZpOr2ux3XWFe4uKlAl9BtbncVV3aZJ7vuty81LVOuNrcZ/6L/Kcca01pdcUlpZdU XFGxs/qhamF+8fxZrdVLzUuLl8zqKO6YFRXCxeFZG6u3V79d8VHxH0o/rbB73HzOYWbfeGW+ U6AWTNUgmCP2azuaQMcRka4bgwtN+fk2eUlJviK7cxr8DbLf6z3uwaon6Nno2e7hPCkb9qOS orIXbMds79umbVyRrdXWBlbRV1WdKiYKWbWKKuQZEtIOkTDvLFlldtJYaHZSj6yGwIp5yLQf HTsrQLoYXTM98yDKouNv9lqZnj3m+kWpG+/0WvHI3ndOD7z+leeufzzyzkM/+OTBx2/c9uT3 rt/65NW5V/rru9c37r0bt7y7C+N7dm3/6+Y/H9v6NDv79YkXXv3xSz8G7u9AiP2IRpL7jiA3 WXyY4wn4uXnsEvaohaOrRMs8voBHtCt2F2vCyJZvElxmWfFLwYb5gWkJT0hYWkVDT09gfmCv +7SbGXQ/5N7rnnZzbsblNyZ7IPNpskJcA8qeQBxalbNstddYPkzfbVad0VdJt+hjIHEXqbhZ eavgt/JKHraIIGiIvIC8BVV16VNB+hJQe6mdUoXPse8Yv2li5Psrxoe3rP5KCwyDf7y/67Fv TV7HPLzjhvZ7b5x8FmTsTlCxFjo/JKAbg11t0k7pIWmvNCG9L52WBCQVSYPSdmm3kXRCmpbk IgnGKoFjWPChbwJP3cRzMi/4TYh+mH4vN8Gd4PgJ7jTHIE7jjsMdx60S0xgmWuh6TcAss0eE sNxYowNY3Dk+Ps797tixczlc+bm3iQWAPrJ/pvNCrwZzBX4dv15ibZb/NJ3l2bXsqMw4eM1J nf/TBxwVJBg4PQ5Xh4kmFNOE4G2QwnMQAPCN0jLO5OfnyFfLo+yw/Db7AS88zuNSvlzwi038 AqnV0mbp5Dr5q4VO6UZuzPSg9BL/b9wv+ZP8x8L/4T8TcxyybGJZjiFTRZIINxDv+fUJIpbj /PqkkQzU4UQMNCB/sUk0m5HMkY+WmkogILcFSzU6xufuBPNs9iPGD74Rwq2oDXjiUyy/Ll7W YygLWWJHXgcNpd8HGQEhDGGeJhKPc+mZIjJlJKhii9jC0rO++DUoS9UFTZJYUNBCJoH2F5C5 oDf2a/Syr9hY4krf+Q8h4zuB/PTE/mL6yny/m1ze26/SGSS40DuFXvaZ03MG2JiBcrzLYdHl htZcrhZ6glJn93tJ4d/vy9Oz465O6tDR6aUGDBGjAEzH//Lx1Gb8wntTD98MweFzeO/UyGQ3 U3T9FNnNcSuIQSOV0nuOIBMY7sYF+sRkYJ5+rZurX0v0icugHzTXZioy7Ta9b+La4HTaxBaZ Bk3bTdMmjvyVUobVlZHURJUyF6z0boQnwFVjsjSTy8htVZUuudRAJSgmBINbx43ZS7AefDlY 61L00hEkQSC60GwB63GSOyn92vOhZnrTdFZjPKJWKnnzNIllSwvz+Zx8sxncZr4016fKx/2Y /EUjxu/x5Fr9O+kC/a6DXv/OPJwHUNCHmIZSPz6OMPEpmSJEpIVFvjL/Ybz1QPGytHUFP3ry JIk5z3RN0ncI4DrTycVWXZTsnuyZeKvicpa7FHsedlhy0iaFblsgC57pa0QPXatI7QodwLIt zMP1j28eeaDoppf/178cKN1wyeA/jV/dfcUtzVz511ddt+nqo3uemaxgvh27rvnrj00+wOzf unX1N746+ZZha38D1HKjV4NOE8s7mSfVw+oH7G+dp9mzTp4jOjsXCDim4l3qce8J77SX00SX 1eV2gNHFvNsiW6yKtcxMLa8Zw3/zKi9lJLG83tNeZtD7kHevd8LLeVmmIcdtGF/HBcbXkza8 Z1r0aBBML33zCBQ7NWN73bxdkkVZkFleLbfz1jxskx0GwciiA1AeKtM5840wMItgOx4Zfnfj w6tVeXz2lsuST3DlD+xZMriy/sbJJHPHQP/C+1+dJKtvFoPPWAE0sSAf+mGwyyHIPmUZf5m4 ju8Ue/moKAbUZkeze553ibrCscK9xLvBtEFao3Y5utxrvP2mfqlb7Xf0u7u9ozhH4k2Wa9gO U4d8jRJjI6aIHFNkTz4n2EHkXGV0fYuzzB+oEzASVEED92/u+0TQIN1HHESArWUoCFmIoDFo bi5xDvU9PENVXWe7uma28RAPmr6SaDe1S5tMmyQOdNxJ1zgjY8Vz9ni9+LG7fvIOdt/wu7vf nzp1ZP+OO/YfuH3HfsaJK+4dmfr15Gu/+xIuxJZXX3n19Z+88jI0vWMqyhUDXRzgCR0LfkdR 56gXqytUrlXbqzFF2iyltKA+p77g0oJBbacmNnua8y73XJ7XKV6jbPBsyNssblGiar9nS96E 9gvXu953c39ReNJ1svCENq25S7kqtSpnHtesLuUuV9erH5p/VzClmu1W8K5JQMu7IaBFVl/Z cRmrclDeKG+XOTmFnQ1Mg8OP0BeGtEUQ0uIvimlpUGtvyg5pnWklc+e4yKan8go7m0WqHY81 39935/HNw+/fsP6+GvvjI1uffiKV3DcVNT3/5SuvvGd616NT5+6+onnyHPvYay++8uYrL/8K 6HXZVJQ9AfRSUT76QXCXmaliZnsvYlYwYwrfmtPqW+HbWfhQoSngDOS1Fi52Ls6DgDcv7Azn bSzcXvgG/6bjN/zHyidedRZTolTlNDHzlOXMUmU9E2XeUt7xfuD+2PebvL8yNsxZXLkQm1l5 F4QcyOqxNiASmdmwagvaNtq22zhbyv4FkVlB4Xm+oO4Inmm5kD5oCNuNQHa+4f2dF5ZVz35g 7fNTn8Z/cdNPhh6ZLP7u1uTje0aGH52KMuJFq3ANFh6auvXxe/+yiP3ea6/9+F/f+OW/Em/i dognXgLq2NGtwYtqnVjlcCkX4BZx7VwPl+J4yS5KomRx2iULYkVspmKAZKlyp4jFEs2JnUyJ /W96co5lL2Y8OYjIzyTI2iyCVFN6cwpSf7bDSufxuxJkll3nvx4bCGArbn/kkmjrNddecuml F13rKuTKHx66rPmJimWtGxOTb5D+t0I0vg/6X4ffCt7AlbhKmqXLpcVl60oiJduke6Xbyh53 Pl39I9YieXK9nroV1b/0mPKYtQyj1mPZu0HcIG2QN5g3KBssm8XN0mZ5s3mzstkyXj5eYSNz R2Wz5petlzvN3eXdlanSVNn2sq/J31Lur3yg+ut1j8lPKY9WPFZ5oPwn5e4CMl3uKGxaL1b4 FZnL1cpzOHNNQS4JHvKLfK2+Nt91vj2+Yz7e5ivyxX3v+7gi330+xvcssxaiYkRiDJWsuFDx cfCSsIoZslDygMsdoAsmC632AMY1GwpiBUxBfo7A5deYi3Jxbpkv6PQGfIeZa/YLZbMh56H8 puOz8ezcelKqHCLejfUT9Uxr/fZ6pl7FGJchrcxW8n7GuZqbDnKHVpK9lYlV1OiTOPdMlfFK ZQhC3Sqw5gmquImTmeVrHn0oCFbMKSyFYKzcrjpUp8ryJRYtD0mVQh42zYFToQtui62leaik 1KKIs+Q8XFkhyXwVl4eK1AIyaOiL1uiJLiKYXXXLLcSTHyKu8Mx2moryihqIfeY3XjCfBz8y +U2Dodb9trtu2LZ1nv9rLz3YtnDB7K+23/j8evteJRndttntrs277YUH1kVfuvHYW/ji/C2J yOKLS73++uW3rFo2VllUddkNvd41G9Y0luYXOOWyhoXbNqzffdV3iaSVTf+RmW16ECLv7UeQ TJaFlRNneiK4EIDtPogCFIuMWeRWpSqbDKaSNdvUElSCLQ6/gqcFcYm0ZKMwKGwXdgocgjHm IWGvMCEcF3jhKLMZefH8fT26stBNvhD5nCRW4BSZ8SNWwN7QQFfwQxDu9+jvZ0g0bW+kO7Ho bBuj5l7RsilWfdttBw4edFZVFj68W70k8ggTvgcLsamv3DP5tZXVuQSXW0FrTtAvTT9/BOWS dyPgITKa000m6U8HZzlcgSonLhOdbgU73WZQeDuggxrcfq+HuhgePOHBnlW5VO2Ji5F7OpcZ zH0od2/udC6XCzFgxiCQnbCadByiJU5a5cuEdqfS3gVYBvp+s6XJ2DIDIpXLqVaLzULmq8iK WfAxOCUPWUR7HiIexuzZt4BFJC/29RdVFeV0wtFDxWQ+gdnWbW9e+2ibah432weuvPLei8a/ NX5Zf9u8JHP/5IGvzF12Zft9dzJNEFBhsp+P/QhoIeNrD82DMLbE3iQTbbbYmyRwrwIiOTGH pz85AFdsXGUytyIVFgdQJZzg7qOgBN42csMJ7t4OHqysCSANTjZlFqqUyuUmNE++DC2T1+F1 TKd4tdSDe5ioGJW2olE8yoyJW6VReQfewdzB3iXcKX5Z+jbaJX1V/i56RH4eHRL2yT9DP5Hf Rm/Kv0cfyOfQGblaRibZi9xyJSKbSNoQRDamoMMdMAXBUZQhyPJLskuSZMQyEE/RGTyIw5Cs T8fxgiyxCJtqFayUiMFgEOJaRjqM8w4GISxgTAAFJY0J4hLzJ/9GWHYq1zfZNdmV6z11ssvY 8pIJvuxNF6zKIgvnZlZQ0EUU6dkxJ0Q535+K/eCkv8hb9fsjUwNc+eRtvfGOEeZOPcIls12H gCMOZl9QtbnwbG6WzFxuv8Z+r521E/mUiooDan6BHt0Gv1dUFuB4RXLyeZLPYeIQx5sls1V0 qMjJuoR8Mc9cAM6bX5gtVlkDaJ7QLF5kXcwu44PCSnGFeZFtmf1yxzW2NY4tQrfY6xjjrxdS 4hH+qO0Zx5/4c1Kl2V6JKi0V1kpbhaPWtQA1OkbFO8Rd7APKE/hJ5knz48pB9Ax/1PpTiIrf kj7iPrL91nGG/4uU72DplKtgkmRZNCuKrNrtoF8rDpiQQzs8vTzYI9us2o/tgqgJdoejyiRA qCxYZUXxW6wui8Uq2m22Kll0QXEyD2twETFYcHCiza5YLbJd5liHRVHImm3CVoeNrCaSXWdV CyYLZ7dbWMth/ERQ1tpkHJdvJvN1zNqg1GbHcfvNdjL9vzZoVk14I40HWWD8EwfxWefZHjos +Fae6erygtmH/0QAurxfPAdrSISdnv8LU7CCVW0hB4HJsWJvUfvV4xZN0Zjnpk8gDId1+vg4 qrNpjsPTJzJbxjpX7A20Q0guTh/fJ5CdZJBQ3L5ibwOdCxCnT+wTND3VYSwKJEt0jj9j00jd 4uHp4/uFOlLjfrSAOaq3lKk8U85Dy9mnTxyQNU5D+kwjNtb7vPGMowlVw0FeGDjpRKMeAdN1 gkTIqYw7PXT+l61g8YqpZ48+1co1PHVk97yLn9kzNf7sU7N+BUL/zZP2l5mByV2vvMb0nHub 2Xbwr8fI36MBe/QfIP0qHj1kc2BbiU9frvqMr2m97Z+5fxYftH7DNmGa4CeEV2ySLehuymWd Uo4lV52Hm8234HvNYq3jKq5T6DRfbX0A75J3mQ8xh5Wfml+2vqq+zb4pvW55R/1Qdjh4nhVE ScI8L5GZYLPNBkbXgm02i2oGm81YzKyiyryNscnqS+gliVH9SHIhJLGM5SULtvgV1qUorCxB +M7wqgWkEMltDuxYbrlJKZFtIV66KSiDITkU5Ffz2+kWo0VBq8bexJS0AaLL7dteNLbNU9sC pkX9UD1zii6DnREx+qUHQ4C6jK22TTbbDpEKjn6GC5GmzFuecau3oMlMlzAWNCklniYWDnK/ v7hJpa+4c5pwSXGTFMzPLPjtpDEreSED9qnBQyxVI3kfw1ZgG75t6sFfP1qTX+0/8Kupr+K7 3327eepjphJPfbas7tKGc1PK5M/x5Z1TXcR6FU9dyf4B+JeLdxyw5WMb6cVj+U2VrnW2PTIb tASBoFplXUAlJ0GRHG6L11FhrlAqLPOV+ZZ51gft5kpHpfMyd6ej09mZE3VEndGcMX7EMma/ 3nV9zu2WL9vvcdzjvMu1S37S/Jz6rP2o6xP5t64/WSbVz1zT+YVgAhQV7AlYfp/L6fQ7ZBfc 2BQwGH6z7DKbZafDoShmns332VC+ms/U5r+Qz+QfZloP2pxBR9B1mOkImlsdQQdzneMFB+M4 jC99xoZL0JI8mTxy2DRzMKgpdUqbwq5WphVGgRwHam2ALNM6nqdtA+OR61MnyeYv4CpZzutV z5z0kQ9DnMr1qqcohLzEuUmzWMx+b0d4vIMyFCyDFTTSCxr5LFKmP0Lm6Y9wlj66pt97prFJ LmlsssIgfDCnyW6suusk36AgC7dxl7NCf3XeSFdmGEMQ+bBCacnNrouqWy7z2MtN5qn+H71b VVJU9cH4VGxhWd22dYGp3qfUyrK8LbYCrnLyweFbto0wW879dM+lne2Ez5Wgp28An634zqDF cZj5mcg4cL2+JOPnQQkAfEkhfRH7o+DlAMxiKqVatQk3ycvxUmapuFxqUzfgDqZDXC+tVmM4 zIQhBLkBp8QbpLvx7eJd0mf4DNnMWI5niVVSk/gd8VdYINJ7SM0JMGCBJLKBvwJccaZZkhlR lv2YgQGCwWTXHxMyVQGKcsiCLFVWmTmMbeMwSJh4skagGgklloesGFmD1o3W7dbTVpM1heSb MN6DcBuKo2nyKs2mpoqJis68eCXB6Uk6A2RsjvwQvNMP6eSh4QGo1her9HX4Q13IWIp/cBYu F0k8o5NFJESCux8dIuQhNNK3rgx10qUcxIy/t99GsDMuHx3Ka5JEd97FZLjf7yFJfw7K7ibG BUeue0aDG+ZhvpSsjMPC/IbinErmseTVU21s9+QP42Ob8e/uZ0X+/tHJa2+QvgnofYqQ4KBf sxGQGbUEHbyJwZzcQkZSjmNluQXcId9+oQWGRN8htgW9orz1J2KvJsnPMFHqKU+9/qGbYuP4 9DX83mv43Z+/Rv9BiNXO/iez3vgy1b8HN+yGMJD5VPjUybwvvO9kjgnHnMwLwgtOZo+wx8ns FnY7mfuE+5zMTcJNTuaceM7FxMSYi1kvrncxiqi4GJdTFDyKzYxY22dW9jPGamGw0mJBLWTv /upgrTMu3CzcJ7ACdi5wtVgtSgu4BEFPbsA6jIUFYguDUQvL3sdgxucdeiK9OJYszIEQnXy+ hEKolSw3hogwewuxvouYRCEoMTQ0hIeMf7gL55TSDbEenheKs2Ds+qE2+5rqxgCL/ykNcS++ /p07WlbPWuq55qoZCCi1jP2YWWX6GaXUO8FVlFKnxdMuBovYxZwQTjiZ48JxJzMhTDiZvcJe J/OI8IiTuV+438l8SfiSkxkUBp1MRIy4mHax3aCUTTGzyPW0k9BGsQDJrEAsLD4tkIQ6DARk UAvGVluLAvSqsHguURQLIZdlmGGA60CyCkRWpm2m1CJLMvVd1oRUoAsn6br7U/rHmNLX84mV odMQ2X1NPqvUQL4EQTdfN2TBV/2wqOqa6vnz2H9PA9yfgUAXXTlrmfu69hmIWJ8Y+zG+mNIq FSz/hfCBwOwTfiwwfxTx18SHRSYpfklk1ooRcPVFLAIFDIQLKcIY5B2jDHYUPZ/y7bGMMBhY TWZ/ZAql2U74no3Cti/qLYJ/S1nyKTiWgGiKngmMIdK6xIAZZDW9Z8AsutY0YcBcVh4T8pr+ YMA8svKFBiygF/lqAxZRubDNgCX0ZctjBixzP6ItE9iMNllrDFhBPdadBmzhx/nTBmxFG6xn 6V+YJf9utq0xYAidbP9hwAyYjYUGzKJaR70Bc1l5TEhxLDdgHvKHDFhAmxx9Biwip1M1YAkt cZcZsMyEbK8bsBnNdUcNWIHw+xsGbGHXO142YCuqcRMrhjkW+qa4z1HYBLDqMVOYJ+mePAoL NL2CwiKFGyksGTzSYZ1HOqzzSId1Hukwl5VH55EO6zzSYZ1HOqzzSId1HumwziMd1nmkwzqP dFjnkQ7rPCKwnIWvmeKyjMJKVrqV4n4VhVWCi6eXwk6AHZ5hCruy8ueQegzYnZXuo2V3UDiP tqXXWZCVpygLLqP5v07h2RR+lMJzKLyPwGJW/8WstpSsdCWNSwcaQ4MognpQCIXhqqGn4OhA fRReCUP2ABwpI5eGFsFdAmByDkF6lObQICUG5WsAWkzTQ/+fNdVmeqahdngSQ8OZPElIWw5X vb25qAl+dWiOAdXT1IVQIgbXNVCmF/qQoqXWQH1JOBJoBM7dtA8D8CyC+jM9SUC7GuQKGS3p +aNAIQ1KkPKkxgFUTVshT0K0pbBRVwhS9JL9tEaCQR/0vp/WGIUnKZq7j7ZFqJ4yWkhSDMO0 bIo+H6C1kCvpU5z2IWrgMkjrJj0K014laWvkCcnfTa96/4dpaxptIbtXUVp/Cp4P0PtRWnef 0XrEyBundeltp9NjtO6UQZEw3OmU+Xy+FNQZoVSJwlWvO2ykDFNKE17NSEmc8iVBKRqj5UlP iXT0G6XSLYRp+RGj1aiBKXmmU3OGCj2Qk9Smp87QNWpQN25gEqX5h+ndDFeTVGJjtHdfLBNp zUlmcCHP+ml9M3UkoJ0tRm9DBv3DVKY1Q+7TNOumbffSVL38KDyJGjwkeWLAe11G4nDuhWcj BrX1GmZ0OUR5pUuHRmkYNvCPUq7FaJ5Bqme6NA7Qkjom2dIdzUiWBs+3Gpzpp70hsqnzLWlo cizTj356NyO9qc/Zm+Tn8AsbbWyiNQxTSnefJ5sRNATpacoO078OmMawh8q2RmVgK6Vtkspd inKjN8N10ndd34kuVWe0KWlI2Yw90p/2U46E0PW0vN5rUm+YPp2RNL31bkqtQaolYxks0m2T 8qP0eYhSImG0QXRIp2KKlk/3OF37IJWhfmpD032rucCuNp/HNWLveqn8E+42o3VGe2lbS2zl AjhrEHWupDxIUH3Q9WhWVl0rQa5n7r5P5Txh6H0/rX1Lhsf/rzZf50uvYQkjhn2bsVN6rWth PNDQalpeQ+W0vZVwboO2e6jkpilGZDNJqd1n1FaDVkG+Dhg9lsKxCDAicBukkvJL4XwFTV8C Ke1wJjqwDKi4BH4raWoHstAv9MkUy6ihh58fQ9Ppeo91zg0avJ3RhQvpo495caBBgkpHH82d xidt+dPytIk+HYP8w5k2wxkbqtNumJadsX0RQzuIhZqx17qdiBq2OWnYjl5aSyRjewltO43W iBUZMWz2psyop7eZ+juUScvWaMYKRgzNjmR0J0HtVMqwGz2G3H8RvdLaTigWyaplxlpc2F63 IV9EljdRC6z3epPBmQGj5i/iUAXF6nxK6Zb/Qqm4sOW0DSXWMkQ9mhC0GjOonTRs1d9qu4bK /kCWPR+7gBcRw5vJ1hx9lAjRHg1SypJxK0r17R/zXDNkcSDLhqbbJdrfTSkdzRqtElkeV3Um dyJLbmd8hL9PKdK7flp/Wq7i59U3Svm/hXIz25qk7fBMzjjk1e3MMKU4qb8vg4/er2zp7jcs t05/XasGDfmYsfDny9Dfw2hGPpZT3C/kXNrHI2NbxPAEdWx0vzJMuTrwOR4kPkfvmZoJfnFq +bsNuzpCfbBRlO3F/WPup+vTdTJi+Brnj8jp+i7ko06tGc84TOu8UI/THAt9jtY9/63ezlD5 whbO9yvO71HE8JZTMEKmayCjzEJInYPI2LgABVAjjIcanOfC3RyINwJw1CESc65FK4ycdfQv 9Qbgp8ONqAEOUmo+mgexCTlI7X3UJxmE9mrhN0p/NXRsP1/jw9Ty/a1xgkCLqXaOZuRCHwWj hrUlfVpDLbQ+hq4y/Ky44cET/dRH0gR9EqUcaIfzzLhBpIpEVsRP+O/1u5bm74e2auGcohaC 8KqWjj3XUSnR/YmaTM7/2RZGqQ+g5438j7SSflb7OXnM1N0xNhjpCYUj2lNaR19EWxkfiKcg SVsUTwzGE6FUND6gDcbCNdriUCr0DzLVksq09nhsmKQkteUDUG5uU1PdHDjV12gLYzFtTbS3 L5XU1kSSkcRIpHtRfCAV6SeVJMa0ZAgKQXq0R+uOJKO9A9XawkQ0FNPCkCsUhYf98URE6xvu Dw1Ekykt3BdKhMIpKJBMRcNJLdUXGtDg2ZgW79Gi0MpgItIdCUeSyXgiqYUGurUQ1D8c7tOi RlXRAS01PBDRRqOpPigegdR4NylN4FgI2oDyIehMOi01GhlIRSOQOwzAcGKsRqMkiY9EEiFA L5WIhFL98IgUCA8DiknSWDLeA92kXegZjsUApH2F5vvj0Eh0oHs4maKoJlNjsUg2JQhzkqSV SKI/OkBzJOJboNoQ9D88DA0N0J51R0O9cfJ8tC8KGPZFYoNAkbjWGx2J0AyUyyEtBuTQ+iNA u4FoGLKHBgcjQMaBcAQa0ckdJcTSIlsBmf5IbEwD3JLA5Bipoz8ao+RNGXKTNNoLQ4lNEW04 GenWqRkZGiadHQ4T+ms9cUAZagSkUqnoQC9BPREBvqeS1YRNSSAZlSO47Q/1hq6PDkDVkVS4 WicaFO+OJgdjoTHSBCk9EBlNDoYGoWuQpRu6mIomScUk+2Ai3h+ntdWkZbVZR21NpHc4Fko0 r4NyRGrraxbUa5Uro+FEnPBoFs21soNentQ6EsD7/lBiC8H470k+4NILQhgBeaMyBVnXtmur QymtXOtYqbX19NTQjkViychoH2SrWdXWsXzp8kULO5a3rdLalmpXLF+0ZFX7Em3hsjVLlqxc sqrDIlvkjj5gRZrShC2kYkAOsE5RLmT6A5oX702EBvvGaDtE+AmdNo1pY/FhUjJMJBR6NzzQ TaUPZAIEiso1yEQUpBmyh3oTkQiR3hqtE4r1hUB04puI6kHJ1HmdIdQaJSIYAWZHCHcSkXAK ZKMHaD/TL8L2eG+EZqFikSkH7ASJ3zScgqqhm3HQwiyEKpLpToHwZ0iRKUwkVBsJxYZDm0Aq Q0mQquzSNdraASrnY2ksACeDOaASIS05GAlHe6LhCzHXgIoDVEJJ2VB3d5TwGCQnQQ1XNUlO UNpSi/C5TsWi/VGCEDRC843GE1uSumBTGaaJ8VGQmeFNsWiyj7QDdenk7gfhhv4DqwbHNF3g DQqd3xClx/KeGeSIxRsajiRpM2Arw5HEgIFBwug3zZzsiw/HukFWR6KRUd3EXYA+yQecjIDV 6J4xixkcoVvUGIdTMzwmiIWMXvd8cbW0y5kChq0wKoJ2QqlmkmFt+0Jtjla5INA4S2ucu2BO XaCuTpLWroDEurlzAwE4NzY0ao3z5zXNa7LIfanUYHNt7ejoaE1/mvHheH+2TkS0xYnQKKEF qCB0CmpaE98EGroKbFYcDHw1UdJENBwNae0hqhtJGLEW1P+Numv7Uv2x2v7UQKg/UtufvC5E 7EQNSfwvFhiNxCA18o+LkLtag440NzhDcRoGEwdkgDq6EAJiCwzmm+H+Y+oKpJ+3U2eRuETE aelmv8HuY59nX4DjCHuU/W5WXSHqGKTvf03rjpzXVuS82mh9XCE3l1vBLeMuhnMT5A7RELHb cEf68F78MIuoi0dewiSoe0bqQOj/ArMLaqRlbmRzdHJlYW0KZW5kb2JqCjE3IDAgb2JqCjw8 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzM3ID4+CnN0cmVhbQp4nF1STYuDMBC9 +yty7B6KSarSggjVtuBhP1h3f4AmY1dYY4j24L/fOGNb2EAM7828l4wzYVGeStNNLPxwg6pg Ym1ntINxuDkFrIFrZwIhme7UtCL8qr62QejF1TxO0JemHYI0ZSz89NFxcjPbHPXQwEsQvjsN rjNXtvkuKo+rm7W/0IOZGA+yjGlovdNrbd/qHliIsm2pfbyb5q3XPDO+ZgtMIhb0GjVoGG2t wNXmCkHK/cpYevErC8Dof/GYVE2rfmqH2TufzbnkGaI9oRjRrkAUHxAdc48klwmiPEEkDnjL 6if43f75mhw9OFnJPV1zQSQoJgskxYnIMx67I5JSUIok8kxkdNctRySIXHVUT5RTBfHdDAuR SEYkj0iekDwieUyPSEiek1keUa3FWisVt/zcZQgenVM353zTcFKwW0ufOgOPYbKDXVTL/gMG C61WZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoMSA3OTU2IC9MZW5ndGggMjE0MCA+PgpzdHJlYW0KeJztWH1sHFcRn73du/M5jh07 PtvEjvNCHGSX09kXiag1oU5wYvrhxPlwIiQCZX23vlv7bu96uxfHwUZV/uEfQBWqIiiiKggV IQhCEEH/rKJWdRGqFIEEaitwS1UF2goU+hlfbGbee/txZ1tI8EcF8p1+OzO/NzNv3rzd5z2D AgAN8AioAOmCXno5FTsFsO0mgHI5m5+ffkX71lMAXSfR63DO0DPvXa3+EfWvIw7mkNjR1foQ 6s8i+nIF5+I3PrvzOMY2ADQu54tpHeBnOLQ9j/brBf1iSW1RJpHA/MAsvWC8dehHn8H8jwJE LgPVEgHo/3b09YdaDr0L2zANfp53jp0n+cKINXrrxsrJ9nDDm7zqEI8AujZUV07CaDx168bq /vaw5L1P6Gli8Pos7AjQ5HUMHgU+rQgJ3SOg5pTroT/AjFaGHsRYtAc+HT4HM8rXYEq7BLe1 S8r18IByXfspTKP/L0I/hi9xec/aP7RvwufVp+E1zYSCNge6Ngr9GLOgDcNZbQLS2kF4APVR 9H+VgDnOUx5CJKVcb+iFY5FmWIo0KwmSsThkUC4KDq6QbOpRErE4jXOfDEmyiZd+XryUiwGd 5yN/NepLGcdtnHNR5Of8ItmiFm/OQH7hI/UXhF7ro0ZXywAr12px558A1S6BlWvos1+A13MF kaE4EVtd0HYhf1pJoP4VgNtvocSba+UNmSMl5QJyvXJsjeaPDisJbZeoJZ4S9Tf2u2uW6ynD UvQJd22i5mjetzGXibiMmFGj1WVpE8KIT6lRWs/t3wF88GfJz5BEHut776zkegNxOLZ6r29T rOCoLrE+su+8hPqLYh7S/X7VgtbNe7BAe4R1TGHc9wE+PC9Q7fL7W12meqk2MZ+YU8zF8wRw 5wLiYQQ+w9W/IZbr8I70rcjaiHs1MN4V0BcC+gPSPibthLCp7hoMSeDT+f6q5NL+uMcROmt1 Gnv/N9JuEPiwBTnckw+uon5XrF08NyTdZ4pzkm/ZF+Dj/jNGvBcbr9PrOPFM+jKYx4Vrx9rh Cj5rV0g29fi6y7fsC/ASZBPvxcbr9DqO/OkccWUwjwvXxpgMnT8k0fZ0l8d5fV6CbOK92Hid XseRP51JrgzmceHaGLPIEfcl8sKOrx8Lgs4l8uX+gfGmbux9t9yLbn9/m3ZLdNfuVc2+dQjf lj7yw551yx52+/vStFuiu7bHNf3uEL4tfdwvw9HjS97n3RLdtb2p6VOH8MU8kqs9u+rPrY3O rM3Oq/qzyj2j/PPJPZsAsK9L8u/Ikty/RcHxe2up9rmi8cBzJfy8eF96ekbsu/j75ErXR+yN 4MW+V5cjzSvXEG9EmlfvFbjzkujNu19AnBfy1g2UiliXODf/V9YRhFtTEG13refJJn6ze3uj vO6ZGDy/+P2/z8+/0TwffT3+s+8Cn5N13Eag3pNvvb83T58v2z4p7X8DOlfIdzP//zQP3r/f wfv3u/57E0C4nXh6w+foka+6C2gp3Nbgyyjb8d1YRf0wPAlX1a92/rLz5c6/sm37f7u2Rm/r kn2k81edy4Jd+8taei1dffLmD2/+4OYTr/3klTfr37u9F+0IeENKiF6z6x2wNC0ciTbEGrc1 bW9u2dHatrM93tHZ9bFd3T27e/ewvR/ft3Hqj+Cj/nfhh7ewhS1sYQtb2MIWtrCF/xuE6D0/ jF98TY5C/NeRUFSJhDSAwecGn1Pokhra27q3dT9eFPy1UWXqM9XDYVgBpj0D9PmE8qL3Y+Ft AO9//GE45f6THjO/LXUV2uAdqWsBnzD0Ku4/9SMBPobfdqk3QQfsETpeupQ+qSsQUx6Tegha lUNSV2GHcpzrCvf/otR9fwX99ygVqWNtkqeu7FWekjr6h0yph6BTeV7qKs71J66reIkrf5e6 Ag2huNSxHuym0FXYKXkNLz2hfqn7+TX0bwsdlbqKPufoV58Ww/J+HypLXYFGtV3qIWjWxqSu Qp82KXUt4BOGQ9pFqUcCfAznelzqTZAI/Xy0WJovm9mcw/rTA+zAUGoowY7qVo7dV7SyrH82 VzDKznzJSE7li1m7VHSS6WJhIDEyMmc6OXbasI3yBSPDxoqWw07oBYM9SBFs4kxyZGQyZ9pi 5Exx2pnTywZDIm+mDcvGmIqVQU8nZ7Az94+ziZJhCedx4ZBg54yybRYtlkqm3GwymPLoF3Qz r0/lDcZL0dnYkVNMd4ZZznFKw4ODdrpslhw7aZv5ZLGcHZwYGz9tZCt5vcxLHHazH0wODQV1 dtRIG4UpLO3A3QnekSP5PJucLxWzZb2UM9NszNCdStmwJW94xGixUMAs42ZW2LictIN5beZ4 4Q9XDHuyWHEMm01vMuzFs7N2xcjn+UyG6zRt2ukc9ur441nsRm7WMB3D4g5HKvYlAymrYmVt vYz0iWK5oOOIm9Eaq1iXcEaTTZoyGeaarDiOwdDNHR03hDsrmd9juKiKZa6vgM0aFvZxVk5O N4nHfM4oGLhP6ZxeKhl5c2Y2UAKMQhFKMA9lMCELOXCAQT+kYQDlARiCFCKB+lHQwcJxBvdh hIW+5DeLTAEMjHYwRwm1JExBHj2yYKNdRD6J2YroNYB5tkMjzOFMDs90Gv1tHn0Brxlkxnhu quEEzkeZGTzozZHk8ZNomxgX9D6D2jRqcxhV5lHCI48yjbbF56EZKqhneDbGqzB49P0wjnKC r8CqyTxek4E6cY5H28gXuW8K60qtq612ZrceHVeqo57HK/WJRvx+6HzmI3j2ku7AMEraEQfr GoZB/NqYk3aqhJyNc9o8VxIrKWPHB3EFY1gx9TWLK83zbvj9G15X+0GMHcLvZjztu8HXUcB6 RdcOwN28D+7dAf8Cg+iPrmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoKPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAyMjcgPj4Kc3RyZWFtCnicXZDBasMwDIbvfgod20NxmsNO IbB2DHLoNpbtARxbyQyLbBTnkLef7IUOJrBB/v9P/Ja+dk8d+QT6jYPtMcHoyTEuYWWLMODk SZ1rcN6mvSu3nU1UWuB+WxLOHY1BNQ2Afhd1SbzB4dGFAY9Kv7JD9jTB4fPaS9+vMX7jjJSg Um0LDkeZdDPxxcwIumCnzonu03YS5s/xsUWEuvTn3zQ2OFyisciGJlRNJdVC8yzVKiT3T9+p YbRfhsVdXx7EXVfVpbj398zl/91D2ZVZ8pQllCA5gie87ymGmKl8fgBM+G9iZW5kc3RyZWFt CmVuZG9iagoyMCAwIG9iago8PCAvVHlwZSAvT2JqU3RtIC9MZW5ndGggNzI1IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9OIDkgL0ZpcnN0IDY0ID4+CnN0cmVhbQp4nMVVS0/bQBC+91fMEQ5Z 7+x7JRQpkFIiRIsILQeUg0m2wWpiR46Ryr/vrPPwAkFIXCrkjT2vb2bnm0EgcBACJIKQgJw+ FCA9QtMbPYaElpSWpF6CcIAKBQgPaFB+OTmB7LquZk/TUMPR+E+RZ9fDc1gaeQz9fqs+q57K BjRkl8VsDffkT5A3gO0p21O3p23PCWS3z6tAYfN5WO+CnF5B9r2ql/kCsmlOzjt5vg7nFcXP BnWRL65uIRuG9TSUs7xsoiIiCr2L/LWcVrOinEM2moWyKZrn3gVk46eHpoWMwJx+qp9lQYYB cJPTNqMW6H3gs9Fw/LxuwnJU/q4gGv2oZ6GOcEc7uGPIbsK8WDf1MxwNZtVDOI74q9UiLMmC 0Pr9NtJt9W00vMpXXaZU2R3p2yxijXWxaqo6dqhNcV8EOUeTmLJ4kXl2R3fB6bGaQ/wT1jIn BZd0NY7kznmGhqOhbx/7JKVknFuHgDre496+U3SyNBr6yBStDUMtpIp0kfyFP4XTTjLvlEwN ORhjmPeCInRvVghKzHqbvCV2yCksRQK7B+jsOtA0dofo9qUkKHufzoN/hH1A65VkTlljXmBP wDgwaQ42dkXT8HWi5O72yRzU7mF5G6H77gqj7iK41MvFdnZNbB0PwfC0aiIFEcFucJCWwn1c GDy22xJdHE/54kQkTOI72U3OII5nA55rJqxUihibry5CMX9swKJmjnLA3Rg30BOIzKPihmi8 yOdrUBs+n55WfwmjZ4xiWhMq9KRQzHIbyciFY201yKVlyD3RbLJxPC8WNBm4nZso+Z4vQzLI oyZfFNNBOV+EOHBjGulfoCizDVuTmUrm8M1euHxc0k48tI7cp9eR/3gdbWH/0zLyn1pGb9mB KIhKyjiX0kMSZ9BqanVHD+0089Lqd9iBRlnmlaf/cZ2p0FwwpWjDISJRRhnuX7HDvWbH9l4/ y41/5yPiuGVuZHN0cmVhbQplbmRvYmoKMSAwIG9iago8PCAvQ29udGVudHMgMiAwIFIgL01l ZGlhQm94IFsgMCAwIDU5NiA4NDMgXSAvUGFyZW50IDIyIDAgUiAvUmVzb3VyY2VzIDw8IC9F eHRHU3RhdGUgPDwgL0cwIDIzIDAgUiA+PiAvRm9udCA8PCAvRjAgMjQgMCBSIC9GMSAyNyAw IFIgPj4gL1Byb2NTZXRzIFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBd ID4+IC9UeXBlIC9QYWdlID4+CmVuZG9iagoyIDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMTE0MTQgPj4Kc3RyZWFtCnic7Z3bjiQ3cobv9RRzbWC5PB8Aw4BGq9lr GwL8ALbXgIE14PX7Aw5WZ3ZnJevPYvysHkkLS/BC7u76ihlkkhHBOLgvVv79g5P/qTF8+be/ /vA/P/SfpJblB960VFz68rf/+OFf/+HLf8vvTEk2+1b87XPH/+8PH38uFPel//svf/7y9h9/ +88f/vhn++U//1fgzvnwpbT49h+C/gv6ob39JOW3EcA/c961tx9aXz4+a/vXv/2HfP3XX374 4zf522hyavJP/fLLX35wH08vvPDll7/+IM9tv/zy71/+0Vob/unLL//1w8+/THw4nT8c8u3D zZSSso3+/Rep3n5RjUvO2VLffxF/VP8CodLblxcTfJWxffy83H4ejS2ulVSek2K5k4F7LgOX s7HVh/T+yP5r1gpyhJxnY2YkxcrzRJnXhYGcGTalTYa12hzTxGzEBqSePJo/9B3J3n7hvPG2 lmLrxLL6dvtFMF5epNg+HiRG9O1wlfwEUPhBHPiF+5N2Nn2Sdyk1Xxdmc2AQq8rnYGpwPq6M 48ywXwOYcR/VAyzVxFpiWxngmcEIqnqTUotpZRxnho1oazsuQX9YmviNCR+fsG0G5R7//Pji 34Mc+oV6Vw0pyesY28rqHxjEpAZ5g1zMrSyN48S431hy/DhFU1YPMMsrLq9WXhngmcEIqsgr boNfOQUHxr5na8ZRnWhlMay8hQODkUeVE132Pbc0jhPj7h2+eyXRgro7pI8fANvK9veKB43e GZtDW1mAA4MQePTJOHnVVrSfgQH3xk3H0YwviLBTsysLYmAwcorOxGCXdrSBQbyoMTaTqrcr x/bAYOSRgvxFtCsbxsC4OIbh6bmZHop3Wy/zFkwqfslCGBiMzFsxOUa/NPdnxpwVKLbpxy+O ZkfJQMPJw3GElC6FBFL08gYdBkNIYGAQM5FiNsmuaFknApZ2/ArWNxKqWmlMYrzKue1WjqKB wQi1pH5uuxVdaGDo5afWJVOr8hd5yZIaGIT8svWm+LpkSQ2Mi23Aqwcof9GSSytv78BgBOWa LJIlXfeMsDFdWn0adEgmHDdijYOxnB2M2H2Dtn2k4iKvDvQ7Qq/OS9yIb08qC8HkXFrg9mIE US2qHVLFGmzNcasbQVTqSnn3itbmLGlUIggjk34qZE5tekjQr068CKG7HHpCFUbe2+hFxe6U srIkBgYxD96FLrCysiAGBjaG4ZYD56KgX8BNB37i8OWPnGlv51hzK7Nabq8Gpy49RjBzWm9v RuK0DsDA3k6kLmGf3NFKcMcbmm/aRxWT2cRycHcTjzowCJEHeQVEb0+cDwAwbHrbiJwVmzz6 w1wcNdf7uYCmLXojv6ofNTljXSFNXsBgRN6d0bWRJi9gzO1co0tfM+4iB7noy0tL5cxg5FdF n5eNZmkez4xZZXdmfE30aFG8luR0ZhByijYYl1NdkdPAuL9tHW1M5EYe5arWi2MQMymuvb8D g5FrkLlxa+/vwIDrL/2kHp+o/rFV0iQFDEZOovinQnpTHyPgRaTGcN/QRY7x4pf02IHBSEl2 xBbjymZxRuBrXLVDDr3sSfuYyXkTknzvwnMODELcyWUTvV86xAbG2tV8te7wm6OyevA3r9zM z/w9XBp61Ta1IHub7G4rIj4zmKlupUdSuZUNaGA80xPQ9SD0NaJ3C15FKCSQQzU5sIFDgEHM RI6ibTk2cAgw9DMBzTr0Dv2oHqTsxCmTfs529nPCwLYpXYt1Qr4NQ57IlOpi5NYOgqgWzwYJ ztQUIrl6EISPTdSMPda3wGBOZ0UQRopJNlTfHKm1IgiOmMTBompXGnTr45t16DqFw9VHfj7x wiomx3uxiksjLRvAIBaJD17eErc0jBPiPk4JeTUnQ4DVu5gX+0HUKPL+AjAYwWZvnOyEK8M4 IV4Sj7ShxYyJ1rmVrX5gMFLqobclLI7jxFBdNm2Mmk320XM2AmAw8mjW5JbJgE7AmIxHeuCq eeK0Ddz93tswQ5BhOvKa/zGCEHgI8hf1oBpSwzgx5oKRDrc3c2kWM2EfcKa/RvAVzqmft8oL 512FL/4VI7izzqv58JC2BFMJwpvktvuIEpVuy6nTCcpUYUFvj+SilbO8ROpuEzE078M7Q55G dB4uohdCngZwaIaYbZ+6zOm1EMIIK/cT0JKBfBDy61iB+3BaNq56zoeLGIRsvbVyxkRLaaaI 8VS11wzQOZMzaV0hBiMol0wJgVMZEINYaeosTDa/TiObmwZtlzazgcHMUc5GNMO2srsPDOtA zPh2oo/+Rwe0hmcf0Dxpq7L1W0/ZPYhBSDxYb5rzjlLoEeNe2zg6anF6HdTsoGvSX6M0QgjF dP/pyhY1MJjJiE7Og8jp+oiBlen5i8GdnYIcwYVz2SEGI6dUxJJta/N1ZuCYp29gBT65AoRe mjEobdH9PiGyaJNJsbaVpTUwiKmLtonxb9vKvjcw6NtbzcB9M60lLl0BMRgBihEteyqXjYIY Lwtd+R4mYCzOpGBXTqwzgpmHkky2omwsDePEeEnO8w6v3bjIa2/8mcEIqnXjoq698WfGs2iX lTyp7TtFqzA5hKUXfmAQ8kvyF8WS6WeIgfMotXf1+rNrwpX6QOnWPG1PZkgX+R2XjKFoz/Bh 70z/ovvPdev5l0fFfuSrvMim+aGwjhi1VWTWDj63zTrsyyZHm0f7MBlRdXMM7TwBMsGhxnB4 6O1VePAtg4F49UQui2IbriPgdZ8fX4LLz5dg+pHBfv3547s5OPntNYrEDxOh/Pbzx5XPLvte TVfhQppPW3fOwL3+dLnVd7hQ9lUf1z25t8HU0q4S8FUft/4n8P747ZVLYpaI+XYwVv1ZSbz8 xtBMf/0ujjnVx5XiiqnXPLiyHFUfP21EsQzp3XhbebStFfib4+6VY5z5CB7AcY/0ddhw52TZ LfmaSiE3nOHjupkMMZhSQyDf+eHju63ICzK1Ib36EQyeaZtNIKeAvF9ucGw+OLjwOjrbvVei iKEnN1tLzuPwcd08xh4cKMcOOY/Dx1feu8kRF9FUxCgit9zh40p51V5TL0fyuBk+frUgvyIl C6tfFwufmRf8Tp4TyK8eOhVv+jjhGXul6MYQTwqrQ1mWd37v492Ewu+9fZ1z2YQSHWcOQojG rtoh3poYRfyUIwFCRiVrAiKnr8+Viy6DEEomzYRWS6WMTQj5lSLd9vH0fP8ULnV4AsKIt+f7 y4nKlbeCEHwTqAh42+k9Az/WvLQAzgxGVLfKLpZzryHGxSXrVyRBePs675DbhyMWUfXVUg4l xCBE660cO/0PFsYxMH7vF+H7c8Uqx2250tr0DGaOkhdzlEwoRoyLaxLoxIOfeHIppnlWeU29 7BlUcBBiMDIvzfi6NPP3hJd483d0baaWwEXRIAYjpBZkb09LZ+nAmE1XOMTRLtUzUlyxjuEF Tr2phFh6oHFZOVMHBjF3vUJDyZXL60WM3bH2IItPran1GsDNkXdqiMEIKssCrTGvnNQD42qR wyo28xnu+9c2Z3LxeUXDHBiMCFsyJUaueApi6Kv7tUulRPE80ReTfL5yJukZhFxjcCa1NSVy YOjzRa9TqDXPk6O8Dj6trNeBwcg1V+MLmdOJGPpTB+tbyqR19f2uerNOPppkW1g5TQYGMXPJ V5PWfCdnxEuqYO7saE21katYiBiMmHquQclr03VmvKI00M7OrifxcQXOEIORUxZLItm0ouAO DBwQ69smwCb68F3WLXpRoeH1TT1M0cNLuFhWl4x0dh/fKYJ3jzLVbUNVlfGBrT+XuzeXVQ1d EL9md5xXhNBts+Zt6rclXPIvYqhetp0hBnNXzZbGcWK8smrotVNL86QxmBh7LYyFJz0zGImL HZlc5IoNIQZzczQfpL9/ay6y8iuXG4IYjASLM6ITkFckgPEaV9EG7+2RYuJSOhCDEVTP83aF 1MwA46In1jdgRBPOTXD2viI3eHuw4PvXXtzWXTLKy65uP+myt2w3gaJXt+ILp0whiGotbpDg Tc6NdFsChuqqd2fI1hlb5TLtIISRSHQme0dWiYaQi7NUXXhG0Q5wH8/NAAhcrDRiMMLtBkAU C2BpmgfIxeb3tmM9aCx67QHTXLwrfJFl08xkndbGdfdCDGI2ljKQEeO3Xw8dGygPzjqNOPtd m49cLRrEYKa137Y11ogBjNcoYuXjvq37bVYGeGYwgur3bclfhZTqGZpKNhuj5wk7S/YARgxC HsFm2eET6esFDKJmzXX58Qe3QejOU92z9BXBVZscsjywC0t7/MBg5jRXY2viClMhBk4JRt51 8POpukVzcw1+/lX9Nt7aONqyJLGBQcxcT4p1pXF1ORBjV80faEqKK6oNHkXvd5XrmYkYjKCi 2MLNkg4QwMAqJe5Hsd5KbR9N1wLIasgAwci16wAl1KUFeGYQx2OsxUQfybg8wGDk0ZyJjUwc RozJ/pLofIQdtGeS1VE/YHWZaf3xKGa6CSGSoT+AQcxpulXdIFtTIcbnHI/H5kHw1ps7Hccv 0Dju3qTQOxJSRaxjOzvtFB9O7jfu8dsGuObxgxDNit8hKx4/xNB4/N4ZKx4/CGEksuTxgxB8 3YZi6vHVJ4wVh9fB8zvy/gBVdgFnue5iiMHMRq2yG3kuzgAxiFtlhf9n+9Zba8CQuAswxCAk 6F3plaTqigQHxneKI/jMVIb90XLrewanXSMGM00l9B2D6zWCGL9KA+19MK326klhZRsdGIRg b64wtoUJYrDN8l5QGRspjdcTpwiVnLdPd+n02iHBcs0HEIOZ6XJLnucuMBADa+PKfkrbWOD9 uuJBo+0HWigrDzowCIFH2f5bSkta7MC4CN2Ddw7r8ev7aFY6BCIGI9mVDoGIsdhJas4hO3OR OvMNfj6EeH/e5o2oKJSLHSCYmWu9qlbhMiAQQ3YPIKawFU8Y+uT6t/PgdtWdSvhQqoJ6u0nB GVH4uEgpxCBEm0IyznsuUgoxmGxP2Hvv7rWY6b2H3ooX9NLbH7iW/gBLO8nAYCavub4nLDka Bsb3yByBTjdY6g+5+2ZSv5cUsZxkmLlxadmIQcx1Tr2dqMsrcz0w7lJNZxSxz+zWtw+yRVNa 5lqXpKGyDG7UoJiCvfaLN2K1+KtyhAREtRheUcoGQl7SZG+n+2aiva4LR0AYYYVgYimNK3gP ITgSCkvxx6NiUcZ6TeNHNIfTXnrEC75wFcoRgxF7yf0vuB7KiPHUmajwhF3MxpPX4IHu/rNW PN4X0wrZfQ4xiGnqrQHl3CXtXsC4yruCBYNQPh9y2nwDP1fH3G/hpYMSYX9SC6LnDFiy/G8a 0to0H/414/I/6V5vD/S2pnobyGsTBFG9KjtEXvzmA5fICiGqm70d0m1Q39ZEcmIwEknB1Bgb eZWEIL+be73tAXo78hC42iGIQcxGr4zlRHYry3NgXAT+v9eynD8/rwtvaZ41ZNP7/nDaBWAw MpeNxbXARbcgxmKA/9/NVcgWG+ucsZUMZEIMYqqDu2UdL031wMC16Gbcx0ffCQwd0wf6qoO6 tZVAPrHp0CbofhVjQwsr+8PAIBZNv4pxzpGXH4DxkiIhO9zHHuIXOTsEMBhB+dpD/NYm7MzA FcLC2wDns9bcfD3TfTSp9I6NZPQBYDCSzc5UebWWZvjMYG4U0cv9M5A4iqNHlh90WirjCqLC 57LFp7razQuuuC5iEFOdvBfjwl21rtAzfj+xtq/TOVITrVbQS4I8M5gJbbFr11zbQ8SwAV62 3bfk9ofgtK2l0NuGGQ7JZ5q7zy2OuevdYpmtPNTAIISbu95dlvTKM+J0d3yMmg3vPZGiDLam uCLBIlaai6TzEDAYCZbUm7QtWWEDY7ay1wy754JUssxUGqLm727L9LnPc1W/1dnxzzqLw3JO UxPdNh9NFT2kNS7jGUJUS26DZDmenOOKJSPG/ZJjY5Q3eGn9vSLVLcBgBFVDf6+4ghSIQZTS 0By+7d0XJpsnaTMBBiHB7guTxcolGCPGwu2gZuhiCVW7NPdnBCPAIO9Z8eTxABj4XSV8vTO1 /u5dICDVXnNPuz1YL8RVfeC8xoDBTFLJxqZIxpQDxlTi41LWOXRgIuUB2auK4jLb0wbfjACX 9qeBQcxcCEGWIRuGBhhw5uB9K8qV1cZmaS5etsHLsvM5kWY3YDATUa0JIZPXcYBx4WG5zoJf ul1pm+dTzv0YA+e6AgxCsNEW411eOoEHxumgPdpoRL2+r+pnkjfOl0bmjgEGI9sgCyU50oYE DE3tgZ0Rk0nWczUuEIORR2xGzMYlw2Jg6K93XnaVog/Bvh6SQpTJVuOj58qFIAYxpanHWrpI posCxq+T/7cNJmRTsrMre8fAYATbw2lCWDp4BwYhWKXfWG/Mpx6AWA9vCfOgZwYjcNEOSj+t VsZxZuCF+cRRrxh47vZvdGSmKGAQAsw290JffsV/NTD0u/jrjJDc7eLWSO81YDCCle2kFUdG RQAGzEvQh6Fotw7tHdXJapl52hZ7I0Wu/nIeqrHgSp3zN9Yb1YnKfr9laiYTQjSr6h3SiyNY x50wEPI9/fGap701WZFlSx0zEMLI/dZmpVouVwJCXtLLdKenZGL2nqtqAyGMsJJo+yF6rqMB hFwU9ZiP7tnpJYmSlblkEMRgRFWaabauLfAz4+I+Dvl157IPpq72FFEiea/40kzvFbYyGQOD mAzvg7H9vF0Zx5mBe/B8ZqjVPpreb9YHzgGHGIxkUzaxJS7+BjEuPKwwuvd7FYNVyCaIQZ8D WfQVMYg5CmLQF0sWfUWMi3uNee/JDu9XA85xiXOIwQiqXw3UECnNHjHgBRqu+apWp0KvFilW 99LAzwxGgKk33VzSU84I7NpAhtGzmmKa52mi2ee6pO4MDEauTfT6Xg50aRwnxvcue3C3+zbw Tryo6oGi7ssmnj3ed+VAHRjEVMcsumcpXNgRYlyE4iny3Hd69SLuUlcW48BgJFWzEXuGKyWN GC9pSbHDewEeF7lweMQgBJWs2Mk1c/FZiEE4oF4n2SS6eG6BayqBGIxkfTElpyWFYWA8u9V+ UtX7zoWHRA4v6eCkvsCPuz9wbsbXnJcm78xgJq/IwZzqktI0MJ4eqpoB1thXBndPjBiMoHrl 21C4e2LE0Kf7abts60+23E385Jd8RwODEHiWLcH5yBWSQYyXpNDt8NBMiIVL0kAMRlC9Satr axN2ZuBIvpl807sPaMsYXuvdmodqvrfa4kpK5aGkFI4anQn2WMwb+MzyzdujuphNcpnLz0EM 1XreGKlHaPXltTKQAXIRqj7VL2uqSzPIaST6QCMf98momxCFd9bIiMnXYKU6Tf77q06TX1Gd BkJUb8srqtNAiKY6zTtkoToNYjASWapOAyEXmzO8K8blsAL6iL4GGTxMXtBXNe+9SJsY4GsS HRjE1Pbrp9ocqXIBBt8/VTPyWEXRi1z4L2IwEuzXXXJAUxFliIGXszre5qIg8ExzrkdXCKyG OSHN4H1PNCW9b4BBzGrwonaltVkdGPdXuwf/9Kfe7G6DSamX1Cd9/YDBCDa1XlI/r2w4A+N3 1OTzBaUV8l6kpZhUsl+R5MAgZjQGZ3KsZDQGYMyF1LLRYntNGG9qIIPAEYMRYMqm2WBX9pqB gfdk5CBT79WxFONFt1wa95nByK86OcUbeccGGJNNpOaaWr46hWTaWYn2OUXPxPzRObImsiJr HipA+LeBPcrR1vsOjre+d24IZF/gikgwBlhdFRmOCn75s5beD74DHT4wAx7XuEBxe3i4r/P+ 4EDNicp6hLUXLDBCjyXcFQfynrxt++0Rl0aMGKr9cGfEfnvEpYogxpRCM5W2DAOXQCL6SyLC 9mRxa0pLZCQRYBAzFHzvY1G4vD7EsC5fbvbj8ePUSzzE1JMJuS43iMEIsPdTdtGuvGoDQ38T o05Kxe6ruZaVCwmu+v2s9wqzPpLhzYBBTHYM1diWlxbdwCASgdEGqI0khMfjVI3hF5d5zXuW cBT7wTbO5w0YxFz3bOVWlo7QMwIX4vgcV9qKvv4KR9qeLNuMjY40KgGDmdBe+cqxdxiA8Tn+ nqm799e6e8ZWGYpkmC0LsvfEEt6CfM8IYpp7R6zavZdLwzgxnhVo0bC7PhsDbkd/xShDruic e55s/LR9nXPFONHAs2NkCiGayd0h3snREytXUxpCbEjITPVtE2NLPvtDmKqf12L2703OhJKt XRr8AGHE2HMlY2lcPAiE7JcBD0x3FPLgoLH/JJpA87TN90ixQB3liMFIvWUj/7e2ds+M+yq+ xxub31hnle0BRAM3NXjuuhkxiMnwYvs1S5ZhRozJZPSJVlgKG2kfTK6mOMdVxkEMRrClNwcO XPYEYhAJkzA2URsyrrjOKXsuYTLymlAaCEAQExFcM15OrLVhnBizlZxnxheSST5wpUQRg5FT aCa1VJbkdGa8MMP3BcUV91H2goTJcXVBEYOReI09L5tzCyPGS8K/d7icsrI1cIVcEYMQVLRW 9uO6NGED49dJbNpH44O8sFwTBoBg5NqDDVrh2rshhtry1ucoveqSVhFovD9tz2csF5rBJWOI t9d8eCVKuQxRypoPD3fFv9EQZ4VB314Q4gwhqjdxh6yEOEOIJsT5HbIQ4owYjESWQpwh5MJR pA4yxvEPyMwnLuLhcOfL85a97L01mcuCfEwgZtX7aEpIS6trYGiuTXdGrw9YC9dGADEYefT6 gKlxeUCIceHzfBLtDeM9NI/UjecoX7XySGcGI9rSW6FwBf8A4r5j7PEiyseD9+mYaw5ry39y p7dnJTwUguwVd3qhG05ZBQxiQnvFHVnlkXNVAQYTYIxEjvRb7c0VNODU72Jo1riuJa2I7Mxg pq5F45rj6usgBnb53vdvTh/O6otOZXft4Y6V8/03YDwo/A5byENKxhdHmtOAQcxGTD0jO5Dm NGC8xCO2sUsy8iqS1jFgMHIqsrQcmf2OGHjHRtvEywoAvywY+tWH0ZJPb4tIyMUUTxYbQQxi zaTiTGk1r+y4AwOvDTQRnxifVD5KhtfAZQ0BBCHuLBt2s5UreYgYcB0rugvubC/6hpw1S+M7 Mxg5+Wqs81zwEWKcvQszjFtddovn/IpRx6gPbVmKyajOxUaXryuFsM3SUnXpuhcZjvLQkYt1 QAzNUnxnVNFgMtedBzGuJvZJgW6uL9vatCqCN7Yn7s4G68krEMQgZs/fuhPblUV0Rnxy1NH+ rblXACRrzyIGI8CeT9ICVy8cMaxDxuoxsOj+FygRbV5dr3vp4r6nk2XDEIOQbBB1omWy/Rhi TLU+enR/rRl4cP0O160siYHBCDCkXp+bq2OJGLvPTDOOaE2Qk/ZqQfVOHJ3RZhm7x83L/MqE HTtn+G2/j87HY7Drtq+Pv9j29fEX76l5MdRQB5dOMEW2tOIHA+jBdydAGi50nkqiX8Dn2q5m Vc14sLqeMfoFfBAVamUcA2M3Rfvwos3HU/wowHQojwdFvr24D34BJwktkMN8h36KnXWIt0V4 TFnbtpMHXz7Enz8VUpJNKbvLcpJqBjPhvUrydYMOLQK/q5v36XIqTq8elPhhjsTcmdkPniwp hdCS/EX3Rq68JQODmLzkskgsL+3BA+NiloZ6TU/hwfbYyMtWxWoGI6ggW0zNi+M4MS42kK/X a1Az8iTLxMXL8DM1g5Fgyt1Feplipmbgg+FOD0hju7Hxvaf3f40QaullSy7bIKoZzGQ015s2 rY3jzCCWMzy+sbYGN2GkrY0hFM+erLfzK6FeaupqBjFLsqRNjG5tHGfG7vh4oEtBmW9eFycG /V1O8Wk3mhlOkZ0kXPTWu2TI1nnyDMIhH/WBWgZ3nkb9GwLOng3Q+Sz6ay31KgpHD1GtoA0i R5+trhTuRUeQ04oI47XUA/kiRQxvr2ihbn61cXJPnvuZZ+suRlcv8xOfMqrr0Qbkmk6Oj9ms xZ4+DCva/f3GvW1CcFlOkSiHCOc7RRCVg2WHVJNcSmsDOTF2T55mHL1vs/zDeXEBg5FH79sc uNKSAKGJeH1HJCOmLhcphhiUNJrJzXHV2xADV73C1xmw6tV1wJLiUX3f9kRGnMsYMAiReycP UzyXiYwYF0XxlQVLYCLqVNAaiv2YqgmliNrZ5VCjac1zyfGIwcypvAIilMVxnBi45pWiF/UG D9YZX0teWfwDgxBUsMkEMYCpkBnEwCGyYb9w6nd5x5K1T6ItRpLm9nQbpthcvmUu0QkxGJH3 W4lMRgchxp1ql8ohJx42c4JxV9flPV6wSwQ5KEUt5tKzEYOZCXnDfbr2s6oZePv9+lh+sBCS tnrRXFXRCbnE2GNjyawbxCDmJ8ZkYnVcFgFiyJ4Czk0YSgyDun9U/pwLAldIrBf7ctFfOqLV DGLmerUvL5CV421gvKy+1GdGRu6DT954n5eUyoHBTETqB1YlY3UAY58IzThupnMjwxsAg5FH t5y9TO7SOE4M/RYO296hFQ52FDUIjhREuLg/aSXcW71F57n6lIhBzPSt1VuNXH1KxLhQYK8D 8TVf2vPeQuRqetdmTz4/6I8jurPBYFe9jcrGUU6tgDchuFSMc4kslQohqrW4QbITZbUErrsn hFwU3IbuG7VbAk7tdeSsQjreeZNk1VFZyYhBzJJ32aRSuAQ1xHgaeqwZYG/zmV3jtCrAYAQV nBH9kCvqhBj69pK4Pr26Bj727EDrecaspmNCNxm1aEr1XO4ZYjDz3aqpKZJXFoBxZ1VNNe/5 VLX9bZQ9Nbg2T6qHgEFIPIRiWo5cF3fEUKntGyPmfvotieOEYKSRbD/5uF5GiMGUFiKaz8zX o9kHWr0pKZEpOoDBCL1mU33heq0hhjprdG3/JdNJt9FHn4wYIVy1FMQgZiL6ZlzjMsYB4t5D f+cEOxo4Nj+3KO889EeS/Qn8QtHmaB9+voqegJ9u7mwMaT4czh/+jVa8ml/X2yOtVbyCEM3K foesVLyCEM39/ztkoeIVYjASWap4BSFMAeR1p/Q+nOpMisVTZjhiMLJdifFAjLkTba3+Eu5/ Bj+h9+08sfMVcpZRGlGDluQ8MIj5lvPLpOr9yuYyMIh+MIoL0v1bqyir0XKxWYjBSLBGI4ZM ohRvxHhanHZ0WoOfK242t8EEW+UvKlcLCTEIwQaxIUqwnKsJMe4vMI8FyKCpfXQOw198pyvM /bHy7c3nAgIRg5micnvzOfsHMX4XV5jb4KP8RWpcjjpAENMQXe0hplzldsTQeEJ2hhdT1pEB W4jByCOI3l0bFz2EGGsXmCiWe2pD0ZM+8Qpzk0+yzpTK3d0DBDHTySZTxQhfWfkDAxv+sF4e PJVftuWnbkvmynU/QAxG4mJJtmjLito1MPSF0pTxXVjvRB94VYU2vWmQXerZiVzEHWIQMy0m XG/MztUfQgzcz05Zkv6u4NPd4a5+tXJyJlfuBgkgGHGnZMTY5Cq0IcaqA/++VeR8mMY+nhoM 27quJXvyLer7UEFLXtGscBuH8z0LVETFbcAIolooO0QUxp4Nyi1YBMF91J+JVzP2NWcmgjBS jLXf/AVudwMMPixIM/LcTCADsgGCkV+RV9vZyDmDAeMiYxJ68WBB9qnUH0W0jjrsRyHN3qHO BmdXXouBQcxq71DnbLArb8XAON0JpzSh3w1lTp5+a28B18iuwYjBSLCI/ZrZSxLAwPrxRNG1 ufQ26ORS70/Bd+2ezCFCDGImeil962peWREDA+up80EMOzt6I69GWFkpA4ORUw8+8X5xHCfG 5BXA2MFy3gQELg5tz/Qn7huFIOUoM7EFLvQQMYgJvXkUM9k7BjHu86OnbiT0AgxiReVGevwB gxFgEDOKDIkGCJU3dUPEW4wc6VwHDEYa8RYjV5aW05mBi+wjPwqOK0OVW6FLRr8wW+nXWUtH 2sAgpuLmMQ2WdGwDBm6lM5+xvbNdMC0FLkodMRg5uWos2TUSIO7tiZIfHywzwWBTtdhn2lEA jubGd3vWXq08tCWtf2Aw01aqEQOmLc3bmbGcjjQx8GxDPy3J+1jAIASYrewxgYxHRQx1wh3Z V0UzxhjNkxJoGDFWfEI5zffXPcd663f9kZw93GHd90e6q9F+7I90dBcoGiRtg+8JV7Y0suEw hKhW3F5lyfXnyVwUPoRcHPf6VBecXQRzYOB3KFSHveqNlXPEk34ywCAmystf2BYjpzoAxif7 O7dv7UVfc+VCzBGDkWCoJkVL+hMAg0jyJMIToSv0aNO1j7cPRyhMuEIf5SkpxNw7HNgeNb0g 5oFBTHfvcOBkrlame2Bg74f6DAiu5117rgkBYjBycsWkFN3K6zkwiMQ37Qc0V4DbKJPvhzoZ ZgUYjMRTlr9gw70AQx8tl5rOYYezkb5XcIZCxj0cLlVLBsECBjHX0Xv5C0+6xADj/8NtjtJp YnfFQNpMgMHMdPcPiU6+oigODJt+PJojx3atyPrVhrLp360UmmnVke4ZwCAk3sPQbApk4A9g 4Paun1cybh9L6UFfaUljGRiMXEsP+srk/QNg6K861TvBzQMTSljZ8wcGIb+bB8Y2MjQFMHBw sdLtqF+XvYC+d2wgIWAwcpV31ddEhtACBl5/eOe9Dnp4pqnOjLKKlnldTh0jxupIbJbe1Nxs hXt6ZFwKhzr4qslBENUq2SHRJJ88eY2LIBehTeg+AIod2fn6StWal3l7suJv6SrcJgkYzDSt lGZHjIsVDX0ripyhrcpLPyJS4OqnIAYhQd+PCJ+42uKI8XtO9X21fbGJqPQ+BKyDHDCY6e5n QmUzdgDjJdrXR/EjmwvXuBcxCDl136EL7bLbl5qxFMX0qFjOk6p1SyRsvX+m32WTnGzJnqz7 DRDMGqjWBFHbOA8bYBC2+JObVMUTRZdMaHnp0BkYhGSja/0ixq68XQPjma2CdHPNuGOW2SSb JSAGI78kKq7PpO8EMAjfr/rcXLmCupvSmWD8pYPoFoC0uEQHBjHVtwikaMmcAMD4tcNpYZOK vgC8PV5Fja3Inj6t2BWc1evtQhksUcbPH/4uZbCmYxH2ATovamQrnrrVwBDF2n6HBN+jdKny N5Dx0rZqOP4EB6I+aRCnkU9zJsiaYI4byGDmqcmRXwKVGwAZfKSOYuQ9ZqZn9TMKD2QQEuwx M81HqjwQZCiKt30wmqliJDCnCWQw8vDByGvjV1b2wMAVG6bq5M7VVl++p3kffvamd1hndDjI YKYiF1EOIpVHDBnw/gvap1CVnG5g+T4Y2WlSboUx2yCDEWxrJkd32TJWzZgKw4X5D/eWv1ar n1ei9+GHGGT4eWm7GRjEVIRYTHGVulaAjJMlf9iXsevkSY1ezSNl0emLpa5XIYMRrWjbvfXQ 0hSfGXhtXm8fmnE3b5IrVOAcZDDya1mWT6Mcw5CBww/Ux1QUFVfQVIw5ZBByii6LLR0oxzBk zHVSmFl/0LRQ18CEXqxXBUfNX8u+y60HNqVK+SAgg1kDPbBpZQ+/BzydA8XQkm3Gyj62ouAP DEJE3eV0t9CYcZwZT7Wzeb8QlLjaOE7Rmeztkm4xMBiJx2Ry81TFJsjQl3pAAkecn8HGB/7+ 63Ti8vszyaHkalkyvQcGMT/ZWlltjUocgYzd9B4dmV69dWR53XJrVDEkyGAE5UTBLVQXOIS4 t8iP6bKv61zzMoM8p15vJa8tlDODmYdsTQtUFilC0Bu45jurY7MxvR2qvOE4KdikD8bm6Jtf KQzdvQaYNV3rJtVTBFGtno+yaLbkRF1cYcjJ2D1mtOJAnG/Xv9A8VW9o6htpwAMGI93e0NQ6 0m8JGBcrFGagKnT47VtrNbUkbnN7jGDkJxZzi4em68wwzgxcs1BzCGxFt0QH97GRjnrAIATl 5UAP3lHZXZBBNA58kgJ9bfBO3upMGLzYGjkGC6z3E3wXXW2mOVJ3fYxgFoHYzK1WqpsbZODk U4XmutX7sj0UKFHZ5JBByCnYHgpUyHtSwMDL7CtaZp9p9G6j7J0KSw0rK2JgMBJfqFoHGVNG 75zEX2v1rjRme39aMWV7Kg70tV8yhmolmg8PqRzfMS5F/x1Tq7C9K8x0ezYMUb0PO2ShojGG XDShhmWatUc81tLV9bQ16taeOWBNsJEKSIUMYv68jSYUKq4TIYjSw3dRkIs1PdTW8N2eeayc Rcxqzkb0Dqp4B2Qws1pkZeRI5XBBBtQLtjdMM76FZAzIYORUewaUtZyxARiyox49BgdryLdt CZ5LsXmF32ULr3fZlOM+R4x8YBASDL7HiAXSLwAY1uXH6o1Dl4oOKUrzrU/fR5OCiamQ3lDA YCSbikm+rSzNM+Izi9i+f2eRvwjyz8q4zwxGfKWaYlm/JGBcBNrp04yg0a4M8YdFRZR1CF9x obD3Yu6N1C1VLxYyiDUQcxTljg2CBYzXFf5BtX4JgbcmOoOlkvYggxC4GLWiM3DtVCHje+xa qafOy58sDfzMYATYE+dDWdr1B4b1PwEBBv0AQzWhUq2nEYIRU/T9fE0rL/bAeFnjTZjro+6M yiV7XXtzHiQfKSTfO5rZsKS4nxHE/GffA3W4voeQYYM76u0Vtd56bebv+3CSULJzS490ZjCi TfKUgSvPABnENfx10J9mMN1OFDMHKpNXDDfkxX1mydf962QGjejA7sPG1kwChGhWww5ZafuG IReXZXoXkb5ODHL8KS6X90frV+vJZs7TAiHMTPXLde/XJurMuE9/XfO/TZk1cwVQ1lx8nGmz iejW3ctxZTogg5huH5uYR42ysgHiYmuDMUmw9wjM99BLvFrTiuWymhCDkXhNxkbPZTUhxksi sXd4y7LN9t8vDPDMIAQVrChQ3lFtLCDDugaWmkP5Xw6kgihcgvtogqiKnvMIAgQj11CMa5VL SEEMtY0BI2n0nXavKy9qJFODyYGrMQUZzAzVYoolrzUQA69jBySuuE/evjTa2gvGc/4jxCAE 2POlnBjmK2/awLhYgfPXLjvce1MC1ywbMhhB+WyqE6V4aRwnxn3JxYmmZFiwL7CL91GmXm/D LZ1qA4OReO7lNgLnIUQMooI48oXiX6hLEpF50wphJpdM9o6qvQgZxKQm10xuwVLuTMS48Fcj xyA8CufrXOyjEaW+v8hLkj0zGMmmII9f0sqRPDCWszlmBt6bcieyeAFiMAIs/e425JV9b2B8 YrXr/TuzdWJqlaVXamAQ8ss2i6nFNfWDjFeaaz1lLCYuqxcgGDF5J0ukckmciDEVv3H3c/D6 or+fb17zPkZRAbwct0vL4cxg5C0qgC95yU03MJ7FPmrYsmU8LG32z/Lv/wFHz2y2ZW5kc3Ry ZWFtCmVuZG9iagozIDAgb2JqCjw8IC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWyAwIDAg NTk2IDg0MyBdIC9QYXJlbnQgMjIgMCBSIC9SZXNvdXJjZXMgPDwgL0V4dEdTdGF0ZSA8PCAv RzAgMjMgMCBSID4+IC9Gb250IDw8IC9GMCAyNCAwIFIgL0YxIDI3IDAgUiA+PiAvUHJvY1Nl dHMgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gPj4gL1R5cGUgL1Bh Z2UgPj4KZW5kb2JqCjQgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAx Mzk2MCA+PgpzdHJlYW0KeJztnduKLUmSnu/rKfa1YHz8fAAh6F1dPdcSBXoAaWZAMAKN3h9k vjIid0T4+mOF/R6rcldruqHZnZnxhYf5ydzcDu6blf/+g5P/qTF8+x//9sv/+aX/JLUsP/Cm peLrt3//51/++3/69r/ld6Ykm30r/vHc9v/9g8s1meY+KO5b/+9/+6dvH//493/95R//yX77 1/8rcO9j/lZa/OacDx39L+iH9vGTlF06/TMfov/4ofXlx7O2v/7jH/L677//8o9/s99cNDk1 +U/99vu//OJ+fL0PKX/7/d9+ke+2337/n9/+s7Up/5dvv/+vX4oJvjqffvz8L4+fO2uSiKjI B6+/ib8+fhOMl0bH9uMXqTx+EY0trpVUfjwB3hG/P35ejUvO2VIvvMKhJz6a+9vvHzJwr2Xg Uja+SHv8CvHf8w5yQZAjxNqgbkm2JiRrW51pyQA56Q8o96pue7Wm+OjbTNOPDEaGNZrSss9T 7TgwbEqLBGu1OaZBUE8k2JDM0RP6d+BJgOaZultlBTLFhZmpcUQQneqTDIyaXJlpxpFxdWXL 8cc4iH/b/CLE4881n1SccaHUmak+MBjRlmS8LBZToj0y1lX4MTJt245AJNnU7hqywXpjWw4z XzQwCMkGm41oCSFMtePAsLFs5rwHQ3Y7MrfrUHPPf55tPAp8eMFueXLJv37AgZ8XtSRTMzIm 4szeMjCYHs3ByGIe00w7jgy8WEedXC+NjN1ihh5ALy7nQ0YhyehlTxBEnJDkwCB6NAZravBT zTggbPIXJtBuf9/0w36xvDIVdySwCMAh8xfwAjAknVMLuGUjvKmpOzCIjhaFWIbt3NQdGNZ+ Bx3hP6ZQM6UkGaKbxfJvYDLC4xcYTVatcaRQTIrOzmgcA4PpiuiMjE47M+kGhnXtuZwcGOIu gZ+rd6dUovGupJl9fmAwci3V+NqmptrAOFHYsrqBtZpaQpkagEcGI6jmTYsi8pl2HBn7Rbnk zSK7WcVt3iwFX6aBvTgeIs1CIeIsWo6Vo8nMWBwYRFfnXIytqcws+wPDRrB2pF/V7OpNypsu OHziKaJcNeFhIwXadKDBCNrjPHhFUqgMHx/kojdR/k1awRBENXpWSDZJjoHkSoEg6x4zCmvR r0a573ar7RMaNWBpT7GmpVSnvunIYIRbkrG+VM60BBiv1ChN+5qVfiuWWzoAg5FTiyaVZjn1 AjAYkzCc+gpF4KM5oumYUHOYmeADgxCt986I1h44WzFg3Cqo4I2cHvJM3w8MRlAhGycLmZtq x4GxPwttBQUlGH/TbnDwuPWrWga5mtxsnOqLI4Ppi+JNyT5wqhVgvDI2adpXm5HD8NxYOTIY ObVgXMhTc/uA2Gk5O0vNC+v1kwfQaQHqcMi+Cy3t30GPIiveTvnY/sIq1NqyGDmdSTHji4lT RjvqtYqHozs+TChbUf0EUs9ePXFlPC+f5KI11duQqF0TQjQz6xMiw7b5ECgVEkLw0EcqCT50 XNoPdjvL9SPu+gG1yrHQcWYsxGB6o3n5zGApPRox3usysLzVOzn8ylZE7RSIQUjQOzmhteZm JtbAsCkgQaHlBZv10RM7+70etd0VNq19to1oxFmDia7OdeuRwXRrLSa2qXlxRNhkHwgZdN7W Uuww/E9tcHsNYDvDthez6A4H6h7XVbTls0JoJgfHWawRg+ihEIMpNnAWa8TAgv2Ohvj5fafm g0S/l22FUzoRgxGs6PdyMM0zY39g2PCh5I6XWiGgX6iHZrTehFTcTMsHBiHBaLOJvnGXZYjx 93PVj26MNRIuXQzWzUz+gcH0dHUmNO8oOx9isD2qaHeyydSY0sxMGRiE/JJtprkSZ2bKwDgx 3ID7cO3UUnjsrY2Us5PNdkpNHBiMwOXk5IJ3MwePgWH9357LaevJkMrGIU6/tifZUXIMbkbt GBiMAEt3SJUxN9WOA+M/1vaNdHIsJtsp9eOIIPo5J2dyqW5GGxsYbD9r3tndaRtpPYvhaADD J3Z4EJ33xV2a4XwxIr1I7g4IohoMCyQ4U1OInK8fhOxn36X7MhwZ8JUhA5rDTviMkqjOkvZI wGB6trsEVZ84BQ4wsKUQGh0vLQxPjJGKT/WuGesTqTMDBiFy74OxrXDxGIiBLWY/TfTNM7vL tHeVZnsNS1SANTIkw8yIHxjEMAg2mpRT4Cx9gIH1E+hYDX7ur/t8rI0JfUxa7u4SMRjBhmIc GcMGENZfv/FeEdEZH2KaasaRwUgjJhNsJk+6gEGYCaEnLFoIflN/qZwqfE52avwdGYzEqzUh kB54iHFy8ABX1dAfFfaE4lY1LDY62fhjaTM76sAgJB6dN821KYkPjD8uFEXzpXKwc4H0D0EM RuJysvOWNNU/R9ziLL+yszOl2To1MI8MRkw5mZp9ndE1Bsala8grP4dmQmwt0R7f4aIF+xpN OoXB7ENuKSTTQp1SswcGMQYeVktnScMdYOyDp7bhDC9WLU3DUzHNe/KCETAYAcpEbE2Wi5l2 HBl4Tb7gjDY5MFswpcwsnQcCI9NWHrvuXCsOjL3n0IWIyEuxOlv/PoUz3dLIHB4qNPZ0PmUM eV6wwQoejaEniz4xhf7lLwxW4xFfERIR15QpzYQkHUsNJcBQDemFUYKJPnJRU4ixj1a65CWn sQUub+3TuVVSfQUMRoJ9QhdLLgqA8WZnuCWHhqtG/k1eQwMGIUHvvQmOdcAAjJOhpg1Zg0eX pZlTYRdr+2WrlcMUF5+CGExfiN4ca5xsx4GBXf2umVk9uMn4mSJYFTIOoh+nRN4KPUcQPf3w ppMNf2blHxjYlVA9I0Ky3eMxz6xOA4ORU4rG99E51Y4DgzlFXglEunJOVcQhrc2v2dSUybME YDBd0ayci0R7nmnHkfHS+K9oYLShdwN5LwgYhKCiLcb7MNVhAwPGoOtXwOiDST6RxznAYOTk i5EDWZnRPAaGTciuo7Yt35D9aG1lkrNCaaSHPGAwEs9yVpDPn5nCAwOHYMOpjfSOVy7vKJ+R QgTJRuPq3P4/MIiuSFZU9zQ19o+IEwPbLvFhRb5CF25iNKajNXOPQEoiHYIAgxF48nJWKlwG MsTQm4/Ud4r6EV5l66hTu88RwYi7ue6Tb2c2mYGxj0gIm/GwjUigvVaXFC09wL+x7kWAQUgw ezllZNaGDBj4CHfRCH/lpdHLX5BJbuKQ5AbmrIHBoHB7QXZNZ8ETOyfp7RMw35tmvC25Ovp9 g/WZ9DNHENWIWyD9xqGIosGtkQhC9CC0AUM78x+Q8Qjdsqizoi9nwDHb4l+1Peb7VOvwiQ4b GMTI6Smfc3OFuzAEDHx58OLGddQfd7bCrWFEYfheM2lUE0uYmqwDg5F4TyQWyQzZiLFTZ/YK +A32tyVVRM9wTOuDgEEIMIg23HW5GQEOjDeHTC5vjdaE6tvMZBsYjARjlJNgnGzHgXE4q6SN cfONR5WlMaVNaH6AwQi2hgnNDzAuBXxNjszukGbLlPyOCEJ80cnqILOSO3oAxjUl5ko2dHTQ Q/YprXXlrX5Ki3TkfGhDTTNr58BgeloOiKIZkHkNAOMep76ymGic6DSRy3mIGISgetxvyZnL xIsY2IUOacooNPdS9Y3dLxAJGckhSK2/pBy6ukymGQEMpktz6anlSA8MwFhPwpp2FFEiiyP9 agGDkUfJPVCYjEEFjC+ynH60JjuZ+DKBZlbZgUFINjuZ+Cn4mVV2YPxcltOlkb1iEO2CDRiM wFOccMEGjN3RZG8i3R5NdkZVRSTz8tYaTaus6+KQBxBG9b2y/V0S9sfrnAvG2VC4QmYQour2 FVL6qZbMQAwhf0Rk69fkD18/+bGL+USGRyII04PFiYrEHtwAg8jQrI9Rf1Ve8YnNXGGsbIu3 oiwOsgdwOzRgEL00F1QNGBeNlZeM2dizUWGuXNop21G1mfSfAgxG5n07KpXUzgCD9jLVNLxU k2Q755QwwGAE2G211ZLGNsDAOYOhI8a5NULxQQ/baQ1kzDNgEIIN8hchpalVaWDckmJwYfss Z6NKxtwDBiOnYOUvLHkaAYxX2bqgSUDT8B4J7kKeWe4HBiPA2EyoKXMHdsC4Zi6/FtmrVryC aPvRy0ow80VHBiPZWk1srE8XYLz5KqctZuZqcrBcvRnEICQYvTdlbm4fEfeYURd2EErNZNA+ YDBiCrLxpdpmDhoD4/83M+oihpaMd468RwcMpktb6yoEmVwRMFRm1PbDpzSTBdQQg5DHw6k0 JPKmADBwATW0F6nVpORlFbRtaokYGIz8gu8G16klYmDglI/n8ntyOXjb2qFfxVMv3hUL6SQE GEwXlWaciGVqqBwZeBV/USZS0fBsrQmW9U8ADEKAMqBMKHNmroGBr6dvWyOyj6bESjrdAwYj P1lnqrdTJ4GBgRMlN3X7opNJFsgAIcBg5CSnLufYIAnAwLYhrYMHSlFT1W2svRhwxR6YZ4w0 FEB6663J8rq5WxMI0QyST8jMrQmEfFHBxLU9oZlWg+UKAUIII94oEkjJcjHpEIINiercI/Cy Sp+PFz7x9fdh4y8UiWWWbvC+dTMgzqV+yhjyTGseHrLSEFXaFLNoSezhctcx3I9kj6qxiyCq WbRAvDUxigJNWVgg5OTaTh2UoLjPW9vT15dWAhd9ACGMePv6khsZcg0hNmRg6SPuUedvpNZ2 VmtKcHFK6kcGI/SeytuGSGlniPHe1DvLW70VnbAULiMlYhAS9LYZ0QETp0MBxp+9KPz6XSmZ XFn9EjCYPkoy+1Pj7jgQA/fRRqHY37uCkDGNark0pjZTW+SuHBCDEWwLpuU8144jg0g5DCV+ 3bywtCa42jNAzYzYI4KQa/C+53+q1OEdMfTVDq+cpvcPaMvg3OD3uX5u7SGrqXKHLcBguq7m h3FzagQdGbfcw63wlk0OniuShxiEoKIV9cVGrhQvYrzTALm+0ztZmKqfUd0GBiM/L8pLslw+ GsS4wwC5svsdaQlTS+nAYOQUnZy40lx/HRl/lAFy+LkiT+radlHPs89TC+PAYPqhVpNbnVoY BwZdnkDR8F7n0HIXXs8JhPBSt7LGyKVIRQwm/BA+cYNXwdrOnvw8+TAl8SODkXlPfu7j1AI2 MPDCccGL81IqNNgR6p1OFCHjXbAz9q6BwXTERyYjOzUgjow7cvEt7GyDEf7U8XJgEHLKtvS/ 4FzoEAMbvS4cxi7FTP/ltB/Gn6vHcc6hn3RnFKUjgumdXPo5l0umhRiXU29egVdr6AvMIePT 97A0bEjHVIE9Nn3XqVREiUx1gAwda3NpYCzJlkoxsXDx7wChGp4LQs6+KRbOfRQx3mwJXjLg WDm1e8elikAMQoLdmtxa4JITIob1H4zFN7xEsNBOFnLQB6GRdYo18izebCc8I84DgunVkmUJ i3Oj68hY6/o9WbbRLkmm/HuSQO/DrdX5nte7FDvTp1eylMAcsPvkXnHT3K2Hnbsev7xIO6Qm 55wTj4lTxhC/rHg4D248b70hz6vfy8wNOYRo5soKmbohhxCsS4QEF0d4UYYCqQk/EPiO6yrq +tElmRoDF+KJGEwPlmaaS1yIJ2Lg7FR4e4GBuPri2cgiB36+rEQKoflQjXyupQwFiEF03iMJ ZIjcCQMxbvGIW+GpGwNqmBnlA4MRVCrGN8uFYyIG3tvgFq1eJrzo+TlHrjQeYjACFEW/yEpD WTwQQ1/HFJeyUd83opyZ+qU8+Nadurm6i4hB9FEvaV3lTDOzlA+Mi3WInoRIPHniSi7eMHG1 h+wGL8q6jCl9rzu+LHLrFUia7E4zK/HAIMZAL3IsOiiXug4x1u1c0w5XTJFj7cycGBiMPLwz NSfO3Q0xcP1bdJeqXZ1eHarR4U8jmZxNLpULZ0EMpoeKNSXZqRPEwLilQNEKr97Q/rKIwQiq p96MZFwNYqgrpv5UiU2Xr0qyaUVREGcW34FB9FAKxaQ0t9gMDOvT5iy1TfS2syhsRa63KKTU 5K2Ri6dGDEaCPcWm51x8AeIkGeRX3LQurczd/OxamxkqA4MQeH6Yn12d2QUGxtWb1its740/ M+ieMobgF2zyQQFM+BdXymFNorCV/j7TlUbXDYu5pwc+Nq4GLmKoxu7KqHIgd+R5BzD25bh2 15i/AtFqTvXLW3uJJDZEFjEYCbZkQi2c6vUcQQQyQDsevLfQGKLCD2sbW/UAMQiJP6xtPpOW e8A4EeGFsop76wdyrH+V2muqZur6YbV7zTkuiwliMJ3Uut9c4IIcEANbLaAz/p/cOhaWyzlR aD3nxwgQRJeG7IzoS2mqGUcG7Yt6/e5WcYm+tlIWZGsLF1SJGIzEW5+IjavUgxhMZvf5nI5L a2KwxoYyNZQHBiHZGKKRWUmeHQDjloCTFR5jr33BBSogBiOoWHvtC67aFmLg60U0t5GxUGlE VFtq1AM8iaoVRBueGeADg+i35LKJdk6xHxj3mAQXeE855ucG+MBgBNVTjrW5AT4w7vCTXtky eeS3nCMuYjBySkF63YYpOR0Z6gmpNvbrj+apR+bHSBrTAYMReJVOc5lLhIMYIvtFgC31PwK+ pZfuXdR7mjwvyl8kr0sAg5Bs9tbkQqaGRwz93oKG+O7IHu1wz6BpZffAjyd3JqeMIXUNkekf WiwSegJa32Byrxdea5dGxpoJpVMSOTIAQzVCF0Yvt+5LJu2DCPLeBGnra3MzITjSXwkwGBmW INpLCJwGBBhEbIPenHyjWVz/DmgWhzMWW9ih1+ilHE0b49wdTibp07m9NMcVsUMMYnQ+vNuz b9xeCBj7tE3be06YEx87nb/zAm+TbKPfek3IYGAQffFRJMKRRwDAwB5Zejk9HMoaF1OLGIyc QjGtkMEliHHLUWlhp2h8CaS5DDAYOaVqQkykLwVgYFvHXUelO4wga4aRYGTr5GKPEYPoiGiL 8Vy6uOeEewwgC9o1I+cYLqUMYjBC8sGkaLmUMoixqhGadoRe7deRljPAYOQRerXfQFrOAEN/ vIYR3ty1iEYAolYk6cCp2XtkMB1RrWypmXQFAwx9SRCke166h9r6dCuy0OQ1+Ug2Uc6SMxv/ wCB6IvXoskqWt0cMLHCFYWmTuCSTdqXnCEZKPW1JqFzyeMR4ee+saWDqCZny1Eo/MBhBpWSS q9ZNtePA2Mc7budd+Jioy33ntjDwDcUS1+ZUmWXZT21eA4MRbZOvDHFq8xoYr8KlFe17ZGyR P5lp38Ag5PTI2BIK6bMJGFjlPnfTHn6+FFEah7I6akc9kHO2Jls/ddYcGEwHZfmLErkimYhx NVHfFXa3vTQyXj4PiV/emvJjed1kyDuCqDp3gcyFvCPI30Nk+5qaxoo2wingTwlMJ/WCUyFy 9X8R46eOalcIx/ciRJY8uz9HEF3kgze1eNL5GDDuiV1f4DGYyFaoQQxGUPHh/Uha/QHjZMjC leDn8i5dPqwlk52fWowHBtNJrZlcY+a2fMDYmZefJZZXNDC41KtMkkojYBCCCq71KpN1psMG Brx7e1VOWdPwIL3j7NRyMDAYAcqSkqsnD8KAsQ9u2Qhwn4xsY4jxegFm6QYXKqedAwYjwOKN q6lOdeSRoT/doJKeyuSYuzRau3AldDmqqEC1fO3Dadkl8rwwk1+r3JFf6/qmUu7IrwUhmrG6 QqYOGxBi/eJG70zsJ/ZNsl69b8VJmNa1xHOky876dbU7HBfOVQYxmK6q0t/sRTdi8KXCFC3v qTBrqWlGggODkOAjFWbiNliA0JT0XhGy19XgOO81xGCkIX/Rs01N9cqRgRPrMXP1uhK6tif2 rLWOO/MhBiPb1NPWkik9EOPE+2xrpxm9aUatFSZQUq+OvsrWneLclx4ZjMRrNP2INbOjDoy3 1oJYXhpsNMlazuiPGIQAg60mFc+d3xADZ6Xd6/3bODuF4r++NgTTz/aUSRAxGBGGIt+Zuah7 xLhUZfZaRlx1LS34wBtTNZc1R5g1ObQ8s64MDKJPo0ytIqr2zLoyMAiL1p82WTOZeWkVXSnG O8+d6RGDGQbVGdkeuDM9YsyVJSRjjZfGiA7bS71yRl/EIATbCxlVS7p6IwZ0m93NCrc5TED3 TmRF+e35oqy4BVgbn0JPQsiFeiIG0xGp9CSEnJ83Ykzs/49LsFQ24ZCKNMpre2p5VOOd+qYj g5Ftc70aL3dniRh7R4jtYPbqZVZ6xuTauAJZiEEIKtseDE8WS0UM7PyEowlf+DtqPim6Hq/O JXVADEa0MfV49alzxsDA6yNM2jOZePRKK0swzWYupVsZUrq91ftked2kQRhBVMMk3GEQRhCc 3AxXo9EcBJf3xtiNhGQFUwhhxNiTCkT5gykxDpBLh8Gvrdyj8QZSCFQUeJPogwBgEB3rZZLJ QOWulxGDKQrGBit//YnwmbFC0wM9AVslq94hBjMSegK2VMnrBMDAgZFqOT2MgjlxJSkQg5BT NwrmQJaBQ4yzPF3KUBXNkW1pTfRGdicu1yNiMJKN2Thrp9bEgfE1RomlMcX2an9TU3tgMIIt 8heO9IhDjGtGCeSqCZNoPrFKKL40um6TclxpEcQgJB5dMiEFruARYsxaH3YuuNAPRlFObm1o T/kWYoBubqeMIfHM8LCX02I4PietPjy35EOQV3nZbJof1DPXy1K43Lau4p+CyznuzljLbE9G BmqO4UcnxLUTSqgxbD560QmevGXY7M6+SE4ZpntsnYUX6Z4fx+/p83Lc7COCff3xceug9IeM HqfgZk1N7mRGaZ5WyqRlmUAlnfgQqh5fZ/I4utaZ3A0Te/PYcHw8e2N39O45dU7M0KrHdeLq iZ99Kmf7jerxE6ksWweedM8mfYG/QXP75BHcgO0Kso1gG06LZ8IIQT66hTMXENXjup4M0Zno Gjnuj0/bELZLdCmDp4YsXdLBbjj+qZZuvNwnvNxjGlzv8QD7i0JIUTTW5h12Ej/bPWsoR3/P F3ULnvh7InPHqyeu6ENLA52vJjU58FCnSwjRaGYrpKfvzI3La4MYRHTInZnCsMFDb4d5Zzn3 RXzetn71w2U6QAxiKHgX5PBM5jhHDCKhGw5LvG5WXJsTiinZJso4gRiMaGXlr8FzSSQQQ+Oc +skQzctxvs4AwUgjWVMqeReNGNcuctggnvWtxQmlhakpcmQwEizJ+DDZkUcGvkjdlhDb3dm/ KFQLjUyKTw2ig/hMFvVADELkQf4iBLKoB2KcZOSBpnbtDavCr2JtZs9TFxvnZo0YjMgfRlTH JZVBjJOgSHXWR/gLdNl93WS6Nr8UY2WxmNENBgbTFVUWLVksZjawgXFLfu0V3pxsS2T2YsRg BNWS7EtzQ/aAeKub+vLO6LJxmctGChCE8KKXdVpWjhnpDQx1Bpo7KlKtjYlygvdcLkiAYMSa ZOI1z+WTQQy9WPWDUjSUbjqdEt+RwciviObjytQBbWB8yUXc0phkYw/En5pnA4MQbLK1B+Jz ERWIceb2d1u6WNI1fibf3/q9WY6jlgu2BAim5+QQU0rhcr4hxpdOiZaNl31jZq0ZGIRgs5Xt qyXORRYx8N30+89vuaf68TbPDNiBwQi25/oRdX9GxRkYt6VhUK9Ainooa+NnsrbVdDSs7z10 ynhrpKmJcD077NKQhzNs8sVzwwpBVONqgXRnWB8zF+ICISclJ/Tp3GCHQNv6h/vhTE7F9cty r9PQUuIWVgRhOqpnhYturiFHBu8+PhUPvzanVVFuQ+UOvYBBiNZb3w/OdWYyDoyXST6mqp2u b/W9NETl0icjBiNB30tDWC7/F2JAd3LsRKwu5HPpemeyEvQd+d5WGTVnkpxjZxaBgcH0d0sm NTe1fQ2MEzfs64kfFvjDJdf7xumhgEEIKrheXjI2zvAIGNcmxpUa27BoE4pEhVl49bNCHWQO dFJFIalVoDX0gj/kuR0wmMFRS9+7plbvgbE6o2naMWV8BgxGHjPG5+cI4kyuHpfX3ZqXRkaf TYmZcydGDELePbFddWSMCGLcKXGFdWlpTQqyZCeu/gliMJJNMitbIe+9AONWQeXaveKnlp6B wQiq+O4VP7X0DIwTswNU96COptbJY5N+s5UrIYYYhGiTdSZXy9XgQQw61Yum4a7KGh7J2zzA YATovand5DDTjiPja2yZS2OSM6E6rsgeYjCCTcnIKju1Sg+Ma8HH9xbeWNvSq784x0XcIQYj 19brNJEphhFD5R68Mno8ZOKKBCEGIY/cbTI2c1HuiIHHE9IP1af87Itx2XJlmBGDkV9wxocp Y8MRYV2+dIq7gn4UFwg4sO+UUY4XApqH2/FhzZnr42Fn7YcxilMTEETVyyskGhfl4MRNVwT5 898ALF+W+hVR1xdnxDNAmI5K8hdZvpLT6BCEuQO4oczI2p5SehlUUskCDEa4teeztVy+YcQ4 Ke6uvxyA6XX/chsKN1eha37Iwscqh7LTsFc9g+hXn7yJwU2Nr4FxbW27dm2gttlu+3tvzFVP vmCDKcWeBQTqGUQnBVtMjZ5UoAHjJAWtQiNb4F42Wlk2Z7bIgcEIykdzGgasJWiKPa+E4I38 m7ReAgYji5BNyI4r5IUYJ9E2IPXNFxR7XhtfHvG1pM8XYDAd0R3jSySjeQCDiE44V/muX1kp ij0vrX/k9qiV9KEBDKInPmrKz63nA+OtB97lnXKUa3J8mFleBwYjv1hMq5lLBoUY2NAEVgio EagDfPQd0fo0JIuQIAbTES0ZH8vUfjswoOlVfyiU50XTb2RIAmAQckqyaGTP+mEABpGHeir/ +7Wct/rRT5YBuGE9S610lyo7s44MDGJ4iLLZXarIAB7AUBvU3V/V7/TdRYmsuNbc0ToHq/6E Nc9DS17eCZZmMnnu0g7nsyjcKVaqEyBEMxpWSLAyq0rkfMghBO9v0GoHLRYwK8Wl2kKXTIZ3 ZL5YZVFrj0zl0jMgBtOxzffIVC49A2JgY5A+JQZ2v4RJNLSunwof/OWLfYzGF8/lykUMovce Vq5IFu9AjEuRGjBr4/4XSGu65Nk3JomFFi2FzB5GpxwKZYNADKLvHkankLg8SIjx1nK+60t9 lWWczPuPGIwAH4YgMu8/YuhdAc5Pstc91r6iJNUqBTnu1Bi5HP2IwfRoa3IOz1PL6sDAy9l3 0NPKM7d6ZJwHyCnkFXMwsbQ6MxMHBtFvMReTkuMuFxHDBpjMLCxp/YbS2kvi1zHHbbh+Dlva 00sv2RK4q1vEIGSbXDAuJi5jM2Loq5vo76DUG3OKuZcF5eo0IgYj8WRNdokLLUOMt2YyWV/a Q/Sa5SxwiMEIsCRjs+cscIjx08QbXxBAdq1f13FZMxCD6IjsQ7+wmzrcDYwTQXk1PPTE5o3L F96GjKd/P7k3FXN/SUSau+U8cDeaiKEaciujW86T5VJpQshZzL3a0+iFgqf42qnoX8QgpO5t 7qFLM51/RJyYS5q6eX0tc5bc2QGDEZOsZbZ6Ul8GjPeWUVvf+nBYLeTWDhiMBKNo6Z6sH4IY hH+a2kQFo1UVm/vS/B4DHQJpuQUMpivkwJ0tmV0CMW6JE1vgcu4xrrapxXFgEIKaSqOKGO/V 59dEor3Kd+IC0RGDEWCIptjCBaIjBi5hA+0m+ryw0NZ2X/m3cyOPRsq1Gd9y5U5NgMH0dgsm 5MqlwEUM6yOwzECX1NvObwqfrKX5UY4lJToushQxiK6IoZnquJTbAPFOj6z1lTnKWkmGTiEG I71cTQhkMTvEOCvPp/XaJHeQGffP5bNST7pVLZfTGDGILko+mpQ857yHGHeEE6/sUHo3u6n2 HRmMnKKTv8icUxBi4JX0PJxY0+7sjQ2Wc4pEDEZ+udeC9Fw4ImL8ESrgI7S35DizEw0MRoCt 154kTeLPEXsnkQvL3H3LX7et1urjzPI3MAipdttqSzHOLC8D448ylGu+M/dDiJ2yuwwMRt65 H0L81Il0YFw+Ml+B98IkO5ukxh4+JCr1benBo49iQtbtO/KUtjXFaDMiDxEVJW0EUXX7mmI0 mFyrtdzyhSAvC5Jrmhh6aaGt9ZBp4gBhhBWtKc0VLjQIQqz/m9ZMr7+buVrJ9ooYipxgS8yc 7QUwmO7o8ckx56lxcWQwzss3hG23Nd1pMi7EqU8aGIRoH4Xj+hXrVDsOjGv+Y08clzUN77m4 QybtgoDBCFDWm2YredAHDMJfGzmRH+6jr3xRDrJuJS7LEWIwks3F1Fy4LEeIQZRjhyr6lcCZ vTVvPmNSW1OaJtNCJu2TgEH00SMm25IpJxHjvf67y0tlcw6VjJhHDEaAMZqY4mQ7DoxXqbmu j0x1kR/FseiG3KmIwXTERO5UgLDBITNp+KzjHKWxdVMKfaeVhM3evhQ8Hy8PNKb9JTuiDNxE 1k4ACELiUYZtjpvq1lQzDoy3mvbXtJ3NWNHFZ6bswGDkJ5p1L7Q9owENDCw/kB0AJrTWuvjr degeeJtCmjpbDwyiI1I/n9viZ5awgYFDfHeLeL6QWfSFzfB6mDKcQ7fpNalngPJza8LAYLq0 9tz62c3M8YFx2Wn0SgN7dLNrnrOaAgYhqB7dXJub6rCBgSsR7y7K85VkJ2g50459RRnd9bN6 bGMki34jBtNFPbbRRS49IWKIQEAX3V3EbQQtzZ+zNS/fVavxrhbO1jzkwHyvF2RZrMG5G9Qc GaiGIKqBtUD65XeULuAmP4L8pPHwXxMovwipb2kpkqYQwGB6vPZUJ+RZ7TnizxkmP/b2blFi bcNl8Q3uaRvZ0CHAIHr7kbbRh8bp14Cx6+9nRYqe7CiwlBQq5a7PfQbT5thfQasUCZcXWcgG Kpsoea85pEzebcDb6aHIpdx+JB/+uAShehpBVENuhci52MdEmtMRBAdF6Uuh4YmusCS0zxtC 6TzLlbqAEEbuomfWUu3cCBgglwyRtD60vDVXk2wlHUQBgxFh8SZVMuk8YjAhX4o6kutrZ+pI IgYhwrlIMsAgprh+EPpHtYDGZUlGDEaCvVxAdFwWbsS4loDx2qp6JQndNjnsZt3eKwvAFIXP hurV2ddmmm1k8gPAYPq0BdOqI8PNAGMy+UF47gC07yLFMWfNrSxDrLDBUoBBSDzIDIiJDZYC jPfeai4vTc5Un0inCMBgBJiSqY0NlgIM69rzIbto4qOh6EWtlCcPgEnx6gGFaKK1sj9VLtkz YhBdFEVdL411TAQM6CtBlAm+ojleSDWFdpw7ikivYijSHTVzaeURg+nSIl+T6pQGOjDuubRY 4LUYWx1XUQ8xGEH1DMspzHXYkYHt2GhOaP2K9Ip96mlPmyN9fgGDEHjqSU8zZ718SngZi6pp XI8JKtbPbJoDgxFS7MGS3s9smgPja6rJrq3px+rY8sx8HxiMZOVY3T18Z+b7wPiKeoltTSkd upmAzHMDGIRcsy3yF35qeRkYLzecy6F6GseopTHBGytnhxkr2MBgBBtkzS2WvFUHjDvXzNzT l5RCBo8BBiMoOazk2MjgMcBgwpuht9O1NEtXmlmbERWZShMW7JDTXe+iP718ra3oydibSDYz lhUMUQyfT4gc0m2wXPAhhrzVD+Dztak7j8ZMxShhCCPFXkq45EztRxjyH34Ag5C8y31JonID QwbR495b+YtMpVyHjJ/IEyDaK7fPl9WLz08WHbK0StV0hAym+0o2VVSDqe47Mq5F1uz0Nlhf EIYpQA1GH9WzvfGvduOliR95kVdN0QPduGlLpFwrIIMYCSGJUhG5NDWQwaaP17S7yiwohTJ1 QQYjvyqzgIveQYgbqmytaFnGOoTyQIUMQkpRznjeB8oDFTIUlTc/Gb1EYImUIQoyGHn0EoEx U6mRIQPnfffft8eZ7RM4CmmXXH57AtqFsG9Gpy/oievH8M9vq9Ek8hgOGUw/1dqtetQxHDLO Tpf65H6Xs/Wu7UnyFyWEmU86IgjJJldNFQV/RhMaGCcRMLdl+oeLM3oD2gp/U4ssVxMbVywL Mpiu6z5KxVHhb5Bxxy3TJ7z2W8lIWZ0hgxGUzPyaM2V1hoyf+BJ8wv66fm4OxZRUqdAGyCC6 LkdnarBT5+yB8XOZFT+bWT6ypXJmxaH6wLVD4O6oDksG4NP9lUrVT2yXl0bAkn0/eeNapTxp IEM1EldGNr7YRu6UCPJmC+Xy2pKNjAHS3AEYjAxrd5cpVDAnZLz0HtX8QmE/WAsBBBn8jiow ARmEaL2TSdhC4s7hgPHSeqdpoH/kTiOVAcBgBBUemdOm+uuA0F/h3JDY7rMxKUlj7NScGhiM XJOcd5OnktNCxolP63kaY03DZUFxPlP+d5DBCFA0XdmkqOy0kLFTOq8lU0JjWb1z97RGsqiV mSVpYBCCDU4UK646LkK8ci3RtG6inAFkMFIK1ZTSSI0fMFSmwYURs2nBUZXeIYORR3Km5yyd 0TsHxrUwrCuuiVeyKey0fnjFM1+4df3caKuxokDMDKGBQXRdlCOME7HMzPiBcbeXGTrVa74z FuOiKzMq1cBg5C3DXHTYPLODDgzrE7Ciw0tJ/d7fsy556YSZLWpgMBIsxcjePbPmHRG3p/9Q fE6yzpRgqcSVkEGINdlkqvVTch0YZxfW20V2c0q57i/++VY5YsRmKQd9yGAk2MtFZE856EPG LRerCzsFUzNrYgYMRk6p9BSepIkZMAjtqZeF6Ma7mS14YDDyKHIgSo1KSAMZtEOypuG9LoTo sVMNPzIYAbbYa+HVqaXryJjMzoXyf81N4dyjrbe9SXzpwCAknnu0dbeCzLTjyHh1P3B9Ez6v 7HZHP5Rm5MBSZg6iA4Pphxp6opqpJWxgXFVurrB7lcposd/JKWOoikHY/+eT36/tcI+b+xLI fQtBVL2+FrTwppYWSCdqBMHZ2KHY56q/bn+xu6fd1cH4Vf1luZhcyPx4wQ758TQPDwmPnPqD HRIqfiKR77g05jYJe7xlRz+CqEb/JmFP84E8iCLIiR/+FTvR1dthXGoewi6XpFk/zvcoOR+p HMuQQfSUt6XnkiWPtoBxcoWpLkfj/qr+pK48xULq6oDBiLYrT6LFcQoIYOwz2O5G+h3b6PLW mE2ukfQIAwxGgsmakjLpZgwYF+/XkbMMSmCgyLsCMxRqRCNaW8qNKisAGUwXtSbaI2uzBQzr PxhPHJrwBSpez6+kQwjDRcGLq4Vtf8OoEoWlcclNU+STHWs5BQyiW0PpTs42zGxPA2O1G16/ LdLLr8Vu/p+ZFUcEI73Wkz8H0okGMPQFZdWLSnf9D7KRz6y3A4OQnxx1TZTNY0Z7HBj7eo3b AijQxRo6SWqzwOoXgpiDCTVTmcIgg+kKOaiJlkE6PQAGuxA8ydiuPiT19Dq1WTJEBjAYwcrm 27KfbMeBYZ3VtiNZOe/FQBVvhgxCHqln+XWJqh0EGbeGb+5Uj+1t2LnTsEYGKfRcXVQhcshg +iKVnquL9FkBjHcW9P58aZFNM3iqYA5kMAKs3gT2tvM54iQG6VLs8rYUyQsjouJDs5UVyMn/ m/jSgUEIPNtmWk12RnMZGLhazN3710wS+M/mR9ntE5nGxQ1pXH5So+h1nXb5pDmjKIRoxugn ZMYoCiF4NqOsFzhcQJ2bRGGdWz+g9GxDmfMPRQymN2owrogoZ9pxZJzI/IXpGFquFZ/kRWlJ zldqMUYMQrRTyWQQQ3MfsjJ8DydObWbmDwxGHv5xoTg15AeGRtVfGROhIgDBSKOHUWbLGZcR 42UI1IuM8VdK99xh5lvbX5McmCKnpyIG0xc9i7zjvM0AYh2Xo0rjrzsEL+xgu0rDHZEBghBS sMVEX6bmzcAgTqbaRNSz4/jKZ2VrQiN9R9wQ46t5eHA8+UkV1nZ9uKU7FFYEUQ38dIfCiiA3 +rDgJ66bDtZ29nhg+Q9l80AMRug9HjiQi81zxJ357y5lz5/bf/WR/op8EIuI+q2w0KmCg5BB 9LZPj8pW5A4MGHt/9KkqOReuSMkLu7XxMxrIcwTTDY8qNtVxmgZg7Hak3UarOTWnRX/IxrMh YIhBCCo4a3wNfmZ5Ghh7O9uuZvJ8YunPt/rcMwNxKbcQg5FgsL2cGRffjhhvta2vL+3Bn65w Dq2IwQiwZ6cUjWJmrg6MWev6bu+ct66vzSzV5FbdjCY4MBiRPxJaWqoIHWSc3KK/KBRxg2R7 oaNcPeehgRiEZB+FjlJMM/vfwMAVXLH3FNS5UJ08qAKw51qN1HKPpHKkYQ8wmN7LsacObTPz YmDAaEJF1OXKLs0UG6bUmoHByKmGHvXMpYVGjD9iz+sOBf2+Y6bhA4MQYLJVBonjMhEghj6W S2toup6Kcm1jFAXLFi7tMWIw8pajXSpcrgyA+NLt7iM9p58bP0cGI9eenjPHqWPMwNAnIUEL x64k+/YconAzW1qZrZNDeS4zXzowCIk/nCtiLTMzamBgUzRwRYU9gUb4+4rwfn5UEoptXOAL YjAdlHqeC8d5fCPGxZwOuy767XQSaVrTAl9PyA2hfepK7zC+Q01SpLBZ2u1CM666xMV1QYhq XC2Q2GdJSFTVPwzB8Uf+182qusutqJdiv1aSdZ7L/gghjBRFO4++cd6xiPHeHKnrW6t0kQ2c DyJiMBLsiabLXE8eEHtjzU5+MAbuncaa8uk5Eyur2wAGIfCH50zKpG8BYDDVqe6TbIg9lIO8 rAEMRrKhVwy15GUFYJwE6KPtavtzu6mO8yIQSGPceWF3R2k7FMIM1j9MsBOyPCKILu13Ii47 0kICGLfUHFjhrprQYyBnGnhkMILysjJNrioD470mnOWl0fds+VwsGWIwAuw5PO2c/A4InDQY rRxI9z9PujOmdrTqBQWZjvTXLmgFmg+9W8QcRf0urXE54hCDGDFRlO9aHOl9Axg/ldFvaWP1 Ai+Nu4sBDEbeNRvv29SWNDC+yOxXNqZnT17ZAgYh2YfpWSAzu+zAYM1+mnb77mbMpZ8ACEZ6 odd7KXFmfgyMa8riLkPedm3f6q9XLgK3II0xdWl9saYFzwUhIwbTEyUZS6aBBYiT2j2wh644 ce1WGvXAz04orZLX0oBBCDz3Ch5FhthUOw6MQ6qQaMFZ7GbjaNmYjAMuTXHKGFKX/UmMo+0O 4yiCqMbVmlpsyjiKIDasa2RPMeEd0K5Yw97y2lyNbIaB2w4Ag5Fhv4fr1sGZdhwZJ6W5rhgx roU5KhKjuDXDWe5V+8gILsAgZO5lm6g5k/fjgHFL5rAV7p0c8R23bzxHMGLyySQfSL85wMAX HPtsVWVzDefVs9vHJotH4lIvIAYjwiTf6QuXPRgxTkod3Gux0Hxod9tOjfQEBAxG4K0XCiEL ryEGPKVjR8AXpeiH5GfXQkjeEGug0WqXlFrZ9d2GdGMFDKKrQ07yF1wRaoDASe7OT2eaVvdy 8iGSTlGAwUivyUHOZtL5EzCw06X6sKXNDaYxS6ypzbo/TiTvwwCD6IkYrLGOKyAKEKoEHytC RJoLl4ESMRhpRDlPhpZn5sfAwKuoIq50Yad+A+pJjzTAYOSU5OwRIumRBhjvvUlaXlrkXGcr 6e0NGIwAqzetcimXAEKtf53kyFbLNfV8+95OqZoDg5Br6tn2m2szE2Rg3G//f1Im/XquqLWZ PSiby73vh0xRmoeHkP8/JGofWQjuyL2/fNJc1D6EaIbxJ2Qmah9CGNvWDXaFtT0zxibEYITb I/wT6UiPGG/IGqUo90GUToDN/a6Vp4/BxOI4YyZiEP3qYzEpktVaEOPi3Q6sA733oLjhdmdt aM8cRBYkAghG5D1s38opbKoZB8YdpfgW9lTIPWIQcpoKuUcM7L6hTYqvr9x7QxGE9bMeYdye iytEDKaLUpOviVyteMQ4ST9+/ey3wnM2ovNz3meIwQiqlyZInE86QJzo0eqFMZQiw9WHufYd GIyYqhMti3T6RAxsSwfBXPDn8wbZpY1RTkvFchZFgCCkHX02pTou5RJivNUgsb6017pOZLpw xGAE2GtdezJdOGIwjjFqP3f9QSQ2K1vmlJ54RDASb9GEfg6basaBgUO7dke/ne/XbWM5+WhS sFw9I8QgJJt8Ndl6zpqMGDYhJQktpeiu4PzvNd+Ze2XTOnWgHhiMvIsc3sLU0nFEvLSsaZpX ZQF3kUtBihiMmGoVLZV0RUUMwsn+ha6l8OOH2oj6Yk2RF8WvZY29sZkz9AIE0ac55EehqZkl b2DgpQPXNQFXxziKCVQ/OKRhvNL8avlQcT+kgMUWK1jyT6GzrjV5rYkpkAVzIEQ1flaIbHc+ eVJ/RpCD4rV1Z4IG3VeFAzRf9biaqJZzj4AQRr5RFJ4of8CtEwhyYi+Hw3e+wtDanEdqWMdV eEMMRrYz0emIgY1a7LqguNPAT7DJi6GPtkLOPiWTW+SiHxGD6G+fmik5T/X3wMB7ndaJ7ZVN 8kUuYtIIsqZlbSaWSF4cAgbRRcEFk2Lm6jIgxm7000fvNftqM1b+PbPdDQxGUCEY2wpXmhEx dloYNLDjsbmrTqUfg6nKSY40JzxHMILN3kQfORdYxLjDg2plF/mLWDi/O8Rg5FSq6Sr5VDP2 iPeaK5d3Npl7ouvPKHYDgxBftME4WaNmFrqBgU9RV/yj9xNeGdeqrQtC3Myp12oZ4SbWNnU0 GRhMX4uuKooaF7iDGLekJV/hzZmWG3kzBxiMoFo2NnKBOwChDtCGwQpq4xK8IVD3T4qynxTS 6RMxiP55ZDVNnNMnQKy1acb0Hg7I+xC5feWdOch297xA0H+V//4/UmhQGWVuZHN0cmVhbQpl bmRvYmoKNSAwIG9iago8PCAvQ29udGVudHMgNiAwIFIgL01lZGlhQm94IFsgMCAwIDU5NiA4 NDMgXSAvUGFyZW50IDIyIDAgUiAvUmVzb3VyY2VzIDw8IC9FeHRHU3RhdGUgPDwgL0cwIDIz IDAgUiA+PiAvRm9udCA8PCAvRjAgMjQgMCBSIC9GMSAyNyAwIFIgPj4gL1Byb2NTZXRzIFsg L1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdID4+IC9UeXBlIC9QYWdlID4+ CmVuZG9iago2IDAgb2JqCjw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTA2NDgg Pj4Kc3RyZWFtCnic7Z3bii3JcYbv5yn2tUHpPB/AGLRHGl3bDPgBbEtgkMHy+4MjV1d1r6pc f62MP1fvvTV4BsSou+urrMhTZGQc3Bcr//7Oyf/UGL78+19/+p+f+k9Sy/IDb1oqNnz523/+ 9G//8OW/5XemJJt9K/723P3/+51PvppaXO4U96X/+69/+vL2H3/7y0//+Cf75S//K/AQcvtS WvzinL+h/4x+aG8/Sdmlyz8LMae3H1pfPp61/fVv/yGv//rrT//4i/3iosmpyT/1y69//sl9 fH2IpX359a8/yXfbL7/+x5d/staGf/7y63/99MdfJx5u54ddvT1cjUvO2VI/fuFuv4jGFtdK Kh+/SIfXueevcy6bUKJrbof4r1nb5hFy/vCZlnhrYswul5WWDBDrf3+DOGeiCMjaj9+ktImx Vptj+pBvjEDwyb6xvPG2lmJnfoNh+s6q3gRfgl+R0JnBdFWV/m7Nt6V2nBg2OSCo+PPtF8F4 mcexhY8nirbl3jpZX2pakeDAICTobZJ10aalZhwR9msAwzl4OAOcuuHBmlB9WGr5mcEIMEQT UwxhqR0nho0FDUG0FG9DcFyK75+wzX9862HVKfluNB+WkGg/xtdhAuSYz/331iwfHj8Q4sO/ PzQq/l7bAUGGk5Vtc2W1HhjEQAguGWdzXhkIA8P+/utbX/Qn852cnHrChBBMDbEuyenMYOQU imk217zUjhPjasxWMDTj45+joZyy+kurrM+t2JXdaWAwEq+yQGeR11I7Tgw4Mr9GbfuibCCy f7SVpXxgEHKKtplUuvK90o4T42LNVA+oKEqly96vLDEDgxGUj0b2LLcysAeGTWCiwr3l9+Dv Z7Tp4064qk37QRV824eznRgH8U12RbTh6u63QvCG+AsA6feEJJ0QpRdWVoaBQQyoftqOLcUV bXhg2PDGaKaUlEooT0caGlHw52jEgh7FYwM1SH2uSK329acuSfLMIHo0W29ybB8KKtGOgXGc 2i493+RTAIL9OrF2HF6ApjuavGpNGYwx9we16Its1WVlEzsRmO6v1tiY2srCMjCOB8v7E4v/ GU2spn5rC8be6zMKy1lyZ8sZPpXdD8AHB7wZWW+vW7OcQYim13fIkuUMQo473r3d5ZlBBp6G NR8VmnHVpUhpOxDCiDf2Dw3JU4oyhFxIEetFAQ1f2FXQcIFVLPgIMtDhboe2T/gEFIq/bpWi Q33sG5zz1GaNGMTA8jGb4jhrLkBcyG/+2LOzUzFe9qOVCTgwGDFlZ0JucWX6DYwLpRDoKPol TFQTU2LISw0/MxgB1mRkEcwrG9XAgOenw0QF58njMfC+J+42QqgUojfAE9rhFwGcDYGZ9IGy qBC9LPgmezkSLYh+YBBDIKRscvNLa83AwEdl7cEN2f7mz2F7G0WNDFn2s5XvPDMYebci2pQt lMkIMUQTByaWtN1xWpNq9OljtYWLmdoq8lUrgii6V2neUUdRxCC6IormVWWrpk5miHGSeL07 e2DRPlmeNN+Uo/FOJuPKN50ZjGxzNb7KP0vtODGmdpCpdT/9rP6glowrpEUMMRjBtmZ8LGFJ sGcGXg2QlQWYcaB553p9V3x/ih0S3YrKMjCIfkiy93qf7cp+MjAuloimb2AzaW28nhGMmHIQ FUW+ZaUZZ8a3UNFl8Tb9g5f698xgBFirfKXn3BkQQz1P4fyd91Ta2pKd6C42L8l1YBByzd6Z WOqSXAfGD6j35nRb68rKWX1gMPLOt7WurBx5B8b0Xe4MvHjRKHOFGuUlI5wNzdDABQ1y8JLK z8s6bBZbLweBTNpnAEPV5zsjmyaLYOZWfwTZZatpSeh+PC2Rxy4EYWSyZr1GkO9lkt/ak4pp cmIInFaGIIx4szOt1kbqZQjy/yb5l5rkR1Of3S8MzzeJVnEEfus9X6wsoY004gMGMRR9iaKl ONLMARgXO55CNQgfFmS/NmkHBiOobkG2bmVpPiOwGwByvsU2GKQSa31KNPcsYfOqFP3SZbsy kgcG0UFBNr5YS1sZyQPjmSftYPVXeFPt70w3A5JfGeADg5Gf6K0hW7eyJw0Mtb+swndpf2fN porWwxlIAYORX7OyLyTu6PAYQZsQlkxYb22JrsmUtHVlwRsYhFijDzIlPXk0BAzsNYpMDgX8 XO3Pee38pxFMSSaHuqSiDwymg0ozxVnyfhsw5tbde8GeHMgnXppsMMGRPlvpfJQeHvbOhHB+ Ltvzc5u7qbzKy6be/HDCcc5U2exbHHZ1Z03O8eB2to27ZERryDHcnbx21bVId4cw3FY8eMuw Zlx9kcvFuFDblQ1V9/w4FC+fL90BLyb29efHrWtILsMWfwnuS3q68nnXPK2UScumlHK1M6oe tyHox+pmfJXetT6G+6WzgaF6MSIRaz96FlNkRrTB9PZg2Ds4uc5eElcyCtYZW9PV4qd6XNfB wRYjw/Hqmkn1+NXC8myZUP1meWlLbfAZe9DHDbHwI+glw13slWCjqybGS3cV1eO6UdFjZEK+ PAipHr/ok00NfVEPxz/Cvld9gCyaJcRA2cjlxecN2u2t6q4S5f5L1EZLhVv+1hAna1qTMcpd SUCIRs/bId4b6YiQqIMqhBy98O+FpTcOwhguxe3E3tAkI6wGxwXmQggj95RMTMkFStGHkAvL 75OMD4qEE4cbxTUUbi6KidBPNu+zCZH0A0AMost7hgHZBDifL8TA2QGwIRzZ7WMCx2HkqQoN mvPmnv27qpeF2LaVeTkwmD6qWf7C15VZOTBwrBI22KqXtiDn3pIy59eNGIQEu/pZRQQr+8nA eCqoYcxuhoNxKTqd82Za4+FJ7fLpfNY5NA/X88PbyVWfd0nzRL5+YmoYvLXcBS/6XuPCkxBD NRx3hhx3e0gMt/ojiPVFrT9uR+MHd5noFzM3SXMbcJr34du/WVax6LgYAYBguk+0/lhToq5/ EINQNaHE9TfXn3ChrhCoT96Elpb6dWAQHSuTw8RcuJRNiGGdVbejx2DFwgUnIwYjjyyqvGtc 3hPEOCiHx/AmFK2kzWKAnCq21o9RTOoRG2SmyH+SRzbAIHpIDnyiHPlM3YgjBs5DArsOXVpN rV3HQYA6df7Wav+uXE1tgQv9QAymj4o3LScu9AMxPtXle39pD++KlksPhRiMAHt4l/NcDkDE UGe1eaL3KL4n+mpCsZwbAWIQco2iysa4pA2fEXgNV+t6Mcpf5JRWRt/AYKQUqymhcN4WiDGp cE2tsThGZt4teG9nrfIXiUvOgxiMzJs3xRcuOQ9iMJGIcNJro0VfECi9fVeKzmS7NC3OCKKH Ukwmi3BXVNSB8RrT0wbv3tOy76wssgODEVT3nS5cAmCAwC5F+tRu0MsTDuQ/vGoblF/K3hG4 EATEIHoo22CSS3mliwbGcYE/uuIiB1oYnKvuVuhb9sSpV/PFSdojXwwlf8Uo1p4sidh0dZ8k Tz7+Y1vxGT4yPwa2ltyMaQeTiGYQQIhmNO6QaE1prnCBeBCykHb9weHtj2ANgLfUMGE5vLWb P+5t3+ytNT5mLn0wYhAd6G00wdVK6YuI8VS0mga6JIoRdxcCEIyYXE9YUS2l4iEG4SdBDLSV hOqIwUgwVJN85sJVEONHO5js7SzdTylyhzDEYGTer3Nd5o7uiKFPx6o3q0Grxrxxemt+8NJO W7m7K8QguqIH8oRqOfMFYhwTBx3yq6otnNCI2lCvou7ebhAevAOk5YIWc6hJojbBV8NcZGgs N/BzfChHCWdhk+BFI/xs1FjcKKS8AzcV3FiY6xvl9AFtVQSEbqM+yeLeWuQuLxCDmMHJFWNz 5kwZiHHR2SgXxYyH0cVhaeZLYzU1rik7A4OReJJeEyV3ZfsaGNYBwR5imO/XUoXnxv7SYo31 XJIngGDEV2RUtVRWtr6B8cNmgVcIJst+XkvirtoQg+ggUWRNi4W7akMMvHAgvVerD7/AOLw3 vidGT41LMIIYTEf01OjBcffSiHF0WbxfUF6RXn1/a0+vHsm0N8Xbk13rIh0G9N6BCXH0eSfY lBtTXf32sS5mk0SF5vI6QIhq0G2QJPpaiZFz2IWQ72eb3FrUnPGNvKdFDEa8LZmQM1fcBzF+ y3bJt0/2SRrqHZfgDTGI7vPp5soSON0PMC5KFqHiffoVxveNoJB7yWMEI78ajYuVqymFGIdd YMoP6hXxDVtrejG/5ht5DgQMQrLBS+dYR54DAeNZblxN+0I2wQYuPwViMHKK1gTZ95fkdGZ8 qiPZ/tJsDRdV+BDAiC7fFlDOoxYxfjhb+Vs7o42mF5hcGa4Dg5B5tLJZOL+0YA4MfLWNDmlo HUW6gtZ0+gq73PaxOZjQAudTgxhMx+ViYia9wBDjW6wzsRZTo3zxSsPPDEaAom0359rSyD8z fqRculsbe0XDVGtcUSkHBiHvdIvJIq2ajxHHo12IH0u7/3p/tPN3d/SH6uE918bHb+r9M/f3 Cf6Xx53h9Z3RQl+yOS9pxGA6o5W+ZFu31I4T41m1jXEwI+1PebuiX4TkRNqTiy/pOwOD6Icc m5w1Ylnph4Ghrzihl18JJtGOIYDByK8Ukwt7VwIYs/7xM+za5Cx+ET50yRhyj9CFIGF23ilZ 77k6+iYgx0hO5UAQVa9vkL4PpNjIqyYEuQinhRkR5ksJ7K+V2VpSzVx1SwhhpJiCqcHmyGli CIJt5q9Yvre3lq642rbU/2cGI8LqjCgl5IkVME6ODWsZhhSFrrb2eFtkWc5xZXwODEK2XlS0 nFm9FTA+t5Tu/lZZWWz0pMkOMBgJhmyci6QTKWDMFUqcSp/+RB1ZT16N73KBnxOsoIj8qOYr cm3yfIsnLnWlTwYGMTbe4okbV1kQMdQHAGyBUxqEUPptRRbY/aNyuOVG466WVzK3lO+TuQXt 1vQ7pkbhlmAjRlGPPXvfhSCq+bBDqpENi/TTBgzr9w5sPXTfAU/fw24Dc8BAhwN1ShfNjrYn QgmmZK7cKkAwfdQNDiFxGekRQ5P5Y2N4601xrOkVMAh5eCvrb+XibwHi4rL9M5Nb7q3pufK4 vIaPCYxQb3ny2KMFYBydoubyGyp8GPakNtb0+y3uMAIYjAS7H0T05E0sYKiu2PakNt37OZCH M8Bg5JG79zPrdwkYr0zaQoa6KkQQZLVrNpF3PoBBdEWQ5a6VTN75AAYxNLtDhpNeWNE2BgYj D9eMlwdXdtSBMXdCnLnrQgdH9bHhk06IU/HfmjPingYnySIcSF9CwGBGR2uyCCeuEhFiLJ0R V3wGvqpnaS+Tbp2PK6rAwCD6IUZZ/GskLXKAQei9Mbme38qtbGQDg5FHysaGsrR6DowrPyFk FUKrDRqZnxlasKXasDLtHXu5ABhEFyXb5FxR88q5fmBcZEO+21nsfY48FDGpsQttrQlOzq9k Ko06pNLQPDzEK0CPdpxsdGZjfF2VTPYkU3f3fpmELgROX4QQzTh+h2Tja/LcIRtCGMteVj+B jpbP3qGQj7fOOOlhap4jBtFPXtYsVwp31YEY+NR+cAiaum7Xx0kQlpgngRIaefbyWzIeVob9 wGD6tcjYKGGtHWfGHt7zZP2cuadQ3P9vrenHWBc8V8sBMQjJ9mOst3FlwpwRNrxJQxORjzbo qcq2x674OqF13Wtv6IQ3bx3f5ZBzLyfpl7r0zGC6tIjgU6TUc4A4xcgdupSr5Kpwqv9GNTZX Toqb2GJs3auJOxkhBjECYgrdp4k7GSHGZ9bs3d9ZBGILd9JGDEZ+VRbW0jifE8SYK8bwOX4O 6+FV9cMDPLvCxYkgBtFDNxfw2hxlG0OMozp+nxgGVZc9aONTD4A5hB9QT6JUipEzc1pZhAYG 00Xdoa26pck8MPDZP+zbhLQ6wZIch+DW++li74pAvCxnx/2bD/mp0IwvWgHdnL4r9j2/RAx+ xVM22blzjtIq+4o9ePeJFQ2q1xbhNj8EUU2A3SdWtKVcAhdNDiFMwTZ0IjwU2Xhwm6/5Wtnv QqxcwCtiMFLvNYO85fL+IAbvEv7gQD9vcK+7+2oyMgK4LH6IQYi2p/Cs8sWcWgQYRI2qtQqV 9z6sMCECcPTUHAq37y3Z1OjI3RgwmL6r1jRHVmlFjENX4IwSD0quzl/jzQRnH189sxsveUoo ooU3yYVUTbBk9gbEIEZByLLAVjJ7A2J8arTw/lLZGQpZxQ0gGPHJvlB9WdpbBsZVAkt04p73 JdjeGp03ctRZGX9nBCG/6LKRAby0kQ2MbzH8YpBFIJS41PAzgxFg7PHKjbTtAQY2D5CCRUuv 5kOLrNOOS90MEIy4S5XdonCuqIihd8ADOU9/WHsSaqlC8ul2VxqWNsyBQYyAlK0JiSxshRiv KLy1s4s3qVTO0QMxGDmVXrKarLGIGN/OHqf40myb8bFwbryIQUg8u2CCa1yhccTAmdPBiFXE +uzvDMHkFrlChYjByE+245Izl4IDMfbkppp2yHZcQ+VScCAGI4+YTLOtrawkA0O/133bdMkz 39SK8YEMBKxDIOArUzcoxtpbO0RCplgfHKfHIohqtO0QmTklenIZRZCjrkSGb+/02DtJNiTu 0IkgjLBi7ZkoIxdKAyFUIXFoREFJWPEVATJjn/aUiW/rrmPNZuzlfsn4jcTbwiemRtoWFpl6 Qu0QyQMmgqjG/A4pxsnpjYvyhBA86vCQR8cstMXAKQJjep8sWmu+tFvkWLe7R2dXOnZgEP3q ZfdoznOhV4iBrwTm7NBTN5dkEfRv6v6/C6hFUyqpyj1GMF3dqqnyiUtdfWbg8gHYRS0c9rl4 N34VCd63BoWQevJ7LgYeMQjhhtB66nvPKSeAofdkmJpfkzdD6jUtlJ7+MydOLQIMpi9qT/9Z yTs+wLgoPYasb+rtvkflWe+5CEPEIAQYrWgMLZIXy4DxKfGnP2B+oldHn+7yLM3kzPpiAgYz NqocNwPriwkY3y36FCkFGjvaHogWTPSZ9IAEDKJ/UigmNjKGHTGWd/lDEW/9Lt8Lf7lQuXLn iMEIt1TjnV1SoQbG4i6PAi4h6fCAepOXBc7I/CVjAAGD6IrsbyERSweXgYFv+Ccrssy8NDpZ /EgDZhsiVnGeKRh2Bt2yIOqFRlIYjqoOeYVrPfw++IonNrGZYdk+qqAHGTrUNo0Ymunxzogm VNK1AzEuRAsHm16CXo6YIXO+RYjBSDD0xDaVK5uNGEwk6v0wtw1MjEOEFswQNK917h9Qesmb xtVrRwymM0qv+e48tdojBjYVgTop+BCNfnE4NN47rsIC12RB3ZHk/qgVcoje2Jq5YoSIQXR2 iFm+pnKxuIiB/VC/g11wb2R1xrWlle6MYMRdk/GZ9KJEjBc6q83752+Nia6YmmxZGT8DgxBs 9M4077lTC2J8qh1qf2noNqTMuVciBiPAnqWp1biyBQ8MPOFRORR1VSu9YellS0psssmJ8rgk sjOD6bpWTbKBM0MghtodCrtyK0Jtt9Z040yKlkvNjRiEZLtxJru1VWVg6I2z0LqT4O0OnEho 9EMFd+bkN+U4/YkR2m0viZ57+pqlY8TAIIZNjtb42LiAI8S4EOC8YWmHJytnNq52DEAwYkqx pzNdUoYGhiYV6c7Ism2lu1LqTDvODEYePVuQr3Vp+J4ZVyE22qy38Rd1c5rvZVyRUC4JQ843 eLEA7VwwQBWWl9EsOltqs1BNyKlwdUwhRDV+9uL0XnSJkhs3kBEEXsVBGyZO1A9NV3qnO1g+ AHoUqesK6BO+b1afZ3dcE/3QHX3osmltSG+geXhw3L3PL3Gs4QAFRLhXwsn6xFQ+NUM+HEGb LIJczi8IUc3VDdIdBXuJdW7zQ5CrlU0tXzwv9IJvzgRb09LXnhmM2FsyoVouuA4x9GH8ryhJ uLXGB2d6sW9OaQAMQrI+JOOb46KgEONiofXqBsZikiPrjCIGI6jU8/pk7l4bMV7i/L/DRYWs tXLhCYjBCKr0PNmWVMsB41MjpveXdqU3kMETiMEIsGUTbeEqwyIGdhXTez1iJQFe2cynn9g+ IERZ20SFXVmXBgbRGSHK2lYKF7OIGNh2orWjLtmkHil4CtFE60xsjiuygBhEF0WbTMqBC7tA jFcEPO9sV0ypmXNZRQxGTt6Zmqpf2SAGhspuszGCNdY2rnIeYjDyCDKfKpdgBCD+34GXc+Dd xCm7hvxFXFLzBwYxMkRXNMUv6eZnxHdz39X4OGxNT73gypoeNDCYXshOPn5NDxoYT8exqoHV xEpWdUQMRlA9G0YqSyvZwNDnarl2Tnh02aW4AHlrZe4pAX3k0lMiBiHx7JopLZM+X4DxLAPA gxUWZmvV5r2+zlWgkYyM51zJ5IGIwfRQ6anTAhcLghgXPeHV8BrliEvmwW1DADh2M4bm8ydh xVPC3oKWb/kVWiQv3BFE1e07pOvJLpL9jiCMeze0sStWvT0mvJuF+xxf+agBwog3yV9k+Uxu eiPIxbEUm7/n0qXMfNRK+l3EYITbrJyFPemTBxhzJ5IHtuxHfUH0kuJedgufjtnk5paWkoFB 9MatnnAmNY3HiCmnnKlAff0SLc+L1uNJXRUwGLFW0b5aJHVVwNC7TaFMvK8ol7S1Msh+5kvj IoQRg5B4kN0skKUvAQKXFwtv8tvuMe/zByJDhzrFsdrEcl0tSdGiVwckKDoxSg+kSFaJQwxi MMXgjBxc0soyMjBwVciDB8N9eczjODvE1Kp3nFicSS6Hlf1/YDCyLalraFyeDsR4ZbX1iZAf RWrV6Qm5FdQYA0sVEeibeFKM3fuRi8xHDKKrU/dFYd0ZHiOOk+hwaL3v6PsSs982ceGEWLLt 5Y0S6QgMGET3yFIjB/9COgIDxkWANLDWPPMc/rbxWHtodjMteC73J2IwXSSHSHmMSxiFGK8x Dm/w7EyQj+QujgGDEVROJtrIJY1FjGlD2EwDSzHZFzKUETAYQcnpJt8FoDLNOCGYSzP9S1s2 IXLe2tGOyRI+0/l6f5/z3vT66MzkgAxFn38wsqiWNWZG98MQwrNwxvT/SVXO552c379YpltM ARfWuGQMAQKahwcP6R808+m0kXf/JBetqd4GKtQZQ1STYoeIitJ8oBw0MASf8rAnM5pG2un1 JOGlQjg98YivnG8AZBCddEs8kiLltwsZRJ0+vcg/sbDf+4elbmGQBWpFOGcG00kpyVmkUCk5 IANvLtCKPO2I8/7SUk1si6PrzGAEWL1JOWfGJAIZF9bLe3NTyI9v+R7ZixWfFJzvueipcwFk EKINLvdM9JSXD2TAZC44+8u9jfRus8AJeqbi2O8szwdNKTx3iJ4/E7+LoQRTbaAcKyGD6dKe GLYkKjkNZPwmazbtX3szRUdHHY4hg+i5GJIpLlBWFciQhQ6sc/c68zEhEiw6BK448ANgdHyP OkjvEmrF5FCWlryBQfR2sq57uiyNuoHxCpPMO9yFbqCjLmkhgxGUq0bWh6W9cmAQJbp+wMEP srxYtaqXSjPNc1EBkMH0de3GWLu0eQ2M5WSlEw3PNhlXA+WmDBmEAG8V2qirE0CAF37qZLxs Pq4HyXihMzFUR9SnR3mhkZZRd+2QwXRotcb5SN21Q8bTOyINvDkjB2SqhlG0Y50xdV16ojIO Qh0umQ+6ksK4vQWah2ZcLp5yKMAQ1QjaUx5IN4fmKecfDFGUDPyAlJ6v11FRwRjCyCS5nrGX i3jHkJd6CMN0K9OxPO8Nrd6EuPixZwYj9e4f69ZmxAnxNM2LpnktmBI5p1PIYMQkp4vqApXs ADLmsjmu5XR5lnNkfMJOh4TvHybbmEyuSJW2hgyik3yUpTly/mKQsebTMeUgqVFtt1bWYIJo hUtfemYwEq/FxOAbp9wCxkXmg/ul/P42/4kVeCGt7N7K4Ht6PirbAEIQ8g4+mubsYjNOjClD 4pynL+ofZOmFHf0CQ+L2taUa0fk5Vf0xguk32alLrKQ3A2DgCGV0tr52uFZ8T5S/SMFSmXoh g5BrdNI11lOZeiFDX2gamKF+mwb6TWotGfltWBoBZwYxApK1IhZL3igDxo9goNfIIPT4AdZS CBhMX0RnsmcthYDxijS97/DUzVMxruwGA4MRVMrGlxxXTjUD41lsuaZ9PedAqUu75sBg5FSy /IVdOiQPDKwUfgXLNZIrzp+A7LMzhVDYW4Mtej3kbvGnyrtDBtF1vVKYPFdWNNWBcZV7WVuZ A5rEp4uivTezWrpifLRDwgC9nyhOD6wYPnuE/Yr/L2Cohs/OWPL/RRBGuIrteA+jdyY6x6Wm wxBGiin1WoWFdIpEkFekUHin52yszCDSeIQgjLCKNS5a0tUDMOayS82Z+NS+tYp9f4vfdsVI 67lt/zGC6AjvZegXT2ofgHGR0HWqeN1UrIDCvL01M0szpctXxtzAYETe44hK4Q4QjxFPjTua 5vX8BqXFpfadGYyYajI1OarOB2Rgc8MnpgrdWxN8D4yyS/v9wCAkG3wyJXsqOxBkYIMKvLdW h4XpkxUAWyg6ZWiCgDY5lNDzl+HL2CuGG+LONA8PEUQwtOQHCLiaGZ5uL+LROzK5Qo1PCNFM lHdId4IvLlEHPAj5saO19K1SSNTb3E+Z1EEDIIh+9a7bID3nU4QYhCcDLhAAs47DCCQYs6QO K3uSEUMj5x6Q3ALneIMYTH93dSQn7uYCMegLUkXDg/XGhUYVCYcMQoBB5pyXnXJlwgwMHIEE 785QiggUPoO2//mzw974nkQ/RKoEDGQwHRGTEUFSiUUh48JUqs29AVU36Fmo8IDZ219kQMt+ ujQYzwymL4oM6BiWlIOBwVhd1dUvv2o/NTrRcl3knH0QgxD5VgCASg4FGS+59NrhvppQLOc1 jRiMoII3Ma5pOANDfdOt3/BkdTS1pUaFESAGI79sTcvchQpAvH6V1XxPqX3l5W7uEYORa/U9 rHhJkRgYn1npfH/pzW1hafs/EQjhJRuN6E9tZVQOjM+sKfX+Uh9NspzLBEAw4pN1NZVIFS2E DGK/hjV11hNlvjczyxIoa8/KuWFgMCIvsgaGtrScD4xvVURE8Z23mDGfl9aHgUHIW045xre6 dDwYGN9148q36o52aQQNDEayvbpj5XKYAITaZRGu1Aqz9d6WVOkCvdEN6af+7i3Pd+maeMsz gqiG2w5ZsjwjCGN5/lSr8NbQ6kxKkXPRQwxG6jWZ7DO31jxG/Batwo8u7hVS9kmEETMXT4MY RG/LydYEV8mtBTA+1yq855RaMasDBiPAJbM6YPx9WIXvMj/VyrlTIQbREbdgp2y5+ADE+IZW Yc2nxiB/EeLKmBsYjMhjMcVTucsR4mkBFE3zcuiO81zKOMRgxJRLd5wn7aGAcWHxni5L+w4v 8hcy9Zc68sxgBLUQOgcQr8jj/c6u/dI9UhWvIIMRU+u37nlJQR8YVzYcFI6gnpFR1nn5T/Lq AjAICUZZ573z5JUyYCjqH38wqpEVZmXenRGMNPodR0jkxRZgqOsWp/lki/s7U5NN1q0oHmcE Iz3ZIUKTeb3SjDPjZdWjp44y9xxU2WXS7DIhsJ6GrdD2OcAgOi71qJFiOQ9QxJhLHPvKeKGZ L30rfbyif5wRjLxzMt430u8NMOYymsyUKEL2cXgAUOsP2VYTXakrJ5SBQXREdrJW11ZXxsPA wKXP1MM1+z65PZcUEzEYOcmeVnPk4nMQQ7+Cw/TH87F2e2NktyvJcpkBEYMRrGx31XuqqBJk sI4ZYwjsL+q2NM/XXXFD9jscHwRDBhVr0ZYaSrTXmELwnLkZQVSDYYdEk3zy5I0+gjzNCfbA tKw4z9yl5qsucdEsEMJIsafmSyF5bm4jCJFX8eCHMnd5BYe1ugs/94JsSx9lnWneRU6PAQyi y2VzM61xFQwh43gAmMqXiS9e1AGQ+IkXBJzvn5y9nNtJc/VjBNN5ORtfExexjRgXieBgYq3r XLlLNp8ti9TN5b0uDdOBQUg8OGvk5EAazQHjJanWd7icJZMLS3vJwGAE5bNJNcWVnWRgvOR4 sLFjz/ZQOCvxYwQjpdhTPTQuXQRiTF433d/XoSor2vBRvQrZ64O0rrisSODMYHqiyl7aLHkD CxhEoAGqlcvZfRQCiDLpS3BLK9vAIDoiyqSvlr2WBAzrrLodvQxL5eqcQgYjj16GJWWuHABi EBHj21vXQju25qRgsshlZdUbGIxoUzElWi4/A2LMOVFM3fWrN/9YY3eZ4vLaIgYj2FpNbpWq fQsZROV5GM3Amss/7cZEv3GmVE3JmSpYDRlEXyc5xvT0wCsmoIFxEYeCeuhJ2hHNFzXfIWFJ smcGI9km5xUflg6ZA+PHze6qkEwWzTtnx9WTQgyih+TrRN8JXD0pxLAO6IAa3/SNnfoNIllX 2Q0p/oaHfS8nf37Oh/Nzm0+7vMrLmGj34WZvg845U2WstDgMOzkq5xwPWQq3gZeMrPT5PvP+ NvCiiLPGEAbb0oO3DEPv6otcLsbJKnUV9qR7fhxyl8+XYPrGx77+/Pg+0CbfLnpB8/nKNKx6 XPntzfb0UxcTTfP0eBy4flqOl0lGFPvy0+O6L/c2mFra1T6vetz6bWYlE62PLQ/mbTxPVPN0 03cfTEc86Qv8DZzbuGWa0d1tcqmFqyhv1eO6Pu6eyzI8r67RVI/vBZXe1khfZzrfn01ol29M Xvb9cOWFoXpcKS45c8mGdZX3T/X4fl3xaOCnTftxIi43xO/rJgQc9wlvdpi2PCOupRS7rw6X HLiXqXuiOVw8XM8P/72HxG1ftBYSByEatfUdshISByFHxXUuwA3d4T17QvO1KyFxiMFIfSEk DiDmwkQOAx16hcCL2Rc4OmzNv2W3TZVzEUYMoifkFNJLuFwpdHoGDgScqsQ158ow7928NzOL YpILZ51BDEbkWf4iNO6mGjHetZkx2sB/hb+pH7tJKmFUjR48Mp/FYGtqEAVLdl4uIBIxCLH3 UDTr0lL3DwzrfwH2Vv/z3VpxZ7m938EPMg/zZs+9NemWC4jLgIIYjGRTMjY0rmgMYjyrhbJi Nt7fWZqJjazrjBiM/GqQRSVy3puIIcIEqqKP6Be/PJbsYSjfmze9WuTR93MYlzAKIAiBR9/k 1JM4x3nE0IsPKvP6peCWFixmLlYXMRjJZpnGrq518JkxXVd7poElGxlBSz1/QjBiqlZWjbLW jDMDRlzAEKSX1aBHWt11nOP0vYsim+cmnJSCjCEymQFiEB0tW7yxNdmVrXFg4GqF1yl+NO0u RY4WjctMhBiM/PphMzjOCRsx5ur+Tl38cUUaFYWI1TeOyst5DHoSJTM0SXElt3VMLqHXl+Ou 5II928YO++zhdA7PkDPdOhUvoj/Xqq0VT2oEKb5u3sN7E3K/sCote2q7QgzNavDOqKbm6qmj JGK8pBTWDm9yGkhkHBZiEILqN13JR87zGTGY8AMU7OLmzQh7c4I3VvSdpU86MxjRhmycd5y3 NGJ865VozE/0Gd60+9c29+xGT89geq4lk5rjzCWIAfNBQdUAZwWBJTKgs9+r9G61PjRvfN0E 11Pjt2o5hRIxiEHQ/eOlbziFEjHobMcrHnpbY6JtRs7sS6N6YBCCvSXit4Wrg4cYegdi+AuF erq35paBhYtBDn7h2rc765+ufd39olFGZxBFRKf7w3zXvjXEuSLz7l4Uqr5FENUg2yDe92zn gVSwEORiN4X7L67gh3oE3zd+l6v4XRr9HtVG7loEMZiura3nGeP85BFjd24bt06vFlTXh53L iTLlIAYhKG+LkUMMd2uBGN9mBuCj6tTUuM97CrTZV1Qs3WV0K0zBHjYBg+nvXpgiW3JjBQxr v95NjJIfG4WPASQwj2QCKEX6tq2dQTYJV2JdkfnAIGTe66H6mOvKojgwrCtAgvZnsEopcoHt bw3VhGS5XGCIwUgwivIkKvJSO86Mkx6U7kwTKGJjPcZob0y3ZmfrlobmmcEI9mbNXloNzghm ovadtpLJbhCDkUaTE0O6dIbXM/TmfrgVXmySapnH6AxbbAkgCInHmEwt5N05YjxLZjD+nKzN BAMmNRKoMotl+qyM/YHB9ES3idnIRVwhBk6Ujvf/dYecrTWpZwsP1XK2VcAgJNvLQjUnDy61 48T41Hpi+0tlx7QukEZywGAEGHO/sl4yGAwMfbjmk9JXnxnf+QLD6ZsYshwZW7BLXTowiC7t eTK7x9dKlw4MYhfMPVt1CnVljRgYjDx6tmqflo4IAwO75CA7KByA6FB2KJl778SjMZBuze95 J2wL0JpxybgIjPkX+ff/AAjuR/VlbmRzdHJlYW0KZW5kb2JqCjcgMCBvYmoKPDwgL0NvbnRl bnRzIDggMCBSIC9NZWRpYUJveCBbIDAgMCA1OTYgODQzIF0gL1BhcmVudCAyMiAwIFIgL1Jl c291cmNlcyA8PCAvRXh0R1N0YXRlIDw8IC9HMCAyMyAwIFIgPj4gL0ZvbnQgPDwgL0YwIDI0 IDAgUiAvRjEgMjcgMCBSID4+IC9Qcm9jU2V0cyBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1h Z2VDIC9JbWFnZUkgXSA+PiAvVHlwZSAvUGFnZSA+PgplbmRvYmoKOCAwIG9iago8PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEwNzc1ID4+CnN0cmVhbQp4nO19264sSW7de3/F eTagUNwvgGGgT3tGzzYa8AfYlgADMmD5/wEzamfunZlRKyu4ovZ4ejQaQBqd2rkykowLySAX 3Q8r//kHJ/+rxvDjv//rL//nl/4vqWX5B29aKsn/+Lf/+ct/+w8//rf8Zkqy2bfiH88d/79/ CKE4U33NHcX96P/5r//04+O//Nu//PKP/2R//Mv/FfAYm/9RWvzhnA8d+p/RP9rHv6Ts0u2f xVTrxz9aX76etf31H/9FXv/z91/+8c/2h4smpyb/U3/8/s+/uK+vj9n6H7//6y/y3fbH7//j x3+09mf4Tz9+/1+/RFOrzfKSzx/8b9sPtrhWUvn8IebHD8UEX51PX/9eH/9ejUvO2fKF5BL4 4Wd8/PCn3z8G7l4P3IVgYg7ZfoL4n/kEMvH1I4i1QT+SYlJIqYalkVxBbPwQezBepkRsYVbs mqGnbHyxLeeVoQ8gjBCzNSH6Ft3KSAYQmzyYcSmgHwqa7Ugf+B1OKwZvrcgypQUhXCEIZXgb RY4llqVhXDB2aYxigtsF/qEgiWf1t8ZofBUhrXzrFYOReawmJG9X5v+AYaN6X5XJbZINbmkc VwxGHrKW5TC2S3PwimFjOyzu9nybsO2wp6Z0OBRLPiz6Xx8/OHmDGA6pXUWugNpms0I4wTYT Y2or+8SAQSgpuGCS67bIwjiuGGdBueSf7wc+PNdqtvHlA6c3HE2d4wNn5Tnw6hkT6PD39s9q GZcmiynXJRlfMRhdV9FTqSvm1hVi365H6R2P2hzzqhoUnxldMaWFuGIRDRiEuKMX7yKn6FfG ccU4GzenlfITCBZqQn3SRjklc/GlrXzRFYORrJySJcaysnkOGG8VVGoyj5tdWfEDBiOoLN7R kkFyQSCmn379yh5TxIlfGvYVgxFeLabG4lbslwHj5qSD0w8ddWjvTWprRFRmYsp2ZUENGITI k0smiR2+smUOGDbZD0PPG29Fhm6YnB/GQj48AQ4pPPuh8jxAAm/QWxepONnIXFhxfwYMRncl mepkx1oaxwXjZIvPyE9viefubee8FEAZMAj55e5uh5pX5v6Acfazx21ZYYirDTr4wLsXkUZA GU7x26f9NdSKzFUcSTpuQqXYiRiJxu7wWwyyGSfWVeAmMwJRzeYNJIoaQ/OOm84IxMY/o5Bq RFKE0UAod3TgOsV8277gsaF5eCbeQsTrpBseFu9A9uzrc+36XPiQvLzKi9iaH2TgupfhcouD P+asyTnK2TiYF8mId51jOOzV+y1DCTXKNnRdFE/eMsRX775IJqVxoTZ3M7t1z48T+/b5Ekyf EOzrr49bF5FcnGpcLZtSy10sSfW4TireelNcSDfnvupx66zq7U0WWL6zGFWPK79dbE2xm/KN i6B63Po/ESsV/rLdkGy/lEO0NMKZt22wH4s4x+F0/vjBHkzF1NBOcTMyjZiCt7J5V0cd3XKO XXfD3SRqyWdRwddwjy7sk1uMmeNve52T7/FJvFDKeYQgmoP4EySJjZIP0qNGcgVhjtWfy+7q PpwoyovyB0vSHUAY6SbZ070IYEm6A8jNTeW8Tbij52CyLEvuLhCCMMKS8zeX6v2SsAYQm+CM g/eVKNgMrUt4jwnNzqQVz8dpcFhKhHQGDEJNMhPlTGzcFTbCwIKKKKMEu1JQ3+qdpN9zxpaW NpIBg5F5v+eUE3plZQwYlxvOenRfD0fd6ZYMX58d9/ujJTGD9OTmTiGcIE5zEWzKqUUYhJKC 64byYb+gxnHBOCdtHe9K/ceKaT2QnUOkklL2t4pLn2q9s9H1GIwExaHP2SbqChJh4Pv6+Kt2 bt7HfTVfWq0YtLktfekVg5F4jSbayt3vIwwbYDDrNGnt4d4y/KYdujhGxuX6tdcQQx8wCBFG cT98tGvjuGKcDzE/GHgr9+D7O2Wh1OL8yhQcMBj5xSKGdvArU3DAUF8MwBgyeaH5hnMtNjFl k+MSFRAGoaBknZH/GlfOtQFjDwuMExko7mR7n6L/6KpCvSJSkMM3Oy4zDmEwAo/W1BC4zDiE ga9u4NRXz9iUZBmGXJYGfsVgBJi9sXLyrNgzA8Y5MBQOUTmYzqZIet/fKmd68b5Q1yIIg5Gg nOmlxbxyOAwYb0mh2cFbMqHUJc9swGAE1ZqJyS55ZgOGfhPEuyNa3Nj3Q/up2sjNsQmI59Kc EAaho5xELkv2xQUBWwWbuDXQOZkYCnUFWOI1eI2DIui4Vd9y4tRaWM6Ckvk1R3R8R2gXgagm VXxHaBeB3ATO33H9sL22BBNavrso1WMwMizFyPnguKUJMHCZG3ZLQz3uhuVwE7XdjT9xWBXb 4cdIve/OkrUrUh8wCKmLaSDT33MFMQjDBgdF+Hm9H/vt7cEkJWSYqnx/Wxv7FYORYe6lpLZx FibA+Fanf3tnzaIfxyUAIQxGfs3KX4TA2bkAQ1MM9Ykhc0GeW9mBBgxCHsF6mZN5ZRhXiJf+ imZ4PSzNVpEiDEZM3vbweOZCEQBjKhRxjg9/ZyxiG2XqmWGNtFoBBiPx1ExtbnEcFwycmo6z INW6wD+8IUL38WHRFiMIS7vYgEEoKcrZ6loKXOAKYBChz/uYq+aDghhc3i7thwMGI9gYTGFv Fp9D7Fl9g5Sceo+I2RrbYl3ZDQcMRko5GpfFBl8axwXjldEzXSGoLbFAKfFoPFuQb6z6depp n8Sqlk1vaR0PGIRCZReQI9L6FSd7wNhZRlTjkAMssQlBAIOSRzNyjLoVa3/AeGepJprKf1J/ abEyj31e+tIrBiPxEsVsjUuG3oDxsuZEM8AqNkr1hQuQAwxGUOKMhST/39I4Lhh4DwR7KTSp 0J4MJuw29ncoKIdgsktxRUEDBqGgHIrJtSx5mAOGSAocOmrbTHHzsg0mZzEUa1zZIgYMRrCl 0+BY8loaYLwnsr+By/KONQY4e24x8jW0DxMhNc7lB6rMABOs92QAGIGolLiDyNZT5FTkTB4E cuNI4huSF5Qhmq+K4npk2d45wwWBMPJNwdRQChmoRCDMLQXMhFaYydt4ZGGFTFrJzyEY0cqp GQPJX4Qwzt7hiVkPXdTZ38C8VdSKb8Pxzsk505YW44BBiPaRpp5dXZm0A8ZNJvk7Esa3twY5 2FjOQoTBSDDavvNxjA0IA/NEnuy2Uz3KtVjv9VtT68QrZEIFwGAkmEMv/VsbxxXjZPie8+fv 8w81A69RbCsyie05BCO+Wo18vl1awleM0+54Ep8Lz8WH/t2qz/Tge+lM5eheEAYh2OCbqd6S 9XoAgyjfQP4Esp+xa6fwQLbhZznskiXLFQAGo4pcTfOerIQCGN9KobS/tDbjW+YIshAGI8AW xAqrZWWvGjD0YTIscWUdiJpNRb25y6Fmsg1khQzAIDQXxSUQ3ScuqgEwJklQ5vYhNe0MeuDX 5/+uIPvYvje5YPoFG1enXq/xAMXD1V4fJorc31ByvI1DxCguQrVcYigE0UzjT5BiivwFlykO QXDcE3FS4wJivXRTNcXVyAXGIAgj3exNaTZyVH0QBN8MwhDDb0AdeuE233ltlqbLBYIRbMtG 5htH1Yow3hrTmT/YtuF470yMkXNYEQYhWjHFTLonjNFj3FS3Q0aB+eDN/lZx1zvLMuUYIAxG gp0rPXE5vQDiJksdUjgcTLGzow08Qni1dTz3Qnz65qlKeP1mE2wx1S0p9ApB6DN0fp6aOeJG hHHJxY6HtXLOxa4jT9lSLvY+oNR5a0taku0VgxFuKibKglsS7hVDnTrzBrbMfSzdK8xkXjTC YOTavcLgOf58hLHnU8ynJCF5gz1IX/YFvZmZcp+Ji3rFHcImtZiz/EXhrr4QBjEDYulVkI3L 2UEY5zsExDHEhW/3dzZnnA1hadxXDEZ+LYkpkMLKChow/tCJJdtHpehNDHnFp7lCEOpJsXdg qVwxEcKY86yOaphP6dvfmZsJLi0ZNQMGI79evlbL0jIbMCYZlabiUZCD7Kf2U7MMp6bqV1ya AYMQuTg4pgXrVrzWAUOf3qvcURRxvn2MyV44nDShOn8N1flynFPHwjqcsQLdzSMHxNHFh77/ xraqqfZ9cZv+JL6ARgVfjouT4TvQgfErki4OyaE8Ajxc9HI0Wj1lIdbTTFo8fMV8EeITR1jr IeNvgNQlsOMWHNT9tnr/FUuWicL9919+XapcghHCUO3bG0Z2JgWygR7CmAuRz9yhIYXCg1Xd wuCFqhWijK6alDxptQEMQqXRe5N9JKOcAENTfrtjBNuDOY5zMgAGI48QH314OKMeYFiXn88b mKyiPT/wreh7a6EUkkxW1k+z3JU+wiA0mqx8fPZ31Ot6DH2BPgrogEtlRSrHPsZYRFaJjM4C DEbeyYmsCkd+ijBwWKCpx5eDSc1ybZAQBiOnzk+d/Zq+rhinyLh4pQPDxsgBcBNln8/H3saT ZZ0kEQzn2AEMQra5px4HR6YVAAwY8tNnkhT1YEJ77ChUxkgdyaFmmqKefQF4wavu6Kz3gd4Q kt5ZlrLxNZHFehBENUM3kN6/PMkOx01RBHLj17+odtGM/UG0ZNuSEK8YjAxrdyV842xogHGT 3oQ8bvWEflUBA5N/5knb9GvjcePfAlc/ijAIrT6u/Pudz9I4LhjfW/KxvzXLX4TGFasgDEaC uadsOTIpCGDg9AcQwzldtISB8UXzPTV3/5IjIUAYjFw7zVTLHAkIwvjWQpC6Ey450Y4lr1oA BiHA4JJx0S+O44Ix16MlvM7lhldb6gMyxGyaJRujIAxG3smaVt2SjTFgXALlh/RFNRH6/wdG 9bpzLQXjvF/aqgcMQkMPzqcWF8dxwXgLu8UOLn+RfOBagyMMRlA91tkix/aKMFiaxaX4704G 1cTLDVyvLYTByLWXXnj2Fh5gvMzP+4hCHBtpvycKsY2nBZlvnrzmBhiMbFvp84285gYYf/up ZwoJp5xNJbmBAASh505z1Fzl2nMgjHc0Y9ixay83Iq94nkMwUqrV2MVVOWC8r4uLgqNtG0x2 vvNNh5XlPWAQgpVFZ5IYIytW3oCBA8nIOIMSR/sS3E/URkrO3riSuYaICIPRhOwlPtYle3vA eCc7nH40tRlxsCqcn7cYI3MR4v+H0Ul4fwnDNlOVo3NRN425nL8isjlGzlwGGKqZuGPEnlca KncmIRC64E4z9FpkAbBxSIDBiLC5nltKxiEBBtH0GBaKwoIxmI83kyBzinjDADZ6t17dPmaT WyWDlQCDULfvuZqyXawsmAFjspISWN/PUuU0X1SS8a6Ql6AAg5FsaYaNtDxF+FZijP2VrZmc A1mwDDAI4QUbTAmJI5tBGGf6pqMAfUZuuFeLUHYZ43Ih/Q6AwYgwiC0QGhnCAhiXgEWaKLmb aT67NmnlwDOizaWjc8BgJF6qyYXMuHoO8e8tS3QjRgmpH2xcZymEQSj0waBfLEcGjTD+2mpk tmGWbjoeejcyn3rFYEReu+kYONZihPH34OFBOkmstZQ5AiUAQeg5pX7hX8qK3TlgvLrLhGUS moGLaVj9IYbPDPyKwQiw9J4yfk2PV4y33QyhMlc/TyK9jTE7GSNbS7bCGdUGzqjhYS/7TBie S9fntpiivMrLcm+HZIxNfJ0cQraBI+1I/LRIc44yUwaPKHUOnRzDcP0ZxeitMYQhyvTkLQP1 8N0XiUFqXKjtjjRb9/w47W+fL8H0tE329dfHdzLNJ3Jx18uGW+CWTanljmpB9bhOKt56U1y4 Y2RSPb4XYcy+va/OW7Yg1ePKb+8Ux9HdWdyqx2340Lv8e7Q+tvGgUK3Um2fgUm0QDD7i4Ft+ VcgyiCpCS+3GiVI9rtNkT28Kog9yFg+Pf8bDiykiyQMz3Y1Silpdl4KvF4MsnS4nc0dZq/Fy qsAur9uV3pNqYvaHGbNkG6ATibtcE0foA0E0BtIOIrrwUQ4/KiwAQW7izPM1OZ/oVezomteE NYAwwgrenDccZiQDCN/MGSbsL7Wn2Aeac7/e4y5OEQYj9WKNc5VLmEQYbyEq3cGrNcX6Sjk7 CIMRVJW9t3BBAQChKdbdIRa4LwEEI4sV7kuE8SqSpKG+hMUcv94veYUMfEzGshm+CIPQhdiI 8jWBi5ohjJelOJoB5h6psRy9L8JgBPWo7/Ac4TrCwMHxiZyc8y0jPFvu4x4KCQRbTS9ZXdHE gEFoIjg5pFvkiAERxk3XMBh5gze+sDBEeRXyIpMQcudohCmHbwpkXSXCYJS6cgOGMHBUG7H8 I267mbLbOVWvl8RuX9tJM6oj+wMhDEJzD9KMZrlbWoTxnSyN+ztTMrIhc2mtCIORX2ricWcu 2RxhfGumxf7S0kxxluPfQxiMAGswpXqO5hJhUI0s0K4CLz/VBnzyMk5L3t0gDELmjxbVhby7 QRj6y0lk2ygvS/HZr/Y3U6m9ITBHDoIwGAX17ogpLkVDBgw9KRGkCNdvN7K79RL1QN23IgxC smK+9hL1sLIEB4xJfrxjZsILmWu+KDmTCnmTjTAYycppmmPjEncRxvJJOPPSko116eAbzMfF k7zwEhfX52q/OqsmlLCPwwVnamiOIlLDIIrp8AWSjEDIFy2N5ArCdPB5EdHVfFQWizEme3cH TIAw4n1QMBeKExJi3PDWvoid6as7xpD8vBO1f4B31ticqLIPiEEow8tfuMBxWUMM5u5iPfL+ OZyQTYuRCphBDEa00cnmnKlTBWLgQmn/IdoxvTh85rDEfi15SK5BCcn+z88PKD/t6+7jD9Yb 23JY2UkHDEIXweZ+LUpR+EGMvdD8WQn6Ueb2WJs332/m872hGGe5bgoQg5GhzEVXCtU7HWJg ijy1AbH1sqFuFCAGI6fOV5zkc1bGccWYDBNPhQjV/XfXe5Du3/VgHqmWun2CGISOoqxMnygn FUFgsapPsOizkTWydIINGIyUepRWdqyVmTxgvGq7qhlffOxqFJ0fxGDklB67WlvZeQaMG0oU +ENC55HXz8EmnlQra7q/YjCybeJH5UaVBkEMdTwJVyPoyxS05URa4u2f8XAgHO8N51PSdsEl OQ4tWfEAMYhJIBIxznM0CRDDhq2aKBgx6vwxiwARVkzXKn++tFkTI0crDDEYAbZokluxfi8I LI2KYsy9X0+thSqohRiE7HrstqVGFdRCjHMTy2oPkp1rYvmMqlszoGw7jQw2D24x/DVyePaE jq1wzt6ntcOgxz7i85Uu+0h6sM2yfZOSWCSXz5kqV0m2DWL4Y5er7F/Elqvg5+dS2j+f58pV 4ON35SrXbekWmCtXgY/rpEKWq8DHd0tEVX4B5yQxWdeqLz6/K6fe0+aOS031uFIpRTa2Ui2r lOvj+64oRon11ZbDZflwaX8LLHMt5HJHTqJ6XCeVHrLz7Ta5U/X4/u14Y8NFKZMjDsVUWlzX p5XSimKBih/Hvvz6+KUW62h649kVrofu7StrZStLU3/sfGo6dHXjEPkXrrqZvxfbxuF8p5pN XHYpBtHYmZ8gnWy2cJm+GATbWfNZQJ/oMZnSrTjKn4EgjLBit4J9ozxThDEWcL7G6IX0KXDV PxiEkUiqpsjZS+VDYhBcLEcXKGk+qrOI1m6gL3zTFYMRbqcRFSthSbZXjL/knbXiW71sZsVX qnIJYhAy97KVVUt1hkIQZ6/7lLBy9rpPHiwMt+pFW6wJ3q990xWDEW2JJrS4tI0PGHNdrWDi 6vkHNW0PeaelEFqQOd2cpXjpIAahvM5w1qqvKyfOgPGdedufL5XzNqRCdTCFGIwAUzDRN4pm DmLgWhpYM+PB5FdX5XAMMwqJPfoxxEgVW0MMQnO9H8NpP6DGccHAxFFaaipIXK1eKo8GCSly uZAIgxF4KnKOZ6qPNMS4yWXw6gHmZlq8jVTqMRhByWlovWh9ZRxXjJdtWVYKBz7fWjtvYuFS tBAGI8HmTYmNS9FCGHqyx+WGQftYkvfG1rAk1wGDkKs4/fIxaUmuAwYuWLyX35Ni1uMUt8c6 KNQK9Rocfj363rCj5byymQ4YjCZ6x45cKe4MiPGXMNxSJyUXp2hp4FcMRoAtGTEjKHJTiPG9 1Mb7ax9cfDFz2fcIgxBh9qF3jeGSJBEG3jUBRf0UZcZMo737PWJ6d59NmZkRTsviGDiq/0Vy 8Robx8HbdwTZ4hYz7pmMsZJHFQJRzc4dpJOR5cplqkCQm1ClmjJpvsrtczwPrtUW1j5qAGHE mx4tWj1FgINBcIj4tLUe5X7eWo/RNs3WGr/iqj5QRC0Qg5Fu63UKiapmhBj69h9/BXRE4w8/ FVdNH5J4UOf0Cb8gzQGD0OqDOkem+8reOGBMN1yaGWBJxrVEWhYAgxFUb7mRC2lZAAx8wiOL Y4IE/Bl/keJDO2Nm8weGU+JDBwxC4MFb02+8V/a9AQNzSSCHWd3sAN8GaPkt3J/UMive9O5K S7q7YjC6K9l439yS7q4Y+3GrGUe1JoiVy90lAAxGHjWaUAIZ7wQY7+yDh7Yh9QyMnW83kPHK 5xCEvKO4ktGGpUNjwHhHF+lP8I/yJap/CMRgBPVRvkQ1jIUYTM0e3GZnAm4nB0ZtYcRc+6lM sQFDDEYXsvGG0JY27wHjPZcRG7jsQCl7iqEFYjCC6uH4EP2KmzdgfG+g8eOlyTYxRyrFVgsx CAGmniBJpx0BjD9alEwjLzFFcgxUT3iIweitEya7xLFZIAxcFDjNWv6J3TmMw+L8vmIwcmrF WLc4v68Y+twcNC/VdHbogXcVuuvPzJyLaeJYrdgNAwah6Vycab2V48o4rhjYy54kHJx5aevc 5zfxzluMfI2jf2+y6sfrnMvigIhZzAkbgai0voH4XjKab9u7ECBztcunxg4oUohjizAnFnYv Vrc1fhXY1Ei6dqKOSJ58AIPReE0m+8xt6M8hMF/ZVErbHHOWvo07fABNA0XZ+yaJzrpUQ+O4 DxAGodTOs99kQ+DMBYBhw8c4xnzmkwTDBP3LPeHJAvP75+D7IeAjeV8FMBhFtGhKy4vjuGDc ZD9PRQEOJ8Rppzto7kX0XCGBEHpCf1va5wYMQhMh9Ix+R1r4AON7XdvtpakZV8iA23MIRnxZ 5khcHMYVg7CnX9yuP6nP0GRibONs4lCSNYr1aj/OMQJ0Hu/f/6YYAbYvohkB4POTJbL78yQj AHr8jhHg6tXfApOMAOhxnVRYRgD0+FwDy6/HqQaW8HHlt3MNLOHj716pp2fK4aze9r7OOuZP DKN4DR9XfTowhA18RLdf3HOjbymUNE8rldUeOUN3lL+qxz/zh8Zuoy83vGe/YCIM2L4Sd7zE 3BlQ85jdAKme3/BV3+/+s0JNMfYcacuxkfuc35X6qHBYFXbcNkAxr42v8jeUcwhBNLbcJ0g1 IdWUKWMOgryFinlHj6K96CtXNw1BGGElsQAEibt4hyA3ddfzt4c7+govOsJgRCXGkphqHI8A wiCCSXgeztTrTcWS5vNltu/yPQVfPBnK/UQYhI68DyKvyGVsIwx9zA3P/plAMbrCmYuFEO3x jm7qTPQEFujORxQ3WQc5deVgpLrzQAxi3vS8Q7H4ObYShKGhTdkxet6hS21lrxswGHl4mQ21 cDX9CONlGplmgEFM3Ja4BD2EwQgqNJNycdQFA8I4HQqQonyu3ejU4p5hkoBF3JDpF4XB0VAV 3UI2yUXbK664ujcAQcyBTrzearvjKdNjfGvsdX+pFyM3B442AGEwAgzexN7YbGUcVww98QQ8 77Q8CG8zq2KppqZalyb4FYNRUO25NVzPZ4hxcxzAaPfUxjili/nM2238vdbbtsqxoyAMQhcp WCPuTKPu3BDGO3K5duzoTeiKXhnfFYORU8wm5rTkNg4Y6lzFt3HWqDPw51M2to/NttuvgaMh QhiE4rJtsu7T0kIbMDB3vVIR8FjejP0nfSERkpaCQ+07qkuQol7QzcpfkNeJvl5jmzhUgShP 4Q9TtQRTzvkUj9QToKk5X7f4VDDZk00IEYZq7e0YxWQ5V7mmWhCEyXPSUz2yqYxw7igE530n rPZcYiHCIBTofepsYlxdDsKwaesIMpal42DkC21ovik5k20lfX2Awci2t7I9tqSgxnHBsOFj l/5IO3OHK+9jPtq5q4UiWrK9tSYj384x/SAMRoK19bYjHNMPwsC2P0p/RzHVuSNjxkiYODHO b1afGL0jX1pcFAMGodJHRz6Z0FwADGC8hQdgB+9lyZnMREYYjKB6WXLI5BUJwPjOdkP7O3u6 mCO9gucQhPSiFTuz+iUDacB43acb3nEoamfe1b/sDbSluyByM85n8s4XYDBKLcG4VjlySISB 5ao26mJ9MAmQtyAAg5FTezAJcGnWCGPp2ITxVDfDfrbiZ00MSJESuwlHHFi6b0cPdjzNbR0L CRLyN7Czo/eCZuIWJ+sJWvDq2+1LVtTdzN6k1vMhegs/amYjDM0K+8QoJlYfKWsKYVgfwUR4 Fc1QjNzbYASc42FCGIQEvRWnP3juBh1haFqx7Bg9gbWGQJ1tCIORR89mYellEYY+FPXi/oPc Dtisj/27cu59rLjQPMJgdNRbRuTItThCGFhH6D78N/D3eqKo+Zj/Nvogpm8JlqvoQxiEJoLL pq5tYlcIzL54SqAN+Xmg8FmyleaDYu5sBFxzVITBCDa5zkbAmfoIA1/D6ps6wFsNznhUiCZa 30G45g0Ig1BRtLn3gF2yPQaMd1zo7ti9MYQPXJNphMHIyXuTG8ccASDe2JwkJiDvb7y43b+q 9PAZmayHMBgFldT/gmvAgzDwLeYb/Pz9pb2IJweunTvCYATY5AgLiQuPI4y/088cpJPyo+cK xxyAMAhNJ1lupVXumg5h3KR+H6OZh+amM6ywM5rDnX/UGupk/rKZci3YEAahoU7m75bMtwvC tyZ07q+MwcTm/Io5P2AwwovFpBzWxHfFwKYfOgjUPVfmCDpmBt/kOI2Z63YQ/L/7tJhNBEtp MQhDNZ93jJW0GAhyk/2isNI39NJMcylTdykIgxHVo6ts4di3Ecb30pRtb/U2mpAdl+SMMAgJ eltNDIHrl4Aw8N6mZgn71l67+/ijOGqxBs5OAxiMLmIWW88urfsBY7KzBHfFu79UjENXAmno AgxGgOLP+Zi4vDiEgSs1QLGT/uTpWUbNuraynQ4YjPxa6ByT3NUvwphKPVZVmyq+KIhZHGTS r2xvAwYh2eBlLxT/aUXDA8ZbWLN38NBMtp4jVEAYjKDEIcgl1pUlPGCoow+K4qn9nWJvhd5Y fmXcVwxGfrKNhlKW5tkFQp07dCpOOMUzZ5qOTAVpzjnCx66ALwJ1T1yR+e4Rm4CizK9aKhlD BxiErqM4rS2RBNII46bE9kWa5Hz1ClQ3ski+M6z9IYdkndhNJEUzwiB0mmwypaW4sv8NGPog KFadsvRxW13zN24oXKKo197FkH1vq0SGPQEGo9KcRYyBy4dHGGxAXTPuJrurz23FGhwwGPm1 aFKrbWWbGzC+N0Dqt8hw7KYwl62OMAgBbhHqlfl3hZi7yywjJdz8xvGNV/LbNz2SaULiEoMA BqOeEh9kAiuhoAFj9kp+BrtmQ1dddq6GS3j5D9VL8zvZ6zfZuN5NvFiuuAZhqObhjpFkjXuu 4gxhzF0IzykJXj/A4CF8Ar5c36NYse/ELUSXTAthSd8DBqFvn3rbybSk7wGD6Kr2LffCxzid XkOtCMiagi4QhH6CuBPBB/JcABjfa/dsL/XO5FY4SkyEwQjQix+UG+kAAAzMioXZ82ZqWeaW ypuKWfRLIrRgQuNoMgAEo1FZVTF7MsEUYLwnjBq31MhmcmXDgACDEFR0wcjxtaKuK8S3BlG3 VwaZwWzFNsJgpBediamRngHA+OMFYTQSk7WdWlibcFcMRnOyuHNOZIkBwCDOzHtVKz4oeW+c I6sxEQYh2E4m5mqoKxvbgPGWyvsdPGQ5qOuSNTtgMIKK1tRo7YrVNmDgFY8SwWEQX23NpVxN io3M9QEYjGCLN52BfmklXDHeefanKpZcjGT2AcBgBFWraS7npZVwxdDXS6snWnbesBcfTxEI 2cliMdkd7hOpUVwwln2umZfK1tVqxPlHtxhD2wcchFFXlevbEeJ4jj5s88Z6c0Xl6c6/73q7 FvICBWCoJvWOkUxNhZzUAOOGeACK9hUBiuKbvPyFi5Es0AIYhGy9q0Z8ycSdjgDjD5yCPXFT o7nJzYfctsbRAiEMRtk9t606MgoCMLC8tdSc81x34Ys0v4VG3gwCDEKuwTcj+yt59gOMV51R NeOL0cRmSe8WYDByimJGZ0/m2QKM740Iby8V+7/J/+KcIoDBCLC3ILSVLBoFGPqNEdb7TtyE 0Amx+Suq5yuZjAIwCE1EV0y1Szv6FYKIp2PS4hf+86hTdHkNIxz3utaIUpzaUBJHbIYwGJWW bGI8mHXUOC4Y30Mc9ld72bIzwcuMzCWvbJcDBqHRJGeFC+wFGsA4e4pLldr355OiFBNULGty 5r4o6eXXJVdrwCA0l50VcVmyogRg6DWhzgaDNi+aM2qbV34Vj7WR1cIAg9FQDuJQOzI5EGB8 b6Rpe2mN4q3WAr3mW4yRhB+VBOJyVW1GUVQ4nBupfL+piJ7kz4UgqmmygQQr0o6ZTEZBIERi G5EaBY/chqC0zSM11tImiyoWhi/kzggwGMU2K/4gSfeKMN5T471Rn/fG5J1MdmGAAwYhKG+z KS3edXfXY5yJ8I/RyyMR/vkHRfx3e2uPyQe2PgdgMBKMznR+UM7nAxiYX/ZkH9sGNoopf/gN EcSdx9+a5tjyHoDBqEIOz1bZWy6AcRdYhy0cFck5G6+6wOdC9u9DGIQIO/ViiYmsvgMYp4t0 mo1xAw/BiOtA3gMDDEZQoRgnViB3Dwww9N4vyg5DODBgoue8f0OIZe8p0G+KHJnRCjAYlbZ+ UxTIXAyAQZRXkix5T3b4qZ3rL9v6QHPRu7cFiKbUTBatAwxieix18EQY1v+GJK62KWMt3Yoo K3v3gMEIqok1UyKZJggw3hioepu301PumoCsbFwDBiHwFLr5aMkYNcDQ97t8V0G6fhN6UbSi EWV3PuVMXnEcBwxGpd35rGHJLxsw/gqTpDXh+/qVi+UiWbgDMAgN5SgOS81LlvKA8TaG120s 0NDTfGhxpsW1EMGAwQi8ZGNdJkl0AAbO8VWEbjfs5k0gO8/EofPMje2m79MIU/5gZe77Sjhh 7pQizrCJx6VmUnTRU1EzCKKZiztIZ6J0IXJ9LyDI95Ij7q9doXVEGIwMazXiRXL1SAjjZnVM daJ/drWh4U2c6kKnolpUxPERZx7k2HtDH5hNEV78hhgL1/YDYRCTyne2Xtf8yrocMM5qPbV8 fUcIMO5dT3qj88JVNyIMQoSdka9fvyyN44px4RRLz4tvNO0ZNV+UovGBjBkiDEayqZpgyZgh wnhLkc0OXkQ9wXOeO8JgBFXkL8QWXjnnBwx9JE5PvaYOr0Ji8xfOtEKYstqMc5Ej4EUYhFKj b8bVHFb2lQEDd0VTxiWxhvT9Y97QQmH/3iqLyXIXWgCC0VyNJpXMBegRxrd2g9le2jkDc7Vc ognCIAT44AxMfmkJDhg3NJ0wJAoDaOtVD/swo6D7wPWtQBiMyGMxviUuEw1h/PEb7eq3oAdH nktlRZADBqHQ7Gp3OcuK8TRg4Ljai2xWzUujNY5leItDAxGi5GyGAmoq+qN3iBVJvtunymqQ xW8jGZ9AIKoZt4P0vqQ+ci0DIAh27DUG+96IpIqrmrgCSYTBiKr43nOOC8ojjG+Ohm1vbd40 OQyXRn7FYCTYirEhkDYWwPh7pblCA17WQYmFdDoBBjETfOkd7Fvm/CSAMXWBNEe45vzzKCOO Jirs9o0kX/6ix1o4IxJgEKoIYi/EWMnAEcCYY/c9GoWQbXamUekx3vuGbtP7V/VuClzO63ME RjvFmeg8Vw6EMN7ZR/ZNJf3o3xWpVNvXyv8x4sqS92cAg9BcDNbUQhL5IYwbzgxYofoGt3cb TY5GMNyKGTFgMJKVAygkkv4WYfzNBtk2+nrXjJwTXPo6wiB0l3wQ4yGQ0T6AgdNM76mlUChD 8z3i+shIlvbnAYORa7ayxzeuKAlhvOfaZQPvxGmyny1NwCsGI6iSTRHzemkCXjFmM2xmxteC seImLsnpisHIqftZlaxyRRj4+J/o8DaVggeDv5CnAT7xtj0ip05wE1eW5hWCUKj8aqzY3Cs7 1YAxS5Ezg90bULD8c3FoEoETXqBjDs9nhca3JgbeyXyKNXCrB4GotL6DJFkjLKspBHlLmeiO Hkqn9iQpDyAII6zoOrln5WiaIMg3x/i212ZnmuxsZOIFAmGk2DtN8TeSCORcRXKUov9A3+4I xTL8+kUvxpWiaoTBCLG3myqOKwhCGJMVt1OMCDCrFr1i8+RH9f2M2g/zMZgozhucpbcYA1Wp 5uGBfeLr4f8i//l/aXbp5GVuZHN0cmVhbQplbmRvYmoKOSAwIG9iago8PCAvVHlwZSAvWFJl ZiAvTGVuZ3RoIDM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvQ29s dW1ucyA1IC9QcmVkaWN0b3IgMTIgPj4gL1cgWyAxIDMgMSBdIC9TaXplIDEwIC9JRCBbPDA5 ZjBlZWMwNmMwZWMwNzI5MjY3MzNjYWQ2ODEzNzlkPjwwOWYwZWVjMDZjMGVjMDcyOTI2NzMz Y2FkNjgxMzc5ZD5dID4+CnN0cmVhbQp4nGNiAAEmRoaFDgxMDAyMt0Ckzn04m9H8IkJc6yES O4EBANuHCAwKZW5kc3RyZWFtCmVuZG9iagogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKc3RhcnR4cmVmCjIxNgolJUVPRgo= --------------18C28708872D5CF21DF03049-- From nobody Mon Oct 9 09:39:29 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6211346B1; Mon, 9 Oct 2017 09:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Zhh0u9LQTfBJ; Mon, 9 Oct 2017 09:39:26 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 BE8291346A3; Mon, 9 Oct 2017 09:39:24 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-2f-59dba63aaa79 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.1D.09869.A36ABD95; Mon, 9 Oct 2017 18:39:22 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Mon, 9 Oct 2017 18:39:22 +0200 From: Christer Holmberg To: Harald Alvestrand CC: "ice@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 Thread-Index: AQHTQRqIopdqNKi4M0G7+rZLE/Y/d6LblpKA Date: Mon, 9 Oct 2017 16:39:21 +0000 Message-ID: <53E41383-CCC9-404F-94A9-4208C1FE4F94@ericsson.com> References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no> In-Reply-To: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-A9D1D8EB-E2F1-4B1D-9714-5284422E70D4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUyM2K7t67VstuRBsd3WVsc6+tis/h2odZi 7b92dgdmjysTrrB6LFnykymAKYrLJiU1J7MstUjfLoEr48W9NraCKZkVa3/tYmxg7EjrYuTg kBAwkVh5QrCLkYtDSOAIo8TZ71/YIZyFjBKfDpxiBSliE7CQ6P6n3cXIySEioCPxcH8DE4jN LOAmcf9JByuILSzgKNHxpJ0ZosZJovfRTVYI20hidcNqsDEsAioSRzaVg4R5BewlPtzfxw5i Cwk4SGz/+58FpIQTaEznckGQMKOAmMT3U2ugNolL3HoyH8yWEBCReHjxNBuELSrx8vE/VpCL mQUmM0pMf9PGDjFfUOLkzCcsExiFZyHpn4WsbhaSullAu5kF4iWm/DSBqJeX2P52DjOErSmx v3s5C4StKDGl+yE7hK0h0fltIiumuLXEjF8H2SBsU4nXRz8yIqtZwMizilG0OLW4ODfdyFgv tSgzubg4P08vL7VkEyMwdg9u+a27g3H1a8dDjAIcjEo8vPnttyOFWBPLiitzDzGqAM15tGH1 BUYplrz8vFQlEd4nTUBp3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRmp6YWpBbB ZJk4OKUaGLmKFm1LOnfN/+SFJHfp1VOawlYumb2DofLKytTj/yXZoua+0121z3JHlqzKm129 B3Rjl2/pWD7T4HpD3r4rUwS4Dud7dx1Mra6NjPR2bbDl3e1T/7Jql6rIwoUvqw7oXfg2Pab7 vWBy8bSrIo77byx/cdCer/tgn/Om/q1bGH0XHvn2/sBObTMlluKMREMt5qLiRACJ3mlX5QIA AA== Archived-At: Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Oct 2017 16:39:28 -0000 --Apple-Mail-A9D1D8EB-E2F1-4B1D-9714-5284422E70D4 Content-Type: multipart/alternative; boundary=Apple-Mail-0B2760C6-94C8-4A29-A4F7-60535C60F673 Content-Transfer-Encoding: 7bit --Apple-Mail-0B2760C6-94C8-4A29-A4F7-60535C60F673 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgSGFyYWxkLA0KDQpUaGFuayB5b3UgVkVSWSBtdWNoISA6KQ0KDQpJIGRvIGFncmVlIHRoYXQg dGhlIGRvY3VtZW50IGNvdWxkIHN0aWxsIGJlIGltcHJvdmVkLCBhbmQgaWYgSSBoYWQgdGhlIHRp bWUgYW5kIGN5Y2xlcy4uLiBCdXQsIHdlIG5lZWQgdG8gZHJhdyB0aGUgbGluZSBzb21ld2hlcmUs IGFuZCB0aGF04oCZcyB3aHkgaXQgaXMgaW1wb3J0YW50IHRoYXQgcGVvcGxlIHJlYWQgdGhlIGRv Y3VtZW50IGluIGNhc2UgdGhlcmUgaXMgc29tZXRoaW5nIHRoZXkgdGhpbmsgc3RpbGwgbmVlZHMg dG8gYmUgZml4ZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KU2VudCBmcm9tIG15IGlQ aG9uZQ0KDQo+IE9uIDkgT2N0IDIwMTcsIGF0IDE5LjIwLCBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFy YWxkQGFsdmVzdHJhbmQubm8+IHdyb3RlOg0KPiANCj4gSSBoYXZlIHJlYWQgdGhyb3VnaCBkcmFm dC1pZXRmLWljZS1yZmM1MjQ1YmlzLTEyIC0gYm90aCBhcyBhIGdlbmVyaWMNCj4gcmV2aWV3ZXIg YW5kIHdpdGggdGhlIHBlcnNwZWN0aXZlIG9mICJkb2VzIHRoaXMgZG8gd2hhdCBSVENXRUIgcmVx dWlyZXMiLg0KPiANCj4gSSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgZ29vZCBlbm91Z2ggdG8g cHVibGlzaCwgYnV0IGNvdWxkIGJlIGltcHJvdmVkDQo+IHNvbWV3aGF0ICh1c3VhbGx5LCBhbGwg ZG9jdW1lbnRzIGNhbikuDQo+IA0KPiBNb3N0IGltcG9ydGFudCBwb2ludHM6DQo+IA0KPiAqIFRo ZSBwcm90b2NvbCBoYXMgYmVlbiBkZXNpZ25lZCBhbmQgcmV2aXNlZCB0byBiZSB1c2FibGUgd2l0 aCBub24tbWVkaWENCj4gZGF0YSwgYnV0IHRoZSBpbnRyb2R1Y3Rpb24gYW5kIGFic3RyYWN0IGRv IG5vdCByZWZsZWN0IHRoaXMuIEV4cHVuZ2luZw0KPiB0aGUgbWVkaWEgYmlhcyBmcm9tIHRoZSBi b2R5IG9mIHRoZSBkb2N1bWVudCBpcyBwcm9iYWJseSBub3Qgd29ydGggaXQsDQo+IGJ1dCB0aGUg aW50cm8gYW5kIGFic3RyYWN0IHNob3VsZCBtZW50aW9uIGl0Lg0KPiAqIFNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNob3VsZCBtZW50aW9uIHRoZSBwcm9ibGVtIHRoYXQgSUNFIHJldmVhbHMNCj4g YWRkcmVzc2VzIHRoYXQgbWlnaHQgb3RoZXJ3aXNlIHJlbWFpbiBoaWRkZW4sIGFuZCB0aGF0IHRo aXMgaXMgYSBwcml2YWN5DQo+IGNvbmNlcm4uDQo+ICogVGhlIGRvY3VtZW50IGhhcyByZW1vdmVk IGFsbCB0aGUgU0RQIHNwZWNpZmljIHBhcnRzIChnb29kKSwgYnV0IHRoZQ0KPiByZXF1aXJlbWVu dHMgaXQgcGxhY2VzIG9uIHRoZSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gYXJlbuKAmXQgY29sbGVj dGl2ZWx5DQo+IGRvY3VtZW50ZWQgYW55d2hlcmUuIEEgc2VjdGlvbiBkZXNjcmliaW5nIHRoaXMg d291bGQgaGVscCBjb21wcmVoZW5zaW9uDQo+IGZvciBwZW9wbGUgZGV2ZWxvcGluZyBzaWduYWxs aW5nIHByb3RvY29scyBmb3IgdXNlIHdpdGggSUNFLg0KPiAqIFRoZSBkZWZpbml0aW9uIG9mIOKA nGNvbXBvbmVudOKAnSB0YWxrcyBhYm91dCBhIGNvbXBvbmVudCBoYXZpbmcgb25lDQo+IGFkZHJl c3MuIEkgYmVsaWV2ZSB0aGF0IGluIGN1cnJlbnQgdXNhZ2UsIGl0IHNob3VsZCBiZSBkZWZpbmVk IHRvIGhhdmUNCj4gYW4gYWRkcmVzcyBwYWlyLiAobm9uLXN5bW1ldHJpYyBSVFAgaXMgZGVhZCku DQo+IA0KPiBUaGUgcmVzdCBvZiBteSBzdWdnZXN0ZWQgY2hhbmdlcyBhcmUgbml0cywgSSB0aGlu ay4NCj4gDQo+IEkgZW5jbG9zZSB0aGUgZnVsbCB0ZXh0IG9mIG15IHJldmlldyBhcyBQREY7IGFw YXJ0IGZyb20gdGhlIHN0dWZmIGFib3ZlLA0KPiBJIGRvbid0IHRoaW5rIHRob3NlIGNvbW1lbnRz IG5lZWRzIG11Y2ggV0cgZGlzY3Vzc2lvbi4gRWRpdG9yOiBQbGVhc2UNCj4gcmFpc2UgaXNzdWVz IGlmIHlvdSB0aGluayBzb21lIGRvIG5lZWQgaXQhDQo+IA0KPiBIb3BlIHRoaXMgaXMgaGVscGZ1 bC4NCj4gDQo+IEhhcmFsZA0KPiA8SUNFIEJJUyByZmM1MjQ1YmlzLTEyIHJldmlldy5wZGY+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dl YiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= --Apple-Mail-0B2760C6-94C8-4A29-A4F7-60535C60F673 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpIEhhcmFsZCw8 ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdSBWRVJZIG11Y2ghIDopPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5JIGRvIGFncmVlIHRoYXQgdGhlIGRvY3VtZW50IGNvdWxkIHN0aWxsIGJlIGlt cHJvdmVkLCBhbmQgaWYgSSBoYWQgdGhlIHRpbWUgYW5kIGN5Y2xlcy4uLiBCdXQsIHdlIG5lZWQg dG8gZHJhdyB0aGUgbGluZSBzb21ld2hlcmUsIGFuZCB0aGF04oCZcyB3aHkgaXQgaXMgaW1wb3J0 YW50IHRoYXQgcGVvcGxlIHJlYWQgdGhlIGRvY3VtZW50IGluIGNhc2UgdGhlcmUgaXMgc29tZXRo aW5nIHRoZXkgdGhpbmsgc3RpbGwgbmVlZHMgdG8gYmUgZml4ZWQuPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5SZWdhcmRzLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q2hyaXN0ZXI8L2Rpdj48 ZGl2Pjxicj48YnI+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5TZW50IGZyb20gbXkgaVBo b25lPC9kaXY+PGRpdj48YnI+T24gOSBPY3QgMjAxNywgYXQgMTkuMjAsIEhhcmFsZCBBbHZlc3Ry YW5kICZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iPmhhcmFsZEBhbHZl c3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48ZGl2PjxzcGFuPkkgaGF2ZSByZWFkIHRocm91Z2ggZHJhZnQtaWV0Zi1pY2UtcmZjNTI0 NWJpcy0xMiAtIGJvdGggYXMgYSBnZW5lcmljPC9zcGFuPjxicj48c3Bhbj5yZXZpZXdlciBhbmQg d2l0aCB0aGUgcGVyc3BlY3RpdmUgb2YgImRvZXMgdGhpcyBkbyB3aGF0IFJUQ1dFQiByZXF1aXJl cyIuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkkgYmVsaWV2ZSB0aGlzIGRvY3Vt ZW50IGlzIGdvb2QgZW5vdWdoIHRvIHB1Ymxpc2gsIGJ1dCBjb3VsZCBiZSBpbXByb3ZlZDwvc3Bh bj48YnI+PHNwYW4+c29tZXdoYXQgKHVzdWFsbHksIGFsbCBkb2N1bWVudHMgY2FuKS48L3NwYW4+ PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+TW9zdCBpbXBvcnRhbnQgcG9pbnRzOjwvc3Bhbj48 YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj4qIFRoZSBwcm90b2NvbCBoYXMgYmVlbiBkZXNpZ25l ZCBhbmQgcmV2aXNlZCB0byBiZSB1c2FibGUgd2l0aCBub24tbWVkaWE8L3NwYW4+PGJyPjxzcGFu PmRhdGEsIGJ1dCB0aGUgaW50cm9kdWN0aW9uIGFuZCBhYnN0cmFjdCBkbyBub3QgcmVmbGVjdCB0 aGlzLiBFeHB1bmdpbmc8L3NwYW4+PGJyPjxzcGFuPnRoZSBtZWRpYSBiaWFzIGZyb20gdGhlIGJv ZHkgb2YgdGhlIGRvY3VtZW50IGlzIHByb2JhYmx5IG5vdCB3b3J0aCBpdCw8L3NwYW4+PGJyPjxz cGFuPmJ1dCB0aGUgaW50cm8gYW5kIGFic3RyYWN0IHNob3VsZCBtZW50aW9uIGl0Ljwvc3Bhbj48 YnI+PHNwYW4+KiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzaG91bGQgbWVudGlvbiB0aGUgcHJv YmxlbSB0aGF0IElDRSByZXZlYWxzPC9zcGFuPjxicj48c3Bhbj5hZGRyZXNzZXMgdGhhdCBtaWdo dCBvdGhlcndpc2UgcmVtYWluIGhpZGRlbiwgYW5kIHRoYXQgdGhpcyBpcyBhIHByaXZhY3k8L3Nw YW4+PGJyPjxzcGFuPmNvbmNlcm4uPC9zcGFuPjxicj48c3Bhbj4qIFRoZSBkb2N1bWVudCBoYXMg cmVtb3ZlZCBhbGwgdGhlIFNEUCBzcGVjaWZpYyBwYXJ0cyAoZ29vZCksIGJ1dCB0aGU8L3NwYW4+ PGJyPjxzcGFuPnJlcXVpcmVtZW50cyBpdCBwbGFjZXMgb24gdGhlIG5lZ290aWF0aW9uIG1lY2hh bmlzbSBhcmVu4oCZdCBjb2xsZWN0aXZlbHk8L3NwYW4+PGJyPjxzcGFuPmRvY3VtZW50ZWQgYW55 d2hlcmUuIEEgc2VjdGlvbiBkZXNjcmliaW5nIHRoaXMgd291bGQgaGVscCBjb21wcmVoZW5zaW9u PC9zcGFuPjxicj48c3Bhbj5mb3IgcGVvcGxlIGRldmVsb3Bpbmcgc2lnbmFsbGluZyBwcm90b2Nv bHMgZm9yIHVzZSB3aXRoIElDRS48L3NwYW4+PGJyPjxzcGFuPiogVGhlIGRlZmluaXRpb24gb2Yg 4oCcY29tcG9uZW504oCdIHRhbGtzIGFib3V0IGEgY29tcG9uZW50IGhhdmluZyBvbmU8L3NwYW4+ PGJyPjxzcGFuPmFkZHJlc3MuIEkgYmVsaWV2ZSB0aGF0IGluIGN1cnJlbnQgdXNhZ2UsIGl0IHNo b3VsZCBiZSBkZWZpbmVkIHRvIGhhdmU8L3NwYW4+PGJyPjxzcGFuPmFuIGFkZHJlc3MgcGFpci4g KG5vbi1zeW1tZXRyaWMgUlRQIGlzIGRlYWQpLjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48 c3Bhbj5UaGUgcmVzdCBvZiBteSBzdWdnZXN0ZWQgY2hhbmdlcyBhcmUgbml0cywgSSB0aGluay48 L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+SSBlbmNsb3NlIHRoZSBmdWxsIHRleHQg b2YgbXkgcmV2aWV3IGFzIFBERjsgYXBhcnQgZnJvbSB0aGUgc3R1ZmYgYWJvdmUsPC9zcGFuPjxi cj48c3Bhbj5JIGRvbid0IHRoaW5rIHRob3NlIGNvbW1lbnRzIG5lZWRzIG11Y2ggV0cgZGlzY3Vz c2lvbi4gRWRpdG9yOiBQbGVhc2U8L3NwYW4+PGJyPjxzcGFuPnJhaXNlIGlzc3VlcyBpZiB5b3Ug dGhpbmsgc29tZSBkbyBuZWVkIGl0ITwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5I b3BlIHRoaXMgaXMgaGVscGZ1bC48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+SGFy YWxkPC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGRpdj4mbHQ7SUNFIEJJUyByZmM1MjQ1YmlzLTEyIHJldmlldy5wZGYmZ3Q7PC9kaXY+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPnJ0Y3dlYiBt YWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90 ZT48L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-0B2760C6-94C8-4A29-A4F7-60535C60F673-- --Apple-Mail-A9D1D8EB-E2F1-4B1D-9714-5284422E70D4 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBfkw ggPhoAMCAQICEDENcj3BkzWA84WFoa5BUMgwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMTA0MTIy ODE5WhcNMTcxMTA0MTIyODE4WjBvMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0 ZXIgSG9sbWJlcmcxLTArBgkqhkiG9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTEPMA0GA1UEBRMGTE1GQ0hIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjG+3x1iF fQiBWGKL/OjUf+om3VVdCPmalSxNtc0Ae6LRb+g0ypVVxO4oguBwrzIZRpIN/6hZgIQLYuWdWe/u XhDBCD+SSRGe3zJugTBN9wZHYIOBHya6uBVBtvB8Nv/9Ksd42Vrytlu+dQJhLlCeZ5GehdNBp8yZ joW73mnQvBOZHqsKMPa4mtP1msx4it8Mc422p6EGmSAPqAio+WMgr/HAk2kpOKRAG18MbYSfewWm T2obJ2+BGRD9PIMUeSBPTUYuOxKoei7QY4lqWgeNhJghAcXNriEPO7ZSdHtkrwqO+K6sZ3V7VHml mrjI47eA54SXYl2WNuOA+SdYFrLERQIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgG CCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRp dmlkdWFsY2F2Mi5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjAdBgNVHQ4EFgQUVKNN/w60QFtsaTJoTdrhpLw4MeowHwYDVR0jBBgwFoAUsQ3K1Ea3r4YC wy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQC28KhuYp4Zf8T8 bLkFnB+xjlGSDwMNCZSpbVUP05bBe4oNCdYss2qOhrFyLSfR91mT6wsuREHISZu6nJ9pCl/Dhm/m K+dxYrC0doMfqpK0DAznYsfVmrNHLyIw1owEJxGW8c/2vnc3QD9E68Dbw/NvNmyMtHwrf97qAX8z J70BvuMBtNfGw7p3PjQo9RZEipEkW/Xz9mdpYuuaXyXMbRiH2+c7FyWRuBrW3tP4cZY9zXHIwf81 Tzuz0PpZ1psbToiUNpaAPutr0K3lEK99vFyuCBxZ6FPs14lX1Ddrq774q0B+x2u9EwTGttCfDZ9m hL2OkGDBECYQIlZjU4r+BBhr+YXl+b2/Mmo+6a+GCL2+g9K/qcKb3xBPGIQBFiYAmT+5Oc0MIa6b khf7PsBK7l6OfbKvWzgnn4IZLXOX8A7vL3nffHIn0T1J7k/3ObJSSfC4xZ/Hfi5xpJVHRQPZC4yC VVcfkzOA/zk2kRvpjxW2NqU8kdFfODxuxy3pLqTbBc3JnuyAZEPtc5G/YY8+qcoqHX+q4e6YfvFx 1jYM2wuT3RggDYPH1Vq8aqjqBM73FHDzMul1ybNCVoVmrPJiXR6tpBgwxKQOwWwWrZrRKs4l0Z2B iXkCt3jA117ZjngUgOMu2GeO8vgsb25J0kOXcoIcJBKvmuzkTxlY7I7ViWCenTCCBrYwggSeoAMC AQICEQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29u ZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0 MDUyNzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+J OOqjddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2a vWWXhPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvM iZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtk dldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1 EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3W AEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJ DxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiA SHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCC AbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFz b25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbK DnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4IC AQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9 IewyaV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYV Cd+xhsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1 qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhG WHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qh tu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVw GB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP 4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TG bTGCApYwggKSAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjICEDENcj3BkzWA84WFoa5BUMgwCQYFKw4DAhoFAKCCAR0wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDA5MTYzOTE5WjAjBgkqhkiG 9w0BCQQxFgQUBVeXoUTEmF4wQ05eyJU68B36YxAwXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGT NYDzhYWhrkFQyDBfBgsqhkiG9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEDENcj3BkzWA84WFoa5BUMgwDQYJKoZI hvcNAQEBBQAEggEAhizLT5b/s+Y+I0SErj5KxWU7qLoBK1bWp9JB9YQrZvDJ5lLAej/Uner6Ggxm POREfqtSDst/bjvwLvuAMsvYwxS32BCYkpsJUJer2L8wYRMLvejbw5A2nk/gaR/6d/PLQR0g7is5 v5STedsJbaDvK1AERalvwCSDSMHFfj4kuXDHxYTdcvtxlOG1FawbUKUxRxTK+ClFSJY0kRg+u9d/ rX7UqAA+OCwjxY+grmDrnHXvBnOGL3x01uU1/KRuhWMlpLhr9FNDZ7qTRWUdCF/It71vaioo+DXB 52f8p0KXUNaQjz4iF/J7gQO+rxhxEWqEzgLmlybW0aJk6zBpw+LPFgAAAAAAAA== --Apple-Mail-A9D1D8EB-E2F1-4B1D-9714-5284422E70D4-- From nobody Mon Oct 9 21:17:08 2017 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 60C6A132F3F; Mon, 9 Oct 2017 21:17:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150760902634.18405.8381092546718350442@ietfa.amsl.com> Date: Mon, 09 Oct 2017 21:17:06 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-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, 10 Oct 2017 04:17:06 -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 WG of the IETF. Title : Annotated Example SDP for WebRTC Authors : Suhas Nandakumar Cullen Jennings Filename : draft-ietf-rtcweb-sdp-07.txt Pages : 108 Date : 2017-10-09 Abstract: The Real-Time Communications in WEB-browsers (Rtcweb) working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the Rtcweb framework, Session Description protocol (SDP) is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common Rtcweb use-cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-07 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 9 21:19:03 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC5132F3F for ; Mon, 9 Oct 2017 21:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9Fj-khxdiRW for ; Mon, 9 Oct 2017 21:18:14 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D58133011 for ; Mon, 9 Oct 2017 21:18:13 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id f46so15958985uae.1 for ; Mon, 09 Oct 2017 21:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=UnebdK7CIDrZ5DSAd7uNdz797c+a4KQH7BkCyJ18YQk=; b=oqsVx47PED62gH/c4tKA4SEOv6X1HwofFu9QryeGX689MCuihMtheHvnJ16F3VsCij CUEfZVSM+02UCD1yH14ROA74JgSoKqqP/aZI5OuWwr4KX5K8SX1jLXvDtwvYPVL370wu 5XF2Qn9/jtDQ6J1Ldk4XW5/XoxXR+Ccog6j0udO2j0Jz57gYlslM2UV1VawXN7mWx2b8 fFuSCtE4M2p5B3tJBV14rrN9Abu/WN5nUTh22zk7hGSAqYmDylY2nYlhocf2+XI4tdeE IKACk4PAXz/GlMjIbpdrp8bX3f8RmXed9LZIKrFNO4xCxAlham0KDXLG53ujhJ+ZuFEd x8kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=UnebdK7CIDrZ5DSAd7uNdz797c+a4KQH7BkCyJ18YQk=; b=UWHe+BOX0nAkxY3tzpEnqeZT+Cpag51HNtMq18umeUBMz6+L9lJt5O8jHADbrwIKDz 1wgVz8YNEipUVz5Ivng4KRkqsiqiOfvUMvQi4z6cVa875WS7L8mBHNWLvpvWs3xsNjsB 5jRRJRKaS2bKVyfkh+IxDWfyWlE4Klmj8zv7BGJMN8UZfohB9CFCrHrVNn4mMdJ3y1AA gCEyzNVWqQgTbbzpjbIUZegq7L7FVqCI+9tsWFMP1mpMrRNCWFaa7Bao30MnJ/qTDr/5 yreY4aE/RqDsFFJgrYcH4y5o1FVTJa9zH8mPBovaTR0QlPpxs55pYp/l1C5WasW1xjmR i9WA== X-Gm-Message-State: AMCzsaVa+UkS+F/iZ2Iya89Y8UhrjBv5WfOSjaIOlA1RoEJRvdExl299 rRClfd1NxC+pp9xRm8KK/z0SVNjmmN1nt25xL3g= X-Google-Smtp-Source: AOwi7QAljyUYk6CXtPnpur+zB9n3LqTEI8YnacyHjDQP25dZ8hV1Hb2wyYl1u2duUpsa0Az2qOxBXKldRxAOOtKFzzA= X-Received: by 10.176.21.45 with SMTP id o42mr7181483uae.6.1507609092780; Mon, 09 Oct 2017 21:18:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.10.12 with HTTP; Mon, 9 Oct 2017 21:18:12 -0700 (PDT) In-Reply-To: <150760902634.18405.8381092546718350442@ietfa.amsl.com> References: <150760902634.18405.8381092546718350442@ietfa.amsl.com> From: Suhas Nandakumar Date: Mon, 9 Oct 2017 21:18:12 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a1145af966f75bf055b2998d0" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Oct 2017 04:19:01 -0000 --001a1145af966f75bf055b2998d0 Content-Type: text/plain; charset="UTF-8" This is just a keep-alive version to keep the draft from expiring. Soon to follow a new version with review from Nils addressed. Thanks Suhas On Mon, Oct 9, 2017 at 9:17 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > WG of the IETF. > > Title : Annotated Example SDP for WebRTC > Authors : Suhas Nandakumar > Cullen Jennings > Filename : draft-ietf-rtcweb-sdp-07.txt > Pages : 108 > Date : 2017-10-09 > > Abstract: > The Real-Time Communications in WEB-browsers (Rtcweb) working group > is charged to provide protocol support for direct interactive rich > communication using audio, video and data between two peers' web > browsers. With in the Rtcweb framework, Session Description protocol > (SDP) is used for negotiating session capabilities between the peers. > Such a negotiation happens based on the SDP Offer/Answer exchange > mechanism. > > This document provides an informational reference in describing the > role of SDP and the Offer/Answer exchange mechanism for the most > common Rtcweb use-cases. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-07 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-07 > > > 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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1145af966f75bf055b2998d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is just a keep-alive version to keep the draft from e= xpiring. Soon to follow a new version with review from Nils addressed.
=
Thanks
Suhas

On Mon, Oct 9, 2017 at 9:17 PM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers WG= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Annotated Example SDP for WebRTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-sdp-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 108
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-09

Abstract:
=C2=A0 =C2=A0The Real-Time Communications in WEB-browsers (Rtcweb) working = group
=C2=A0 =C2=A0is charged to provide protocol support for direct interactive = rich
=C2=A0 =C2=A0communication using audio, video and data between two peers= 9; web
=C2=A0 =C2=A0browsers.=C2=A0 With in the Rtcweb framework, Session Descript= ion protocol
=C2=A0 =C2=A0(SDP) is used for negotiating session capabilities between the= peers.
=C2=A0 =C2=A0Such a negotiation happens based on the SDP Offer/Answer excha= nge
=C2=A0 =C2=A0mechanism.

=C2=A0 =C2=A0This document provides an informational reference in describin= g the
=C2=A0 =C2=A0role of SDP and the Offer/Answer exchange mechanism for the mo= st
=C2=A0 =C2=A0common Rtcweb use-cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-sdp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcw= eb-sdp-07
https://datatracker.ietf.org/doc/= html/draft-ietf-rtcweb-sdp-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-rtcweb-sdp-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--001a1145af966f75bf055b2998d0-- From nobody Tue Oct 10 05:31:07 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F5D13451A for ; Tue, 10 Oct 2017 05:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.812 X-Spam-Level: X-Spam-Status: No, score=0.812 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 94ZiDsGqXJol for ; Tue, 10 Oct 2017 05:30:58 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B928134508 for ; Tue, 10 Oct 2017 05:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 830B47C068C for ; Tue, 10 Oct 2017 14:30:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1hqh6WDesN2 for ; Tue, 10 Oct 2017 14:30:52 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:c5a7:16e:54b4:c6f3] (unknown [IPv6:2001:470:de0a:1:c5a7:16e:54b4:c6f3]) by mork.alvestrand.no (Postfix) with ESMTPSA id B93727C044C for ; Tue, 10 Oct 2017 14:30:52 +0200 (CEST) References: <2260f3c9-e5e2-4e13-a121-9fe19e373278@googlegroups.com> To: "rtcweb@ietf.org" From: Harald Alvestrand X-Forwarded-Message-Id: <2260f3c9-e5e2-4e13-a121-9fe19e373278@googlegroups.com> Message-ID: <9e18d97b-c8d1-2ddf-c66f-4a08be94b321@alvestrand.no> Date: Tue, 10 Oct 2017 14:30:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2260f3c9-e5e2-4e13-a121-9fe19e373278@googlegroups.com> Content-Type: multipart/alternative; boundary="------------FBE4FA585D7E20BEBB8B87C2" Content-Language: en-US Archived-At: Subject: [rtcweb] Fwd: [discuss-webrtc] Google is releasing a WebRTC interoperability test system as open source project X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Oct 2017 12:31:06 -0000 This is a multi-part message in MIME format. --------------FBE4FA585D7E20BEBB8B87C2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This should be interesting for anyone who wants to make sure WebRTC apps keep running in multiple browsers, as well as (fo course) browser developers. -------- Forwarded Message -------- Subject: [discuss-webrtc] Google is releasing a WebRTC interoperability test system as open source project Date: Tue, 10 Oct 2017 02:43:55 -0700 (PDT) From: huib@webrtc.org Reply-To: discuss-webrtc@googlegroups.com To: discuss-webrtc We’re pleased to announce KITE , a new tool for testing WebRTC interoperability across browsers. With this open source project we aim to improve interoperability across browsers and ensure WebRTC is a stable and predictable standard for real time communications on the web. The system is designed to run tests that establish WebRTC sessions between different browsers on different operating systems, reporting the results in a convenient dashboard. The system can be setup to run stand alone, or as a Selenium grid consisting of different test nodes running different test environments. The test nodes can run on physical or virtual machines. In addition, KITE supports cloud solutions such as SauceLabs, BrowserStack and TestingBot. KITE supports Chrome, Firefox, Safari and Edge, as well as other browsers implementing WebDriver. KITE has been designed and developed by the WebRTC enthusiasts at CosMo Software , and is part of Google’s contribution towards WebRTC 1.0. It supplements the already existing Web Platform Tests by allowing us to test interoperability between different browsers, not just one browser at a time. In the upcoming months we aim to further extend KITE with new test features and connection tests. We encourage developers to try out KITE, and welcome contributions to the open source project. Regards, Huib Kleinhout Product Manager @ Google -- --- You received this message because you are subscribed to the Google Groups "discuss-webrtc" group. To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com . To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2260f3c9-e5e2-4e13-a121-9fe19e373278%40googlegroups.com . For more options, visit https://groups.google.com/d/optout. --------------FBE4FA585D7E20BEBB8B87C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This should be interesting for anyone who wants to make sure WebRTC apps keep running in multiple browsers, as well as (fo course) browser developers.



-------- Forwarded Message --------
Subject: [discuss-webrtc] Google is releasing a WebRTC interoperability test system as open source project
Date: Tue, 10 Oct 2017 02:43:55 -0700 (PDT)
From: huib@webrtc.org
Reply-To: discuss-webrtc@googlegroups.com
To: discuss-webrtc <discuss-webrtc@googlegroups.com>


We’re pleased to announce KITE, a new tool for testing WebRTC interoperability across browsers. With this open source project we aim to improve interoperability across browsers and ensure WebRTC is a stable and predictable standard for real time communications on the web.


The system is designed to run tests that establish WebRTC sessions between different browsers on different operating systems, reporting the results in a convenient dashboard.

The system can be setup to run stand alone, or as a Selenium grid consisting of different test nodes running different test environments. The test nodes can run on physical or virtual machines. In addition, KITE supports cloud solutions such as SauceLabs, BrowserStack and TestingBot. KITE supports Chrome, Firefox, Safari and Edge, as well as other browsers implementing WebDriver.


KITE has been designed and developed by the WebRTC enthusiasts at CosMo Software, and is part of Google’s contribution towards WebRTC 1.0. It supplements the already existing Web Platform Tests by allowing us to test interoperability between different browsers, not just one browser at a time.


In the upcoming months we aim to further extend KITE with new test features and connection tests. We encourage developers to try out KITE, and welcome contributions to the open source project.

Regards,

Huib Kleinhout

Product Manager @ Google

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2260f3c9-e5e2-4e13-a121-9fe19e373278%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--------------FBE4FA585D7E20BEBB8B87C2-- From nobody Tue Oct 10 11:32:15 2017 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 06CA11346BC; Tue, 10 Oct 2017 11:32:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150766032571.13523.12984197593088868167@ietfa.amsl.com> Date: Tue, 10 Oct 2017 11:32:06 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-24.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-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, 10 Oct 2017 18:32:06 -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 WG of the IETF. Title : JavaScript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-24.txt Pages : 115 Date : 2017-10-10 Abstract: This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-24 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 Oct 11 00:23:14 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB88132153 for ; Wed, 11 Oct 2017 00:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JtX319_p929d for ; Wed, 11 Oct 2017 00:23:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A1C2E132076 for ; Wed, 11 Oct 2017 00:23:11 -0700 (PDT) X-AuditID: c1b4fb3a-de7ff70000006897-f3-59ddc6dd9c50 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2B.A3.26775.DD6CDD95; Wed, 11 Oct 2017 09:23:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Wed, 11 Oct 2017 09:23:08 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP: SDP end-of-candidates attribute reference Thread-Index: AQHTQmHJUOIKIyxquk2y6jLoUkC2KQ== Date: Wed, 11 Oct 2017 07:23:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D603A30C23A2Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7k+7dY3cjDe5/0bNY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGQ0/vjIXfBKvaJvRwt7A2C/axcjJISFgIvH9Th9bFyMXh5DA EUaJTfMPMEM4ixglPpz+yt7FyMHBJmAh0f1PG6RBREBd4vLDC+wgtjBQ+PbBBywQcVuJX5P3 MUPYehJPpj4Ba2URUJW48bwaJMwrYC1xYN9DsFZGATGJ76fWMIHYzALiEreezGeCuEdAYsme 88wQtqjEy8f/WEFsUaCRG07cBhspIaAkMW1rGkRrgkTHizPsEOMFJU7OfMIygVFoFpKps5CU zUJSBhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMELa1xNvZk1HULGDkWMUoWpxaXJybbmSkl1qU mVxcnJ+nl5dasokRGCcHt/y22sF48LnjIUYBDkYlHt7q3XcjhVgTy4orcw8xSnAwK4nwVq8D CvGmJFZWpRblxxeV5qQWH2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cCoM/F8ccmu LRFPv5TyPmtlf5STPWm2itWLWzNYemwTbzOVlBd9P+H00kpH4+yG30ybHIJlpzK1zTGfeDz5 9Q4/24v8H0VW/WBalbidxVDY8f2v21a+8oVN2gXPnOoUOfKiZp/Yubny3X/JZRue3mc0W8z5 wjR1R+1/u2MKev+j2vUmXVbr72FQYinOSDTUYi4qTgQAf30hc48CAAA= Archived-At: Subject: [rtcweb] JSEP: SDP end-of-candidates attribute reference X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Oct 2017 07:23:13 -0000 --_000_D603A30C23A2Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, JSEP references draft-ietf-ice-trickle for the SDP =91end-of-candidates=92 = attribute. But, draft-ice-trickle only talks about a generic end-of-candidates indicat= ion. For SDP, the actual SDP attribute is defined in draft-ietf-mmusic-tric= kle-ice-sip. Shouldn=92t JSEP reference that spec instead? Regards, Christer --_000_D603A30C23A2Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <119147AEDA6CAD499197C6ABC1308A16@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

JSEP references draft-ietf-ice-trickle for the SDP =91end-of-candidates=92 = attribute.

But= , draft-ice-trickle only talks about a generic end-of-candidates indication= . For SDP, the actual SDP attribute is defined in draft-ietf-mmusic-trickle-ice-sip. Shouldn=92t JSEP reference that spec instead?
=
= Regards,
=
= Christer


--_000_D603A30C23A2Fchristerholmbergericssoncom_-- From nobody Wed Oct 11 10:29:49 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C137132397 for ; Wed, 11 Oct 2017 10:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk6NnXmQO9Pf for ; Wed, 11 Oct 2017 10:29:46 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 B52A412895E for ; Wed, 11 Oct 2017 10:29:45 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id z4so1543950uaz.5 for ; Wed, 11 Oct 2017 10:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fvBKeqM2GjmkhsZlSihodkr2NaSvA97f40B35WQ/9C8=; b=Ib5zhZXNB4rCrRDQTbU8br7x/NIa95ENCJ+uzlRa24Ix84gWUxBD7Xbgk88XUPG+Lc 1kUCqPtODxcVhQft6noB+vax1bzP2aNY2s5s0sxJCrL0rRr4MklxXPy1Sp54KGOcm9mv RXBhKOIOTVhE9VocqxUqRwQugkrty/jQA+hK0JSNciz3EJsgpROZsZCmjPyXAXwI6/ol 9+0LTXTCVNu6aAu3fZ3jbCKmAHLe3xtEZQLUpkksTzDE+sd9EYuGpKaMEYkWEXvQocrC 1e4LVBLOfeMsEl7jkk5/0NughOd6LrFGbFztugNWEoP2nrczr86BWmpCUYgx3BSg4s99 mQ1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fvBKeqM2GjmkhsZlSihodkr2NaSvA97f40B35WQ/9C8=; b=sQ45hQlZvzxhNGySBorieMdR1Y/JxekeFe6i7WLhTlEEjt5mCEK8i0wCt65rrSVEUX 5ZsFqhzNdfZviZpODiCadfEmPNw/rtNtScQIU+xuTr6QQ8qP82T1oPwxClmd6dZUMZsi UHob3GbiGmY9wQqqKHtP4pPtuCo87Tg4KcNTtn6Z43pjLsLr7WCesUSLuI/DCkFBpxqa ejsNFghEnowfublrUFeiYW6pj9v4SyAyB3kj1n+xswvC52FVv0F+Z62RO06DKqd4C7RF UbvjI6pYMNBRTl7ayrDrCOCvARPhdZO586q8wyZ1XePTHBTS2Kg1YCLKh+h3T0zo3x2E Dnxg== X-Gm-Message-State: AMCzsaUGbKe/+wLaGInQmpjjsySS+iE9o2/iKRKUiMHyo3KGFPln+6wW hqfaucGt+OxPjUEnqVBPZtoq6Xl/WbWb66m4RzpNJePzxjk= X-Google-Smtp-Source: AOwi7QB4er1F8vNQhl7mhdCweI73ukYquPGtEdq+XJDcNOINDJ0yCVMePJT4CV/Gbx9FJ1AMpjtzAoglXvrTY0auoHg= X-Received: by 10.159.48.74 with SMTP id i10mr301054uab.115.1507742984213; Wed, 11 Oct 2017 10:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.169.130 with HTTP; Wed, 11 Oct 2017 10:29:43 -0700 (PDT) From: Taylor Brandstetter Date: Wed, 11 Oct 2017 10:29:43 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="f403045e3b64fcddbd055b48c42c" Archived-At: Subject: [rtcweb] Issue with "priority" defined in rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Oct 2017 17:29:48 -0000 --f403045e3b64fcddbd055b48c42c Content-Type: text/plain; charset="UTF-8" (Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625) When defining priority, rtcweb-transports says: The WebRTC prioritization model is that the application tells the WebRTC endpoint about the priority of media and data that is controlled from the API. ... The priority settings affect two pieces of behavior: Packet send sequence decisions and packet markings. Each is described in its own section below. The sections below are "Local prioritization" and "Usage of Quality of Service - DSCP and Multiplexing". The "local prioritization" section gives this guidance: When an WebRTC endpoint has packets to send on multiple streams that are congestion-controlled under the same congestion control regime, the WebRTC endpoint SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "high" priority flow will have the ability to send 8 times as much data as a "very-low" priority flow if both have data to send. This prioritization is independent of the media type. The details of which packet to send first are implementation defined. For example: If there is a high priority audio flow sending 100 byte packets, and a low priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. This has two significant issues I can see: - It only allows ratios of 1:2:4:8. This is not granular enough to be very useful. Especially when balancing transmission capacity between audio tracks and video tracks; in practice it's common for video tracks to use much more than 8 times the bitrate of audio tracks. - A single enum is used for both relative bitrate and relative QoS priority. But in my experience it's common for an application to want a flow that uses *less* bitrate to have a *higher* QoS priority. This may even be the *more* common situation. So, why do we have one enum for both things? I'd propose defining the priority as something that only impacts the priority in network queues (QoS-level priority and SCTP priority, as previously discussed), and use something else to control the relative bitrate allocation. For example, a floating point value attached to each RTCEncodingParameters (say, relativeCapacity), where an encoding with twice the relativeCapacity of another encoding will be given twice the transmission capacity. If implementations can handle ratios of 1:2:4:8, I don't see any reason why they shouldn't be able to handle arbitrary ratios. --f403045e3b64fcddbd055b48c42c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

(= Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625)

When defining priority, rtcweb-transpor= ts says:

The WebRTC prioritization model = is that the application tells the
WebRTC= endpoint about the priority of media and data that is
controlled from the API.
= ...
The priority settings affect two pie= ces of behavior: Packet send
sequence de= cisions and packet markings. Each is described in its own
section below.

The sections below are "Local prioritiz= ation" and "Usage of Quality of Service - DSCP and Multiplexing&q= uot;. The "local prioritization" section gives this guidance:

=

When an WebRTC endpoint has packets to send= on multiple streams that
are congestion= -controlled under the same congestion control regime,
the WebRTC endpoint SHOULD cause data to be emitted in such a= way
that=C2=A0each stream at each level of priority is being= given
approximately twice the transmiss= ion capacity (measured in payload
bytes)= of the level below.

Thus, when congestion occurs, a "high" p= riority flow will have the
ability to se= nd 8 times as much data as a "very-low" priority flow if
both have data to send. This prioritization is i= ndependent of the
media type. The detail= s of which packet to send first are
impl= ementation defined.

For example: If there is a high priority audio flow sending= 100 byte
packets, and a low priority vi= deo flow sending 1000 byte packets, and
= outgoing capacity exists for sending >5000 payload bytes, it would beappropriate to send 4000 bytes (40 packets= ) of audio and 1000 bytes
(one packet) o= f video as the result of a single pass of sending
decisions.

This has two significant issues I can see:

  • It only allows ratios of 1:2:4:8= . This is not granular enough to be very useful. Especially when balancing = transmission capacity between audio tracks and video tracks; in practice it= 's common for video tracks to use much more than 8 times the bitrate of= audio tracks.
  • A single enum is used for both relative bitrate and relative = QoS priority. But in my experience it's common for an application to wa= nt a flow that uses=C2=A0less=C2= =A0bitrate to have a=C2=A0higher= =C2=A0QoS priority. This may even be the=C2=A0more=C2=A0common situation.

So, why do we have one enum for both things?= I'd propose defining the priority as something that only impacts the p= riority in network queues (QoS-level priority and SCTP priority, as previou= sly discussed), and use something else to control the relative bitrate allo= cation.

For exam= ple, a floating point value attached to each=C2=A0RTCEncodingParameters=C2=A0(say,=C2=A0relativeCapacity), where an encoding with tw= ice the=C2=A0relativeCapacity=C2=A0of another encoding will be giv= en twice the transmission capacity. If implementations can handle ratios of= 1:2:4:8, I don't see any reason why they shouldn't be able to hand= le arbitrary ratios.

--f403045e3b64fcddbd055b48c42c-- From nobody Wed Oct 11 14:40:09 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B160E1329B5 for ; Wed, 11 Oct 2017 14:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8RP8-XyiWJO for ; Wed, 11 Oct 2017 14:40:05 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 A23641330B3 for ; Wed, 11 Oct 2017 14:40:05 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id l196so4559062itl.4 for ; Wed, 11 Oct 2017 14:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=frBoLQd9K6kJ6OO1vSu4y6wQ2FEwuTHO7TpMFfK+bdM=; b=DJ8Ka6CCADVtwtrai25LubFDw1/6bgQRWVrfztDJzKf+vUof45PIQZJaCTDMEJdgj4 NCXQg9yDXdvZRqjoMo6PVIwp7ocCyZlyImVONCAPho3211sn2wsHIzc1l+LpiPp/bBvl qWwwxW4ecJwUEj6DuO+xxkhKNK2iAmNogrEp9z3pQnDL7PzN6pfGj4kBN2UeCryH1IF/ ACvpa1qKCWTAFiwQPnABLuOLBDRMhMWb1t9GpAo+b4IGQuyUfabHWsxCTtheiKmAKL9z lfEi09vj5TYCN05pwK9mInguGzrQR7ZUSye0ovXyiWEN/CnzD6bMSvO7oDhcRsSnmJhE KHsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=frBoLQd9K6kJ6OO1vSu4y6wQ2FEwuTHO7TpMFfK+bdM=; b=hP2+jc8JDXNQbB5+pSW5atR9a2tgiLvZGpdzidTfHSwZj4BMWT2ismApE4SJaE3Tmd Z75dmdWhs/mwLogsLfzspNd9G2xcb+ho/A3SbzPQmb0p7Mhtjkm7QDumHUFCCi60/tl4 kHjl9Vovzfvmqbp1EpvSSd/VPXc1kYtXQjTca0lL1bS40fhY23cOBczQ4vCQNi8CEWd2 LmmPkFIIkrlou1Yj7SBmbPbA0FLiO/2DnVZRil0iQH4wp3Ia+GsacxwQ8YRnkcWBC4hW xwzT16ajKr77COj83wjjdZspSDn2sX7DvQLWg+QbDgSFrueLLaXKsmHdlbd+eiK0rWUt G3og== X-Gm-Message-State: AMCzsaXwofmWtVldAzIimEUg0bgS1c4q+In0WFErCADQn+Qg2492uwxv PgJWmFy7nqH8GtKLTcEsa7U9Tjs3VdExTX27/HuItw== X-Google-Smtp-Source: AOwi7QDJ8MqySKgLPw8LUaZ2HmJMXgNfQkvJjp3pHPZGUU+P8ouJZs/2X2RHy4ycGyIamWHMlYv+U0jq5Z3CBtJh8QQ= X-Received: by 10.36.76.150 with SMTP id a144mr485912itb.39.1507758004711; Wed, 11 Oct 2017 14:40:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.175.136 with HTTP; Wed, 11 Oct 2017 14:39:44 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 11 Oct 2017 14:39:44 -0700 Message-ID: To: Christer Holmberg Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a11448f0247e9b3055b4c446d" Archived-At: Subject: Re: [rtcweb] JSEP: SDP end-of-candidates attribute reference X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Oct 2017 21:40:07 -0000 --001a11448f0247e9b3055b4c446d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree, the references in Sections 5.2.2 and 5.3.2 should be updated accordingly. https://github.com/rtcweb-wg/jsep/issues/841 On Wed, Oct 11, 2017 at 12:23 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > JSEP references draft-ietf-ice-trickle for the SDP =E2=80=98end-of-candid= ates=E2=80=99 > attribute. > > But, draft-ice-trickle only talks about a generic end-of-candidates > indication. For SDP, the actual SDP attribute is defined in > draft-ietf-mmusic-trickle-ice-sip. Shouldn=E2=80=99t JSEP reference that = spec > instead? > > Regards, > > Christer > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11448f0247e9b3055b4c446d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree, the references in Sectio= ns 5.2.2 and 5.3.2 should be updated accordingly.=C2=A0
https= ://github.com/rtcweb-wg/jsep/issues/841

On Wed, Oct 11, 2017 at 12:23 AM, Chris= ter Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

JSEP references draft-ietf-ice-trickle for the SDP =E2=80=98end-of-candidat= es=E2=80=99 attribute.

But, draft-ice-trickle only talks ab= out a generic end-of-candidates indication. For SDP, the actual SDP attribu= te is defined in=C2=A0draft-ietf-mmusic-trickle-ice-sip. Shouldn=E2=80=99t JSEP reference that spec instead?

Regards,

Christer



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

--001a11448f0247e9b3055b4c446d-- From nobody Mon Oct 16 03:03:17 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE3D1321A2; Mon, 16 Oct 2017 03:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 52WNGP5J51L0; Mon, 16 Oct 2017 03:03:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 038411321CB; Mon, 16 Oct 2017 03:03:13 -0700 (PDT) X-AuditID: c1b4fb3a-1c7889c000006897-f6-59e483e018f1 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 62.E1.26775.0E384E95; Mon, 16 Oct 2017 12:03:12 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 16 Oct 2017 12:02:09 +0200 From: Christer Holmberg To: Harald Alvestrand , "ice@ietf.org" CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 Thread-Index: AQHTQRqIopdqNKi4M0G7+rZLE/Y/d6LmXBGA Date: Mon, 16 Oct 2017 10:02:09 +0000 Message-ID: References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no> In-Reply-To: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7ge6D5ieRBjO6hSyO9XWxWXy7UGux 9l87uwOzx5UJV1g9liz5yRTAFMVlk5Kak1mWWqRvl8CV0X9rMmvBRaGKl3eusjYwfuPrYuTk kBAwkZh+9B9TFyMXh5DAEUaJxtVb2CCcJYwSTVN/MXYxcnCwCVhIdP/TBmkQEfCW+Pi5lQnE ZhZQl7iz+Bw7iC0s4CjR8aSdGaLGSaL30U1WCNtIYvaHC8wgY1gEVCX+7HMBMXkFrCX+X8wG qRAScJDY/vc/C0iYE2hK53JBkDCjgJjE91NroBaJS9x6Mp8J4mIBiSV7zjND2KISLx//A1sk KqAnseHEbXaIuKJE+9MGRohePYkbU6ewQdjWEncnvWSGsLUlli18DWbzCghKnJz5hGUCo/gs JOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjLiDW35b7WA8 +NzxEKMAB6MSD29z1pNIIdbEsuLK3EOMEhzMSiK8ek1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhgX/ZRseR2feuZ6fs757cu7Vs1i98vyDQxo/92z 0059ss2C9yuv/7mS/3kl/y/uB3Ztz72/X+7QqH3OeXBlEd+XT988GTbuWHBxrp/lp/VOJ7e/ T3EL2ZXnyt4gYxedqTPttKTGEq91D9VvOEau705PnJRQ/2XB68oaneuhUpYLWR/raAbOZAlV YinOSDTUYi4qTgQAm5fmBbQCAAA= Archived-At: Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Oct 2017 10:03:16 -0000 Hi Harald, Some feedback on your comments. >Most important points: > >* The protocol has been designed and revised to be usable with non-media >data, but the introduction and abstract do not reflect this. Expunging >the media bias from the body of the document is probably not worth it, >but the intro and abstract should mention it. We COULD do a search/replace operation, and replace =B3media=B2 with =B3dat= a=B2. We would end up with terms like =B3data stream=B2, =B3data packets=B2 etc, = but I guess that it would be ok. In the =B3data definition=B2 we would then describe that data includes both RTP and non-RTP data. >* Security considerations should mention the problem that ICE reveals >addresses that might otherwise remain hidden, and that this is a privacy >concern. I would be glad if someone could provide text for that, to make sure we get it right. >* The document has removed all the SDP specific parts (good), but the >requirements it places on the negotiation mechanism aren=B9t collectively >documented anywhere. A section describing this would help comprehension >for people developing signalling protocols for use with ICE. I can think of the following requirements: REQ: There MUST be a mechanism for ICE agents to determine whether the remote peer supports ICE REQ: There MUST be a mechanism for ICE agents to exchange candidate information REQ: There MUST be a mechanism for ICE agents to indicate an ICE restart to the remote peer >* The definition of =B3component=B2 talks about a component having one >address. I believe that in current usage, it should be defined to have >an address pair. (non-symmetric RTP is dead). Or, should we say =B3having one candidate pair=B2? A component is a piece of a data stream requiring a candidate pair; a data stream may require multiple components, each of which has to work for the data stream as a whole to work. For media streams based on RTP, unless RTP and RTCP are multiplexed in the same port, there are two components per media stream -- one for RTP, and one for RTCP. Regarding non-symmetric RTP, the spec says that the selected candidate pair MUST be used for sending and receiving media, so I guess that means symmetric RTP. Perhaps it would be good to point that out. Regards, Christer From nobody Mon Oct 16 05:08:55 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195BE132D49 for ; Mon, 16 Oct 2017 05:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qGe3fIsPVYjT for ; Mon, 16 Oct 2017 05:08:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 3B8C8127517 for ; Mon, 16 Oct 2017 05:08:51 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-41-59e4a150e0ea Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.D7.03220.051A4E95; Mon, 16 Oct 2017 14:08:49 +0200 (CEST) Received: from [147.214.163.82] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 16 Oct 2017 14:08:48 +0200 To: Taylor Brandstetter , RTCWeb IETF References: From: Magnus Westerlund Message-ID: <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com> Date: Mon, 16 Oct 2017 14:10:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060904070909010601080507" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7rm7gwieRBot/cVhcXvGQ1WLtv3Z2 ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAlXH32Ry2gvV7GCsW3rvF3sD4fDZjFyMnh4SA icSdo5eYuxi5OIQEjjBKHNy9gAnC2cwo8XzJBxaQKmEBD4kvEy+zg9giAj4Sr/78YAaxhQQC JP4c+QNWwyZgIXHzRyMbiM0rYC/RfvkdWA2LgKrE1ZOzwWpEBWIkJj64yAhRIyhxcuYToDgH B6dAoMTLraoge5kFuhklfmy+xgIxX1uioamDFeJSJYnr866zTGDkn4WkfRaynllAs5gFwiTO 3jYBqWEWEJdo+rKSFcI2k5i3+SEzhK0tsWzha2aIcjWJZa1KqMIgtrXEjF8H2SBsRYkp3Q/Z IWxTiddHPzJC2EYS7/Y0si9g5FnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhZB7f8Vt3B ePmN4yFGAQ5GJR7evx1PIoVYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCURXq+5QGnelMTKqtSi /Pii0pzU4kOM0hwsSuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoY66yKvZdLrPNbpR0fcvh3 ks2bpSo/T1jVcBku9RDcOX/Oc+0GyV8mv3SWWLUUswt66itvX3TMYeG2c/8/7DaRFezLKxfV 5yriuSq5vairJn7bArNjtgv2q6T7BFRsyZNLUbbfF7C/+9yt5j0B6koHfWf8fpezIqZ0+dEz ZzcnPl0eEpsTd+aDEktxRqKhFnNRcSIACd6W6LQCAAA= Archived-At: Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Oct 2017 12:08:54 -0000 --------------ms060904070909010601080507 Content-Type: multipart/alternative; boundary="------------16F198C876779C90941B20D9" Content-Language: en-GB This is a multi-part message in MIME format. --------------16F198C876779C90941B20D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Taylor, I think the text you quoted is directly related to your transmission=20 queuing. And as no one was willing to write up a specific queuing=20 algorithm that would be more flexible, the discussion in the WG at the=20 time this was written ended up in a per prioritization level round robin = queue basically, where each lower priority is given one transmission=20 slot in the upper queue. Thus giving roughly halving, but it could be=20 less actually depending on how many processes are part of a particular=20 level. I also think you scheme for relative capacity is likely good, but appear = to be missing two important parameters. One for minimal bit-rate, and=20 one for maximum. At least for audio sources, there is a limit to scaling = these both upwards and downwards. The upper limit when reached should be = redistributed, or otherwise it might be wasted. The minimal is an=20 interesting one. Because one have to decided if this means taking more=20 from the lower prioritise and how they relate to other. The classical=20 example of one audio plus one video comes to mind, where one would like=20 to maintain the audio in user interactive applications despite taking=20 more from the video. To the point where one have to turn off video to=20 maintain audio. So, I think you have to work on the proposal a bit more. Cheers Magnus Den 2017-10-11 kl. 19:29, skrev Taylor Brandstetter: > > (Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625) > > When defining priority, rtcweb-transports says: > > The WebRTC prioritization model is that the application tells the > WebRTC endpoint about the priority of media and data that is > controlled from the API. > ... > The priority settings affect two pieces of behavior: Packet send > sequence decisions and packet markings. Each is described in its ow= n > section below. > > The sections below are "Local prioritization" and "Usage of Quality of = > Service - DSCP and Multiplexing". The "local prioritization" section=20 > gives this guidance: > > When an WebRTC endpoint has packets to send on multiple streams tha= t > are congestion-controlled under the same congestion control regime,= > the WebRTC endpoint SHOULD cause data to be emitted in such a way > that each stream at each level of priority is being given > approximately twice the transmission capacity (measured in payload > bytes) of the level below. > > Thus, when congestion occurs, a "high" priority flow will have the > ability to send 8 times as much data as a "very-low" priority flow = if > both have data to send. This prioritization is independent of the > media type. The details of which packet to send first are > implementation defined. > > For example: If there is a high priority audio flow sending 100 byt= e > packets, and a low priority video flow sending 1000 byte packets, a= nd > outgoing capacity exists for sending >5000 payload bytes, it would = be > appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes= > (one packet) of video as the result of a single pass of sending > decisions. > > This has two significant issues I can see: > > * It only allows ratios of 1:2:4:8. This is not granular enough to > be very useful. Especially when balancing transmission capacity > between audio tracks and video tracks; in practice it's common for > video tracks to use much more than 8 times the bitrate of audio > tracks. > * A single enum is used for both relative bitrate and relative QoS > priority. But in my experience it's common for an application to > want a flow that uses /less/=C2=A0bitrate to have a /higher/=C2=A0Q= oS > priority. This may even be the /more/=C2=A0common situation. > > So, why do we have one enum for both things? I'd propose defining the=20 > priority as something that only impacts the priority in network queues = > (QoS-level priority and SCTP priority, as previously discussed), and=20 > use something else to control the relative bitrate allocation. > > For example, a floating point value attached to each=20 > |RTCEncodingParameters|=C2=A0(say, |relativeCapacity|), where an encodi= ng=20 > with twice the |relativeCapacity|=C2=A0of another encoding will be give= n=20 > twice the transmission capacity. If implementations can handle ratios=20 > of 1:2:4:8, I don't see any reason why they shouldn't be able to=20 > handle arbitrary ratios. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------16F198C876779C90941B20D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Taylor,

I think the text you quoted is directly related to your transmission queuing. And as no one was willing to write up a specific queuing algorithm that would be more flexible, the discussion in the WG at the time this was written ended up in a per prioritization level round robin queue basically, where each lower priority is given one transmission slot in the upper queue. Thus giving roughly halving, but it could be less actually depending on how many processes are part of a particular level.

I also think you scheme for relative capacity is likely good, but appear to be missing two important parameters. One for minimal bit-rate, and one for maximum. At least for audio sources, there is a limit to scaling these both upwards and downwards. The upper limit when reached should be redistributed, or otherwise it might be wasted. The minimal is an interesting one. Because one have to decided if this means taking more from the lower prioritise and how they relate to other. The classical example of one audio plus one video comes to mind, where one would like to maintain the audio in user interactive applications despite taking more from the video. To the point where one have to turn off video to maintain audio.

So, I think you have to work on the proposal a bit more.

Cheers

Magnus


Den 2017-10-11 kl. 19:29, skrev Taylor= Brandstetter:

(Mainly copied from https://github.com/w3c/webrtc-pc/iss= ues/1625)

When defining priority, rtcweb-transports says:

The WebRTC prioritization model is that the application tells the
WebRTC endpoint about the priority of media and data that is<= br style=3D"box-sizing:border-box"> controlled from the API.
...
The priority settings affect two pieces of behavior: Packet send
sequence decisions and packet markings. Each is described in its own
section below.

The sections below are "Local prioritization" and "Usage of Quality of Service - DSCP and Multiplexing". The "local prioritization" section gives this guidance:

When an WebRTC endpoint has packets to send on multiple streams that
are congestion-controlled under the same congestion control regime,
the WebRTC endpoint SHOULD cause data to be emitted in such a way
that=C2=A0each stream at each level of priority is being given
approximately twice the transmission capacity (measured in payload
bytes) of the level below.

Thus, when congestion occurs, a "high" priority flow will have the<= br style=3D"box-sizing:border-box"> ability to send 8 times as much data as a "very-low" priority flow if
both have data to send. This prioritization is independent of the
media type. The details of which packet to send first are
implementation defined.

For example: If there is a high priority audio flow sending 100 byte
packets, and a low priority video flow sending 1000 byte packets, and
outgoing capacity exists for sending >5000 payload bytes, it would be
appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes
(one packet) of video as the result of a single pass of sending
decisions.

This has two significant issues I can see:

  • It only allows ratios of 1:2:4:8. This is not granular enough to be very useful. Especially when balancing transmission capacity between audio tracks and video tracks; in practice it's common for video tracks to use much more than 8 times the bitrate of audio tracks.
  • A single enum is used for both relative bitrate and relative QoS priority. But in my experience it's common for an application to want a flow that uses=C2=A0less=C2=A0bitrate to h= ave a=C2=A0higher=C2=A0QoS priori= ty. This may even be the=C2=A0more=C2=A0common situation.

So, why do we have one enum for both things? I'd propose defining the priority as something that only impacts the priority in network queues (QoS-level priority and SCTP priority, as previously discussed), and use something else to control the relative bitrate allocation.

For example, a floating point value attached to each=C2=A0RTCEncodingParameters=C2=A0(say,=C2=A0relativeCapacity), where an encoding with twice the=C2=A0relativeCapacity=C2=A0of another encoding will be given twice the transmission capacity. If implementations can handle ratios of 1:2:4:8, I don't see any reason why they shouldn't be able to handle arbitrary ratios.



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


--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------16F198C876779C90941B20D9--

--------------ms060904070909010601080507
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzEwMTYxMjEwMDNaMC8GCSqGSIb3DQEJBDEiBCByD9Xck6SPX2qP8sFm
82IzTHzago+0pRBIR370ouzX4TBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAeYusfc5ETOFhmFqUUnlz5N8wrlMqCF0BK5HzYQZ15M1lD12l
2dHqylNFew9GmVmnF01C2v+2G6/uIiMNiGey6OEqXAjLA+Ok1PDZVRL/INfDWhBqPuass77h
1EeTGgcP0N4gwAC152srczegSb2kB3Nl97XtvJXGmJNpTZ+cBce/jbhguJ/qKDoY7X0+6Vl+
22EjaLyG2VfsutsdUFTIZvZ04A/32sWp0mIv+njCxpxoyuuW5ynaXej8ZqS4nwH+xDs5leMP
SK++CKGuNqJpCyWnXWVHrrEAnePQoz+1elOllCiW/Zl+ptlVwWFfEWkEaYDxilF6gdTdxWEQ
e2aHGgAAAAAAAA==
--------------ms060904070909010601080507--


From nobody Mon Oct 16 11:29:14 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD7134534 for ; Mon, 16 Oct 2017 11:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbfyrGIAXHqB for ; Mon, 16 Oct 2017 11:29:02 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 CFAAA134532 for ; Mon, 16 Oct 2017 11:29:01 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id b11so10346633uae.12 for ; Mon, 16 Oct 2017 11:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wW5ioRhJnovNxwSNi29waDck2luhlYW4cRRx+ZgNTbE=; b=MZXf+1/TmWyIxfKMIxI3yI/hYMaIrtSJrU/DDCIyb7F0QF+JRF+sREGNTjAG+emIoW Q7J3iMYrI7wj9vVCu9SlzrOXz+yyjOa8myijvVL515rFOoMGCVHVRACxem5yTAy0vA8d KUad7J56NlRMlbRfq8pZkD4fyvZRpAN0L0CINyDYussM8ORI0Rnsv5JMfB0nMzjR0f1s p3Fpkgm/DezbxHaM5qKBASpDP3HtahXEvQTB3WqLOArUL+iLyV1QVFFLJA+zXzThxV20 JagADeJE8gotQE06cN3tMRtlpi9GTuPYlezx45NF3Vu+QVk6Zf1edjGEawYoPlbENFuN ObcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wW5ioRhJnovNxwSNi29waDck2luhlYW4cRRx+ZgNTbE=; b=kYQxpBW0OYP6nlirWRv8SNGXFruXL4fUM9MmFCK3IusyedrT5azG3yCS8pQMRFcFwJ NCcDnnniE/uxEOh28ixZpvWtX8WWcifsAcRgaM46U+d/6Rr1G32V24erXv+nnhW7Ibwz HKXOCcpPoIfd1i4ar0DviMr9TmvnE8Oef+ZUPtCbSG6UAG7ow3Rvwp5wULjYmgQG58T9 JzPYxVLN5eDCwXwwQXzHkXnSc4hnyhvhSkP6f01diOp20BzpISKV04xI4PX6taPj3e7n v/Am3s3iXIVuEKkQ8miKToJcyoB2PSw3eJlZEMr2pgdrYLdieAOc/tL5XO1T1wzmnqly g2tA==
X-Gm-Message-State: AMCzsaWWZFXdBcb9s9uvYHYyKSPx6hlYT6ow79Vjkc3LH4zJGp2VfDFC ouKZTQ78O+c9G9E5wurECANQVZa0pxJYKry7cnaPOw==
X-Google-Smtp-Source: ABhQp+QeR35BoNes2Z+hLMFiBZIWGsrPZiIqTZH5rCDeEpxfnek84CdMGFxMc5cy4nO6oBJ234dEX/z8GbMAXSaErII=
X-Received: by 10.176.87.89 with SMTP id t25mr8028990uac.76.1508178540666; Mon, 16 Oct 2017 11:29:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.169.130 with HTTP; Mon, 16 Oct 2017 11:28:59 -0700 (PDT)
In-Reply-To: <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>
From: Taylor Brandstetter 
Date: Mon, 16 Oct 2017 11:28:59 -0700
Message-ID: 
To: Magnus Westerlund 
Cc: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="f403045e61902d2979055bae2eb5"
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 16 Oct 2017 18:29:13 -0000

--f403045e61902d2979055bae2eb5
Content-Type: text/plain; charset="UTF-8"

This is something that came up in the WebRTC virtual interim as well (but
for the simulcast use case, rather than audio vs. video). When bandwidth is
constrained, you don't necessarily want to send multiple simulcast layers,
each with a low bitrate. You want to start by sending only the lowest
quality encoding, until you have enough bits to send the next encoding, etc.

I think we could meet most everyone's use cases with a combination of:

   - Priority
   - Min bitrate
   - Max bitrate
   - "Relative" bitrate ratio

For example, suppose I set up simulcast layers like so:

encodings = [
{
  rid: "f",
  priority: "low",
  minBitrate:  600000,
  maxBitrate: 2500000,
  relativeBitrate: 4.0
},
{
  rid: "h",
  priority: "medium",
  scaleResolutionDownBy: 2.0,
  minBitrate: 150000,
  maxBitrate: 700000,
  relativeBitrate: 2.0
},
{
  rid: "q",
  priority: "high",
  scaleResolutionDownBy: 4.0,
  maxBitrate: 200000,
  relativeBitrate: 1.0
}
]

The algorithm would be "if you can't meet the minimums of every encoding,
prioritize the higher priority encodings." So if only 100kbps is available,
only the "q" (quarter-resolution) encoding would be used. If the available
bandwidth reaches, say, 300kbps, then it would be split between "h" and
"q", with a split of 200kbps/100kbps. And so on.

I believe this is pretty similar to how our hard-coded implementation
already works (I took some of these values directly from the code).


On Mon, Oct 16, 2017 at 5:10 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Hi Taylor,
>
> I think the text you quoted is directly related to your transmission
> queuing. And as no one was willing to write up a specific queuing algorithm
> that would be more flexible, the discussion in the WG at the time this was
> written ended up in a per prioritization level round robin queue basically,
> where each lower priority is given one transmission slot in the upper
> queue. Thus giving roughly halving, but it could be less actually depending
> on how many processes are part of a particular level.
>
> I also think you scheme for relative capacity is likely good, but appear
> to be missing two important parameters. One for minimal bit-rate, and one
> for maximum. At least for audio sources, there is a limit to scaling these
> both upwards and downwards. The upper limit when reached should be
> redistributed, or otherwise it might be wasted. The minimal is an
> interesting one. Because one have to decided if this means taking more from
> the lower prioritise and how they relate to other. The classical example of
> one audio plus one video comes to mind, where one would like to maintain
> the audio in user interactive applications despite taking more from the
> video. To the point where one have to turn off video to maintain audio.
>
> So, I think you have to work on the proposal a bit more.
>
> Cheers
>
> Magnus
>
> Den 2017-10-11 kl. 19:29, skrev Taylor Brandstetter:
>
> (Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625)
>
> When defining priority, rtcweb-transports says:
>
> The WebRTC prioritization model is that the application tells the
> WebRTC endpoint about the priority of media and data that is
> controlled from the API.
> ...
> The priority settings affect two pieces of behavior: Packet send
> sequence decisions and packet markings. Each is described in its own
> section below.
>
> The sections below are "Local prioritization" and "Usage of Quality of
> Service - DSCP and Multiplexing". The "local prioritization" section gives
> this guidance:
>
> When an WebRTC endpoint has packets to send on multiple streams that
> are congestion-controlled under the same congestion control regime,
> the WebRTC endpoint SHOULD cause data to be emitted in such a way
> that each stream at each level of priority is being given
> approximately twice the transmission capacity (measured in payload
> bytes) of the level below.
>
> Thus, when congestion occurs, a "high" priority flow will have the
> ability to send 8 times as much data as a "very-low" priority flow if
> both have data to send. This prioritization is independent of the
> media type. The details of which packet to send first are
> implementation defined.
>
> For example: If there is a high priority audio flow sending 100 byte
> packets, and a low priority video flow sending 1000 byte packets, and
> outgoing capacity exists for sending >5000 payload bytes, it would be
> appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes
> (one packet) of video as the result of a single pass of sending
> decisions.
>
> This has two significant issues I can see:
>
>    - It only allows ratios of 1:2:4:8. This is not granular enough to be
>    very useful. Especially when balancing transmission capacity between audio
>    tracks and video tracks; in practice it's common for video tracks to use
>    much more than 8 times the bitrate of audio tracks.
>    - A single enum is used for both relative bitrate and relative QoS
>    priority. But in my experience it's common for an application to want a
>    flow that uses *less* bitrate to have a *higher* QoS priority. This
>    may even be the *more* common situation.
>
> So, why do we have one enum for both things? I'd propose defining the
> priority as something that only impacts the priority in network queues
> (QoS-level priority and SCTP priority, as previously discussed), and use
> something else to control the relative bitrate allocation.
>
> For example, a floating point value attached to each RTCEncodingParameters
>  (say, relativeCapacity), where an encoding with twice the
> relativeCapacity of another encoding will be given twice the transmission
> capacity. If implementations can handle ratios of 1:2:4:8, I don't see any
> reason why they shouldn't be able to handle arbitrary ratios.
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287 <+46%2010%20714%2082%2087>Torshamnsgatan 23            | Mobile +46 73 0949079 <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>

--f403045e61902d2979055bae2eb5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This is something that came up in the WebRTC virtual inter=
im as well (but for the simulcast use case, rather than audio vs. video). W=
hen bandwidth is constrained, you don't necessarily want to send multip=
le simulcast layers, each with a low bitrate. You want to start by sending =
only the lowest quality encoding, until you have enough bits to send the ne=
xt encoding, etc.

I think we could meet most everyone=
9;s use cases with a combination of:
  • Priority
  • Min=
 bitrate
  • Max bitrate
  • "Relative" bitrate ratio
For example, suppose I set up simulcast layers like so:

encodings =3D [<=
br>
{
=C2=A0 rid: "f",=

=C2=A0 priority: "low&q=
uot;,
=C2=A0 minBitrat=
e:=C2=A0 600000,
=C2=
=A0 maxBitrate: 2500000,
=C2=A0 relativeBitrate: 4.0
},
{
=C2=A0 rid: "h",
=C2=A0 priority: "me=
dium",
=C2=A0 sca=
leResolutionDownBy: 2.0,
=C2=A0 minBitrate: 150000,
=C2=A0 maxBitrate: 700000,
=C2=A0 relativeBitrate: 2.0
},
=
{
=C2=A0 rid: "q&=
quot;,
=C2=A0 priority=
: "high",
=
=C2=A0 scaleResolutionDownBy: 4.0,
=C2=A0 maxBitrate: 200000,
=C2=A0 relativeBitrate: 1.0
}
]

The algorithm would be "=
if you can't meet the minimums of every encoding, prioritize the higher=
 priority encodings." So if only 100kbps is available, only the "=
q" (quarter-resolution) encoding would be used. If the available bandw=
idth reaches, say, 300kbps, then it would be split between "h" an=
d "q", with a split of 200kbps/100kbps. And so on.

=

I believe this is pretty similar to how our hard-coded implement=
ation already works (I took some of these values directly from the code).


On Mon, Oct 16, 2017 at 5:10 AM, Magnus Westerlund <m=
agnus.westerlund@ericsson.com> wrote:

 =20
   =20
 =20
  

    
Hi Taylor,

    
I think the text you quoted is directly related to your
      transmission queuing. And as no one was willing to write up a
      specific queuing algorithm that would be more flexible, the
      discussion in the WG at the time this was written ended up in a
      per prioritization level round robin queue basically, where each
      lower priority is given one transmission slot in the upper queue.
      Thus giving roughly halving, but it could be less actually
      depending on how many processes are part of a particular level. 

    

    
I also think you scheme for relative capacity is likely good, but
      appear to be missing two important parameters. One for minimal
      bit-rate, and one for maximum. At least for audio sources, there
      is a limit to scaling these both upwards and downwards. The upper
      limit when reached should be redistributed, or otherwise it might
      be wasted. The minimal is an interesting one. Because one have to
      decided if this means taking more from the lower prioritise and
      how they relate to other. The classical example of one audio plus
      one video comes to mind, where one would like to maintain the
      audio in user interactive applications despite taking more from
      the video. To the point where one have to turn off video to
      maintain audio. 

    

    
So, I think you have to work on the proposal a bit more. 

    

    
Cheers

    
Magnus

    

    

    
Den 2017-10-11 kl.=
 19:29, skrev Taylor
      Brandstetter:

    

    

     =20
      

        
(Mainly copied from https://github.com/w3c/webrtc-pc/issues=
/1625)

        
When defining priority,
          rtcweb-transports says:

        

          
The
            WebRTC prioritization model is that the application tells
            the

            WebRTC endpoint about the priority of media and data that is
            controlled from the API.

            ...

            The priority settings affect two pieces of behavior: Packet
            send

            sequence decisions and packet markings. Each is described in
            its own

            section below.

        

        
The sections below are "Local
          prioritization" and "Usage of Quality of Service - DSCP=
 and
          Multiplexing". The "local prioritization" section =
gives this
          guidance:

        

          
When
            an WebRTC endpoint has packets to send on multiple streams
            that

            are congestion-controlled under the same congestion control
            regime,

            the WebRTC endpoint SHOULD cause data to be emitted in such
            a way

            that=C2=A0each
              stream at each level of priority is being given

              approximately twice the transmission capacity (measured in
              payload

              bytes) of the level below.

          
Thus,
            when congestion occurs, a "high" priority flow will h=
ave the

            ability to send 8 times as much data as a "very-low"
            priority flow if

            both have data to send. This prioritization is independent
            of the

            media type. The details of which packet to send first are

            implementation defined.

          
For
            example: If there is a high priority audio flow sending 100
            byte

            packets, and a low priority video flow sending 1000 byte
            packets, and

            outgoing capacity exists for sending >5000 payload bytes,
            it would be

            appropriate to send 4000 bytes (40 packets) of audio and
            1000 bytes

            (one packet) of video as the result of a single pass of
            sending

            decisions.

        

        
This has two significant issues I
          can see:

        
    
          
  • It only
            allows ratios of 1:2:4:8. This is not granular enough to be
            very useful. Especially when balancing transmission capacity
            between audio tracks and video tracks; in practice it's
            common for video tracks to use much more than 8 times the
            bitrate of audio tracks.
    • 
          
  • A
            single enum is used for both relative bitrate and relative
            QoS priority. But in my experience it's common for an
            application to want a flow that uses=C2=A0less=C2=A0bitrate to have a=C2=A0higher=C2=A0QoS priority.
            This may even be the=C2=A0m=
ore=C2=A0common
            situation.
    • 
        

        
So, why do we have one enum for
          both things? I'd propose defining the priority as something
          that only impacts the priority in network queues (QoS-level
          priority and SCTP priority, as previously discussed), and use
          something else to control the relative bitrate allocation.

        
For example, a
          floating point value attached to each=C2=A0RTCEncodingParam=
eters=C2=A0(say,=C2=A0relativeCapacity),
          where an encoding with twice the=C2=A0relativeCapacity=C2=A0of
          another encoding will be given twice the transmission
          capacity. If implementations can handle ratios of 1:2:4:8, I
          don't see any reason why they shouldn't be able to handle
          arbitrary ratios.

      

      

      

      

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


    

    

    
--=20

Magnus Westerlund=20

-----------------------------------------------------------------=
-----
Media Technologies, Ericsson Research
-----------------------------------------------------------------=
-----
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 094=
9079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------=
-----

  






--f403045e61902d2979055bae2eb5--


From nobody Mon Oct 16 16:13:03 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57152132403 for ; Mon, 16 Oct 2017 16:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43LnaUxZxAjV for ; Mon, 16 Oct 2017 16:12:59 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0601270AE for ; Mon, 16 Oct 2017 16:12:59 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id 126so8722236vkj.9 for ; Mon, 16 Oct 2017 16:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aE6wDrJ95ftWm3mO0YusLpD6zNGvWmJ335Vibz+UcIs=; b=QfLU4DqZk3FOgc26VyPfWOFQm9ob6PwULwf0i0cvNcOj9t2UNzsSvedGln4YGI7I12 T95fZeo485D3k7K00yqVzTk54uPChh4e2Xi1lTvlDgkEM30xFbp3fMa4AhFtDiLh5AQ+ 084PYtR4bpS4irq8BbJvYlWMTvDH4E2fMwO+XsNtztchLhHhGupqOrOB+kMm/xpHpsXr X2rK/smcTLCYje0Ei/SdRHtE9ITM2utdkQ94mleGxQmjD0lD/pKYKVFYQW+BdPF+Xcgh BvnBWv4QXO34q47cLxLGSIDvauiqSBrBWIqHzJEI5PZd6WBQ1iIo3mKMSy8oR4TbmJ94 o2gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aE6wDrJ95ftWm3mO0YusLpD6zNGvWmJ335Vibz+UcIs=; b=dB6bdEQzYQOR3Qub6hdhQgg4HtzjtpjrUFdMlB7/7DDBqwb3HZf8nK8Umr+V2KoAph 5B/JRfZV5JY+B6x8Z97jcCqwSAPCZDH4d9YH7/ca6eK/EOD0zG5PI3bqroo4cGw7FVXR Ub2EZwSqqDZxIw+VYWVkMA3Zsyamjh7TfWdAniuIfsvRUrxLd966CSx7VScqnko+gHN2 vRZWY0T/KWANxdNtuR6EQux3VJpUR+4isOifeyUdCe19IBBF85qxuOtzxn4Q8j2Tnf07 /4i110M9EgihaRHrtTpyTIRvkm5hRQfsgvZ7fgCjShSOcNQ2cknfil9hQA9lR1OLGvt2 aOlQ==
X-Gm-Message-State: AMCzsaVLAGHbN2yHmDAmkkW6u/n8SYjLuUfuPeQthjcGMYAqKwCR8TPV CrOL+zAJ6y6J7Exb5OPpDqXlOYiuTzGupA+VbKpQnh+m
X-Google-Smtp-Source: ABhQp+T3UXO1nQ5Kz0GIZyFjXKogP0HamaVgX7nVfyQr/U/llAJQqqxIWDREz+OOL/eZcXBhcQW5mUOWZAQpQ3z91Z8=
X-Received: by 10.31.74.134 with SMTP id x128mr1692001vka.14.1508195578411; Mon, 16 Oct 2017 16:12:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.169.130 with HTTP; Mon, 16 Oct 2017 16:12:57 -0700 (PDT)
From: Taylor Brandstetter 
Date: Mon, 16 Oct 2017 16:12:57 -0700
Message-ID: 
To: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a114dacdcb4b94d055bb22576"
Archived-At: 
Subject: [rtcweb] Processing multiple remote offers
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 16 Oct 2017 23:13:01 -0000

--001a114dacdcb4b94d055bb22576
Content-Type: text/plain; charset="UTF-8"

JSEP allows a remote offer to be applied while in the "have-remote-offer"
state. Meaning that, in addition to supporting multiple answers (via
pr-answers), JSEP also supports multiple offers.

However, I don't see any text that calls out what (if anything) must be the
same between these offers. Should we assume that they can be
*completely* different?
Or do they at least need to contain the same m= sections (same type, MID
and order)? For example: is it legal to apply an audio-only remote offer,
then apply a video-only remote offer? Is it legal to apply an audio-only
offer, then an audio+video offer?

This affects WebRTC 1.0, because depending on which direction this goes, we
may need to address a situation where an RTCRtpTransceiver is created by
applying a remote offer, then invalidated by the next remote offer. Does it
go away or exist in limbo state?

Of course, another solution would be to say "this isn't supported, do a
rollback if you need this."

--001a114dacdcb4b94d055bb22576
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


JSEP allows a remote offer to be applied while in the &quo=
t;have-remote-offer" state. Meaning that, in addition to supporting mu=
ltiple answers (via pr-answers), JSEP also supports multiple offers.
However, I don't see any text that calls out what (if anyt=
hing) must be the same between these offers. Should we assume that they can=
 be completely=C2=A0different? Or do they at least need to contain t=
he same m=3D sections (same type, MID and order)? For example: is it legal =
to apply an audio-only remote offer, then apply a video-only remote offer? =
Is it legal to apply an audio-only offer, then an audio+video offer?
<=
div>
This affects WebRTC 1.0, because depending on which dire=
ction this goes, we may need to address a situation where an RTCRtpTranscei=
ver is created by applying a remote offer, then invalidated by the next rem=
ote offer. Does it go away or exist in limbo state?

Of course, another solution would be to say "this isn't supporte=
d, do a rollback if you need this."


--001a114dacdcb4b94d055bb22576--


From nobody Tue Oct 17 07:36:30 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76956132D54; Tue, 17 Oct 2017 07:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 narFCoWZ8FxV; Tue, 17 Oct 2017 07:36:20 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74BA132F3F; Tue, 17 Oct 2017 07:36:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4D15B7C32DB; Tue, 17 Oct 2017 16:36:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljrEFhhFiV7n; Tue, 17 Oct 2017 16:36:16 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0004B7C0AF4; Tue, 17 Oct 2017 16:36:15 +0200 (CEST)
To: Christer Holmberg , "ice@ietf.org" 
Cc: "rtcweb@ietf.org" 
References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no> 
From: Harald Alvestrand 
Message-ID: 
Date: Tue, 17 Oct 2017 16:36:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 14:36:22 -0000

Den 16. okt. 2017 12:02, skrev Christer Holmberg:
> Hi Harald,
> 
> Some feedback on your comments.
> 
>> Most important points:
>>
>> * The protocol has been designed and revised to be usable with non-media
>> data, but the introduction and abstract do not reflect this. Expunging
>> the media bias from the body of the document is probably not worth it,
>> but the intro and abstract should mention it.
> 
> We COULD do a search/replace operation, and replace ³media² with ³data².
> We would end up with terms like ³data stream², ³data packets² etc, but I
> guess that it would be ok.
> 
> In the ³data definition² we would then describe that data includes both
> RTP and non-RTP data.

I would like that! I was proposing a smaller change because it's so late
in the cycle, but better is better!

> 
>> * Security considerations should mention the problem that ICE reveals
>> addresses that might otherwise remain hidden, and that this is a privacy
>> concern.
> 
> I would be glad if someone could provide text for that, to make sure we
> get it right.

The paragraph I suggested in the PDF was:

“The process of probing for candidates reveals the source addresses of
the client and its peer to any on-network listening attacker, and the
process of exchanging candidates reveals the addresses to any attacker
that is able to see the negotiation. Some addresses, such as the server
reflexive addresses gathered through the local interface of VPN users,
may be sensitive information. If these potential attacks can’t be
mitigated, the implementation may want to institute controls for which
addresses are revealed to the negotiation and/or probing process. Such
controls need to be specified as part of the ICE usage.”

Of course, that's only my suggestion.

> 
>> * The document has removed all the SDP specific parts (good), but the
>> requirements it places on the negotiation mechanism aren¹t collectively
>> documented anywhere. A section describing this would help comprehension
>> for people developing signalling protocols for use with ICE.
> 
> I can think of the following requirements:
> 
> REQ: There MUST be a mechanism for ICE agents to determine whether the
> remote peer supports ICE
> 
> 
> REQ: There MUST be a mechanism for ICE agents to exchange candidate
> information
> 
> REQ: There MUST be a mechanism for ICE agents to indicate an ICE restart
> to the remote peer

I was thinking of something like:

The exchange of information MUST result in the following information
being available to the ICE agent:

- Whether the remote peer supports ICE at all
- What ICE options, if any, are supported
- Whether the remote peer is Lite or Full
- Whether the remote peer thinks it's the Initiating Agent or not
- What candidates the remote peer wishes to make available
- Whether an ICE restart is desired

> 
> 
>> * The definition of ³component² talks about a component having one
>> address. I believe that in current usage, it should be defined to have
>> an address pair. (non-symmetric RTP is dead).
> 
> Or, should we say ³having one candidate pair²?
> 
>  A component is a piece of a data stream
> requiring a candidate pair; a data stream may require
> multiple components, each of which has to work for the data stream as
> a whole to work.  For media streams based on RTP, unless RTP and RTCP
> are multiplexed in the same port, there are two components per media
> stream -- one for RTP, and one for RTCP.

This works for me!

> 
> 
> Regarding non-symmetric RTP, the spec says that the selected candidate
> pair MUST be used for sending and receiving media, so I guess that means
> symmetric RTP. Perhaps it would be good to point that out.

Can't harm.

> 
> Regards,
> 
> Christer
> 


From nobody Tue Oct 17 07:45:51 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81F5134212 for ; Tue, 17 Oct 2017 07:45:50 -0700 (PDT)
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 autolearn_force=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 mR36SKrYMy12 for ; Tue, 17 Oct 2017 07:45:48 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCD2132F30 for ; Tue, 17 Oct 2017 07:45:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 686B37C32DB; Tue, 17 Oct 2017 16:45:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EMz6YXZWQuj; Tue, 17 Oct 2017 16:45:45 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id EB51D7C0AF4; Tue, 17 Oct 2017 16:45:44 +0200 (CEST)
To: Taylor Brandstetter , Magnus Westerlund 
Cc: RTCWeb IETF 
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com> 
From: Harald Alvestrand 
Message-ID: <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no>
Date: Tue, 17 Oct 2017 16:45:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 14:45:51 -0000

Den 16. okt. 2017 20:28, skrev Taylor Brandstetter:
> This is something that came up in the WebRTC virtual interim as well
> (but for the simulcast use case, rather than audio vs. video). When
> bandwidth is constrained, you don't necessarily want to send multiple
> simulcast layers, each with a low bitrate. You want to start by sending
> only the lowest quality encoding, until you have enough bits to send the
> next encoding, etc.
> 
> I think we could meet most everyone's use cases with a combination of:
> 
>   * Priority
>   * Min bitrate
>   * Max bitrate
>   * "Relative" bitrate ratio

My thinking is that this grows very complex.

I don't think we have much chance of getting this right for all use
cases. For instance, screenshare-type video varies enormously in
bandwidth (very low at static images, enormous at slide change) - if it
competes against audio, a "relative" bitrate ratio will not be useful at
all.

> 
> For example, suppose I set up simulcast layers like so:
> 
> encodings = [
> {
>   rid: "f",
>   priority: "low",
>   minBitrate:  600000,
>   maxBitrate: 2500000,
>   relativeBitrate: 4.0
> },
> {
>   rid: "h",
>   priority: "medium",
>   scaleResolutionDownBy: 2.0,
>   minBitrate: 150000,
>   maxBitrate: 700000,
>   relativeBitrate: 2.0
> },
> {
>   rid: "q",
>   priority: "high",
>   scaleResolutionDownBy: 4.0,
>   maxBitrate: 200000,
>   relativeBitrate: 1.0
> }
> ]
> 
> The algorithm would be "if you can't meet the minimums of every
> encoding, prioritize the higher priority encodings." So if only 100kbps
> is available, only the "q" (quarter-resolution) encoding would be used.
> If the available bandwidth reaches, say, 300kbps, then it would be split
> between "h" and "q", with a split of 200kbps/100kbps. And so on.
> 
> I believe this is pretty similar to how our hard-coded implementation
> already works (I took some of these values directly from the code
I worry about the complexity of getting this specified. Having code
helps, of course.

I like extension specs. Especially for trying out things where our
solutions may be perfect for some scenarios, but might not work in other
scenarios, and the base specs attempt to cover all cases.

Is there a way we can punt this?

> 
> 
> On Mon, Oct 16, 2017 at 5:10 AM, Magnus Westerlund
> >
> wrote:
> 
>     Hi Taylor,
> 
>     I think the text you quoted is directly related to your transmission
>     queuing. And as no one was willing to write up a specific queuing
>     algorithm that would be more flexible, the discussion in the WG at
>     the time this was written ended up in a per prioritization level
>     round robin queue basically, where each lower priority is given one
>     transmission slot in the upper queue. Thus giving roughly halving,
>     but it could be less actually depending on how many processes are
>     part of a particular level.
> 
>     I also think you scheme for relative capacity is likely good, but
>     appear to be missing two important parameters. One for minimal
>     bit-rate, and one for maximum. At least for audio sources, there is
>     a limit to scaling these both upwards and downwards. The upper limit
>     when reached should be redistributed, or otherwise it might be
>     wasted. The minimal is an interesting one. Because one have to
>     decided if this means taking more from the lower prioritise and how
>     they relate to other. The classical example of one audio plus one
>     video comes to mind, where one would like to maintain the audio in
>     user interactive applications despite taking more from the video. To
>     the point where one have to turn off video to maintain audio.
> 
>     So, I think you have to work on the proposal a bit more.
> 
>     Cheers
> 
>     Magnus
> 
> 
>     Den 2017-10-11 kl. 19:29, skrev Taylor Brandstetter:
>>
>>     (Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625
>>     )
>>
>>     When defining priority, rtcweb-transports says:
>>
>>         The WebRTC prioritization model is that the application tells the
>>         WebRTC endpoint about the priority of media and data that is
>>         controlled from the API.
>>         ...
>>         The priority settings affect two pieces of behavior: Packet send
>>         sequence decisions and packet markings. Each is described in
>>         its own
>>         section below.
>>
>>     The sections below are "Local prioritization" and "Usage of
>>     Quality of Service - DSCP and Multiplexing". The "local
>>     prioritization" section gives this guidance:
>>
>>         When an WebRTC endpoint has packets to send on multiple
>>         streams that
>>         are congestion-controlled under the same congestion control
>>         regime,
>>         the WebRTC endpoint SHOULD cause data to be emitted in such a way
>>         that each stream at each level of priority is being given
>>         approximately twice the transmission capacity (measured in payload
>>         bytes) of the level below.
>>
>>         Thus, when congestion occurs, a "high" priority flow will have the
>>         ability to send 8 times as much data as a "very-low" priority
>>         flow if
>>         both have data to send. This prioritization is independent of the
>>         media type. The details of which packet to send first are
>>         implementation defined.
>>
>>         For example: If there is a high priority audio flow sending
>>         100 byte
>>         packets, and a low priority video flow sending 1000 byte
>>         packets, and
>>         outgoing capacity exists for sending >5000 payload bytes, it
>>         would be
>>         appropriate to send 4000 bytes (40 packets) of audio and 1000
>>         bytes
>>         (one packet) of video as the result of a single pass of sending
>>         decisions.
>>
>>     This has two significant issues I can see:
>>
>>       * It only allows ratios of 1:2:4:8. This is not granular enough
>>         to be very useful. Especially when balancing transmission
>>         capacity between audio tracks and video tracks; in practice
>>         it's common for video tracks to use much more than 8 times the
>>         bitrate of audio tracks.
>>       * A single enum is used for both relative bitrate and relative
>>         QoS priority. But in my experience it's common for an
>>         application to want a flow that uses /less/ bitrate to have
>>         a /higher/ QoS priority. This may even be the /more/ common
>>         situation.
>>
>>     So, why do we have one enum for both things? I'd propose defining
>>     the priority as something that only impacts the priority in
>>     network queues (QoS-level priority and SCTP priority, as
>>     previously discussed), and use something else to control the
>>     relative bitrate allocation.
>>
>>     For example, a floating point value attached to
>>     each |RTCEncodingParameters| (say, |relativeCapacity|), where an
>>     encoding with twice the |relativeCapacity| of another encoding
>>     will be given twice the transmission capacity. If implementations
>>     can handle ratios of 1:2:4:8, I don't see any reason why they
>>     shouldn't be able to handle arbitrary ratios.
>>
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     rtcweb@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>     
> 
>     -- 
> 
>     Magnus Westerlund 
> 
>     ----------------------------------------------------------------------
>     Media Technologies, Ericsson Research
>     ----------------------------------------------------------------------
>     Ericsson AB                 | Phone  +46 10 7148287 
>     Torshamnsgatan 23
>                | Mobile +46 73 0949079 
>     SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com 
>     ----------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


From nobody Tue Oct 17 07:50:57 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4B0134212 for ; Tue, 17 Oct 2017 07:50:55 -0700 (PDT)
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 autolearn_force=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 8B8ZDsZ5we9m for ; Tue, 17 Oct 2017 07:50:53 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96500134211 for ; Tue, 17 Oct 2017 07:50:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2A9707C32DB; Tue, 17 Oct 2017 16:50:52 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdd9inn0rIaH; Tue, 17 Oct 2017 16:50:51 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4BE207C0AF4; Tue, 17 Oct 2017 16:50:51 +0200 (CEST)
To: Taylor Brandstetter , RTCWeb IETF 
References: 
From: Harald Alvestrand 
Message-ID: <624deabb-0fa2-4ae2-4661-f71b3ee322ae@alvestrand.no>
Date: Tue, 17 Oct 2017 16:50:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [rtcweb] Processing multiple remote offers
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 14:50:55 -0000

Den 17. okt. 2017 01:12, skrev Taylor Brandstetter:
> JSEP allows a remote offer to be applied while in the
> "have-remote-offer" state. Meaning that, in addition to supporting
> multiple answers (via pr-answers), JSEP also supports multiple offers.
> 
> However, I don't see any text that calls out what (if anything) must be
> the same between these offers. Should we assume that they can be
> /completely/ different? Or do they at least need to contain the same m=
> sections (same type, MID and order)? For example: is it legal to apply
> an audio-only remote offer, then apply a video-only remote offer? Is it
> legal to apply an audio-only offer, then an audio+video offer?

Offhand, I can't think of a scenario where multiple offers in have-offer
state is useful. Most of these convolutions were justified by 3PCC
cases, which I don't understand fully.

A contrived one is where the remote party sends an audio-only offer,
adds a video track, and then wishes to re-offer with both audio and
video before the answerer picks up. This only makes sense if the
answerer is waiting for the human response before sending the answer.

> This affects WebRTC 1.0, because depending on which direction this goes,
> we may need to address a situation where an RTCRtpTransceiver is created
> by applying a remote offer, then invalidated by the next remote offer.
> Does it go away or exist in limbo state?
> 
> Of course, another solution would be to say "this isn't supported, do a
> rollback if you need this."

Or we could specify the effect of applying a new remote offer as being
identical to rollback + apply the new offer. Is that the simplest spec
change we can make?


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


From nobody Tue Oct 17 09:59:56 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776E1133020 for ; Tue, 17 Oct 2017 09:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu9HVcNcNUjS for ; Tue, 17 Oct 2017 09:59:51 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 023F313207A for ; Tue, 17 Oct 2017 09:59:50 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id q13so1565774vkb.2 for ; Tue, 17 Oct 2017 09:59:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BDftxJr18T45x9FR1ZrbeW7Ww71QvH0x7FwaR0FcTCk=; b=HkspdwrEECZi1ZuxyRrEqnLD+XkmhKXP+qZ80fj5p0YTFsn8XX5atrecqc9X9fm0lr 7Cy1cmjPAZTJRGT29cj5piTDJ5ZtHoxjv201lD3hgB69un2hpY+aDnULW6qlYGImPLyU fqx6Cyshu4uXMe29NFHhrKWLPFSBzwT+XBTzP+UBwNWmY+w4m2tgGyrgDe7BGcpDq4+S SNmQ7fUYY8rpciSCVnJbaPGX7wmaGed0uXMaDxp2fgFEx5u7bIeYVd4Cgak4g/HShvwm Y/3b2ZX2Ff7tQVyjp/SwwzRGefVv4WH/qvelIZHF2igOvUF2u8rLFCQzUgnv1iZd6k3U FOdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BDftxJr18T45x9FR1ZrbeW7Ww71QvH0x7FwaR0FcTCk=; b=J01iapOpK3zbY0d9BBh3653ztabw0mP2V0yIYYCYoSCJ/M1RVs2BwXM9/sr0+05Dwf YUlR/ws/b1zzmvm/1FBd5HR9l4+TbyTL63Fk54o/nAL1Ye/h8nHO+jKZv18v3JiT5RGY /Lkql8hi+2oeR5dL1XjlxC5IlNrxDwWktqj+mKn6rI43IPJeqozurVm1BNanfvG8D/xN lswrAKx03EYZUMpfYmqAHyCJDzgcWJQSjGheHUedduYFQA4TidN81S8fLzcBsBg0OJe3 /6VPknNnb/bfA3Tb4bQ7VQetMY+F+PLfMKmbzD0kUeRCUyeoL5rcwHjkLfm+xWIv9O5m 62wg==
X-Gm-Message-State: AMCzsaUrdA4QArXhAxJRlchlXUpMZv0Leycr5jVNpdALQ8ZR2vl+me1X Co1LTiHEdVDI0P7sLHKaK1BCHmZ5jbJWLaYDDrvrTQ==
X-Google-Smtp-Source: ABhQp+Q312Wr7u3XakFoqX5mPFKMlubCyAm7zXzU08+884dFfxxwyMM2ZDcFptiw2J1eRGPYWC+4CpWTcBSXYkcWeY8=
X-Received: by 10.31.16.35 with SMTP id g35mr3663722vki.131.1508259589658; Tue, 17 Oct 2017 09:59:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.169.130 with HTTP; Tue, 17 Oct 2017 09:59:48 -0700 (PDT)
In-Reply-To: <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no>
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>  <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no>
From: Taylor Brandstetter 
Date: Tue, 17 Oct 2017 09:59:48 -0700
Message-ID: 
To: Harald Alvestrand 
Cc: Magnus Westerlund , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a1143195e129c49055bc10df8"
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 16:59:54 -0000

--001a1143195e129c49055bc10df8
Content-Type: text/plain; charset="UTF-8"

>
> For instance, screenshare-type video varies enormously in
> bandwidth (very low at static images, enormous at slide change) - if it
> competes against audio, a "relative" bitrate ratio will not be useful at
> all.


I think that's where it's important to get the terminology right; for
example, rtcweb-transports uses the term "capacity", which implies that
it's possible to use fewer bits than the capacity. Maybe that's the best
way to think of this. We also can allow some implementation flexibility.

Is there a way we can punt this?


If we do punt this, I still think we should remove the part of
rtcweb-transports that talks about the priority causing codecs to be
configured with send rates at these 1:2:4:8 ratios:

   o  When the available bandwidth is known from the congestion control
>       algorithm, configure each codec and each data channel with a
>       target send rate that is appropriate to its share of the available
>       bandwidth.


We should make it clear that the priority only affects the delivery of
packets (pacing decisions, QoS, SCTP priority), and not how the packets are
generated upstream. Assuming others agree.


On Tue, Oct 17, 2017 at 7:45 AM, Harald Alvestrand 
wrote:

> Den 16. okt. 2017 20:28, skrev Taylor Brandstetter:
> > This is something that came up in the WebRTC virtual interim as well
> > (but for the simulcast use case, rather than audio vs. video). When
> > bandwidth is constrained, you don't necessarily want to send multiple
> > simulcast layers, each with a low bitrate. You want to start by sending
> > only the lowest quality encoding, until you have enough bits to send the
> > next encoding, etc.
> >
> > I think we could meet most everyone's use cases with a combination of:
> >
> >   * Priority
> >   * Min bitrate
> >   * Max bitrate
> >   * "Relative" bitrate ratio
>
> My thinking is that this grows very complex.
>
> I don't think we have much chance of getting this right for all use
> cases. For instance, screenshare-type video varies enormously in
> bandwidth (very low at static images, enormous at slide change) - if it
> competes against audio, a "relative" bitrate ratio will not be useful at
> all.
>
> >
> > For example, suppose I set up simulcast layers like so:
> >
> > encodings = [
> > {
> >   rid: "f",
> >   priority: "low",
> >   minBitrate:  600000,
> >   maxBitrate: 2500000,
> >   relativeBitrate: 4.0
> > },
> > {
> >   rid: "h",
> >   priority: "medium",
> >   scaleResolutionDownBy: 2.0,
> >   minBitrate: 150000,
> >   maxBitrate: 700000,
> >   relativeBitrate: 2.0
> > },
> > {
> >   rid: "q",
> >   priority: "high",
> >   scaleResolutionDownBy: 4.0,
> >   maxBitrate: 200000,
> >   relativeBitrate: 1.0
> > }
> > ]
> >
> > The algorithm would be "if you can't meet the minimums of every
> > encoding, prioritize the higher priority encodings." So if only 100kbps
> > is available, only the "q" (quarter-resolution) encoding would be used.
> > If the available bandwidth reaches, say, 300kbps, then it would be split
> > between "h" and "q", with a split of 200kbps/100kbps. And so on.
> >
> > I believe this is pretty similar to how our hard-coded implementation
> > already works (I took some of these values directly from the code
> I worry about the complexity of getting this specified. Having code
> helps, of course.
>
> I like extension specs. Especially for trying out things where our
> solutions may be perfect for some scenarios, but might not work in other
> scenarios, and the base specs attempt to cover all cases.
>
> Is there a way we can punt this?
>
> >
> >
> > On Mon, Oct 16, 2017 at 5:10 AM, Magnus Westerlund
> > >
> > wrote:
> >
> >     Hi Taylor,
> >
> >     I think the text you quoted is directly related to your transmission
> >     queuing. And as no one was willing to write up a specific queuing
> >     algorithm that would be more flexible, the discussion in the WG at
> >     the time this was written ended up in a per prioritization level
> >     round robin queue basically, where each lower priority is given one
> >     transmission slot in the upper queue. Thus giving roughly halving,
> >     but it could be less actually depending on how many processes are
> >     part of a particular level.
> >
> >     I also think you scheme for relative capacity is likely good, but
> >     appear to be missing two important parameters. One for minimal
> >     bit-rate, and one for maximum. At least for audio sources, there is
> >     a limit to scaling these both upwards and downwards. The upper limit
> >     when reached should be redistributed, or otherwise it might be
> >     wasted. The minimal is an interesting one. Because one have to
> >     decided if this means taking more from the lower prioritise and how
> >     they relate to other. The classical example of one audio plus one
> >     video comes to mind, where one would like to maintain the audio in
> >     user interactive applications despite taking more from the video. To
> >     the point where one have to turn off video to maintain audio.
> >
> >     So, I think you have to work on the proposal a bit more.
> >
> >     Cheers
> >
> >     Magnus
> >
> >
> >     Den 2017-10-11 kl. 19:29, skrev Taylor Brandstetter:
> >>
> >>     (Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625
> >>     )
> >>
> >>     When defining priority, rtcweb-transports says:
> >>
> >>         The WebRTC prioritization model is that the application tells
> the
> >>         WebRTC endpoint about the priority of media and data that is
> >>         controlled from the API.
> >>         ...
> >>         The priority settings affect two pieces of behavior: Packet send
> >>         sequence decisions and packet markings. Each is described in
> >>         its own
> >>         section below.
> >>
> >>     The sections below are "Local prioritization" and "Usage of
> >>     Quality of Service - DSCP and Multiplexing". The "local
> >>     prioritization" section gives this guidance:
> >>
> >>         When an WebRTC endpoint has packets to send on multiple
> >>         streams that
> >>         are congestion-controlled under the same congestion control
> >>         regime,
> >>         the WebRTC endpoint SHOULD cause data to be emitted in such a
> way
> >>         that each stream at each level of priority is being given
> >>         approximately twice the transmission capacity (measured in
> payload
> >>         bytes) of the level below.
> >>
> >>         Thus, when congestion occurs, a "high" priority flow will have
> the
> >>         ability to send 8 times as much data as a "very-low" priority
> >>         flow if
> >>         both have data to send. This prioritization is independent of
> the
> >>         media type. The details of which packet to send first are
> >>         implementation defined.
> >>
> >>         For example: If there is a high priority audio flow sending
> >>         100 byte
> >>         packets, and a low priority video flow sending 1000 byte
> >>         packets, and
> >>         outgoing capacity exists for sending >5000 payload bytes, it
> >>         would be
> >>         appropriate to send 4000 bytes (40 packets) of audio and 1000
> >>         bytes
> >>         (one packet) of video as the result of a single pass of sending
> >>         decisions.
> >>
> >>     This has two significant issues I can see:
> >>
> >>       * It only allows ratios of 1:2:4:8. This is not granular enough
> >>         to be very useful. Especially when balancing transmission
> >>         capacity between audio tracks and video tracks; in practice
> >>         it's common for video tracks to use much more than 8 times the
> >>         bitrate of audio tracks.
> >>       * A single enum is used for both relative bitrate and relative
> >>         QoS priority. But in my experience it's common for an
> >>         application to want a flow that uses /less/ bitrate to have
> >>         a /higher/ QoS priority. This may even be the /more/ common
> >>         situation.
> >>
> >>     So, why do we have one enum for both things? I'd propose defining
> >>     the priority as something that only impacts the priority in
> >>     network queues (QoS-level priority and SCTP priority, as
> >>     previously discussed), and use something else to control the
> >>     relative bitrate allocation.
> >>
> >>     For example, a floating point value attached to
> >>     each |RTCEncodingParameters| (say, |relativeCapacity|), where an
> >>     encoding with twice the |relativeCapacity| of another encoding
> >>     will be given twice the transmission capacity. If implementations
> >>     can handle ratios of 1:2:4:8, I don't see any reason why they
> >>     shouldn't be able to handle arbitrary ratios.
> >>
> >>
> >>
> >>     _______________________________________________
> >>     rtcweb mailing list
> >>     rtcweb@ietf.org 
> >>     https://www.ietf.org/mailman/listinfo/rtcweb
> >>     
> >
> >     --
> >
> >     Magnus Westerlund
> >
> >     ------------------------------------------------------------
> ----------
> >     Media Technologies, Ericsson Research
> >     ------------------------------------------------------------
> ----------
> >     Ericsson AB                 | Phone  +46 10 7148287
> 
> >     Torshamnsgatan 23
> >     
>          | Mobile +46 73 0949079 
> >     SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> 
> >     ------------------------------------------------------------
> ----------
> >
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
>

--001a1143195e129c49055bc10df8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


For instance, screenshare-type video varies enormo=
usly in
bandwidth (very low at static images, enormous at slide change) - if it<=
/span>
compe=
tes against audio, a "relative" bitrate ratio will not be useful =
at
al=
l.

I think that's where it's=
 important to get the terminology right; for example, rtcweb-transports use=
s the term "capacity", which implies that it's possible to us=
e fewer bits than the capacity. Maybe that's the best way to think of t=
his. We also can allow some implementation flexibility.

Is there a way we can punt this?

If we do punt this, I still think we should remove the part of rtcweb=
-transports that talks about the priority causing codecs to be configured w=
ith send rates at these 1:2:4:8 ratios:

=C2=A0 =C2=A0o=C2=A0 When the avail=
able bandwidth is known from the congestion control
=C2=A0 =C2=A0 =C2=A0=
 algorithm, configure each codec and each data channel with a
=C2=A0 =C2=
=A0 =C2=A0 target send rate that is appropriate to its share of the availab=
le
=C2=A0 =C2=A0 =C2=A0 bandwidth.

We should make it clear that the priority only affects the delivery of pac=
kets (pacing decisions, QoS, SCTP priority), and not how the packets are ge=
nerated upstream. Assuming others agree.


On Tue, Oct 17, 2017 at 7=
:45 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
Den 16. okt. 2017 20:28, =
skrev Taylor Brandstetter:

> This is something that came up in the WebRTC virtual interim as well
> (but for the simulcast use case, rather than audio vs. video). When
> bandwidth is constrained, you don't necessarily want to send multi=
ple

> simulcast layers, each with a low bitrate. You want to start by sendin=
g

> only the lowest quality encoding, until you have enough bits to send t=
he

> next encoding, etc.

>

> I think we could meet most everyone's use cases with a combination=
 of:

>

>=C2=A0 =C2=A0* Priority

>=C2=A0 =C2=A0* Min bitrate

>=C2=A0 =C2=A0* Max bitrate

>=C2=A0 =C2=A0* "Relative" bitrate ratio



My thinking is that this grows very complex.



I don't think we have much chance of getting this right for all use

cases. For instance, screenshare-type video varies enormously in

bandwidth (very low at static images, enormous at slide change) - if it

competes against audio, a "relative" bitrate ratio will not be us=
eful at

all.




>

> For example, suppose I set up simulcast layers like so:

>

> encodings =3D [

> {

> =C2=A0 rid: "f",

> =C2=A0 priority: "low",

> =C2=A0 minBitrate:=C2=A0 600000,

> =C2=A0 maxBitrate: 2500000,

> =C2=A0 relativeBitrate: 4.0

> },

> {

> =C2=A0 rid: "h",

> =C2=A0 priority: "medium",

> =C2=A0 scaleResolutionDownBy: 2.0,

> =C2=A0 minBitrate: 150000,

> =C2=A0 maxBitrate: 700000,

> =C2=A0 relativeBitrate: 2.0

> },

> {

> =C2=A0 rid: "q",

> =C2=A0 priority: "high",

> =C2=A0 scaleResolutionDownBy: 4.0,

> =C2=A0 maxBitrate: 200000,

> =C2=A0 relativeBitrate: 1.0

> }

> ]

>

> The algorithm would be "if you can't meet the minimums of eve=
ry

> encoding, prioritize the higher priority encodings." So if only 1=
00kbps

> is available, only the "q" (quarter-resolution) encoding wou=
ld be used.

> If the available bandwidth reaches, say, 300kbps, then it would be spl=
it

> between "h" and "q", with a split of 200kbps/100kb=
ps. And so on.

>

> I believe this is pretty similar to how our hard-coded implementation<=
br>
> already works (I took some of these values directly from the code


I worry about the complexity of getting this specified. Having =
code

helps, of course.



I like extension specs. Especially for trying out things where our

solutions may be perfect for some scenarios, but might not work in other
scenarios, and the base specs attempt to cover all cases.



Is there a way we can punt this?



>

>

> On Mon, Oct 16, 2017 at 5:10 AM, Magnus Westerlund

> <magnus.we=
sterlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>


> wrote:

>

>=C2=A0 =C2=A0 =C2=A0Hi Taylor,

>

>=C2=A0 =C2=A0 =C2=A0I think the text you quoted is directly related to =
your transmission

>=C2=A0 =C2=A0 =C2=A0queuing. And as no one was willing to write up a sp=
ecific queuing

>=C2=A0 =C2=A0 =C2=A0algorithm that would be more flexible, the discussi=
on in the WG at

>=C2=A0 =C2=A0 =C2=A0the time this was written ended up in a per priorit=
ization level

>=C2=A0 =C2=A0 =C2=A0round robin queue basically, where each lower prior=
ity is given one

>=C2=A0 =C2=A0 =C2=A0transmission slot in the upper queue. Thus giving r=
oughly halving,

>=C2=A0 =C2=A0 =C2=A0but it could be less actually depending on how many=
 processes are

>=C2=A0 =C2=A0 =C2=A0part of a particular level.

>

>=C2=A0 =C2=A0 =C2=A0I also think you scheme for relative capacity is li=
kely good, but

>=C2=A0 =C2=A0 =C2=A0appear to be missing two important parameters. One =
for minimal

>=C2=A0 =C2=A0 =C2=A0bit-rate, and one for maximum. At least for audio s=
ources, there is

>=C2=A0 =C2=A0 =C2=A0a limit to scaling these both upwards and downwards=
. The upper limit

>=C2=A0 =C2=A0 =C2=A0when reached should be redistributed, or otherwise =
it might be

>=C2=A0 =C2=A0 =C2=A0wasted. The minimal is an interesting one. Because =
one have to

>=C2=A0 =C2=A0 =C2=A0decided if this means taking more from the lower pr=
ioritise and how

>=C2=A0 =C2=A0 =C2=A0they relate to other. The classical example of one =
audio plus one

>=C2=A0 =C2=A0 =C2=A0video comes to mind, where one would like to mainta=
in the audio in

>=C2=A0 =C2=A0 =C2=A0user interactive applications despite taking more f=
rom the video. To

>=C2=A0 =C2=A0 =C2=A0the point where one have to turn off video to maint=
ain audio.

>

>=C2=A0 =C2=A0 =C2=A0So, I think you have to work on the proposal a bit =
more.

>

>=C2=A0 =C2=A0 =C2=A0Cheers

>

>=C2=A0 =C2=A0 =C2=A0Magnus

>

>

>=C2=A0 =C2=A0 =C2=A0Den 2017-10-11 kl. 19:29, skrev Taylor Brandstetter=
:

>>

>>=C2=A0 =C2=A0 =C2=A0(Mainly copied from https://=
github.com/w3c/webrtc-pc/issues/1625


>>=C2=A0 =C2=A0 =C2=A0<https://gith=
ub.com/w3c/webrtc-pc/issues/1625>)


>>

>>=C2=A0 =C2=A0 =C2=A0When defining priority, rtcweb-transports says:=


>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The WebRTC prioritization model i=
s that the application tells the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WebRTC endpoint about the priorit=
y of media and data that is

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0controlled from the API.

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The priority settings affect two =
pieces of behavior: Packet send

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sequence decisions and packet mar=
kings. Each is described in

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its own

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0section below.

>>

>>=C2=A0 =C2=A0 =C2=A0The sections below are "Local prioritizati=
on" and "Usage of

>>=C2=A0 =C2=A0 =C2=A0Quality of Service - DSCP and Multiplexing"=
;. The "local

>>=C2=A0 =C2=A0 =C2=A0prioritization" section gives this guidanc=
e:

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When an WebRTC endpoint has packe=
ts to send on multiple

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streams that

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are congestion-controlled under t=
he same congestion control

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regime,

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the WebRTC endpoint SHOULD cause =
data to be emitted in such a way

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that=C2=A0each stream at each lev=
el of priority is being given

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0approximately twice the transmiss=
ion capacity (measured in payload

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bytes) of the level below.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thus, when congestion occurs, a &=
quot;high" priority flow will have the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ability to send 8 times as much d=
ata as a "very-low" priority

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flow if

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0both have data to send. This prio=
ritization is independent of the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0media type. The details of which =
packet to send first are

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation defined.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example: If there is a high p=
riority audio flow sending

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0100 byte

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets, and a low priority video=
 flow sending 1000 byte

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets, and

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0outgoing capacity exists for send=
ing >5000 payload bytes, it

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would be

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0appropriate to send 4000 bytes (4=
0 packets) of audio and 1000

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bytes

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(one packet) of video as the resu=
lt of a single pass of sending

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decisions.

>>

>>=C2=A0 =C2=A0 =C2=A0This has two significant issues I can see:

>>


>>=C2=A0 =C2=A0 =C2=A0 =C2=A0* It only allows ratios of 1=
:2:4:8. This is not granular enough

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to be very usefu=
l. Especially when balancing transmission

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0capacity between audio tracks and=
 video tracks; in practice

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it's common for video tracks =
to use much more than 8 times the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitrate of audio tracks.

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0* A single enum is used for both =
relative bitrate and relative

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0QoS priority. Bu=
t in my experience it's common for an

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0application to want a flow=
 that uses=C2=A0/less/=C2=A0bitrate to have

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a=C2=A0/higher/=C2=A0QoS priority=
. This may even be the=C2=A0/more/=C2=A0common

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0situation.

>>

>>=C2=A0 =C2=A0 =C2=A0So, why do we have one enum for both things? I&=
#39;d propose defining

>>=C2=A0 =C2=A0 =C2=A0the priority as something that only impacts the=
 priority in

>>=C2=A0 =C2=A0 =C2=A0network queues (QoS-level priority and SCTP pri=
ority, as

>>=C2=A0 =C2=A0 =C2=A0previously discussed), and use something else t=
o control the

>>=C2=A0 =C2=A0 =C2=A0relative bitrate allocation.

>>

>>=C2=A0 =C2=A0 =C2=A0For example, a floating point value attached to=


>>=C2=A0 =C2=A0 =C2=A0each=C2=A0|RTCEncodingParameters|=C2=A0(=
say,=C2=A0|relativeCapacity|), where an

>>=C2=A0 =C2=A0 =C2=A0encoding with twice the=C2=A0|=
relativeCapacity|=C2=A0of another encoding

>>=C2=A0 =C2=A0 =C2=A0will be given twice the transmission capacity. =
If implementations

>>=C2=A0 =C2=A0 =C2=A0can handle ratios of 1:2:4:8, I don't see a=
ny reason why they

>>=C2=A0 =C2=A0 =C2=A0shouldn't be able to handle arbitrary ratio=
s.

>>

>>

>>

>>=C2=A0 =C2=A0 =C2=A0__________________________________________=
_____

>>=C2=A0 =C2=A0 =C2=A0rtcweb mailing list

>>=C2=A0 =C2=A0 =C2=A0rtcwe=
b@ietf.org <mailto:rtcweb@ietf.or=
g>

>>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman=
/listinfo/rtcweb

>>=C2=A0 =C2=A0 =C2=A0<https:/=
/www.ietf.org/mailman/listinfo/rtcweb>

>

>=C2=A0 =C2=A0 =C2=A0--

>

>=C2=A0 =C2=A0 =C2=A0Magnus Westerlund

>

>=C2=A0 =C2=A0 =C2=A0----------------------------------------------=
------------------------

>=C2=A0 =C2=A0 =C2=A0Media Technologies, Ericsson Research

>=C2=A0 =C2=A0 =C2=A0----------------------------------------------=
------------------------

>=C2=A0 =C2=A0 =C2=A0Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287 <tel:+46%2010%20714%208=
2%2087>

>=C2=A0 =C2=A0 =C2=A0Torshamnsgatan 23

>=C2=A0 =C2=A0 =C2=A0<https://maps.google.com/?q=3DTorshamnsgatan+23&entry=3Dgmai=
l&source=3Dg>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mob=
ile +46 73 0949=
079 <tel:+46%2073%20094%2090%2079>

>=C2=A0 =C2=A0 =C2=A0SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com <=
;mailto:magnus.westerlund=
@ericsson.com>

>=C2=A0 =C2=A0 =C2=A0----------------------------------------------=
------------------------


>

>

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>







--001a1143195e129c49055bc10df8--


From nobody Tue Oct 17 10:03:52 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BD8133020 for ; Tue, 17 Oct 2017 10:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COzcC7SJiaCh for ; Tue, 17 Oct 2017 10:03:49 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C2813207A for ; Tue, 17 Oct 2017 10:03:49 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id i35so1661822uah.9 for ; Tue, 17 Oct 2017 10:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uqb8rh7Wb+Nv2EJcRFnN6UrFr2uR9ISihhzkFqGa7cc=; b=PiG2VBPdvzXC00B6GUm78s6Q+SIBt4l0cc0dWPbOusMLU0LJSbhpOkJMm2HAGl2UNJ bnNC8TuJO81EhTD1E/iJjQbUgehm/vEt7O3pwRPgJ3Y8aZAg9V5DBufZfIyL/ZduOUyU V+Jlrx3k4LbzimBS/sm4DuJ9GbsH66jtUUQudz8YFsHvLtRiEvm6Amqgb9VdfD9FqxBh 3VJJotG/5AyMW06hV6kyH5T+wyWpKg0d2FQ5YOHSFkC4E7RkEWZly+8ES/TDhgNdDqj0 dDCNRa6zp83B1jMYwnXlgGAU+Pfa4omRxahkkeZZsTuP85tuLurjX+pZFPfNtO+gJYee hQEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uqb8rh7Wb+Nv2EJcRFnN6UrFr2uR9ISihhzkFqGa7cc=; b=tlgkH29AfZn9Qvw8qRdufH6Hec4FAj1TlSpS+potnT+/8SqJhV0HoaVJXmtnTnwA8b V+z3MNeX6XOXtIrzTYVPTAenHHlPsfd0jUNK1H0wr4yYtP63Ns8upUqcYxo7b4hF+0y5 f/LCte6KQ8Aw7wqzulSMgYkWWtnj+hD7LqGqzlQO23ZGVL/qnBLTakliDTlxASQE3jx/ wJrYgqpJy2Jgj8KpRkJ5jWUzR//Fts1zP0vVF40a9CcTdJ5TuRWQ83tX8fgh4+d6vKkH cRlgRksx8JRaUVefFjd5E+3NoZy1iFxyqMQSMWk+ABo8PIeJzzgcvHWDpbjbVVqAeYew ENJw==
X-Gm-Message-State: AMCzsaXc4JYbJXltsHD5q0Gahcji7ODCWmRq0mdZzUqrmHrkyrsYbn+I hbeP7vN05ZJz/QKOj2kcfEDIG3Tcg8u2jCaoc0+E3FNw
X-Google-Smtp-Source: AOwi7QDIwBtdcCMofGJlrUPcSsSBBNwNAGJxYyzsrkaGGQTh6isgRjHUKtv7rsu177LygIyKdQupX2Y99dG/HTN8jeI=
X-Received: by 10.176.81.132 with SMTP id g4mr10516458uaa.60.1508259828274; Tue, 17 Oct 2017 10:03:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.169.130 with HTTP; Tue, 17 Oct 2017 10:03:47 -0700 (PDT)
In-Reply-To: <624deabb-0fa2-4ae2-4661-f71b3ee322ae@alvestrand.no>
References:  <624deabb-0fa2-4ae2-4661-f71b3ee322ae@alvestrand.no>
From: Taylor Brandstetter 
Date: Tue, 17 Oct 2017 10:03:47 -0700
Message-ID: 
To: Harald Alvestrand 
Cc: RTCWeb IETF 
Content-Type: multipart/alternative; boundary="94eb2c1922704b6f8b055bc11b89"
Archived-At: 
Subject: Re: [rtcweb] Processing multiple remote offers
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 17:03:52 -0000

--94eb2c1922704b6f8b055bc11b89
Content-Type: text/plain; charset="UTF-8"

I think it would be simple to allow *adding* m= sections (transceivers);
that would satisfy the use case you describe. It's mostly removing them,
reordering them, or choosing different MIDs that would introduce
complexity. In short, anything that's impossible to do on the local side
(by calling createOffer again after setLocalDescription).

But specifying "apply new remote offer" as "do the steps of a rollback
followed by the steps of applying a fresh offer" would probably work. I
can't think of any potential problems at the moment.

On Tue, Oct 17, 2017 at 7:50 AM, Harald Alvestrand 
wrote:

> Den 17. okt. 2017 01:12, skrev Taylor Brandstetter:
> > JSEP allows a remote offer to be applied while in the
> > "have-remote-offer" state. Meaning that, in addition to supporting
> > multiple answers (via pr-answers), JSEP also supports multiple offers.
> >
> > However, I don't see any text that calls out what (if anything) must be
> > the same between these offers. Should we assume that they can be
> > /completely/ different? Or do they at least need to contain the same m=
> > sections (same type, MID and order)? For example: is it legal to apply
> > an audio-only remote offer, then apply a video-only remote offer? Is it
> > legal to apply an audio-only offer, then an audio+video offer?
>
> Offhand, I can't think of a scenario where multiple offers in have-offer
> state is useful. Most of these convolutions were justified by 3PCC
> cases, which I don't understand fully.
>
> A contrived one is where the remote party sends an audio-only offer,
> adds a video track, and then wishes to re-offer with both audio and
> video before the answerer picks up. This only makes sense if the
> answerer is waiting for the human response before sending the answer.
>
> > This affects WebRTC 1.0, because depending on which direction this goes,
> > we may need to address a situation where an RTCRtpTransceiver is created
> > by applying a remote offer, then invalidated by the next remote offer.
> > Does it go away or exist in limbo state?
> >
> > Of course, another solution would be to say "this isn't supported, do a
> > rollback if you need this."
>
> Or we could specify the effect of applying a new remote offer as being
> identical to rollback + apply the new offer. Is that the simplest spec
> change we can make?
>
>
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
>

--94eb2c1922704b6f8b055bc11b89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think it would be simple to allow *adding* m=3D sections=
 (transceivers); that would satisfy the use case you describe. It's mos=
tly removing them, reordering them, or choosing different MIDs that would i=
ntroduce complexity. In short, anything that's impossible to do on the =
local side (by calling createOffer again after setLocalDescription).
But specifying "apply new remote offer" as "do =
the steps of a rollback followed by the steps of applying a fresh offer&quo=
t; would probably work. I can't think of any potential problems at the =
moment.

On Tue, Oct 17, 2017 at 7:50 AM, Harald Alvestrand <=
harald@alvestrand=
.no> wrote:
Den 17. okt. 2017 01:12, skrev Taylor Brandstetter:

> JSEP allows a remote offer to be applied while in the

> "have-remote-offer" state. Meaning that, in addition to supp=
orting

> multiple answers (via pr-answers), JSEP also supports multiple offers.=


>

> However, I don't see any text that calls out what (if anything) mu=
st be

> the same between these offers. Should we assume that they can be

> /completely/=C2=A0different? Or do they at least need to contai=
n the same m=3D

> sections (same type, MID and order)? For example: is =
it legal to apply

> an audio-only remote offer, then apply a video-only remote offer? Is i=
t

> legal to apply an audio-only offer, then an audio+video offer?



Offhand, I can't think of a scenario where multiple offers in ha=
ve-offer

state is useful. Most of these convolutions were justified by 3PCC

cases, which I don't understand fully.



A contrived one is where the remote party sends an audio-only offer,

adds a video track, and then wishes to re-offer with both audio and

video before the answerer picks up. This only makes sense if the

answerer is waiting for the human response before sending the answer.



> This affects WebRTC 1.0, because depending on which direction this goe=
s,

> we may need to address a situation where an RTCRtpTransceiver is creat=
ed

> by applying a remote offer, then invalidated by the next remote offer.=


> Does it go away or exist in limbo state?

>

> Of course, another solution would be to say "this isn't suppo=
rted, do a

> rollback if you need this."



Or we could specify the effect of applying a new remote offer as bei=
ng

identical to rollback + apply the new offer. Is that the simplest spec

change we can make?





>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>







--94eb2c1922704b6f8b055bc11b89--


From nobody Tue Oct 17 12:26:33 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24DC133085; Tue, 17 Oct 2017 12:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Mqv48RzgOaiN; Tue, 17 Oct 2017 12:26:30 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 CCA08132D4E; Tue, 17 Oct 2017 12:26:29 -0700 (PDT)
X-AuditID: c1b4fb2d-bddff7000000268d-f8-59e659632c5c
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 99.C8.09869.36956E95; Tue, 17 Oct 2017 21:26:28 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Tue, 17 Oct 2017 21:26:27 +0200
From: Christer Holmberg 
To: Harald Alvestrand , "ice@ietf.org" 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
Thread-Index: AQHTQRqIopdqNKi4M0G7+rZLE/Y/d6LmXBGAgAGqxYCAAG9bcA==
Date: Tue, 17 Oct 2017 19:26:27 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B5635D4B5@ESESSMB109.ericsson.se>
References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7n25K5LNIg4ZDXBbH+rrYLL5dqLVY +6+d3YHZ48qEK6weS5b8ZApgiuKySUnNySxLLdK3S+DKOPR7DltBj27Fh56zrA2MP7S7GDk5 JARMJN5tOs/WxcjFISRwhFHi86uL7BDOEkaJA/27mLoYOTjYBCwkuv+BNYgIeEt8/NzKBGIz C6hL3Fl8jh3EFhZwlFgy5yIjRI2TRO+jm6ww9tNzy8DGsAioSrSecgUJ8wr4Stx/94cZYtVK RonTHV/ZQBKcQHPert4FNodRQEzi+6k1ULvEJW49mc8EcbSAxJI955khbFGJl4//sULYShKN S56wguxiFtCUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg6C8nUWQgds5B0zELSsYCRZRWjaHFq cXFuupGxXmpRZnJxcX6eXl5qySZGYKwc3PJbdwfj6teOhxgFOBiVeHhPhT2LFGJNLCuuzD3E KMHBrCTCq2cLFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNT qoFxcZzi8vf5WReWHXi641+91vyEgisVobG6V1VKLKPl/IWZjiacYeqRN5oh8K/q9f/7/DIW ArsE1x7XzUtUZJ+qs/FBeTijGOvFpcfV9to/MBT01JRbFeCrHvPqrePzM7euFe52MpePfMhV /GRn2a9FMaxei9ubGQoeTZ39af+uN/OvH7DcfXyiEktxRqKhFnNRcSIApX3gQZECAAA=
Archived-At: 
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 19:26:32 -0000

SGksDQoNCj4+PiBNb3N0IGltcG9ydGFudCBwb2ludHM6DQo+Pj4NCj4+PiAqIFRoZSBwcm90b2Nv
bCBoYXMgYmVlbiBkZXNpZ25lZCBhbmQgcmV2aXNlZCB0byBiZSB1c2FibGUgd2l0aCANCj4+PiBu
b24tbWVkaWEgZGF0YSwgYnV0IHRoZSBpbnRyb2R1Y3Rpb24gYW5kIGFic3RyYWN0IGRvIG5vdCBy
ZWZsZWN0IA0KPj4+IHRoaXMuIEV4cHVuZ2luZyB0aGUgbWVkaWEgYmlhcyBmcm9tIHRoZSBib2R5
IG9mIHRoZSBkb2N1bWVudCBpcyANCj4+PiBwcm9iYWJseSBub3Qgd29ydGggaXQsIGJ1dCB0aGUg
aW50cm8gYW5kIGFic3RyYWN0IHNob3VsZCBtZW50aW9uIGl0Lg0KPj4gDQo+PiBXZSBDT1VMRCBk
byBhIHNlYXJjaC9yZXBsYWNlIG9wZXJhdGlvbiwgYW5kIHJlcGxhY2UgIm1lZGlhIiB3aXRoICJk
YXRhIi4NCj4+IFdlIHdvdWxkIGVuZCB1cCB3aXRoIHRlcm1zIGxpa2UgImRhdGEgc3RyZWFtIiwg
ImRhdGEgcGFja2V0cyIgZXRjLCBidXQgDQo+PiBJIGd1ZXNzIHRoYXQgaXQgd291bGQgYmUgb2su
DQo+PiANCj4+IEluIHRoZSAiZGF0YSBkZWZpbml0aW9uIiB3ZSB3b3VsZCB0aGVuIGRlc2NyaWJl
IHRoYXQgZGF0YSBpbmNsdWRlcyANCj4+IGJvdGggUlRQIGFuZCBub24tUlRQIGRhdGEuDQo+DQo+
IEkgd291bGQgbGlrZSB0aGF0ISBJIHdhcyBwcm9wb3NpbmcgYSBzbWFsbGVyIGNoYW5nZSBiZWNh
dXNlIGl0J3Mgc28gbGF0ZSBpbiB0aGUgY3ljbGUsIGJ1dCBiZXR0ZXIgaXMgYmV0dGVyIQ0KDQpX
ZWxsLCB0aGUgY3ljbGUgaXMgbW92aW5nIHZlcnkgc2xvd2x5LCBzby4uLiA6KQ0KIA0KPj4+ICog
U2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2hvdWxkIG1lbnRpb24gdGhlIHByb2JsZW0gdGhhdCBJ
Q0UgcmV2ZWFscyANCj4+PiBhZGRyZXNzZXMgdGhhdCBtaWdodCBvdGhlcndpc2UgcmVtYWluIGhp
ZGRlbiwgYW5kIHRoYXQgdGhpcyBpcyBhIA0KPj4+IHByaXZhY3kgY29uY2Vybi4NCj4+IA0KPj4g
SSB3b3VsZCBiZSBnbGFkIGlmIHNvbWVvbmUgY291bGQgcHJvdmlkZSB0ZXh0IGZvciB0aGF0LCB0
byBtYWtlIHN1cmUgDQo+PiB3ZSBnZXQgaXQgcmlnaHQuDQo+DQo+IFRoZSBwYXJhZ3JhcGggSSBz
dWdnZXN0ZWQgaW4gdGhlIFBERiB3YXM6DQo+DQo+IOKAnFRoZSBwcm9jZXNzIG9mIHByb2Jpbmcg
Zm9yIGNhbmRpZGF0ZXMgcmV2ZWFscyB0aGUgc291cmNlIGFkZHJlc3NlcyBvZiB0aGUgY2xpZW50
IGFuZCBpdHMgcGVlciB0byBhbnkgb24tbmV0d29yayANCj4gICBsaXN0ZW5pbmcgYXR0YWNrZXIs
IGFuZCB0aGUgcHJvY2VzcyBvZiBleGNoYW5naW5nIGNhbmRpZGF0ZXMgcmV2ZWFscyB0aGUgYWRk
cmVzc2VzIHRvIGFueSBhdHRhY2tlciB0aGF0IGlzIGFibGUgdG8gDQo+ICAgc2VlIHRoZSBuZWdv
dGlhdGlvbi4gU29tZSBhZGRyZXNzZXMsIHN1Y2ggYXMgdGhlIHNlcnZlciByZWZsZXhpdmUgYWRk
cmVzc2VzIGdhdGhlcmVkIHRocm91Z2ggdGhlIGxvY2FsIGludGVyZmFjZSANCj4gICBvZiBWUE4g
dXNlcnMsIG1heSBiZSBzZW5zaXRpdmUgaW5mb3JtYXRpb24uIElmIHRoZXNlIHBvdGVudGlhbCBh
dHRhY2tzIGNhbuKAmXQgYmUgbWl0aWdhdGVkLCB0aGUgaW1wbGVtZW50YXRpb24gbWF5IA0KPiAg
IHdhbnQgdG8gaW5zdGl0dXRlIGNvbnRyb2xzIGZvciB3aGljaCBhZGRyZXNzZXMgYXJlIHJldmVh
bGVkIHRvIHRoZSBuZWdvdGlhdGlvbiBhbmQvb3IgcHJvYmluZyBwcm9jZXNzLiBTdWNoIGNvbnRy
b2xzIA0KPiAgIG5lZWQgdG8gYmUgc3BlY2lmaWVkIGFzIHBhcnQgb2YgdGhlIElDRSB1c2FnZS7i
gJ0NCj4NCj4gT2YgY291cnNlLCB0aGF0J3Mgb25seSBteSBzdWdnZXN0aW9uLg0KDQpJdCdzIGEg
Z29vZCBzdWdnZXN0aW9uIGluIG15IG9waW5pb24uIFVubGVzcyBzb21lb25lIG9iamVjdHMsIEkg
c3VnZ2VzdCB3ZSBhZGQgaXQgdG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLg0KDQo+Pj4g
KiBUaGUgZG9jdW1lbnQgaGFzIHJlbW92ZWQgYWxsIHRoZSBTRFAgc3BlY2lmaWMgcGFydHMgKGdv
b2QpLCBidXQgdGhlIA0KPj4+IHJlcXVpcmVtZW50cyBpdCBwbGFjZXMgb24gdGhlIG5lZ290aWF0
aW9uIG1lY2hhbmlzbSBhcmVuwrl0IA0KPj4+IGNvbGxlY3RpdmVseSBkb2N1bWVudGVkIGFueXdo
ZXJlLiBBIHNlY3Rpb24gZGVzY3JpYmluZyB0aGlzIHdvdWxkIA0KPj4+IGhlbHAgY29tcHJlaGVu
c2lvbiBmb3IgcGVvcGxlIGRldmVsb3Bpbmcgc2lnbmFsbGluZyBwcm90b2NvbHMgZm9yIHVzZSB3
aXRoIElDRS4NCj4+IA0KPj4gSSBjYW4gdGhpbmsgb2YgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVu
dHM6DQo+PiANCj4+IFJFUTogVGhlcmUgTVVTVCBiZSBhIG1lY2hhbmlzbSBmb3IgSUNFIGFnZW50
cyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgDQo+PiByZW1vdGUgcGVlciBzdXBwb3J0cyBJQ0UN
Cj4+ICANCj4+IFJFUTogVGhlcmUgTVVTVCBiZSBhIG1lY2hhbmlzbSBmb3IgSUNFIGFnZW50cyB0
byBleGNoYW5nZSBjYW5kaWRhdGUgDQo+PiBpbmZvcm1hdGlvbg0KPj4gDQo+PiBSRVE6IFRoZXJl
IE1VU1QgYmUgYSBtZWNoYW5pc20gZm9yIElDRSBhZ2VudHMgdG8gaW5kaWNhdGUgYW4gSUNFIA0K
Pj4gcmVzdGFydCB0byB0aGUgcmVtb3RlIHBlZXINCj4NCj4gSSB3YXMgdGhpbmtpbmcgb2Ygc29t
ZXRoaW5nIGxpa2U6DQo+DQo+IFRoZSBleGNoYW5nZSBvZiBpbmZvcm1hdGlvbiBNVVNUIHJlc3Vs
dCBpbiB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGJlaW5nIGF2YWlsYWJsZSB0byB0aGUgSUNF
IGFnZW50Og0KPg0KPiAtIFdoZXRoZXIgdGhlIHJlbW90ZSBwZWVyIHN1cHBvcnRzIElDRSBhdCBh
bGwNCj4gLSBXaGF0IElDRSBvcHRpb25zLCBpZiBhbnksIGFyZSBzdXBwb3J0ZWQNCj4gLSBXaGV0
aGVyIHRoZSByZW1vdGUgcGVlciBpcyBMaXRlIG9yIEZ1bGwNCj4gLSBXaGV0aGVyIHRoZSByZW1v
dGUgcGVlciB0aGlua3MgaXQncyB0aGUgSW5pdGlhdGluZyBBZ2VudCBvciBub3QNCj4gLSBXaGF0
IGNhbmRpZGF0ZXMgdGhlIHJlbW90ZSBwZWVyIHdpc2hlcyB0byBtYWtlIGF2YWlsYWJsZQ0KPiAt
IFdoZXRoZXIgYW4gSUNFIHJlc3RhcnQgaXMgZGVzaXJlZA0KDQpMb29rcyBvaywgYnV0IEkgYW0g
bm90IHN1cmUgd2hhdCBtZWFuIGJ5IHRoZSA0dGgsIHJlZ2FyZGluZyB0aGlua2luZyBpdCdzIHRo
ZSBpbml0aWF0aW5nIGFnZW50IG9yIG5vdC4NCg0KDQo+Pj4gKiBUaGUgZGVmaW5pdGlvbiBvZiAi
Y29tcG9uZW50IiB0YWxrcyBhYm91dCBhIGNvbXBvbmVudCBoYXZpbmcgb25lIA0KPj4+IGFkZHJl
c3MuIEkgYmVsaWV2ZSB0aGF0IGluIGN1cnJlbnQgdXNhZ2UsIGl0IHNob3VsZCBiZSBkZWZpbmVk
IHRvIA0KPj4+IGhhdmUgYW4gYWRkcmVzcyBwYWlyLiAobm9uLXN5bW1ldHJpYyBSVFAgaXMgZGVh
ZCkuDQo+PiANCj4+IE9yLCBzaG91bGQgd2Ugc2F5ICJoYXZpbmcgb25lIGNhbmRpZGF0ZSBwYWly
Ij8NCj4+IA0KPj4gPHQgaGFuZ1RleHQ9IkNvbXBvbmVudDoiPiBBIGNvbXBvbmVudCBpcyBhIHBp
ZWNlIG9mIGEgZGF0YSBzdHJlYW0gDQo+PiByZXF1aXJpbmcgYSBjYW5kaWRhdGUgcGFpcjsgYSBk
YXRhIHN0cmVhbSBtYXkgcmVxdWlyZSBtdWx0aXBsZSANCj4+IGNvbXBvbmVudHMsIGVhY2ggb2Yg
d2hpY2ggaGFzIHRvIHdvcmsgZm9yIHRoZSBkYXRhIHN0cmVhbSBhcyBhIHdob2xlIA0KPj4gdG8g
d29yay4gIEZvciBtZWRpYSBzdHJlYW1zIGJhc2VkIG9uIFJUUCwgdW5sZXNzIFJUUCBhbmQgUlRD
UCBhcmUgDQo+PiBtdWx0aXBsZXhlZCBpbiB0aGUgc2FtZSBwb3J0LCB0aGVyZSBhcmUgdHdvIGNv
bXBvbmVudHMgcGVyIG1lZGlhIA0KPj4gc3RyZWFtIC0tIG9uZSBmb3IgUlRQLCBhbmQgb25lIGZv
ciBSVENQLjwvdD4NCj4NCj4gVGhpcyB3b3JrcyBmb3IgbWUhDQoNClVubGVzcyBzb21lb25lIG9i
amVjdHMsIEkgd2lsbCBhZGQgaXQuDQoNCj4+IFJlZ2FyZGluZyBub24tc3ltbWV0cmljIFJUUCwg
dGhlIHNwZWMgc2F5cyB0aGF0IHRoZSBzZWxlY3RlZCBjYW5kaWRhdGUgDQo+PiBwYWlyIE1VU1Qg
YmUgdXNlZCBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5nIG1lZGlhLCBzbyBJIGd1ZXNzIHRoYXQg
DQo+PiBtZWFucyBzeW1tZXRyaWMgUlRQLiBQZXJoYXBzIGl0IHdvdWxkIGJlIGdvb2QgdG8gcG9p
bnQgdGhhdCBvdXQuDQo+DQo+IENhbid0IGhhcm0uDQoNCkkgd2lsbCBhZGQgdGV4dCAodW5sZXNz
IGl0J3MgYWxyZWFkeSBzYWlkIHNvbWV3aGVyZSkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo=


From nobody Tue Oct 17 12:32:31 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD96132D4E; Tue, 17 Oct 2017 12:32:24 -0700 (PDT)
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 autolearn_force=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 FXcjM5mEkJri; Tue, 17 Oct 2017 12:32:23 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B609F13292A; Tue, 17 Oct 2017 12:32:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 330007C32DB; Tue, 17 Oct 2017 21:32:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcjE5-Gq14v3; Tue, 17 Oct 2017 21:32:20 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 443C17C0AF4; Tue, 17 Oct 2017 21:32:20 +0200 (CEST)
To: Christer Holmberg , "ice@ietf.org" 
Cc: "rtcweb@ietf.org" 
References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no>   <7594FB04B1934943A5C02806D1A2204B5635D4B5@ESESSMB109.ericsson.se>
From: Harald Alvestrand 
Message-ID: <1cb09b36-54db-afc1-ff5f-4a37c1701a23@alvestrand.no>
Date: Tue, 17 Oct 2017 21:32:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5635D4B5@ESESSMB109.ericsson.se>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 19:32:24 -0000

Leaving in only the one with something left to write...

Den 17. okt. 2017 21:26, skrev Christer Holmberg:
>> I was thinking of something like:
>>
>> The exchange of information MUST result in the following information being available to the ICE agent:
>>
>> - Whether the remote peer supports ICE at all
>> - What ICE options, if any, are supported
>> - Whether the remote peer is Lite or Full
>> - Whether the remote peer thinks it's the Initiating Agent or not
>> - What candidates the remote peer wishes to make available
>> - Whether an ICE restart is desired
> Looks ok, but I am not sure what mean by the 4th, regarding thinking it's the initiating agent or not.
> 
> 

The spec says that the initiating agent will take the CONTROLLING role
if both parties are Full ICE implementations, or if both parties are
Lite implementations. This means that it has to know that it's the
initiating agent.

In cases like Offer/Answer (without glare), it's simple to see which one
is initiating. In cases with 3rd party control (both parties get called
for setup), chat-line systems (both parties initiate a join) or
protocols where glare is possible, something has to make the decision on
which side has the Initiator role.

I'd prefer to abandon the Initiator concept, and say that the exchange
of information should give back the information to each about whether
they should try to take the Controlling role, but that may be a larger
rewrite.


From nobody Tue Oct 17 13:18:15 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06F513292A for ; Tue, 17 Oct 2017 13:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 FNGu5Kjg6w15 for ; Tue, 17 Oct 2017 13:18:12 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AD0132355 for ; Tue, 17 Oct 2017 13:18:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0F9DD7C32DB; Tue, 17 Oct 2017 22:18:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVxCQMwqn-3i; Tue, 17 Oct 2017 22:18:10 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2E1D97C0AF4; Tue, 17 Oct 2017 22:18:10 +0200 (CEST)
To: Taylor Brandstetter 
Cc: Magnus Westerlund , RTCWeb IETF 
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>  <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no> 
From: Harald Alvestrand 
Message-ID: <6da0d797-e1db-a8e7-65d1-0e632ee55c6a@alvestrand.no>
Date: Tue, 17 Oct 2017 22:18:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 20:18:14 -0000

Den 17. okt. 2017 18:59, skrev Taylor Brandstetter:
>     For instance, screenshare-type video varies enormously in
>     bandwidth (very low at static images, enormous at slide change) - if it
>     competes against audio, a "relative" bitrate ratio will not be useful at
>     all.
> 
> 
> I think that's where it's important to get the terminology right; for
> example, rtcweb-transports uses the term "capacity", which implies that
> it's possible to use fewer bits than the capacity. Maybe that's the best
> way to think of this. We also can allow some implementation flexibility.
> 
>     Is there a way we can punt this?
> 
> 
> If we do punt this, I still think we should remove the part of
> rtcweb-transports that talks about the priority causing codecs to be
> configured with send rates at these 1:2:4:8 ratios:
> 
>        o  When the available bandwidth is known from the congestion control
>           algorithm, configure each codec and each data channel with a
>           target send rate that is appropriate to its share of the available
>           bandwidth.
> 
> 
> We should make it clear that the priority only affects the delivery of
> packets (pacing decisions, QoS, SCTP priority), and not how the packets
> are generated upstream. Assuming others agree.

The words about configuring the codecs were intended as advice - most
codecs are terrible at dealing with random lost packets (even with FEC
and NACK and all that), so if the pacer is going to throw their packets
away, the best thing to do is to not generate them.

(Hierarchical coding schemes with frames that have no references to them
work fine as long as you throw away complete frames, though. So
sometimes it works.)

This section is already headed with the words "Two example
implementation strategies are:", so it should already be clear that it's
advice, not normative language.

I'm happy to weaken the words even more, but wouldn't want to lose the
advice entirely.


From nobody Tue Oct 17 15:10:06 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB82013209C for ; Tue, 17 Oct 2017 15:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYotym74pPOg for ; Tue, 17 Oct 2017 15:10:04 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A17126B7E for ; Tue, 17 Oct 2017 15:10:04 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id q13so2127799vkb.2 for ; Tue, 17 Oct 2017 15:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KQ3XZMBgVkGBM0C8uXoMjoGZBbC7jOFWdMbsyGz9/Z0=; b=oPN7JBSZbZooOUPRmGy42e3p+5eEPPOZ+dNm+u2SMDXDXl6GTXr44XzPkBCfeFyILV IGjOyFVugRKVbu8YXzokUcT6hWfzC1GrURj+rE9R2zBh/ioZGml74br7/8J24MwFPk3G Veu+E+GNwD63adgpyfzgAd0XDew/F4itvO6rYpATdHuQPc3Vh7JqfD//nf4P4RrElBD0 MMoHcTS5MoCnlPCw2IW4xWh25kd7YyF3omaw8Bu7wrLySKKceVXYUP9WqcftwE0NfaRF g7dB7VGZnY5ZvKGFCs6OimbLT3iPJ4dnegneNbgmthjTYdZTq6/5/wE3xmw+RGxiNDwK //Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KQ3XZMBgVkGBM0C8uXoMjoGZBbC7jOFWdMbsyGz9/Z0=; b=XN+AzZsQazFJ3LQl5BL822HT3OxYBpPFRFcQZcuuDEK7fkbT0ZTQ33A68oZbwjoQ8B yi6j65XrvaXvHUAf0JNP1Kr9NzDnC0ff4HnM+ZHoyg/vV7FDT/0ynIDoZxMD4VVovpdz iSOu9jN6xMAuI0hBuymnozp/M2yOxe7NPtQKultnBvTidZOAm35F5I5GZo7Wg63cKwgO yTkpHvkZyMsg0fkktPzfdc0xbRUj4zJ6qGTdkj2vRa85qhtU1d9sbVoeIlzcx4LaHSPX eLoKebHKGOiLvARAiRr2UML0NR47BuGYcKrqynQLI0QEoMMxeHlAc916XEwZQalMkKU8 EbKQ==
X-Gm-Message-State: AMCzsaWaz00lUTgpv9Tliw25H5eRUiIu2LMAYB+JdBte0JHHSkOR76IF JsmpJz5HORcO8DUUB6HyTGMzLuk8tFpEEua7qVSVJg==
X-Google-Smtp-Source: ABhQp+T+crUBs+LicmS1tNfcRNlk5uiEBvqnNzKDZzbTpwe1iWo5ydfEsNthBCKMYC5XKx3tdz2em5YqY0/ZKNi6RPE=
X-Received: by 10.31.16.35 with SMTP id g35mr4356428vki.131.1508278202793; Tue, 17 Oct 2017 15:10:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.169.130 with HTTP; Tue, 17 Oct 2017 15:10:01 -0700 (PDT)
In-Reply-To: <6da0d797-e1db-a8e7-65d1-0e632ee55c6a@alvestrand.no>
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>  <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no>  <6da0d797-e1db-a8e7-65d1-0e632ee55c6a@alvestrand.no>
From: Taylor Brandstetter 
Date: Tue, 17 Oct 2017 15:10:01 -0700
Message-ID: 
To: Harald Alvestrand 
Cc: Magnus Westerlund , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a1143195e808e12055bc56248"
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 22:10:06 -0000

--001a1143195e808e12055bc56248
Content-Type: text/plain; charset="UTF-8"

I think the issue is that the example leads you to get the wrong idea about
what the priority is intended to effect. Does it affect encoding, or just
transport? Is the advice meant to say "give the codecs a 1:2 split of the
available bandwidth"? Or "give the codecs some split of the available
bandwidth determined elsewhere, then as packets are queued for
transmission, send them with a 1:2 weighted round-robin scheme or something
equivalent"? I interpreted it as the former. It may just be that I'm not
interpreting this as intended, and there really isn't an issue, other than
possibly needing some clarification.

On Tue, Oct 17, 2017 at 1:18 PM, Harald Alvestrand 
wrote:

> Den 17. okt. 2017 18:59, skrev Taylor Brandstetter:
> >     For instance, screenshare-type video varies enormously in
> >     bandwidth (very low at static images, enormous at slide change) - if
> it
> >     competes against audio, a "relative" bitrate ratio will not be
> useful at
> >     all.
> >
> >
> > I think that's where it's important to get the terminology right; for
> > example, rtcweb-transports uses the term "capacity", which implies that
> > it's possible to use fewer bits than the capacity. Maybe that's the best
> > way to think of this. We also can allow some implementation flexibility.
> >
> >     Is there a way we can punt this?
> >
> >
> > If we do punt this, I still think we should remove the part of
> > rtcweb-transports that talks about the priority causing codecs to be
> > configured with send rates at these 1:2:4:8 ratios:
> >
> >        o  When the available bandwidth is known from the congestion
> control
> >           algorithm, configure each codec and each data channel with a
> >           target send rate that is appropriate to its share of the
> available
> >           bandwidth.
> >
> >
> > We should make it clear that the priority only affects the delivery of
> > packets (pacing decisions, QoS, SCTP priority), and not how the packets
> > are generated upstream. Assuming others agree.
>
> The words about configuring the codecs were intended as advice - most
> codecs are terrible at dealing with random lost packets (even with FEC
> and NACK and all that), so if the pacer is going to throw their packets
> away, the best thing to do is to not generate them.
>
> (Hierarchical coding schemes with frames that have no references to them
> work fine as long as you throw away complete frames, though. So
> sometimes it works.)
>
> This section is already headed with the words "Two example
> implementation strategies are:", so it should already be clear that it's
> advice, not normative language.
>
> I'm happy to weaken the words even more, but wouldn't want to lose the
> advice entirely.
>

--001a1143195e808e12055bc56248
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think the issue is that the example leads you to get the=
 wrong idea about what the priority is intended to effect. Does it affect e=
ncoding, or just transport? Is the advice meant to say "give the codec=
s a 1:2 split of the available bandwidth"? Or "give the codecs so=
me split of the available bandwidth determined elsewhere, then as packets a=
re queued for transmission, send them with a 1:2 weighted round-robin schem=
e or something equivalent"? I interpreted it as the former. It may jus=
t be that I'm not interpreting this as intended, and there really isn&#=
39;t an issue, other than possibly needing some clarification.

On Tue, Oct 17, 2017=
 at 1:18 PM, Harald Alvestrand <harald@alvestrand.no> wro=
te:
Den 17. okt. 2017 18=
:59, skrev Taylor Brandstetter:

>=C2=A0 =C2=A0 =C2=A0For instance, screenshare-type video varies enormou=
sly in

>=C2=A0 =C2=A0 =C2=A0bandwidth (very low at static images, enormous at s=
lide change) - if it

>=C2=A0 =C2=A0 =C2=A0competes against audio, a "relative" bitr=
ate ratio will not be useful at

>=C2=A0 =C2=A0 =C2=A0all.

>

>

> I think that's where it's important to get the terminology rig=
ht; for

> example, rtcweb-transports uses the term "capacity", which i=
mplies that

> it's possible to use fewer bits than the capacity. Maybe that'=
s the best

> way to think of this. We also can allow some implementation flexibilit=
y.

>

>=C2=A0 =C2=A0 =C2=A0Is there a way we can punt this?

>

>

> If we do punt this, I still think we should remove the part of

> rtcweb-transports that talks about the priority causing codecs to be
> configured with send rates at these 1:2:4:8 ratios:

>

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0o=C2=A0 When the available bandwidth i=
s known from the congestion control

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 algorithm, configure each code=
c and each data channel with a

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 target send rate that is appro=
priate to its share of the available

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 bandwidth.

>

>

> We should make it clear that the priority only affects the delivery of=


> packets (pacing decisions, QoS, SCTP priority), and not how the packet=
s

> are generated upstream. Assuming others agree.



The words about configuring the codecs were intended as advice - mos=
t

codecs are terrible at dealing with random lost packets (even with FEC

and NACK and all that), so if the pacer is going to throw their packets

away, the best thing to do is to not generate them.



(Hierarchical coding schemes with frames that have no references to them
work fine as long as you throw away complete frames, though. So

sometimes it works.)



This section is already headed with the words "Two example

implementation strategies are:", so it should already be clear that it=
's

advice, not normative language.



I'm happy to weaken the words even more, but wouldn't want to lose =
the

advice entirely.





--001a1143195e808e12055bc56248--


From nobody Tue Oct 17 16:23:32 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFE13300C for ; Tue, 17 Oct 2017 16:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4RKLp6_XgSC for ; Tue, 17 Oct 2017 16:23:28 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 1E1B5132620 for ; Tue, 17 Oct 2017 16:23:28 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id b5so2198934vkf.12 for ; Tue, 17 Oct 2017 16:23:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FQWesU7CBVf9GF0bEsv8jTFDPcN7nx1uLoswSOcbqhU=; b=GUiRfc4kHIitJP8AwSlNuZt7ZwS9BsId6SWdeg22fLHGrRfVWiftYuHeNIiEVN2bCL Jann64nWMxm6GanLFPwE3AJY1LXOCekHC7qpy6i81hJA5U72hleY0RLeMLgkBfRQAYdj rivBEw2wRu6nGr/wo1ylE/euL2+ai2yuKK457AB83Bm/2k9I1iO4xkUTKyjlWwXtWSV/ pPWewsXQKOYK3G1SiN4xAsGjTPbn9QHoWsAGNjNK+3W4ev/drg6kxpZhH8kMo2aO9ZpB 63jCobvgbcfNSzRnAYL7xAWIGR2B909RNOJLFdfw7OZQZTUzlQ5ZchHeBNXLslDpQzyW qL6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FQWesU7CBVf9GF0bEsv8jTFDPcN7nx1uLoswSOcbqhU=; b=BpQiQDyYwWPROmDoJXcrTl6QBb1cSFFesij4isvWzJzxfcrY76kgl2bvGt6w51fhXT blvX8bDI+ZdUgZQgxrnT+a7r8kkUND6zfNb0T7qX/DVu1/Dwi7G9yLPE7yBkovl9LmYH 9uF9z24VX+l22xIcBn/aj3Ih0PnuSCPtSwuBrPSAqGRkhdW3Xb8xSxfZUA7GBDnp2b3O LoNbyemtH9yVNmnwLQwRWtMLDZaxW2QqKc/DDEVbwArBU/EPPi6PC25fIWm9ZmHYEW2N dA47y9B4WvSGok2cmIKjxlitbG03wLCm8dM/rVxhfJxbVkhHOhdqTCKNbMdoWNROrgWh Vb0w==
X-Gm-Message-State: AMCzsaW/+PbByrkeHErK16i5oSMjdgbpbN9oxZYIWZ/s26TVjhraFJLM HEW9g/7AiWr6qnX+JN44PZZ9DrlgEtcRdj1GlQk=
X-Google-Smtp-Source: ABhQp+SitqAWKtly2Wjv/z7xhS7TtsUvISK/T/H3weDi0EKs//WRcWFsjy6n5KffGoF4oswzU8Hf8bz5wNlY08y6UnE=
X-Received: by 10.31.63.144 with SMTP id m138mr4193302vka.5.1508282606836; Tue, 17 Oct 2017 16:23:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.32.76 with HTTP; Tue, 17 Oct 2017 16:23:06 -0700 (PDT)
In-Reply-To: 
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>  <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no>  <6da0d797-e1db-a8e7-65d1-0e632ee55c6a@alvestrand.no> 
From: Bernard Aboba 
Date: Tue, 17 Oct 2017 16:23:06 -0700
Message-ID: 
To: Taylor Brandstetter 
Cc: Harald Alvestrand , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a114dbff40064d8055bc66940"
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Oct 2017 23:23:30 -0000

--001a114dbff40064d8055bc66940
Content-Type: text/plain; charset="UTF-8"

In practice, many enterprise networks do their own policing/re-marking, so
browser-enforced bandwidth limitations may bear no relation to corpnet
policies.  For example, an enterprise may have its own policies on what
traffic should be marked "high priority" and how much bandwidth it should
be allocated.  As a result, the traffic marked by the browser with a
particular DSCP might be re-marked and different bandwidth limits might be
imposed. As a result, traffic that the browser would chose to drop due to
its own limits might have been allowed to pass through, and traffic the
browser would not drop might be dropped later.  In these situations, it
probably makes more sense for the browser just to mark traffic and let the
enterprise network re-mark and impose its own bandwidth limits as necessary.

On Tue, Oct 17, 2017 at 3:10 PM, Taylor Brandstetter 
wrote:

> I think the issue is that the example leads you to get the wrong idea
> about what the priority is intended to effect. Does it affect encoding, or
> just transport? Is the advice meant to say "give the codecs a 1:2 split of
> the available bandwidth"? Or "give the codecs some split of the available
> bandwidth determined elsewhere, then as packets are queued for
> transmission, send them with a 1:2 weighted round-robin scheme or something
> equivalent"? I interpreted it as the former. It may just be that I'm not
> interpreting this as intended, and there really isn't an issue, other than
> possibly needing some clarification.
>
> On Tue, Oct 17, 2017 at 1:18 PM, Harald Alvestrand 
> wrote:
>
>> Den 17. okt. 2017 18:59, skrev Taylor Brandstetter:
>> >     For instance, screenshare-type video varies enormously in
>> >     bandwidth (very low at static images, enormous at slide change) -
>> if it
>> >     competes against audio, a "relative" bitrate ratio will not be
>> useful at
>> >     all.
>> >
>> >
>> > I think that's where it's important to get the terminology right; for
>> > example, rtcweb-transports uses the term "capacity", which implies that
>> > it's possible to use fewer bits than the capacity. Maybe that's the best
>> > way to think of this. We also can allow some implementation flexibility.
>> >
>> >     Is there a way we can punt this?
>> >
>> >
>> > If we do punt this, I still think we should remove the part of
>> > rtcweb-transports that talks about the priority causing codecs to be
>> > configured with send rates at these 1:2:4:8 ratios:
>> >
>> >        o  When the available bandwidth is known from the congestion
>> control
>> >           algorithm, configure each codec and each data channel with a
>> >           target send rate that is appropriate to its share of the
>> available
>> >           bandwidth.
>> >
>> >
>> > We should make it clear that the priority only affects the delivery of
>> > packets (pacing decisions, QoS, SCTP priority), and not how the packets
>> > are generated upstream. Assuming others agree.
>>
>> The words about configuring the codecs were intended as advice - most
>> codecs are terrible at dealing with random lost packets (even with FEC
>> and NACK and all that), so if the pacer is going to throw their packets
>> away, the best thing to do is to not generate them.
>>
>> (Hierarchical coding schemes with frames that have no references to them
>> work fine as long as you throw away complete frames, though. So
>> sometimes it works.)
>>
>> This section is already headed with the words "Two example
>> implementation strategies are:", so it should already be clear that it's
>> advice, not normative language.
>>
>> I'm happy to weaken the words even more, but wouldn't want to lose the
>> advice entirely.
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a114dbff40064d8055bc66940
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


In practice, many enterprise networks do their own policin=
g/re-marking, so browser-enforced bandwidth limitations may bear no relatio=
n to corpnet policies.=C2=A0 For example, an enterprise may have its own po=
licies on what traffic should be marked "high priority" and how m=
uch bandwidth it should be allocated.=C2=A0 As a result, the traffic marked=
 by the browser with a particular DSCP might be re-marked and different ban=
dwidth limits might be imposed. As a result, traffic that the browser would=
 chose to drop due to its own limits might have been allowed to pass throug=
h, and traffic the browser would not drop might be dropped later.=C2=A0 In =
these situations, it probably makes more sense for the browser just to mark=
 traffic and let the enterprise network re-mark and impose its own bandwidt=
h limits as necessary.

On Tue, Oct 17, 2017 at 3:10 PM, Taylor Brandstetter <deadb=
eef@google.com> wrote:
I think the issue is that the example leads you to get the wro=
ng idea about what the priority is intended to effect. Does it affect encod=
ing, or just transport? Is the advice meant to say "give the codecs a =
1:2 split of the available bandwidth"? Or "give the codecs some s=
plit of the available bandwidth determined elsewhere, then as packets are q=
ueued for transmission, send them with a 1:2 weighted round-robin scheme or=
 something equivalent"? I interpreted it as the former. It may just be=
 that I'm not interpreting this as intended, and there really isn't=
 an issue, other than possibly needing some clarification.

On Tue, Oct 17, 2017 at 1:18 PM, Harald Alvestrand <ha=
rald@alvestrand.no> wrote:
=
Den 17. okt. 2017 18:59, skrev Taylor Brandstetter:

>=C2=A0 =C2=A0 =C2=A0For instance, screenshare-type video varies enormou=
sly in

>=C2=A0 =C2=A0 =C2=A0bandwidth (very low at static images, enormous at s=
lide change) - if it

>=C2=A0 =C2=A0 =C2=A0competes against audio, a "relative" bitr=
ate ratio will not be useful at

>=C2=A0 =C2=A0 =C2=A0all.

>

>

> I think that's where it's important to get the terminology rig=
ht; for

> example, rtcweb-transports uses the term "capacity", which i=
mplies that

> it's possible to use fewer bits than the capacity. Maybe that'=
s the best

> way to think of this. We also can allow some implementation flexibilit=
y.

>

>=C2=A0 =C2=A0 =C2=A0Is there a way we can punt this?

>

>

> If we do punt this, I still think we should remove the part of

> rtcweb-transports that talks about the priority causing codecs to be
> configured with send rates at these 1:2:4:8 ratios:

>

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0o=C2=A0 When the available bandwidth i=
s known from the congestion control

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 algorithm, configure each code=
c and each data channel with a

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 target send rate that is appro=
priate to its share of the available

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 bandwidth.

>

>

> We should make it clear that the priority only affects the delivery of=


> packets (pacing decisions, QoS, SCTP priority), and not how the packet=
s

> are generated upstream. Assuming others agree.



The words about configuring the codecs were intended as advice - mos=
t

codecs are terrible at dealing with random lost packets (even with FEC

and NACK and all that), so if the pacer is going to throw their packets

away, the best thing to do is to not generate them.



(Hierarchical coding schemes with frames that have no references to them
work fine as long as you throw away complete frames, though. So

sometimes it works.)



This section is already headed with the words "Two example

implementation strategies are:", so it should already be clear that it=
's

advice, not normative language.



I'm happy to weaken the words even more, but wouldn't want to lose =
the

advice entirely.






_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--001a114dbff40064d8055bc66940--


From nobody Tue Oct 17 21:33:06 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47FC132F3E for ; Tue, 17 Oct 2017 21:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LJetMs5Ef5FR for ; Tue, 17 Oct 2017 21:33:01 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9C7124239 for ; Tue, 17 Oct 2017 21:33:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4D46A7C3635; Wed, 18 Oct 2017 06:32:59 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZcbf9EVa1mG; Wed, 18 Oct 2017 06:32:58 +0200 (CEST)
Received: from [IPv6:2a02:2121:340:532a:0:48:9f9a:6e01] (unknown [IPv6:2a02:2121:340:532a:0:48:9f9a:6e01]) by mork.alvestrand.no (Postfix) with ESMTPSA id B41D17C0DBA; Wed, 18 Oct 2017 06:32:57 +0200 (CEST)
Date: Wed, 18 Oct 2017 06:32:54 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: 
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>  <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no>  <6da0d797-e1db-a8e7-65d1-0e632ee55c6a@alvestrand.no>  
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----NZWG4DHKXKQ521GX4K67O6TZ4IDUJ0"
Content-Transfer-Encoding: 7bit
To: Bernard Aboba , Taylor Brandstetter 
CC: RTCWeb IETF 
From: Harald Alvestrand 
Message-ID: <7912980F-EAA3-4F9D-81AF-EA3BF86ED2A2@alvestrand.no>
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 18 Oct 2017 04:33:04 -0000

------NZWG4DHKXKQ521GX4K67O6TZ4IDUJ0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

Throwing away packets at sender is only supposed to happen at all after con=
gestion is detected=2E The idea is that the sender can do a better job of d=
eciding what to discard than the router can=2E

Den 18=2E oktober 2017 01:23:06 CEST, skrev Bernard Aboba :
>In practice, many enterprise networks do their own policing/re-marking,
>so
>browser-enforced bandwidth limitations may bear no relation to corpnet
>policies=2E  For example, an enterprise may have its own policies on what
>traffic should be marked "high priority" and how much bandwidth it
>should
>be allocated=2E  As a result, the traffic marked by the browser with a
>particular DSCP might be re-marked and different bandwidth limits might
>be
>imposed=2E As a result, traffic that the browser would chose to drop due
>to
>its own limits might have been allowed to pass through, and traffic the
>browser would not drop might be dropped later=2E  In these situations, it
>probably makes more sense for the browser just to mark traffic and let
>the
>enterprise network re-mark and impose its own bandwidth limits as
>necessary=2E
>
>On Tue, Oct 17, 2017 at 3:10 PM, Taylor Brandstetter
>
>wrote:
>
>> I think the issue is that the example leads you to get the wrong idea
>> about what the priority is intended to effect=2E Does it affect
>encoding, or
>> just transport? Is the advice meant to say "give the codecs a 1:2
>split of
>> the available bandwidth"? Or "give the codecs some split of the
>available
>> bandwidth determined elsewhere, then as packets are queued for
>> transmission, send them with a 1:2 weighted round-robin scheme or
>something
>> equivalent"? I interpreted it as the former=2E It may just be that I'm
>not
>> interpreting this as intended, and there really isn't an issue, other
>than
>> possibly needing some clarification=2E
>>
>> On Tue, Oct 17, 2017 at 1:18 PM, Harald Alvestrand
>
>> wrote:
>>
>>> Den 17=2E okt=2E 2017 18:59, skrev Taylor Brandstetter:
>>> >     For instance, screenshare-type video varies enormously in
>>> >     bandwidth (very low at static images, enormous at slide
>change) -
>>> if it
>>> >     competes against audio, a "relative" bitrate ratio will not be
>>> useful at
>>> >     all=2E
>>> >
>>> >
>>> > I think that's where it's important to get the terminology right;
>for
>>> > example, rtcweb-transports uses the term "capacity", which implies
>that
>>> > it's possible to use fewer bits than the capacity=2E Maybe that's
>the best
>>> > way to think of this=2E We also can allow some implementation
>flexibility=2E
>>> >
>>> >     Is there a way we can punt this?
>>> >
>>> >
>>> > If we do punt this, I still think we should remove the part of
>>> > rtcweb-transports that talks about the priority causing codecs to
>be
>>> > configured with send rates at these 1:2:4:8 ratios:
>>> >
>>> >        o  When the available bandwidth is known from the
>congestion
>>> control
>>> >           algorithm, configure each codec and each data channel
>with a
>>> >           target send rate that is appropriate to its share of the
>>> available
>>> >           bandwidth=2E
>>> >
>>> >
>>> > We should make it clear that the priority only affects the
>delivery of
>>> > packets (pacing decisions, QoS, SCTP priority), and not how the
>packets
>>> > are generated upstream=2E Assuming others agree=2E
>>>
>>> The words about configuring the codecs were intended as advice -
>most
>>> codecs are terrible at dealing with random lost packets (even with
>FEC
>>> and NACK and all that), so if the pacer is going to throw their
>packets
>>> away, the best thing to do is to not generate them=2E
>>>
>>> (Hierarchical coding schemes with frames that have no references to
>them
>>> work fine as long as you throw away complete frames, though=2E So
>>> sometimes it works=2E)
>>>
>>> This section is already headed with the words "Two example
>>> implementation strategies are:", so it should already be clear that
>it's
>>> advice, not normative language=2E
>>>
>>> I'm happy to weaken the words even more, but wouldn't want to lose
>the
>>> advice entirely=2E
>>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf=2Eorg
>> https://www=2Eietf=2Eorg/mailman/listinfo/rtcweb
>>
>>

--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------NZWG4DHKXKQ521GX4K67O6TZ4IDUJ0
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

Throwing away packets at sender is only supposed t=
o happen at all after congestion is detected=2E The idea is that the sender=
 can do a better job of deciding what to discard than the router can=2E
=

Den 18=2E oktober 2017 01:23:06 CEST, skrev =
Bernard Aboba <bernard=2Eaboba@gmail=2Ecom>:


In practice, many enterprise networks do their own polici=
ng/re-marking, so browser-enforced bandwidth limitations may bear no relati=
on to corpnet policies=2E  For example, an enterprise may have its own=
 policies on what traffic should be marked "high priority" and ho=
w much bandwidth it should be allocated=2E  As a result, the traffic m=
arked by the browser with a particular DSCP might be re-marked and differen=
t bandwidth limits might be imposed=2E As a result, traffic that the browse=
r would chose to drop due to its own limits might have been allowed to pass=
 through, and traffic the browser would not drop might be dropped later=2E&=
nbsp; In these situations, it probably makes more sense for the browser jus=
t to mark traffic and let the enterprise network re-mark and impose its own=
 bandwidth limits as necessary=2E

On Tue, Oct 17, 2017 at 3:10 PM, Taylor Brandstette=
r <deadbeef@google=2Ecom> wrote:
I think the issue is that the example lead=
s you to get the wrong idea about what the priority is intended to effect=
=2E Does it affect encoding, or just transport? Is the advice meant to say =
"give the codecs a 1:2 split of the available bandwidth"? Or &quo=
t;give the codecs some split of the available bandwidth determined elsewher=
e, then as packets are queued for transmission, send them with a 1:2 weight=
ed round-robin scheme or something equivalent"? I interpreted it as th=
e former=2E It may just be that I'm not interpreting this as intended, and =
there really isn't an issue, other than possibly needing some clarification=
=2E

On Tue, Oct 17, 2017 at 1:18 PM, Ha=
rald Alvestrand <harald@alvestrand=2Eno> wrote:
=

Den 17=2E okt=2E 2017 18:59, skrev T=
aylor Brandstetter:

>     For instance, screenshare-type video varies enormo=
usly in

>     bandwidth (very low at static images, enormous at =
slide change) - if it

>     competes against audio, a "relative" bit=
rate ratio will not be useful at

>     all=2E

>

>

> I think that's where it's important to get the terminology right; for=


> example, rtcweb-transports uses the term "capacity", which =
implies that

> it's possible to use fewer bits than the capacity=2E Maybe that's the=
 best

> way to think of this=2E We also can allow some implementation flexibi=
lity=2E

>

>     Is there a way we can punt this?

>

>

> If we do punt this, I still think we should remove the part of

> rtcweb-transports that talks about the priority causing codecs to be<=
br />
> configured with send rates at these 1:2:4:8 ratios:

>

>        o  When the available bandwidth =
is known from the congestion control

>           algorithm, configure each cod=
ec and each data channel with a

>           target send rate that is appr=
opriate to its share of the available

>           bandwidth=2E

>

>

> We should make it clear that the priority only affects the delivery o=
f

> packets (pacing decisions, QoS, SCTP priority), and not how the packe=
ts

> are generated upstream=2E Assuming others agree=2E



The words about configuring the codecs were intended as advice - mo=
st

codecs are terrible at dealing with random lost packets (even with FEC

and NACK and all that), so if the pacer is going to throw their packets
away, the best thing to do is to not generate them=2E



(Hierarchical coding schemes with frames that have no references to them
work fine as long as you throw away complete frames, though=2E So

sometimes it works=2E)



This section is already headed with the words "Two example

implementation strategies are:", so it should already be clear that i=
t's

advice, not normative language=2E



I'm happy to weaken the words even more, but wouldn't want to lose the

advice entirely=2E






_______________________________________________
rtcweb mailing list

rtcweb@ietf=2Eorg

https://www=2Eietf=2Eorg/mailman/listinfo/rt=
cweb







-- 

Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------NZWG4DHKXKQ521GX4K67O6TZ4IDUJ0--


From nobody Wed Oct 18 05:37:34 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82AF13319E; Wed, 18 Oct 2017 05:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 M3mAnjz8oeIe; Wed, 18 Oct 2017 05:37:31 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 D2C311320C9; Wed, 18 Oct 2017 05:37:30 -0700 (PDT)
X-AuditID: c1b4fb3a-1c7889c000006897-13-59e74b0847a8
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.F9.26775.80B47E95; Wed, 18 Oct 2017 14:37:29 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 18 Oct 2017 14:37:17 +0200
From: Christer Holmberg 
To: Harald Alvestrand , "ice@ietf.org" 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Security Considerations Pull Request
Thread-Index: AQHTSA3U4CXrlZbiCEazjRESjRn5kg==
Date: Wed, 18 Oct 2017 12:37:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <295DE90FC5203A4EA3C551256BC317D9@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbFdS5fT+3mkwS47i2N9XWwW3y7UWqz9 187uwOxxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGUcWzCPpeA1R8Xlf1dYGxinsncxcnJI CJhIzHj+Hcjm4hASOMIo8WB/FyuEs4RR4lDjTiCHg4NNwEKi+582SIOIgLfEx8+tTCA2s4C6 xJ3F58AGCQtkSaz5uI4doiZb4kD3RiYIW0/ixtepzCA2i4CqxNXj91hBbF4Ba4mvncvB6hkF xCS+n1oDNVNc4taT+UwQxwlILNlznhnCFpV4+fgfWK8o0MwNJ25DPaAo8fHVPkaIXqBdU6ew QdjWEj//v4OytSWWLXzNDLFXUOLkzCcsExhFZyFZNwtJ+ywk7bOQtM9C0r6AkXUVo2hxanFx brqRkV5qUWZycXF+nl5easkmRmAUHdzy22oH48HnjocYBTgYlXh4GdWeRwqxJpYVV+YeYpTg YFYS4Y11AQrxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TBKdXA WHDm1DSVUwWqAUplxyTfzw29tb+UPXCp4KU9O/80ZzyO75o9e6Pf67XbyhbK/drE0FHQmnO4 ePtcmZ/VHVzv0k85qdTpV7rt3vq/aeLLtde6TT5E2Ap6XLgQuLbKP07gmvKC7s0dN/7cjuBo +H7Og6P6g43lte9/A2SWP/zorS7xOzlbxjEuVYmlOCPRUIu5qDgRAD3EzX6eAgAA
Archived-At: 
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Security Considerations Pull Request
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 18 Oct 2017 12:37:33 -0000

Hi,

...

>>=20
>>> * Security considerations should mention the problem that ICE reveals
>>> addresses that might otherwise remain hidden, and that this is a
>>>privacy
>>> concern.
>>=20
>> I would be glad if someone could provide text for that, to make sure we
>> get it right.
>
>The paragraph I suggested in the PDF was:
>
>=B3The process of probing for candidates reveals the source addresses of
>the client and its peer to any on-network listening attacker, and the
>process of exchanging candidates reveals the addresses to any attacker
>that is able to see the negotiation. Some addresses, such as the server
>reflexive addresses gathered through the local interface of VPN users,
>may be sensitive information. If these potential attacks can=B9t be
>mitigated, the implementation may want to institute controls for which
>addresses are revealed to the negotiation and/or probing process. Such
>controls need to be specified as part of the ICE usage.=B2
>
>Of course, that's only my suggestion.

Pull request created:

https://github.com/ice-wg/rfc5245bis/pull/49


Regards,

Christer


From nobody Wed Oct 18 08:53:55 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2D9132E24 for ; Wed, 18 Oct 2017 08:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7jxi5O2UIxW for ; Wed, 18 Oct 2017 08:53:50 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 AE016132031 for ; Wed, 18 Oct 2017 08:53:50 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id w45so3899309uac.3 for ; Wed, 18 Oct 2017 08:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jm++OIrkgfuOgl5VEC+rcmP7pY/8GEG8x5qMq440Kmw=; b=LoKuKFkXMzAvXnjmC7Vnx4ALeLGnhqW1BhFY5Jq5EZU6ynzqKCP+S23d5CKlFk+BFA 2YEwSx2gmQj4l6Kjqxu+/ZLux57BY73CM/wmuEblP+TkFLMkWB6AL0bM+ECw2Zvl+uN4 0xA9A6fCxwhXe+v5ABbj5garQP9JKaLUDibpcdbd9avU8wXBmCat4biSHikfrPn55vaD qkmBTtE8OuFEM8TCD4/jegipL4xpsCNhbWMO/OSAL+LfsvWFaOvpMXILLjDB980ooeO9 qqzEzlDwn257iaIV9Z0iKLXgNox2qUbd05mT5B6ossIteyfmEecnRy7JI4mYy19HkqB1 eQKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jm++OIrkgfuOgl5VEC+rcmP7pY/8GEG8x5qMq440Kmw=; b=gqOC7MSL/SRUYfsQzbgI47BoM2ZG7XJFTXBj9oB8b0UXC0CTcQ4mxpYwzBuse2G1hh asbb7N72la4RwInC6B47jzAKQdYhw4C727La0v7EBSqXQDqAsZzwXa04duyNhusrQ9BN Gd6087Qz6bH0vqG1tSDApLKAXa+cV8IroUZmNW2dzO3R6Ob/LgAkhlUxcYv1JjoxxyPC DRrH/szQi49WC89kir8iFYMXUm4NG4+oh52mi+vth4hSLhFz9Mx967sJoujBWTPuvN80 fO6gpCHjR8r9fK1uojMaDvH34toJB9KFu0sypQysngOa70KIwxm6YgWqZRmBXKtpcAHq f5tA==
X-Gm-Message-State: AMCzsaURz8ZR9fAh7iZNpT2ndOSOQ9sHWPQJQr5ULeuV0KTE5WjaRfQf iYlLEOaCQ1oyEVixM0+udBx8Zhdi58ytI8ryeIkXDWASQc0=
X-Google-Smtp-Source: ABhQp+Rthc58zPe33OIqbpAOEvwcwHTEHqxxsbQ+SHQe35egrGzE59utDbD1kpX1PeQk68mVA2g0RPrnQ6EGBkYVHXU=
X-Received: by 10.159.50.112 with SMTP id y45mr9389095uad.166.1508342029192; Wed, 18 Oct 2017 08:53:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.169.130 with HTTP; Wed, 18 Oct 2017 08:53:48 -0700 (PDT)
In-Reply-To: <7912980F-EAA3-4F9D-81AF-EA3BF86ED2A2@alvestrand.no>
References:  <183cc5c2-470b-0dab-d474-7f22134f867a@ericsson.com>  <85ff04f8-bcae-8561-9866-48d5c16bf0a1@alvestrand.no>  <6da0d797-e1db-a8e7-65d1-0e632ee55c6a@alvestrand.no>   <7912980F-EAA3-4F9D-81AF-EA3BF86ED2A2@alvestrand.no>
From: Taylor Brandstetter 
Date: Wed, 18 Oct 2017 08:53:48 -0700
Message-ID: 
To: Harald Alvestrand 
Cc: Bernard Aboba , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a11456ed6d9e94e055bd43e2f"
Archived-At: 
Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 18 Oct 2017 15:53:53 -0000

--001a11456ed6d9e94e055bd43e2f
Content-Type: text/plain; charset="UTF-8"

Bernard, I think you're describing a situation where the flows would (or at
least should) use different congestion controllers, but this guidance is
for "[w]hen an WebRTC endpoint has packets to send on multiple streams that
are congestion-controlled under the same congestion control regime".

Also, a sidenote: I'm realizing now that we probably don't want to use
RTCPriorityType to indicate which simulcast stream should be allocated bits
first. That's still mixing up QoS with something that should be
independent. Could we use the order of the RTCRtpEncodingParameters list?
If their order in the list determines the order of the RIDs in
"a=simulcast", then this already indicates preference. JSEP doesn't
explicitly say how the order is determined, though.

On Tue, Oct 17, 2017 at 9:32 PM, Harald Alvestrand 
wrote:

> Throwing away packets at sender is only supposed to happen at all after
> congestion is detected. The idea is that the sender can do a better job of
> deciding what to discard than the router can.
>
>
> Den 18. oktober 2017 01:23:06 CEST, skrev Bernard Aboba <
> bernard.aboba@gmail.com>:
>>
>> In practice, many enterprise networks do their own policing/re-marking,
>> so browser-enforced bandwidth limitations may bear no relation to corpnet
>> policies.  For example, an enterprise may have its own policies on what
>> traffic should be marked "high priority" and how much bandwidth it should
>> be allocated.  As a result, the traffic marked by the browser with a
>> particular DSCP might be re-marked and different bandwidth limits might be
>> imposed. As a result, traffic that the browser would chose to drop due to
>> its own limits might have been allowed to pass through, and traffic the
>> browser would not drop might be dropped later.  In these situations, it
>> probably makes more sense for the browser just to mark traffic and let the
>> enterprise network re-mark and impose its own bandwidth limits as necessary.
>>
>> On Tue, Oct 17, 2017 at 3:10 PM, Taylor Brandstetter > > wrote:
>>
>>> I think the issue is that the example leads you to get the wrong idea
>>> about what the priority is intended to effect. Does it affect encoding, or
>>> just transport? Is the advice meant to say "give the codecs a 1:2 split of
>>> the available bandwidth"? Or "give the codecs some split of the available
>>> bandwidth determined elsewhere, then as packets are queued for
>>> transmission, send them with a 1:2 weighted round-robin scheme or something
>>> equivalent"? I interpreted it as the former. It may just be that I'm not
>>> interpreting this as intended, and there really isn't an issue, other than
>>> possibly needing some clarification.
>>>
>>> On Tue, Oct 17, 2017 at 1:18 PM, Harald Alvestrand >> > wrote:
>>>
>>>> Den 17. okt. 2017 18:59, skrev Taylor Brandstetter:
>>>> >     For instance, screenshare-type video varies enormously in
>>>> >     bandwidth (very low at static images, enormous at slide change) -
>>>> if it
>>>> >     competes against audio, a "relative" bitrate ratio will not be
>>>> useful at
>>>> >     all.
>>>> >
>>>> >
>>>> > I think that's where it's important to get the terminology right; for
>>>> > example, rtcweb-transports uses the term "capacity", which implies
>>>> that
>>>> > it's possible to use fewer bits than the capacity. Maybe that's the
>>>> best
>>>> > way to think of this. We also can allow some implementation
>>>> flexibility.
>>>> >
>>>> >     Is there a way we can punt this?
>>>> >
>>>> >
>>>> > If we do punt this, I still think we should remove the part of
>>>> > rtcweb-transports that talks about the priority causing codecs to be
>>>> > configured with send rates at these 1:2:4:8 ratios:
>>>> >
>>>> >        o  When the available bandwidth is known from the congestion
>>>> control
>>>> >           algorithm, configure each codec and each data channel with a
>>>> >           target send rate that is appropriate to its share of the
>>>> available
>>>> >           bandwidth.
>>>> >
>>>> >
>>>> > We should make it clear that the priority only affects the delivery of
>>>> > packets (pacing decisions, QoS, SCTP priority), and not how the
>>>> packets
>>>> > are generated upstream. Assuming others agree.
>>>>
>>>> The words about configuring the codecs were intended as advice - most
>>>> codecs are terrible at dealing with random lost packets (even with FEC
>>>> and NACK and all that), so if the pacer is going to throw their packets
>>>> away, the best thing to do is to not generate them.
>>>>
>>>> (Hierarchical coding schemes with frames that have no references to them
>>>> work fine as long as you throw away complete frames, though. So
>>>> sometimes it works.)
>>>>
>>>> This section is already headed with the words "Two example
>>>> implementation strategies are:", so it should already be clear that it's
>>>> advice, not normative language.
>>>>
>>>> I'm happy to weaken the words even more, but wouldn't want to lose the
>>>> advice entirely.
>>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

--001a11456ed6d9e94e055bd43e2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Bernard, I think you're describing a situation where t=
he flows would (or at least should) use different congestion controllers, b=
ut this guidance is for "[w]hen an WebRTC endpoint has packets to send=
 on multiple streams that are congestion-controlled under the same congesti=
on control regime".

Also, a sidenote: I'm reali=
zing now that we probably don't want to use RTCPriorityType to indicate=
 which simulcast stream should be allocated bits first. That's still mi=
xing up QoS with something that should be independent. Could we use the ord=
er of the RTCRtpEncodingParameters list? If their order in the list determi=
nes the order of the RIDs in "a=3Dsimulcast", then this already i=
ndicates preference. JSEP doesn't explicitly say how the order is deter=
mined, though.

On Tue, Oct 17, 2017 at 9:32 PM, Harald Alvestrand <harald@alv=
estrand.no> wrote:
Thr=
owing away packets at sender is only supposed to happen at all after conges=
tion is detected. The idea is that the sender can do a better job of decidi=
ng what to discard than the router can.


Den 18. oktober 2017 01:23:06 CEST, skrev Bernard Abo=
ba <bernard=
.aboba@gmail.com>:


In practice, many enterprise networks do their own policin=
g/re-marking, so browser-enforced bandwidth limitations may bear no relatio=
n to corpnet policies.=C2=A0 For example, an enterprise may have its own po=
licies on what traffic should be marked "high priority" and how m=
uch bandwidth it should be allocated.=C2=A0 As a result, the traffic marked=
 by the browser with a particular DSCP might be re-marked and different ban=
dwidth limits might be imposed. As a result, traffic that the browser would=
 chose to drop due to its own limits might have been allowed to pass throug=
h, and traffic the browser would not drop might be dropped later.=C2=A0 In =
these situations, it probably makes more sense for the browser just to mark=
 traffic and let the enterprise network re-mark and impose its own bandwidt=
h limits as necessary.

On Tue, Oct 17, 2017 at 3:10 PM, Taylor Brandstetter <deadb=
eef@google.com> wrote:
I think the issue is that the example leads you to get the wro=
ng idea about what the priority is intended to effect. Does it affect encod=
ing, or just transport? Is the advice meant to say "give the codecs a =
1:2 split of the available bandwidth"? Or "give the codecs some s=
plit of the available bandwidth determined elsewhere, then as packets are q=
ueued for transmission, send them with a 1:2 weighted round-robin scheme or=
 something equivalent"? I interpreted it as the former. It may just be=
 that I'm not interpreting this as intended, and there really isn't=
 an issue, other than possibly needing some clarification.

On Tue, Oct 17,=
 2017 at 1:18 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
Den 17. okt. 2017 18:59, s=
krev Taylor Brandstetter:

>=C2=A0 =C2=A0 =C2=A0For instance, screenshare-type video varies enormou=
sly in

>=C2=A0 =C2=A0 =C2=A0bandwidth (very low at static images, enormous at s=
lide change) - if it

>=C2=A0 =C2=A0 =C2=A0competes against audio, a "relative" bitr=
ate ratio will not be useful at

>=C2=A0 =C2=A0 =C2=A0all.

>

>

> I think that's where it's important to get the terminology rig=
ht; for

> example, rtcweb-transports uses the term "capacity", which i=
mplies that

> it's possible to use fewer bits than the capacity. Maybe that'=
s the best

> way to think of this. We also can allow some implementation flexibilit=
y.

>

>=C2=A0 =C2=A0 =C2=A0Is there a way we can punt this?

>

>

> If we do punt this, I still think we should remove the part of

> rtcweb-transports that talks about the priority causing codecs to be
> configured with send rates at these 1:2:4:8 ratios:

>

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0o=C2=A0 When the available bandwidth i=
s known from the congestion control

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 algorithm, configure each code=
c and each data channel with a

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 target send rate that is appro=
priate to its share of the available

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 bandwidth.

>

>

> We should make it clear that the priority only affects the delivery of=


> packets (pacing decisions, QoS, SCTP priority), and not how the packet=
s

> are generated upstream. Assuming others agree.



The words about configuring the codecs were intended as advice - mos=
t

codecs are terrible at dealing with random lost packets (even with FEC

and NACK and all that), so if the pacer is going to throw their packets

away, the best thing to do is to not generate them.



(Hierarchical coding schemes with frames that have no references to them
work fine as long as you throw away complete frames, though. So

sometimes it works.)



This section is already headed with the words "Two example

implementation strategies are:", so it should already be clear that it=
's

advice, not normative language.



I'm happy to weaken the words even more, but wouldn't want to lose =
the

advice entirely.






_______________________________________________

rtcweb mailing list

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






-- 

Sent from my Android device with K-9 Mail. Please excuse my brevity.=



--001a11456ed6d9e94e055bd43e2f--


From nobody Thu Oct 19 00:19:19 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE551344A5 for ; Thu, 19 Oct 2017 00:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level: 
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hARz0Eow5_GK for ; Thu, 19 Oct 2017 00:19:15 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 8E6F7134499 for ; Thu, 19 Oct 2017 00:19:15 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id q124so13968117wmb.0 for ; Thu, 19 Oct 2017 00:19:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=message-id:from:date:to:subject:mime-version :content-transfer-encoding; bh=bxCkcJcOk0xGr0XVA+CXfZ6NVsO49U9eC264kQ61wgA=; b=o/8h4+DKByiDoLxj7fELmOO5gt0kk6J5pwrukS8JfGZY7TbMj6nBf+a/8v3W45Mu2L ivNy8xmaVIT8KLs20nMPi0CZLqXyEG6jeEkjJh3zIXlpcvbr4+sAX/dMuctqyLabWy/e P7V7x6j8mW43q7J8cLFfyM9fFII1MxV+fM68GzhX/i/YFiLui13OJ3cQ7TmT8GiqZ1/P vGXqkjh4qbYQGNZ+FNlhB90Td79jlgWmlRo8tV+DQldkBIApv3ChYKdlz5SRCF4y4Jhz qHR0ZBC+6Gn6E163wP/BpKNALZw9aI77l2NwhAQTopRAxk7qYxOAqREbj8/66OPHLxoF UIaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:date:to:subject:mime-version :content-transfer-encoding; bh=bxCkcJcOk0xGr0XVA+CXfZ6NVsO49U9eC264kQ61wgA=; b=WbYWWDywSXHmwQrXL1ZGpSX+4Mbgxzn4UbDb3b/m49gUKKt/KXK/WiEi4TXJRCXFOa iJpgU9eICtjqfuEvVAVhdX3bxjA06qWPBaYqd9J8L5TU3PjTvJ3I6mJuQDfmPDm0XKnl Vkp0LBzjOrEGlepyx1ESIT5F1ZPVJ9KSAHq1R19g+wNv+In6r2j+f0icifuUEPVzPeks YJqvnN8F1ToyYKKUcq74syEZBond7xlukozl2bS4FJI8G+VrcEiQjTqtnR4Zc0Ej7kzV 4Iha2iyCBk9yhJSu4YC63MJyrVKKai2dZ+uHcIqPIaf6LVUlKNBdiFd1qAlnMD3MU71s bjnA==
X-Gm-Message-State: AMCzsaX8UT9nef+6V/yYDh3O4BM6dAu52BYMcJ0ihuUDwo4FfnRmzBCi vbzF6NJxoeXIIPD+t4rPDjaNOA==
X-Google-Smtp-Source: ABhQp+QZyE3fp9hXWcXdtCdbr7GOKDPSq27gRvrWh9wsypC9EGg/YsRWcfLPYo7RSpMhkC63CBu9dg==
X-Received: by 10.80.157.199 with SMTP id l7mr1259832edk.170.1508397553600; Thu, 19 Oct 2017 00:19:13 -0700 (PDT)
Received: from alpha.saghul.lan (215-213-144-85.ftth.glasoperator.nl. [85.144.213.215]) by smtp.gmail.com with ESMTPSA id q6sm7643422edh.93.2017.10.19.00.19.11 for  (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Oct 2017 00:19:12 -0700 (PDT)
Message-ID: <59e851f0.c685500a.eb016.c29a@mx.google.com>
From: FOSDEM RTC Team 
X-Google-Original-From: FOSDEM RTC Team 
Received: by alpha.saghul.lan (sSMTP sendmail emulation); Thu, 19 Oct 2017 09:19:11 +0200
Date: Thu, 19 Oct 2017 09:19:11 +0200
To: rtcweb@ietf.org
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [rtcweb] [CFP] FOSDEM 2018, RTC devroom, speakers, volunteers neeeded
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 19 Oct 2017 07:19:18 -0000

FOSDEM is one of the world's premier meetings of free software developers,
with over five thousand people attending each year.  FOSDEM 2018
takes place 3-4 February 2018 in Brussels, Belgium.  https://fosdem.org

This email contains information about:
- Real-Time Communications dev-room and lounge,
- speaking opportunities,
- volunteering in the dev-room and lounge,
- related events around FOSDEM, including the XMPP summit,
- social events (the legendary FOSDEM Beer Night and Saturday night dinners
  provide endless networking opportunities),
- the Planet aggregation sites for RTC blogs

Call for participation - Real Time Communications (RTC)
=======================================================

The Real-Time dev-room and Real-Time lounge is about all things involving
real-time communication, including: XMPP, SIP, WebRTC, telephony,
mobile VoIP, codecs, peer-to-peer, privacy and encryption.  The dev-room
is a successor to the previous XMPP and telephony dev-rooms.
We are looking for speakers for the dev-room and volunteers and
participants for the tables in the Real-Time lounge.

The dev-room is only on Sunday, 4th of February 2018.  The lounge will
be present for both days.

To discuss the dev-room and lounge, please join the FSFE-sponsored
Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc

To be kept aware of major developments in Free RTC, without being on the
discussion list, please join the Free-RTC Announce list:
http://lists.freertc.org/mailman/listinfo/announce

Speaking opportunities
----------------------

Note: if you used FOSDEM Pentabarf before, please use the same account/username

Real-Time Communications dev-room: deadline 23:59 UTC on 30th of November.
Please use the Pentabarf system to submit a talk proposal for the
dev-room.  On the "General" tab, please look for the "Track" option and
choose "Real Time Communications devroom".
https://penta.fosdem.org/submission/FOSDEM18/

Other dev-rooms and lightning talks: some speakers may find their topic is
in the scope of more than one dev-room.  It is encouraged to apply to more
than one dev-room and also consider proposing a lightning talk, but please
be kind enough to tell us if you do this by filling out the notes in the form.
You can find the full list of dev-rooms at
   https://www.fosdem.org/2018/schedule/tracks/
and apply for a lightning talk at https://fosdem.org/submit

Main track: the deadline for main track presentations is 23:59 UTC
3rd of November.  Leading developers in the Real-Time Communications
field are encouraged to consider submitting a presentation to
the main track at https://fosdem.org/submit

First-time speaking?
--------------------

FOSDEM dev-rooms are a welcoming environment for people who have never
given a talk before.  Please feel free to contact the dev-room administrators
personally if you would like to ask any questions about it.

Submission guidelines
---------------------

The Pentabarf system will ask for many of the essential details.  Please
remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:
- the purpose of your talk
- any other talk applications (dev-rooms, lightning talks, main track)
- availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the
URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes,
presentations aimed at developers of free and open source software about
RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
dev-room administrators based on the number of received proposals.
As the two previous dev-rooms have been combined into one, we may decide to
give shorter slots than in previous years so that more speakers can
participate.

Please note FOSDEM aims to record and live-stream all talks.
The CC-BY license is used.

Volunteers needed
=================

To make the dev-room and lounge run successfully, we are looking for
volunteers:

- FOSDEM provides video recording equipment and live streaming,
  volunteers are needed to assist in this
- organizing one or more restaurant bookings (dependending upon number of
  participants) for the evening of Saturday, 3rd of February
- participation in the Real-Time lounge
- helping attract sponsorship funds for the dev-room to pay for the
  Saturday night dinner and any other expenses
- circulating this Call for Participation to other mailing lists

Related events - XMPP and RTC summits
=====================================

The XMPP Standards Foundation (XSF) has traditionally held a summit
in the days before FOSDEM.  There is discussion about a similar
summit taking place on the 2nd of February 2018
http://wiki.xmpp.org/web/Summit_22 - please join the mailing
list for details: http://mail.jabber.org/mailman/listinfo/summit

Social events and dinners
=========================

The traditional FOSDEM beer night occurs on Friday, 2nd of February.

On Saturday night, there are usually dinners associated with
each of the dev-rooms.  Most restaurants in Brussels are not so
large so these dinners have space constraints and reservations are
essential.  Please subscribe to the Free-RTC mailing list for
further details about the Saturday night dinner options and how
you can register for a seat: https://lists.fsfe.org/mailman/listinfo/free-rtc

Spread the word and discuss
===========================

If you know of any mailing lists where this CfP would be relevant, please
forward this email. If this dev-room excites you, please blog or microblog
about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:

  All projects    http://planet.freertc.org       planet@freertc.org

  XMPP            http://planet.jabber.org        ralphm@ik.nu

  SIP             http://planet.sip5060.net       planet@sip5060.net
    (Español)     http://planet.sip5060.net/es/   planet@sip5060.net

Please also link to the Planet sites from your own blog or web site as
this helps everybody in the free real-time communications community.

Contact
=======

For any private queries, contact us directly using the address
fosdem-rtc-admin@freertc.org and for any other queries please ask on
the Free-RTC mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc

The dev-room administration team:

  Saúl Ibarra Corretgé 
  Iain R. Learmonth 
  Ralph Meijer 
  Daniel-Constantin Mierla 
  Daniel Pocock 



From nobody Thu Oct 19 05:40:49 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197181241F3; Thu, 19 Oct 2017 05:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 P5iTmfxs28lT; Thu, 19 Oct 2017 05:40:41 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4158B1347FE; Thu, 19 Oct 2017 05:40:22 -0700 (PDT)
X-AuditID: c1b4fb25-debff70000000c94-0f-59e89d346247
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6E.73.03220.43D98E95; Thu, 19 Oct 2017 14:40:20 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Thu, 19 Oct 2017 14:40:19 +0200
From: Christer Holmberg 
To: Christer Holmberg , Harald Alvestrand , "ice@ietf.org" 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Security Considerations Pull Request
Thread-Index: AQHTSA3U4CXrlZbiCEazjRESjRn5kqLrHq1A
Date: Thu, 19 Oct 2017 12:40:19 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B56364946@ESESSMB109.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.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdQ9dk7otIg6YTwhbH+rrYLL5dqLVY +6+d3YHZ48qEK6weS5b8ZApgiuKySUnNySxLLdK3S+DK+L1/LlvBRN6K13ddGhg/cHUxcnJI CJhIdG9cwNbFyMUhJHCEUeLI0W+MEM4SRon5y1vZuxg5ONgELCS6/2mDxEUEGhkl7sx8yATS zSygLnFn8Tl2EFtYIEvi1NGDjCC2iEC2xIHujUwQtpHEk6/HwWwWAVWJL9f2g9XzCvhK/Hw1 CcwWErCWaHz6EczmFLCRuL7jKhuIzSggJvH91BqoXeISt57MZ4K4WkBiyZ7zzBC2qMTLx/9Y IWwlicYlT1gh6vUkbkydwgZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKK UbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzBeDm75rbqD8fIbx0OMAhyMSjy8G5tfRAqxJpYV V+YeYpTgYFYS4c0PAArxpiRWVqUW5ccXleakFh9ilOZgURLnddx3IUJIID2xJDU7NbUgtQgm y8TBKdXAGPPFYJnuXO3a6bpZUY8MTaZmSDvLMGnKfKv/6i24cAW7YR9/ZKeL1/U1S5ZbGqtN ED3swSPEVygWdCdm+ccJdgvP2ofMfMzkGNa06LFSycUgBv7snTzfvLdcMzMyj42q9/L5e/f/ htcL0gtrP0kkV1ycsWfd/nuKobxB+crWviH8EneeznBVYinOSDTUYi4qTgQAenK3KZMCAAA=
Archived-At: 
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Security Considerations Pull Request
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 19 Oct 2017 12:40:43 -0000

Hi,

The PR has been merged.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber=
g
Sent: 18 October 2017 14:37
To: Harald Alvestrand ; ice@ietf.org
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Securit=
y Considerations Pull Request

Hi,

...

>>=20
>>> * Security considerations should mention the problem that ICE=20
>>>reveals  addresses that might otherwise remain hidden, and that this=20
>>>is a privacy  concern.
>>=20
>> I would be glad if someone could provide text for that, to make sure=20
>> we get it right.
>
>The paragraph I suggested in the PDF was:
>
>=B3The process of probing for candidates reveals the source addresses of=20
>the client and its peer to any on-network listening attacker, and the=20
>process of exchanging candidates reveals the addresses to any attacker=20
>that is able to see the negotiation. Some addresses, such as the server=20
>reflexive addresses gathered through the local interface of VPN users,=20
>may be sensitive information. If these potential attacks can=B9t be=20
>mitigated, the implementation may want to institute controls for which=20
>addresses are revealed to the negotiation and/or probing process. Such=20
>controls need to be specified as part of the ICE usage.=B2
>
>Of course, that's only my suggestion.

Pull request created:

https://github.com/ice-wg/rfc5245bis/pull/49


Regards,

Christer

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


From nobody Thu Oct 19 08:29:40 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1F134211; Thu, 19 Oct 2017 08:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KaPrekN9cE5g; Thu, 19 Oct 2017 08:29:37 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 309FF13219B; Thu, 19 Oct 2017 08:29:37 -0700 (PDT)
X-AuditID: c1b4fb2d-bf5ff7000000268d-94-59e8c4df9c7c
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.72.09869.FD4C8E95; Thu, 19 Oct 2017 17:29:35 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Thu, 19 Oct 2017 17:29:34 +0200
From: Christer Holmberg 
To: Harald Alvestrand , "ice@ietf.org" 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
Thread-Index: AdNI7ph4so5Kxoc0TFG794P/hHhttA==
Date: Thu, 19 Oct 2017 15:29:34 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B56364D2A@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7pe79Iy8iDXqfKlkc6+tis/h2odZi 7b92dgdmjysTrrB6LFnykymAKYrLJiU1J7MstUjfLoEro3fmQvaCP0IVPbsvsDUw7hHqYuTk kBAwkbi/9CZ7FyMXh5DAEUaJ39f/MUM4SxglHnzbzdTFyMHBJmAh0f1PG6RBRMBb4uPnViYQ m1lAXeLO4nPsILawQLpE/7V/jBA1GRK7/mxngbD1JD5cnsIMYrMIqErsm3WcDcTmFfCVWH70 Nlgvo4CYxPdTa6BmikvcejKfCeI4AYkle84zQ9iiEi8f/2OFsJUk1h4Gmc8BVK8psX6XPkSr osSU7ofsEOMFJU7OfMIygVF4FpKpsxA6ZiHpmIWkYwEjyypG0eLU4uLcdCNjvdSizOTi4vw8 vbzUkk2MwNA/uOW37g7G1a8dDzEKcDAq8fBu3PsiUog1say4MvcQowQHs5IIb34AUIg3JbGy KrUoP76oNCe1+BCjNAeLkjivw74LEUIC6YklqdmpqQWpRTBZJg5OqQbGoJW7Mos6fOf8ncO9 71rz7EyTr3EiHZvn/N30IsPPxm7H58CqU9GM32u5LNYbidszPVgoL+r8+6T2+6SogtlrXlde 2PDFJPXw+gk+RzR3/zPwW+MZafm8JDuHYYWa6+4296u/l1esPt3QymXPM5vbecNRBa9P8zdu 8tH6OkkrIUY8JOPcBsU6JZbijERDLeai4kQAJi1t/3kCAAA=
Archived-At: 
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 19 Oct 2017 15:29:39 -0000

SGkgSGFyYWxkIChhbmQgb3RoZXJzKSwNCg0KRG8geW91IHRoaW5rIHdlIHNob3VsZCBhZGQgYSBu
ZXcgc2VjdGlvbiAoIklDRSB1c2luZyBwcm90b2NvbCByZXF1aXJlbWVudHMiLCBvciBzb21ldGhp
bmcpLCBvciBkbyB5b3UgdGhpbmsgdGhlIHRleHQgZml0cyBpbiBhbiBleGlzdGluZyBzZWN0aW9u
Pw0KDQpTZWN0aW9uIDQuMyBhbHJlYWR5IGNvbnRhaW5zIHNvbWUgcmVxdWlyZW1lbnRzIHJlZ2Fy
ZGluZyBjYW5kaWRhdGUgZXhjaGFuZ2UgKHRoZSA1dGggYnVsbGV0IGluIHlvdXIgbGlzdCksIGJ1
dCBJIGRvbid0IHRoaW5rIHRoZSBvdGhlciByZXF1aXJlbWVudHMgZml0IHRoZXJlLg0KDQpSZWdh
cmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KRGVuIDE3LiBva3QuIDIwMTcgMjE6MjYsIHNrcmV2IENo
cmlzdGVyIEhvbG1iZXJnOg0KPj4gSSB3YXMgdGhpbmtpbmcgb2Ygc29tZXRoaW5nIGxpa2U6DQo+
Pg0KPj4gVGhlIGV4Y2hhbmdlIG9mIGluZm9ybWF0aW9uIE1VU1QgcmVzdWx0IGluIHRoZSBmb2xs
b3dpbmcgaW5mb3JtYXRpb24gYmVpbmcgYXZhaWxhYmxlIHRvIHRoZSBJQ0UgYWdlbnQ6DQo+Pg0K
Pj4gLSBXaGV0aGVyIHRoZSByZW1vdGUgcGVlciBzdXBwb3J0cyBJQ0UgYXQgYWxsDQo+PiAtIFdo
YXQgSUNFIG9wdGlvbnMsIGlmIGFueSwgYXJlIHN1cHBvcnRlZA0KPj4gLSBXaGV0aGVyIHRoZSBy
ZW1vdGUgcGVlciBpcyBMaXRlIG9yIEZ1bGwNCj4+IC0gV2hldGhlciB0aGUgcmVtb3RlIHBlZXIg
dGhpbmtzIGl0J3MgdGhlIEluaXRpYXRpbmcgQWdlbnQgb3Igbm90DQo+PiAtIFdoYXQgY2FuZGlk
YXRlcyB0aGUgcmVtb3RlIHBlZXIgd2lzaGVzIHRvIG1ha2UgYXZhaWxhYmxlDQo+PiAtIFdoZXRo
ZXIgYW4gSUNFIHJlc3RhcnQgaXMgZGVzaXJlZA0KPiBMb29rcyBvaywgYnV0IEkgYW0gbm90IHN1
cmUgd2hhdCBtZWFuIGJ5IHRoZSA0dGgsIHJlZ2FyZGluZyB0aGlua2luZyBpdCdzIHRoZSBpbml0
aWF0aW5nIGFnZW50IG9yIG5vdC4NCj4gDQo+IA0KDQpUaGUgc3BlYyBzYXlzIHRoYXQgdGhlIGlu
aXRpYXRpbmcgYWdlbnQgd2lsbCB0YWtlIHRoZSBDT05UUk9MTElORyByb2xlIGlmIGJvdGggcGFy
dGllcyBhcmUgRnVsbCBJQ0UgaW1wbGVtZW50YXRpb25zLCBvciBpZiBib3RoIHBhcnRpZXMgYXJl
IExpdGUgaW1wbGVtZW50YXRpb25zLiBUaGlzIG1lYW5zIHRoYXQgaXQgaGFzIHRvIGtub3cgdGhh
dCBpdCdzIHRoZSBpbml0aWF0aW5nIGFnZW50Lg0KDQpJbiBjYXNlcyBsaWtlIE9mZmVyL0Fuc3dl
ciAod2l0aG91dCBnbGFyZSksIGl0J3Mgc2ltcGxlIHRvIHNlZSB3aGljaCBvbmUgaXMgaW5pdGlh
dGluZy4gSW4gY2FzZXMgd2l0aCAzcmQgcGFydHkgY29udHJvbCAoYm90aCBwYXJ0aWVzIGdldCBj
YWxsZWQgZm9yIHNldHVwKSwgY2hhdC1saW5lIHN5c3RlbXMgKGJvdGggcGFydGllcyBpbml0aWF0
ZSBhIGpvaW4pIG9yIHByb3RvY29scyB3aGVyZSBnbGFyZSBpcyBwb3NzaWJsZSwgc29tZXRoaW5n
IGhhcyB0byBtYWtlIHRoZSBkZWNpc2lvbiBvbiB3aGljaCBzaWRlIGhhcyB0aGUgSW5pdGlhdG9y
IHJvbGUuDQoNCkknZCBwcmVmZXIgdG8gYWJhbmRvbiB0aGUgSW5pdGlhdG9yIGNvbmNlcHQsIGFu
ZCBzYXkgdGhhdCB0aGUgZXhjaGFuZ2Ugb2YgaW5mb3JtYXRpb24gc2hvdWxkIGdpdmUgYmFjayB0
aGUgaW5mb3JtYXRpb24gdG8gZWFjaCBhYm91dCB3aGV0aGVyIHRoZXkgc2hvdWxkIHRyeSB0byB0
YWtlIHRoZSBDb250cm9sbGluZyByb2xlLCBidXQgdGhhdCBtYXkgYmUgYSBsYXJnZXIgcmV3cml0
ZS4NCg0K


From nobody Thu Oct 19 11:48:30 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA295133079 for ; Thu, 19 Oct 2017 11:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHC-nQAl6g5S for ; Thu, 19 Oct 2017 11:48:28 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 04227134219 for ; Thu, 19 Oct 2017 11:48:27 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id o44so9287457wrf.11 for ; Thu, 19 Oct 2017 11:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=Z5iOw+K/0xx+gdC8l3zsvJXP7FwpPqU7KQgIf7ZJMO4=; b=gg9Exk8xGWz1OKYYE8QmsYVva3hR5qBcq+bhk5uYnefasDlPejizwqtZvGjK802MRv aKpbT4m7zm+EVX1qev+ZH2mNtKP/8JxMxTDXyKzly84C2hzJr3BQomAVXqOYlYvcNoVI 8eX1da94zCp8gfEz/9YYIzn1FNQx7j1zsBILRcuCSNyxldTEaoqq+KMopyy+mXPVzhDF guFfrOd1CsHpdcW/ttjjc1aDGkJ8ou76zjMbAUos8QLWN3NTut0c5uMXIRnO+7TVcAOK OOc5S2nm5ZoMKJ4+DU0MzTDf1O+fAg44jHsr8ZaLy1hNDZpcM11+mnnhAoU19wvEGuVt buzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=Z5iOw+K/0xx+gdC8l3zsvJXP7FwpPqU7KQgIf7ZJMO4=; b=VlZminl1Z0nUgUwOb2mOmMK7GVdxlvv65C2Vw9KTnWpl8Dv3swrCBVxW7a0PGIYby3 xaN+ZuXhJvIzSBX4bCLg3PrEzcA8807YmVpdl7Tz9/Ef47HG2JbgY/A8Q+UCogpWlBZU 2KLa08U5LDlQimtgzMzm1N+BiRxrBh4pXKDlkOP3F5Vbq9iRXygFXA04MUyjhXCdtjJJ Vezodlfax079wOz9zDNgNVdTVKKTMWiJsgYmMIiwbI/rqs8vzFkyZ8158a5bomBl7Xgo 0rOJU1XMVaEuZ0fJ9BjVe4nPHZL/m2OMKCXnhDGYCgN1l7YYO762RsVX8FyqCFvk9+Jo agFw==
X-Gm-Message-State: AMCzsaUX3Wga3lxmwwNoqj5k3x/JH4+aOtBMDMNXjiTKe390FHl64YeX EIeNM1RQjeX1V1Sy6mTc/vPaYTy3
X-Google-Smtp-Source: ABhQp+T2zb//2xAuYls+RhMXEsqHZWDah1WURjNLuSRn7yCh2nwOXPC8T2Y0IpIyM2NeqpBE1XaSJQ==
X-Received: by 10.223.179.84 with SMTP id k20mr2397064wrd.129.1508438906288; Thu, 19 Oct 2017 11:48:26 -0700 (PDT)
Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id w4sm19033689wrc.17.2017.10.19.11.48.25 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 11:48:25 -0700 (PDT)
To: "rtcweb@ietf.org" 
From: Sergio Garcia Murillo 
Message-ID: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com>
Date: Thu, 19 Oct 2017 20:48:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 19 Oct 2017 18:48:29 -0000

Hi all,

According to the rtp usage draft, it is allowed to pause and resume 
transmissions at any time. There are several scenarios in which it would 
make sense to signal when a webrtc sender decides to pause one stream to 
the receiving side.

One of them, (as described in detail in 
https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207) is be 
when the webrtc endpoints decides to stop sending one simulcast stream 
in order to adapt the sent bandwidth to the bandwidth estimation. In 
that case the SFU would benefit from having that indication before 
having to wait for a timeout on media reception before switching to a 
different simulcast stream. Note that in this case, the stream is paused 
from inside the webrtc stack, so there is no event triggered to be able 
to signal this to the js app so it could notify it off band to the 
receiving side.

 From the solutions discussed, IMHO, the cleanest one would be to 
support the PAUSE indication from RFC7728. Do you think it could be 
considered to support it in webrtc?

Best regards

Sergio


From nobody Thu Oct 19 12:12:58 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5F13307F; Thu, 19 Oct 2017 12:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Dsg7ok1xSdwl; Thu, 19 Oct 2017 12:12:51 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 BF5781321C7; Thu, 19 Oct 2017 12:12:50 -0700 (PDT)
X-AuditID: c1b4fb2d-bf5ff7000000268d-9f-59e8f930e957
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0E.4C.09869.039F8E95; Thu, 19 Oct 2017 21:12:48 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Thu, 19 Oct 2017 21:12:48 +0200
From: Christer Holmberg 
To: Harald Alvestrand , "ice@ietf.org" 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
Thread-Index: AdNI7ph4so5Kxoc0TFG794P/hHhttAAH364g
Date: Thu, 19 Oct 2017 19:12:48 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B56365198@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B56364D2A@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56364D2A@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7va7BzxeRBqum6Vkc6+tis/h2odZi 7b92dgdmjysTrrB6LFnykymAKYrLJiU1J7MstUjfLoEr496rH2wFy8Qq9j3/yNzA2C7UxcjJ ISFgInHtwgVmEFtI4AijxJv7sV2MXED2EkaJjd+Ws3UxcnCwCVhIdP/TBqkREfCW+Pi5lQnE ZhZQl7iz+Bw7iC0skC7Rf+0fI0RNhsSuP9tZIGwjiaf9F5hAxrAIqErMu6sKEuYV8JV4vGkC E8RaX4lZCx6AtXIK+ElcfnkELM4oICbx/dQaqFXiEreezGeCOFlAYsme88wQtqjEy8f/WCFs JYm1hyHWMgvoSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNo cWpxcW66kbFealFmcnFxfp5eXmrJJkZgrBzc8lt3B+Pq146HGAU4GJV4eCfdexEpxJpYVlyZ e4hRgoNZSYR32U2gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KLYLJM HJxSDYyGG05IZvo+aarovtzgWBMbf+ZQXqumHV/+RKuHxya1myaKb1n25IGVdZyQh18x37f/ xtFnAs89vPKrY3bJEff2bXfZTabOPVbv5btp+bEMxqctKYd9KzSbTr6vzP676sPdo70MSy1N uJfy81m79jutsXj44IYHxxRJE1+5tDX66vOsCtNuNiuxFGckGmoxFxUnAgAgY1QBkQIAAA==
Archived-At: 
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 19 Oct 2017 19:12:52 -0000

I suggest to add the following text to section 2.8 (Usages of ICE):

Each usage of ICE MUST define mechanisms for the ICE agents to exchange the=
 following information:
-	Whether the ICE agents supports ICE.
-	What ICE options, if any, the ICE agents support.
-	Whether an agent represents a Lite or Full ICE implementation.
-	Whether an agent assumes it is has the role of the Initiating Agent.
-	The ICE candidates that the ICE agent wants to make available.
-	Whether the ICE agent want to trigger an ICE restart.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber=
g
Sent: 19 October 2017 17:30
To: Harald Alvestrand ; ice@ietf.org
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Informa=
tion exchange requirements

Hi Harald (and others),

Do you think we should add a new section ("ICE using protocol requirements"=
, or something), or do you think the text fits in an existing section?

Section 4.3 already contains some requirements regarding candidate exchange=
 (the 5th bullet in your list), but I don't think the other requirements fi=
t there.

Regards,

Christer



Den 17. okt. 2017 21:26, skrev Christer Holmberg:
>> I was thinking of something like:
>>
>> The exchange of information MUST result in the following information bei=
ng available to the ICE agent:
>>
>> - Whether the remote peer supports ICE at all
>> - What ICE options, if any, are supported
>> - Whether the remote peer is Lite or Full
>> - Whether the remote peer thinks it's the Initiating Agent or not
>> - What candidates the remote peer wishes to make available
>> - Whether an ICE restart is desired
> Looks ok, but I am not sure what mean by the 4th, regarding thinking it's=
 the initiating agent or not.
>=20
>=20

The spec says that the initiating agent will take the CONTROLLING role if b=
oth parties are Full ICE implementations, or if both parties are Lite imple=
mentations. This means that it has to know that it's the initiating agent.

In cases like Offer/Answer (without glare), it's simple to see which one is=
 initiating. In cases with 3rd party control (both parties get called for s=
etup), chat-line systems (both parties initiate a join) or protocols where =
glare is possible, something has to make the decision on which side has the=
 Initiator role.

I'd prefer to abandon the Initiator concept, and say that the exchange of i=
nformation should give back the information to each about whether they shou=
ld try to take the Controlling role, but that may be a larger rewrite.

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


From nobody Thu Oct 19 14:23:43 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2393134312 for ; Thu, 19 Oct 2017 14:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxXhuNF4dbT4 for ; Thu, 19 Oct 2017 14:23:39 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C8F132A1A for ; Thu, 19 Oct 2017 14:23:39 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id x7so7841771pfa.1 for ; Thu, 19 Oct 2017 14:23:39 -0700 (PDT)
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:from:date:message-id:subject:to :cc; bh=LNFIl7dOT+zPhxZlg45NUZ0Hz5WSWMJQ8BJEzVYEM2Q=; b=n9CjET/LQUyaJJvdyia6jDGCTSsZqskOfIeiN8Hbn5o9vpl6Z5GVdOv0edL/c2ChN6 RvUODXrOfHyHryE9zE1Sa0xv+6Y+8MqSvW57RhtxFrk0Qlsx2cLdllO0+k2dd3ynYBIq PTZyrSdmG59yfrnXvxMdNgkW6BEL30ejfUby/R2m1tiMPRYC7MOUGo6/rBr6fDj/DX+T YdY1Y6wa3euea1CL9UxK7G3fEqp7rH66PnDidCFWr8B4V/z5ZugEYzDjtIAKo4XG2l5h i/C8Rv+YMxmqc3FG2YZFTfr99lPlRLUcpqwPbhhEHcrwDRhzD0XLZRKUX1Nls4t7dem2 DUHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LNFIl7dOT+zPhxZlg45NUZ0Hz5WSWMJQ8BJEzVYEM2Q=; b=EFupYapFw2RD2ICjLIdFX70e2X4olXqOxQDwu10PnT6g+MdRWjG1nR1mZLDvkxo7EK jBa5dcRHujFAY3KW0K93irPu5Jsa86XH/FIEUJ6R31SpR0/PwdkRe0HCRu4WXBcslr3V 4HLVQL31MddrzhmLBJSCyw3tDgTRgxQtttKJ5mTZeUg4WNVOCdPoLp1f2wy86Rs9dK0Q VpGXd6qRgSZhmzianp6K84to1GP6CkSggjAzvTIJdapZc1jNwzGBoQtDs3qndAh+VILv cd9rKpWHJ5oamwCC4cAn8dPcEnonrSLFIXpGjRuQ5uZ4xPsidnXNlG/KiX3ykb2uhaoz G7+Q==
X-Gm-Message-State: AMCzsaXUISyU/zx4i3oFXqeFc4ix9G5dhI07N/H2pMBMifLbb1HUYdUq R/oPBRexZeNl3DwD0IyuvDi2VQ==
X-Received: by 10.99.136.198 with SMTP id l189mr2404849pgd.165.1508448219168;  Thu, 19 Oct 2017 14:23:39 -0700 (PDT)
Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com. [209.85.192.176]) by smtp.gmail.com with ESMTPSA id d7sm25006246pgf.20.2017.10.19.14.23.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 14:23:37 -0700 (PDT)
Received: by mail-pf0-f176.google.com with SMTP id x7so7841615pfa.1; Thu, 19 Oct 2017 14:23:37 -0700 (PDT)
X-Google-Smtp-Source: ABhQp+R1NyopTkylCzDo8OcK7aAl2faPS4YmoOsOiZR34zM+q1RiJbJRryoDDHv5bgTBREKntj3brxBn9rFQaxxok8M=
X-Received: by 10.98.210.5 with SMTP id c5mr2764576pfg.181.1508448217363; Thu, 19 Oct 2017 14:23:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.128.131 with HTTP; Thu, 19 Oct 2017 14:23:36 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56365198@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B56364D2A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56365198@ESESSMB109.ericsson.se>
From: Roman Shpount 
Date: Thu, 19 Oct 2017 17:23:36 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Harald Alvestrand , "ice@ietf.org" ,  "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114673b2287bc1055becf80f"
Archived-At: 
Subject: Re: [rtcweb] [Ice] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 19 Oct 2017 21:23:42 -0000

--001a114673b2287bc1055becf80f
Content-Type: text/plain; charset="UTF-8"

Should this also include ice-ufrag, ice-pwd and remote-candidates?

Regards,

_____________
Roman Shpount

On Thu, Oct 19, 2017 at 3:12 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> I suggest to add the following text to section 2.8 (Usages of ICE):
>
> Each usage of ICE MUST define mechanisms for the ICE agents to exchange
> the following information:
> -       Whether the ICE agents supports ICE.
> -       What ICE options, if any, the ICE agents support.
> -       Whether an agent represents a Lite or Full ICE implementation.
> -       Whether an agent assumes it is has the role of the Initiating
> Agent.
> -       The ICE candidates that the ICE agent wants to make available.
> -       Whether the ICE agent want to trigger an ICE restart.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer
> Holmberg
> Sent: 19 October 2017 17:30
> To: Harald Alvestrand ; ice@ietf.org
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 -
> Information exchange requirements
>
> Hi Harald (and others),
>
> Do you think we should add a new section ("ICE using protocol
> requirements", or something), or do you think the text fits in an existing
> section?
>
> Section 4.3 already contains some requirements regarding candidate
> exchange (the 5th bullet in your list), but I don't think the other
> requirements fit there.
>
> Regards,
>
> Christer
>
>
>
> Den 17. okt. 2017 21:26, skrev Christer Holmberg:
> >> I was thinking of something like:
> >>
> >> The exchange of information MUST result in the following information
> being available to the ICE agent:
> >>
> >> - Whether the remote peer supports ICE at all
> >> - What ICE options, if any, are supported
> >> - Whether the remote peer is Lite or Full
> >> - Whether the remote peer thinks it's the Initiating Agent or not
> >> - What candidates the remote peer wishes to make available
> >> - Whether an ICE restart is desired
> > Looks ok, but I am not sure what mean by the 4th, regarding thinking
> it's the initiating agent or not.
> >
> >
>
> The spec says that the initiating agent will take the CONTROLLING role if
> both parties are Full ICE implementations, or if both parties are Lite
> implementations. This means that it has to know that it's the initiating
> agent.
>
> In cases like Offer/Answer (without glare), it's simple to see which one
> is initiating. In cases with 3rd party control (both parties get called for
> setup), chat-line systems (both parties initiate a join) or protocols where
> glare is possible, something has to make the decision on which side has the
> Initiator role.
>
> I'd prefer to abandon the Initiator concept, and say that the exchange of
> information should give back the information to each about whether they
> should try to take the Controlling role, but that may be a larger rewrite.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>

--001a114673b2287bc1055becf80f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Should this also include ice-ufrag, ice-pwd and=C2=A0remote-candidates?
Regards,

_____________
Roman Shp=
ount


On Thu, Oct 19, 2017 at 3:12 PM, Christer Ho=
lmberg <christer.holmberg@ericsson.com> wrote:<=
br>
I suggest to add the following text to se=
ction 2.8 (Usages of ICE):



Each usage of ICE MUST define mechanisms for the ICE agents to exchange the=
 following information:

-=C2=A0 =C2=A0 =C2=A0 =C2=A0Whether the ICE agents supports ICE.</t><=
br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0What ICE options, if any, the ICE agents suppor=
t.</t>

-=C2=A0 =C2=A0 =C2=A0 =C2=A0Whether an agent represents a Lite or Full ICE =
implementation.</t>

-=C2=A0 =C2=A0 =C2=A0 =C2=A0Whether an agent assumes it is has the role of =
the Initiating Agent.</t>

-=C2=A0 =C2=A0 =C2=A0 =C2=A0The ICE candidates that the ICE agent wants to =
make available.</t>

-=C2=A0 =C2=A0 =C2=A0 =C2=A0Whether the ICE agent want to trigger an ICE re=
start.</t>



Regards,



Christer



-----Original Message-----

From: rtcweb [mailto:rtcweb-boun=
ces@ietf.org] On Behalf Of Christer Holmberg

Sent: 19 October 2017 17:30

To: Harald Alvestrand <harald@al=
vestrand.no>; ice@ietf.org

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Informa=
tion exchange requirements



Hi Harald (and others),



Do you think we should add a new section ("ICE using protocol requirem=
ents", or something), or do you think the text fits in an existing sec=
tion?



Section 4.3 already contains some requirements regarding candidate exchange=
 (the 5th bullet in your list), but I don't think the other requirement=
s fit there.



Regards,



Christer







Den 17. okt. 2017 21:26, skrev Christer Holmberg:

>> I was thinking of something like:

>>

>> The exchange of information MUST result in the following informati=
on being available to the ICE agent:

>>

>> - Whether the remote peer supports ICE at all

>> - What ICE options, if any, are supported

>> - Whether the remote peer is Lite or Full

>> - Whether the remote peer thinks it's the Initiating Agent or =
not

>> - What candidates the remote peer wishes to make available

>> - Whether an ICE restart is desired

> Looks ok, but I am not sure what mean by the 4th, regarding thinking i=
t's the initiating agent or not.

>

>



The spec says that the initiating agent will take the CONTROLLING role if b=
oth parties are Full ICE implementations, or if both parties are Lite imple=
mentations. This means that it has to know that it's the initiating age=
nt.



In cases like Offer/Answer (without glare), it's simple to see which on=
e is initiating. In cases with 3rd party control (both parties get called f=
or setup), chat-line systems (both parties initiate a join) or protocols wh=
ere glare is possible, something has to make the decision on which side has=
 the Initiator role.



I'd prefer to abandon the Initiator concept, and say that the exchange =
of information should give back the information to each about whether they =
should try to take the Controlling role, but that may be a larger rewrite.<=
br>


_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________

Ice mailing list

Ice@ietf.org

https://www.ietf.org/mailman/listinfo/ice





--001a114673b2287bc1055becf80f--


From nobody Thu Oct 19 21:56:30 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B791321A4; Thu, 19 Oct 2017 21:56:24 -0700 (PDT)
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 autolearn_force=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 8QcJYtSHgJVj; Thu, 19 Oct 2017 21:56:21 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4471270AB; Thu, 19 Oct 2017 21:56:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4A3597C0DF0; Fri, 20 Oct 2017 06:56:19 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLT7sO-BvW8x; Fri, 20 Oct 2017 06:56:18 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id BB4597C0CFF; Fri, 20 Oct 2017 06:56:17 +0200 (CEST)
To: Roman Shpount , Christer Holmberg 
Cc: "rtcweb@ietf.org" , "ice@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B56364D2A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56365198@ESESSMB109.ericsson.se> 
From: Harald Alvestrand 
Message-ID: <3b325a91-f676-1e6e-c0f4-ff08ad08f634@alvestrand.no>
Date: Fri, 20 Oct 2017 06:56:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [rtcweb] [Ice] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 20 Oct 2017 04:56:24 -0000

Den 19. okt. 2017 23:23, skrev Roman Shpount:
> Should this also include ice-ufrag, ice-pwd and remote-candidates?

Yes.

(candidates are in bullet #4, I'd forgotten the others)
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Thu, Oct 19, 2017 at 3:12 PM, Christer Holmberg
> >
> wrote:
> 
>     I suggest to add the following text to section 2.8 (Usages of ICE):
> 
>     Each usage of ICE MUST define mechanisms for the ICE agents to
>     exchange the following information:
>     -       Whether the ICE agents supports ICE.
>     -       What ICE options, if any, the ICE agents support.
>     -       Whether an agent represents a Lite or Full ICE
>     implementation.
>     -       Whether an agent assumes it is has the role of the
>     Initiating Agent.
>     -       The ICE candidates that the ICE agent wants to make
>     available.
>     -       Whether the ICE agent want to trigger an ICE restart.
> 
>     Regards,
> 
>     Christer
> 
>     -----Original Message-----
>     From: rtcweb [mailto:rtcweb-bounces@ietf.org
>     ] On Behalf Of Christer Holmberg
>     Sent: 19 October 2017 17:30
>     To: Harald Alvestrand      >; ice@ietf.org 
>     Cc: rtcweb@ietf.org 
>     Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 -
>     Information exchange requirements
> 
>     Hi Harald (and others),
> 
>     Do you think we should add a new section ("ICE using protocol
>     requirements", or something), or do you think the text fits in an
>     existing section?
> 
>     Section 4.3 already contains some requirements regarding candidate
>     exchange (the 5th bullet in your list), but I don't think the other
>     requirements fit there.
> 
>     Regards,
> 
>     Christer
> 
> 
> 
>     Den 17. okt. 2017 21:26, skrev Christer Holmberg:
>     >> I was thinking of something like:
>     >>
>     >> The exchange of information MUST result in the following
>     information being available to the ICE agent:
>     >>
>     >> - Whether the remote peer supports ICE at all
>     >> - What ICE options, if any, are supported
>     >> - Whether the remote peer is Lite or Full
>     >> - Whether the remote peer thinks it's the Initiating Agent or not
>     >> - What candidates the remote peer wishes to make available
>     >> - Whether an ICE restart is desired
>     > Looks ok, but I am not sure what mean by the 4th, regarding
>     thinking it's the initiating agent or not.
>     >
>     >
> 
>     The spec says that the initiating agent will take the CONTROLLING
>     role if both parties are Full ICE implementations, or if both
>     parties are Lite implementations. This means that it has to know
>     that it's the initiating agent.
> 
>     In cases like Offer/Answer (without glare), it's simple to see which
>     one is initiating. In cases with 3rd party control (both parties get
>     called for setup), chat-line systems (both parties initiate a join)
>     or protocols where glare is possible, something has to make the
>     decision on which side has the Initiator role.
> 
>     I'd prefer to abandon the Initiator concept, and say that the
>     exchange of information should give back the information to each
>     about whether they should try to take the Controlling role, but that
>     may be a larger rewrite.
> 
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org 
>     https://www.ietf.org/mailman/listinfo/rtcweb
>     
> 
>     _______________________________________________
>     Ice mailing list
>     Ice@ietf.org 
>     https://www.ietf.org/mailman/listinfo/ice
>     
> 
> 
> 
> 
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
> 


From nobody Thu Oct 19 23:24:51 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA29E1270AB; Thu, 19 Oct 2017 23:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 U-3FUU94Ps4j; Thu, 19 Oct 2017 23:24:39 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 153F7124F57; Thu, 19 Oct 2017 23:24:38 -0700 (PDT)
X-AuditID: c1b4fb2d-bf5ff7000000268d-c0-59e996a4c303
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.89.09869.4A699E95; Fri, 20 Oct 2017 08:24:37 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.191]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Fri, 20 Oct 2017 08:24:36 +0200
From: Christer Holmberg 
To: Harald Alvestrand 
CC: Roman Shpount , "rtcweb@ietf.org" , "ice@ietf.org" 
Thread-Topic: [Ice] [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
Thread-Index: AdNI7ph4so5Kxoc0TFG794P/hHhttAAH364gAABq0gAAD88oAAADFXYA
Date: Fri, 20 Oct 2017 06:24:35 +0000
Message-ID: <6AD93BC3-C2ED-4724-9106-E208F0478ECE@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B56364D2A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56365198@ESESSMB109.ericsson.se>  <3b325a91-f676-1e6e-c0f4-ff08ad08f634@alvestrand.no>
In-Reply-To: <3b325a91-f676-1e6e-c0f4-ff08ad08f634@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Content-Type: multipart/signed; boundary="Apple-Mail-67E1B4F5-B78F-4258-9310-358F7ACFD2EC"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUyM2K7pe7SaS8jDS4u47U41tfFZvHtQq3F jAtTmS3W/mtnd2DxuDLhCqvHkiU/mTxuTSkIYI7isklJzcksSy3St0vgyrjd3Mxa8P0+Y8XL +Z1MDYytlxm7GDk5JARMJO4f3sPWxcjFISRwhFHiQ9cjFghnCaPE2edngDIcHGwCFhLd/7RB GkQEdCQe7m9gArGZBbIlrkzZxQJiCwvkStx/toIZoiZPYtfltewQtpvExWXvwepZBFQl5r7p AKvhFbCXWPHkGTPErn4mifPLnzGC7OIUcJSY8SEUpIZRQEzi+6k1ULvEJW49mc8EcbSIxMOL p9kgbFGJl4//sYLMYRaYzCjx7/JqVogFghInZz5hmcAoPAtJ/yxkdbOQ1EEUxUvsWDOfGcKW l9j+dg6QzQFk60hMXsgIEdaWWLbwNVSJhkTnt4msELaixJTuh+wQtrXEjF8H2SBsU4nXRz8y IqtZwMizilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwrg9u+a27g3H1a8dDjAIcjEo8vFZ1 LyOFWBPLiitzDzGqAM15tGH1BUYplrz8vFQlEV7/iUBp3pTEyqrUovz4otKc1OJDjNIcLEri vA77LkQICaQnlqRmp6YWpBbBZJk4OKUaGCfPjl1W08fTn+B8tXZjAqf0f8/ZGrkxYsEyFj5V T+y+Vp4KuHVaTmbr2jNhNztzXW+7vPkd5KzmtcuA7d+eh1vvOr+9buNjkxi/L+zKvS67mVl3 34Xebrl481SfjXDrkj9voh9uO/Hh9R3u+esUVaT+K2i47/mfYlKzX8w5sk1zScPvwCLdP0os xRmJhlrMRcWJANDK0fTzAgAA
Archived-At: 
Subject: Re: [rtcweb] [Ice] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 20 Oct 2017 06:24:49 -0000

--Apple-Mail-67E1B4F5-B78F-4258-9310-358F7ACFD2EC
Content-Type: multipart/alternative;
	boundary=Apple-Mail-F9DA1DE6-9984-480B-9451-E0D83767859E
Content-Transfer-Encoding: 7bit


--Apple-Mail-F9DA1DE6-9984-480B-9451-E0D83767859E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

Detailed candidate requirements can be found in section 4.3. I think we coul=
d simply reference that section.

Regards,

Christer=20


Sent from my iPhone

> On 20 Oct 2017, at 6.56, Harald Alvestrand  wrote:
>=20
> Den 19. okt. 2017 23:23, skrev Roman Shpount:
>> Should this also include ice-ufrag, ice-pwd and remote-candidates?
>=20
> Yes.
>=20
> (candidates are in bullet #4, I'd forgotten the others)
>>=20
>> Regards,
>>=20
>> _____________
>> Roman Shpount
>>=20
>> On Thu, Oct 19, 2017 at 3:12 PM, Christer Holmberg
>> >
>> wrote:
>>=20
>>    I suggest to add the following text to section 2.8 (Usages of ICE):
>>=20
>>    Each usage of ICE MUST define mechanisms for the ICE agents to
>>    exchange the following information:
>>    -       Whether the ICE agents supports ICE.
>>    -       What ICE options, if any, the ICE agents support.
>>    -       Whether an agent represents a Lite or Full ICE
>>    implementation.
>>    -       Whether an agent assumes it is has the role of the
>>    Initiating Agent.
>>    -       The ICE candidates that the ICE agent wants to make
>>    available.
>>    -       Whether the ICE agent want to trigger an ICE restart.
>>=20
>>    Regards,
>>=20
>>    Christer
>>=20
>>    -----Original Message-----
>>    From: rtcweb [mailto:rtcweb-bounces@ietf.org
>>    ] On Behalf Of Christer Holmberg
>>    Sent: 19 October 2017 17:30
>>    To: Harald Alvestrand >    >; ice@ietf.org 
>>    Cc: rtcweb@ietf.org 
>>    Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 -
>>    Information exchange requirements
>>=20
>>    Hi Harald (and others),
>>=20
>>    Do you think we should add a new section ("ICE using protocol
>>    requirements", or something), or do you think the text fits in an
>>    existing section?
>>=20
>>    Section 4.3 already contains some requirements regarding candidate
>>    exchange (the 5th bullet in your list), but I don't think the other
>>    requirements fit there.
>>=20
>>    Regards,
>>=20
>>    Christer
>>=20
>>=20
>>=20
>>    Den 17. okt. 2017 21:26, skrev Christer Holmberg:
>>>> I was thinking of something like:
>>>>=20
>>>> The exchange of information MUST result in the following
>>    information being available to the ICE agent:
>>>>=20
>>>> - Whether the remote peer supports ICE at all
>>>> - What ICE options, if any, are supported
>>>> - Whether the remote peer is Lite or Full
>>>> - Whether the remote peer thinks it's the Initiating Agent or not
>>>> - What candidates the remote peer wishes to make available
>>>> - Whether an ICE restart is desired
>>> Looks ok, but I am not sure what mean by the 4th, regarding
>>    thinking it's the initiating agent or not.
>>>=20
>>>=20
>>=20
>>    The spec says that the initiating agent will take the CONTROLLING
>>    role if both parties are Full ICE implementations, or if both
>>    parties are Lite implementations. This means that it has to know
>>    that it's the initiating agent.
>>=20
>>    In cases like Offer/Answer (without glare), it's simple to see which
>>    one is initiating. In cases with 3rd party control (both parties get
>>    called for setup), chat-line systems (both parties initiate a join)
>>    or protocols where glare is possible, something has to make the
>>    decision on which side has the Initiator role.
>>=20
>>    I'd prefer to abandon the Initiator concept, and say that the
>>    exchange of information should give back the information to each
>>    about whether they should try to take the Controlling role, but that
>>    may be a larger rewrite.
>>=20
>>    _______________________________________________
>>    rtcweb mailing list
>>    rtcweb@ietf.org 
>>    https://www.ietf.org/mailman/listinfo/rtcweb
>>    
>>=20
>>    _______________________________________________
>>    Ice mailing list
>>    Ice@ietf.org 
>>    https://www.ietf.org/mailman/listinfo/ice
>>    
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice
>>=20
>=20

--Apple-Mail-F9DA1DE6-9984-480B-9451-E0D83767859E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpLDxkaXY+PGJy
PjwvZGl2PjxkaXY+RGV0YWlsZWQgY2FuZGlkYXRlIHJlcXVpcmVtZW50cyBjYW4gYmUgZm91bmQg
aW4gc2VjdGlvbiA0LjMuIEkgdGhpbmsgd2UgY291bGQgc2ltcGx5IHJlZmVyZW5jZSB0aGF0IHNl
Y3Rpb24uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5SZWdhcmRzLDwvZGl2PjxkaXY+PGJyPjwv
ZGl2PjxkaXY+Q2hyaXN0ZXImbmJzcDs8L2Rpdj48ZGl2Pjxicj48YnI+PGRpdiBpZD0iQXBwbGVN
YWlsU2lnbmF0dXJlIj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+PGRpdj48YnI+T24gMjAgT2N0
IDIwMTcsIGF0IDYuNTYsIEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86aGFy
YWxkQGFsdmVzdHJhbmQubm8iPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PGJy
Pjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPkRlbiAxOS4gb2t0
LiAyMDE3IDIzOjIzLCBza3JldiBSb21hbiBTaHBvdW50Ojwvc3Bhbj48YnI+PGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+PHNwYW4+U2hvdWxkIHRoaXMgYWxzbyBpbmNsdWRlIGljZS11ZnJhZywgaWNl
LXB3ZCBhbmQmbmJzcDtyZW1vdGUtY2FuZGlkYXRlcz88L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48
c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlllcy48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNw
YW4+KGNhbmRpZGF0ZXMgYXJlIGluIGJ1bGxldCAjNCwgSSdkIGZvcmdvdHRlbiB0aGUgb3RoZXJz
KTwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Js
b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+UmVnYXJkcyw8L3NwYW4+PGJy
PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwv
YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5fX19fX19fX19fX19fPC9z
cGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Um9tYW4g
U2hwb3VudDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz
cGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu
Pk9uIFRodSwgT2N0IDE5LCAyMDE3IGF0IDM6MTIgUE0sIENocmlzdGVyIEhvbG1iZXJnPC9zcGFu
Pjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jmx0OzxhIGhy
ZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1i
ZXJnQGVyaWNzc29uLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy
Z0Blcmljc3Nvbi5jb20iPm1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+
Jmd0OyZndDs8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48
c3Bhbj53cm90ZTo8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48
c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7SSBzdWdnZXN0IHRvIGFkZCB0aGUgZm9sbG93aW5nIHRl
eHQgdG8gc2VjdGlvbiAyLjggKFVzYWdlcyBvZiBJQ0UpOjwvc3Bhbj48YnI+PC9ibG9ja3F1b3Rl
PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtFYWNoIHVzYWdl
IG9mIElDRSBNVVNUIGRlZmluZSBtZWNoYW5pc21zIGZvciB0aGUgSUNFIGFnZW50cyB0bzwvc3Bh
bj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsm
bmJzcDsmbmJzcDtleGNoYW5nZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uOjwvc3Bhbj48YnI+
PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsm
bmJzcDstJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V2hldGhlciB0aGUgSUNFIGFnZW50cyBz
dXBwb3J0cyBJQ0UuJmx0Oy90Jmd0Ozwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7V2hhdCBJQ0Ugb3B0aW9ucywgaWYgYW55LCB0aGUgSUNFIGFnZW50cyBzdXBwb3J0
LiZsdDsvdCZndDs8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1do
ZXRoZXIgYW4gYWdlbnQgcmVwcmVzZW50cyBhIExpdGUgb3IgRnVsbCBJQ0U8L3NwYW4+PGJyPjwv
YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5i
c3A7aW1wbGVtZW50YXRpb24uJmx0Oy90Jmd0Ozwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7V2hldGhlciBhbiBhZ2VudCBhc3N1bWVzIGl0IGlzIGhhcyB0aGUgcm9s
ZSBvZiB0aGU8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48
c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7SW5pdGlhdGluZyBBZ2VudC4mbHQ7L3QmZ3Q7PC9zcGFu
Pjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZu
YnNwOyZuYnNwOy0mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgSUNFIGNhbmRpZGF0ZXMg
dGhhdCB0aGUgSUNFIGFnZW50IHdhbnRzIHRvIG1ha2U8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48
YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7YXZhaWxhYmxl
LiZsdDsvdCZndDs8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1do
ZXRoZXIgdGhlIElDRSBhZ2VudCB3YW50IHRvIHRyaWdnZXIgYW4gSUNFIHJlc3RhcnQuJmx0Oy90
Jmd0Ozwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu
Pjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAm
bmJzcDsmbmJzcDsmbmJzcDtSZWdhcmRzLDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtDaHJpc3Rlcjwvc3Bhbj48YnI+
PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9i
bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJz
cDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtGcm9tOiBydGN3ZWIg
WzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1i
b3VuY2VzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0
Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+
Jmd0O10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnPC9zcGFuPjxicj48L2Jsb2NrcXVv
dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwO1NlbnQ6
IDE5IE9jdG9iZXIgMjAxNyAxNzozMDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtUbzogSGFyYWxkIEFsdmVzdHJh
bmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyI+aGFyYWxkQGFsdmVz
dHJhbmQubm88L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFs
dmVzdHJhbmQubm8iPm1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7Jmd0OzsgPGEg
aHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyI+aWNlQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmljZUBpZXRmLm9yZyI+bWFpbHRvOmljZUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxi
cj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNw
OyZuYnNwO0NjOiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5v
cmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5tYWlsdG86cnRjd2Vi
QGlldGYub3JnPC9hPiZndDs8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7U3ViamVjdDogUmU6IFtydGN3ZWJdIFdH
TEMgUmV2aWV3IG9mIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTIgLTwvc3Bhbj48YnI+PC9i
bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJz
cDtJbmZvcm1hdGlvbiBleGNoYW5nZSByZXF1aXJlbWVudHM8L3NwYW4+PGJyPjwvYmxvY2txdW90
ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48
YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7SGkgSGFyYWxk
IChhbmQgb3RoZXJzKSw8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7RG8geW91IHRoaW5rIHdlIHNob3VsZCBhZGQgYSBu
ZXcgc2VjdGlvbiAoIklDRSB1c2luZyBwcm90b2NvbDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlbWVu
dHMiLCBvciBzb21ldGhpbmcpLCBvciBkbyB5b3UgdGhpbmsgdGhlIHRleHQgZml0cyBpbiBhbjwv
c3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJz
cDsmbmJzcDsmbmJzcDtleGlzdGluZyBzZWN0aW9uPzwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtTZWN0aW9uIDQuMyBh
bHJlYWR5IGNvbnRhaW5zIHNvbWUgcmVxdWlyZW1lbnRzIHJlZ2FyZGluZyBjYW5kaWRhdGU8L3Nw
YW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7
Jm5ic3A7Jm5ic3A7ZXhjaGFuZ2UgKHRoZSA1dGggYnVsbGV0IGluIHlvdXIgbGlzdCksIGJ1dCBJ
IGRvbid0IHRoaW5rIHRoZSBvdGhlcjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlbWVudHMgZml0IHRo
ZXJlLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu
Pjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAm
bmJzcDsmbmJzcDsmbmJzcDtSZWdhcmRzLDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtDaHJpc3Rlcjwvc3Bhbj48YnI+
PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9i
bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9j
a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1
b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtEZW4g
MTcuIG9rdC4gMjAxNyAyMToyNiwgc2tyZXYgQ2hyaXN0ZXIgSG9sbWJlcmc6PC9zcGFuPjxicj48
L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SSB3YXMgdGhpbmtpbmcgb2Ygc29tZXRo
aW5nIGxpa2U6PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90
ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv
dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlRoZSBleGNoYW5nZSBvZiBpbmZv
cm1hdGlvbiBNVVNUIHJlc3VsdCBpbiB0aGUgZm9sbG93aW5nPC9zcGFuPjxicj48L2Jsb2NrcXVv
dGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh
bj4gJm5ic3A7Jm5ic3A7Jm5ic3A7aW5mb3JtYXRpb24gYmVpbmcgYXZhaWxhYmxlIHRvIHRoZSBJ
Q0UgYWdlbnQ6PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9z
cGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj48c3Bhbj4tIFdoZXRoZXIgdGhlIHJlbW90ZSBwZWVyIHN1cHBvcnRzIElDRSBhdCBhbGw8
L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPjxzcGFuPi0gV2hhdCBJQ0Ugb3B0aW9ucywgaWYgYW55LCBhcmUgc3VwcG9ydGVkPC9z
cGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj48c3Bhbj4tIFdoZXRoZXIgdGhlIHJlbW90ZSBwZWVyIGlzIExpdGUgb3IgRnVsbDwvc3Bh
bj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+PHNwYW4+LSBXaGV0aGVyIHRoZSByZW1vdGUgcGVlciB0aGlua3MgaXQncyB0aGUgSW5pdGlh
dGluZyBBZ2VudCBvciBub3Q8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9i
bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0gV2hhdCBjYW5kaWRhdGVzIHRoZSByZW1v
dGUgcGVlciB3aXNoZXMgdG8gbWFrZSBhdmFpbGFibGU8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48
L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0gV2hldGhlciBh
biBJQ0UgcmVzdGFydCBpcyBkZXNpcmVkPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1
b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj48c3Bhbj5Mb29rcyBvaywgYnV0IEkgYW0gbm90IHN1cmUgd2hhdCBtZWFuIGJ5IHRo
ZSA0dGgsIHJlZ2FyZGluZzwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7dGhpbmtpbmcgaXQn
cyB0aGUgaW5pdGlhdGluZyBhZ2VudCBvciBub3QuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFu
Pjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxv
Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2tx
dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7VGhl
IHNwZWMgc2F5cyB0aGF0IHRoZSBpbml0aWF0aW5nIGFnZW50IHdpbGwgdGFrZSB0aGUgQ09OVFJP
TExJTkc8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh
bj4gJm5ic3A7Jm5ic3A7Jm5ic3A7cm9sZSBpZiBib3RoIHBhcnRpZXMgYXJlIEZ1bGwgSUNFIGlt
cGxlbWVudGF0aW9ucywgb3IgaWYgYm90aDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtwYXJ0aWVzIGFyZSBMaXRl
IGltcGxlbWVudGF0aW9ucy4gVGhpcyBtZWFucyB0aGF0IGl0IGhhcyB0byBrbm93PC9zcGFuPjxi
cj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNw
OyZuYnNwO3RoYXQgaXQncyB0aGUgaW5pdGlhdGluZyBhZ2VudC48L3NwYW4+PGJyPjwvYmxvY2tx
dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90
ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7SW4gY2Fz
ZXMgbGlrZSBPZmZlci9BbnN3ZXIgKHdpdGhvdXQgZ2xhcmUpLCBpdCdzIHNpbXBsZSB0byBzZWUg
d2hpY2g8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh
bj4gJm5ic3A7Jm5ic3A7Jm5ic3A7b25lIGlzIGluaXRpYXRpbmcuIEluIGNhc2VzIHdpdGggM3Jk
IHBhcnR5IGNvbnRyb2wgKGJvdGggcGFydGllcyBnZXQ8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48
YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Y2FsbGVkIGZv
ciBzZXR1cCksIGNoYXQtbGluZSBzeXN0ZW1zIChib3RoIHBhcnRpZXMgaW5pdGlhdGUgYSBqb2lu
KTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAm
bmJzcDsmbmJzcDsmbmJzcDtvciBwcm90b2NvbHMgd2hlcmUgZ2xhcmUgaXMgcG9zc2libGUsIHNv
bWV0aGluZyBoYXMgdG8gbWFrZSB0aGU8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7ZGVjaXNpb24gb24gd2hpY2gg
c2lkZSBoYXMgdGhlIEluaXRpYXRvciByb2xlLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiAmbmJzcDsmbmJzcDsmbmJzcDtJJ2QgcHJlZmVyIHRvIGFi
YW5kb24gdGhlIEluaXRpYXRvciBjb25jZXB0LCBhbmQgc2F5IHRoYXQgdGhlPC9zcGFuPjxicj48
L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZu
YnNwO2V4Y2hhbmdlIG9mIGluZm9ybWF0aW9uIHNob3VsZCBnaXZlIGJhY2sgdGhlIGluZm9ybWF0
aW9uIHRvIGVhY2g8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7YWJvdXQgd2hldGhlciB0aGV5IHNob3VsZCB0cnkg
dG8gdGFrZSB0aGUgQ29udHJvbGxpbmcgcm9sZSwgYnV0IHRoYXQ8L3NwYW4+PGJyPjwvYmxvY2tx
dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7bWF5
IGJlIGEgbGFyZ2VyIHJld3JpdGUuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwO3J0Y3dlYiBtYWlsaW5nIGxp
c3Q8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4g
Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2Vi
QGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+bWFpbHRv
OnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT4mZ3Q7PC9zcGFuPjxicj48L2Js
b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2Nr
cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwO19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48
L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZu
YnNwO0ljZSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOkljZUBp
ZXRmLm9yZyI+SWNlQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9y
ZyI+bWFpbHRvOkljZUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTwvYT48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTwvYT4mZ3Q7PC9zcGFuPjxicj48L2Jsb2NrcXVv
dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl
Ij48c3Bhbj5JY2UgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyI+SWNlQGll
dGYub3JnPC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
PjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNl
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTwvYT48L3NwYW4+PGJy
PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwv
YmxvY2txdW90ZT48c3Bhbj48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Jv
ZHk+PC9odG1sPg==

--Apple-Mail-F9DA1DE6-9984-480B-9451-E0D83767859E--

--Apple-Mail-67E1B4F5-B78F-4258-9310-358F7ACFD2EC
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBfkw
ggPhoAMCAQICEDENcj3BkzWA84WFoa5BUMgwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp
Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMTA0MTIy
ODE5WhcNMTcxMTA0MTIyODE4WjBvMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0
ZXIgSG9sbWJlcmcxLTArBgkqhkiG9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv
bTEPMA0GA1UEBRMGTE1GQ0hIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjG+3x1iF
fQiBWGKL/OjUf+om3VVdCPmalSxNtc0Ae6LRb+g0ypVVxO4oguBwrzIZRpIN/6hZgIQLYuWdWe/u
XhDBCD+SSRGe3zJugTBN9wZHYIOBHya6uBVBtvB8Nv/9Ksd42Vrytlu+dQJhLlCeZ5GehdNBp8yZ
joW73mnQvBOZHqsKMPa4mtP1msx4it8Mc422p6EGmSAPqAio+WMgr/HAk2kpOKRAG18MbYSfewWm
T2obJ2+BGRD9PIMUeSBPTUYuOxKoei7QY4lqWgeNhJghAcXNriEPO7ZSdHtkrwqO+K6sZ3V7VHml
mrjI47eA54SXYl2WNuOA+SdYFrLERQIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0
cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYI
KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgG
CCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRp
dmlkdWFsY2F2Mi5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t
MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjAdBgNVHQ4EFgQUVKNN/w60QFtsaTJoTdrhpLw4MeowHwYDVR0jBBgwFoAUsQ3K1Ea3r4YC
wy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQC28KhuYp4Zf8T8
bLkFnB+xjlGSDwMNCZSpbVUP05bBe4oNCdYss2qOhrFyLSfR91mT6wsuREHISZu6nJ9pCl/Dhm/m
K+dxYrC0doMfqpK0DAznYsfVmrNHLyIw1owEJxGW8c/2vnc3QD9E68Dbw/NvNmyMtHwrf97qAX8z
J70BvuMBtNfGw7p3PjQo9RZEipEkW/Xz9mdpYuuaXyXMbRiH2+c7FyWRuBrW3tP4cZY9zXHIwf81
Tzuz0PpZ1psbToiUNpaAPutr0K3lEK99vFyuCBxZ6FPs14lX1Ddrq774q0B+x2u9EwTGttCfDZ9m
hL2OkGDBECYQIlZjU4r+BBhr+YXl+b2/Mmo+6a+GCL2+g9K/qcKb3xBPGIQBFiYAmT+5Oc0MIa6b
khf7PsBK7l6OfbKvWzgnn4IZLXOX8A7vL3nffHIn0T1J7k/3ObJSSfC4xZ/Hfi5xpJVHRQPZC4yC
VVcfkzOA/zk2kRvpjxW2NqU8kdFfODxuxy3pLqTbBc3JnuyAZEPtc5G/YY8+qcoqHX+q4e6YfvFx
1jYM2wuT3RggDYPH1Vq8aqjqBM73FHDzMul1ybNCVoVmrPJiXR6tpBgwxKQOwWwWrZrRKs4l0Z2B
iXkCt3jA117ZjngUgOMu2GeO8vgsb25J0kOXcoIcJBKvmuzkTxlY7I7ViWCenTCCBrYwggSeoAMC
AQICEQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29u
ZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0
MDUyNzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+J
OOqjddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2a
vWWXhPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvM
iZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtk
dldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1
EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3W
AEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJ
DxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiA
SHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCC
AbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFz
b25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy
YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE
TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1
c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1
c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbK
DnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4IC
AQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9
IewyaV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYV
Cd+xhsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1
qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhG
WHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qh
tu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVw
GB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP
4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TG
bTGCApYwggKSAgEBME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M
IEluZGl2aWR1YWwgQ0EgdjICEDENcj3BkzWA84WFoa5BUMgwCQYFKw4DAhoFAKCCAR0wGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDIwMDYyNDM0WjAjBgkqhkiG
9w0BCQQxFgQU0UdJIS3uMTiUkI+p+ytQ7keilaYwXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQK
DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGT
NYDzhYWhrkFQyDBfBgsqhkiG9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEDENcj3BkzWA84WFoa5BUMgwDQYJKoZI
hvcNAQEBBQAEggEAfjEg1F0mM9oTiOIRDKG1Kl3iWvq9quwV18y2Su0n8DrV0/wZ+5+HBzks3ffZ
4gj44YBZmiufb1A7qSbnpG95OGYlGEQn+06uSiUMYnAqSL0Fi8OSZMUEefZ7ALkVliETx39FRblh
7KsJPAF47ED8oI9OmKbgHIANIaW/oz8ei9xIOspJNTTMqpo/YQ6K36XQFy5CoYg5mcw5wpmykThk
5h4/JgBBUqAhFD1FqPOFPMH7KqP7fPLjtY+3hfjTCH1ROnZyMKew2uAPV4jVN1zYlWT4CTGtbOW+
D/oHPGZbIWPNkM2kqZd40fnuURHdS/QRDqNacFgNnBXnW7V6N+9/swAAAAAAAA==

--Apple-Mail-67E1B4F5-B78F-4258-9310-358F7ACFD2EC--


From nobody Fri Oct 20 17:29:26 2017
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 5261013452E; Fri, 20 Oct 2017 17:24:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: adam@nostrum.com, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150854546532.20809.14299462426675273125.idtracker@ietfa.amsl.com>
Date: Fri, 20 Oct 2017 17:24:25 -0700
Archived-At: 
Subject: [rtcweb] rtcweb - Requested session has been scheduled for IETF 100
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-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, 21 Oct 2017 00:24:25 -0000

Dear Ted Hardie,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

rtcweb Session 1 (1:30:00)
    Wednesday, Afternoon Session II 1520-1650
    Room Name: Bras Basah size: 100
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Real-Time Communication in WEB-browsers
Area Name: Applications and Real-Time Area
Session Requester: Ted Hardie

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 70
Conflicts to Avoid: 
 First Priority: perc sipcore payload mmusic stir httpbis dispatch clue avtcore aqm rmcat tls quic
 Second Priority: tsvwg tsvarea ace uta netvc capport



People who must be present:
  Eric Rescorla
  Sean Turner
  Adam Roach
  Cullen Jennings
  Martin Thomson
  Richard Barnes
  Ted Hardie
  Justin Uberti
  Harald Alvestrand

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Tue Oct 24 12:59:01 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5499413F826 for ; Tue, 24 Oct 2017 12:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3e50HFjUlAA for ; Tue, 24 Oct 2017 12:58:58 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 E8624139602 for ; Tue, 24 Oct 2017 12:58:57 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id m189so27804283qke.4 for ; Tue, 24 Oct 2017 12:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=g6EBVZrFyXa98aGLOb3uN+8D/w5Dflfc1+dpQA9mvUI=; b=nYGhiNinyN+lRI+EblP+f7aSVM3s4QG8UpBss4pN1ihn+wkpweaFyh7niI2LfQirdP PNI9asM9XPOpotvcow4+LdDSItCw+l8yfUsll7e4AeL2cpKCnc5+cS+Q8haydhoWyono 5mvw0np1XGpOZPHLD4R73OBTGiDSYBDQtoS3E7scWEClkFksa33CtD/oBAhtHLfj/sE1 oPPkZAAC/Gp6+RFgnm7TU9/T7ZeawHVOiSdU5M2gvzyKwW0TyhqRNXV/JQCWaIRnSxTO wAf2S/bur2blbdxW00YK0aWEKCYMZKkiVcTS7uy4j6/UKE7UcDvnOc+fURnhzzxM8CJH XISQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=g6EBVZrFyXa98aGLOb3uN+8D/w5Dflfc1+dpQA9mvUI=; b=BV4mLNG04heOJsE0RDaV2uoTXQlzq60RCdKs+1IKaEop/z0Da25fWhzoV8VptWp9Y1 jrv05MwLZHjERqHdQDLl/gXsI4lX5zM5a5yHzWX/u7uJeyjTZObJL9fvpgk+021xL8Eh rgmDRv2Fonn2282TAeamJGvAu6YsuZtAr5fzy0kaIQbUbzrRUfJexk8grbuuk7sS5EPw M+lzmpwYRADpddEmaTaJ4lAPKOy43pHy6M5MsNMPQ7wyhZ8GHKELUYZEQhBAfTsWF81v eeLMjn4HtFPEfdKRT8uK6wGSLaEGmNpKjJPFSs3YTkYGnpY9aif5fGfHHBxsWMyIV8b1 4LhQ==
X-Gm-Message-State: AMCzsaVEwZDMEz5zTpbIrY8+XKlD/pa6LYiBwS5Fr+pXrnyksnawLyNR ouHAtc7VlYTw/hRBmCsm8lk6iPQIpaw=
X-Google-Smtp-Source: ABhQp+R2N8/P++tpTwgHHAKJ23r3q3wLDnDJ23VtkBghBeVVILmUwqfOC5jTjuTTfgOgodWBjr4//A==
X-Received: by 10.55.170.74 with SMTP id t71mr25653170qke.84.1508875136864; Tue, 24 Oct 2017 12:58:56 -0700 (PDT)
Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id g11sm699992qkb.58.2017.10.24.12.58.55 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:58:56 -0700 (PDT)
From: Jonathan Lennox 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3AD33538-CB84-4C5C-8156-983C1B79ED32"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>
Date: Tue, 24 Oct 2017 15:58:55 -0400
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [rtcweb] JSEP: codecs in answer: MUST vs. MAY
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 24 Oct 2017 19:58:59 -0000

--Apple-Mail=_3AD33538-CB84-4C5C-8156-983C1B79ED32
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

JSEP (section 5.3.1) seems to be inconsistent about how whether =
locally-supported codecs that weren=E2=80=99t listed in a remote offer =
MUST, or MAY, be included in an answer:

   o  If codec preferences have been set for the associated transceiver,
      media formats MUST be generated in the corresponding order,
      regardless of what was offered, and MUST exclude any codecs not
      present in the codec preferences.

   o  Otherwise, the media formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.

   o  In either case, the media formats in the answer MUST include at
      least one format that is present in the offer, but MAY include
      formats that are locally supported but not present in the offer,
      as mentioned in [RFC3264], Section=C2=A06.1 =
.  If no common format
      exists, the m=3D section is rejected as described above.

The first two paragraphs certainly seem to indicate that these codecs =
MUST be included in the answer; however, the third paragraph suddenly =
weakens this to a MAY.

Is the intent of the third paragraph simply to restate RFC 3264=E2=80=99s =
loose requirements, whereas the first two are JSEP=E2=80=99s more =
binding ones?  If so, I think this should be stated more clearly, =
otherwise the required behavior is unclear.=

--Apple-Mail=_3AD33538-CB84-4C5C-8156-983C1B79ED32
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


JSEP (section 5.3.1) seems to be inconsistent =
about how whether locally-supported codecs that weren=E2=80=99t listed =
in a remote offer MUST, or MAY, be included in an answer:

  =
 o  If codec preferences have been set for the associated transceiver,
      media formats MUST be generated in the corresponding order,
      regardless of what was offered, and MUST exclude any codecs not
      present in the codec preferences.

   o  Otherwise, the media formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.

   o  In either case, the media formats in the answer MUST include at
      least one format that is present in the offer, but MAY include
      formats that are locally supported but not present in the offer,
      as mentioned in [RFC3264], Section 6.1.  If no common format
      exists, the m=3D section is rejected as described above.

The first two =
paragraphs certainly seem to indicate that these codecs MUST be included =
in the answer; however, the third paragraph suddenly weakens this to a =
MAY.

Is the =
intent of the third paragraph simply to restate RFC 3264=E2=80=99s loose =
requirements, whereas the first two are JSEP=E2=80=99s more binding =
ones?  If so, I think this should be stated more clearly, otherwise =
the required behavior is unclear.
=

--Apple-Mail=_3AD33538-CB84-4C5C-8156-983C1B79ED32--


From nobody Tue Oct 24 13:37:29 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289FC13F529 for ; Tue, 24 Oct 2017 13:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9_PVho9abAt for ; Tue, 24 Oct 2017 13:37:26 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 9D70A1390EE for ; Tue, 24 Oct 2017 13:37:25 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id q83so27961438qke.6 for ; Tue, 24 Oct 2017 13:37:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lHSZGSdKqyyBykJiCaqqrje0zKySJmSmm21Zm6R/JJ4=; b=mJoGERlm+ad3IKnaNG1X5uZxI3H0DNoNwJO1O8f77STAD0BwwAINJVU72nG5g+zzzj t+gjgmHDVRK5W+ROVjPhS9EEav2+13IYCflcK3tho7prQ3C5RufIOo9x30bPFjeJQ5eZ wfnZyEnS/bOPbbh5ElLrnFjZO6/e3dCx2gbywYs+qVapdHtYvJVu/VcqpoiZ9B+o7BqN /564UjiwuG1WucoTCwzSiHojWMZtI8kdvh8UcSYM9/mcqdg19jeKMBo4F3k0qJ4HXQHP jMaOxQ4RUzww21CHYIIZSsHkb5GyFMWCyDJfUIGQz4w8Z7f9l1xx+hqnCgU5vhRc98n2 5B7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lHSZGSdKqyyBykJiCaqqrje0zKySJmSmm21Zm6R/JJ4=; b=s8gjgUk6ez86S2ZDKMKiJlpujsFd8fxD2MvyZDYcs3y0kGhInQ+0BdUVNRjsahYwPd zty8x4Q5AYOTq+BDuBtId5rhUt7Q9PDr1/1xToZBPNOwgcXmB0p3obBmADW8gReIPFlI KOrLaU0F4uMReED+JnydeSnHbeamsBVx/aUDuzcX4IlQh1dVpF4GgRBqE/jl0VmccHpY 5uIei9wnpA3aDOqufsIxsWc4cyx7zQWNrQj/edD+hi3lZ5+QcBX+n/htShIIfdNeUkYc 6geETGrikWt4/GX7F5PQh3a6IVcL2J7cOEap7nzMv5+gCzFy1/VpY3E8ztT23cWrPxdF /LNg==
X-Gm-Message-State: AMCzsaXct9wSEwXmNNqrbuaWliPqaeQ5ZtxN7/9wgJwziAb90BV4afDi /6VdzAmb+IHE3IvslsYmifm2p/K9Fq6kq/OHcdU=
X-Google-Smtp-Source: ABhQp+T5Ehofn4GGiuqWQODqJzMrOrFESjqqAaqX21V/alx3DR4C1uRlO9D3AB2qce3NCgTyLvc9K1Ftc7H/yYYWSsM=
X-Received: by 10.55.101.4 with SMTP id z4mr26000707qkb.114.1508877444544; Tue, 24 Oct 2017 13:37:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.40.68 with HTTP; Tue, 24 Oct 2017 13:36:54 -0700 (PDT)
In-Reply-To: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>
From: Ted Hardie 
Date: Tue, 24 Oct 2017 13:36:54 -0700
Message-ID: 
To: Jonathan Lennox 
Cc: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c05afde177d94055c50e8fd"
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: MUST vs. MAY
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 24 Oct 2017 20:37:28 -0000

--94eb2c05afde177d94055c50e8fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I read this slightly differently, see below.

On Tue, Oct 24, 2017 at 12:58 PM, Jonathan Lennox 
wrote:

> JSEP (section 5.3.1) seems to be inconsistent about how whether
> locally-supported codecs that weren=E2=80=99t listed in a remote offer MU=
ST, or
> MAY, be included in an answer:
>
>    o  If codec preferences have been set for the associated transceiver,
>       media formats MUST be generated in the corresponding order,
>       regardless of what was offered, and MUST exclude any codecs not
>       present in the codec preferences.
>
>
This is what you do if codec preferences are set (keep the order, and don't
add new ones)


>
>    o  Otherwise, the media formats on the m=3D line MUST be generated in
>       the same order as those offered in the current remote description,
>       excluding any currently unsupported formats.  Any currently
>       available media formats that are not present in the current remote
>       description MUST be added after all existing formats.
>
>
This is what you do if codec preferences are not set (keep the order, add
any new ones to the end)

>    o  In either case, the media formats in the answer MUST include at
>       least one format that is present in the offer, but MAY include
>       formats that are locally supported but not present in the offer,
>       as mentioned in [RFC3264], Section 6.1 .  If no common format
>       exists, the m=3D section is rejected as described above.
>
>
>
In either case, if you don't have at least one codec that matches, you
reject the m=3D section (don't add any new ones).

I think the MAY there from RFC 3264 permits the behavior in the  "if not
codec preferences are set" behavior branch, but doesn't require it, which
is why there can be a branch like the one where codec preferences are set
and they are not sent.


> The first two paragraphs certainly seem to indicate that these codecs MUS=
T
> be included in the answer; however, the third paragraph suddenly weakens
> this to a MAY.
>
> Is the intent of the third paragraph simply to restate RFC 3264=E2=80=99s=
 loose
> requirements, whereas the first two are JSEP=E2=80=99s more binding ones?=
  If so, I
> think this should be stated more clearly, otherwise the required behavior
> is unclear.
>
> _


So I don't personally see an inconsistency in this, but if you have other
language, please suggest it.  We're already in IESG evaluation, but it
might be a friendly amendment by Adam or someone else.

regards,

Ted


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

--94eb2c05afde177d94055c50e8fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I read this slightly differently, see below.

On Tue, Oct 24, 2017 at 12:=
58 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
JSEP (se=
ction 5.3.1) seems to be inconsistent about how whether locally-supported c=
odecs that weren=E2=80=99t listed in a remote offer MUST, or MAY, be includ=
ed in an answer:

   o  If codec preferences have been set for the associated tran=
sceiver,
      media formats MUST be generated in the corresponding order,
      regardless of what was offered, and MUST exclude any codecs not
      present in the codec preferences.
=

This is what you do if codec preferences are set (keep the o=
rder, and don't add new ones)
=C2=A0
   o  Otherwise, the media formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.


This is what you do if c=
odec preferences are not set (keep the order, add any new ones to the end)<=
br>
   o  In either case, the=
 media formats in the answer MUST include at
      least one format that is present in the offer, but MAY include
      formats that are locally supported but not present in the offer,
      as mentioned in [RFC3264], Section=C2=A06.1.  If no common for=
mat
      exists, the m=3D section is rejected as described above.

In either case, if you=
 don't have at least one codec that matches, you reject the m=3D sectio=
n (don't add any new ones). 

I think the MAY there fr=
om RFC 3264 permits the behavior in the=C2=A0 "if not codec preference=
s are set" behavior branch, but doesn't require it, which is why t=
here can be a branch like the one where codec preferences are set and they =
are not sent.
=C2=A0
The first two pa=
ragraphs certainly seem to indicate that these codecs MUST be included in t=
he answer; however, the third paragraph suddenly weakens this to a MAY.

Is the intent of the third paragraph simply to restat=
e RFC 3264=E2=80=99s loose requirements, whereas the first two are JSEP=E2=
=80=99s more binding ones?=C2=A0 If so, I think this should be stated more =
clearly, otherwise the required behavior is unclear.

_

So I don't personally see an inconsistency i=
n this, but if you have other language, please suggest it.=C2=A0 We're =
already in IESG evaluation, but it might be a friendly amendment by Adam or=
 someone else.

regards,

Ted
=C2=A0
_____________________________=
_________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--94eb2c05afde177d94055c50e8fd--


From nobody Tue Oct 24 14:15:37 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E434A13F850 for ; Tue, 24 Oct 2017 14:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKtt78as7lg7 for ; Tue, 24 Oct 2017 14:15:34 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C540413F84C for ; Tue, 24 Oct 2017 14:15:33 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id r196so1640222wmf.2 for ; Tue, 24 Oct 2017 14:15:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gPdFbKyBiC1YzjIbVSufZcYuOhQiVZuwdhSccRFPw3U=; b=nANDx9257qz84WfFA7ng1eFh6WNBXCtDog0RpPRbAOrH70iQHsoiVaVVOdEuKPwvO4 upb4tr6MYU+0j9CqBN25DhXR/MMgfa2zAwAHakLbGLojp5os4s7E3buL3M/WNQZh/ZM9 p+d8MAfSynco3/mmUrf7icxE8pR2q4s/fjNAeu0pyYEMVWt7QeBYXZqKvU4lqooaWwAp kfH9f7WAquZtT/ZYakFG1xmbXqML+cr5eUfey/mdLmygTtdgspnCRHnT7y2XddKWsX+U VqdsKodeybB3zopnJPM8QwQkWyb9NhjMT/b4pcUBeyPcNuxBqrblATo0ziCTyHBd+jSx 4WeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gPdFbKyBiC1YzjIbVSufZcYuOhQiVZuwdhSccRFPw3U=; b=sLR9Asy+PSSkHfSaAgC1a5N3k2wY59zwceZCLjDCJhV2GrpIVQqyaYo4QOqAdPL5Zj NbkjYnQJYnTI01Gq4dkbZTbNk6wsXP7ZOs5EqWKi9PeJZy1zOq3603QdyxlD1ZmH2o63 tqKGkkJEpY1ACBJGAzXURMlv5hwT4VCJMc66WLxAUXU8lWq1r5UG8o8F3YO5PpMFMFIi 34eSrNEy73SQ+f19fthXp9FhSpYbVVlDFsPmA3e0L+yoE1VJy6cO5550qCaqxp2AlHi8 x+Zeh2mQUe3epkqrac7SiQFzKjN/abj2BReAmyaZxzhUV4KA5gqkuZ/8aySFTbG22CC1 N38g==
X-Gm-Message-State: AMCzsaXBFpf+EB4BF8mrGmdHqVDO9PX4ya0JVfDwwpoxQLUoL64uGpKL XhQjig9Cw0JVxvryDvDgU4Id8oRUvqNP3O+FcQFzdAc97yE=
X-Google-Smtp-Source: ABhQp+RlynvLG5qgOnlamvryvJ60Wj7qxRJpMN3mT92adVN3R498l0eQVY/FcAaisUsFVQOxyLF4C8mzHOg2kGIfDKg=
X-Received: by 10.80.149.75 with SMTP id v11mr21685427eda.284.1508879732112; Tue, 24 Oct 2017 14:15:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 24 Oct 2017 14:15:11 -0700 (PDT)
In-Reply-To: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 24 Oct 2017 23:15:11 +0200
Message-ID: 
To: Jonathan Lennox 
Cc: "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: MUST vs. MAY
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 24 Oct 2017 21:15:36 -0000

I thought that one of the reasons for adopting SDP in WebRTC was that
it allows rapid implementation.
Are we still defining how codecs are negotiated? Is not even that
properly defined in the SDP O/A spec?

On 24 October 2017 at 21:58, Jonathan Lennox  wrote:
> JSEP (section 5.3.1) seems to be inconsistent about how whether
> locally-supported codecs that weren=E2=80=99t listed in a remote offer MU=
ST, or MAY,
> be included in an answer:
>
>    o  If codec preferences have been set for the associated transceiver,
>       media formats MUST be generated in the corresponding order,
>       regardless of what was offered, and MUST exclude any codecs not
>       present in the codec preferences.
>
>    o  Otherwise, the media formats on the m=3D line MUST be generated in
>       the same order as those offered in the current remote description,
>       excluding any currently unsupported formats.  Any currently
>       available media formats that are not present in the current remote
>       description MUST be added after all existing formats.
>
>    o  In either case, the media formats in the answer MUST include at
>       least one format that is present in the offer, but MAY include
>       formats that are locally supported but not present in the offer,
>       as mentioned in [RFC3264], Section 6.1.  If no common format
>       exists, the m=3D section is rejected as described above.
>
>
> The first two paragraphs certainly seem to indicate that these codecs MUS=
T
> be included in the answer; however, the third paragraph suddenly weakens
> this to a MAY.
>
> Is the intent of the third paragraph simply to restate RFC 3264=E2=80=99s=
 loose
> requirements, whereas the first two are JSEP=E2=80=99s more binding ones?=
  If so, I
> think this should be stated more clearly, otherwise the required behavior=
 is
> unclear.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--=20
I=C3=B1aki Baz Castillo



From nobody Tue Oct 24 21:48:18 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A11713B0F4 for ; Tue, 24 Oct 2017 21:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APBPdr_SQQ78 for ; Tue, 24 Oct 2017 21:48:14 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 0FDF413AC9E for ; Tue, 24 Oct 2017 21:48:14 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id n38so16897391uai.11 for ; Tue, 24 Oct 2017 21:48:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7n0Uas5utjNkPf8HpUwOljW96X/RnzdgnED8ZqhgXCE=; b=GD6Rns66BoFHsjMHb77TKlKPH0BmH605TId8hlXGEJvxdHawiDlYnbGEGpns+WPVW6 6MbkL4RYMAe6l23UAeD3+IJFxgNsacLRwPcsidZiDYGFIlKVp/B0GchmzCGCV49ycUD5 Fkke0PktBUbZwtv3itgQB9l5oBS/ipYMjFd2ULYvYjgdhzoJUgSuqK88oWzuDAgUOUWm 0xLkXu5+2+vPD+KL2M59n3UKGPvUb2QXqkwAglUtDn68kMu18XKGEGfA6AF0aiAeTzh/ X4LdcOCfQImDN+MJI58anF7ePmajmvn0wkQfdY6/LIWyVhh4ycIrSxOSF/DgPFBHXvRj juxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7n0Uas5utjNkPf8HpUwOljW96X/RnzdgnED8ZqhgXCE=; b=blZO0wA1OQoq+trqSJQT/TCtAXslgietYIiuuHYK1Dx5a2FM1QN6/23RJUd8XTAJhh OA0uMS1cud2OYbmMKHaO8N+6QgNe+tIxLKJub/zCseRTRasbBRxmORZPuEG/CuAyeJS/ ncQiQiiz0r+h16w6Y6jKt0qzybkGEE0pR1k/rihAWfd85XOpFVYxyd2chlSFvvpffV5e xZdUPcHop9HUxeO0Vs2Nv/1zauYm9+1+zyozsKt5MzovDxpuYvHYltafgMkzqMq6FScD 10iO4VDeCDamccciAUOGx7BBMlZ2j7fss8lft9Gi28sXqiJQQXx7O0uCnPzGuykTo+Rq plxA==
X-Gm-Message-State: AMCzsaV9NARbIEG/f89a809QIYwMUSPEibmjQKO0ukbP/Y/679a+9mOc ZE+ojb0yXL2q7ED1Bdw8z/E6jJhLTy0CQLE1XIV3nQ==
X-Google-Smtp-Source: ABhQp+QC20cYKQCgHNT2SrhbNkpWGKqRGa1+XaCpyXGF8FbnL4xS/n1AXAgH2mUwDRn6vsGA/UVx9NkMRjtuXsvW1rU=
X-Received: by 10.176.7.73 with SMTP id h67mr822770uah.109.1508906892828; Tue, 24 Oct 2017 21:48:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.174.215 with HTTP; Tue, 24 Oct 2017 21:47:52 -0700 (PDT)
In-Reply-To: 
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com> 
From: Justin Uberti 
Date: Tue, 24 Oct 2017 21:47:52 -0700
Message-ID: 
To: Ted Hardie 
Cc: Jonathan Lennox , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c123fe85910ba055c57c395"
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: MUST vs. MAY
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Oct 2017 04:48:16 -0000

--94eb2c123fe85910ba055c57c395
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ted's interpretation is correct - this text is intentionally reiterating
3264's point that it is permissible to respond with codecs that weren't
offered, as this has been a frequent misunderstanding.

One option to clarify this could be to replace the "MAY" with "is permitted
to".



On Tue, Oct 24, 2017 at 1:36 PM, Ted Hardie  wrote:

> I read this slightly differently, see below.
>
> On Tue, Oct 24, 2017 at 12:58 PM, Jonathan Lennox 
> wrote:
>
>> JSEP (section 5.3.1) seems to be inconsistent about how whether
>> locally-supported codecs that weren=E2=80=99t listed in a remote offer M=
UST, or
>> MAY, be included in an answer:
>>
>>    o  If codec preferences have been set for the associated transceiver,
>>       media formats MUST be generated in the corresponding order,
>>       regardless of what was offered, and MUST exclude any codecs not
>>       present in the codec preferences.
>>
>>
> This is what you do if codec preferences are set (keep the order, and
> don't add new ones)
>
>
>>    o  Otherwise, the media formats on the m=3D line MUST be generated in
>>       the same order as those offered in the current remote description,
>>       excluding any currently unsupported formats.  Any currently
>>       available media formats that are not present in the current remote
>>       description MUST be added after all existing formats.
>>
>>
> This is what you do if codec preferences are not set (keep the order, add
> any new ones to the end)
>
>>    o  In either case, the media formats in the answer MUST include at
>>       least one format that is present in the offer, but MAY include
>>       formats that are locally supported but not present in the offer,
>>       as mentioned in [RFC3264], Section 6.1 .  If no common format
>>       exists, the m=3D section is rejected as described above.
>>
>>
>>
> In either case, if you don't have at least one codec that matches, you
> reject the m=3D section (don't add any new ones).
>
> I think the MAY there from RFC 3264 permits the behavior in the  "if not
> codec preferences are set" behavior branch, but doesn't require it, which
> is why there can be a branch like the one where codec preferences are set
> and they are not sent.
>
>
>> The first two paragraphs certainly seem to indicate that these codecs
>> MUST be included in the answer; however, the third paragraph suddenly
>> weakens this to a MAY.
>>
>> Is the intent of the third paragraph simply to restate RFC 3264=E2=80=99=
s loose
>> requirements, whereas the first two are JSEP=E2=80=99s more binding ones=
?  If so, I
>> think this should be stated more clearly, otherwise the required behavio=
r
>> is unclear.
>>
>> _
>
>
> So I don't personally see an inconsistency in this, but if you have other
> language, please suggest it.  We're already in IESG evaluation, but it
> might be a friendly amendment by Adam or someone else.
>
> regards,
>
> Ted
>
>
>> ______________________________________________
>> 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
>
>

--94eb2c123fe85910ba055c57c395
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ted's interpretation is correct - this text is intenti=
onally reiterating 3264's point that it is permissible to respond with =
codecs that weren't offered, as this has been a frequent misunderstandi=
ng.

One option to clarify this could be to replace the &=
quot;MAY" with "is permitted to".


On Tue, Oct 24, 2017 at 1:36 PM, Ted Hardie <ted.ietf@gmail.com>=
 wrote:
I read th=
is slightly differently, see below.

On Tue, Oct 24, 2017 at 12:58 PM, Jo=
nathan Lennox <jonathan@vidyo.com> wrote:
JSEP (section 5.3=
.1) seems to be inconsistent about how whether locally-supported codecs tha=
t weren=E2=80=99t listed in a remote offer MUST, or MAY, be included in an =
answer:

   o  If codec preferences have been set for the asso=
ciated transceiver,
      media formats MUST be generated in the corresponding order,
      regardless of what was offered, and MUST exclude any codecs not
      present in the codec preferences.
=

This is what you do if codec preferences are set (kee=
p the order, and don't add new ones)
=C2=
=A0
   o =
 Otherwise, the media formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.


This is what you =
do if codec preferences are not set (keep the order, add any new ones to th=
e end)
   o  In either case, the media formats in the answer M=
UST include at
      least one format that is present in the offer, but MAY include
      formats that are locally supported but not present in the offer,
      as mentioned in [RFC3264], Section=C2=A06.1.  If no common for=
mat
      exists, the m=3D section is rejected as described above.

In either case,=
 if you don't have at least one codec that matches, you reject the m=3D=
 section (don't add any new ones). 

I think the MAY t=
here from RFC 3264 permits the behavior in the=C2=A0 "if not codec pre=
ferences are set" behavior branch, but doesn't require it, which i=
s why there can be a branch like the one where codec preferences are set an=
d they are not sent.
=C2=A0
The first two paragraphs certainly seem to indicate that these code=
cs MUST be included in the answer; however, the third paragraph suddenly we=
akens this to a MAY.

Is the intent of the third pa=
ragraph simply to restate RFC 3264=E2=80=99s loose requirements, whereas th=
e first two are JSEP=E2=80=99s more binding ones?=C2=A0 If so, I think this=
 should be stated more clearly, otherwise the required behavior is unclear.=


_

So I don't per=
sonally see an inconsistency in this, but if you have other language, pleas=
e suggest it.=C2=A0 We're already in IESG evaluation, but it might be a=
 friendly amendment by Adam or someone else.

regards,
=

Ted
=C2=A0
______________________________________________

rtcweb mailing list

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




_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--94eb2c123fe85910ba055c57c395--


From nobody Wed Oct 25 09:27:15 2017
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 3C009138AED; Wed, 25 Oct 2017 09:27:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150894882819.4846.5066483655730613021@ietfa.amsl.com>
Date: Wed, 25 Oct 2017 09:27:08 -0700
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-08.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Oct 2017 16:27: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 WG of the IETF.

        Title           : Annotated Example SDP for WebRTC
        Authors         : Suhas Nandakumar
                          Cullen Jennings
	Filename        : draft-ietf-rtcweb-sdp-08.txt
	Pages           : 107
	Date            : 2017-10-25

Abstract:
   The Real-Time Communications in WEB-browsers (Rtcweb) working group
   is charged to provide protocol support for direct interactive rich
   communication using audio, video and data between two peers' web
   browsers.  With in the Rtcweb framework, Session Description protocol
   (SDP) is used for negotiating session capabilities between the peers.
   Such a negotiation happens based on the SDP Offer/Answer exchange
   mechanism.

   This document provides an informational reference in describing the
   role of SDP and the Offer/Answer exchange mechanism for the most
   common Rtcweb use-cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-08
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Oct 25 22:09:17 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55BA13A5BC for ; Wed, 25 Oct 2017 22:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFaOlhqW_6Zw for ; Wed, 25 Oct 2017 22:09:13 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 ACAE91393A8 for ; Wed, 25 Oct 2017 22:09:13 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id n38so1603200uai.11 for ; Wed, 25 Oct 2017 22:09:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=OUNQjp9QBGsgu+ZXljiINSZrIuwB2hIlg07MEegvNOw=; b=Aq0BfEi7Q853C04oCFkvMWjChhkKe8//tB0d0lhyh8+pZWUZm0tf8yIhZttOzmZ61p LEJovt17OyuU5tFtLC2Mu3KNmV8ZLx0wIv43Ux3P12Lti0xK1mVJI9m7bdmgfUXJ1kxA jv4A7SLdfPc43NEXSJdNfwcio9IStYR/bI0WTOYMQ39SiV7AGfpiY4GoioUjSJ5plJfd pKRW0WiymWAApa6VBMlc7PX4IXj4cWXGtGueu6ihnzYmPWGUIxr1NKLDqKAcCN4QGM0C UZv9gV+QPUGY2nKJDP28aih0fFcJrtxsUqWUheKj3/yIa5/N+5K+DqTlOg3vlX3Yh9gD o3Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OUNQjp9QBGsgu+ZXljiINSZrIuwB2hIlg07MEegvNOw=; b=XMw1PaeJnk/MRS98WDMZ1ttzbPnNzrU1Fce3Hmn67sP4FJMqna7IjtWkqRpmLPpj6O 0GY2n4btYEjxY8Nop5sJqMt8rkh9rmaGcCws+oyZJp3owIEcBn1cNVG6IcAUF4qPDda6 tlqyRpJNEaRB5cjA/LHf33JIvhLUOBuhDLPcL7YSYNM2/PGIsHMCl7rhgitqf1qHJzXj XGThiIlsMSZ6xwIV0Lo7A/Y7OXGZMxu5cd4WddP3WYGvreN3tfDchmx18FzDQazVB0Sd 3gdhgMepzjvQST26tz4v5N5eLDGvA/DUGo+vfay/dpwmQ5xevXu2a3KeAUAo925KU1US MuQQ==
X-Gm-Message-State: AMCzsaXp5oZqvDFtaGYJvD8fkjY3sdpQphngC8EIPe6a8/vdNIWdVPNL rwpvtHfUKWXmqRVGjIsHKsWnfse2zSYrjmxIsX4=
X-Google-Smtp-Source: ABhQp+ThNKIkFVNmQXRuYAtkqRis7Ww89sC2lZlv1Z9bzZ0/wznDksRaHvQXqkWPLm5mM/Ur5h/baNA2mAbPwxKL6eg=
X-Received: by 10.176.74.211 with SMTP id t19mr3618679uae.83.1508994552662; Wed, 25 Oct 2017 22:09:12 -0700 (PDT)
MIME-Version: 1.0
References: <150894882819.4846.5066483655730613021@ietfa.amsl.com>
In-Reply-To: <150894882819.4846.5066483655730613021@ietfa.amsl.com>
From: Suhas Nandakumar 
Date: Thu, 26 Oct 2017 05:09:02 +0000
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045f8af2478cfc055c6c2cd0"
Archived-At: 
Subject: [rtcweb] Fwd:  I-D Action: draft-ietf-rtcweb-sdp-08.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 26 Oct 2017 05:09:16 -0000

--f403045f8af2478cfc055c6c2cd0
Content-Type: text/plain; charset="UTF-8"

Hello all

This version incorporates review from Nils

Thanks
Suhas

---------- Forwarded message ---------
From: 
Date: Wed, Oct 25, 2017 at 9:27 AM
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-08.txt
To: 
CC: 



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 WG
of the IETF.

        Title           : Annotated Example SDP for WebRTC
        Authors         : Suhas Nandakumar
                          Cullen Jennings
        Filename        : draft-ietf-rtcweb-sdp-08.txt
        Pages           : 107
        Date            : 2017-10-25

Abstract:
   The Real-Time Communications in WEB-browsers (Rtcweb) working group
   is charged to provide protocol support for direct interactive rich
   communication using audio, video and data between two peers' web
   browsers.  With in the Rtcweb framework, Session Description protocol
   (SDP) is used for negotiating session capabilities between the peers.
   Such a negotiation happens based on the SDP Offer/Answer exchange
   mechanism.

   This document provides an informational reference in describing the
   role of SDP and the Offer/Answer exchange mechanism for the most
   common Rtcweb use-cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-08
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--f403045f8af2478cfc055c6c2cd0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello all

This version incorporates review from Nils

Thanks
Suhas

<=
div class=3D"gmail_quote">
---------- Forwarded message ---------
Fr=
om:  <internet-drafts@ietf.o=
rg>
Date: Wed, Oct 25, 2017 at 9:27 AM
Subject: [rtcweb] I-D A=
ction: draft-ietf-rtcweb-sdp-08.txt
To:  <i-d-announce@ietf.org>
CC:  <rtcweb@ietf.org>




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Real-Time Communication in WEB-browsers WG=
 of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Annotated Example SDP for WebRTC

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Suha=
s Nandakumar

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Cullen Jennings

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-rtcweb-sdp-08.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 107

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-10-25



Abstract:

=C2=A0 =C2=A0The Real-Time Communications in WEB-browsers (Rtcweb) working =
group

=C2=A0 =C2=A0is charged to provide protocol support for direct interactive =
rich

=C2=A0 =C2=A0communication using audio, video and data between two peers=
9; web

=C2=A0 =C2=A0browsers.=C2=A0 With in the Rtcweb framework, Session Descript=
ion protocol

=C2=A0 =C2=A0(SDP) is used for negotiating session capabilities between the=
 peers.

=C2=A0 =C2=A0Such a negotiation happens based on the SDP Offer/Answer excha=
nge

=C2=A0 =C2=A0mechanism.



=C2=A0 =C2=A0This document provides an informational reference in describin=
g the

=C2=A0 =C2=A0role of SDP and the Offer/Answer exchange mechanism for the mo=
st

=C2=A0 =C2=A0common Rtcweb use-cases.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-r=
tcweb-sdp/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-rtcweb-sd=
p-08

https://datatracker.ietf.org/doc/html/=
draft-ietf-rtcweb-sdp-08



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddraf=
t-ietf-rtcweb-sdp-08





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

rtcweb mailing list

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




--f403045f8af2478cfc055c6c2cd0--


From nobody Fri Oct 27 10:14:39 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433CF13B2BB for ; Fri, 27 Oct 2017 10:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PLRij2v7O-r for ; Fri, 27 Oct 2017 10:14:36 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 5C8181384B5 for ; Fri, 27 Oct 2017 10:14:36 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id q83so9179232qke.6 for ; Fri, 27 Oct 2017 10:14:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Tb82Z/QzPWVChS5Ly4NxYaltJZRLfccaHSHGCNXsr7Q=; b=BZ5DWpjOnX11ctS60g3o4I0CNBVfYiMH+0xkgiZgcWjFP3tFsQZ1WP5Ph/IeOiKfPD Z1MWd3Q+N64s/spP8PLUjPe56y144u7SECXcL7oiLq3muoSXGkq4BkyWfYVcy0XgWDNO ou0sZuw/lwD2UhdECfhTS9uyvqg9nRAnUnsvfrZB/sEOP+O2whc4/PYDYfu7EBF7htv9 sV2I5vd35ZPtXNsdqCJzCSeybOSkg/ZehEFMD6t0r7a0+e89V48D8/imVFqxPRSY8c0W gZ676YigdC5hLbEECbkXYHFHdopTnypLyBRBajeZ1xKA/E+9WNdPqalalqn2M51NN+nS BZKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Tb82Z/QzPWVChS5Ly4NxYaltJZRLfccaHSHGCNXsr7Q=; b=Twha/W8A/iRSGb+Uc1Cr7G+Z4aXhhJjzMKGmGlaURiCehileDBe8aepcgPWLrJKiuZ YxhtlaFHaw923gP7mzlUoWtA/IevBI52nCZL7qGnm8bXQ4bv0rQ3QlsmVN4w9zEIRLwh nWvwhzVJSmhwRaJ5Vzge0SlidVIqXuivdRDALiBKwcoImM/2bf/D+jbKNJ1AOaJAqGuN 2MgjTDyHiiZJ3F+ZJyrungyYg+XHeSBHAHsz0RL/1J7/XxRgQHeorLzmU+vlWYthM1PS U5hYqLODOZHglH6EQnjWViqUgxm0i3zawO4iFK+rSTB1OH8tl/R9rrGreOcU8kGeGY0f FDFQ==
X-Gm-Message-State: AMCzsaVRaBK+OFs0T0R9i3uUjknHysOp0gLR5tMh8t6b5pSJDDkvgp/s E2Ng0r7P1h9Te0gORatt97ZPFA==
X-Google-Smtp-Source: ABhQp+TszeigynmdsmrZo0WDd8GHYIIZBy6YkWGr7rtib/BPrW1AcyBcHxwr48y+2AhuXPWlHr6PTg==
X-Received: by 10.55.157.78 with SMTP id g75mr1747692qke.347.1509124475520; Fri, 27 Oct 2017 10:14:35 -0700 (PDT)
Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id b26sm5472367qtc.39.2017.10.27.10.14.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Oct 2017 10:14:34 -0700 (PDT)
From: Jonathan Lennox 
Message-Id: <2CFCA859-B941-4AFF-B80A-792509EED6F5@vidyo.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3EEB844B-26B7-4461-837E-C60E1F2B2A60"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 27 Oct 2017 13:14:33 -0400
In-Reply-To: 
Cc: Ted Hardie , "rtcweb@ietf.org" 
To: Justin Uberti 
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: MUST vs. MAY
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 27 Oct 2017 17:14:38 -0000

--Apple-Mail=_3EEB844B-26B7-4461-837E-C60E1F2B2A60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Oct 25, 2017, at 12:47 AM, Justin Uberti  =
wrote:
>=20
> Ted's interpretation is correct - this text is intentionally =
reiterating 3264's point that it is permissible to respond with codecs =
that weren't offered, as this has been a frequent misunderstanding.

Okay, good, that=E2=80=99s what I hoped; but this is mixing up normative =
text (MUST reject if no common codec) with informative, which is =
confusing.

> One option to clarify this could be to replace the "MAY" with "is =
permitted to=E2=80=9D.

I would go further than this, clearly distinguishing the normative text =
from the informative. Perhaps:

In either case, the media formats in the answer MUST include at least =
one format that is present in the offer.  If no common format exists, =
the m=3D section is rejected as described above.
(Note that in SDP offer/answer, an answer is permitted to include =
formats that are locally supported but not present in the offer, as =
mentioned in [RFC3264], Section 6.1.  As described in the preceding =
paragraphs, in JSEP including these formats is mandatory.)


> On Tue, Oct 24, 2017 at 1:36 PM, Ted Hardie > wrote:
> I read this slightly differently, see below.
>=20
> On Tue, Oct 24, 2017 at 12:58 PM, Jonathan Lennox > wrote:
> JSEP (section 5.3.1) seems to be inconsistent about how whether =
locally-supported codecs that weren=E2=80=99t listed in a remote offer =
MUST, or MAY, be included in an answer:
>=20
>    o  If codec preferences have been set for the associated =
transceiver,
>       media formats MUST be generated in the corresponding order,
>       regardless of what was offered, and MUST exclude any codecs not
>       present in the codec preferences.
>=20
> This is what you do if codec preferences are set (keep the order, and =
don't add new ones)
> =20
>    o  Otherwise, the media formats on the m=3D line MUST be generated =
in
>       the same order as those offered in the current remote =
description,
>       excluding any currently unsupported formats.  Any currently
>       available media formats that are not present in the current =
remote
>       description MUST be added after all existing formats.
>=20
> This is what you do if codec preferences are not set (keep the order, =
add any new ones to the end)
>    o  In either case, the media formats in the answer MUST include at
>       least one format that is present in the offer, but MAY include
>       formats that are locally supported but not present in the offer,
>       as mentioned in [RFC3264], Section=C2=A06.1 =
.  If no common format
>       exists, the m=3D section is rejected as described above.
>=20
>=20
> In either case, if you don't have at least one codec that matches, you =
reject the m=3D section (don't add any new ones).=20
>=20
> I think the MAY there from RFC 3264 permits the behavior in the  "if =
not codec preferences are set" behavior branch, but doesn't require it, =
which is why there can be a branch like the one where codec preferences =
are set and they are not sent.
> =20
> The first two paragraphs certainly seem to indicate that these codecs =
MUST be included in the answer; however, the third paragraph suddenly =
weakens this to a MAY.
>=20
> Is the intent of the third paragraph simply to restate RFC 3264=E2=80=99=
s loose requirements, whereas the first two are JSEP=E2=80=99s more =
binding ones?  If so, I think this should be stated more clearly, =
otherwise the required behavior is unclear.
>=20
> _
>=20
> So I don't personally see an inconsistency in this, but if you have =
other language, please suggest it.  We're already in IESG evaluation, =
but it might be a friendly amendment by Adam or someone else.
>=20
> regards,
>=20
> Ted
> =20
> ______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org 
> https://www.ietf.org/mailman/listinfo/rtcweb =

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

>=20
>=20


--Apple-Mail=_3EEB844B-26B7-4461-837E-C60E1F2B2A60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Oct 25, 2017, at 12:47 AM, Justin Uberti <juberti@google.com> =
wrote:

Ted's interpretation is correct - this text is =
intentionally reiterating 3264's point that it is permissible to respond =
with codecs that weren't offered, as this has been a frequent =
misunderstanding.

Okay, =
good, that=E2=80=99s what I hoped; but this is mixing up normative text =
(MUST reject if no common codec) with informative, which is =
confusing.

One=
 option to clarify this could be to replace the "MAY" with "is permitted =
to=E2=80=9D.

I would go further than this, clearly =
distinguishing the normative text from the informative. =
Perhaps:

In either =
case, the media formats in the answer MUST include at least one format =
that is present in the offer.  If no common format exists, the m=3D =
section is rejected as described above.
(Note that =
in SDP offer/answer, an answer is permitted to include formats that are =
locally supported but not present in the offer, as mentioned in =
[RFC3264], Section 6.1.  As described in the preceding paragraphs, =
in JSEP including these formats is mandatory.)


On Tue, Oct 24, 2017 =
at 1:36 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
I read this slightly differently, see below.

On Tue, Oct 24, 2017 at 12:58 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
JSEP (section =
5.3.1) seems to be inconsistent about how whether locally-supported =
codecs that weren=E2=80=99t listed in a remote offer MUST, or MAY, be =
included in an answer:

   o  If =
codec preferences have been set for the associated transceiver,
      media formats MUST be generated in the corresponding order,
      regardless of what was offered, and MUST exclude any codecs not
      present in the codec =
preferences.

This is what you do if codec =
preferences are set (keep the order, and don't add new ones)
 
   o  =
Otherwise, the media formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.


This is what you do if codec =
preferences are not set (keep the order, add any new ones to the end)
   o  In =
either case, the media formats in the answer MUST include at
      least one format that is present in the offer, but MAY include
      formats that are locally supported but not present in the offer,
      as mentioned in [RFC3264], Section 6.1.  If no common format
      exists, the m=3D section is rejected as described above.


In either case, =
if you don't have at least one codec that matches, you reject the m=3D =
section (don't add any new ones). 

I think the MAY there from RFC 3264 permits the behavior in =
the  "if not codec preferences are set" behavior branch, but =
doesn't require it, which is why there can be a branch like the one =
where codec preferences are set and they are not sent.
 
The first two paragraphs =
certainly seem to indicate that these codecs MUST be included in the =
answer; however, the third paragraph suddenly weakens this to a =
MAY.

Is the =
intent of the third paragraph simply to restate RFC 3264=E2=80=99s loose =
requirements, whereas the first two are JSEP=E2=80=99s more binding =
ones?  If so, I think this should be stated more clearly, otherwise =
the required behavior is unclear.

_

So I don't personally see an inconsistency in this, but if =
you have other language, please suggest it.  We're already in IESG =
evaluation, but it might be a friendly amendment by Adam or someone =
else.

regards,

Ted
 
______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb





=

--Apple-Mail=_3EEB844B-26B7-4461-837E-C60E1F2B2A60--


From nobody Fri Oct 27 13:05:18 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B7C13F445 for ; Fri, 27 Oct 2017 13:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqWx65lY4wCt for ; Fri, 27 Oct 2017 13:05:16 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 49D8213F43F for ; Fri, 27 Oct 2017 13:05:16 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id n5so9730794qke.11 for ; Fri, 27 Oct 2017 13:05:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=7Vo4gsAsZKC/Fbx44G3wV1fUxXQQM7rU8t2GhJmpQSg=; b=WOucHpdrfRZzw4va6OD5eyanyhhuC9kD3VXqOcu9kxElhh2oycqHMqYOJ4tCkrAlIS xVBVc6OXQyEuPSgXio9iFAGOo9k8r+ZNFsG4o29O93HBU/FewFhQL/p9XDOQqsLGRR1H 5AGm0BSl1lXq178+U/KLwwTP0A3YXeqxdQin2y2g+kxwxY02CKstyNJA4a0b76q6PLN6 F1vXPQZIYo+7OdIyRc9bmDsSqZDnEvt64URZn+jCpGnkvz7My7Om+ndbrjp1FhYWiJ5+ y5k2DwNzpW+NelBb10yO5O24hVeLVWz/2LFnoU8e8IkCQl+eSd8SdW9X5Q3BsBi4Kf8L teRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7Vo4gsAsZKC/Fbx44G3wV1fUxXQQM7rU8t2GhJmpQSg=; b=tgpqF02d0eve0qXO20zVxqWkPBqK/GOCuAkrv80q7y3GFycNm9tPO/lO+a0boZ271F Jn+rdHcmTUlY5+CpkR1nAZiKN8RHWvXwnAu7GNEnMyVNCGrFfsl93YrC7envDAGsVppx Zat5TmZei+W35ALQBhdOT8HQCPEoGlizqkVHs6MlOVZCCcOTPU+UBdmaq086Auxxb/y+ XFMXKlYwwyvDaJPKRmd40ZamZfqAlBhvF2vUiipE6/I+4zsHava8cabdtKoucjUhQudG b4bf8tFuJ1o+UvJu9rcZb1bQi7G7HExSnTMtSksd6WSYdyZiCvhgy5zNdZhi+WvqdZFW NPlw==
X-Gm-Message-State: AMCzsaXtFKAAMiHDz5mL/ZcXhTmSSgEVfIzy4vOt5ohTDkvwSfyQpisd yPJ1yGkaa7KwMcId6JrQbz0F/A==
X-Google-Smtp-Source: ABhQp+S3NrJYdBoJAVzVZxVnHcB2Bma4hNNS/TaaXz/D+0JVsOtUcF7Ki8E1R7OZ7umGsvVBsrWGsw==
X-Received: by 10.55.27.136 with SMTP id m8mr2610669qkh.356.1509134715329; Fri, 27 Oct 2017 13:05:15 -0700 (PDT)
Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id o70sm5609657qki.35.2017.10.27.13.05.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Oct 2017 13:05:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2C18E05B-98AB-47B0-B97B-F9C54BFDD655"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jonathan Lennox 
In-Reply-To: <2CFCA859-B941-4AFF-B80A-792509EED6F5@vidyo.com>
Date: Fri, 27 Oct 2017 16:05:13 -0400
Cc: Ted Hardie , "rtcweb@ietf.org" 
Message-Id: <7CA6CF4C-6A92-4198-B2E6-10FB5EC6EA5D@vidyo.com>
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>   <2CFCA859-B941-4AFF-B80A-792509EED6F5@vidyo.com>
To: Justin Uberti 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: ordering (was codecs in answer: MUST vs. MAY)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 27 Oct 2017 20:05:17 -0000

--Apple-Mail=_2C18E05B-98AB-47B0-B97B-F9C54BFDD655
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Another question about JSEP=E2=80=99s codec answer rules.

The spec currently says:
>>    o  Otherwise, the media formats on the m=3D line MUST be generated =
in
>>       the same order as those offered in the current remote =
description,
>>       excluding any currently unsupported formats.  Any currently
>>       available media formats that are not present in the current =
remote
>>       description MUST be added after all existing formats.
>>=20
>> This is what you do if codec preferences are not set (keep the order, =
add any new ones to the end)

Why are remotely-unsupported codecs added at the end of the list, rather =
than just listing all locally-supported codecs in the browser=E2=80=99s =
preference order?

My concern is in an SFU conferencing scenario.  Consider the following:

* Participant 1 joins a conference.  It supports only codec A.
* Participant 2 joins the conference.  It supports codecs A and B, but =
prefers B.  Since the conference can only do A, if the offer/answer =
exchange goes SFU->Participant, the participant=E2=80=99s answer must =
list its codecs as A, B.
* Participant 3 joins the conference.  It is the same as Participant 2, =
preferring B to A.

If participant 1 leaves, the SFU can re-offer to participants 2 and 3; =
but as far as it knows, everyone prefers A to B, so the conference can =
end up in a scenario where everyone=E2=80=99s using a less-preferred =
codec.

I would suggest that instead, the browser=E2=80=99s codec preference =
order always be sent as-is in an answer (unless overridden by the app =
with setCodecPreferences).  This also has the benefit of aligning the =
behavior with and without app codec preferences, rather than having two =
separate behaviors (where the order is fixed if the app has set codec =
preferences, and mirrored otherwise).=

--Apple-Mail=_2C18E05B-98AB-47B0-B97B-F9C54BFDD655
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Another question about JSEP=E2=80=99s codec answer =
rules.

The spec currently =
says:
   o  =
Otherwise, the media formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.


This is what you do if codec =
preferences are not set (keep the order, add any new ones to the =
end)

Why are =
remotely-unsupported codecs added at the end of the list, rather than =
just listing all locally-supported codecs in the browser=E2=80=99s =
preference order?

My concern is in =
an SFU conferencing scenario.  Consider the =
following:

* Participant 1 joins a =
conference.  It supports only codec A.
* Participant 2 =
joins the conference.  It supports codecs A and B, but prefers B. =
 Since the conference can only do A, if the offer/answer exchange =
goes SFU->Participant, the participant=E2=80=99s answer must list its =
codecs as A, B.
* Participant 3 joins the conference.  It =
is the same as Participant 2, preferring B to A.

If participant 1 leaves, the SFU can re-offer to =
participants 2 and 3; but as far as it knows, everyone prefers A to B, =
so the conference can end up in a scenario where everyone=E2=80=99s =
using a less-preferred codec.

I =
would suggest that instead, the browser=E2=80=99s codec preference order =
always be sent as-is in an answer (unless overridden by the app with =
setCodecPreferences).  This also has the benefit of aligning the =
behavior with and without app codec preferences, rather than having two =
separate behaviors (where the order is fixed if the app has set codec =
preferences, and mirrored otherwise).
=

--Apple-Mail=_2C18E05B-98AB-47B0-B97B-F9C54BFDD655--


From nobody Fri Oct 27 14:15:24 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BF913F5D5 for ; Fri, 27 Oct 2017 14:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IglKVplTa0Se for ; Fri, 27 Oct 2017 14:15:21 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 A399813F5A9 for ; Fri, 27 Oct 2017 14:15:21 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id w134so9956238qkb.0 for ; Fri, 27 Oct 2017 14:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TYDyWhWDVoL0dZqg6NUvhShdOd6R5/jcjFDFfm54zJU=; b=GEnn6i7m567Slpe1cooEWIP5o9ouzi1zLlXIdLzSOxqxUV1nqe7KvpDlUDWunFoBfS mzWbrhOERW0e0jTli7AjCGE3NbS2m2vbbLk/klsQBplq1yn1nctLDWrsuqQF7WQO1oLy A8CDBEtq8M2kpUPFeR8V7Oh6QCWPAJwU1QDW/u4KfnyxT8Yt2j/ALEtnzNiEoCfQI6Wp oPSqUcNsTwLVYmKnJ0bVgzCJl5PnYcaEHbGX0s5xL0IDKYMByQyfhdcphCZa38WOmFxE Cb1DPHH6RT1N/a972Xk4J6leQXa/QLxADnG+ft0zIG2FQnEsL2OsoH7xPOMI/7nBydC9 WLNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TYDyWhWDVoL0dZqg6NUvhShdOd6R5/jcjFDFfm54zJU=; b=R9UUaZg8cMJYuH7KOLTjdovHvIp7lpa5SM8R0NY0423TqOKxKrPjal8cvnrsWX6DNj RIhEcVTBT0cj5lvUxgBM330m4RkJbDvjvzvcDw7FJl/uNiHdYSm9tr5LYuzwOY8L1WIc CzeeSXPEyhqnp+nupBpALkOZqjdLRsuIwSIj0ACLB5YTuAjsdSLxLyfK0EFX7edYhZKN UrU8+FTj41xe/zwpgkB5K6AUoU1EJxwcX2ykjfXEALCvSUCnXM5CgaSRIoTK/1IOGBU0 7tdVrEQqRHFfowW+5gGAXpO12fAJ9EoQd7E+lMcEUgh/yYrbVmDp30Fjz8MKxm+0l1lB rHMA==
X-Gm-Message-State: AMCzsaVOhZrJds28qqiOmFJqJ/gZKtUsldMVJ6YlyZiyKkZ+qsrA3pA1 OKPmdG+Zg/1TBAodcZIG+VgXMPPCV3Oy1RFBKsA=
X-Google-Smtp-Source: ABhQp+RFvCBJr/A93vEvJfjwsL8LzqZJCtJe7SVIDcHEqpIbVls1uxAuPMLmqAGteMgVvvETFt62MlNwuEdOcuu4qKA=
X-Received: by 10.55.159.4 with SMTP id i4mr2825167qke.339.1509138920601; Fri, 27 Oct 2017 14:15:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.40.68 with HTTP; Fri, 27 Oct 2017 14:14:50 -0700 (PDT)
In-Reply-To: <7CA6CF4C-6A92-4198-B2E6-10FB5EC6EA5D@vidyo.com>
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>   <2CFCA859-B941-4AFF-B80A-792509EED6F5@vidyo.com> <7CA6CF4C-6A92-4198-B2E6-10FB5EC6EA5D@vidyo.com>
From: Ted Hardie 
Date: Fri, 27 Oct 2017 14:14:50 -0700
Message-ID: 
To: Jonathan Lennox 
Cc: Justin Uberti , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c06f162477f6f055c8dc928"
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: ordering (was codecs in answer: MUST vs. MAY)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 27 Oct 2017 21:15:23 -0000

--94eb2c06f162477f6f055c8dc928
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

On Fri, Oct 27, 2017 at 1:05 PM, Jonathan Lennox  wrote=
:

> Another question about JSEP=E2=80=99s codec answer rules.
>
> The spec currently says:
>
>    o  Otherwise, the media formats on the m=3D line MUST be generated in
>>>       the same order as those offered in the current remote description=
,
>>>       excluding any currently unsupported formats.  Any currently
>>>       available media formats that are not present in the current remot=
e
>>>       description MUST be added after all existing formats.
>>>
>>>
>> This is what you do if codec preferences are not set (keep the order, ad=
d
>> any new ones to the end)
>>
>
> Why are remotely-unsupported codecs added at the end of the list, rather
> than just listing all locally-supported codecs in the browser=E2=80=99s p=
reference
> order?
>
> My concern is in an SFU conferencing scenario.  Consider the following:
>
> * Participant 1 joins a conference.  It supports only codec A.
> * Participant 2 joins the conference.  It supports codecs A and B, but
> prefers B.  Since the conference can only do A, if the offer/answer
> exchange goes SFU->Participant, the participant=E2=80=99s answer must lis=
t its
> codecs as A, B.
> * Participant 3 joins the conference.  It is the same as Participant 2,
> preferring B to A.
>
> If participant 1 leaves, the SFU can re-offer to participants 2 and 3; bu=
t
> as far as it knows, everyone prefers A to B, so the conference can end up
> in a scenario where everyone=E2=80=99s using a less-preferred codec.
>
>
>
I would suggest that instead, the browser=E2=80=99s codec preference order =
always
> be sent as-is in an answer (unless overridden by the app with
> setCodecPreferences).  This also has the benefit of aligning the behavior
> with and without app codec preferences, rather than having two separate
> behaviors (where the order is fixed if the app has set codec preferences,
> and mirrored otherwise).
>

So, we're currently past WG last call and IETF last call, with the draft in
IESG evaluation.  This proposal appears to change a method that has been
agreed through all of those process and which produces a correct answer.
While it may bee mildly suboptimal for the duration of the conference in
the case above, it works and simplifies the conference behavior by
presuming no re-offer occurs until a participant 4 arrives who does only B
(If participant 1 has left, the conference can then re-offer codec B to 2
and 3).

While I appreciate the care you're going through with this, I don't believe
that this trade-off rises to the level of concern that would warrant
re-opening the question.

regards,

Ted

--94eb2c06f162477f6f055c8dc928
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Jonathan, 

On Fri, Oct 27, 2017 at 1:05 PM, Jonathan Lennox <jonath=
an@vidyo.com> wrote:
Another question about JSEP=E2=80=99s co=
dec answer rules.

The spec currently says:
=

<=
div style=3D"word-wrap:break-word">
   o  Otherwise, the medi=
a formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.


This is what you =
do if codec preferences are not set (keep the order, add any new ones to th=
e end)
<=
/div>

Why are remotely-unsupported c=
odecs added at the end of the list, rather than just listing all locally-su=
pported codecs in the browser=E2=80=99s preference order?

My concern is in an SFU conferencing scenario.=C2=A0 Consider the f=
ollowing:

* Participant 1 joins a conference.=C2=
=A0 It supports only codec A.
* Participant 2 joins the conferenc=
e.=C2=A0 It supports codecs A and B, but prefers B.=C2=A0 Since the confere=
nce can only do A, if the offer/answer exchange goes SFU->Participant, t=
he participant=E2=80=99s answer must list its codecs as A, B.
* P=
articipant 3 joins the conference.=C2=A0 It is the same as Participant 2, p=
referring B to A.

If participant 1 leaves, the SFU=
 can re-offer to participants 2 and 3; but as far as it knows, everyone pre=
fers A to B, so the conference can end up in a scenario where everyone=E2=
=80=99s using a less-preferred codec.

=C2=A0
=

I would suggest that instead, the browser=E2=80=99s codec p=
reference order always be sent as-is in an answer (unless overridden by the=
 app with setCodecPreferences).=C2=A0 This also has the benefit of aligning=
 the behavior with and without app codec preferences, rather than having tw=
o separate behaviors (where the order is fixed if the app has set codec pre=
ferences, and mirrored otherwise).

=

So, we're currently past WG last call and IE=
TF last call, with the draft in IESG evaluation.=C2=A0 This proposal appear=
s to change a method that has been agreed through all of those process and =
which produces a correct answer.=C2=A0 While it may bee mildly suboptimal f=
or the duration of the conference in the case above, it works and simplifie=
s the conference behavior by presuming no re-offer occurs until a participa=
nt 4 arrives who does only B (If participant 1 has left, the conference can=
 then re-offer codec B to 2 and 3).=C2=A0 

While I appreciate the care you're going through with this, I d=
on't believe that this trade-off rises to the level of concern that wou=
ld warrant re-opening the question.

regards,

Ted


--94eb2c06f162477f6f055c8dc928--


From nobody Sat Oct 28 10:48:09 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353E513FCAF for ; Sat, 28 Oct 2017 10:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 196iIciuNvvC for ; Sat, 28 Oct 2017 10:48:06 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F4813FCAE for ; Sat, 28 Oct 2017 10:48:06 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id n61so11965153qte.10 for ; Sat, 28 Oct 2017 10:48:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gYWFLBpOgLdA99sLHx793BV6754UhYdMcJMMgOhXkz4=; b=nzA/V+39cveygN/m0VXMO43xwkIck3RIaB07mAXFrbhCraF+c3j14UYwbFwJPlXGjZ Owcr7FgS1r3sulcisffO+6SMT4f23WyUQIX+TcLdgYMMzkBqgPeoRkkD8bvzAhXNG04i 0lU62Hav+exed5Kgrv6hTMRrLazLFbY3ssLo1dVJ2x2/kKMVwm36ViEll61LG5YQ/ptC E/O7EPMAjdAZaZDbTUPm1V5qO3Fgb+DEvJ3nbKHt1aCLhIrQ6MnaB1HfBncrpNvCBOfr DBqafcIEPDvlTW+wzO4h0DA76DuK8BYaCwnlqReXzmbcYRPHPXKQdbtWuNp9qyFbHaC2 htrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gYWFLBpOgLdA99sLHx793BV6754UhYdMcJMMgOhXkz4=; b=ClRET+Ry2psZxVRcgWHo9DrL2QThxdMRZQ3w7zn/z84dqZwy4MQxuDPlfQYSWXq/X5 pmtgPVqyfV+iuztPqX/wl+XlKKyKjHH4yhbYjvKtKsvEvQEHT1hkJG4j+itt+wxlXK9W 7fSeomiiPhOkvz5V1ol9XmqP3net/5FW5rVmI1tD/stTfzNSVIq8gCbyQZynGoewBtAJ J48TMFOr2RHKPZ+cNDsN1Ipy1fSbg8V/jMss1bsQFKv37N+gCZaneYyU5bAoxP/fQOkJ vVWRRoJUm8xmwa5O8c30/XzNNze36QO3GAj0XSqI3ylTOu3sl1U8QGA+r1kdym8fr5HI kFxA==
X-Gm-Message-State: AMCzsaXdgex8K97iaEfM3PKOeXUlL5Byp57g1PXL6+3zvJJHBBsjulVu 5VWZbMBq/icn9TNqt7BCXZ7g+9kQXjERd2Se48oNeQ==
X-Google-Smtp-Source: ABhQp+T047GSWItb2DHAMtRIG81qy9BY70zHE+9WmGAf8VEOubF4ynQqyvUpZOuCajvbQdE2eYa8ejuIqfH9EY1COK0=
X-Received: by 10.200.43.8 with SMTP id 8mr6738413qtu.193.1509212885025; Sat, 28 Oct 2017 10:48:05 -0700 (PDT)
MIME-Version: 1.0
References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no>   <7594FB04B1934943A5C02806D1A2204B5635D4B5@ESESSMB109.ericsson.se> <1cb09b36-54db-afc1-ff5f-4a37c1701a23@alvestrand.no>
In-Reply-To: <1cb09b36-54db-afc1-ff5f-4a37c1701a23@alvestrand.no>
From: Peter Thatcher 
Date: Sat, 28 Oct 2017 17:47:53 +0000
Message-ID: 
To: Harald Alvestrand 
Cc: Christer Holmberg , "ice@ietf.org" , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11353eb6e77a90055c9f0156"
Archived-At: 
Subject: Re: [rtcweb] [Ice]  WGLC Review of draft-ietf-ice-rfc5245bis-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 28 Oct 2017 17:48:08 -0000

--001a11353eb6e77a90055c9f0156
Content-Type: text/plain; charset="UTF-8"

I looked through all of Harald's suggestions and I reviewed the PRs since
then, and it appears to me that most, if not all, of Harald's suggestions
have been incorporated into the doc.

Do the two of you agree, or is there something still missing that we need
to do?

On Tue, Oct 17, 2017 at 12:32 PM Harald Alvestrand 
wrote:

> Leaving in only the one with something left to write...
>
> Den 17. okt. 2017 21:26, skrev Christer Holmberg:
> >> I was thinking of something like:
> >>
> >> The exchange of information MUST result in the following information
> being available to the ICE agent:
> >>
> >> - Whether the remote peer supports ICE at all
> >> - What ICE options, if any, are supported
> >> - Whether the remote peer is Lite or Full
> >> - Whether the remote peer thinks it's the Initiating Agent or not
> >> - What candidates the remote peer wishes to make available
> >> - Whether an ICE restart is desired
> > Looks ok, but I am not sure what mean by the 4th, regarding thinking
> it's the initiating agent or not.
> >
> >
>
> The spec says that the initiating agent will take the CONTROLLING role
> if both parties are Full ICE implementations, or if both parties are
> Lite implementations. This means that it has to know that it's the
> initiating agent.
>
> In cases like Offer/Answer (without glare), it's simple to see which one
> is initiating. In cases with 3rd party control (both parties get called
> for setup), chat-line systems (both parties initiate a join) or
> protocols where glare is possible, something has to make the decision on
> which side has the Initiator role.
>
> I'd prefer to abandon the Initiator concept, and say that the exchange
> of information should give back the information to each about whether
> they should try to take the Controlling role, but that may be a larger
> rewrite.
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>

--001a11353eb6e77a90055c9f0156
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I looked through all of Harald's suggestions and I rev=
iewed the PRs since then, and it appears to me that most, if not all, of Ha=
rald's suggestions have been incorporated into the doc.=C2=A0=C2=A0
Do the two of you agree, or is there something still missin=
g that we need to do?=C2=A0=C2=A0

On Tue, Oct 17, 2017 at 12:32 PM Harald Alvestrand <harald@alvestrand.no> wrote:
Leaving in only the one with somethi=
ng left to write...



Den 17. okt. 2017 21:26, skrev Christer Holmberg:

>> I was thinking of something like:

>>

>> The exchange of information MUST result in the following informati=
on being available to the ICE agent:

>>

>> - Whether the remote peer supports ICE at all

>> - What ICE options, if any, are supported

>> - Whether the remote peer is Lite or Full

>> - Whether the remote peer thinks it's the Initiating Agent or =
not

>> - What candidates the remote peer wishes to make available

>> - Whether an ICE restart is desired

> Looks ok, but I am not sure what mean by the 4th, regarding thinking i=
t's the initiating agent or not.

>

>



The spec says that the initiating agent will take the CONTROLLING role

if both parties are Full ICE implementations, or if both parties are

Lite implementations. This means that it has to know that it's the

initiating agent.



In cases like Offer/Answer (without glare), it's simple to see which on=
e

is initiating. In cases with 3rd party control (both parties get called

for setup), chat-line systems (both parties initiate a join) or

protocols where glare is possible, something has to make the decision on
which side has the Initiator role.



I'd prefer to abandon the Initiator concept, and say that the exchange<=
br>
of information should give back the information to each about whether

they should try to take the Controlling role, but that may be a larger

rewrite.



_______________________________________________

Ice mailing list

Ice@ietf.org

https://www.ietf.org/mailman/listinfo/ice




--001a11353eb6e77a90055c9f0156--


From nobody Sat Oct 28 12:23:35 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5680013F567; Sat, 28 Oct 2017 12:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 io6MzMu6AIWa; Sat, 28 Oct 2017 12:23:31 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC7113FD29; Sat, 28 Oct 2017 12:23:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8BAFB7C0DBA; Sat, 28 Oct 2017 21:23:28 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRs7lQoqapOE; Sat, 28 Oct 2017 21:23:27 +0200 (CEST)
Received: from [192.168.8.101] (216-90-11.connect.netcom.no [176.11.90.216]) by mork.alvestrand.no (Postfix) with ESMTPSA id A195A7C0AF4; Sat, 28 Oct 2017 21:23:26 +0200 (CEST)
Date: Sat, 28 Oct 2017 21:23:16 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no>   <7594FB04B1934943A5C02806D1A2204B5635D4B5@ESESSMB109.ericsson.se> <1cb09b36-54db-afc1-ff5f-4a37c1701a23@alvestrand.no> 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----T44WE4HWJ5P2D1FWX7O25QPQMTHE2X"
Content-Transfer-Encoding: 7bit
To: ice@ietf.org,Peter Thatcher 
CC: "ice@ietf.org" , "rtcweb@ietf.org" , Christer Holmberg 
From: Harald Alvestrand 
Message-ID: <65F82D26-ADBD-48C9-B483-BA74D9C46A11@alvestrand.no>
Archived-At: 
Subject: Re: [rtcweb] [Ice]  WGLC Review of draft-ietf-ice-rfc5245bis-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 28 Oct 2017 19:23:33 -0000

------T44WE4HWJ5P2D1FWX7O25QPQMTHE2X
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think the rewrites done are entirely satisfactory=2E There's always thing=
s one can quibble about, but finishing is valuable=2E On to IETF Last Call!

Den 28=2E oktober 2017 19:47:53 CEST, skrev Peter Thatcher :
>I looked through all of Harald's suggestions and I reviewed the PRs
>since
>then, and it appears to me that most, if not all, of Harald's
>suggestions
>have been incorporated into the doc=2E
>
>Do the two of you agree, or is there something still missing that we
>need
>to do?
>
>On Tue, Oct 17, 2017 at 12:32 PM Harald Alvestrand
>
>wrote:
>
>> Leaving in only the one with something left to write=2E=2E=2E
>>
>> Den 17=2E okt=2E 2017 21:26, skrev Christer Holmberg:
>> >> I was thinking of something like:
>> >>
>> >> The exchange of information MUST result in the following
>information
>> being available to the ICE agent:
>> >>
>> >> - Whether the remote peer supports ICE at all
>> >> - What ICE options, if any, are supported
>> >> - Whether the remote peer is Lite or Full
>> >> - Whether the remote peer thinks it's the Initiating Agent or not
>> >> - What candidates the remote peer wishes to make available
>> >> - Whether an ICE restart is desired
>> > Looks ok, but I am not sure what mean by the 4th, regarding
>thinking
>> it's the initiating agent or not=2E
>> >
>> >
>>
>> The spec says that the initiating agent will take the CONTROLLING
>role
>> if both parties are Full ICE implementations, or if both parties are
>> Lite implementations=2E This means that it has to know that it's the
>> initiating agent=2E
>>
>> In cases like Offer/Answer (without glare), it's simple to see which
>one
>> is initiating=2E In cases with 3rd party control (both parties get
>called
>> for setup), chat-line systems (both parties initiate a join) or
>> protocols where glare is possible, something has to make the decision
>on
>> which side has the Initiator role=2E
>>
>> I'd prefer to abandon the Initiator concept, and say that the
>exchange
>> of information should give back the information to each about whether
>> they should try to take the Controlling role, but that may be a
>larger
>> rewrite=2E
>>
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf=2Eorg
>> https://www=2Eietf=2Eorg/mailman/listinfo/ice
>>

--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------T44WE4HWJ5P2D1FWX7O25QPQMTHE2X
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think the rewrites done are entirely satisfactor=
y=2E There's always things one can quibble about, but finishing is valu=
able=2E On to IETF Last Call!

Den 28=2E o=
ktober 2017 19:47:53 CEST, skrev Peter Thatcher <pthatcher@google=2Ecom&=
gt;:


I looked through all of Harald's suggestions and I review=
ed the PRs since then, and it appears to me that most, if not all, of Haral=
d's suggestions have been incorporated into the doc=2E  

Do the two of you agree, or is there something still missing t=
hat we need to do?  

=

On Tue, Oct 17, 2017 at 12:32 PM Harald Alvestrand <harald@alvestrand=2Eno> wrote=
:
Leaving in only the one with =
something left to write=2E=2E=2E



Den 17=2E okt=2E 2017 21:26, skrev Christer Holmberg:

>> I was thinking of something like:

>>

>> The exchange of information MUST result in the following informat=
ion being available to the ICE agent:

>>

>> - Whether the remote peer supports ICE at all

>> - What ICE options, if any, are supported

>> - Whether the remote peer is Lite or Full

>> - Whether the remote peer thinks it's the Initiating Agent or not=


>> - What candidates the remote peer wishes to make available

>> - Whether an ICE restart is desired

> Looks ok, but I am not sure what mean by the 4th, regarding thinking =
it's the initiating agent or not=2E

>

>



The spec says that the initiating agent will take the CONTROLLING role

if both parties are Full ICE implementations, or if both parties are

Lite implementations=2E This means that it has to know that it's the

initiating agent=2E



In cases like Offer/Answer (without glare), it's simple to see which one
is initiating=2E In cases with 3rd party control (both parties get called<=
br />
for setup), chat-line systems (both parties initiate a join) or

protocols where glare is possible, something has to make the decision on
which side has the Initiator role=2E



I'd prefer to abandon the Initiator concept, and say that the exchange

of information should give back the information to each about whether

they should try to take the Controlling role, but that may be a larger

rewrite=2E



_______________________________________________

Ice mailing list

Ice@ietf=2Eorg

https://www=2Eietf=2Eorg/mailman/listinfo/ice






-- 

Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------T44WE4HWJ5P2D1FWX7O25QPQMTHE2X--


From nobody Sun Oct 29 16:58:44 2017
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 C99B513F415; Sun, 29 Oct 2017 16:58:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150932151771.3345.13939646703846981665@ietfa.amsl.com>
Date: Sun, 29 Oct 2017 16:58:37 -0700
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-09.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-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, 29 Oct 2017 23:58:38 -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 WG of the IETF.

        Title           : Security Considerations for WebRTC
        Author          : Eric Rescorla
	Filename        : draft-ietf-rtcweb-security-09.txt
	Pages           : 25
	Date            : 2017-10-29

Abstract:
   WebRTC is a protocol suite for use with real-time applications that
   can be deployed in browsers - "real time communication on the Web".
   This document defines the WebRTC threat model and analyzes the
   security threats of WebRTC in that model.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-09
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 30 05:18:53 2017
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 DC2F313F7B6; Mon, 30 Oct 2017 05:18:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150936593186.3417.5204799814073320403@ietfa.amsl.com>
Date: Mon, 30 Oct 2017 05:18:51 -0700
Archived-At: 
Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-13.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
List-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, 30 Oct 2017 12:18:52 -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 WG of the IETF.

        Title           : WebRTC Security Architecture
        Author          : Eric Rescorla
	Filename        : draft-ietf-rtcweb-security-arch-13.txt
	Pages           : 40
	Date            : 2017-10-30

Abstract:
   This document defines the security architecture for WebRTC, a
   protocol suite intended for use with real-time applications that can
   be deployed in browsers - "real time communication on the Web".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-13
https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-arch-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 30 08:03:13 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CCD13FA54 for ; Mon, 30 Oct 2017 08:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 BhNjw5rjScSX for ; Mon, 30 Oct 2017 08:03:05 -0700 (PDT)
Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 00EA513FA4D for ; Mon, 30 Oct 2017 08:03:04 -0700 (PDT)
Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C46C15A07; Mon, 30 Oct 2017 11:02:59 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 60CC358A5;  Mon, 30 Oct 2017 11:02:59 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.55] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 30 Oct 2017 11:02:59 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings 
In-Reply-To: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com>
Date: Mon, 30 Oct 2017 09:02:58 -0600
Cc: RTCWeb IETF 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com>
To: Sergio Garcia Murillo 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 30 Oct 2017 15:03:12 -0000

I think this is a bit late to add something like 7728 as MTI to in the =
sort of "1.0" specs. Of course any browser could add support that that =
and it would work fine with WebRTC and it could be added to future =
specs.  Long ago when this was discussed, some people had concerns about=20=


https://datatracker.ietf.org/ipr/1641/

and

https://datatracker.ietf.org/ipr/1935/


> On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo =
 wrote:
>=20
> Hi all,
>=20
> According to the rtp usage draft, it is allowed to pause and resume =
transmissions at any time. There are several scenarios in which it would =
make sense to signal when a webrtc sender decides to pause one stream to =
the receiving side.
>=20
> One of them, (as described in detail in =
https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=3D5207) is =
be when the webrtc endpoints decides to stop sending one simulcast =
stream in order to adapt the sent bandwidth to the bandwidth estimation. =
In that case the SFU would benefit from having that indication before =
having to wait for a timeout on media reception before switching to a =
different simulcast stream. Note that in this case, the stream is paused =
from inside the webrtc stack, so there is no event triggered to be able =
to signal this to the js app so it could notify it off band to the =
receiving side.
>=20
> =46rom the solutions discussed, IMHO, the cleanest one would be to =
support the PAUSE indication from RFC7728. Do you think it could be =
considered to support it in webrtc?
>=20
> Best regards
>=20
> Sergio
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Mon Oct 30 09:24:56 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74024F17 for ; Mon, 30 Oct 2017 09:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWaPjcSKfRO7 for ; Mon, 30 Oct 2017 09:24:53 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829535384 for ; Mon, 30 Oct 2017 09:14:17 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id y23so16778483qkb.10 for ; Mon, 30 Oct 2017 09:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=p37nXfHl5fKnpCpo5FbaZjiESBhRfjF6M5piVBS4tAI=; b=WPlKpVfrGh/uDTp2s9C/lrYuC0QpeTtv0TYwFC60zFrSasIbOE6v+p+WWmcSVDW7jn SUl4XQrNpsnMN1IM+eR+T9V5Fle49lOc1qcQxPR5AiiyWfLRIzhCdjF1Y06vaU+52W4Q g+q8PjD41IhZ1dVdLnOgH5dw2PnZTOalo8V3mrIitQsmlKtZP5y2Plv7T34n2zPJ5Lc0 bocIt6GlhuwafOGRTZ/TkI/Wu3VrERtFvVrwuKovPZI1RGWECf1lQJYb06PNnco14/7A mH9SSW/42GDrQ2bPz5ncZnqmVomf2Ho5yrfmlbQjcNulWokNRob4vht9KP/MbMDOyOz/ q/Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p37nXfHl5fKnpCpo5FbaZjiESBhRfjF6M5piVBS4tAI=; b=s5TrTOZgauOYpf18EvVOf8e4vxOEhLlcbMJrA2IQr3v0ko0Wa+vnCzRB8EFjt7QDFv GEW6++g5LKG/uu57Yqb8RBdKtJ3oT2QsuY44bXxQrqoIStTWEUQ1nZeyQEK5nOq2rqh5 e/5hsue16JF+1pLF2GRxeAoRb88drxLhbvdyKls59QwyepkMqu3V1RtH0xj3qKRFiXl+ TOhS30a0cc5Et/IvE81AH1Vzv6OffChKmCIoIICqO97IxAh2hxCbY/7A/PaNTIJ0KV1d kpdH/5HzHQJKYh+WW8vnzg86MbkP/qZ3VKST6ZKWnZB71w10YRsKqC1VKPSpjTU4bMj/ K+Vw==
X-Gm-Message-State: AMCzsaWzNvKaSIvebm9+kY478nHhzVC4tO8Tye6h7fy3enIqf7Q4W8xv Ld7ege0d1PWt6Dr6t3c+K1d13GgBdgS+uo33ZYeukA==
X-Google-Smtp-Source: ABhQp+SlJE+aBumxJIRFP0KU4Uo2XNP4ufl9NAkp/OioZX9yA9VzBzYbYWzw4lFWw/SQhwTc5x5IlPsu/ImrTdyvZ3o=
X-Received: by 10.55.197.194 with SMTP id k63mr13965908qkl.208.1509380056409;  Mon, 30 Oct 2017 09:14:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.40.68 with HTTP; Mon, 30 Oct 2017 09:13:35 -0700 (PDT)
From: Ted Hardie 
Date: Mon, 30 Oct 2017 09:13:35 -0700
Message-ID: 
To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner 
Content-Type: multipart/alternative; boundary="001a1149916817ead6055cc5ee65"
Archived-At: 
Subject: [rtcweb] PNTAW list
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 30 Oct 2017 16:24:55 -0000

--001a1149916817ead6055cc5ee65
Content-Type: text/plain; charset="UTF-8"

Howdy,

Folks may recall that we had an adjunct list call "PNTAW" to discuss proxy,
NAT and TURN server behavior during a period of time when this list was
occasionally very active.  The archives are here:

https://www.ietf.org/mail-archive/web/pntaw/current/maillist.html

It is long dormant, and the chairs intend to close it at the end of this
week unless we hear objections.  Please let us know by Thursday, 12:00 PDT
if you do.

thanks,

Ted, Cullen, Sean

--001a1149916817ead6055cc5ee65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Howdy,

Folks may recall that we had=
 an adjunct list call "PNTAW" to discuss proxy, NAT and TURN serv=
er behavior during a period of time when this list was occasionally very ac=
tive.=C2=A0 The archives are here:

https://www.ietf.org/mail-arch=
ive/web/pntaw/current/maillist.html

It is long dorman=
t, and the chairs intend to close it at the end of this week unless we hear=
 objections.=C2=A0 Please let us know by Thursday, 12:00 PDT if you do.
=

thanks,

Ted, Cullen, Sean



--001a1149916817ead6055cc5ee65--


From nobody Mon Oct 30 11:20:57 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CCC9BA1 for ; Mon, 30 Oct 2017 11:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSKsVgxjlbrg for ; Mon, 30 Oct 2017 11:20:53 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9FA9BA7 for ; Mon, 30 Oct 2017 11:20:53 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id b7so8711789vkh.12 for ; Mon, 30 Oct 2017 11:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E+uJ6mticd98Rdp417HiQa9lBYUiaSULt3LMpKUCu74=; b=lcCqQs/k427TZVOXcirp1WePWy7eKCy8qbedeaF8MnYNjy7nwXfb2FgFoSDXjGRZoj blmvnMuZdRpoWP47S6C9wsNr41XiGzmEb1srv5AO+snQ0NuNh8BP5/40oLYEN1e0fKMg alDLVxGYR8BU7ASc+UIlasuX4ie7Ilm4Y635XYQEE6Walt4lSuXuUV9Gxb7NYCBB5LFH oLvjzVLFECsGKLahxcwFmI+9U1Bs3Xd4BfZ+Ph+AntPwvED0tRaC+Q6+vO4BOdArNVSj G/WjA1yRyenfrWie4IBz7Ncf7mNnEVyb0mn0uXphrHY76Zv79T8XEmcJVPC/IeTWgH7T zTvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E+uJ6mticd98Rdp417HiQa9lBYUiaSULt3LMpKUCu74=; b=fUyoZteds55ndQ+749dqLSPXBMzAWjbVnUM/XXVo1IDQh5sOYs5TFW5zEWB3lhHNZt +s+vqV7FD5rdxDyNmY43a/BQplmO0sq8Yy8Jt+zw02SP/+Cef3Dk8gWnL5PUFj6hV1mZ sf+9Zr1fUJrejPF9Cm7oRYw5yhGM8RDBWlnvUHEf662dy/7r51doq20w2YqmERtydb6Y YJYky0r9SO4dXxwkJVqwe0Eg+Pe8CKBJhfZmkZ+rZ8k9Og+u+7ehsUsNj8qN01rA7Ma3 0k1e+bRyOhTwb36hNC/Wn+srqVnuKEhF5o/74crVfR/KjfoOerX20vZddRHHesacpfMx V9ng==
X-Gm-Message-State: AMCzsaWVXNJvBKCbIOPRxk+C7gSF/SBXmllnwdGdT3VH/vy2fNcCovRE mGBzNEGzCcaCcw1ADr6mLGiTEGAH3eWb33O6h0E=
X-Google-Smtp-Source: ABhQp+Q1qYODeT2lrjHtWWQhr7pGAyWQPbtlWYqLYhFIWXHlbD2musHyJVbJaGXCk3KV1K+CYaQ/f8ZpxtTs0jbsQaU=
X-Received: by 10.31.157.7 with SMTP id g7mr8347521vke.130.1509387651965; Mon, 30 Oct 2017 11:20:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Mon, 30 Oct 2017 11:20:31 -0700 (PDT)
In-Reply-To: <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>
From: Bernard Aboba 
Date: Mon, 30 Oct 2017 11:20:31 -0700
Message-ID: 
To: Cullen Jennings 
Cc: Sergio Garcia Murillo , RTCWeb IETF 
Content-Type: multipart/alternative; boundary="001a1142d8d2d2e865055cc7b253"
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 30 Oct 2017 18:20:56 -0000

--001a1142d8d2d2e865055cc7b253
Content-Type: text/plain; charset="UTF-8"

To consider support for PAUSE/PAUSED, it would be first be necessary to
have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is
based on that.

However, although TMMBR/TMMBN is required in RTP-Usage, it has not been
widely implemented in WebRTC browsers. Part of the reason may have been
that REMB was used for both bandwidth estimation as well as control, so
TMMBR/TMMBN seemed like overlapping functionality. Although that argument
would be less valid after the transition from REMB to transport-cc,
experience tells us that "late blooming" protocol proposals are relatively
rare.

On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings  wrote:

>
> I think this is a bit late to add something like 7728 as MTI to in the
> sort of "1.0" specs. Of course any browser could add support that that and
> it would work fine with WebRTC and it could be added to future specs.  Long
> ago when this was discussed, some people had concerns about
>
> https://datatracker.ietf.org/ipr/1641/
>
> and
>
> https://datatracker.ietf.org/ipr/1935/
>
>
> > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
> >
> > Hi all,
> >
> > According to the rtp usage draft, it is allowed to pause and resume
> transmissions at any time. There are several scenarios in which it would
> make sense to signal when a webrtc sender decides to pause one stream to
> the receiving side.
> >
> > One of them, (as described in detail in https://monorail-prod.appspot.
> com/p/webrtc/issues/detail?id=5207) is be when the webrtc endpoints
> decides to stop sending one simulcast stream in order to adapt the sent
> bandwidth to the bandwidth estimation. In that case the SFU would benefit
> from having that indication before having to wait for a timeout on media
> reception before switching to a different simulcast stream. Note that in
> this case, the stream is paused from inside the webrtc stack, so there is
> no event triggered to be able to signal this to the js app so it could
> notify it off band to the receiving side.
> >
> > From the solutions discussed, IMHO, the cleanest one would be to support
> the PAUSE indication from RFC7728. Do you think it could be considered to
> support it in webrtc?
> >
> > Best regards
> >
> > Sergio
> >
> > _______________________________________________
> > 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
>

--001a1142d8d2d2e865055cc7b253
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


To consider support for PAUSE/PAUSED, it would be first be=
 necessary to have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED m=
echanism is based on that.=C2=A0

However, although TMMBR=
/TMMBN is required in RTP-Usage,=C2=A0it has not been widely implemented in=
 WebRTC browsers. Part of the reason may have been that REMB was used for b=
oth bandwidth estimation as well as control, so TMMBR/TMMBN seemed like ove=
rlapping functionality. Although that argument would be less valid after th=
e transition from REMB to transport-cc, experience tells us that "late=
 blooming" protocol proposals are relatively rare.=C2=A0

On Mon, Oct 30,=
 2017 at 8:02 AM, Cullen Jennings <fluffy@iii.ca> wrote:


I think this is a bit late to add something like 7728 as MTI to in the sort=
 of "1.0" specs. Of course any browser could add support that tha=
t and it would work fine with WebRTC and it could be added to future specs.=
=C2=A0 Long ago when this was discussed, some people had concerns about



https://datatracker.ietf.org/ipr/1641/



and



https://datatracker.ietf.org/ipr/1935/






> On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

>

> Hi all,

>

> According to the rtp usage draft, it is allowed to pause and resume tr=
ansmissions at any time. There are several scenarios in which it would make=
 sense to signal when a webrtc sender decides to pause one stream to the re=
ceiving side.

>

> One of them, (as described in detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?i=
d=3D5207) is be when the webrtc endpoints decides to stop sending =
one simulcast stream in order to adapt the sent bandwidth to the bandwidth =
estimation. In that case the SFU would benefit from having that indication =
before having to wait for a timeout on media reception before switching to =
a different simulcast stream. Note that in this case, the stream is paused =
from inside the webrtc stack, so there is no event triggered to be able to =
signal this to the js app so it could notify it off band to the receiving s=
ide.

>

> From the solutions discussed, IMHO, the cleanest one would be to suppo=
rt the PAUSE indication from RFC7728. Do you think it could be considered t=
o support it in webrtc?

>

> Best regards

>

> Sergio

>

> _______________________________________________

> 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




--001a1142d8d2d2e865055cc7b253--


From nobody Mon Oct 30 15:06:34 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC631389AC for ; Mon, 30 Oct 2017 15:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuJzYSOAp6Dp for ; Mon, 30 Oct 2017 15:06:31 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 953DD13FC3E for ; Mon, 30 Oct 2017 15:06:25 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id w45so10634309uac.3 for ; Mon, 30 Oct 2017 15:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZMg357tP5cgQnm8yJmQkYtSSGJGTbNPghVjdQUY8tDc=; b=KUA9qF1UOXkawaROamUswIDcYfWT8mK1KSYqzXDnJA99orGAKGpOpeObM+KOjCK5qE 6Ako21C5dPuY4UvkTWLWat/Zwcf4LhzGOvZX0FFpElxdcNBFyu5p9o5VAm1qfpqaiCci oW7ujIeAk7F0RgxTw25CtblHEtF97iagwBr4ETM7NcX+ZCUL4iVMpbfQ1FbKsFOnyCO1 E5/+ydZCDNNiNhS7jikLq5mxGeeL0HUn3rkBlG/y5S58TM3PbcmN+lMJEAVz0xtNW4J4 8fvnHqywKPyJtywTKDrtr58LyzopD8qpzWvjcuMh1ylNwKb5IPkcHuC2uihA2e+sjNYV 3Dgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZMg357tP5cgQnm8yJmQkYtSSGJGTbNPghVjdQUY8tDc=; b=VHmEW/H8jSMhrGkA7o1qSV4mb1+aRScl9b5sCIL/mMAWzDizEorHISMgtfygajMRRR MuRHf5S5f+zzrwfMZwAvKYsoeN+vC3ksNgwIpHDl5fOoNaJ/JpONI2AJeECA95dXZ/pL u45KMJscj5EHKRgtFavkZRU9xU4Ywd9fbBDmBOPAjqfCw1Z9/IvlXp11u4OF802IqJpt zNWmp1i9b+55Ok1nA4dcfazJvaJ94zZI2ZrPiE3URVd+tEla5bwAL0PPzDZ2lj/gBW7j 1SmpRALw4hUxI5ijTiO5U1rznEdLC6nK0Qrjup4d5aRf13qhMknOs0Ya/RUJ9aFx+S36 EUJA==
X-Gm-Message-State: AMCzsaWps57oKR6ESyuDW4pItLAwSfqWZhTbhmvznQisRQF7XGwxp7ZB 9n3DvxlLAwls5u/ud1/fF0DCZ5oaVp4O2zUZuAkguA==
X-Google-Smtp-Source: ABhQp+RkNMuXFb5LeNjFsyPjxqjNHcNy1zpfYp5TH93QvIXTGFRT7fYjfbP5eibKd0ySLNa35Y1/qXDnfmrODFm4+VQ=
X-Received: by 10.159.57.227 with SMTP id p35mr8993810uag.198.1509401184431; Mon, 30 Oct 2017 15:06:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.76.134 with HTTP; Mon, 30 Oct 2017 15:06:23 -0700 (PDT)
In-Reply-To: 
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>   <2CFCA859-B941-4AFF-B80A-792509EED6F5@vidyo.com> <7CA6CF4C-6A92-4198-B2E6-10FB5EC6EA5D@vidyo.com> 
From: Taylor Brandstetter 
Date: Mon, 30 Oct 2017 15:06:23 -0700
Message-ID: 
To: Ted Hardie 
Cc: Jonathan Lennox , "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c19f2106c8988055ccad905"
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: ordering (was codecs in answer: MUST vs. MAY)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 30 Oct 2017 22:06:33 -0000

--94eb2c19f2106c8988055ccad905
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

This is why we have setCodecPreferences. There are certainly use cases
where you *do* want to list codecs in browser preference order. And there
are cases where you don't. setCodecPreferences lets the application
developer decide which is appropriate.

Regards,
-Taylor

On Fri, Oct 27, 2017 at 2:14 PM, Ted Hardie  wrote:

> Hi Jonathan,
>
> On Fri, Oct 27, 2017 at 1:05 PM, Jonathan Lennox 
> wrote:
>
>> Another question about JSEP=E2=80=99s codec answer rules.
>>
>> The spec currently says:
>>
>>    o  Otherwise, the media formats on the m=3D line MUST be generated in
>>>>       the same order as those offered in the current remote descriptio=
n,
>>>>       excluding any currently unsupported formats.  Any currently
>>>>       available media formats that are not present in the current remo=
te
>>>>       description MUST be added after all existing formats.
>>>>
>>>>
>>> This is what you do if codec preferences are not set (keep the order,
>>> add any new ones to the end)
>>>
>>
>> Why are remotely-unsupported codecs added at the end of the list, rather
>> than just listing all locally-supported codecs in the browser=E2=80=99s =
preference
>> order?
>>
>> My concern is in an SFU conferencing scenario.  Consider the following:
>>
>> * Participant 1 joins a conference.  It supports only codec A.
>> * Participant 2 joins the conference.  It supports codecs A and B, but
>> prefers B.  Since the conference can only do A, if the offer/answer
>> exchange goes SFU->Participant, the participant=E2=80=99s answer must li=
st its
>> codecs as A, B.
>> * Participant 3 joins the conference.  It is the same as Participant 2,
>> preferring B to A.
>>
>> If participant 1 leaves, the SFU can re-offer to participants 2 and 3;
>> but as far as it knows, everyone prefers A to B, so the conference can e=
nd
>> up in a scenario where everyone=E2=80=99s using a less-preferred codec.
>>
>>
>>
> I would suggest that instead, the browser=E2=80=99s codec preference orde=
r always
>> be sent as-is in an answer (unless overridden by the app with
>> setCodecPreferences).  This also has the benefit of aligning the behavio=
r
>> with and without app codec preferences, rather than having two separate
>> behaviors (where the order is fixed if the app has set codec preferences=
,
>> and mirrored otherwise).
>>
>
> So, we're currently past WG last call and IETF last call, with the draft
> in IESG evaluation.  This proposal appears to change a method that has be=
en
> agreed through all of those process and which produces a correct answer.
> While it may bee mildly suboptimal for the duration of the conference in
> the case above, it works and simplifies the conference behavior by
> presuming no re-offer occurs until a participant 4 arrives who does only =
B
> (If participant 1 has left, the conference can then re-offer codec B to 2
> and 3).
>
> While I appreciate the care you're going through with this, I don't
> believe that this trade-off rises to the level of concern that would
> warrant re-opening the question.
>
> regards,
>
> Ted
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--94eb2c19f2106c8988055ccad905
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Jonathan,

This is why we have setCod=
ecPreferences. There are certainly use cases where you do=C2=A0want =
to list codecs in browser preference order. And there are cases where you d=
on't. setCodecPreferences lets the application developer decide which i=
s appropriate.

Regards,
-Taylor

On Fri, Oct 27=
, 2017 at 2:14 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Jonathan, 

On=
 Fri, Oct 27, 2017 at 1:05 PM, Jonathan Lennox <jonathan@vidyo.com>=
; wrote:
Another question about JSEP=E2=80=99s codec answer rules.

The spec currently says:
   o  Otherwise, the me=
dia formats on the m=3D line MUST be generated in
      the same order as those offered in the current remote description,
      excluding any currently unsupported formats.  Any currently
      available media formats that are not present in the current remote
      description MUST be added after all existing formats.


This is what you =
do if codec preferences are not set (keep the order, add any new ones to th=
e end)
<=
/div>

Why are remotely-unsupported c=
odecs added at the end of the list, rather than just listing all locally-su=
pported codecs in the browser=E2=80=99s preference order?

My concern is in an SFU conferencing scenario.=C2=A0 Consider the f=
ollowing:

* Participant 1 joins a conference.=C2=
=A0 It supports only codec A.
* Participant 2 joins the conferenc=
e.=C2=A0 It supports codecs A and B, but prefers B.=C2=A0 Since the confere=
nce can only do A, if the offer/answer exchange goes SFU->Participant, t=
he participant=E2=80=99s answer must list its codecs as A, B.
* P=
articipant 3 joins the conference.=C2=A0 It is the same as Participant 2, p=
referring B to A.

If participant 1 leaves, the SFU=
 can re-offer to participants 2 and 3; but as far as it knows, everyone pre=
fers A to B, so the conference can end up in a scenario where everyone=E2=
=80=99s using a less-preferred codec.

=C2=A0
=

I would suggest that instead, the browser=E2=80=99s codec p=
reference order always be sent as-is in an answer (unless overridden by the=
 app with setCodecPreferences).=C2=A0 This also has the benefit of aligning=
 the behavior with and without app codec preferences, rather than having tw=
o separate behaviors (where the order is fixed if the app has set codec pre=
ferences, and mirrored otherwise).

=

So, we're currently past WG last=
 call and IETF last call, with the draft in IESG evaluation.=C2=A0 This pro=
posal appears to change a method that has been agreed through all of those =
process and which produces a correct answer.=C2=A0 While it may bee mildly =
suboptimal for the duration of the conference in the case above, it works a=
nd simplifies the conference behavior by presuming no re-offer occurs until=
 a participant 4 arrives who does only B (If participant 1 has left, the co=
nference can then re-offer codec B to 2 and 3).=C2=A0 

While I appreciate the care you're going through wi=
th this, I don't believe that this trade-off rises to the level of conc=
ern that would warrant re-opening the question.

regards,

Ted
=



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--94eb2c19f2106c8988055ccad905--


From nobody Tue Oct 31 00:16:34 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B5911F81 for ; Tue, 31 Oct 2017 00:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 IskZj8O-Ykla for ; Tue, 31 Oct 2017 00:16:30 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004C9126B6 for ; Tue, 31 Oct 2017 00:16:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 50CC87C07E1; Tue, 31 Oct 2017 08:16:28 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBaXqZ0EQDx6; Tue, 31 Oct 2017 08:16:27 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 19D327C03A2; Tue, 31 Oct 2017 08:16:27 +0100 (CET)
To: Jonathan Lennox , Justin Uberti 
Cc: "rtcweb@ietf.org" 
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>   <2CFCA859-B941-4AFF-B80A-792509EED6F5@vidyo.com> <7CA6CF4C-6A92-4198-B2E6-10FB5EC6EA5D@vidyo.com>
From: Harald Alvestrand 
Message-ID: <4bf1b168-0830-f317-be74-f1cab95c8b47@alvestrand.no>
Date: Tue, 31 Oct 2017 08:16:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <7CA6CF4C-6A92-4198-B2E6-10FB5EC6EA5D@vidyo.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: ordering (was codecs in answer: MUST vs. MAY)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 07:16:33 -0000

Den 27. okt. 2017 22:05, skrev Jonathan Lennox:
> Another question about JSEP’s codec answer rules.
> 
> The spec currently says:
>>>
>>>            o  Otherwise, the media formats on the m= line MUST be generated in
>>>               the same order as those offered in the current remote description,
>>>               excluding any currently unsupported formats.  Any currently
>>>               available media formats that are not present in the current remote
>>>               description MUST be added after all existing formats.
>>>
>>>
>>>     This is what you do if codec preferences are not set (keep the
>>>     order, add any new ones to the end)
> 
> Why are remotely-unsupported codecs added at the end of the list, rather
> than just listing all locally-supported codecs in the browser’s
> preference order?

I don't read it like that.

The answer consists of:

- The offer's listed codecs that are also supported by the answerer,
possibly rearranged according to codec preference
- The answerer's supported codecs that were not listed in the offer.

These aren't "remotely-unsupported", they are unlisted by the offerer.

If they're really not supported by the offerer, adding them will have no
effect.

If they're supported by the offerer but the offerer chose not to list
them (might happen for instance if one is an inferior mode of a
supported codec, which the offerer did not think was worth mentioning),
listing them before listed codecs would be overriding a strongly stated
preference by the offerer.

I like the current logic.


> 
> My concern is in an SFU conferencing scenario.  Consider the following:
> 
> * Participant 1 joins a conference.  It supports only codec A.
> * Participant 2 joins the conference.  It supports codecs A and B, but
> prefers B.  Since the conference can only do A, if the offer/answer
> exchange goes SFU->Participant, the participant’s answer must list its
> codecs as A, B.
> * Participant 3 joins the conference.  It is the same as Participant 2,
> preferring B to A.
> 
> If participant 1 leaves, the SFU can re-offer to participants 2 and 3;
> but as far as it knows, everyone prefers A to B, so the conference can
> end up in a scenario where everyone’s using a less-preferred codec.

If the SFU offers A, B to participants 2 and 3, and both 2 and 3 prefer
B, they will answer B, A based on local codec preference.

It will have to ask, but is that a big deal?

> 
> I would suggest that instead, the browser’s codec preference order
> always be sent as-is in an answer (unless overridden by the app with
> setCodecPreferences).  This also has the benefit of aligning the
> behavior with and without app codec preferences, rather than having two
> separate behaviors (where the order is fixed if the app has set codec
> preferences, and mirrored otherwise).

I don't have a strong preference here, but do have a strong preference
against holding up the spec if this is the biggest issue left.

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


From nobody Tue Oct 31 02:22:43 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878A13F70D for ; Tue, 31 Oct 2017 02:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REZHoRWQYjAm for ; Tue, 31 Oct 2017 02:22:36 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 33EAA13F704 for ; Tue, 31 Oct 2017 02:22:34 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id 75so18181811lfx.1 for ; Tue, 31 Oct 2017 02:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=gRWNWf0zvge7x8Xxdd37vSBfKEzPdRGwv16Au4aC9WE=; b=PtO1TBxxJZvHRWQjys0boBq2DVuycFUNWt9ly3tdiLfRm+UGPoCchW995Od83pHlsV cD6glxANTvc6Mggv32uYGdJLpg3e1ig90zyykoc+NnenNGhuI5FgB7s3GhJ+GI6LFepu 9gH4O/UQk+Kqu4OlDOe310JQALgyo5q1cKUHAVSq5/fy6XkbyenFdCMYgVHN7VXAvZuK pRQ7rTgSRd+RtequUmpVA63eh/shRe3FYDzTDyOT3D8cwYoPS8tUBvlXutDY0+lzuOJ2 ixKqw2GyxxUO3vbw42vBdQD8hO07aeY4+H6Bs5WBvNgBoIeQ+CrC/2TWLPlhHrr2y6d3 Dwyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gRWNWf0zvge7x8Xxdd37vSBfKEzPdRGwv16Au4aC9WE=; b=T/OEjUO1DHHvJ83rMS6JYBTGIrUcFSVgBU4kAu/R9aojdVRyx7sZIrPd+l1X4E1B/F 6mKCaF9jhNX8JGom/gSZIY29VJTRUNKcjxexIy1CIqatGO0CvD6oQPbg/sZFjc3Gm4Ez hfZ5qP7+YY/xp8+lyK4D2Qn5n4RAMw+8XaDsg/vmOdF1ji0yYsegBYoPWBMFkMTfNo+D VBQ0Se87bpLVFem2w2VWaTVktTPa49WecfzRuYufl+R4LOJpK19gdZjcizMfD87XxIqX u3uFM4uVE5iMjg/Bup7kag54MsDOP5zWVoZWgN0tTu3T6QEs6vNyFiQ6cOMaEF47xhR9 d3XA==
X-Gm-Message-State: AMCzsaUE330x6uxkm/o6cOqhN0jbiPVqPNH6JLBSV8nlSgR77k506t/S yXYO4h0Zu73jbT+6jwCK1rTZmofz
X-Google-Smtp-Source: ABhQp+SF+56CkS4emtPT/FcPQRBlkCX3rze9NOwAuTORZKNLS7eqzGd2MS/jmH4+v1qkRvJ+PtWw4Q==
X-Received: by 10.46.16.218 with SMTP id 87mr704933ljq.115.1509441751243; Tue, 31 Oct 2017 02:22:31 -0700 (PDT)
Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id a73sm239174ljf.6.2017.10.31.02.22.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 02:22:30 -0700 (PDT)
To: Bernard Aboba , Cullen Jennings 
Cc: RTCWeb IETF 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca> 
From: Sergio Garcia Murillo 
Message-ID: <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>
Date: Tue, 31 Oct 2017 10:22:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1417DAE30B13829ECE43E897"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 09:22:39 -0000

This is a multi-part message in MIME format.
--------------1417DAE30B13829ECE43E897
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Bernard,

I agree that late blooming is relatively rare, but I have to try.. ;)

Indeed RFC 7728 provides to different implementation for the PAUSE/PAUSED:

    This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
    possible and defines a small set of new RTCP feedback messages where
    new semantics is needed.

But it also states that:

    As stated above, TMMBR/TMMBN may be used to provide pause and resume
    functionality for the point-to-point case.  If the topology is not
    point to point, TMMBR/TMMBN cannot safely be used for pause or
    resume.


So, at least for the SFU case, the RFC 7728 recommends the usage of the 
new RTCP messages, which does not require implementation of TMMBR/TMMBN.

While I agree, that the PAUSE request could be more difficult to 
implement and the use case could also be done "out off band", the PAUSED 
indication is relatively trivial to implement and it is not possible to 
be implemented any other way with current APIs.

Best regards
Sergio

On 30/10/2017 19:20, Bernard Aboba wrote:
> To consider support for PAUSE/PAUSED, it would be first be necessary 
> to have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED 
> mechanism is based on that.
>
> However, although TMMBR/TMMBN is required in RTP-Usage, it has not 
> been widely implemented in WebRTC browsers. Part of the reason may 
> have been that REMB was used for both bandwidth estimation as well as 
> control, so TMMBR/TMMBN seemed like overlapping functionality. 
> Although that argument would be less valid after the transition from 
> REMB to transport-cc, experience tells us that "late blooming" 
> protocol proposals are relatively rare.
>
> On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings  > wrote:
>
>
>     I think this is a bit late to add something like 7728 as MTI to in
>     the sort of "1.0" specs. Of course any browser could add support
>     that that and it would work fine with WebRTC and it could be added
>     to future specs.  Long ago when this was discussed, some people
>     had concerns about
>
>     https://datatracker.ietf.org/ipr/1641/
>     
>
>     and
>
>     https://datatracker.ietf.org/ipr/1935/
>     
>
>
>     > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo
>          > wrote:
>     >
>     > Hi all,
>     >
>     > According to the rtp usage draft, it is allowed to pause and
>     resume transmissions at any time. There are several scenarios in
>     which it would make sense to signal when a webrtc sender decides
>     to pause one stream to the receiving side.
>     >
>     > One of them, (as described in detail in
>     https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207
>     )
>     is be when the webrtc endpoints decides to stop sending one
>     simulcast stream in order to adapt the sent bandwidth to the
>     bandwidth estimation. In that case the SFU would benefit from
>     having that indication before having to wait for a timeout on
>     media reception before switching to a different simulcast stream.
>     Note that in this case, the stream is paused from inside the
>     webrtc stack, so there is no event triggered to be able to signal
>     this to the js app so it could notify it off band to the receiving
>     side.
>     >
>     > From the solutions discussed, IMHO, the cleanest one would be to
>     support the PAUSE indication from RFC7728. Do you think it could
>     be considered to support it in webrtc?
>     >
>     > Best regards
>     >
>     > Sergio
>     >
>     > _______________________________________________
>     > 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
>     
>
>


--------------1417DAE30B13829ECE43E897
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Bernard,

      

      I agree that late blooming is relatively rare, but I have to try..
      ;)

      

      Indeed RFC 7728 provides to different implementation for the
      PAUSE/PAUSED:

      

      
   This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



      But it also states that:

      

      
   As stated above, TMMBR/TMMBN may be used to provide pause and resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

      

      So, at least for the SFU case, the RFC 7728 recommends the usage
      of the new RTCP messages, which does not require implementation of
      TMMBR/TMMBN.

      

      While I agree, that the PAUSE request could be more difficult to
      implement and the use case could also be done "out off band", the
      PAUSED indication is relatively trivial to implement and it is not
      possible to be implemented any other way with current APIs.

      

      Best regards

      Sergio

      

      On 30/10/2017 19:20, Bernard Aboba wrote:

    

    

      
To consider support for PAUSE/PAUSED, it would be
        first be necessary to have implementations of TMMBR/TMMBN, since
        the PAUSE/PAUSED mechanism is based on that. 
        


        

        
However, although TMMBR/TMMBN is required in RTP-Usage, it
          has not been widely implemented in WebRTC browsers. Part of
          the reason may have been that REMB was used for both bandwidth
          estimation as well as control, so TMMBR/TMMBN seemed like
          overlapping functionality. Although that argument would be
          less valid after the transition from REMB to transport-cc,
          experience tells us that "late blooming" protocol proposals
          are relatively rare. 

        

      

      


        
On Mon, Oct 30, 2017 at 8:02 AM, Cullen
          Jennings <fluffy@iii.ca>
          wrote:

          


            I think this is a bit late to add something like 7728 as MTI
            to in the sort of "1.0" specs. Of course any browser could
            add support that that and it would work fine with WebRTC and
            it could be added to future specs.  Long ago when this was
            discussed, some people had concerns about

            

            https://datatracker.ietf.org/ipr/1641/

            

            and

            

            https://datatracker.ietf.org/ipr/1935/

            

              


                

                > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo
                <sergio.garcia.murillo@gmail.com>
                wrote:

                >

                > Hi all,

                >

                > According to the rtp usage draft, it is allowed to
                pause and resume transmissions at any time. There are
                several scenarios in which it would make sense to signal
                when a webrtc sender decides to pause one stream to the
                receiving side.

                >

                > One of them, (as described in detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207)
                is be when the webrtc endpoints decides to stop sending
                one simulcast stream in order to adapt the sent
                bandwidth to the bandwidth estimation. In that case the
                SFU would benefit from having that indication before
                having to wait for a timeout on media reception before
                switching to a different simulcast stream. Note that in
                this case, the stream is paused from inside the webrtc
                stack, so there is no event triggered to be able to
                signal this to the js app so it could notify it off band
                to the receiving side.

                >

                > From the solutions discussed, IMHO, the cleanest
                one would be to support the PAUSE indication from
                RFC7728. Do you think it could be considered to support
                it in webrtc?

                >

                > Best regards

                >

                > Sergio

                >

                > _______________________________________________

                > 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

              

            

          

        

        

      

    

    


    

  


--------------1417DAE30B13829ECE43E897--


From nobody Tue Oct 31 02:34:34 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7F13F705 for ; Tue, 31 Oct 2017 02:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWhZxLdhGq-h for ; Tue, 31 Oct 2017 02:34:30 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 C2C6A13F5D7 for ; Tue, 31 Oct 2017 02:34:29 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id m72so13436722wmc.0 for ; Tue, 31 Oct 2017 02:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W1XPXRuW6WDELJZjmg/8O8YXgDTjdaoD4cOf+yGwSuk=; b=hnRalZHGZN8SGg9o/acDLQh6eAx3XoIfRQf9wtsdnDRenqougjgJWMuj+2hW1i9dSG 1GuyqaDhsrYKcwjq4L69FCDpwggHpk8lPnoF/5wD9luxEEsxwsfEYOVPg/EEsTwNTC6W F5/TPOcVn7gwnBw6A7246TSX8nsG4MSUubzVeaSrWVj5N3kcdIwzB161jc3ZuiWagNtF cF1F1VtMCe+XbEhHR/O3VrXCP22zRDXWRI1LZqjmRZF0IZFm0I06e1A2LCMNxtdRrv3Q iOTHyG+UZFUMLVvZz2UlSgMWfZWYGzh0v5Wq7ueQWAPHbFTiyHR5oU4ywyE24+NtJRVm HxLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W1XPXRuW6WDELJZjmg/8O8YXgDTjdaoD4cOf+yGwSuk=; b=jIFqvVnJFuhExUf4soOAAvQiDyYSmGHSUq9LMrgzhlR0oBE7n9MkU/b10mYjKeBfFk +2H2QfEYqsyAADBp5TunOLZbFel0/IhgI5xk9LNa9GrVUcBDFZY6hRAM+6xNbnKkw2qO gIC2e9tS85OMqERjNUNv+xwTJ3p6oGmjWXrgR0tCPc9+wRtEQ8IZ4Pm/YBLGWxfZKXG/ D1sy7um2BTYNqpBUP28VcTZItOAwjw8HwQXCXHoFJ80QNvOpG1EpfGD6TPqXwftnBJ1G Cky+FIaosUidICc5w8F7jPSXBc1J+284qtBY/7abuQ3hygkRtir86yjEzYUNljT3NNIf CQbQ==
X-Gm-Message-State: AMCzsaWbxDnHzncHY60DQ85mse/f2a1Ycw1UwsuhhU6qjekPE0bATy0+ OANmNgLM8pdZtHHPDy/QmOc8HqZOobCDBXyn57hZFw==
X-Google-Smtp-Source: ABhQp+SKNAAtpTXJAKwtq/qNSr4iyNo5WofH4NzSYxs8Vu+pL0Z84CNMhX3n2+eweNMkhA2LxjUxeBbejQ+828UuYbU=
X-Received: by 10.80.173.138 with SMTP id a10mr2042636edd.49.1509442468299; Tue, 31 Oct 2017 02:34:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 02:34:27 -0700 (PDT)
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 02:34:27 -0700 (PDT)
In-Reply-To: <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 31 Oct 2017 10:34:27 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
Content-Type: multipart/alternative; boundary="94eb2c0df83221df61055cd476ae"
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 09:34:33 -0000

--94eb2c0df83221df61055cd476ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't know how PAUSE could be implemented "out of band". In fact, the
problem is that, currently, browsers stop a simulcast stream at any time
without any indication at media or API layers. This is, I see RTCP PAUSE
useful for that use case rather than for the app to programmagically pause
a sending track (which can be indeed done via track.enabled =3D false +
signaling).

El 31 oct. 2017 10:22, "Sergio Garcia Murillo" <
sergio.garcia.murillo@gmail.com> escribi=C3=B3:

> Hi Bernard,
>
> I agree that late blooming is relatively rare, but I have to try.. ;)
>
> Indeed RFC 7728 provides to different implementation for the PAUSE/PAUSED=
:
>
>    This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
>    possible and defines a small set of new RTCP feedback messages where
>    new semantics is needed.
>
>
> But it also states that:
>
>    As stated above, TMMBR/TMMBN may be used to provide pause and resume
>    functionality for the point-to-point case.  If the topology is not
>    point to point, TMMBR/TMMBN cannot safely be used for pause or
>    resume.
>
>
> So, at least for the SFU case, the RFC 7728 recommends the usage of the
> new RTCP messages, which does not require implementation of TMMBR/TMMBN.
>
> While I agree, that the PAUSE request could be more difficult to implemen=
t
> and the use case could also be done "out off band", the PAUSED indication
> is relatively trivial to implement and it is not possible to be implement=
ed
> any other way with current APIs.
>
> Best regards
> Sergio
>
> On 30/10/2017 19:20, Bernard Aboba wrote:
>
> To consider support for PAUSE/PAUSED, it would be first be necessary to
> have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is
> based on that.
>
> However, although TMMBR/TMMBN is required in RTP-Usage, it has not been
> widely implemented in WebRTC browsers. Part of the reason may have been
> that REMB was used for both bandwidth estimation as well as control, so
> TMMBR/TMMBN seemed like overlapping functionality. Although that argument
> would be less valid after the transition from REMB to transport-cc,
> experience tells us that "late blooming" protocol proposals are relativel=
y
> rare.
>
> On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings  wrote:
>
>>
>> I think this is a bit late to add something like 7728 as MTI to in the
>> sort of "1.0" specs. Of course any browser could add support that that a=
nd
>> it would work fine with WebRTC and it could be added to future specs.  L=
ong
>> ago when this was discussed, some people had concerns about
>>
>> https://datatracker.ietf.org/ipr/1641/
>>
>> and
>>
>> https://datatracker.ietf.org/ipr/1935/
>>
>>
>> > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > According to the rtp usage draft, it is allowed to pause and resume
>> transmissions at any time. There are several scenarios in which it would
>> make sense to signal when a webrtc sender decides to pause one stream to
>> the receiving side.
>> >
>> > One of them, (as described in detail in https://monorail-prod.appspot.
>> com/p/webrtc/issues/detail?id=3D5207) is be when the webrtc endpoints
>> decides to stop sending one simulcast stream in order to adapt the sent
>> bandwidth to the bandwidth estimation. In that case the SFU would benefi=
t
>> from having that indication before having to wait for a timeout on media
>> reception before switching to a different simulcast stream. Note that in
>> this case, the stream is paused from inside the webrtc stack, so there i=
s
>> no event triggered to be able to signal this to the js app so it could
>> notify it off band to the receiving side.
>> >
>> > From the solutions discussed, IMHO, the cleanest one would be to
>> support the PAUSE indication from RFC7728. Do you think it could be
>> considered to support it in webrtc?
>> >
>> > Best regards
>> >
>> > Sergio
>> >
>> > _______________________________________________
>> > 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
>
>

--94eb2c0df83221df61055cd476ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't know how PAUSE could be implemented "out=
 of band". In fact, the problem is that, currently, browsers stop a si=
mulcast stream at any time without any indication at media or API layers. T=
his is, I see RTCP PAUSE useful for that use case rather than for the app t=
o programmagically pause a sending track (which can be indeed done via trac=
k.enabled =3D false + signaling).

El 31 oct. 2017 10:22, "Sergio Garcia Murillo&qu=
ot; <sergio.garcia.mu=
rillo@gmail.com> escribi=C3=B3:

 =20
   =20
 =20
  

    
Hi Bernard,

      

      I agree that late blooming is relatively rare, but I have to try..
      ;)

      

      Indeed RFC 7728 provides to different implementation for the
      PAUSE/PAUSED:

      

      
=
   This solution reuses CCM TMMBR and TMMBN [RFC5104] to =
the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



      But it also states that:

      

      
=
   As stated above, TMMBR/TMMBN may be used to provide pause and resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

      

      So, at least for the SFU case, the RFC 7728 recommends the usage
      of the new RTCP messages, which does not require implementation of
      TMMBR/TMMBN.

      

      While I agree, that the PAUSE request could be more difficult to
      implement and the use case could also be done "out off band"=
;, the
      PAUSED indication is relatively trivial to implement and it is not
      possible to be implemented any other way with current APIs.

      

      Best regards

      Sergio

      

      On 30/10/2017 19:20, Bernard Aboba wrote:

    

    

      
To consider support for PAUSE/PAUSED, it would be
        first be necessary to have implementations of TMMBR/TMMBN, since
        the PAUSE/PAUSED mechanism is based on that.=C2=A0
        


        

        
However, although TMMBR/TMMBN is required in RTP-Usage,=C2=A0i=
t
          has not been widely implemented in WebRTC browsers. Part of
          the reason may have been that REMB was used for both bandwidth
          estimation as well as control, so TMMBR/TMMBN seemed like
          overlapping functionality. Although that argument would be
          less valid after the transition from REMB to transport-cc,
          experience tells us that "late blooming" protocol propo=
sals
          are relatively rare.=C2=A0

        

      

      


        
On Mon, Oct 30, 2017 at 8:02 AM, Cullen
          Jennings <fluffy@iii.ca>
          wrote:

          


            I think this is a bit late to add something like 7728 as MTI
            to in the sort of "1.0" specs. Of course any browser =
could
            add support that that and it would work fine with WebRTC and
            it could be added to future specs.=C2=A0 Long ago when this was
            discussed, some people had concerns about

            

            https://datatracker.ietf.org/ipr/1641/
            

            and

            

            https://datatracker.ietf.org/ipr/1935/
            

              


                

                > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo
                <sergio.garcia.murillo@gmail.com>
                wrote:

                >

                > Hi all,

                >

                > According to the rtp usage draft, it is allowed to
                pause and resume transmissions at any time. There are
                several scenarios in which it would make sense to signal
                when a webrtc sender decides to pause one stream to the
                receiving side.

                >

                > One of them, (as described in detail in https://monorail-prod.appspot.com/p/webrtc/=
issues/detail?id=3D5207)
                is be when the webrtc endpoints decides to stop sending
                one simulcast stream in order to adapt the sent
                bandwidth to the bandwidth estimation. In that case the
                SFU would benefit from having that indication before
                having to wait for a timeout on media reception before
                switching to a different simulcast stream. Note that in
                this case, the stream is paused from inside the webrtc
                stack, so there is no event triggered to be able to
                signal this to the js app so it could notify it off band
                to the receiving side.

                >

                > From the solutions discussed, IMHO, the cleanest
                one would be to support the PAUSE indication from
                RFC7728. Do you think it could be considered to support
                it in webrtc?

                >

                > Best regards

                >

                > Sergio

                >

                > _______________________________________________
                > rtcweb mailing list

                > r=
tcweb@ietf.org

                > https://www.ietf.org/mailman/l=
istinfo/rtcweb

                

                _______________________________________________

                rtcweb mailing list

                rtcweb=
@ietf.org

                https://www.ietf.org/mailman/listin=
fo/rtcweb

              

            

          

        

        

      

    

    


    

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb



--94eb2c0df83221df61055cd476ae--


From nobody Tue Oct 31 02:37:57 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3753413F70E for ; Tue, 31 Oct 2017 02:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uBsV2VjHPNEP for ; Tue, 31 Oct 2017 02:37:55 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 84E2113F70D for ; Tue, 31 Oct 2017 02:37:54 -0700 (PDT)
X-AuditID: c1b4fb30-ef1ff70000001b7f-55-59f844708b31
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.E0.07039.07448F95; Tue, 31 Oct 2017 10:37:52 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Tue, 31 Oct 2017 10:37:51 +0100
From: Christer Holmberg 
To: Harald Alvestrand , Jonathan Lennox , Justin Uberti 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] JSEP: codecs in answer: ordering (was codecs in answer: MUST vs. MAY)
Thread-Index: AQHTT17s8rvlJFkOIUaE/XLZ8XLAw6L9gNIAgAA6TwA=
Date: Tue, 31 Oct 2017 09:37:51 +0000
Message-ID: 
References: <4CB5EF91-8CB2-433F-85E9-A86140CECC62@vidyo.com>   <2CFCA859-B941-4AFF-B80A-792509EED6F5@vidyo.com> <7CA6CF4C-6A92-4198-B2E6-10FB5EC6EA5D@vidyo.com> <4bf1b168-0830-f317-be74-f1cab95c8b47@alvestrand.no>
In-Reply-To: <4bf1b168-0830-f317-be74-f1cab95c8b47@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7pW6By49Ig3U/DCyO9XWxWexffJ7Z YutUIYu1/9rZHVg8rky4wuqxYFOpx5IlP5k82p7dYQ9gieKySUnNySxLLdK3S+DKuL5iBVPB L/6KBSsSGhiX8nQxcnJICJhIbDq1mrmLkYtDSOAwo0TjjGNMEM5iRon1h3axdjFycLAJWEh0 /9MGaRARqJA4tuwpM4jNLKAucWfxOXYQW1ggVmLe4bfMIOUiAnESz28zQpRbSTQ9nQBWwiKg KtHUehvM5hWwlrh4eCEjxKrnTBK7p79hBUlwCjhKPHjzngnEZhQQk/h+ag0TxC5xiVtP5jNB HC0gsWTPeWYIW1Ti5eN/YL2iAnoSG05ALJAQUJRof9rACNGrJ3Fj6hQ2CNta4k/jRKiZ2hLL Fr5mhjhIUOLkzCcsExjFZyFZNwtJ+ywk7bOQtM9C0r6AkXUVo2hxanFSbrqRkV5qUWZycXF+ nl5easkmRmBEHtzy22AH48vnjocYBTgYlXh4tSx+RAqxJpYVV+YeYpTgYFYS4RX6+D1SiDcl sbIqtSg/vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsZt6Qtc2ZRybylM XrWGVdG+4mvHHn613NJ3OvXKmiezItJXrvZULV2YcMh9cYrBIyUP8y+GbW2bO6ZZqGU9vKoh O93tZoC9WKq/0TLbzDPX24NkAo9aPekofnF475Hm8gmeTD+Mj/ZYzWZovOyyNOyVu448byKP 2pGk0ycjRV/nbAz7/qGyQomlOCPRUIu5qDgRAObbetzEAgAA
Archived-At: 
Subject: Re: [rtcweb] JSEP: codecs in answer: ordering (was codecs in answer: MUST vs. MAY)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 09:37:56 -0000

Hi,

>>Another question about JSEP=B9s codec answer rules.
>>=20
>> The spec currently says:
>>>>
>>>>            o  Otherwise, the media formats on the m=3D line MUST be
>>>>generated in
>>>>               the same order as those offered in the current remote
>>>>description,
>>>>               excluding any currently unsupported formats.  Any
>>>>currently
>>>>               available media formats that are not present in the
>>>>current remote
>>>>               description MUST be added after all existing formats.
>>>>
>>>>
>>>>     This is what you do if codec preferences are not set (keep the
>>>>     order, add any new ones to the end)
>>=20
>> Why are remotely-unsupported codecs added at the end of the list, rather
>> than just listing all locally-supported codecs in the browser=B9s
>> preference order?
>
>I don't read it like that.
>
>The answer consists of:
>
>- The offer's listed codecs that are also supported by the answerer,
>possibly rearranged according to codec preference
>- The answerer's supported codecs that were not listed in the offer.
>
>These aren't "remotely-unsupported", they are unlisted by the offerer.
>
>If they're really not supported by the offerer, adding them will have no
>effect.
>
>If they're supported by the offerer but the offerer chose not to list
>them (might happen for instance if one is an inferior mode of a
>supported codec, which the offerer did not think was worth mentioning),
>listing them before listed codecs would be overriding a strongly stated
>preference by the offerer.
>
>I like the current logic.

A few things to keep in mind, if adding codec X in the answer, when X was
not in the offer:

1) The answerer needs to be prepared to receive media using codec X, but
the answerer cannot send media using codec X.
2) If the offerer does support X (even if it did not include it in the
offer), the offerer cannot use it if using it would require providing
codec related SEND parameters.

Regards,

Christer
=20


From nobody Tue Oct 31 02:41:00 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8EC13F70D for ; Tue, 31 Oct 2017 02:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH5oC9k1dsOS for ; Tue, 31 Oct 2017 02:40:56 -0700 (PDT)
Received: from smtpcmd10101.aruba.it (smtpcmd15176.aruba.it [62.149.156.176]) by ietfa.amsl.com (Postfix) with ESMTP id 295C713F650 for ; Tue, 31 Oct 2017 02:40:56 -0700 (PDT)
Received: from lminiero ([93.44.32.157]) by smtpcmd15.ad.aruba.it with bizsmtp id U9gu1w02G3PQJjh019gvTR; Tue, 31 Oct 2017 10:40:55 +0100
Date: Tue, 31 Oct 2017 10:40:53 +0100
From: Lorenzo Miniero 
To: =?UTF-8?B?ScOxYWtp?= Baz Castillo 
Cc: Sergio Garcia Murillo , RTCWeb IETF 
Message-ID: <20171031104053.1a99f7c4@lminiero>
In-Reply-To: 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com> 
Organization: Meetecho
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1509442855; bh=FZ5xpz9M8lEMip2UFQtvCWBPRKWtAMRj/0CcZbqrgsA=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=RTAv9RQO6/tRNAEzvITs2e7czbNMNTQKgiyppcb9HrnBJHHAfac+sp2hJDAu2BR+r podoa8FVVPG3IsGNRGXSqYgy1EjUUKUOe+R85yZMJxzGikyDan36+Nn7U9FHxH8DKD nPi0f+DuTBejKOTTfcCbf6NEIWwZ7agc1y+06rGB1qIAJfZHBYmcbES4xXy1ydbmQd wK8s1byo8LW3/FVCSk7myHMJZc623ntOCbh28nWO4jZQoo5ZXRtThotCscod418Yql gSYUEkl58CjKEk5zclQS4TyqyHPc4ktfAb+x1TdRsoeVlaWOPYv+V1wj0VdtK+mJZN 5fR5OtvsaVZVg==
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 09:40:59 -0000

On Tue, 31 Oct 2017 10:34:27 +0100
I=C3=B1aki Baz Castillo  wrote:

> I don't know how PAUSE could be implemented "out of band". In fact,
> the problem is that, currently, browsers stop a simulcast stream at
> any time without any indication at media or API layers. This is, I
> see RTCP PAUSE useful for that use case rather than for the app to
> programmagically pause a sending track (which can be indeed done via
> track.enabled =3D false + signaling).
>=20


100% agree on this. What's missing is not how to do the action, but the
notification that the action occurred. Besides, a PAUSED event is all
that would be needed, as a RESUMED is implicitly inferred from seeing
traffic for an SSRC again.

L.


> El 31 oct. 2017 10:22, "Sergio Garcia Murillo" <
> sergio.garcia.murillo@gmail.com> escribi=C3=B3: =20
>=20
> > Hi Bernard,
> >
> > I agree that late blooming is relatively rare, but I have to
> > try.. ;)
> >
> > Indeed RFC 7728 provides to different implementation for the
> > PAUSE/PAUSED:
> >
> >    This solution reuses CCM TMMBR and TMMBN [RFC5104
> > ] to the extent possible and
> > defines a small set of new RTCP feedback messages where new
> > semantics is needed.
> >
> >
> > But it also states that:
> >
> >    As stated above, TMMBR/TMMBN may be used to provide pause and
> > resume functionality for the point-to-point case.  If the topology
> > is not point to point, TMMBR/TMMBN cannot safely be used for pause
> > or resume.
> >
> >
> > So, at least for the SFU case, the RFC 7728 recommends the usage of
> > the new RTCP messages, which does not require implementation of
> > TMMBR/TMMBN.
> >
> > While I agree, that the PAUSE request could be more difficult to
> > implement and the use case could also be done "out off band", the
> > PAUSED indication is relatively trivial to implement and it is not
> > possible to be implemented any other way with current APIs.
> >
> > Best regards
> > Sergio
> >
> > On 30/10/2017 19:20, Bernard Aboba wrote:
> >
> > To consider support for PAUSE/PAUSED, it would be first be
> > necessary to have implementations of TMMBR/TMMBN, since the
> > PAUSE/PAUSED mechanism is based on that.
> >
> > However, although TMMBR/TMMBN is required in RTP-Usage, it has not
> > been widely implemented in WebRTC browsers. Part of the reason may
> > have been that REMB was used for both bandwidth estimation as well
> > as control, so TMMBR/TMMBN seemed like overlapping functionality.
> > Although that argument would be less valid after the transition
> > from REMB to transport-cc, experience tells us that "late blooming"
> > protocol proposals are relatively rare.
> >
> > On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings 
> > wrote:=20
> >>
> >> I think this is a bit late to add something like 7728 as MTI to in
> >> the sort of "1.0" specs. Of course any browser could add support
> >> that that and it would work fine with WebRTC and it could be added
> >> to future specs.  Long ago when this was discussed, some people
> >> had concerns about
> >>
> >> https://datatracker.ietf.org/ipr/1641/
> >>
> >> and
> >>
> >> https://datatracker.ietf.org/ipr/1935/
> >>
> >> =20
> >> > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <
> >> sergio.garcia.murillo@gmail.com> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > According to the rtp usage draft, it is allowed to pause and
> >> > resume =20
> >> transmissions at any time. There are several scenarios in which it
> >> would make sense to signal when a webrtc sender decides to pause
> >> one stream to the receiving side. =20
> >> >
> >> > One of them, (as described in detail in
> >> > https://monorail-prod.appspot. =20
> >> com/p/webrtc/issues/detail?id=3D5207) is be when the webrtc endpoints
> >> decides to stop sending one simulcast stream in order to adapt the
> >> sent bandwidth to the bandwidth estimation. In that case the SFU
> >> would benefit from having that indication before having to wait
> >> for a timeout on media reception before switching to a different
> >> simulcast stream. Note that in this case, the stream is paused
> >> from inside the webrtc stack, so there is no event triggered to be
> >> able to signal this to the js app so it could notify it off band
> >> to the receiving side. =20
> >> >
> >> > From the solutions discussed, IMHO, the cleanest one would be
> >> > to =20
> >> support the PAUSE indication from RFC7728. Do you think it could be
> >> considered to support it in webrtc? =20
> >> >
> >> > Best regards
> >> >
> >> > Sergio
> >> >
> >> > _______________________________________________
> >> > 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
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > =20



--=20
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero


From nobody Tue Oct 31 02:59:44 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD0B13B11B for ; Tue, 31 Oct 2017 02:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQr36SCEMf4b for ; Tue, 31 Oct 2017 02:59:40 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 1A2AD139428 for ; Tue, 31 Oct 2017 02:59:40 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id r196so21875030wmf.2 for ; Tue, 31 Oct 2017 02:59:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=O6MTBr3gneHHdpyMjjddA+YhAfwSK8k9kVUQ53Slm5M=; b=q9hkgQmcj7TKNET2eGZBelqj7VF/462tgP4DWOGgIMNoZCw3nbpHJ9Rx4bELb+hPBz 0FhHIBHPPP1nk3jutDZWGBSs/aipLbM/f8yVP67hPTuVCtgpIdqUbK/9sQwYI0ZRMPSK uzAL3vxrbuBtRp50l+BrWAkkPpKqixkQ9AMQ32cLEFsMES7t74VzGRFq7AOx4kzCN4FQ 7aDifZ5bYproFvUMf/r08Rhyzw76xZZSevJ5sf6yApwv10a/Usg+INg5xdRIIkRkIuHV SlUHjn/0kyUcumPqCXnIs4peq8q2vV7wqSSyQVOm96zjDWDHVy1MBTevGc0nKnzt48pC X2kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=O6MTBr3gneHHdpyMjjddA+YhAfwSK8k9kVUQ53Slm5M=; b=oD+0bEkQ5Stm7rIadVXoJFGPzCiQrQQRd0kR2mlM/EKgBEb5kRwa1bnMc/D5JUVoWR 9JaNfIGpmL54yXO7KvjdN/VJ2pqjRXAW2IAigk+5tp7VvuK0juR6TmbF1v72h2KoB3+R ZCCq5rj1yiECGsTy2zgda/ktOVIyNltJwaRbXhxLVaYIvNIc6Aqs2jWzXbV3Jcp2XGdl lEBck/ErTD9MpDcuZT2PORIpXxtwB1xLhwz5BtXEAEFVxuYDaW8HIXNTaSSA9eRJo8hU qtbDn2klGPtUy98rpBC6eemM35P60IKydcenMOLJqZDzWVaxoNVGmkSEY7IamXlWC3Qn XtwQ==
X-Gm-Message-State: AMCzsaX5OnMVriN3tQM7ALPzVf/zZBf5nHnZddu1bQH9lfpQmjrnFjzF LcGHno4DP5zpOEG+LgfdcxsNFuSC
X-Google-Smtp-Source: ABhQp+SibWGKP9dSePra5FWsywuW6Dyw5E4wDsptP37ylDxju/ny7TW34kXQ1ZqMBJ8kOYyWWLSxfg==
X-Received: by 10.80.148.235 with SMTP id t40mr2291565eda.149.1509443978100; Tue, 31 Oct 2017 02:59:38 -0700 (PDT)
Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id e56sm897637edb.72.2017.10.31.02.59.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 02:59:37 -0700 (PDT)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: 
Date: Tue, 31 Oct 2017 10:59:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FAEC619EB5B2304EE86D9174"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 09:59:43 -0000

This is a multi-part message in MIME format.
--------------FAEC619EB5B2304EE86D9174
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Please, re-read my email, as I am basically saying what you are stating.

PAUSE request can be done out of band (track.enabled = false + 
signaling), PAUSED indication of simulcast layers can't be done with 
current APIs.

BR
Sergio

On 31/10/2017 10:34, Iñaki Baz Castillo wrote:
> I don't know how PAUSE could be implemented "out of band". In fact, 
> the problem is that, currently, browsers stop a simulcast stream at 
> any time without any indication at media or API layers. This is, I see 
> RTCP PAUSE useful for that use case rather than for the app to 
> programmagically pause a sending track (which can be indeed done via 
> track.enabled = false + signaling).
>
> El 31 oct. 2017 10:22, "Sergio Garcia Murillo" 
>  > escribió:
>
>     Hi Bernard,
>
>     I agree that late blooming is relatively rare, but I have to try.. ;)
>
>     Indeed RFC 7728 provides to different implementation for the
>     PAUSE/PAUSED:
>
>         This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
>         possible and defines a small set of new RTCP feedback messages where
>         new semantics is needed.
>
>     But it also states that:
>
>         As stated above, TMMBR/TMMBN may be used to provide pause and resume
>         functionality for the point-to-point case.  If the topology is not
>         point to point, TMMBR/TMMBN cannot safely be used for pause or
>         resume.
>
>
>     So, at least for the SFU case, the RFC 7728 recommends the usage
>     of the new RTCP messages, which does not require implementation of
>     TMMBR/TMMBN.
>
>     While I agree, that the PAUSE request could be more difficult to
>     implement and the use case could also be done "out off band", the
>     PAUSED indication is relatively trivial to implement and it is not
>     possible to be implemented any other way with current APIs.
>
>     Best regards
>     Sergio
>
>     On 30/10/2017 19:20, Bernard Aboba wrote:
>>     To consider support for PAUSE/PAUSED, it would be first be
>>     necessary to have implementations of TMMBR/TMMBN, since the
>>     PAUSE/PAUSED mechanism is based on that.
>>
>>     However, although TMMBR/TMMBN is required in RTP-Usage, it has
>>     not been widely implemented in WebRTC browsers. Part of the
>>     reason may have been that REMB was used for both bandwidth
>>     estimation as well as control, so TMMBR/TMMBN seemed like
>>     overlapping functionality. Although that argument would be less
>>     valid after the transition from REMB to transport-cc, experience
>>     tells us that "late blooming" protocol proposals are relatively
>>     rare.
>>
>>     On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings >     > wrote:
>>
>>
>>         I think this is a bit late to add something like 7728 as MTI
>>         to in the sort of "1.0" specs. Of course any browser could
>>         add support that that and it would work fine with WebRTC and
>>         it could be added to future specs.  Long ago when this was
>>         discussed, some people had concerns about
>>
>>         https://datatracker.ietf.org/ipr/1641/
>>         
>>
>>         and
>>
>>         https://datatracker.ietf.org/ipr/1935/
>>         
>>
>>
>>         > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo
>>         >         > wrote:
>>         >
>>         > Hi all,
>>         >
>>         > According to the rtp usage draft, it is allowed to pause
>>         and resume transmissions at any time. There are several
>>         scenarios in which it would make sense to signal when a
>>         webrtc sender decides to pause one stream to the receiving side.
>>         >
>>         > One of them, (as described in detail in
>>         https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207
>>         )
>>         is be when the webrtc endpoints decides to stop sending one
>>         simulcast stream in order to adapt the sent bandwidth to the
>>         bandwidth estimation. In that case the SFU would benefit from
>>         having that indication before having to wait for a timeout on
>>         media reception before switching to a different simulcast
>>         stream. Note that in this case, the stream is paused from
>>         inside the webrtc stack, so there is no event triggered to be
>>         able to signal this to the js app so it could notify it off
>>         band to the receiving side.
>>         >
>>         > From the solutions discussed, IMHO, the cleanest one would
>>         be to support the PAUSE indication from RFC7728. Do you think
>>         it could be considered to support it in webrtc?
>>         >
>>         > Best regards
>>         >
>>         > Sergio
>>         >
>>         > _______________________________________________
>>         > 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
>     
>


--------------FAEC619EB5B2304EE86D9174
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Please, re-read my email, as I am
      basically saying what you are stating.

      

      PAUSE request can be done out of band (track.enabled = false +
      signaling), PAUSED indication of simulcast layers can't be done
      with current APIs.

      

      BR

      Sergio

      

      On 31/10/2017 10:34, Iñaki Baz Castillo wrote:

    

    

      
I don't know how PAUSE could be implemented "out
        of band". In fact, the problem is that, currently, browsers stop
        a simulcast stream at any time without any indication at media
        or API layers. This is, I see RTCP PAUSE useful for that use
        case rather than for the app to programmagically pause a sending
        track (which can be indeed done via track.enabled = false +
        signaling).

      


        
El 31 oct. 2017 10:22, "Sergio Garcia
          Murillo" <sergio.garcia.murillo@gmail.com>
          escribió:

          

            

              
Hi
                Bernard,

                

                I agree that late blooming is relatively rare, but I
                have to try.. ;)

                

                Indeed RFC 7728 provides to different implementation for
                the PAUSE/PAUSED:

                

                
   This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



                But it also states that:

                

                
   As stated above, TMMBR/TMMBN may be used to provide pause and resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

                

                So, at least for the SFU case, the RFC 7728 recommends
                the usage of the new RTCP messages, which does not
                require implementation of TMMBR/TMMBN.

                

                While I agree, that the PAUSE request could be more
                difficult to implement and the use case could also be
                done "out off band", the PAUSED indication is relatively
                trivial to implement and it is not possible to be
                implemented any other way with current APIs.

                

                Best regards

                Sergio

                

                On 30/10/2017 19:20, Bernard Aboba wrote:

              

              

                
To consider support for PAUSE/PAUSED, it
                  would be first be necessary to have implementations of
                  TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is based
                  on that. 
                  


                  

                  
However, although TMMBR/TMMBN is required in
                    RTP-Usage, it has not been widely implemented in
                    WebRTC browsers. Part of the reason may have been
                    that REMB was used for both bandwidth estimation as
                    well as control, so TMMBR/TMMBN seemed like
                    overlapping functionality. Although that argument
                    would be less valid after the transition from REMB
                    to transport-cc, experience tells us that "late
                    blooming" protocol proposals are relatively rare. 

                  

                

                


                  
On Mon, Oct 30, 2017 at 8:02
                    AM, Cullen Jennings <fluffy@iii.ca>
                    wrote:

                    


                      I think this is a bit late to add something like
                      7728 as MTI to in the sort of "1.0" specs. Of
                      course any browser could add support that that and
                      it would work fine with WebRTC and it could be
                      added to future specs.  Long ago when this was
                      discussed, some people had concerns about

                      

                      https://datatracker.ietf.org/ipr/1641/

                      

                      and

                      

                      https://datatracker.ietf.org/ipr/1935/

                      

                        


                          

                          > On Oct 19, 2017, at 12:48 PM, Sergio
                          Garcia Murillo <sergio.garcia.murillo@gmail.com>
                          wrote:

                          >

                          > Hi all,

                          >

                          > According to the rtp usage draft, it is
                          allowed to pause and resume transmissions at
                          any time. There are several scenarios in which
                          it would make sense to signal when a webrtc
                          sender decides to pause one stream to the
                          receiving side.

                          >

                          > One of them, (as described in detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207)
                          is be when the webrtc endpoints decides to
                          stop sending one simulcast stream in order to
                          adapt the sent bandwidth to the bandwidth
                          estimation. In that case the SFU would benefit
                          from having that indication before having to
                          wait for a timeout on media reception before
                          switching to a different simulcast stream.
                          Note that in this case, the stream is paused
                          from inside the webrtc stack, so there is no
                          event triggered to be able to signal this to
                          the js app so it could notify it off band to
                          the receiving side.

                          >

                          > From the solutions discussed, IMHO, the
                          cleanest one would be to support the PAUSE
                          indication from RFC7728. Do you think it could
                          be considered to support it in webrtc?

                          >

                          > Best regards

                          >

                          > Sergio

                          >

                          > _______________________________________________

                          > 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

            

          

        

      

    

    


    

  


--------------FAEC619EB5B2304EE86D9174--


From nobody Tue Oct 31 03:07:19 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7980513A66B for ; Tue, 31 Oct 2017 03:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5TJ36Q1NQ_y for ; Tue, 31 Oct 2017 03:07:14 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 66939139428 for ; Tue, 31 Oct 2017 03:07:14 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id s66so21132569wmf.5 for ; Tue, 31 Oct 2017 03:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eVjnFO67eV/daaGn11KGY0BNpChaUVu5IvNlbHQZ0U8=; b=p7P+v69tOcGoqXsfL2tVgP07wZhjac9VLiIbpXzHURBWEJM+TmjaRBiaA2tn39qY6M 7cF9twRohuBTjHa9rRWHFQ5C/8DiYA+Oxcb3UW1YYzO9dPQxPMJnB/73U8hxBpDIT602 UJR4brsAqXDSj+tmvWzpQZ18/HgDSAGwfIGsrF5s8y4gXobf2RLrT0wh1XlESqGhmRu9 s2OIOpgzANi073H7UJ1a30LkIApjzZ6r/r8cpKJloyxosNNY51RNIyzntNbiHYFgtCPH T3chskdQb5Qw2LAy9lFd+wxnAtRo/nX+xfW2ZwRf/5KHdaCtc/KhqYRToCiJF4wg5rOI VO8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eVjnFO67eV/daaGn11KGY0BNpChaUVu5IvNlbHQZ0U8=; b=ASXLigKu1brtaL/Js3BMlNeyQ2ZbaUNIQ5QZqZCpZqaTayeKL76r3+pJhGWbunF3pQ RnMvzmKEf4QXbUei+qVoiZzpg+YS//LnKB2nh/C7RsYOEJPBMITYFxwfrqXn4r11u3+2 Kj7F4EXNP+xcf3LygvLrtvyDPxOHdJvMOhNkFcV+wj5OYyi9jb0qTf7bfeE2Br8baSrM t1zvI8tiursoMiJ7k+zm8CwmRSU/Fx8dhxgvRQPQy6eDb7uhh2AaehQhxIW/0wkZVHYa 7XQhkANGckjzaixcKO0cMtFJVR9d75PWAoHrlefMHfjUZe+g0Bm5dgO1f32MHQHz4T7n i0LQ==
X-Gm-Message-State: AMCzsaVmTRQ502l1hMd0UVie5xA2v/kDy1FDvUwqw4Qe4rUqoB0YiCYP ZZkyGB0Lrr6bJzyq0SJK0tiHEBdhS3VB1RhwuTuXXg==
X-Google-Smtp-Source: ABhQp+RVvfjM+kAORaUpKWpWtc7XhKVeHgKRyAF4DsE/zqZm4Qya+zy+WKdFqoDqgjv2KY47C69Iv5h4phzfGb1jhBA=
X-Received: by 10.80.137.91 with SMTP id f27mr2181192edf.18.1509444432770; Tue, 31 Oct 2017 03:07:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 03:07:11 -0700 (PDT)
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 03:07:11 -0700 (PDT)
In-Reply-To: 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 31 Oct 2017 11:07:11 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
Content-Type: multipart/alternative; boundary="f403045c1468394b27055cd4ebb2"
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 10:07:16 -0000

--f403045c1468394b27055cd4ebb2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I am trying to focus on the use case in which the browser decides to pause
a simulcast stream (typically the highest one) under changing CPU or
network conditions. The client side app does nothing to trigger that and
it's not even notified in any way, so this is not the "track.enabled=3Dfals=
e
+ signaling" usecase.

The use case I mean happens transparently and we need a RTCP PAUSE sent by
the browser to tell the receiver (SFU) about it.

El 31 oct. 2017 10:59, "Sergio Garcia Murillo" <
sergio.garcia.murillo@gmail.com> escribi=C3=B3:

> Please, re-read my email, as I am basically saying what you are stating.
>
> PAUSE request can be done out of band (track.enabled =3D false + signalin=
g),
> PAUSED indication of simulcast layers can't be done with current APIs.
>
> BR
> Sergio
>
> On 31/10/2017 10:34, I=C3=B1aki Baz Castillo wrote:
>
> I don't know how PAUSE could be implemented "out of band". In fact, the
> problem is that, currently, browsers stop a simulcast stream at any time
> without any indication at media or API layers. This is, I see RTCP PAUSE
> useful for that use case rather than for the app to programmagically paus=
e
> a sending track (which can be indeed done via track.enabled =3D false +
> signaling).
>
> El 31 oct. 2017 10:22, "Sergio Garcia Murillo" <
> sergio.garcia.murillo@gmail.com> escribi=C3=B3:
>
>> Hi Bernard,
>>
>> I agree that late blooming is relatively rare, but I have to try.. ;)
>>
>> Indeed RFC 7728 provides to different implementation for the PAUSE/PAUSE=
D:
>>
>>    This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
>>    possible and defines a small set of new RTCP feedback messages where
>>    new semantics is needed.
>>
>>
>> But it also states that:
>>
>>    As stated above, TMMBR/TMMBN may be used to provide pause and resume
>>    functionality for the point-to-point case.  If the topology is not
>>    point to point, TMMBR/TMMBN cannot safely be used for pause or
>>    resume.
>>
>>
>> So, at least for the SFU case, the RFC 7728 recommends the usage of the
>> new RTCP messages, which does not require implementation of TMMBR/TMMBN.
>>
>> While I agree, that the PAUSE request could be more difficult to
>> implement and the use case could also be done "out off band", the PAUSED
>> indication is relatively trivial to implement and it is not possible to =
be
>> implemented any other way with current APIs.
>>
>> Best regards
>> Sergio
>>
>> On 30/10/2017 19:20, Bernard Aboba wrote:
>>
>> To consider support for PAUSE/PAUSED, it would be first be necessary to
>> have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is
>> based on that.
>>
>> However, although TMMBR/TMMBN is required in RTP-Usage, it has not been
>> widely implemented in WebRTC browsers. Part of the reason may have been
>> that REMB was used for both bandwidth estimation as well as control, so
>> TMMBR/TMMBN seemed like overlapping functionality. Although that argumen=
t
>> would be less valid after the transition from REMB to transport-cc,
>> experience tells us that "late blooming" protocol proposals are relative=
ly
>> rare.
>>
>> On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings  wrote:
>>
>>>
>>> I think this is a bit late to add something like 7728 as MTI to in the
>>> sort of "1.0" specs. Of course any browser could add support that that =
and
>>> it would work fine with WebRTC and it could be added to future specs.  =
Long
>>> ago when this was discussed, some people had concerns about
>>>
>>> https://datatracker.ietf.org/ipr/1641/
>>>
>>> and
>>>
>>> https://datatracker.ietf.org/ipr/1935/
>>>
>>>
>>> > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <
>>> sergio.garcia.murillo@gmail.com> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > According to the rtp usage draft, it is allowed to pause and resume
>>> transmissions at any time. There are several scenarios in which it woul=
d
>>> make sense to signal when a webrtc sender decides to pause one stream t=
o
>>> the receiving side.
>>> >
>>> > One of them, (as described in detail in https://monorail-prod.appspot=
.
>>> com/p/webrtc/issues/detail?id=3D5207) is be when the webrtc endpoints
>>> decides to stop sending one simulcast stream in order to adapt the sent
>>> bandwidth to the bandwidth estimation. In that case the SFU would benef=
it
>>> from having that indication before having to wait for a timeout on medi=
a
>>> reception before switching to a different simulcast stream. Note that i=
n
>>> this case, the stream is paused from inside the webrtc stack, so there =
is
>>> no event triggered to be able to signal this to the js app so it could
>>> notify it off band to the receiving side.
>>> >
>>> > From the solutions discussed, IMHO, the cleanest one would be to
>>> support the PAUSE indication from RFC7728. Do you think it could be
>>> considered to support it in webrtc?
>>> >
>>> > Best regards
>>> >
>>> > Sergio
>>> >
>>> > _______________________________________________
>>> > 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
>>
>>
>

--f403045c1468394b27055cd4ebb2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am trying to focus on the use case in which the browser=
 decides to pause a simulcast stream (typically the highest one) under chan=
ging CPU or network conditions. The client side app does nothing to trigger=
 that and it's not even notified in any way, so this is not the "t=
rack.enabled=3Dfalse + signaling" usecase.

=

The use case I mean happens transparently and we need a R=
TCP PAUSE sent by the browser to tell the receiver (SFU) about it.

El 31 oct. 201=
7 10:59, "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com> escribi=C3=
=B3:

 =20
   =20
 =20
  

    
Please, re-read my=
 email, as I am
      basically saying what you are stating.

      

      PAUSE request can be done out of band (track.enabled =3D false +
      signaling), PAUSED indication of simulcast layers can't be done
      with current APIs.

      

      BR

      Sergio

      

      On 31/10/2017 10:34, I=C3=B1aki Baz Castillo wrote:

    

    

      
I don't know how PAUSE could be implemented &qu=
ot;out
        of band". In fact, the problem is that, currently, browsers st=
op
        a simulcast stream at any time without any indication at media
        or API layers. This is, I see RTCP PAUSE useful for that use
        case rather than for the app to programmagically pause a sending
        track (which can be indeed done via track.enabled =3D false +
        signaling).

      


        
El 31 oct. 2017 10:22, "Sergio Garc=
ia
          Murillo" <sergio.garcia.murillo@gmail.com>
          escribi=C3=B3:

          

            

              
Hi
                Bernard,

                

                I agree that late blooming is relatively rare, but I
                have to try.. ;)

                

                Indeed RFC 7728 provides to different implementation for
                the PAUSE/PAUSED:

                

                
   This solution reuses CCM TMMBR and TMMBN=
 [RFC5104] to the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



                But it also states that:

                

                
   As stated above, TMMBR/TMMBN may be used=
 to provide pause and resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

                

                So, at least for the SFU case, the RFC 7728 recommends
                the usage of the new RTCP messages, which does not
                require implementation of TMMBR/TMMBN.

                

                While I agree, that the PAUSE request could be more
                difficult to implement and the use case could also be
                done "out off band", the PAUSED indication is rel=
atively
                trivial to implement and it is not possible to be
                implemented any other way with current APIs.

                

                Best regards

                Sergio

                

                On 30/10/2017 19:20, Bernard Aboba wrote:

              

              

                
To consider support for PAUSE/PAUSED, it
                  would be first be necessary to have implementations of
                  TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is based
                  on that.=C2=A0
                  


                  

                  
However, although TMMBR/TMMBN is required in
                    RTP-Usage,=C2=A0it has not been widely implemented in
                    WebRTC browsers. Part of the reason may have been
                    that REMB was used for both bandwidth estimation as
                    well as control, so TMMBR/TMMBN seemed like
                    overlapping functionality. Although that argument
                    would be less valid after the transition from REMB
                    to transport-cc, experience tells us that "late
                    blooming" protocol proposals are relatively rare.=
=C2=A0

                  

                

                


                  
On Mon, Oct 30, 2017 at 8:02
                    AM, Cullen Jennings <fluffy@iii.ca>
                    wrote:

                    


                      I think this is a bit late to add something like
                      7728 as MTI to in the sort of "1.0" specs. =
Of
                      course any browser could add support that that and
                      it would work fine with WebRTC and it could be
                      added to future specs.=C2=A0 Long ago when this was
                      discussed, some people had concerns about

                      

                      https://datatracker.ietf.org/ipr/16=
41/

                      

                      and

                      

                      https://datatracker.ietf.org/ipr/19=
35/

                      

                        


                          

                          > On Oct 19, 2017, at 12:48 PM, Sergio
                          Garcia Murillo <sergio.garcia.murillo@gmail.com=
>
                          wrote:

                          >

                          > Hi all,

                          >

                          > According to the rtp usage draft, it is
                          allowed to pause and resume transmissions at
                          any time. There are several scenarios in which
                          it would make sense to signal when a webrtc
                          sender decides to pause one stream to the
                          receiving side.

                          >

                          > One of them, (as described in detail in https://monorail-prod.appspot.com=
/p/webrtc/issues/detail?id=3D5207)
                          is be when the webrtc endpoints decides to
                          stop sending one simulcast stream in order to
                          adapt the sent bandwidth to the bandwidth
                          estimation. In that case the SFU would benefit
                          from having that indication before having to
                          wait for a timeout on media reception before
                          switching to a different simulcast stream.
                          Note that in this case, the stream is paused
                          from inside the webrtc stack, so there is no
                          event triggered to be able to signal this to
                          the js app so it could notify it off band to
                          the receiving side.

                          >

                          > From the solutions discussed, IMHO, the
                          cleanest one would be to support the PAUSE
                          indication from RFC7728. Do you think it could
                          be considered to support it in webrtc?

                          >

                          > Best regards

                          >

                          > Sergio

                          >

                          > _______________________________________=
________

                          > rtcweb mailing list

                          > rtcweb@ietf.org

                          > https://www.ietf.org/mail=
man/listinfo/rtcweb

                          

                          ____________________________________________=
___

                          rtcweb mailing list

                          rtcweb@ietf.org

                          https://www.ietf.org/mailman/l=
istinfo/rtcweb

                        

                      

                    

                  

                  

                

              

              


              

            

            

            _______________________________________________

            rtcweb mailing list

            rtcweb@iet=
f.org

            https://www.ietf.org/mailman/listinfo/r=
tcweb

            

          

        

      

    

    


    

  





--f403045c1468394b27055cd4ebb2--


From nobody Tue Oct 31 03:11:04 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7099C13F50A for ; Tue, 31 Oct 2017 03:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ictwRv5aZ0zV for ; Tue, 31 Oct 2017 03:11:02 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 265BB13F634 for ; Tue, 31 Oct 2017 03:11:01 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id y80so14428114wmd.0 for ; Tue, 31 Oct 2017 03:11:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=V4Uh4F5cmoHelAvVOClOJeqtMqVnpJ2BTmAoA7Qm3zg=; b=njYg4tLbJQUV2YsuZXH9BQMmNLPr2jplCCll8EQNWdhQu17zoKHI6gYjTm3cAL7m8l OEFzLvVu0H+NqzziiiLZccw2wyyuGnbMTe/jJoQn0JP+WgOQB72vVWdiFEYBxrEOO1Vy NQ7cbv6nxZc8bGfRcg7pOyTa1iTu7Zpw0EytFqweErgBi4+WGzSgDavbKNcAsAo/zz2/ +LGOUyIuxxSIMuhm4qwf3hVvPeBn5ar6Lvw7yQ2EFszV7+iUDxbiy1LFoAPgpWZPQrLk agrzlKDuuv3OTxNaLZPFbgIHiR2Sfk+mfwln65zcuotZciK5C9kn8nXXWjngaFS2lw0T 2rmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=V4Uh4F5cmoHelAvVOClOJeqtMqVnpJ2BTmAoA7Qm3zg=; b=Vr8bkWI7J8j6wthKIX1ledxVznNgxwwmHxLc3aS2ZBtzMyFmHRToVilh9qzKw+b7xr q4k1PLEjkP0zB4KZ63U1grVYi5GRAf7TJyl2FT0QfipajDMBifs6JS+UeoAJwH46tF9y tRMKEdsYqw29GF38XfKYhqnBOF71V6Tg8dW57w7qGMvbzCGcuWdaPWWTt9bKLW/YME1P WoNWcCU8XLT3zk8UT5NLy6grs41ymy48WhCDztZaPuhCTJgwhjtI9S+u+vAvnlOzkfr9 eTRFDT+nicYcp+TN7IX1nyr7nqv0ruGInBaUpOKkgNp2nJWtzyiJje5vvLr9oALMEl53 OdyQ==
X-Gm-Message-State: AMCzsaVxLKDdoCPXUy2HI7KNQlGjXzGv1LjSON1WratiTmlsmiIhpwEQ o+AtGKzwHHTN3ixIxornQ9SfXMkF
X-Google-Smtp-Source: ABhQp+QHAXwkrjBN5k2BJoBTf/4AKhUxrr6mlocXfuUWslHd7CbfOSUTpjGxlX7d0dKvveFgWqgscw==
X-Received: by 10.80.145.6 with SMTP id e6mr2270461eda.34.1509444659138; Tue, 31 Oct 2017 03:10:59 -0700 (PDT)
Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id c5sm995082edd.38.2017.10.31.03.10.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 03:10:58 -0700 (PDT)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>   
From: Sergio Garcia Murillo 
Message-ID: <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com>
Date: Tue, 31 Oct 2017 11:10:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DC3DBE31165CA35700725C73"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 10:11:04 -0000

This is a multi-part message in MIME format.
--------------DC3DBE31165CA35700725C73
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

No, you need a rtcp PAUSED indication, not an rtcp PAUSE request:

    An RTP stream sender can choose to pause the stream at any time.
    This can be either a result of receiving a PAUSE or based on some
    local sender consideration.  When it does, it sends a PAUSED
    indication, containing the current PauseID.  Note that the current
    PauseID in an unsolicited PAUSED (without having received a PAUSE) is
    incremented compared to a previously sent PAUSED.  It also sends the
    PAUSED indication in the next two regular RTCP reports, given that
    the pause condition is then still effective.


Best regards
Sergio

On 31/10/2017 11:07, Iñaki Baz Castillo wrote:
> I am trying to focus on the use case in which the browser decides to 
> pause a simulcast stream (typically the highest one) under changing 
> CPU or network conditions. The client side app does nothing to trigger 
> that and it's not even notified in any way, so this is not the 
> "track.enabled=false + signaling" usecase.
>
> The use case I mean happens transparently and we need a RTCP PAUSE 
> sent by the browser to tell the receiver (SFU) about it.
>
> El 31 oct. 2017 10:59, "Sergio Garcia Murillo" 
>  > escribió:
>
>     Please, re-read my email, as I am basically saying what you are
>     stating.
>
>     PAUSE request can be done out of band (track.enabled = false +
>     signaling), PAUSED indication of simulcast layers can't be done
>     with current APIs.
>
>     BR
>     Sergio
>
>     On 31/10/2017 10:34, Iñaki Baz Castillo wrote:
>>     I don't know how PAUSE could be implemented "out of band". In
>>     fact, the problem is that, currently, browsers stop a simulcast
>>     stream at any time without any indication at media or API layers.
>>     This is, I see RTCP PAUSE useful for that use case rather than
>>     for the app to programmagically pause a sending track (which can
>>     be indeed done via track.enabled = false + signaling).
>>
>>     El 31 oct. 2017 10:22, "Sergio Garcia Murillo"
>>     >     > escribió:
>>
>>         Hi Bernard,
>>
>>         I agree that late blooming is relatively rare, but I have to
>>         try.. ;)
>>
>>         Indeed RFC 7728 provides to different implementation for the
>>         PAUSE/PAUSED:
>>
>>             This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
>>             possible and defines a small set of new RTCP feedback messages where
>>             new semantics is needed.
>>
>>         But it also states that:
>>
>>             As stated above, TMMBR/TMMBN may be used to provide pause and resume
>>             functionality for the point-to-point case.  If the topology is not
>>             point to point, TMMBR/TMMBN cannot safely be used for pause or
>>             resume.
>>
>>
>>         So, at least for the SFU case, the RFC 7728 recommends the
>>         usage of the new RTCP messages, which does not require
>>         implementation of TMMBR/TMMBN.
>>
>>         While I agree, that the PAUSE request could be more difficult
>>         to implement and the use case could also be done "out off
>>         band", the PAUSED indication is relatively trivial to
>>         implement and it is not possible to be implemented any other
>>         way with current APIs.
>>
>>         Best regards
>>         Sergio
>>
>>         On 30/10/2017 19:20, Bernard Aboba wrote:
>>>         To consider support for PAUSE/PAUSED, it would be first be
>>>         necessary to have implementations of TMMBR/TMMBN, since the
>>>         PAUSE/PAUSED mechanism is based on that.
>>>
>>>         However, although TMMBR/TMMBN is required in RTP-Usage, it
>>>         has not been widely implemented in WebRTC browsers. Part of
>>>         the reason may have been that REMB was used for both
>>>         bandwidth estimation as well as control, so TMMBR/TMMBN
>>>         seemed like overlapping functionality. Although that
>>>         argument would be less valid after the transition from REMB
>>>         to transport-cc, experience tells us that "late blooming"
>>>         protocol proposals are relatively rare.
>>>
>>>         On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings
>>>         > wrote:
>>>
>>>
>>>             I think this is a bit late to add something like 7728 as
>>>             MTI to in the sort of "1.0" specs. Of course any browser
>>>             could add support that that and it would work fine with
>>>             WebRTC and it could be added to future specs.  Long ago
>>>             when this was discussed, some people had concerns about
>>>
>>>             https://datatracker.ietf.org/ipr/1641/
>>>             
>>>
>>>             and
>>>
>>>             https://datatracker.ietf.org/ipr/1935/
>>>             
>>>
>>>
>>>             > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo
>>>             >>             > wrote:
>>>             >
>>>             > Hi all,
>>>             >
>>>             > According to the rtp usage draft, it is allowed to
>>>             pause and resume transmissions at any time. There are
>>>             several scenarios in which it would make sense to signal
>>>             when a webrtc sender decides to pause one stream to the
>>>             receiving side.
>>>             >
>>>             > One of them, (as described in detail in
>>>             https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207
>>>             )
>>>             is be when the webrtc endpoints decides to stop sending
>>>             one simulcast stream in order to adapt the sent
>>>             bandwidth to the bandwidth estimation. In that case the
>>>             SFU would benefit from having that indication before
>>>             having to wait for a timeout on media reception before
>>>             switching to a different simulcast stream. Note that in
>>>             this case, the stream is paused from inside the webrtc
>>>             stack, so there is no event triggered to be able to
>>>             signal this to the js app so it could notify it off band
>>>             to the receiving side.
>>>             >
>>>             > From the solutions discussed, IMHO, the cleanest one
>>>             would be to support the PAUSE indication from RFC7728.
>>>             Do you think it could be considered to support it in webrtc?
>>>             >
>>>             > Best regards
>>>             >
>>>             > Sergio
>>>             >
>>>             > _______________________________________________
>>>             > 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
>>         
>>
>


--------------DC3DBE31165CA35700725C73
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
No, you need a rtcp PAUSED indication,
      not an rtcp PAUSE request:

      

      
   An RTP stream sender can choose to pause the stream at any time.
   This can be either a result of receiving a PAUSE or based on some
   local sender consideration.  When it does, it sends a PAUSED
   indication, containing the current PauseID.  Note that the current
   PauseID in an unsolicited PAUSED (without having received a PAUSE) is
   incremented compared to a previously sent PAUSED.  It also sends the
   PAUSED indication in the next two regular RTCP reports, given that
   the pause condition is then still effective.

      

      Best regards

      Sergio

      

      On 31/10/2017 11:07, Iñaki Baz Castillo wrote:

    

    

      
I am trying to focus on the use case in which the
        browser decides to pause a simulcast stream (typically the
        highest one) under changing CPU or network conditions. The
        client side app does nothing to trigger that and it's not even
        notified in any way, so this is not the "track.enabled=false +
        signaling" usecase.
        


        

        
The use case I mean happens transparently and we
          need a RTCP PAUSE sent by the browser to tell the receiver
          (SFU) about it.

      

      


        
El 31 oct. 2017 10:59, "Sergio Garcia
          Murillo" <sergio.garcia.murillo@gmail.com>
          escribió:

          

            

              
Please,
                re-read my email, as I am basically saying what you are
                stating.

                

                PAUSE request can be done out of band (track.enabled =
                false + signaling), PAUSED indication of simulcast
                layers can't be done with current APIs.

                

                BR

                Sergio

                

                On 31/10/2017 10:34, Iñaki Baz Castillo wrote:

              

              

                
I don't know how PAUSE could be
                  implemented "out of band". In fact, the problem is
                  that, currently, browsers stop a simulcast stream at
                  any time without any indication at media or API
                  layers. This is, I see RTCP PAUSE useful for that use
                  case rather than for the app to programmagically pause
                  a sending track (which can be indeed done via
                  track.enabled = false + signaling).

                


                  
El 31 oct. 2017 10:22,
                    "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>
                    escribió:

                    

                      

                        
Hi
                          Bernard,

                          

                          I agree that late blooming is relatively rare,
                          but I have to try.. ;)

                          

                          Indeed RFC 7728 provides to different
                          implementation for the PAUSE/PAUSED:

                          

                          
   This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



                          But it also states that:

                          

                          
   As stated above, TMMBR/TMMBN may be used to provide pause and resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

                          

                          So, at least for the SFU case, the RFC 7728
                          recommends the usage of the new RTCP messages,
                          which does not require implementation of
                          TMMBR/TMMBN.

                          

                          While I agree, that the PAUSE request could be
                          more difficult to implement and the use case
                          could also be done "out off band", the PAUSED
                          indication is relatively trivial to implement
                          and it is not possible to be implemented any
                          other way with current APIs.

                          

                          Best regards

                          Sergio

                          

                          On 30/10/2017 19:20, Bernard Aboba wrote:

                        

                        

                          
To consider support for
                            PAUSE/PAUSED, it would be first be necessary
                            to have implementations of TMMBR/TMMBN,
                            since the PAUSE/PAUSED mechanism is based on
                            that. 
                            


                            

                            
However, although TMMBR/TMMBN is
                              required in RTP-Usage, it has not been
                              widely implemented in WebRTC browsers.
                              Part of the reason may have been that REMB
                              was used for both bandwidth estimation as
                              well as control, so TMMBR/TMMBN seemed
                              like overlapping functionality. Although
                              that argument would be less valid after
                              the transition from REMB to transport-cc,
                              experience tells us that "late blooming"
                              protocol proposals are relatively rare. 

                            

                          

                          


                            
On Mon, Oct 30,
                              2017 at 8:02 AM, Cullen Jennings <fluffy@iii.ca>
                              wrote:

                              


                                I think this is a bit late to add
                                something like 7728 as MTI to in the
                                sort of "1.0" specs. Of course any
                                browser could add support that that and
                                it would work fine with WebRTC and it
                                could be added to future specs.  Long
                                ago when this was discussed, some people
                                had concerns about

                                

                                https://datatracker.ietf.org/ipr/1641/

                                

                                and

                                

                                https://datatracker.ietf.org/ipr/1935/

                                

                                  


                                    

                                    > On Oct 19, 2017, at 12:48 PM,
                                    Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
                                    wrote:

                                    >

                                    > Hi all,

                                    >

                                    > According to the rtp usage
                                    draft, it is allowed to pause and
                                    resume transmissions at any time.
                                    There are several scenarios in which
                                    it would make sense to signal when a
                                    webrtc sender decides to pause one
                                    stream to the receiving side.

                                    >

                                    > One of them, (as described in
                                    detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207)
                                    is be when the webrtc endpoints
                                    decides to stop sending one
                                    simulcast stream in order to adapt
                                    the sent bandwidth to the bandwidth
                                    estimation. In that case the SFU
                                    would benefit from having that
                                    indication before having to wait for
                                    a timeout on media reception before
                                    switching to a different simulcast
                                    stream. Note that in this case, the
                                    stream is paused from inside the
                                    webrtc stack, so there is no event
                                    triggered to be able to signal this
                                    to the js app so it could notify it
                                    off band to the receiving side.

                                    >

                                    > From the solutions discussed,
                                    IMHO, the cleanest one would be to
                                    support the PAUSE indication from
                                    RFC7728. Do you think it could be
                                    considered to support it in webrtc?

                                    >

                                    > Best regards

                                    >

                                    > Sergio

                                    >

                                    > _______________________________________________

                                    > 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

                      

                    

                  

                

              

              


              

            

          

        

      

    

    


    

  


--------------DC3DBE31165CA35700725C73--


From nobody Tue Oct 31 03:21:41 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DBC139B9F for ; Tue, 31 Oct 2017 03:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k66stqRiDVU9 for ; Tue, 31 Oct 2017 03:21:37 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 239C213F5E1 for ; Tue, 31 Oct 2017 03:21:37 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id s66so21226386wmf.5 for ; Tue, 31 Oct 2017 03:21:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EJimuSTZHPpxAJ/0aLqRv16nARhHTIsgRoKOkANgtxM=; b=W3STJaV5iHDV8kQbZHRi3E8WzOtY35d1IuE66FsOTpOfFZXDChjjkPYeFHwuKDjKju EbMJdi1wxSJFNmoAkIKnYKY+lH/WhvJN3+3TizyFo+ATEG4uTII1dsvXWPT4fQNuf3VT 7V7h/2GiEA74bbXBFB6sfLDuoPD4hmdjM+a14Xd6qbof2x1kPKPBVYtTbapNc35Xk0Or tDz3M7KgM3SRfp1XJQDCOW0z/wQIm9TI/D+ALvWuMfGwqY+A9quLR5eUGgEa7nYu1ELD ovHRISAEyuY5ODESbsLwbHAyYx9AuAqfYDsdg5KN58oXaeStQUHnUZH2rDjxx/J9j1mY F4BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EJimuSTZHPpxAJ/0aLqRv16nARhHTIsgRoKOkANgtxM=; b=OMp6Avta2egX2ehkfBuE8UptfVeHAa255XbbUo8ISqbYAJv8W/GizmjKBqh0H6aYHb GSR993wbcehhtfF/yOEwRBvkCc+gXNiudZSbZoy5nh/y5sp7tyu9T6FwBT8wzHoaCPU9 Gi4Z6FFQRf/fdL0kL0AmP94ftoVI2ht0ia1yMsHwt9F6gdmXP/3WZMK12Hpcw+5olQnS R4n9nBy4vfJXI66h63p5fPHzXZMEpjCEbefMpnodFK61yUITFU91EPVS/OJ1kkSOXdFx nsdvZVVai3AvTLt9TkkA+DOo6fqz9ZoLanX4E03Vk8rMLSVpDDbt4O0C8vxF/0L1vz4s QMAw==
X-Gm-Message-State: AMCzsaVWE+wJkrgnqR/0HlM5CnqCjbgm52OjtGkPOtY85xgApE5qz+NH KUgcc7ysTYg+RoS2do3o8CmM+rX4N7N317vTj+/5vA==
X-Google-Smtp-Source: ABhQp+TYrVxwR+dnj6Tn5wogmGGXjWuTA5ZOCe7i2eWjKuT8P6oD9tKo956Zl2FroQflJFHSK6TdyBwGkFLWBq/JHZ4=
X-Received: by 10.80.194.146 with SMTP id o18mr2221624edf.19.1509445295596; Tue, 31 Oct 2017 03:21:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 03:21:34 -0700 (PDT)
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 03:21:34 -0700 (PDT)
In-Reply-To: <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com>
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>    <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 31 Oct 2017 11:21:34 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
Content-Type: multipart/alternative; boundary="94eb2c1ccc90a6f77b055cd51ee2"
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 10:21:40 -0000

--94eb2c1ccc90a6f77b055cd51ee2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Oh yes, wording issue here, sorry.

So we all mean the unsolicited PAUSED sent by the browser.



El 31 oct. 2017 11:10, "Sergio Garcia Murillo" <
sergio.garcia.murillo@gmail.com> escribi=C3=B3:

> No, you need a rtcp PAUSED indication, not an rtcp PAUSE request:
>
>    An RTP stream sender can choose to pause the stream at any time.
>    This can be either a result of receiving a PAUSE or based on some
>    local sender consideration.  When it does, it sends a PAUSED
>    indication, containing the current PauseID.  Note that the current
>    PauseID in an unsolicited PAUSED (without having received a PAUSE) is
>    incremented compared to a previously sent PAUSED.  It also sends the
>    PAUSED indication in the next two regular RTCP reports, given that
>    the pause condition is then still effective.
>
>
> Best regards
> Sergio
>
> On 31/10/2017 11:07, I=C3=B1aki Baz Castillo wrote:
>
> I am trying to focus on the use case in which the browser decides to paus=
e
> a simulcast stream (typically the highest one) under changing CPU or
> network conditions. The client side app does nothing to trigger that and
> it's not even notified in any way, so this is not the "track.enabled=3Dfa=
lse
> + signaling" usecase.
>
> The use case I mean happens transparently and we need a RTCP PAUSE sent b=
y
> the browser to tell the receiver (SFU) about it.
>
> El 31 oct. 2017 10:59, "Sergio Garcia Murillo" <
> sergio.garcia.murillo@gmail.com> escribi=C3=B3:
>
>> Please, re-read my email, as I am basically saying what you are stating.
>>
>> PAUSE request can be done out of band (track.enabled =3D false +
>> signaling), PAUSED indication of simulcast layers can't be done with
>> current APIs.
>>
>> BR
>> Sergio
>>
>> On 31/10/2017 10:34, I=C3=B1aki Baz Castillo wrote:
>>
>> I don't know how PAUSE could be implemented "out of band". In fact, the
>> problem is that, currently, browsers stop a simulcast stream at any time
>> without any indication at media or API layers. This is, I see RTCP PAUSE
>> useful for that use case rather than for the app to programmagically pau=
se
>> a sending track (which can be indeed done via track.enabled =3D false +
>> signaling).
>>
>> El 31 oct. 2017 10:22, "Sergio Garcia Murillo" <
>> sergio.garcia.murillo@gmail.com> escribi=C3=B3:
>>
>>> Hi Bernard,
>>>
>>> I agree that late blooming is relatively rare, but I have to try.. ;)
>>>
>>> Indeed RFC 7728 provides to different implementation for the
>>> PAUSE/PAUSED:
>>>
>>>    This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
>>>    possible and defines a small set of new RTCP feedback messages where
>>>    new semantics is needed.
>>>
>>>
>>> But it also states that:
>>>
>>>    As stated above, TMMBR/TMMBN may be used to provide pause and resume
>>>    functionality for the point-to-point case.  If the topology is not
>>>    point to point, TMMBR/TMMBN cannot safely be used for pause or
>>>    resume.
>>>
>>>
>>> So, at least for the SFU case, the RFC 7728 recommends the usage of the
>>> new RTCP messages, which does not require implementation of TMMBR/TMMBN=
.
>>>
>>> While I agree, that the PAUSE request could be more difficult to
>>> implement and the use case could also be done "out off band", the PAUSE=
D
>>> indication is relatively trivial to implement and it is not possible to=
 be
>>> implemented any other way with current APIs.
>>>
>>> Best regards
>>> Sergio
>>>
>>> On 30/10/2017 19:20, Bernard Aboba wrote:
>>>
>>> To consider support for PAUSE/PAUSED, it would be first be necessary to
>>> have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED mechanism i=
s
>>> based on that.
>>>
>>> However, although TMMBR/TMMBN is required in RTP-Usage, it has not been
>>> widely implemented in WebRTC browsers. Part of the reason may have been
>>> that REMB was used for both bandwidth estimation as well as control, so
>>> TMMBR/TMMBN seemed like overlapping functionality. Although that argume=
nt
>>> would be less valid after the transition from REMB to transport-cc,
>>> experience tells us that "late blooming" protocol proposals are relativ=
ely
>>> rare.
>>>
>>> On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings  wrote:
>>>
>>>>
>>>> I think this is a bit late to add something like 7728 as MTI to in the
>>>> sort of "1.0" specs. Of course any browser could add support that that=
 and
>>>> it would work fine with WebRTC and it could be added to future specs. =
 Long
>>>> ago when this was discussed, some people had concerns about
>>>>
>>>> https://datatracker.ietf.org/ipr/1641/
>>>>
>>>> and
>>>>
>>>> https://datatracker.ietf.org/ipr/1935/
>>>>
>>>>
>>>> > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <
>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>> >
>>>> > Hi all,
>>>> >
>>>> > According to the rtp usage draft, it is allowed to pause and resume
>>>> transmissions at any time. There are several scenarios in which it wou=
ld
>>>> make sense to signal when a webrtc sender decides to pause one stream =
to
>>>> the receiving side.
>>>> >
>>>> > One of them, (as described in detail in
>>>> https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=3D5207) is
>>>> be when the webrtc endpoints decides to stop sending one simulcast str=
eam
>>>> in order to adapt the sent bandwidth to the bandwidth estimation. In t=
hat
>>>> case the SFU would benefit from having that indication before having t=
o
>>>> wait for a timeout on media reception before switching to a different
>>>> simulcast stream. Note that in this case, the stream is paused from in=
side
>>>> the webrtc stack, so there is no event triggered to be able to signal =
this
>>>> to the js app so it could notify it off band to the receiving side.
>>>> >
>>>> > From the solutions discussed, IMHO, the cleanest one would be to
>>>> support the PAUSE indication from RFC7728. Do you think it could be
>>>> considered to support it in webrtc?
>>>> >
>>>> > Best regards
>>>> >
>>>> > Sergio
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>
>>>
>>
>

--94eb2c1ccc90a6f77b055cd51ee2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Oh yes, wording issue here, sorry.

<=
/div>
So we all mean the unsolicited PAUSED sent by the br=
owser.



El 31 oct. 201=
7 11:10, "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com> escribi=C3=
=B3:

 =20
   =20
 =20
  

    
No, you need a rtc=
p PAUSED indication,
      not an rtcp PAUSE request:

      

      
=
   An RTP stream sender can choose to pause the stream at any time.
   This can be either a result of receiving a PAUSE or based on some
   local sender consideration.  When it does, it sends a PAUSED
   indication, containing the current PauseID.  Note that the current
   PauseID in an unsolicited PAUSED (without having received a PAUSE) is
   incremented compared to a previously sent PAUSED.  It also sends the
   PAUSED indication in the next two regular RTCP reports, given that
   the pause condition is then still effective.

      

      Best regards

      Sergio

      

      On 31/10/2017 11:07, I=C3=B1aki Baz Castillo wrote:

    

    

      
I am trying to focus on the use case in which the
        browser decides to pause a simulcast stream (typically the
        highest one) under changing CPU or network conditions. The
        client side app does nothing to trigger that and it's not even
        notified in any way, so this is not the "track.enabled=3Dfalse=
 +
        signaling" usecase.
        


        

        
The use case I mean happens transparently and we
          need a RTCP PAUSE sent by the browser to tell the receiver
          (SFU) about it.

      

      


        
El 31 oct. 2017 10:59, "Sergio Garc=
ia
          Murillo" <sergio.garcia.murillo@gmail.com>
          escribi=C3=B3:

          

            

              
Please,
                re-read my email, as I am basically saying what you are
                stating.

                

                PAUSE request can be done out of band (track.enabled =3D
                false + signaling), PAUSED indication of simulcast
                layers can't be done with current APIs.

                

                BR

                Sergio

                

                On 31/10/2017 10:34, I=C3=B1aki Baz Castillo wrote:

              

              

                
I don't know how PAUSE could be
                  implemented "out of band". In fact, the problem=
 is
                  that, currently, browsers stop a simulcast stream at
                  any time without any indication at media or API
                  layers. This is, I see RTCP PAUSE useful for that use
                  case rather than for the app to programmagically pause
                  a sending track (which can be indeed done via
                  track.enabled =3D false + signaling).

                


                  
El 31 oct. 2017 10:22,
                    "Sergio Garcia Murillo" <sergio.garcia.murillo@g=
mail.com>
                    escribi=C3=B3:

                    

                      

                        
Hi
                          Bernard,

                          

                          I agree that late blooming is relatively rare,
                          but I have to try.. ;)

                          

                          Indeed RFC 7728 provides to different
                          implementation for the PAUSE/PAUSED:

                          

                          
   This sol=
ution reuses CCM TMMBR and TMMBN [RFC5104] to the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



                          But it also states that:

                          

                          
   As state=
d above, TMMBR/TMMBN may be used to provide pause and resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

                          

                          So, at least for the SFU case, the RFC 7728
                          recommends the usage of the new RTCP messages,
                          which does not require implementation of
                          TMMBR/TMMBN.

                          

                          While I agree, that the PAUSE request could be
                          more difficult to implement and the use case
                          could also be done "out off band", the =
PAUSED
                          indication is relatively trivial to implement
                          and it is not possible to be implemented any
                          other way with current APIs.

                          

                          Best regards

                          Sergio

                          

                          On 30/10/2017 19:20, Bernard Aboba wrote:

                        

                        

                          
To consider support for
                            PAUSE/PAUSED, it would be first be necessary
                            to have implementations of TMMBR/TMMBN,
                            since the PAUSE/PAUSED mechanism is based on
                            that.=C2=A0
                            


                            

                            
However, although TMMBR/TMMBN is
                              required in RTP-Usage,=C2=A0it has not been
                              widely implemented in WebRTC browsers.
                              Part of the reason may have been that REMB
                              was used for both bandwidth estimation as
                              well as control, so TMMBR/TMMBN seemed
                              like overlapping functionality. Although
                              that argument would be less valid after
                              the transition from REMB to transport-cc,
                              experience tells us that "late blooming&=
quot;
                              protocol proposals are relatively rare.=C2=A0=


                            

                          

                          


                            
On Mon, Oct 30,
                              2017 at 8:02 AM, Cullen Jennings <fluffy@iii.ca<=
/a>>
                              wrote:

                              


                                I think this is a bit late to add
                                something like 7728 as MTI to in the
                                sort of "1.0" specs. Of course an=
y
                                browser could add support that that and
                                it would work fine with WebRTC and it
                                could be added to future specs.=C2=A0 Long
                                ago when this was discussed, some people
                                had concerns about

                                

                                https://datatracker.ietf.org/i=
pr/1641/

                                

                                and

                                

                                https://datatracker.ietf.org/i=
pr/1935/

                                

                                  


                                    

                                    > On Oct 19, 2017, at 12:48 PM,
                                    Sergio Garcia Murillo <sergio.garcia.muril=
lo@gmail.com>
                                    wrote:

                                    >

                                    > Hi all,

                                    >

                                    > According to the rtp usage
                                    draft, it is allowed to pause and
                                    resume transmissions at any time.
                                    There are several scenarios in which
                                    it would make sense to signal when a
                                    webrtc sender decides to pause one
                                    stream to the receiving side.

                                    >

                                    > One of them, (as described in
                                    detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?i=
d=3D5207)
                                    is be when the webrtc endpoints
                                    decides to stop sending one
                                    simulcast stream in order to adapt
                                    the sent bandwidth to the bandwidth
                                    estimation. In that case the SFU
                                    would benefit from having that
                                    indication before having to wait for
                                    a timeout on media reception before
                                    switching to a different simulcast
                                    stream. Note that in this case, the
                                    stream is paused from inside the
                                    webrtc stack, so there is no event
                                    triggered to be able to signal this
                                    to the js app so it could notify it
                                    off band to the receiving side.

                                    >

                                    > From the solutions discussed,
                                    IMHO, the cleanest one would be to
                                    support the PAUSE indication from
                                    RFC7728. Do you think it could be
                                    considered to support it in webrtc?

                                    >

                                    > Best regards

                                    >

                                    > Sergio

                                    >

                                    > _______________________________________________

                                    > rtcweb mailing list

                                    > rtcweb@ietf.org

                                    > https://www.iet=
f.org/mailman/listinfo/rtcweb

                                    

                                    __________________________________=
_____________

                                    rtcweb mailing list

                                    rtcweb@ietf.org

                                    https://www.ietf.org=
/mailman/listinfo/rtcweb

                                  

                                

                              

                            

                            

                          

                        

                        


                        

                      

                      

                      _______________________________________________<=
br>
                      rtcweb mailing list

                      =
rtcweb@ietf.org

                      https://www.ietf.org/mailman/listinfo/rtcweb

                      

                    

                  

                

              

              


              

            

          

        

      

    

    


    

  





--94eb2c1ccc90a6f77b055cd51ee2--


From nobody Tue Oct 31 03:29:08 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1411395ED for ; Tue, 31 Oct 2017 03:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd-U8pj41BYy for ; Tue, 31 Oct 2017 03:29:05 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 E95231393AE for ; Tue, 31 Oct 2017 03:29:04 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id n74so12467815wmi.1 for ; Tue, 31 Oct 2017 03:29:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OS4hu+HO9vxtn9JPHKiQbx3cX+yjjebXEDdRjywXCZU=; b=ynsEwqoNOtSSr02AVbQPagTo5cY6uKJodOaI5KpcyU/TtjM9DNLJbFANyz9kWHZ48E 9ly18vAX+JMzcX+L4ZU7QBbbAsU0MH6lqtKVV4STxeghCbsjOH6ov5H9TjhW9sAIimom oHTxftmWtn7IRzV0+0zgMBA2KQUFN9CFT8g4mz/VJCEx6A6XPwlSYBJ3j2kOGI1VKqbJ rlVN0IwjXF20WEki7uGf1AcB3CmiZvyeYgVEZgVsQLdFLwOKtHbsUVt7W1mQ4G0bl8VP u0sjnGIYFH8KFyiOxmoC7ie7R2NqxwRQ9MlsYWv4dGPFgGEpEeF7kjbSK/u6QKN/Iw8p 7QUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OS4hu+HO9vxtn9JPHKiQbx3cX+yjjebXEDdRjywXCZU=; b=VFeFznatUQ6zglJ18O/EqbzpxAoAO0yeaGgqHxmFz5+ghn9nWkv7xOhwf2UsXJGQbu nHfpMQ1WueohOvi7du/onAl8LTtbCmBBqGJBP+pdu/MG4WpnvBCk1/2+Th3u4LLZj7XJ 8Y0fdT2ggujKAjlftHXoaZIxRvJw9Egs5+nxbXKzCRo6IruYt6X/VZ3Mr8UGIksC8t2z RbxtiT2eCTgxzx7BZh/S8/9X+iTB1ctNcxmcn2iBmL2+58EU2fCzimlRnBrNmi6eEDiJ 1NheS6XrDZ3bj9Yd9m317C3nTJm7QXUSpCtg7b6HxKl6nnXAmX3lXASL35qYV3JvRkor aiVg==
X-Gm-Message-State: AMCzsaUYYaUj3kEJhlY+F3cr2OLbNHsdaA7HJCKWkKGnk4wrEIDai5PL MZH7vDhZiMv+wY5ftbpdMnSOOMExlJsJ7V3H4dyS+g==
X-Google-Smtp-Source: ABhQp+QmxdnqjGvZSidf7teezhf5Hiu+u4AwsciDAtfnXzvVJIoros3AbruI4BShJ5Q6KedNz5zrA1M2mRr9LTD6fFI=
X-Received: by 10.80.157.141 with SMTP id w13mr2397043ede.151.1509445743423; Tue, 31 Oct 2017 03:29:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 03:29:02 -0700 (PDT)
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 03:29:02 -0700 (PDT)
In-Reply-To: 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>    <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 31 Oct 2017 11:29:02 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
Content-Type: multipart/alternative; boundary="089e0824a68858460d055cd5394f"
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 10:29:07 -0000

--089e0824a68858460d055cd5394f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Said that, I'm afraid we enter into a transactional PAUSE/RESUME game with
increasing ids and so on for just this simple usecase/need...

- Glare when PAUSE and PAUSED sent at the same time.
- RTP after PAUSED but before RESUMED.
- etc

I assume the RFC provides solutions for these potential issues, but I'm
afraid anyway.

El 31 oct. 2017 11:21, "I=C3=B1aki Baz Castillo"  escribi=C3=
=B3:

> Oh yes, wording issue here, sorry.
>
> So we all mean the unsolicited PAUSED sent by the browser.
>
>
>
> El 31 oct. 2017 11:10, "Sergio Garcia Murillo" <
> sergio.garcia.murillo@gmail.com> escribi=C3=B3:
>
>> No, you need a rtcp PAUSED indication, not an rtcp PAUSE request:
>>
>>    An RTP stream sender can choose to pause the stream at any time.
>>    This can be either a result of receiving a PAUSE or based on some
>>    local sender consideration.  When it does, it sends a PAUSED
>>    indication, containing the current PauseID.  Note that the current
>>    PauseID in an unsolicited PAUSED (without having received a PAUSE) is
>>    incremented compared to a previously sent PAUSED.  It also sends the
>>    PAUSED indication in the next two regular RTCP reports, given that
>>    the pause condition is then still effective.
>>
>>
>> Best regards
>> Sergio
>>
>> On 31/10/2017 11:07, I=C3=B1aki Baz Castillo wrote:
>>
>> I am trying to focus on the use case in which the browser decides to
>> pause a simulcast stream (typically the highest one) under changing CPU =
or
>> network conditions. The client side app does nothing to trigger that and
>> it's not even notified in any way, so this is not the "track.enabled=3Df=
alse
>> + signaling" usecase.
>>
>> The use case I mean happens transparently and we need a RTCP PAUSE sent
>> by the browser to tell the receiver (SFU) about it.
>>
>> El 31 oct. 2017 10:59, "Sergio Garcia Murillo" <
>> sergio.garcia.murillo@gmail.com> escribi=C3=B3:
>>
>>> Please, re-read my email, as I am basically saying what you are stating=
.
>>>
>>> PAUSE request can be done out of band (track.enabled =3D false +
>>> signaling), PAUSED indication of simulcast layers can't be done with
>>> current APIs.
>>>
>>> BR
>>> Sergio
>>>
>>> On 31/10/2017 10:34, I=C3=B1aki Baz Castillo wrote:
>>>
>>> I don't know how PAUSE could be implemented "out of band". In fact, the
>>> problem is that, currently, browsers stop a simulcast stream at any tim=
e
>>> without any indication at media or API layers. This is, I see RTCP PAUS=
E
>>> useful for that use case rather than for the app to programmagically pa=
use
>>> a sending track (which can be indeed done via track.enabled =3D false +
>>> signaling).
>>>
>>> El 31 oct. 2017 10:22, "Sergio Garcia Murillo" <
>>> sergio.garcia.murillo@gmail.com> escribi=C3=B3:
>>>
>>>> Hi Bernard,
>>>>
>>>> I agree that late blooming is relatively rare, but I have to try.. ;)
>>>>
>>>> Indeed RFC 7728 provides to different implementation for the
>>>> PAUSE/PAUSED:
>>>>
>>>>    This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
>>>>    possible and defines a small set of new RTCP feedback messages wher=
e
>>>>    new semantics is needed.
>>>>
>>>>
>>>> But it also states that:
>>>>
>>>>    As stated above, TMMBR/TMMBN may be used to provide pause and resum=
e
>>>>    functionality for the point-to-point case.  If the topology is not
>>>>    point to point, TMMBR/TMMBN cannot safely be used for pause or
>>>>    resume.
>>>>
>>>>
>>>> So, at least for the SFU case, the RFC 7728 recommends the usage of th=
e
>>>> new RTCP messages, which does not require implementation of TMMBR/TMMB=
N.
>>>>
>>>> While I agree, that the PAUSE request could be more difficult to
>>>> implement and the use case could also be done "out off band", the PAUS=
ED
>>>> indication is relatively trivial to implement and it is not possible t=
o be
>>>> implemented any other way with current APIs.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>> On 30/10/2017 19:20, Bernard Aboba wrote:
>>>>
>>>> To consider support for PAUSE/PAUSED, it would be first be necessary t=
o
>>>> have implementations of TMMBR/TMMBN, since the PAUSE/PAUSED mechanism =
is
>>>> based on that.
>>>>
>>>> However, although TMMBR/TMMBN is required in RTP-Usage, it has not bee=
n
>>>> widely implemented in WebRTC browsers. Part of the reason may have bee=
n
>>>> that REMB was used for both bandwidth estimation as well as control, s=
o
>>>> TMMBR/TMMBN seemed like overlapping functionality. Although that argum=
ent
>>>> would be less valid after the transition from REMB to transport-cc,
>>>> experience tells us that "late blooming" protocol proposals are relati=
vely
>>>> rare.
>>>>
>>>> On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings  wrote=
:
>>>>
>>>>>
>>>>> I think this is a bit late to add something like 7728 as MTI to in th=
e
>>>>> sort of "1.0" specs. Of course any browser could add support that tha=
t and
>>>>> it would work fine with WebRTC and it could be added to future specs.=
  Long
>>>>> ago when this was discussed, some people had concerns about
>>>>>
>>>>> https://datatracker.ietf.org/ipr/1641/
>>>>>
>>>>> and
>>>>>
>>>>> https://datatracker.ietf.org/ipr/1935/
>>>>>
>>>>>
>>>>> > On Oct 19, 2017, at 12:48 PM, Sergio Garcia Murillo <
>>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>> >
>>>>> > Hi all,
>>>>> >
>>>>> > According to the rtp usage draft, it is allowed to pause and resume
>>>>> transmissions at any time. There are several scenarios in which it wo=
uld
>>>>> make sense to signal when a webrtc sender decides to pause one stream=
 to
>>>>> the receiving side.
>>>>> >
>>>>> > One of them, (as described in detail in
>>>>> https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=3D5207) i=
s
>>>>> be when the webrtc endpoints decides to stop sending one simulcast st=
ream
>>>>> in order to adapt the sent bandwidth to the bandwidth estimation. In =
that
>>>>> case the SFU would benefit from having that indication before having =
to
>>>>> wait for a timeout on media reception before switching to a different
>>>>> simulcast stream. Note that in this case, the stream is paused from i=
nside
>>>>> the webrtc stack, so there is no event triggered to be able to signal=
 this
>>>>> to the js app so it could notify it off band to the receiving side.
>>>>> >
>>>>> > From the solutions discussed, IMHO, the cleanest one would be to
>>>>> support the PAUSE indication from RFC7728. Do you think it could be
>>>>> considered to support it in webrtc?
>>>>> >
>>>>> > Best regards
>>>>> >
>>>>> > Sergio
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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
>>>>
>>>>
>>>
>>

--089e0824a68858460d055cd5394f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Said that, I'm afraid we enter into a transactional P=
AUSE/RESUME game with increasing ids and so on for just this simple usecase=
/need...

- Glare when PAUSE an=
d PAUSED sent at the same time.
- RTP after PAUSED b=
ut before RESUMED.
- etc

=

I assume the RFC provides solutions for these poten=
tial issues, but I'm afraid anyway.

El 31 oct. 2017 11:21, "I=C3=B1aki B=
az Castillo" <ibc@aliax.net>=
; escribi=C3=B3:
Oh yes, wording issue here, sorry.

So we all mean the unsolicited PAUSED sent by the brows=
er.


=


El 31 oct. 2017 1=
1:10, "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com<=
/a>> escribi=C3=B3:

 =20
   =20
 =20
  

    
No, you need a rtcp PAUSED indication,
      not an rtcp PAUSE request:

      

      
   An RTP stream sender can choose to pause the stream=
 at any time.
   This can be either a result of receiving a PAUSE or based on some
   local sender consideration.  When it does, it sends a PAUSED
   indication, containing the current PauseID.  Note that the current
   PauseID in an unsolicited PAUSED (without having received a PAUSE) is
   incremented compared to a previously sent PAUSED.  It also sends the
   PAUSED indication in the next two regular RTCP reports, given that
   the pause condition is then still effective.

      

      Best regards

      Sergio

      

      On 31/10/2017 11:07, I=C3=B1aki Baz Castillo wrote:

    

    

      
I am trying to focus on the use case in which the
        browser decides to pause a simulcast stream (typically the
        highest one) under changing CPU or network conditions. The
        client side app does nothing to trigger that and it's not even
        notified in any way, so this is not the "track.enabled=3Dfalse=
 +
        signaling" usecase.
        


        

        
The use case I mean happens transparently and we
          need a RTCP PAUSE sent by the browser to tell the receiver
          (SFU) about it.

      

      


        
El 31 oct. 2017 10:59, "Sergio Garc=
ia
          Murillo" <sergio.garcia.murillo@gmail.com>
          escribi=C3=B3:

          

            

              
Please,
                re-read my email, as I am basically saying what you are
                stating.

                

                PAUSE request can be done out of band (track.enabled =3D
                false + signaling), PAUSED indication of simulcast
                layers can't be done with current APIs.

                

                BR

                Sergio

                

                On 31/10/2017 10:34, I=C3=B1aki Baz Castillo wrote:

              

              

                
I don't know how PAUSE could be
                  implemented "out of band". In fact, the problem=
 is
                  that, currently, browsers stop a simulcast stream at
                  any time without any indication at media or API
                  layers. This is, I see RTCP PAUSE useful for that use
                  case rather than for the app to programmagically pause
                  a sending track (which can be indeed done via
                  track.enabled =3D false + signaling).

                


                  
El 31 oct. 2017 10:22,
                    "Sergio Garcia Murillo" <sergio.garcia.murillo@g=
mail.com>
                    escribi=C3=B3:

                    

                      

                        
Hi
                          Bernard,

                          

                          I agree that late blooming is relatively rare,
                          but I have to try.. ;)

                          

                          Indeed RFC 7728 provides to different
                          implementation for the PAUSE/PAUSED:

                          

                          
   This solution reuses CCM TMMBR and TMMBN [RFC510=
4] to the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



                          But it also states that:

                          

                          
   As stated above, TMMBR/TMMBN may be used to provide pause and =
resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

                          

                          So, at least for the SFU case, the RFC 7728
                          recommends the usage of the new RTCP messages,
                          which does not require implementation of
                          TMMBR/TMMBN.

                          

                          While I agree, that the PAUSE request could be
                          more difficult to implement and the use case
                          could also be done "out off band", the =
PAUSED
                          indication is relatively trivial to implement
                          and it is not possible to be implemented any
                          other way with current APIs.

                          

                          Best regards

                          Sergio

                          

                          On 30/10/2017 19:20, Bernard Aboba wrote:

                        

                        

                          
To consider support for
                            PAUSE/PAUSED, it would be first be necessary
                            to have implementations of TMMBR/TMMBN,
                            since the PAUSE/PAUSED mechanism is based on
                            that.=C2=A0
                            


                            

                            
However, although TMMBR/TMMBN is
                              required in RTP-Usage,=C2=A0it has not been
                              widely implemented in WebRTC browsers.
                              Part of the reason may have been that REMB
                              was used for both bandwidth estimation as
                              well as control, so TMMBR/TMMBN seemed
                              like overlapping functionality. Although
                              that argument would be less valid after
                              the transition from REMB to transport-cc,
                              experience tells us that "late blooming&=
quot;
                              protocol proposals are relatively rare.=C2=A0=


                            

                          

                          


                            
On Mon, Oct 30,
                              2017 at 8:02 AM, Cullen Jennings <fluffy@iii.ca<=
/a>>
                              wrote:

                              


                                I think this is a bit late to add
                                something like 7728 as MTI to in the
                                sort of "1.0" specs. Of course an=
y
                                browser could add support that that and
                                it would work fine with WebRTC and it
                                could be added to future specs.=C2=A0 Long
                                ago when this was discussed, some people
                                had concerns about

                                

                                https://datatracker.ietf.org/i=
pr/1641/

                                

                                and

                                

                                https://datatracker.ietf.org/i=
pr/1935/

                                

                                  


                                    

                                    > On Oct 19, 2017, at 12:48 PM,
                                    Sergio Garcia Murillo <sergio.garcia.muril=
lo@gmail.com>
                                    wrote:

                                    >

                                    > Hi all,

                                    >

                                    > According to the rtp usage
                                    draft, it is allowed to pause and
                                    resume transmissions at any time.
                                    There are several scenarios in which
                                    it would make sense to signal when a
                                    webrtc sender decides to pause one
                                    stream to the receiving side.

                                    >

                                    > One of them, (as described in
                                    detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?i=
d=3D5207)
                                    is be when the webrtc endpoints
                                    decides to stop sending one
                                    simulcast stream in order to adapt
                                    the sent bandwidth to the bandwidth
                                    estimation. In that case the SFU
                                    would benefit from having that
                                    indication before having to wait for
                                    a timeout on media reception before
                                    switching to a different simulcast
                                    stream. Note that in this case, the
                                    stream is paused from inside the
                                    webrtc stack, so there is no event
                                    triggered to be able to signal this
                                    to the js app so it could notify it
                                    off band to the receiving side.

                                    >

                                    > From the solutions discussed,
                                    IMHO, the cleanest one would be to
                                    support the PAUSE indication from
                                    RFC7728. Do you think it could be
                                    considered to support it in webrtc?

                                    >

                                    > Best regards

                                    >

                                    > Sergio

                                    >

                                    > _______________________________________________

                                    > rtcweb mailing list

                                    > rtcweb@ietf.org

                                    > https://www.iet=
f.org/mailman/listinfo/rtcweb

                                    

                                    __________________________________=
_____________

                                    rtcweb mailing list

                                    rtcweb@ietf.org

                                    https://www.ietf.org=
/mailman/listinfo/rtcweb

                                  

                                

                              

                            

                            

                          

                        

                        


                        

                      

                      

                      _______________________________________________<=
br>
                      rtcweb mailing list

                      =
rtcweb@ietf.org

                      https://www.ietf.org/mailman/listinfo/rtcweb

                      

                    

                  

                

              

              


              

            

          

        

      

    

    


    

  







--089e0824a68858460d055cd5394f--


From nobody Tue Oct 31 03:55:13 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE57813F449 for ; Tue, 31 Oct 2017 03:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgLA48_we8ON for ; Tue, 31 Oct 2017 03:55:08 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 E3D1E13F44B for ; Tue, 31 Oct 2017 03:55:07 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id m72so21617371wmc.1 for ; Tue, 31 Oct 2017 03:55:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=abLQaaC+4IEXuXuiDAh0BtBMdolun98tLSQCXQ4Vf/A=; b=PXJbmLt5iB6tufPnjO7Ki6ePXuyaC3N29CTHgZI2C/GIPu2V30bSIn2riGpGnJ+EQt /GKv8aXjY0pZKkBVjdxO6iYxbUUdzJMl854J+Jz0bzyD4fcFGND7VcXGI2JyY7+LAabb +XMNzX0oYa4Vd31m/DZ9BWF3TQWHeM246m9bk0TqWBMSw12zxQHwf7pZY1YwhnkFTark BAckG1iQ8KvbDCx1dffIZLltajiQbH5y9/aovpo7JqbytTIrV8grtJuaHnhsSvknVYHU 3gXZN2+vDfg10+fAGgFle2+dxawaq1ymIEZ0XVsYztsrFfTCisvP9X2yOhvxKZJUpliH qZ8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=abLQaaC+4IEXuXuiDAh0BtBMdolun98tLSQCXQ4Vf/A=; b=d4ptJlvSzI5wqmI0L3tIqJ/qmkbB1a/85MGrIyvRmKjUzmjdk9sVDd1Q9bUoxe/xly sZgQp0B8QJHHsE4F/vk104MBObV01FdRixs/dunMz/zhtZkIVXnom0tE7DbvtPtPWwAo LCvPHKY4QfGXih/HPHJE9vFt8kRvGdIWcvC2gaxLFfWwlg5JN3FNs+nYLKQJR2h2xtJQ cESqYBEhNC9zchScJv4oxuAfkm9i822fRLF87UknhmBB/Gj78ZYpXyyShxrD6HDFCKk6 5YjDKA2YxIIIRcSxw+09BRL7wHpw/3muxGdOMdMm47JRhw0zkOGbeYgdHBAPjhGlBgVW 6odg==
X-Gm-Message-State: AMCzsaX8eFCV5T9wVURcIUHpHmbWgTNSLZsAhv7VtBDrWuIhPwnSPDxO qbUtfOu8zYBX2AEGhOojrUViAdyB
X-Google-Smtp-Source: ABhQp+SgQ8p32XOQ70lSJobwySt32YFpVkxQGWs6padxkC7vz8dt4p9BslspHTCrE+kHflD4aKhngw==
X-Received: by 10.80.215.156 with SMTP id w28mr2332748edi.81.1509447306182; Tue, 31 Oct 2017 03:55:06 -0700 (PDT)
Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id j6sm921795edj.58.2017.10.31.03.55.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 03:55:04 -0700 (PDT)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>    <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com>  
From: Sergio Garcia Murillo 
Message-ID: <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com>
Date: Tue, 31 Oct 2017 11:55:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DDCCCAF86461253F4FA4F12F"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 10:55:12 -0000

This is a multi-part message in MIME format.
--------------DDCCCAF86461253F4FA4F12F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Couple of things:

  *   there is not a RESUMED indication, you just start sending media.
  * PAUSE/PAUSED glare is solved on the RFC
  * We only need the unsolicited PAUSED indication for the simulcast use
    case, not the whole PAUSE/RESUME mechanism.

Best regards
Sergio
On 31/10/2017 11:29, Iñaki Baz Castillo wrote:
> Said that, I'm afraid we enter into a transactional PAUSE/RESUME game 
> with increasing ids and so on for just this simple usecase/need...
>
> - Glare when PAUSE and PAUSED sent at the same time.
> - RTP after PAUSED but before RESUMED.
> - etc
>
> I assume the RFC provides solutions for these potential issues, but 
> I'm afraid anyway.
>
> El 31 oct. 2017 11:21, "Iñaki Baz Castillo"  > escribió:
>
>     Oh yes, wording issue here, sorry.
>
>     So we all mean the unsolicited PAUSED sent by the browser.
>
>
>
>     El 31 oct. 2017 11:10, "Sergio Garcia Murillo"
>          > escribió:
>
>         No, you need a rtcp PAUSED indication, not an rtcp PAUSE request:
>
>             An RTP stream sender can choose to pause the stream at any time.
>             This can be either a result of receiving a PAUSE or based on some
>             local sender consideration.  When it does, it sends a PAUSED
>             indication, containing the current PauseID.  Note that the current
>             PauseID in an unsolicited PAUSED (without having received a PAUSE) is
>             incremented compared to a previously sent PAUSED.  It also sends the
>             PAUSED indication in the next two regular RTCP reports, given that
>             the pause condition is then still effective.
>
>
>         Best regards
>         Sergio
>
>         On 31/10/2017 11:07, Iñaki Baz Castillo wrote:
>>         I am trying to focus on the use case in which the browser
>>         decides to pause a simulcast stream (typically the highest
>>         one) under changing CPU or network conditions. The client
>>         side app does nothing to trigger that and it's not even
>>         notified in any way, so this is not the "track.enabled=false
>>         + signaling" usecase.
>>
>>         The use case I mean happens transparently and we need a RTCP
>>         PAUSE sent by the browser to tell the receiver (SFU) about it.
>>
>>         El 31 oct. 2017 10:59, "Sergio Garcia Murillo"
>>         >         > escribió:
>>
>>             Please, re-read my email, as I am basically saying what
>>             you are stating.
>>
>>             PAUSE request can be done out of band (track.enabled =
>>             false + signaling), PAUSED indication of simulcast layers
>>             can't be done with current APIs.
>>
>>             BR
>>             Sergio
>>
>>             On 31/10/2017 10:34, Iñaki Baz Castillo wrote:
>>>             I don't know how PAUSE could be implemented "out of
>>>             band". In fact, the problem is that, currently, browsers
>>>             stop a simulcast stream at any time without any
>>>             indication at media or API layers. This is, I see RTCP
>>>             PAUSE useful for that use case rather than for the app
>>>             to programmagically pause a sending track (which can be
>>>             indeed done via track.enabled = false + signaling).
>>>
>>>             El 31 oct. 2017 10:22, "Sergio Garcia Murillo"
>>>             >>             > escribió:
>>>
>>>                 Hi Bernard,
>>>
>>>                 I agree that late blooming is relatively rare, but I
>>>                 have to try.. ;)
>>>
>>>                 Indeed RFC 7728 provides to different implementation
>>>                 for the PAUSE/PAUSED:
>>>
>>>                     This solution reuses CCM TMMBR and TMMBN [RFC5104 ] to the extent
>>>                     possible and defines a small set of new RTCP feedback messages where
>>>                     new semantics is needed.
>>>
>>>                 But it also states that:
>>>
>>>                     As stated above, TMMBR/TMMBN may be used to provide pause and resume
>>>                     functionality for the point-to-point case.  If the topology is not
>>>                     point to point, TMMBR/TMMBN cannot safely be used for pause or
>>>                     resume.
>>>
>>>
>>>                 So, at least for the SFU case, the RFC 7728
>>>                 recommends the usage of the new RTCP messages, which
>>>                 does not require implementation of TMMBR/TMMBN.
>>>
>>>                 While I agree, that the PAUSE request could be more
>>>                 difficult to implement and the use case could also
>>>                 be done "out off band", the PAUSED indication is
>>>                 relatively trivial to implement and it is not
>>>                 possible to be implemented any other way with
>>>                 current APIs.
>>>
>>>                 Best regards
>>>                 Sergio
>>>
>>>                 On 30/10/2017 19:20, Bernard Aboba wrote:
>>>>                 To consider support for PAUSE/PAUSED, it would be
>>>>                 first be necessary to have implementations of
>>>>                 TMMBR/TMMBN, since the PAUSE/PAUSED mechanism is
>>>>                 based on that.
>>>>
>>>>                 However, although TMMBR/TMMBN is required in
>>>>                 RTP-Usage, it has not been widely implemented in
>>>>                 WebRTC browsers. Part of the reason may have been
>>>>                 that REMB was used for both bandwidth estimation as
>>>>                 well as control, so TMMBR/TMMBN seemed like
>>>>                 overlapping functionality. Although that argument
>>>>                 would be less valid after the transition from REMB
>>>>                 to transport-cc, experience tells us that "late
>>>>                 blooming" protocol proposals are relatively rare.
>>>>
>>>>                 On Mon, Oct 30, 2017 at 8:02 AM, Cullen Jennings
>>>>                 > wrote:
>>>>
>>>>
>>>>                     I think this is a bit late to add something
>>>>                     like 7728 as MTI to in the sort of "1.0" specs.
>>>>                     Of course any browser could add support that
>>>>                     that and it would work fine with WebRTC and it
>>>>                     could be added to future specs.  Long ago when
>>>>                     this was discussed, some people had concerns about
>>>>
>>>>                     https://datatracker.ietf.org/ipr/1641/
>>>>                     
>>>>
>>>>                     and
>>>>
>>>>                     https://datatracker.ietf.org/ipr/1935/
>>>>                     
>>>>
>>>>
>>>>                     > On Oct 19, 2017, at 12:48 PM, Sergio Garcia
>>>>                     Murillo >>>                     > wrote:
>>>>                     >
>>>>                     > Hi all,
>>>>                     >
>>>>                     > According to the rtp usage draft, it is
>>>>                     allowed to pause and resume transmissions at
>>>>                     any time. There are several scenarios in which
>>>>                     it would make sense to signal when a webrtc
>>>>                     sender decides to pause one stream to the
>>>>                     receiving side.
>>>>                     >
>>>>                     > One of them, (as described in detail in
>>>>                     https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207
>>>>                     )
>>>>                     is be when the webrtc endpoints decides to stop
>>>>                     sending one simulcast stream in order to adapt
>>>>                     the sent bandwidth to the bandwidth estimation.
>>>>                     In that case the SFU would benefit from having
>>>>                     that indication before having to wait for a
>>>>                     timeout on media reception before switching to
>>>>                     a different simulcast stream. Note that in this
>>>>                     case, the stream is paused from inside the
>>>>                     webrtc stack, so there is no event triggered to
>>>>                     be able to signal this to the js app so it
>>>>                     could notify it off band to the receiving side.
>>>>                     >
>>>>                     > From the solutions discussed, IMHO, the
>>>>                     cleanest one would be to support the PAUSE
>>>>                     indication from RFC7728. Do you think it could
>>>>                     be considered to support it in webrtc?
>>>>                     >
>>>>                     > Best regards
>>>>                     >
>>>>                     > Sergio
>>>>                     >
>>>>                     > _______________________________________________
>>>>                     > 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
>>>                 
>>>
>>
>


--------------DDCCCAF86461253F4FA4F12F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Couple of things:

      
    
        
  •  there is not a RESUMED indication, you just start sending
          media. 
    
        
    • 
        
  • PAUSE/PAUSED glare is solved on the RFC
    • 
        
  • We only need the unsolicited PAUSED indication for the
          simulcast use case, not the whole PAUSE/RESUME mechanism.
    
        
    • 
      

      Best regards

      Sergio

      On 31/10/2017 11:29, Iñaki Baz Castillo wrote:

    

    

      
Said that, I'm afraid we enter into a
        transactional PAUSE/RESUME game with increasing ids and so on
        for just this simple usecase/need...
        


        

        
- Glare when PAUSE and PAUSED sent at the same
          time.

        
- RTP after PAUSED but before RESUMED.

        
- etc

        


        

        
I assume the RFC provides solutions for these
          potential issues, but I'm afraid anyway.

      

      


        
El 31 oct. 2017 11:21, "Iñaki Baz
          Castillo" <ibc@aliax.net> escribió:

          

            
Oh yes, wording issue here, sorry.
              


              

              
So we all mean the unsolicited PAUSED sent
                by the browser.

                


                

                


                

              

            

            


              
El 31 oct. 2017 11:10, "Sergio
                Garcia Murillo" <sergio.garcia.murillo@gmail.com>
                escribió:

                

                  

                    
No,
                      you need a rtcp PAUSED indication, not an rtcp
                      PAUSE request:

                      

                      
   An RTP stream sender can choose to pause the stream at any time.
   This can be either a result of receiving a PAUSE or based on some
   local sender consideration.  When it does, it sends a PAUSED
   indication, containing the current PauseID.  Note that the current
   PauseID in an unsolicited PAUSED (without having received a PAUSE) is
   incremented compared to a previously sent PAUSED.  It also sends the
   PAUSED indication in the next two regular RTCP reports, given that
   the pause condition is then still effective.

                      

                      Best regards

                      Sergio

                      

                      On 31/10/2017 11:07, Iñaki Baz Castillo wrote:

                    

                    

                      
I am trying to focus on the use
                        case in which the browser decides to pause a
                        simulcast stream (typically the highest one)
                        under changing CPU or network conditions. The
                        client side app does nothing to trigger that and
                        it's not even notified in any way, so this is
                        not the "track.enabled=false + signaling"
                        usecase.
                        


                        

                        
The use case I mean happens
                          transparently and we need a RTCP PAUSE sent by
                          the browser to tell the receiver (SFU) about
                          it.

                      

                      


                        
El 31 oct. 2017 10:59,
                          "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>
                          escribió:

                          

                            

                              
Please,
                                re-read my email, as I am basically
                                saying what you are stating.

                                

                                PAUSE request can be done out of band
                                (track.enabled = false + signaling),
                                PAUSED indication of simulcast layers
                                can't be done with current APIs.

                                

                                BR

                                Sergio

                                

                                On 31/10/2017 10:34, Iñaki Baz Castillo
                                wrote:

                              

                              

                                
I don't know how PAUSE
                                  could be implemented "out of band". In
                                  fact, the problem is that, currently,
                                  browsers stop a simulcast stream at
                                  any time without any indication at
                                  media or API layers. This is, I see
                                  RTCP PAUSE useful for that use case
                                  rather than for the app to
                                  programmagically pause a sending track
                                  (which can be indeed done via
                                  track.enabled = false + signaling).

                                


                                  
El 31 oct.
                                    2017 10:22, "Sergio Garcia Murillo"
                                    <sergio.garcia.murillo@gmail.com>
                                    escribió:

                                    

                                      

                                        
Hi
                                          Bernard,

                                          

                                          I agree that late blooming is
                                          relatively rare, but I have to
                                          try.. ;)

                                          

                                          Indeed RFC 7728 provides to
                                          different implementation for
                                          the PAUSE/PAUSED:

                                          

                                          
   This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent
   possible and defines a small set of new RTCP feedback messages where
   new semantics is needed.



                                          But it also states that:

                                          

                                          
   As stated above, TMMBR/TMMBN may be used to provide pause and resume
   functionality for the point-to-point case.  If the topology is not
   point to point, TMMBR/TMMBN cannot safely be used for pause or
   resume. 

                                          

                                          So, at least for the SFU case,
                                          the RFC 7728 recommends the
                                          usage of the new RTCP
                                          messages, which does not
                                          require implementation of
                                          TMMBR/TMMBN.

                                          

                                          While I agree, that the PAUSE
                                          request could be more
                                          difficult to implement and the
                                          use case could also be done
                                          "out off band", the PAUSED
                                          indication is relatively
                                          trivial to implement and it is
                                          not possible to be implemented
                                          any other way with current
                                          APIs.

                                          

                                          Best regards

                                          Sergio

                                          

                                          On 30/10/2017 19:20, Bernard
                                          Aboba wrote:

                                        

                                        

                                          
To consider
                                            support for PAUSE/PAUSED, it
                                            would be first be necessary
                                            to have implementations of
                                            TMMBR/TMMBN, since the
                                            PAUSE/PAUSED mechanism is
                                            based on that. 
                                            


                                            

                                            
However, although
                                              TMMBR/TMMBN is required in
                                              RTP-Usage, it has not been
                                              widely implemented in
                                              WebRTC browsers. Part of
                                              the reason may have been
                                              that REMB was used for
                                              both bandwidth estimation
                                              as well as control, so
                                              TMMBR/TMMBN seemed like
                                              overlapping functionality.
                                              Although that argument
                                              would be less valid after
                                              the transition from REMB
                                              to transport-cc,
                                              experience tells us that
                                              "late blooming" protocol
                                              proposals are relatively
                                              rare. 

                                            

                                          

                                          


                                            
On
                                              Mon, Oct 30, 2017 at 8:02
                                              AM, Cullen Jennings <fluffy@iii.ca>
                                              wrote:

                                              


                                                I think this is a bit
                                                late to add something
                                                like 7728 as MTI to in
                                                the sort of "1.0" specs.
                                                Of course any browser
                                                could add support that
                                                that and it would work
                                                fine with WebRTC and it
                                                could be added to future
                                                specs.  Long ago when
                                                this was discussed, some
                                                people had concerns
                                                about

                                                

                                                https://datatracker.ietf.org/ipr/1641/

                                                

                                                and

                                                

                                                https://datatracker.ietf.org/ipr/1935/

                                                

                                                  


                                                    

                                                    > On Oct 19,
                                                    2017, at 12:48 PM,
                                                    Sergio Garcia
                                                    Murillo <sergio.garcia.murillo@gmail.com>
                                                    wrote:

                                                    >

                                                    > Hi all,

                                                    >

                                                    > According to
                                                    the rtp usage draft,
                                                    it is allowed to
                                                    pause and resume
                                                    transmissions at any
                                                    time. There are
                                                    several scenarios in
                                                    which it would make
                                                    sense to signal when
                                                    a webrtc sender
                                                    decides to pause one
                                                    stream to the
                                                    receiving side.

                                                    >

                                                    > One of them,
                                                    (as described in
                                                    detail in https://monorail-prod.appspot.com/p/webrtc/issues/detail?id=5207)
                                                    is be when the
                                                    webrtc endpoints
                                                    decides to stop
                                                    sending one
                                                    simulcast stream in
                                                    order to adapt the
                                                    sent bandwidth to
                                                    the bandwidth
                                                    estimation. In that
                                                    case the SFU would
                                                    benefit from having
                                                    that indication
                                                    before having to
                                                    wait for a timeout
                                                    on media reception
                                                    before switching to
                                                    a different
                                                    simulcast stream.
                                                    Note that in this
                                                    case, the stream is
                                                    paused from inside
                                                    the webrtc stack, so
                                                    there is no event
                                                    triggered to be able
                                                    to signal this to
                                                    the js app so it
                                                    could notify it off
                                                    band to the
                                                    receiving side.

                                                    >

                                                    > From the
                                                    solutions discussed,
                                                    IMHO, the cleanest
                                                    one would be to
                                                    support the PAUSE
                                                    indication from
                                                    RFC7728. Do you
                                                    think it could be
                                                    considered to
                                                    support it in
                                                    webrtc?

                                                    >

                                                    > Best regards

                                                    >

                                                    > Sergio

                                                    >

                                                    >
                                                    _______________________________________________

                                                    > 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

                                      

                                    

                                  

                                

                              

                              


                              

                            

                          

                        

                      

                    

                    


                    

                  

                

              

            

          

        

      

    

    


    

  


--------------DDCCCAF86461253F4FA4F12F--


From nobody Tue Oct 31 04:00:45 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB3313F5F6 for ; Tue, 31 Oct 2017 04:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 533dD4Y-O1i6 for ; Tue, 31 Oct 2017 04:00:42 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5F713A044 for ; Tue, 31 Oct 2017 04:00:41 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id y83so22128261wmc.4 for ; Tue, 31 Oct 2017 04:00:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1RT5fQtaELSPxvcy3KQnuSqP3qb3djr+xvYlCaAMCzI=; b=t6uqZr5NIqqN+igas+Rio3cdaFHF3WZ35osBktpTxNaMzkmlhJDLspQtWqP14SSdlB 2TSnOT4Rm0nJAcKA9uhh/VeLmcv+vNcD3jZRLWR6BVfYmjTN2Fv+Oc/7kEicTNH3LVuS TKRn+jOcMEgy8yU6Kz1Xhoikxr3slYO7bqcqyEkkxAL76Ia3dFIs+sj8l6P5p+bmCC+7 o1Ik2j/g29Dnc0QcNmC5V4stcBCbYQFe3pEH2qEOQlBlE/O25NACwCRpRhGPJHmbtJwQ PwsnmC3DrOZxUrw5arpLvsJ8KhQ8WPoztoQxnnFgsLDZU++9OW8Jq4OOXhefnu8vaqUt 6tEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1RT5fQtaELSPxvcy3KQnuSqP3qb3djr+xvYlCaAMCzI=; b=rmMlLO0qCDck8dlxiwgxQgkUaYbZNhkBvHwMsiiBgQPtHyfBKgeyRCkMXAZQVDwUeL lWOmBccKHFxyFzkWgMGE1vpcjDFqi/Ap2nbMRaN/qMgoei3YSy1O5ddaHo0rNOhybLAh S1f85gQuo8AJ3U50SEkvqRnCU2vQhC/MKrjbtt0IixFxWHSwm3mcba76BJbGwMWgOr0j MVX4aHL43BMUYFG8m7SPkdP1RRqa1H3BUpYPgsMAgIOdQfO4IFFtisPtjP1MfyOiNB/2 GuJFMwQg83YRZoRfG4NUE/VmjXtQ2oX9YL4G/sgxJJbV8BJtDKaPQHw0uVbASqU0c+dz 6psA==
X-Gm-Message-State: AMCzsaWFQlUfhMHguNaI6I3yvAcJg7VPMw4FpthpRZs0TPbEm7LOxpj7 AjqLzokUy9KdytJOswdCeBD9FTqgATgpLJCUjiI0lA==
X-Google-Smtp-Source: ABhQp+SZi1hayDoGeeDYffmo6PXFRD1pJzqTmkyi5r4xfSW70ZEwWaxBPppO4GyMk//2ThFCUEoouyXCzoNLNJnQexE=
X-Received: by 10.80.152.69 with SMTP id h5mr2372416edb.192.1509447639856; Tue, 31 Oct 2017 04:00:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 04:00:18 -0700 (PDT)
In-Reply-To: <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com>
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>    <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com>   <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 31 Oct 2017 12:00:18 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 11:00:44 -0000

On 31 October 2017 at 11:55, Sergio Garcia Murillo
 wrote:
> Couple of things:
>
>  - there is not a RESUMED indication, you just start sending media.

Nice. However, the last RTP packet sent before PAUSED may arrive after
the PAUSED itself. Not sure how to handle that in the receiver side...


> - PAUSE/PAUSED glare is solved on the RFC

Sure, but this involves more state in the RTCP agent. Loadable anyway.


> We only need the unsolicited PAUSED indication for the simulcast use case=
,
> not the whole PAUSE/RESUME mechanism.

And that's the problem. In order to solve a real and specific problem
we have today, browsers need to implement a whole RFC. I don't think
WebRTC X.Y will mandate implementing just a subset of a RFC...

--=20
I=C3=B1aki Baz Castillo



From nobody Tue Oct 31 04:16:47 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7072113F66A for ; Tue, 31 Oct 2017 04:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKailCISvIP6 for ; Tue, 31 Oct 2017 04:16:43 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4772C13F61E for ; Tue, 31 Oct 2017 04:16:43 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id b9so22381835wmh.0 for ; Tue, 31 Oct 2017 04:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=9xG8pt7gjkNrkuwSDsjl3p7YhVYFjU+GknMDsmTETd8=; b=OWigc4QhO4oKxJNqTdHNLkK5lWwlEwMNTJhEpbmvibc2LYot8j6xbxkuSwfWN40sTC jz5ma0eDo0lldfLbu5za3GgF8460ovkNAkvHkCdk+enAXdnRMn/x5hORowbaYOHkCjki 8/I7of7n4EexFB9sfhM/yBwj/Zy7c4wBcfOhLZlJFySkUvkCTtm5Hro3v4luh0y54/0Y gaA6coJsncHf7wRmM7s/RVhimiHJSPLaNkq1FJTB7ASj/meOTAwBuMrGXna2XDgTxrdz 5u9OOjhlZsguOoSM99D6xIUTdYctjGnRs7+RAd9h5syo/wWjLyyAugPO806pT8u+VgV4 KvHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=9xG8pt7gjkNrkuwSDsjl3p7YhVYFjU+GknMDsmTETd8=; b=YnVmnUA2Vu+QRiQon88fDTcmWvT3eo3On/94ZmaDfikgBpjsTjd1gvzoQHuy0U52ej We7p9AdWDjdSfCrhfOHWD0o353C94hdH+c94MF4uG7EfC0/plA7tENtzgJKBicxeDCM1 w+VxwRdNmRPvOQhzsyV2Z5RodkJ3DcJeMpT79nFhxKu194BZJ0O07MuXMbRYQ7HHUpYG CYbBuyxqDmBAR+4Roor06/Hc6Xvby5H9CgH54dZYaFnzg6wNkAR3gVdnxJEYH21fi5CU WoqrdqKJYrXKviBWQPcfFHGOrvn2+BDF4mxJNuawVZ7nydGls2jh3WvnGpCq58m4g426 zj8A==
X-Gm-Message-State: AMCzsaVDBm6HI3XvYVocWMsIZjzzKOWnXP7PY/VXKfFv9m/6fM/Q+Zxk KzNVHMh5i6acPu7c9Nv0WepOh9Cc
X-Google-Smtp-Source: ABhQp+STMKJqppWBYhRbOC0gp4SRiZkFBu8oNictB9n1rGNv5U4NgTystkUqglZkHSQoe5L16QZlvQ==
X-Received: by 10.80.151.38 with SMTP id c35mr2589867edb.47.1509448601615; Tue, 31 Oct 2017 04:16:41 -0700 (PDT)
Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id j39sm1230509ede.7.2017.10.31.04.16.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 04:16:40 -0700 (PDT)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>    <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com>   <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: 
Date: Tue, 31 Oct 2017 12:16:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7C8F1BA6B5DABAFDAB82469E"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 11:16:45 -0000

This is a multi-part message in MIME format.
--------------7C8F1BA6B5DABAFDAB82469E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 31/10/2017 12:00, Iñaki Baz Castillo wrote:
> On 31 October 2017 at 11:55, Sergio Garcia Murillo
>  wrote:
>> Couple of things:
>>
>>   - there is not a RESUMED indication, you just start sending media.
> Nice. However, the last RTP packet sent before PAUSED may arrive after
> the PAUSED itself. Not sure how to handle that in the receiver side...

    When entering the state, the RTP stream sender SHALL send a PAUSED
    indication to all known RTP stream receivers, and SHALL also repeat
    PAUSED in the next two regular RTCP reports, as long as it is then
    still in paused state.

>> We only need the unsolicited PAUSED indication for the simulcast use case,
>> not the whole PAUSE/RESUME mechanism.
> And that's the problem. In order to solve a real and specific problem
> we have today, browsers need to implement a whole RFC. I don't think
> WebRTC X.Y will mandate implementing just a subset of a RFC...
>
RFC 7728 allows partial implementation, with fine grained control about 
sending/receiving PAUSED indication:

       "config" allows for partial implementation of this specification
       according to the different roles in the use-cases section:

       6  The implementation supports sent and received RTP streams being
          paused due to local considerations and thus supports sending
          and receiving PAUSED indications.

       7  The implementation supports and desires to receive PAUSED
          indications for received RTP streams but does not pause or send
          PAUSED indications for sent RTP streams.  It does not support
          any other messages defined in this specification.

       8  The implementation supports pausing sent RTP streams and
          sending PAUSED indications for them but does not support
          receiving PAUSED indications for received RTP streams.  It does
          not support any other messages defined in this specification.


Best regards

Sergio



--------------7C8F1BA6B5DABAFDAB82469E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 31/10/2017 12:00, Iñaki Baz Castillo
      wrote:

    

    

      
On 31 October 2017 at 11:55, Sergio Garcia Murillo
<sergio.garcia.murillo@gmail.com> wrote:


      

        
Couple of things:

 - there is not a RESUMED indication, you just start sending media.


      

      
Nice. However, the last RTP packet sent before PAUSED may arrive after
the PAUSED itself. Not sure how to handle that in the receiver side...

    

    

    
   When entering the state, the RTP stream sender SHALL send a PAUSED
   indication to all known RTP stream receivers, and SHALL also repeat
   PAUSED in the next two regular RTCP reports, as long as it is then
   still in paused state.



    

      

        
We only need the unsolicited PAUSED indication for the simulcast use case,
not the whole PAUSE/RESUME mechanism.


      

      
And that's the problem. In order to solve a real and specific problem
we have today, browsers need to implement a whole RFC. I don't think
WebRTC X.Y will mandate implementing just a subset of a RFC...



    

    
RFC 7728 allows partial implementation, with fine grained control
      about sending/receiving PAUSED indication:

    

    
      "config" allows for partial implementation of this specification
      according to the different roles in the use-cases section:

      6  The implementation supports sent and received RTP streams being
         paused due to local considerations and thus supports sending
         and receiving PAUSED indications.

      7  The implementation supports and desires to receive PAUSED
         indications for received RTP streams but does not pause or send
         PAUSED indications for sent RTP streams.  It does not support
         any other messages defined in this specification.

      8  The implementation supports pausing sent RTP streams and
         sending PAUSED indications for them but does not support
         receiving PAUSED indications for received RTP streams.  It does
         not support any other messages defined in this specification.

    


    

    
Best regards

    
Sergio

    

    


    

  


--------------7C8F1BA6B5DABAFDAB82469E--


From nobody Tue Oct 31 04:27:46 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2852F13F67B for ; Tue, 31 Oct 2017 04:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wObSmHjqwNHs for ; Tue, 31 Oct 2017 04:27:42 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 A50F313F664 for ; Tue, 31 Oct 2017 04:27:41 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id r196so21845321wmf.2 for ; Tue, 31 Oct 2017 04:27:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HtIm/NbHtBtrRgcR3gZzyFIgbJR7fq6H6bZugOGK1dc=; b=NgspqK3qrK113gxDwOqMweoopqnsei7blaj1sgzNLpfZATN9SpX5gsrk9sRXUXqsSh ML0W9qpmCLVxNIaX0QCxVqT/+xnoc5fu2UmhKbFvSzUyfZi25PdCv65dpdiuQ4r8CCbL YzqkJQ1jkD+v6d8OdA4n7VdrjcjY+CsIspMCD/aflew4DOLF2zXk/7FzVFwViEl0fW8G wL1ZJXzfzd8W4vJ1XkheErp8cWiAeQYWbsL2eG9fyxjeRghDBohYHP5Nqy9DorH4TqmA CrtREN8N0IO8HEsa2osb2TehNkkbT2QvkrVtET6UwgCaOoHyK8tN9qSetQpoN/BpOrfJ 9MVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HtIm/NbHtBtrRgcR3gZzyFIgbJR7fq6H6bZugOGK1dc=; b=MITqu4pks29zWTrz6r7r1R1bgZBzvBE1VB2z624pWLzFh1exFzq4At/iF59jGl2WR4 ZeQwskHzZbm+I/atC2j0JZjn24c9tI0A7NPath2qcH/bx7PRFVmcgNCLGxy/6hx4nMWs llrwHbhtnLaWWNMqXCV9dmp6YadqjmET40ODFjqOtNnUXZgP0jn+hVi0kXIvuU+Pl0bj 1jwhHPOAlaPVomugCnYKQ9Fv/YrdTfmccuZ4M8vTpq8jqocSJFBBbn8HfXM2xvyzkljG Ul+4uSZKb456v/4QEO5Ebtk4ewzUE8RSwaILbGBGhjh4CN/nUamf05zwrHYRNInIr9XA AIKw==
X-Gm-Message-State: AMCzsaXZUTW0WT1zZuEVgsbPZgGWk+cM6ZB61bkI6xcmEY7wn/2t+lqJ mXzAyuUlgbBmQfmLvm9lX1H3fS+oycnP38BnQNCulw==
X-Google-Smtp-Source: ABhQp+Sr+pz8T9YDTBQCgWtFq25x0DOciy8pIvegQ9eXMQK9Pii8FGgsFTB72Vn2dvs6qwVZ6faTayCklaH6sd8Y5cY=
X-Received: by 10.80.137.91 with SMTP id f27mr2457050edf.18.1509449260031; Tue, 31 Oct 2017 04:27:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 31 Oct 2017 04:27:19 -0700 (PDT)
In-Reply-To: 
References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca>  <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com>    <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com>   <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 31 Oct 2017 12:27:19 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Bernard Aboba , Cullen Jennings ,  RTCWeb IETF 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Support for RFC7728 pause indication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 11:27:45 -0000

> Nice. However, the last RTP packet sent before PAUSED may arrive after
> the PAUSED itself. Not sure how to handle that in the receiver side...
>
>    When entering the state, the RTP stream sender SHALL send a PAUSED
>    indication to all known RTP stream receivers, and SHALL also repeat
>    PAUSED in the next two regular RTCP reports, as long as it is then
>    still in paused state.

Should be enough to mitigate the issue.


> RFC 7728 allows partial implementation, with fine grained control about
> sending/receiving PAUSED indication:
>
>       "config" allows for partial implementation of this specification
>       according to the different roles in the use-cases section:
>
>       6  The implementation supports sent and received RTP streams being
>          paused due to local considerations and thus supports sending
>          and receiving PAUSED indications.
>
>       7  The implementation supports and desires to receive PAUSED
>          indications for received RTP streams but does not pause or send
>          PAUSED indications for sent RTP streams.  It does not support
>          any other messages defined in this specification.
>
>       8  The implementation supports pausing sent RTP streams and
>          sending PAUSED indications for them but does not support
>          receiving PAUSED indications for received RTP streams.  It does
>          not support any other messages defined in this specification.

Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) also
seem easy to implement but, despite being mandatory, better don't send
a TMMBR to Chrome in 2017.

--=20
I=C3=B1aki Baz Castillo



From nobody Tue Oct 31 13:48:51 2017
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFCD139A2F for ; Tue, 31 Oct 2017 13:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pF8p0thATNCN for ; Tue, 31 Oct 2017 13:48:48 -0700 (PDT)
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 D3CA713F6DA for ; Tue, 31 Oct 2017 13:48:47 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id y23so364124qkb.10 for ; Tue, 31 Oct 2017 13:48:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=TQpjGlRKWGe5A0dVO1EyBEaUcI146dp0yowjLwbDkAw=; b=keOGh575IK6tuoZcxi3rjQyryDg7ZdM9JQX52IgmWAF2uZ6z+msSEEJopcJh0hcD3X 8gFlNeM+314ipC8AywL6yNQgRmeuGaLi0WRNdU47vorGOeCSdVIByXQPM3dd3F+ZuGXe HWnm13aiw89kmeUqvHeQl3TGl4FcLvbyZsSWs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=TQpjGlRKWGe5A0dVO1EyBEaUcI146dp0yowjLwbDkAw=; b=HsgskrPP1RQET+PdU6sax7AA8IqhMUGm1TLwPz+Nn8gpXdyp2TumejZ7uZ7I9pQ3Gy 7JRhY+AyvSaIjtCaSDN/PJ7dmsfZroDN+YqXSd8ikh/e0MdNE+aFnCNWJQ75l8fwy1jj dzwwqzRV/PvHYCtqfL/KMFfVweenIfwafLVqKSSvrIHXVeHADmt417O3Q6ohMAv5AZDe +oKikGqH6fkDGtrGSTnXGmTuqX1VvFQfF6Qe3cYi4aDn/0wKeOdlclAfweVTdYgS0XgO uWZE5IGDOBQkIz+QNkEV5X8oUjkUhuPWU5twzzNKuUKFLNEUoCoO1Lg9em4xH+OHEgDo q6Zw==
X-Gm-Message-State: AMCzsaXxAJvUmgLaN3UI/0NzTPkBqhfoJKXT0MsnGrN9TVn3HKqZxP5H N0ZcjREHlCS7SBIt4pb0bbk81jyQWiw=
X-Google-Smtp-Source: ABhQp+Q6CUig3jPCzGda5NXs5TyKXyuXIHfnx++LWsDgfNlwOpOw13Av4xXiQLaKkF/lS/leGp4sXA==
X-Received: by 10.55.124.198 with SMTP id x189mr4849401qkc.40.1509482926965; Tue, 31 Oct 2017 13:48:46 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id t16sm1486983qtt.92.2017.10.31.13.48.46 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 13:48:46 -0700 (PDT)
From: Sean Turner 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Tue, 31 Oct 2017 16:48:45 -0400
To: RTCWeb IETF 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [rtcweb] draft-ietf-rtcweb-overview status
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 31 Oct 2017 20:48:50 -0000

All,

Now that Harald=E2=80=99s back, he=E2=80=99s reviewed and merged the PRs =
I submitted as document shepherd to address the IESG discuss and =
comments from back in April.  Please see: =
https://github.com/rtcweb-wg/rtcweb-overview

There is one that I asked him not merge immediately related to whether =
to reference 5245bis or 5245: =
https://github.com/rtcweb-wg/rtcweb-overview/pull/37

The chairs and AD believe that this issue will be addressed as cluster =
238 (https://www.rfc-editor.org/cluster_info.php?cid=3DC238) gets =
untangled and therefore we propose that this PR#37 be merged and we move =
this document to the RFC editor=E2=80=99s queue.  We=E2=80=99ll ask =
Harald to do the merge/submission when the submission window reopens.

Ted, Cullen, and Sean=