From nobody Fri Oct 9 07:24:00 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E7A3A084A for ; Fri, 9 Oct 2020 07:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=chriswendt-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 EpINfwcx3ODI for ; Fri, 9 Oct 2020 07:23:57 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 BCAA23A0846 for ; Fri, 9 Oct 2020 07:23:57 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id x20so3705088qkn.1 for ; Fri, 09 Oct 2020 07:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nmc8FNoPRzfTTEmZKYTwHIJVW48HZTM8eqGai9BKWPs=; b=OooxFyARdaqGw8HvpTL7eA3Id+juNxmLBn77dkoJ4o5vdpIz2wkmmwQID2WH9JW4i2 1DqbFtMtWvy0hOH4Vh9WIfqeBEdB6wvIPaqx8ORP4TcF+4/3geREYbM02eSh54D+g610 nmdtaDRo1yX+oO7KZY5GknaAtuPhROwZhwdytxkv/7/4p9QOGHhVAaF5w0L3gRvzBEgp sEEQFaB2j0j6PtHw2QhXVrrEppl5sydXeqQYNE686x4phul783qIZtaiDA9ZCnwIHOma pbPahl4qHY45HyZS6vNK2e4CrzreLHLA95GRrXUs1BDJBNNBmizplaJLEXjYX917bwvC Z8PA== 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 :content-transfer-encoding:message-id:references:to; bh=Nmc8FNoPRzfTTEmZKYTwHIJVW48HZTM8eqGai9BKWPs=; b=H+S5pPj+/EB5MUdys7kwQJZ7vRatdLi7lBu8pcKyGZBoA0d9e88v1ROTl1CXL9WXy3 K0VW9nxOeqPLBI4F3i6XQ8xIFnDqZezCWbGRr9p4oL0xA5KVpcLSo6UtsduxZ7xIXps8 33okMOTK30DVqFSvaWTsW+6X9zhfi+TgFYaaffqICoJsY565tkBkGpvQ13XGcTtDXU8U A9s7La38U7N3Dkh/1ZjBduUtmr0cuoyRWi5fMHV9hlPg6pHtyZSAfHoUkqA9Fqhucy31 9eh6GLEZS3S+i+RuUUGhNgvg+DBfJX+GbSa3oMadp+JmB19YYPx8u7T3EwPHt+TK8Oqh 7OVQ== X-Gm-Message-State: AOAM533D6VjSs6g8ii2iVf0xr1fANJPJRUvy1xuV+cYerY/36/mrbymF JnYCyMQ6esHyYKBmGhJFr9sfsTVUGeDtiuWs X-Google-Smtp-Source: ABdhPJyVHP6aSMZPubEPZwyC0CM40u22jO7qHbrJVrM2msjW04kNJTU8o4avXn0lGESihWB8gjPqBw== X-Received: by 2002:a05:620a:54f:: with SMTP id o15mr13250919qko.91.1602253436865; Fri, 09 Oct 2020 07:23:56 -0700 (PDT) Received: from [192.168.0.153] (c-69-242-45-210.hsd1.pa.comcast.net. [69.242.45.210]) by smtp.gmail.com with ESMTPSA id q135sm4891387qka.93.2020.10.09.07.23.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 07:23:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Chris Wendt In-Reply-To: <778633be-5252-d5e2-3272-af615f41e8a2@alum.mit.edu> Date: Fri, 9 Oct 2020 10:23:55 -0400 Cc: "Peterson, Jon" Content-Transfer-Encoding: quoted-printable Message-Id: References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> <3A143F2A-2E4D-4B08-8E61-3F32CB3FB9B4@team.neustar> <778633be-5252-d5e2-3272-af615f41e8a2@alum.mit.edu> To: Brian Rosen , "sipcore@ietf.org" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 14:24:00 -0000 So, i think i=E2=80=99ve heard some good suggestions/comments, but not a = lot of disagreement that would prevent adoption. Could I ask for WG adoption for draft-wendt-sipcore-callinfo-rcd-03? Thanks! -Chris > On Aug 5, 2020, at 12:23 PM, Paul Kyzivat = wrote: >=20 > I had more thoughts after hitting send. So elaborating: >=20 > On 8/5/20 12:01 PM, Peterson, Jon wrote: >> Thanks for taking a glance Paul. Just to the matter of call reason = and Subject: >> Similarly, I think it need do discuss the need for the = "call-reason" >> parameter. As the draft notes, the contents of the Subject header = could >> be used for this purpose. I would like to some some further in >> investigation of why it is unsuitable before giving up on it. >> Broadly I imagine that call reason might eventually call for = structured data to handle cases like internationalization (display the = Spanish version if the UE indicates a native Spanish speaker) or broad = categories of subject types ("appointment/reservation confirmation" or = "IVR callback") that might be handled programmatically in some way. I = guess I look at the Subject header as pretty syntactically poor, and = moreover something that legacy implementations might expect to treat = already in some unhelpful way (most likely by stripping/ignoring it). = But I'm interested to hear what people think about this one. >=20 > This all makes sense to me. It just needs to make it into the = document. >=20 > While it makes sense to me that you might want a syntactically richer = call reason than what fits in the Subject header, as defined it isn't = any richer - it is still just a string. >=20 > Thanks, > Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Oct 9 10:06:59 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658EC3A0D1E for ; Fri, 9 Oct 2020 10:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-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 OmOrpMBCgg3B for ; Fri, 9 Oct 2020 10:06:57 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 D769B3A0D18 for ; Fri, 9 Oct 2020 10:06:56 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id q1so9779527ilt.6 for ; Fri, 09 Oct 2020 10:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=+bNMqkmx1fmnk6gMC75/y/kaBBhjlJjGBThhSw8/FLk=; b=MqtDVk0b9S0PAwstaw2FVsqcQe1fqzMniL+7+0vp3v22SCIf3penpQprNUNGLwrd9d r3gx5Ah1nlouPn0xnQRCeEFrh+3gRYDDy6yQInruyoTa2OXAHf+7TUhjMFtVQun5xOtG /guMVb2b8w/wBBvF1fz0XkxWzIyUeh52hlozE7JnDvVOrf6K/vX+Kk/SuzV9UV6PViFf bsBElfA1T57vfUcuzLG24vrqO1SmJ2dWWs5YVZnPE5+CQTSM8LhGd9WPnL7T2Al57Nck /stn84uAsAcNs7UxrSc8dr3aCOoOvtA7vpAHlHKqh87tUXAZGo+XHUDuyF9Z41vAX2Uz 7YlA== 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=+bNMqkmx1fmnk6gMC75/y/kaBBhjlJjGBThhSw8/FLk=; b=kPeuwKrdHRytT7I3URp+5Nn4uX40DT4xrm96PtzPExBd7JVZtbgXDQZpC7fr36fw15 1sJXJEBD9jPqzixEmpH3AUPz63ESFcy4EAsdmrW/5A+IXI2lv6gaKlI4iWuOSwDcF2Eb ifpvBMi0yoXSPunCQ9oSBzGouiRN3LPV6cc6PAAFy//Ma2oCitwt0bXihAD+D32c6nmb wZRheWl5YCkxqDI6VzMXa1GTb5TWFh/N25CNuTbo6bkKmlUjUfXCYxYeBCOSTHZuDGoF ioAHF+tmIiEol3FGC3Ht+wc7kVMX1iIzHleBqkSB7aPCCe/hIbiGiQtVPuqxDXbuko+c oooQ== X-Gm-Message-State: AOAM532uLLZmn6kBhv0BwrZAaUAom6EHC/fqAYZt/nTzV+5fAQ1Y9Nki ajfymFE3yuPGDv4PVJCgZNVO/sm9QYWUZz7O X-Google-Smtp-Source: ABdhPJyBJsNBqrjsm3ijblhwFcONJxEEr6TIdYMueJbYBYPqHnqo+9l2eibcNwRYH9S/8Ca8DheswQ== X-Received: by 2002:a92:c5ad:: with SMTP id r13mr10027573ilt.96.1602263215536; Fri, 09 Oct 2020 10:06:55 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id s13sm4411383ilq.16.2020.10.09.10.06.54 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 10:06:55 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_6E840350-6D37-4F7A-8B12-30EC4BC5CA83" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <4B853BAF-CCD2-488B-B969-418631EA1F82@brianrosen.net> Date: Fri, 9 Oct 2020 13:06:53 -0400 To: SIPCORE X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [sipcore] Call For Adoption draft-went-sipcore-callinfo-rcd X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 17:06:58 -0000 --Apple-Mail=_6E840350-6D37-4F7A-8B12-30EC4BC5CA83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This message starts a two week call for adoption of = https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-03 = Please send comments and offers to assist/review/comment to the list. Brian= --Apple-Mail=_6E840350-6D37-4F7A-8B12-30EC4BC5CA83 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii This message starts a two week call for adoption of https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-03

Please send comments and offers to assist/review/comment to the list.

Brian
--Apple-Mail=_6E840350-6D37-4F7A-8B12-30EC4BC5CA83-- From nobody Sat Oct 10 12:06:13 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BE73A1693 for ; Sat, 10 Oct 2020 12:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKHmXEPNObL6 for ; Sat, 10 Oct 2020 12:06:09 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2047.outbound.protection.outlook.com [40.107.94.47]) (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 76F7A3A163A for ; Sat, 10 Oct 2020 12:06:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xd4vixJ1Yya1+r/NZP3I46uZt3mdjYkfDP2OnxlW2eVr4svze+ffaUFRcijF5w8pfF/GBenZgJmfmmRrxKQA4NPkyDfBJJpRKlr2HBZoRplIFJ6OrrEFpLUCzA9a6B1A25q6OIp0YIXTYIEw9acLLrTr5/Gs8Vg2Q0SB32ygye4GYsnMxVmTzmmngAvGYf4BXedTzlHnffYmDFWdXNkVKAUi+GCepteNjja9xxxZ08wciJD2j62h7CaU8pQ/I5gzAxOItQkMHNCV4nVe7QV4/XA5xFjgqzqiKbezR2RpyDqTREOCro7AfPlFpGuOR4TxyiWe6acqsdC9VPRcG1g1TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q3nMBwpjO08aWhQ83+/2gzY4mDwzZNknJ9aWzvMWwrg=; b=lbuge5aLYmvdqY9HDrr92wDSqMwh/mPi0+2WZHdVUu+NiDBqqO6fs2JjuKs+nrpBfru0ReciLDJyzS/8ve1wT4DpXbiUMRJegO9TPvdoIuhXaYab5qT8LcoortugDuGTNXnr9VQRrKBRfilNF78lhY55JF/ywFLcNM5IV0+EevXArYQ+GdsUd8C387akYkK97pgj+YT0c9inhweE2wWdcFu3Shb7mmpAoak5gRe6KvdyNT4T2AxhSrU30cb/RN8176LYb+1Lvn00SypxikcJC9+wE2+K1PdwCk16hDb9FsQop1sBCvOVf4DfWGRNGqH6YF504rr5rmJGBnvBAUoJmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q3nMBwpjO08aWhQ83+/2gzY4mDwzZNknJ9aWzvMWwrg=; b=QM9MyFMKYfs9+xSje1yxRAllZmF5vbK7Mk6KbRnLFOBbFTiVgrk4yfnEfROeR6U02Q3JdRm4zK+XsKlFnYXYI3u8ovxh/HNr9xDCwXZ+pCa7fIcqZSgErPPp3C9KCk6jPToIus21ND8gJznc51gu/bu06q2sIzHGa1YoTtvqeZY= Received: from SN6PR08CA0015.namprd08.prod.outlook.com (2603:10b6:805:66::28) by MN2PR12MB4333.namprd12.prod.outlook.com (2603:10b6:208:1d3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.22; Sat, 10 Oct 2020 19:06:06 +0000 Received: from SN1NAM02FT042.eop-nam02.prod.protection.outlook.com (2603:10b6:805:66:cafe::8e) by SN6PR08CA0015.outlook.office365.com (2603:10b6:805:66::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23 via Frontend Transport; Sat, 10 Oct 2020 19:06:06 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT042.mail.protection.outlook.com (10.152.73.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.25 via Frontend Transport; Sat, 10 Oct 2020 19:06:05 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09AJ63VQ009122 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 10 Oct 2020 15:06:04 -0400 To: sipcore@ietf.org References: <4B853BAF-CCD2-488B-B969-418631EA1F82@brianrosen.net> From: Paul Kyzivat Message-ID: <774e399f-35ae-b934-f9e6-a3fc1a9e6911@alum.mit.edu> Date: Sat, 10 Oct 2020 15:06:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <4B853BAF-CCD2-488B-B969-418631EA1F82@brianrosen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 26dfd759-7bcf-4e66-99be-08d86d4f8a03 X-MS-TrafficTypeDiagnostic: MN2PR12MB4333: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3631; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IcJE6hInOjrBGVVDs3kVBTQX5dbVmzNAQKClkUnsydMFc/tXAk93VFGwoNQrA+RwDpylaZ05OxqAfqb5pgK8jNVNd8VnKhQVabe6kQLs2focL2BdxdR6PbRj7rxvncAjfBgqTwlpAqGEep1XmLSejVvrQvySLDQdjWF6GVh34s613GkUmgg/vE48J3LnuRYGiS4lfL1IcIXKud5i6FU1Iu+tV38PptRdscDxfwyPHg3666W/fiXe1oTsMFtSG+gyiCBz8cwHRzQ+c17pQUH+4Xr2RpxW/6QDtYkFqazcIx4yjW13i2simYy0yR98yl2xrIUhwAdS+hcAWoqGKIrcWp1rgULyWkI73LgSc+BCE5chd6RUkyfHUF266YqPm5gWtNNshYesBMv91PqZ15jrT1+CZFbp3Y7QCtsjVPz7eeQDrg5vrih/HYvbqrujRpYRlErchov1W5czSaEqLNXa3KMslhE+IXMuDWRzkJUYKcfXuAcgTermcq3VqMYTI3T3 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(346002)(396003)(376002)(136003)(39860400002)(46966005)(478600001)(86362001)(47076004)(6916009)(53546011)(26005)(966005)(75432002)(82310400003)(2906002)(5660300002)(36906005)(7596003)(83080400001)(2616005)(336012)(8936002)(70586007)(70206006)(956004)(186003)(786003)(316002)(82740400003)(8676002)(31696002)(356005)(83380400001)(4744005)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2020 19:06:05.6401 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 26dfd759-7bcf-4e66-99be-08d86d4f8a03 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT042.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4333 Archived-At: Subject: Re: [sipcore] Call For Adoption draft-went-sipcore-callinfo-rcd X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 19:06:11 -0000 I support adoption. On 10/9/20 1:06 PM, Brian Rosen wrote: > This message starts a two week call for adoption of > https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-03 > > > Please send comments and offers to assist/review/comment to the list. > > Brian > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Oct 10 15:37:19 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5923A09DF for ; Sat, 10 Oct 2020 15:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyHWaP-kL2a9 for ; Sat, 10 Oct 2020 15:37:15 -0700 (PDT) Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [192.185.168.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F8F3A09E1 for ; Sat, 10 Oct 2020 15:37:15 -0700 (PDT) Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway30.websitewelcome.com (Postfix) with ESMTP id B963C5D0 for ; Sat, 10 Oct 2020 17:37:13 -0500 (CDT) Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id RNUHkjLiNLFNkRNUHkkU8Q; Sat, 10 Oct 2020 17:37:13 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+uwN/N37AQhHWk0hEYiEYmz2fPUfNciRBqQ/Lnuzd3A=; b=c2u6EhWXRcppTMiX8xB8jS28yR AL27TzhIWvcAr+S+ggbWSbggydvA0EoVhib7X3Omkw9SvgvmqFrVUegRbSImYI3/svJnVEm4f4rya QffwRZu8vk+ztbHeTBCwgmpYJ; Received: from pool-100-36-18-145.washdc.fios.verizon.net ([100.36.18.145]:52484 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.93) (envelope-from ) id 1kRNUH-001ARk-Bd; Sat, 10 Oct 2020 16:37:13 -0600 User-Agent: Microsoft-MacOutlook/16.41.20091302 Date: Sat, 10 Oct 2020 18:37:11 -0400 From: Richard Shockey To: Paul Kyzivat , Message-ID: <4A8025B5-7E1C-4C96-A7DF-D5A2DB16698F@shockey.us> Thread-Topic: [sipcore] Call For Adoption draft-went-sipcore-callinfo-rcd References: <4B853BAF-CCD2-488B-B969-418631EA1F82@brianrosen.net> <774e399f-35ae-b934-f9e6-a3fc1a9e6911@alum.mit.edu> In-Reply-To: <774e399f-35ae-b934-f9e6-a3fc1a9e6911@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5527.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.18.145 X-Source-L: No X-Exim-ID: 1kRNUH-001ARk-Bd X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-18-145.washdc.fios.verizon.net ([192.168.1.156]) [100.36.18.145]:52484 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [sipcore] Call For Adoption draft-went-sipcore-callinfo-rcd X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 22:37:17 -0000 + 1 I support adoption as well. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =EF=BB=BFOn 10/10/20, 3:06 PM, "sipcore on behalf of Paul Kyzivat" wrote: I support adoption. On 10/9/20 1:06 PM, Brian Rosen wrote: > This message starts a two week call for adoption of=20 > https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-03=20 > >=20 > Please send comments and offers to assist/review/comment to the list. >=20 > Brian >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Oct 11 08:07:39 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112433A0E56 for ; Sun, 11 Oct 2020 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 jKbtgLAt6-HA for ; Sun, 11 Oct 2020 08:07:35 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 A04F83A0E51 for ; Sun, 11 Oct 2020 08:07:35 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id u74so7697201vsc.2 for ; Sun, 11 Oct 2020 08:07:35 -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:cc; bh=UAVivG8t8pDK3fhNTUia5YW+PNDV+JNBVatLDZHhDQI=; b=sF01twOTB3LCs6BHVI+DY8SP16Qf1DDhOXjplWWWozq9KYIEBhPl3JsQvtojiZ6vlI HAX6ska8lBHYp1zuMZEMSNSq4NCHANGO3+tgDdHULd7bcWW9eHSIUifCq+zltd89k7JC M6udVtPnZ/0buHthtg27R0UKtyL++XuQ+cxJ9tmhTyhg8em+qKnnxsMW+UhShwlXCbZp lOz/KOqQvdKkKYpLGjV837bOb8e0XhpZ8yvS5Igi7mnQZiB0+8sZucWMcqOuEP+xKAAG Z8qV4fGQOFS3WybZ3MLAt2Le2bT1YmfwnmWSowArGASy4NWRgRrAggxpt9/4/PAdLYTl Zs3Q== 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:cc; bh=UAVivG8t8pDK3fhNTUia5YW+PNDV+JNBVatLDZHhDQI=; b=sq/R4G/dn6HWGHt6q1E0Mp/f8PVB77R0F1b0UqGAZyTyT1rNyrZYnU39OEUKGUqcZm MdGj3O0DYyLsn6/bwmSRz6UIXXJEJBsL/AgmiZvLLpXyDQXS4XYgHWfVRYBNJ6/4cjn+ K/cSAMRxkYGirQPAvRfdLPkAGqCIpPwNiYAONvJx0It4vzRILK/LuxEU/G5m+QhrNFVY dpNdghWVzzk3HMa7WnjAIyvy4zfR816g/PcwwCVOkaWg6PhrbCN7CHwhYWvHMMZAp0W7 QNLwc490V+lJhmGXySQv5Q0jYqO+7l4t07T47VcSVomJ8Bzseg4GBRTc6Gv2BrFL8+fd vObg== X-Gm-Message-State: AOAM532rf3/qSZclgOoqvbK8YNJUpMDcVw4LEeRiLBEt6J5GJ3IFkzz/ jhKRyS4ahjyNCXTrnMsgG//Zx6BHTRF5JwHNJyrUWpI4g0Apzw== X-Google-Smtp-Source: ABdhPJxug5jFi+nd/0pQxMW6CO4+6pqlBmAxYsS9tOUercux3yxL8I031NF4OuEqn5Xnb+kkDnQn2BHtjZhy9TP/3AQ= X-Received: by 2002:a67:fb96:: with SMTP id n22mr12120292vsr.13.1602428854192; Sun, 11 Oct 2020 08:07:34 -0700 (PDT) MIME-Version: 1.0 From: Yehoshua Gev Date: Sun, 11 Oct 2020 18:07:23 +0300 Message-ID: To: sipcore Content-Type: multipart/alternative; boundary="000000000000a1cdd205b1668a56" Archived-At: Subject: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 15:07:37 -0000 --000000000000a1cdd205b1668a56 Content-Type: text/plain; charset="UTF-8" Hi All, I hope it is ok to post this here and not on sip-implementors... We are trying to implement RFC 8599 for performing push notifications for Apple devices. Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps receiving VoIP push notifications *must report the call quickly to CallKit, so it can alert the user* to the presence of the incoming call." According to RFC 8599, pushes are used for (at least) two different goals: 1) Initiating registration refreshes (section 5.5) 2) Notifying of incoming calls (section 5.6.2) Now, for a reasonable user experience, the registration refresh pushes must not trigger the UI of incoming call. However, when an INVITE is received, the UA must be awoken immediately, which is the purpose of VoIP push. Does it make sense to make a different push type for registration refresh and for incoming calls? I'm not sure this is possible with the current RFC (and it is also against the spirit of the RFC), but I can't think of another way around it (besides using regular pushes instead of VoIP pushes, which might introduce delays, or having a registration with infinite expiration that will not require refreshes, which might leave many zomby registrations). See some discussion here: [2], [3]. Thanks, Yehoshua [1] https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-voip [2] https://developer.apple.com/forums/thread/117939 [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps --000000000000a1cdd205b1668a56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I hope it is ok to=C2=A0post th= is here and not on sip-implementors...

We are tryi= ng to implement RFC 8599 for performing push notifications for Apple device= s.

Starting with iOS 13, there is a restriction=C2= =A0on VoIP pushes [1]: "Apps receiving VoIP push notifications must= report the call quickly to CallKit, so it can alert the user to the pr= esence of the incoming call."

According to RF= C 8599, pushes are used for (at least) two different=C2=A0goals:
= =C2=A0 1) Initiating registration refreshes (section 5.5)
=C2=A0 = 2) Notifying of incoming calls (section 5.6.2)

Now, for a reasonable=C2=A0user experience, the registration refresh pushe= s must not trigger the UI of incoming call.
However, when an INVI= TE is received, the UA must be awoken immediately, which is the purpose=C2= =A0of VoIP push.

Does it make sense to make a diff= erent push type for registration refresh and for incoming calls?
=
I'm not sure this is possible with the current RFC (and = it is also against the spirit of the RFC), but I can't think of another= way around it (besides using regular pushes instead of VoIP pushes, which = might introduce delays, or having a registration with infinite expiration t= hat=C2=A0will not require refreshes, which might leave many zomby registrat= ions).

See some discussion here: [2], [3].

Thanks,
Yehoshua


--000000000000a1cdd205b1668a56-- From nobody Sun Oct 11 13:43:53 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DA33A08B9 for ; Sun, 11 Oct 2020 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 CzCAcSaArD_6 for ; Sun, 11 Oct 2020 13:43:50 -0700 (PDT) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 EFA1D3A08B2 for ; Sun, 11 Oct 2020 13:43:49 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id x62so16557785oix.11 for ; Sun, 11 Oct 2020 13:43:49 -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 :cc; bh=gpuspdb2F+sf/8/U6Vfw3tcDUm2+xWPXctsu063arcc=; b=pKicZGfIFLeGJRxtRivC926U9Zum1AHmZOGcYwpw2U31qRcRSIbPFY712FKi5zkNWF IgovWWtAyX39Xu/QqUEYx2jC1c7A0aaJLq53y8hjANTLLe1mZAM2NF4mp+X7cZq2OkRK HtgIKbO4EBn6qaVLKIasMfN8HOS+enS2l51sMio1U/WPLEQaDWDabwqG2l+Y6KMIN2Ww mYAbFJl48DwOXSn+qDhNyhvPf2M4xJgI7SRKo3Yyxi3HopEaI5nJas0WAtGXiq80NmrY 7rqDIqX8d+mOT9cETvGslXNnovlotrPUl8xKTHTrkkHxu9O+zb8k7Ppe3sgkrKLXJID9 S9OQ== 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=gpuspdb2F+sf/8/U6Vfw3tcDUm2+xWPXctsu063arcc=; b=J1PiDIkvLHrIZPc5OkFLkIsFXmEoGBMMQlqYGt+r/211N/4pB1Ji5vt9smyrYNme7c /rdxC4T12EU5878YLApHZKw3iOWm5t9Rs2jJlPL6YBZ7I8GClqOJMRnSxjYBJD9rKHp/ k6JCQWYuE80PKfVeid3oQ2XK8oIODBr5vbFn/sgLSslf1Afy4Ug/IPEhXLBsK2YQZq2c Un+UPoS0IQWJ++OnhNTkQ9FNy3FSRH/w0COMjM6AWfQ2lkLRk5oy0OrDEYoIHgOsFeZD K89AV8QXq7dPJv+YZgRYyxe3T4eiNBQrRXp9h0MbCFBqRY7dGPj2XCiBqfUA667QTpD9 F8GA== X-Gm-Message-State: AOAM532GnUoORqfpjqvE/ON/HFHcUsOCiA9jsk5kKYB50AJqVFqb5PbE Q6Zs1+g3pXnk+/J61JCvSQV95Av4IL3UGmw4tJY= X-Google-Smtp-Source: ABdhPJzifLDEiEnMyxdKveaMIEkWDAbKtmaVLZ6Ul43iktTAw5Hjwy0/9O33YCRAOscYyKzo5Iix1w4LuLm6iPxTZi0= X-Received: by 2002:aca:b2d7:: with SMTP id b206mr9262467oif.110.1602449029185; Sun, 11 Oct 2020 13:43:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon MORLAT Date: Sun, 11 Oct 2020 22:43:29 +0200 Message-ID: To: Yehoshua Gev Cc: sipcore Content-Type: multipart/alternative; boundary="00000000000027c44005b16b3d16" Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 20:43:52 -0000 --00000000000027c44005b16b3d16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yehoshua, Thank you for starting this discussion. My company is developing the Linphone software (https://linphone.org), an cross platform open-source SIP softphone and SDK. The last version we published was for adding compatibility for iOS 13. I admit it was a nightmare to comply with the new restrictions. For push notifications, we based our work on RFC 8599 , but indeed we had to somewhat extend the RFC in order to transmit 2 different push notification tokens: - the one for calls (PushKit kind of notifications) - the one for IMs (using Remote push notification service). To answer your question: the "remote push notification" token could apparently also be used for "Background push notifications" ( https://developer.apple.com/documentation/usernotifications/setting_up_a_re= mote_notification_server/pushing_background_updates_to_your_app?language=3D= objc ), which are the push notifications we need to refresh a REGISTER that is about to expire (or expired). So yes you need two different push services and tokens. As of today, the Linphone app doesn't use push notifications for triggering REGISTER refreshes: we use a very long expire time (one year) instead. However we would prefer to switch to push-triggered REGISTER refresh as soon as possible. The syntax extension we made to RFC8599 is described in our wiki: https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/iOS/= #HUpdateContactURIparameters We designed this syntax to be compatible with RFC8599 syntax. To summarize, here is a quick example to understand how we convey push tokens for an app that needs to advertise calls and IMs: pn-prid=3D00fc13adff78512:voip&c11292f7b74733d:remote; pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;pn-provider=3Dapns Notice the ":voip" and ":remote" token suffixes, and the "&". We decided not to go with a multiple contact headers approach, each contact uri bearing a pn-prid for either voip or remote service: the forking by a proxy that is unaware of push notifications could result in INVITEs to be duplicated. We had to go fast otherwise our app would stop working, but from the beginning we have in mind that this issue should be raised and hopefully resolved here at IETF, with or without our proposed syntax extension. Today due to Apple's recent changes, it looks like RFC8599 cannot be used "as is" to make a SIP app for iOS. The risk that Google does the same in near future exists. Are there people interested here in collaborating to an RFC8599 update to address this iOS platform evolution ? In other words, we need to solve how to convey multiple pn-prid and pn-param for a same user-agent instance. Best regards, Simon Le dim. 11 oct. 2020 =C3=A0 17:07, Yehoshua Gev a =C3= =A9crit : > Hi All, > > I hope it is ok to post this here and not on sip-implementors... > > We are trying to implement RFC 8599 for performing push notifications for > Apple devices. > > Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps > receiving VoIP push notifications *must report the call quickly to > CallKit, so it can alert the user* to the presence of the incoming call." > > According to RFC 8599, pushes are used for (at least) two different goals= : > 1) Initiating registration refreshes (section 5.5) > 2) Notifying of incoming calls (section 5.6.2) > > Now, for a reasonable user experience, the registration refresh pushes > must not trigger the UI of incoming call. > However, when an INVITE is received, the UA must be awoken immediately, > which is the purpose of VoIP push. > > Does it make sense to make a different push type for registration refresh > and for incoming calls? > > I'm not sure this is possible with the current RFC (and it is also agains= t > the spirit of the RFC), but I can't think of another way around it (besid= es > using regular pushes instead of VoIP pushes, which might introduce delays= , > or having a registration with infinite expiration that will not require > refreshes, which might leave many zomby registrations). > > See some discussion here: [2], [3]. > > Thanks, > Yehoshua > > [1] > https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-voip > [2] https://developer.apple.com/forums/thread/117939 > [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00000000000027c44005b16b3d16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Yehoshua,

Thank you for starting this discussion.
My company is deve= loping the Linphone software (https://linp= hone.org), an cross platform open-source SIP softphone and SDK.
The last version we published was for adding compatibility for iOS 13. I= admit it was a nightmare to comply with the new restrictions.
Fo= r push notifications, we based our work on RFC 8599 , but indeed we had to = somewhat extend the RFC in order to transmit 2 different push notification = tokens:
- the one for calls (PushKit kind of notifications)
=
- the one for IMs (using Remote push notification service).=C2=A0

To answer your question: the "remote push notific= ation" token could apparently also be used for "Background push n= otifications" (https://developer.apple.com/documentat= ion/usernotifications/setting_up_a_remote_notification_server/pushing_backg= round_updates_to_your_app?language=3Dobjc ), which are the push notific= ations we need to refresh a REGISTER that is about to expire (or expired). = So yes you need two different push services and tokens.

As of today, the Linphone app doesn't use push notifications for = triggering REGISTER refreshes: we use a very long expire time (one year) in= stead. However we would prefer to switch to push-triggered REGISTER refresh= as soon as possible.

The syntax extension we made= to RFC8599 is described in our wiki:


We designed this syntax to be compatible with RFC8599 synta= x. To summarize, here is a quick example to understand how we convey push t= okens for an app that needs to advertise calls and IMs:

pn-prid=3D00fc13adff78512:v= oip&c11292f7b74733d:remote;pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;pn-provider=3Dapns

Notice the ":voip" and ":remote&= quot; token suffixes, and the "&".
We decided not to go with a multiple conta= ct headers approach, each contact uri bearing a pn-prid for either voip or = remote service: the forking by a proxy that is unaware of push notification= s could result in INVITEs to be duplicated.

We had to go fast otherwise our app would stop working, bu= t from=C2=A0the beginning we have in mind that this issue should be raised = and hopefully resolved here at IETF, with or without our proposed syntax ex= tension.

Today due to Apple's recent changes, it looks like RFC8599 ca= nnot be used "as is" to make a SIP app for iOS. The risk that Goo= gle does the same in near future exists.
Are there people interested her= e in collaborating to an RFC8599 update to address this iOS platform evolut= ion ? In other words, we need to solve how to convey multiple pn-prid and p= n-param for a same user-agent instance.

Best regards,

Simon







Le=C2=A0dim. 11 oct. 2020 =C3=A0= =C2=A017:07, Yehoshua Gev <yoshige= v@gmail.com> a =C3=A9crit=C2=A0:
Hi All,

I hope it is ok to=C2=A0post this here = and not on sip-implementors...

We are trying to im= plement RFC 8599 for performing push notifications for Apple devices.
=

Starting with iOS 13, there is a restriction=C2=A0on Vo= IP pushes [1]: "Apps receiving VoIP push notifications must report = the call quickly to CallKit, so it can alert the user to the presence o= f the incoming call."

According to RFC 8599, = pushes are used for (at least) two different=C2=A0goals:
=C2=A0 1= ) Initiating registration refreshes (section 5.5)
=C2=A0 2) Notif= ying of incoming calls (section 5.6.2)

Now, fo= r a reasonable=C2=A0user experience, the registration refresh pushes must n= ot trigger the UI of incoming call.
However, when an INVITE is re= ceived, the UA must be awoken immediately, which is the purpose=C2=A0of VoI= P push.

Does it make sense to make a different pus= h type for registration refresh and for incoming calls?

I'm not sure this is possible with the current RFC (and it is als= o against the spirit of the RFC), but I can't think of another way arou= nd it (besides using regular pushes instead of VoIP pushes, which might int= roduce delays, or having a registration with infinite expiration that=C2=A0= will not require refreshes, which might leave many zomby registrations).

See some discussion here: [2], [3].

Thanks,
Yehoshua

[1]=C2=A0<= a href=3D"https://developer.apple.com/documentation/pushkit/pkpushtype/1614= 481-voip" target=3D"_blank">https://developer.apple.com/documentation/pushk= it/pkpushtype/1614481-voip
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--00000000000027c44005b16b3d16-- From nobody Mon Oct 12 07:40:45 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF9C3A1532 for ; Mon, 12 Oct 2020 07:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 fVqsvAF3Oja9 for ; Mon, 12 Oct 2020 07:40:40 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 46D193A14FE for ; Mon, 12 Oct 2020 07:40:40 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id r24so9250867vsp.8 for ; Mon, 12 Oct 2020 07:40:40 -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 :cc; bh=qFxCqkmMWmTfmIUN0NLi6WgcZROox3th1vTR4G1ULU4=; b=MXpv0IEfCIkZb71hboZoAZlsPxRc/56XdGsLtpwBsjBURsS0SVxIY/pxHrRCWCLpH1 ROGU1HbMsS9RPzBweDUNORXyfamvXg9cDen0b/UyOE66XShIhlXrRU79mA3kUnXXGbYF eHvEplOOba1ATpjlajAtxbL6ExUdFlJcIAn6TijhHw4sH82+/5QQVBDEp/DpbS9l4Z2f 7BGYLzi4GgyXPY1rRaLIt09HFKQjnl/kvJYOu8lfBpXYuVbeHizzd5pHabJYwQdbElwn T3u6C8jhEl0iswl0skv1p76ycYFmw8L+YuKTcM04+WsQFqXXp3pC/EeW7lWCHG6TSkHG TXMA== 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=qFxCqkmMWmTfmIUN0NLi6WgcZROox3th1vTR4G1ULU4=; b=iXjQK2/Y1oxNeQMB36dcKrR8zQK+A+nJJYADy5YOhwcIEg+hCTKCuM1Un71qCng7Ue WMMOpQz25sxI9Sb/nu4VsAQQci515Ab/HBl/o2ucssrfCBlc8JXmYsM7EkA6Z5J5T4a8 n8Gz20XiC81/7wvAZkpX91k/zX6a6F9c4UJ8f0tSL/yly9bHXLvOTNl/E34p5ZDYp3GV PnVvOUOuSOU6V4x+CLQrLxrl5yw6S0KFWqlptEiCZcFrPyH7Y+HOVLiCzmSSI1CERr3v ZZZ2TUFo7TM085Ggjg9ovb94VDptDXAXVswtwtnwtEiiwwAaTOVOUgd97s+Y3MffwzbI SssA== X-Gm-Message-State: AOAM532NoWcu4gyoNS+du/g1N2LXnTDksG/yn5l0HpNpbg7c6g56GK+F p7FK46ITXTyax+LVggRcssfqXeSjURtDpddgRWU= X-Google-Smtp-Source: ABdhPJykw52EfwOPryIMKV+pUqFw7whssW1amPYQbtO5tlzJ+pXYsOYzGnwKZ+5L4BJ2U/VR4YVCHxMDs6TZfMY2Oq8= X-Received: by 2002:a67:ef5d:: with SMTP id k29mr10111094vsr.33.1602513639310; Mon, 12 Oct 2020 07:40:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yehoshua Gev Date: Mon, 12 Oct 2020 17:40:28 +0300 Message-ID: To: Simon MORLAT Cc: sipcore Content-Type: multipart/alternative; boundary="000000000000380d6105b17a48db" Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 14:40:43 -0000 --000000000000380d6105b17a48db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Simon, Thanks for your detailed explanation of the behavior you have implemented. One Q: How is the "pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote" us= ed? Does the server really make use of the "&remote" suffix or it can be used like "DEF123GHIJ.org.linphone.phone.*" with the "*" being always replaced with the service? In any case, I'm willing to help with work on a new RFC, but sadly I don't have much time for it. Regarding the scope of the updated RFC, I think there are several issues that should be addressed: 1. How the UA passes several "pn-*"-sets for a single registration. The solution you've done on Linphone seems like a good approach if backward compatibility with RFC 8599 is required. 2. How would the proxy decide which pn-*-values-set to use for a specific push notification? For example, a naive approach is to pre-define a mapping between "pr-*"-set and SIP methods (i.e., INVITE will use a "voip" params). 3. (maybe unrelated) For good user experience, the caller-id should be passed along with the voip push notification so the UI of incoming calls can display it immediately. BTW, regarding triggering of registration refreshes, our iOS developers say that in order for a push notification to work reliably (i.e., assured to be processed by the application even if it is terminated), it must have some UI notification. This means that the user will be informed of each registration refresh. If this is true, then the expiry time must be kept very long (weeks/months) in any case. Is this also your understanding? Yehoshua On Sun, Oct 11, 2020 at 11:43 PM Simon MORLAT wrote: > Hi Yehoshua, > > Thank you for starting this discussion. > My company is developing the Linphone software (https://linphone.org), an > cross platform open-source SIP softphone and SDK. > The last version we published was for adding compatibility for iOS 13. I > admit it was a nightmare to comply with the new restrictions. > For push notifications, we based our work on RFC 8599 , but indeed we had > to somewhat extend the RFC in order to transmit 2 different push > notification tokens: > - the one for calls (PushKit kind of notifications) > - the one for IMs (using Remote push notification service). > > To answer your question: the "remote push notification" token could > apparently also be used for "Background push notifications" ( > https://developer.apple.com/documentation/usernotifications/setting_up_a_= remote_notification_server/pushing_background_updates_to_your_app?language= =3Dobjc > ), which are the push notifications we need to refresh a REGISTER that is > about to expire (or expired). So yes you need two different push services > and tokens. > > As of today, the Linphone app doesn't use push notifications for > triggering REGISTER refreshes: we use a very long expire time (one year) > instead. However we would prefer to switch to push-triggered REGISTER > refresh as soon as possible. > > The syntax extension we made to RFC8599 is described in our wiki: > > > https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/iO= S/#HUpdateContactURIparameters > > We designed this syntax to be compatible with RFC8599 syntax. To > summarize, here is a quick example to understand how we convey push token= s > for an app that needs to advertise calls and IMs: > > pn-prid=3D00fc13adff78512:voip&c11292f7b74733d:remote; > pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;pn-provider=3Dapns > > Notice the ":voip" and ":remote" token suffixes, and the "&". > We decided not to go with a multiple contact headers approach, each > contact uri bearing a pn-prid for either voip or remote service: the > forking by a proxy that is unaware of push notifications could result in > INVITEs to be duplicated. > > We had to go fast otherwise our app would stop working, but from the > beginning we have in mind that this issue should be raised and hopefully > resolved here at IETF, with or without our proposed syntax extension. > > Today due to Apple's recent changes, it looks like RFC8599 cannot be used > "as is" to make a SIP app for iOS. The risk that Google does the same in > near future exists. > Are there people interested here in collaborating to an RFC8599 update to > address this iOS platform evolution ? In other words, we need to solve ho= w > to convey multiple pn-prid and pn-param for a same user-agent instance. > > Best regards, > > Simon > > > > > > > > Le dim. 11 oct. 2020 =C3=A0 17:07, Yehoshua Gev a = =C3=A9crit : > >> Hi All, >> >> I hope it is ok to post this here and not on sip-implementors... >> >> We are trying to implement RFC 8599 for performing push notifications fo= r >> Apple devices. >> >> Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps >> receiving VoIP push notifications *must report the call quickly to >> CallKit, so it can alert the user* to the presence of the incoming call.= " >> >> According to RFC 8599, pushes are used for (at least) two different goal= s: >> 1) Initiating registration refreshes (section 5.5) >> 2) Notifying of incoming calls (section 5.6.2) >> >> Now, for a reasonable user experience, the registration refresh pushes >> must not trigger the UI of incoming call. >> However, when an INVITE is received, the UA must be awoken immediately, >> which is the purpose of VoIP push. >> >> Does it make sense to make a different push type for registration refres= h >> and for incoming calls? >> >> I'm not sure this is possible with the current RFC (and it is also >> against the spirit of the RFC), but I can't think of another way around = it >> (besides using regular pushes instead of VoIP pushes, which might introd= uce >> delays, or having a registration with infinite expiration that will not >> require refreshes, which might leave many zomby registrations). >> >> See some discussion here: [2], [3]. >> >> Thanks, >> Yehoshua >> >> [1] >> https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-voi= p >> [2] https://developer.apple.com/forums/thread/117939 >> [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > --000000000000380d6105b17a48db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Simon,

Thanks for your detailed expl= anation of the behavior you have implemented.

One = Q: How is the "pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remot= e" used?
Does the server really make use of the "&r= emote" suffix or it can be used like "DEF123GHIJ.org.linphone.pho= ne.*" with=C2=A0the "*" being always replaced with the servi= ce?

In any case, I'm willing to help with work= on a new RFC, but sadly I don't have much time for it.

<= /div>
Regarding the scope of the updated RFC, I think there are several= issues that should be addressed:

1. How the UA pa= sses several "pn-*"-sets for a single registration. The solution = you've done on Linphone seems like a good approach if backward compatib= ility with RFC 8599 is required.

2. How would the = proxy decide which pn-*-values-set to use for a specific push notification?= For example, a naive approach is to pre-define a mapping between "pr-= *"-set and SIP methods (i.e., INVITE will use a "voip" param= s).

3. (maybe unrelated) For good user experience,= the caller-id should be passed along with the voip push notification so th= e UI of incoming calls can display it immediately.

BTW, regarding triggering=C2=A0of registration refreshes, our iOS develope= rs say that in order for a push notification to work reliably (i.e., assure= d to be processed by the application even if it is terminated), it must hav= e some UI notification. This means that the user will be informed of each r= egistration refresh. If this is true, then the expiry time must be kept ver= y long (weeks/months) in any case. Is this also your understanding?


Yehoshua


On Sun, Oct 1= 1, 2020 at 11:43 PM Simon MORLAT <simon.morlat@gmail.com> wrote:
Hi=C2=A0Yehoshua,

Thank you for starting this discussion.
My company is developing the Linphone software (https://linphone.org), an cross platfor= m open-source SIP softphone and SDK.
The last version we publishe= d was for adding compatibility for iOS 13. I admit it was a nightmare to co= mply with the new restrictions.
For push notifications, we based = our work on RFC 8599 , but indeed we had to somewhat extend the RFC in orde= r to transmit 2 different push notification tokens:
- the one for= calls (PushKit kind of notifications)
- the one for IMs (using R= emote push notification service).=C2=A0

To answer = your question: the "remote push notification" token could apparen= tly also be used for "Background push notifications" (https://developer.apple.com/documentation/usernotif= ications/setting_up_a_remote_notification_server/pushing_background_updates= _to_your_app?language=3Dobjc ), which are the push notifications we nee= d to refresh a REGISTER that is about to expire (or expired). So yes you ne= ed two different push services and tokens.

As of t= oday, the Linphone app doesn't use push notifications for triggering RE= GISTER refreshes: we use a very long expire time (one year) instead. Howeve= r we would prefer to switch to push-triggered REGISTER refresh as soon as p= ossible.

The syntax extension we made to RFC8599 i= s described in our wiki:

https://wiki.linphone.org/xwiki/wiki/publ= ic/view/Lib/Getting%20started/iOS/#HUpdateContactURIparameters

We designed this syntax to be compatible with RFC8599 = syntax. To summarize, here is a quick example to understand how we convey p= ush tokens for an app that needs to advertise calls and IMs:

=
pn-prid=3D00fc13adff78= 512:voip&c11292f7b74733d:remote;pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;<= span style=3D"color:rgb(51,51,51);font-family:"Helvetica Neue",He= lvetica,Arial,sans-serif;font-size:14px">pn-provider=3Dapns

Notice the ":voip" and ":re= mote" token suffixes, and the "&".
We decided not to go with a multiple = contact headers approach, each contact uri bearing a pn-prid for either voi= p or remote service: the forking by a proxy that is unaware of push notific= ations could result in INVITEs to be duplicated.

We had to go fast otherwise our app would stop workin= g, but from=C2=A0the beginning we have in mind that this issue should be ra= ised and hopefully resolved here at IETF, with or without our proposed synt= ax extension.
Today due to Apple's recent changes, it looks like RFC85= 99 cannot be used "as is" to make a SIP app for iOS. The risk tha= t Google does the same in near future exists.
Are there people intereste= d here in collaborating to an RFC8599 update to address this iOS platform e= volution ? In other words, we need to solve how to convey multiple pn-prid = and pn-param for a same user-agent instance.

Best regards,

Si= mon






Le=C2=A0dim. 11 oct. 2020 =C3= =A0=C2=A017:07, Yehoshua Gev <yoshigev@gmail.com> a =C3=A9crit=C2=A0:
Hi All,
<= br>
I hope it is ok to=C2=A0post this here and not on sip-impleme= ntors...

We are trying to implement RFC 8599 for p= erforming push notifications for Apple devices.

St= arting with iOS 13, there is a restriction=C2=A0on VoIP pushes [1]: "A= pps receiving VoIP push notifications must report the call quickly to Ca= llKit, so it can alert the user to the presence of the incoming call.&q= uot;

According to RFC 8599, pushes are used for (a= t least) two different=C2=A0goals:
=C2=A0 1) Initiating registrat= ion refreshes (section 5.5)
=C2=A0 2) Notifying of incoming calls= (section 5.6.2)

Now, for a reasonable=C2=A0us= er experience, the registration refresh pushes must not trigger the UI of i= ncoming call.
However, when an INVITE is received, the UA must be= awoken immediately, which is the purpose=C2=A0of VoIP push.

=
Does it make sense to make a different push type for registratio= n refresh and for incoming calls?

I'm not sure= this is possible with the current RFC (and it is also against the spirit o= f the RFC), but I can't think of another way around it (besides using r= egular pushes instead of VoIP pushes, which might introduce delays, or havi= ng a registration with infinite expiration that=C2=A0will not require refre= shes, which might leave many zomby registrations).

See some discussion here: [2], [3].

--000000000000380d6105b17a48db-- From nobody Mon Oct 12 07:55:33 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938853A1544 for ; Mon, 12 Oct 2020 07:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 VpPZwCeqZ8PH for ; Mon, 12 Oct 2020 07:55:30 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2082.outbound.protection.outlook.com [40.107.20.82]) (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 1F8523A1535 for ; Mon, 12 Oct 2020 07:55:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ph8l9tSPtQSqcIpS16aRHCRyq+18a2/9r68bEoDMqI1xwtDrTi4EiDWkTDLiArNO8jiiY6fnkmXiMSCaxFjffci1oSaAfTskl57I66Fs8niIXa+sN6c+AhfSrxl/uiJJwrqStxR4Zt7OnxMQpzJ9LhG2JsydnxmTTdiyvkDrsh8VLJmumaftYPOpnxLwIPB13oWj1fyYN1iZYMjiinlE7p+C2la1qSMaD5ECB+Qwy+gBCtyBeR+d6wgLTf3GIELPA13fD7b9l/d+8iJCq+aGbav4Z+G9l6+Ugz/uUwBeGoE91ECRPSYxjFSljEMijptYiDuM/8XZQe+ShGz7CiQJwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XuGlnHFLUx6RgJiS/dk2uj+u1s+Y/y4ZrXgdXuSYxco=; b=X8oBXQ/YgOYQ7Zb9PgZngLMOw/Fd4XrMksLyxBSe5Y7J+Kk+MMDAEeW0dkMz5E6g6cCcKX6eFSt9e41TxPcZq0Y9eKAcc9JESexC0++mvvRagflbDCVWDNVsw3/iiaAcWcCL8yoSisA6CARbw3j9v/OSMjacFEoAd9EsSS01Qjr2nOBeFTnvlYxr+0OublEgSFOFbw8VdpegyMLtTqHKjS/vCGTx36O9xQmbYl4Q5/8k1og73TGIT3mFpH0bJyWiEgF0Nu/LzAYbuvwkYDJG115xJ3T53CFCt8tNojn+VBgsh6WuJqVKSs/jFg5nMU7QAsy5dGW1mR40jDfGWhG9Gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XuGlnHFLUx6RgJiS/dk2uj+u1s+Y/y4ZrXgdXuSYxco=; b=YMF/PLbEOEFvrFEAEWRV6IuwUrhRwatcT9LsfExI3eDUG9Mm8+Ap64RDv74FT/B43+OG/4WRbMsqCr0uempBgZpVKSDQLpWty38FqG6wfxW85yKN7WWBy2FYnnhm21t2TMIQ1jRqD/8X3ASwtHa/X/drueyZbb4I8M0IJjXXyFo= Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM0PR07MB6402.eurprd07.prod.outlook.com (2603:10a6:20b:15e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Mon, 12 Oct 2020 14:55:28 +0000 Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::6cc3:4783:280b:d741]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::6cc3:4783:280b:d741%7]) with mapi id 15.20.3477.018; Mon, 12 Oct 2020 14:55:28 +0000 From: Christer Holmberg To: Simon MORLAT , Yehoshua Gev CC: sipcore Thread-Topic: [sipcore] Push notifications with iOS 13 (RFC 8599) Thread-Index: AQHWn+BDUTnEZITSgUW2d71fVS8LKKmS3pmAgAEvHcA= Date: Mon, 12 Oct 2020 14:55:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 235f41ce-b882-449b-4e3d-08d86ebedba4 x-ms-traffictypediagnostic: AM0PR07MB6402: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i0iWsOxhWIjVHS3RuFeJAB8A0i2VBallDFpQDzb55u2C0pu80YJjtVgsOjfSj9aNrhsRo5jWVtsVL7NX/5UQwBttNUdddKUiD3ZbZ1cnUzI72uMQpprTz3qRII6c4mZozIGF5TQrMbqM80xOoHVjWUYwcLuZaWIWW9rJK22A7eNtwjKh3PPy68DRKw+SVNl2CzHE5Sq+VWIHNXDzBIYsV9cPfOz048/7TwF5gIyUPRwY1Y3s6Q9J/EZkVde1rosbk7Ah4g71TUeC0to403QaVL7NqEXl/WQkJwC2wagovPEDmcgPeLdPE+9AjeyT6gwoEd0miJIps/KKWQ6Y+0El4oUZuYmOTxxjXg+6WIZ+zxmQXeY6M+Vo494jhba/M2sSzRs35NvZOCOQdZIEbq0EEQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(39860400002)(376002)(366004)(76116006)(66476007)(66556008)(64756008)(66946007)(66446008)(52536014)(5660300002)(83080400001)(4326008)(7696005)(166002)(9686003)(55016002)(478600001)(44832011)(2906002)(83380400001)(15650500001)(186003)(33656002)(966005)(26005)(66574015)(6506007)(8676002)(8936002)(110136005)(316002)(86362001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DnaG3IS1JyONavbB1UJlX3Deirw0+tmItjbkwxI9FD4zo0YnYWpQokj15jTnxv4KDCoEoKuduGZtagCm6SNRIeoLN0pml45EQ//oltkwEosxz6ESFecmwb+p8rQTyWe33Gsmp2taKcg1bC8xZzmX+KoCOS+NObgRuTNGaJ1P6tDGe8akSoH65/Zu7y8d8pBjZCWkXzd0rk6A5GwyxZPg+wl19MQqg8IQsvHC6ozXYP4/i/MVBAluGeFcRkE6ugZ/jszqHVf0Xt0FTrRA6OaG8vDCMcyldpJB9OOASu+CZxyvWZ8O7KzqQbENRIO1a7+YghyuIFQRIyMTyqnExune6okF09364HOFZk/H//hTNQAUd/IAdbx/cjQwknKnjcPBRNXctvpZAx/vO1/Zni1NLRso8WtKavVeTYbm9VXmVkfS2KVTCyFlRsrXjG/vW2Xaqp6KG0TEsHEIdjOPYonbJe/qiNhnYNbUcHaKAcKqpKmRf+37QS6c7G0HA4wmlHxBaYoH0ty2VkQiMyP+/x/AX7ktXBe6557OlAIJH8I9Cw80RukIC8gW7tJ6uQhNxBKmR50H48BcHZWXDZ1LPn0oKzJKkRY4OFPYgMXrH9WuGnkc+IcF8a8df8jT0Z4G+MIA49A5hJrsDIX6kXBJzGE70Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB3860F48A7A45C799B59466B993070AM0PR07MB3860eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 235f41ce-b882-449b-4e3d-08d86ebedba4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2020 14:55:28.0425 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dUP8rCG6zTrD9C/uf9sIXdk7hTj/r2lnh7tg1lSEGRY3tHPpmt1YYnzLtBrHaCUCqRPBT9Kgup5ZV+N+weQk8LRgQpdtCWFJfsSeD3K24yM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6402 Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 14:55:33 -0000 --_000_AM0PR07MB3860F48A7A45C799B59466B993070AM0PR07MB3860eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHlvdSBzdWdnZXN0LCBvbmUgc29sdXRpb24gaXMgdG8gdXNlIGEgZGlmZmVyZW50 IChub24tVm9JUCkgcHVzaCBub3RpZmljYXRpb24gaW4gb3JkZXIgdG8gdHJpZ2dlciByZS1yZWdp c3RyYXRpb25zLg0KDQpUaGUgb25seSBpc3N1ZSB3aXRoIHRob3NlLCBBRkFJSywgaXMgdGhhdCB0 aGVyZSBpcyBubyBndWFyYW50ZWUgd2hlbi9pZiB0aGV5IHdpbGwgYWN0dWFsbHkgd2FrZSB1cCB0 aGUgYXBwbGljYXRpb24uIEl0IGRlcGVuZHMgb24gYSBudW1iZXIgb2YgZmFjdG9ycywgZS5nLiwg ZW5lcmd5IG1vZGUsIGhvdyBvZnRlbiB0aGUgYXBwIGlzIHVzZWQsIGV0YyBldGMuIEhvd2V2ZXIs IEkgZG9u4oCZdCBoYXZlIGFueSBkYXRhIHJlZ2FyZGluZyB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBTaW1vbiBNT1JMQVQNClNlbnQ6IHN1bm51bnRhaSAxMS4gbG9rYWt1dXRhIDIwMjAg MjMuNDMNClRvOiBZZWhvc2h1YSBHZXYgPHlvc2hpZ2V2QGdtYWlsLmNvbT4NCkNjOiBzaXBjb3Jl IDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBQdXNoIG5vdGlmaWNh dGlvbnMgd2l0aCBpT1MgMTMgKFJGQyA4NTk5KQ0KDQpIaSBZZWhvc2h1YSwNCg0KVGhhbmsgeW91 IGZvciBzdGFydGluZyB0aGlzIGRpc2N1c3Npb24uDQpNeSBjb21wYW55IGlzIGRldmVsb3Bpbmcg dGhlIExpbnBob25lIHNvZnR3YXJlIChodHRwczovL2xpbnBob25lLm9yZzxodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTEwYzhkMDZlLTRlNjgzMGZhLTEwYzg5MGY1LTg2ZDIx MTRlYWIyZi1kOGNhZGI1MzgzOWYxZjkxJnE9MSZlPTViMGVlMjUyLTYyZTMtNDExMy05MDcyLWM0 Njk3NDMxOTM2YyZ1PWh0dHBzJTNBJTJGJTJGbGlucGhvbmUub3JnJTJGPiksIGFuIGNyb3NzIHBs YXRmb3JtIG9wZW4tc291cmNlIFNJUCBzb2Z0cGhvbmUgYW5kIFNESy4NClRoZSBsYXN0IHZlcnNp b24gd2UgcHVibGlzaGVkIHdhcyBmb3IgYWRkaW5nIGNvbXBhdGliaWxpdHkgZm9yIGlPUyAxMy4g SSBhZG1pdCBpdCB3YXMgYSBuaWdodG1hcmUgdG8gY29tcGx5IHdpdGggdGhlIG5ldyByZXN0cmlj dGlvbnMuDQpGb3IgcHVzaCBub3RpZmljYXRpb25zLCB3ZSBiYXNlZCBvdXIgd29yayBvbiBSRkMg ODU5OSAsIGJ1dCBpbmRlZWQgd2UgaGFkIHRvIHNvbWV3aGF0IGV4dGVuZCB0aGUgUkZDIGluIG9y ZGVyIHRvIHRyYW5zbWl0IDIgZGlmZmVyZW50IHB1c2ggbm90aWZpY2F0aW9uIHRva2VuczoNCi0g dGhlIG9uZSBmb3IgY2FsbHMgKFB1c2hLaXQga2luZCBvZiBub3RpZmljYXRpb25zKQ0KLSB0aGUg b25lIGZvciBJTXMgKHVzaW5nIFJlbW90ZSBwdXNoIG5vdGlmaWNhdGlvbiBzZXJ2aWNlKS4NCg0K VG8gYW5zd2VyIHlvdXIgcXVlc3Rpb246IHRoZSAicmVtb3RlIHB1c2ggbm90aWZpY2F0aW9uIiB0 b2tlbiBjb3VsZCBhcHBhcmVudGx5IGFsc28gYmUgdXNlZCBmb3IgIkJhY2tncm91bmQgcHVzaCBu b3RpZmljYXRpb25zIiAoaHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRpb24v dXNlcm5vdGlmaWNhdGlvbnMvc2V0dGluZ191cF9hX3JlbW90ZV9ub3RpZmljYXRpb25fc2VydmVy L3B1c2hpbmdfYmFja2dyb3VuZF91cGRhdGVzX3RvX3lvdXJfYXBwP2xhbmd1YWdlPW9iamMgKSwg d2hpY2ggYXJlIHRoZSBwdXNoIG5vdGlmaWNhdGlvbnMgd2UgbmVlZCB0byByZWZyZXNoIGEgUkVH SVNURVIgdGhhdCBpcyBhYm91dCB0byBleHBpcmUgKG9yIGV4cGlyZWQpLiBTbyB5ZXMgeW91IG5l ZWQgdHdvIGRpZmZlcmVudCBwdXNoIHNlcnZpY2VzIGFuZCB0b2tlbnMuDQoNCkFzIG9mIHRvZGF5 LCB0aGUgTGlucGhvbmUgYXBwIGRvZXNuJ3QgdXNlIHB1c2ggbm90aWZpY2F0aW9ucyBmb3IgdHJp Z2dlcmluZyBSRUdJU1RFUiByZWZyZXNoZXM6IHdlIHVzZSBhIHZlcnkgbG9uZyBleHBpcmUgdGlt ZSAob25lIHllYXIpIGluc3RlYWQuIEhvd2V2ZXIgd2Ugd291bGQgcHJlZmVyIHRvIHN3aXRjaCB0 byBwdXNoLXRyaWdnZXJlZCBSRUdJU1RFUiByZWZyZXNoIGFzIHNvb24gYXMgcG9zc2libGUuDQoN ClRoZSBzeW50YXggZXh0ZW5zaW9uIHdlIG1hZGUgdG8gUkZDODU5OSBpcyBkZXNjcmliZWQgaW4g b3VyIHdpa2k6DQoNCmh0dHBzOi8vd2lraS5saW5waG9uZS5vcmcveHdpa2kvd2lraS9wdWJsaWMv dmlldy9MaWIvR2V0dGluZyUyMHN0YXJ0ZWQvaU9TLyNIVXBkYXRlQ29udGFjdFVSSXBhcmFtZXRl cnM8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az1hZDliMzM1ZS1mMzNiZDNj YS1hZDliNzNjNS04NmQyMTE0ZWFiMmYtODFlMDk0NWYxYzc4NjFlYyZxPTEmZT01YjBlZTI1Mi02 MmUzLTQxMTMtOTA3Mi1jNDY5NzQzMTkzNmMmdT1odHRwcyUzQSUyRiUyRndpa2kubGlucGhvbmUu b3JnJTJGeHdpa2klMkZ3aWtpJTJGcHVibGljJTJGdmlldyUyRkxpYiUyRkdldHRpbmclMjUyMHN0 YXJ0ZWQlMkZpT1MlMkYlMjNIVXBkYXRlQ29udGFjdFVSSXBhcmFtZXRlcnM+DQoNCldlIGRlc2ln bmVkIHRoaXMgc3ludGF4IHRvIGJlIGNvbXBhdGlibGUgd2l0aCBSRkM4NTk5IHN5bnRheC4gVG8g c3VtbWFyaXplLCBoZXJlIGlzIGEgcXVpY2sgZXhhbXBsZSB0byB1bmRlcnN0YW5kIGhvdyB3ZSBj b252ZXkgcHVzaCB0b2tlbnMgZm9yIGFuIGFwcCB0aGF0IG5lZWRzIHRvIGFkdmVydGlzZSBjYWxs cyBhbmQgSU1zOg0KDQpwbi1wcmlkPTAwZmMxM2FkZmY3ODUxMjp2b2lwJmMxMTI5MmY3Yjc0NzMz ZDpyZW1vdGU7cG4tcGFyYW09REVGMTIzR0hJSi5vcmcubGlucGhvbmUucGhvbmUudm9pcCZyZW1v dGU7cG4tcHJvdmlkZXI9YXBucw0KDQpOb3RpY2UgdGhlICI6dm9pcCIgYW5kICI6cmVtb3RlIiB0 b2tlbiBzdWZmaXhlcywgYW5kIHRoZSAiJiIuDQpXZSBkZWNpZGVkIG5vdCB0byBnbyB3aXRoIGEg bXVsdGlwbGUgY29udGFjdCBoZWFkZXJzIGFwcHJvYWNoLCBlYWNoIGNvbnRhY3QgdXJpIGJlYXJp bmcgYSBwbi1wcmlkIGZvciBlaXRoZXIgdm9pcCBvciByZW1vdGUgc2VydmljZTogdGhlIGZvcmtp bmcgYnkgYSBwcm94eSB0aGF0IGlzIHVuYXdhcmUgb2YgcHVzaCBub3RpZmljYXRpb25zIGNvdWxk IHJlc3VsdCBpbiBJTlZJVEVzIHRvIGJlIGR1cGxpY2F0ZWQuDQoNCldlIGhhZCB0byBnbyBmYXN0 IG90aGVyd2lzZSBvdXIgYXBwIHdvdWxkIHN0b3Agd29ya2luZywgYnV0IGZyb20gdGhlIGJlZ2lu bmluZyB3ZSBoYXZlIGluIG1pbmQgdGhhdCB0aGlzIGlzc3VlIHNob3VsZCBiZSByYWlzZWQgYW5k IGhvcGVmdWxseSByZXNvbHZlZCBoZXJlIGF0IElFVEYsIHdpdGggb3Igd2l0aG91dCBvdXIgcHJv cG9zZWQgc3ludGF4IGV4dGVuc2lvbi4NCg0KVG9kYXkgZHVlIHRvIEFwcGxlJ3MgcmVjZW50IGNo YW5nZXMsIGl0IGxvb2tzIGxpa2UgUkZDODU5OSBjYW5ub3QgYmUgdXNlZCAiYXMgaXMiIHRvIG1h a2UgYSBTSVAgYXBwIGZvciBpT1MuIFRoZSByaXNrIHRoYXQgR29vZ2xlIGRvZXMgdGhlIHNhbWUg aW4gbmVhciBmdXR1cmUgZXhpc3RzLg0KQXJlIHRoZXJlIHBlb3BsZSBpbnRlcmVzdGVkIGhlcmUg aW4gY29sbGFib3JhdGluZyB0byBhbiBSRkM4NTk5IHVwZGF0ZSB0byBhZGRyZXNzIHRoaXMgaU9T IHBsYXRmb3JtIGV2b2x1dGlvbiA/IEluIG90aGVyIHdvcmRzLCB3ZSBuZWVkIHRvIHNvbHZlIGhv dyB0byBjb252ZXkgbXVsdGlwbGUgcG4tcHJpZCBhbmQgcG4tcGFyYW0gZm9yIGEgc2FtZSB1c2Vy LWFnZW50IGluc3RhbmNlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNpbW9uDQoNCg0KDQoNCg0KDQoN CkxlIGRpbS4gMTEgb2N0LiAyMDIwIMOgIDE3OjA3LCBZZWhvc2h1YSBHZXYgPHlvc2hpZ2V2QGdt YWlsLmNvbTxtYWlsdG86eW9zaGlnZXZAZ21haWwuY29tPj4gYSDDqWNyaXQgOg0KSGkgQWxsLA0K DQpJIGhvcGUgaXQgaXMgb2sgdG8gcG9zdCB0aGlzIGhlcmUgYW5kIG5vdCBvbiBzaXAtaW1wbGVt ZW50b3JzLi4uDQoNCldlIGFyZSB0cnlpbmcgdG8gaW1wbGVtZW50IFJGQyA4NTk5IGZvciBwZXJm b3JtaW5nIHB1c2ggbm90aWZpY2F0aW9ucyBmb3IgQXBwbGUgZGV2aWNlcy4NCg0KU3RhcnRpbmcg d2l0aCBpT1MgMTMsIHRoZXJlIGlzIGEgcmVzdHJpY3Rpb24gb24gVm9JUCBwdXNoZXMgWzFdOiAi QXBwcyByZWNlaXZpbmcgVm9JUCBwdXNoIG5vdGlmaWNhdGlvbnMgbXVzdCByZXBvcnQgdGhlIGNh bGwgcXVpY2tseSB0byBDYWxsS2l0LCBzbyBpdCBjYW4gYWxlcnQgdGhlIHVzZXIgdG8gdGhlIHBy ZXNlbmNlIG9mIHRoZSBpbmNvbWluZyBjYWxsLiINCg0KQWNjb3JkaW5nIHRvIFJGQyA4NTk5LCBw dXNoZXMgYXJlIHVzZWQgZm9yIChhdCBsZWFzdCkgdHdvIGRpZmZlcmVudCBnb2FsczoNCiAgMSkg SW5pdGlhdGluZyByZWdpc3RyYXRpb24gcmVmcmVzaGVzIChzZWN0aW9uIDUuNSkNCiAgMikgTm90 aWZ5aW5nIG9mIGluY29taW5nIGNhbGxzIChzZWN0aW9uIDUuNi4yKQ0KDQpOb3csIGZvciBhIHJl YXNvbmFibGUgdXNlciBleHBlcmllbmNlLCB0aGUgcmVnaXN0cmF0aW9uIHJlZnJlc2ggcHVzaGVz IG11c3Qgbm90IHRyaWdnZXIgdGhlIFVJIG9mIGluY29taW5nIGNhbGwuDQpIb3dldmVyLCB3aGVu IGFuIElOVklURSBpcyByZWNlaXZlZCwgdGhlIFVBIG11c3QgYmUgYXdva2VuIGltbWVkaWF0ZWx5 LCB3aGljaCBpcyB0aGUgcHVycG9zZSBvZiBWb0lQIHB1c2guDQoNCkRvZXMgaXQgbWFrZSBzZW5z ZSB0byBtYWtlIGEgZGlmZmVyZW50IHB1c2ggdHlwZSBmb3IgcmVnaXN0cmF0aW9uIHJlZnJlc2gg YW5kIGZvciBpbmNvbWluZyBjYWxscz8NCg0KSSdtIG5vdCBzdXJlIHRoaXMgaXMgcG9zc2libGUg d2l0aCB0aGUgY3VycmVudCBSRkMgKGFuZCBpdCBpcyBhbHNvIGFnYWluc3QgdGhlIHNwaXJpdCBv ZiB0aGUgUkZDKSwgYnV0IEkgY2FuJ3QgdGhpbmsgb2YgYW5vdGhlciB3YXkgYXJvdW5kIGl0IChi ZXNpZGVzIHVzaW5nIHJlZ3VsYXIgcHVzaGVzIGluc3RlYWQgb2YgVm9JUCBwdXNoZXMsIHdoaWNo IG1pZ2h0IGludHJvZHVjZSBkZWxheXMsIG9yIGhhdmluZyBhIHJlZ2lzdHJhdGlvbiB3aXRoIGlu ZmluaXRlIGV4cGlyYXRpb24gdGhhdCB3aWxsIG5vdCByZXF1aXJlIHJlZnJlc2hlcywgd2hpY2gg bWlnaHQgbGVhdmUgbWFueSB6b21ieSByZWdpc3RyYXRpb25zKS4NCg0KU2VlIHNvbWUgZGlzY3Vz c2lvbiBoZXJlOiBbMl0sIFszXS4NCg0KVGhhbmtzLA0KWWVob3NodWENCg0KWzFdIGh0dHBzOi8v ZGV2ZWxvcGVyLmFwcGxlLmNvbS9kb2N1bWVudGF0aW9uL3B1c2hraXQvcGtwdXNodHlwZS8xNjE0 NDgxLXZvaXANClsyXSBodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20vZm9ydW1zL3RocmVhZC8x MTc5MzkNClszXSBodHRwczovL3d3dy5saW5waG9uZS5vcmcvbmV3cy9pb3MtMTMtaW1wb3J0YW50 LWNoYW5nZXMtdm9pcGltLWFwcHM8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/ az0zYjQxZDYwNS02NWUxMzY5MS0zYjQxOTY5ZS04NmQyMTE0ZWFiMmYtYTcwYzFmZWJkYzY1NmIy MSZxPTEmZT01YjBlZTI1Mi02MmUzLTQxMTMtOTA3Mi1jNDY5NzQzMTkzNmMmdT1odHRwcyUzQSUy RiUyRnd3dy5saW5waG9uZS5vcmclMkZuZXdzJTJGaW9zLTEzLWltcG9ydGFudC1jaGFuZ2VzLXZv aXBpbS1hcHBzPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNv cmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCg== --_000_AM0PR07MB3860F48A7A45C799B59466B993070AM0PR07MB3860eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5BcyB5b3Ugc3VnZ2VzdCwgb25lIHNvbHV0aW9uIGlzIHRvIHVzZSBhIGRpZmZlcmVudCAo bm9uLVZvSVApIHB1c2ggbm90aWZpY2F0aW9uIGluIG9yZGVyIHRvIHRyaWdnZXIgcmUtcmVnaXN0 cmF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgb25seSBpc3N1ZSB3 aXRoIHRob3NlLCBBRkFJSywgaXMgdGhhdCB0aGVyZSBpcyBubyBndWFyYW50ZWUgd2hlbi9pZiB0 aGV5IHdpbGwgYWN0dWFsbHkgd2FrZSB1cCB0aGUgYXBwbGljYXRpb24uIEl0IGRlcGVuZHMgb24g YSBudW1iZXIgb2YgZmFjdG9ycywgZS5nLiwgZW5lcmd5IG1vZGUsIGhvdyBvZnRlbiB0aGUNCiBh cHAgaXMgdXNlZCwgZXRjIGV0Yy4gSG93ZXZlciwgSSBkb27igJl0IGhhdmUgYW55IGRhdGEgcmVn YXJkaW5nIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBzaXBjb3JlICZsdDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNpbW9uIE1PUkxBVDxicj4NCjxiPlNlbnQ6PC9iPiBzdW5u dW50YWkgMTEuIGxva2FrdXV0YSAyMDIwIDIzLjQzPGJyPg0KPGI+VG86PC9iPiBZZWhvc2h1YSBH ZXYgJmx0O3lvc2hpZ2V2QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNpcGNvcmUgJmx0 O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0g UHVzaCBub3RpZmljYXRpb25zIHdpdGggaU9TIDEzIChSRkMgODU5OSk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpJm5ic3A7WWVob3NodWEsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3Igc3RhcnRpbmcgdGhpcyBkaXNjdXNzaW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgY29t cGFueSBpcyBkZXZlbG9waW5nIHRoZSBMaW5waG9uZSBzb2Z0d2FyZSAoPGEgaHJlZj0iaHR0cHM6 Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az0xMGM4ZDA2ZS00ZTY4MzBmYS0xMGM4OTBm NS04NmQyMTE0ZWFiMmYtZDhjYWRiNTM4MzlmMWY5MSZhbXA7cT0xJmFtcDtlPTViMGVlMjUyLTYy ZTMtNDExMy05MDcyLWM0Njk3NDMxOTM2YyZhbXA7dT1odHRwcyUzQSUyRiUyRmxpbnBob25lLm9y ZyUyRiI+aHR0cHM6Ly9saW5waG9uZS5vcmc8L2E+KSwNCiBhbiBjcm9zcyBwbGF0Zm9ybSBvcGVu LXNvdXJjZSBTSVAgc29mdHBob25lIGFuZCBTREsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbGFzdCB2ZXJzaW9uIHdlIHB1Ymxpc2hlZCB3 YXMgZm9yIGFkZGluZyBjb21wYXRpYmlsaXR5IGZvciBpT1MgMTMuIEkgYWRtaXQgaXQgd2FzIGEg bmlnaHRtYXJlIHRvIGNvbXBseSB3aXRoIHRoZSBuZXcgcmVzdHJpY3Rpb25zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHB1c2ggbm90aWZp Y2F0aW9ucywgd2UgYmFzZWQgb3VyIHdvcmsgb24gUkZDIDg1OTkgLCBidXQgaW5kZWVkIHdlIGhh ZCB0byBzb21ld2hhdCBleHRlbmQgdGhlIFJGQyBpbiBvcmRlciB0byB0cmFuc21pdCAyIGRpZmZl cmVudCBwdXNoIG5vdGlmaWNhdGlvbiB0b2tlbnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHRoZSBvbmUgZm9yIGNhbGxzIChQdXNoS2l0IGtp bmQgb2Ygbm90aWZpY2F0aW9ucyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0gdGhlIG9uZSBmb3IgSU1zICh1c2luZyBSZW1vdGUgcHVzaCBub3Rp ZmljYXRpb24gc2VydmljZSkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uOiB0aGUgJnF1b3Q7 cmVtb3RlIHB1c2ggbm90aWZpY2F0aW9uJnF1b3Q7IHRva2VuIGNvdWxkIGFwcGFyZW50bHkgYWxz byBiZSB1c2VkIGZvciAmcXVvdDtCYWNrZ3JvdW5kIHB1c2ggbm90aWZpY2F0aW9ucyZxdW90OyAo PGEgaHJlZj0iaHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRpb24vdXNlcm5v dGlmaWNhdGlvbnMvc2V0dGluZ191cF9hX3JlbW90ZV9ub3RpZmljYXRpb25fc2VydmVyL3B1c2hp bmdfYmFja2dyb3VuZF91cGRhdGVzX3RvX3lvdXJfYXBwP2xhbmd1YWdlPW9iamMiPmh0dHBzOi8v ZGV2ZWxvcGVyLmFwcGxlLmNvbS9kb2N1bWVudGF0aW9uL3VzZXJub3RpZmljYXRpb25zL3NldHRp bmdfdXBfYV9yZW1vdGVfbm90aWZpY2F0aW9uX3NlcnZlci9wdXNoaW5nX2JhY2tncm91bmRfdXBk YXRlc190b195b3VyX2FwcD9sYW5ndWFnZT1vYmpjPC9hPg0KICksIHdoaWNoIGFyZSB0aGUgcHVz aCBub3RpZmljYXRpb25zIHdlIG5lZWQgdG8gcmVmcmVzaCBhIFJFR0lTVEVSIHRoYXQgaXMgYWJv dXQgdG8gZXhwaXJlIChvciBleHBpcmVkKS4gU28geWVzIHlvdSBuZWVkIHR3byBkaWZmZXJlbnQg cHVzaCBzZXJ2aWNlcyBhbmQgdG9rZW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBvZiB0b2RheSwgdGhlIExpbnBob25lIGFwcCBkb2Vz bid0IHVzZSBwdXNoIG5vdGlmaWNhdGlvbnMgZm9yIHRyaWdnZXJpbmcgUkVHSVNURVIgcmVmcmVz aGVzOiB3ZSB1c2UgYSB2ZXJ5IGxvbmcgZXhwaXJlIHRpbWUgKG9uZSB5ZWFyKSBpbnN0ZWFkLiBI b3dldmVyIHdlIHdvdWxkIHByZWZlciB0byBzd2l0Y2ggdG8gcHVzaC10cmlnZ2VyZWQgUkVHSVNU RVIgcmVmcmVzaCBhcyBzb29uIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3ludGF4IGV4dGVuc2lvbiB3ZSBtYWRl IHRvIFJGQzg1OTkgaXMgZGVzY3JpYmVkIGluIG91ciB3aWtpOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3YxL3VybD9rPWFkOWIzMzVlLWYzM2JkM2NhLWFkOWI3M2M1LTg2ZDIx MTRlYWIyZi04MWUwOTQ1ZjFjNzg2MWVjJmFtcDtxPTEmYW1wO2U9NWIwZWUyNTItNjJlMy00MTEz LTkwNzItYzQ2OTc0MzE5MzZjJmFtcDt1PWh0dHBzJTNBJTJGJTJGd2lraS5saW5waG9uZS5vcmcl MkZ4d2lraSUyRndpa2klMkZwdWJsaWMlMkZ2aWV3JTJGTGliJTJGR2V0dGluZyUyNTIwc3RhcnRl ZCUyRmlPUyUyRiUyM0hVcGRhdGVDb250YWN0VVJJcGFyYW1ldGVycyI+aHR0cHM6Ly93aWtpLmxp bnBob25lLm9yZy94d2lraS93aWtpL3B1YmxpYy92aWV3L0xpYi9HZXR0aW5nJTIwc3RhcnRlZC9p T1MvI0hVcGRhdGVDb250YWN0VVJJcGFyYW1ldGVyczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgZGVzaWduZWQgdGhpcyBzeW50YXgg dG8gYmUgY29tcGF0aWJsZSB3aXRoIFJGQzg1OTkgc3ludGF4LiBUbyBzdW1tYXJpemUsIGhlcmUg aXMgYSBxdWljayBleGFtcGxlIHRvIHVuZGVyc3RhbmQgaG93IHdlIGNvbnZleSBwdXNoIHRva2Vu cyBmb3IgYW4gYXBwIHRoYXQgbmVlZHMgdG8gYWR2ZXJ0aXNlIGNhbGxzIGFuZCBJTXM6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPnBuLXByaWQ9MDBmYzEzYWRmZjc4NTEyOnZvaXAmYW1w O2MxMTI5MmY3Yjc0NzMzZDpyZW1vdGU7cG4tcGFyYW09REVGMTIzR0hJSi5vcmcubGlucGhvbmUu cGhvbmUudm9pcCZhbXA7cmVtb3RlO3BuLXByb3ZpZGVyPWFwbnM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMzMzMzMzMiPk5vdGljZSB0aGUgJnF1b3Q7OnZvaXAmcXVvdDsgYW5kICZxdW90 OzpyZW1vdGUmcXVvdDsgdG9rZW4gc3VmZml4ZXMsIGFuZCB0aGUgJnF1b3Q7JmFtcDsmcXVvdDsu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+V2UgZGVjaWRlZCBub3QgdG8gZ28g d2l0aCBhIG11bHRpcGxlIGNvbnRhY3QgaGVhZGVycyBhcHByb2FjaCwgZWFjaCBjb250YWN0IHVy aSBiZWFyaW5nIGEgcG4tcHJpZCBmb3IgZWl0aGVyIHZvaXAgb3IgcmVtb3RlIHNlcnZpY2U6IHRo ZSBmb3JraW5nIGJ5IGEgcHJveHkNCiB0aGF0IGlzIHVuYXdhcmUgb2YgcHVzaCBub3RpZmljYXRp b25zIGNvdWxkIHJlc3VsdCBpbiBJTlZJVEVzIHRvIGJlIGR1cGxpY2F0ZWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5XZSBoYWQgdG8gZ28gZmFzdCBvdGhlcndpc2Ugb3Vy IGFwcCB3b3VsZCBzdG9wIHdvcmtpbmcsIGJ1dCBmcm9tJm5ic3A7dGhlIGJlZ2lubmluZyB3ZSBo YXZlIGluIG1pbmQgdGhhdCB0aGlzIGlzc3VlIHNob3VsZCBiZSByYWlzZWQgYW5kIGhvcGVmdWxs eSByZXNvbHZlZCBoZXJlDQogYXQgSUVURiwgd2l0aCBvciB3aXRob3V0IG91ciBwcm9wb3NlZCBz eW50YXggZXh0ZW5zaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ub2RheSBkdWUgdG8gQXBwbGUncyByZWNlbnQgY2hhbmdlcywgaXQgbG9v a3MgbGlrZSBSRkM4NTk5IGNhbm5vdCBiZSB1c2VkICZxdW90O2FzIGlzJnF1b3Q7IHRvIG1ha2Ug YSBTSVAgYXBwIGZvciBpT1MuIFRoZSByaXNrIHRoYXQgR29vZ2xlIGRvZXMgdGhlIHNhbWUgaW4g bmVhciBmdXR1cmUgZXhpc3RzLjxicj4NCkFyZSB0aGVyZSBwZW9wbGUgaW50ZXJlc3RlZCBoZXJl IGluIGNvbGxhYm9yYXRpbmcgdG8gYW4gUkZDODU5OSB1cGRhdGUgdG8gYWRkcmVzcyB0aGlzIGlP UyBwbGF0Zm9ybSBldm9sdXRpb24gPyBJbiBvdGhlciB3b3Jkcywgd2UgbmVlZCB0byBzb2x2ZSBo b3cgdG8gY29udmV5IG11bHRpcGxlIHBuLXByaWQgYW5kIHBuLXBhcmFtIGZvciBhIHNhbWUgdXNl ci1hZ2VudCBpbnN0YW5jZS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KPGJyPg0KU2lt b248bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUmbmJzcDtkaW0uIDExIG9jdC4g MjAyMCDDoCZuYnNwOzE3OjA3LCBZZWhvc2h1YSBHZXYgJmx0OzxhIGhyZWY9Im1haWx0bzp5b3No aWdldkBnbWFpbC5jb20iPnlvc2hpZ2V2QGdtYWlsLmNvbTwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7 OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgaG9wZSBpdCBpcyBvayB0byZuYnNwO3Bvc3QgdGhpcyBoZXJlIGFuZCBub3Qgb24g c2lwLWltcGxlbWVudG9ycy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgdHJ5aW5nIHRvIGltcGxlbWVudCBSRkMgODU5OSBmb3Ig cGVyZm9ybWluZyBwdXNoIG5vdGlmaWNhdGlvbnMgZm9yIEFwcGxlIGRldmljZXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0YXJ0aW5nIHdp dGggaU9TIDEzLCB0aGVyZSBpcyBhIHJlc3RyaWN0aW9uJm5ic3A7b24gVm9JUCBwdXNoZXMgWzFd OiAmcXVvdDtBcHBzIHJlY2VpdmluZyBWb0lQIHB1c2ggbm90aWZpY2F0aW9ucw0KPHU+bXVzdCBy ZXBvcnQgdGhlIGNhbGwgcXVpY2tseSB0byBDYWxsS2l0LCBzbyBpdCBjYW4gYWxlcnQgdGhlIHVz ZXI8L3U+IHRvIHRoZSBwcmVzZW5jZSBvZiB0aGUgaW5jb21pbmcgY2FsbC4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWNjb3JkaW5n IHRvIFJGQyA4NTk5LCBwdXNoZXMgYXJlIHVzZWQgZm9yIChhdCBsZWFzdCkgdHdvIGRpZmZlcmVu dCZuYnNwO2dvYWxzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7IDEpIEluaXRpYXRpbmcgcmVnaXN0cmF0aW9uIHJlZnJlc2hlcyAoc2Vj dGlvbiA1LjUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgMikgTm90aWZ5aW5nIG9mIGluY29taW5nIGNhbGxzIChzZWN0aW9uIDUuNi4y KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O b3csIGZvciBhIHJlYXNvbmFibGUmbmJzcDt1c2VyIGV4cGVyaWVuY2UsIHRoZSByZWdpc3RyYXRp b24gcmVmcmVzaCBwdXNoZXMgbXVzdCBub3QgdHJpZ2dlciB0aGUgVUkgb2YgaW5jb21pbmcgY2Fs bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhv d2V2ZXIsIHdoZW4gYW4gSU5WSVRFIGlzIHJlY2VpdmVkLCB0aGUgVUEgbXVzdCBiZSBhd29rZW4g aW1tZWRpYXRlbHksIHdoaWNoIGlzIHRoZSBwdXJwb3NlJm5ic3A7b2YgVm9JUCBwdXNoLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIGl0 IG1ha2Ugc2Vuc2UgdG8gbWFrZSBhIGRpZmZlcmVudCBwdXNoIHR5cGUgZm9yIHJlZ2lzdHJhdGlv biByZWZyZXNoIGFuZCBmb3IgaW5jb21pbmcgY2FsbHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3Qgc3VyZSB0aGlzIGlzIHBvc3Np YmxlIHdpdGggdGhlIGN1cnJlbnQgUkZDIChhbmQgaXQgaXMgYWxzbyBhZ2FpbnN0IHRoZSBzcGly aXQgb2YgdGhlIFJGQyksIGJ1dCBJIGNhbid0IHRoaW5rIG9mIGFub3RoZXIgd2F5IGFyb3VuZCBp dCAoYmVzaWRlcyB1c2luZyByZWd1bGFyIHB1c2hlcyBpbnN0ZWFkIG9mIFZvSVAgcHVzaGVzLCB3 aGljaCBtaWdodCBpbnRyb2R1Y2UgZGVsYXlzLCBvciBoYXZpbmcNCiBhIHJlZ2lzdHJhdGlvbiB3 aXRoIGluZmluaXRlIGV4cGlyYXRpb24gdGhhdCZuYnNwO3dpbGwgbm90IHJlcXVpcmUgcmVmcmVz aGVzLCB3aGljaCBtaWdodCBsZWF2ZSBtYW55IHpvbWJ5IHJlZ2lzdHJhdGlvbnMpLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgc29tZSBk aXNjdXNzaW9uIGhlcmU6IFsyXSwgWzNdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWhvc2h1YTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJzcDs8YSBocmVmPSJodHRwczov L2RldmVsb3Blci5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi9wdXNoa2l0L3BrcHVzaHR5cGUvMTYx NDQ4MS12b2lwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2Rv Y3VtZW50YXRpb24vcHVzaGtpdC9wa3B1c2h0eXBlLzE2MTQ0ODEtdm9pcDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsyXSZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9mb3J1bXMvdGhyZWFkLzExNzkzOSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9mb3J1bXMvdGhyZWFkLzEx NzkzOTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlszXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJs P2s9M2I0MWQ2MDUtNjVlMTM2OTEtM2I0MTk2OWUtODZkMjExNGVhYjJmLWE3MGMxZmViZGM2NTZi MjEmYW1wO3E9MSZhbXA7ZT01YjBlZTI1Mi02MmUzLTQxMTMtOTA3Mi1jNDY5NzQzMTkzNmMmYW1w O3U9aHR0cHMlM0ElMkYlMkZ3d3cubGlucGhvbmUub3JnJTJGbmV3cyUyRmlvcy0xMy1pbXBvcnRh bnQtY2hhbmdlcy12b2lwaW0tYXBwcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmxpbnBo b25lLm9yZy9uZXdzL2lvcy0xMy1pbXBvcnRhbnQtY2hhbmdlcy12b2lwaW0tYXBwczwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM0PR07MB3860F48A7A45C799B59466B993070AM0PR07MB3860eurp_-- From nobody Tue Oct 13 03:18:03 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B7E3A0F11 for ; Tue, 13 Oct 2020 03:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=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 0DGILdtlqFMr for ; Tue, 13 Oct 2020 03:18:00 -0700 (PDT) Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (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 DA1623A0F0F for ; Tue, 13 Oct 2020 03:17:59 -0700 (PDT) Received: by mail-vs1-xe42.google.com with SMTP id d4so5127922vsk.13 for ; Tue, 13 Oct 2020 03:17:59 -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 :cc; bh=bzCW99wHS6OBxuoTRb30zcwJ8wS2fr1E3AlmaN+4j7g=; b=L0X0DVRXT3OIRgh1q5E0itbshA/KFI8tJ6acNcfQEO9g5SVfWqu7Ieaf75k00HAvgV a82wbc53/jcnVZEKLb/CMAfa3tW3/NLC7bps5bIWngJW1Co+sDkHq76yeB+Icer7Mx0v yBG1nGJ78awdA9hSxj3DXI6xko2vRFycmmEvwhyeYFGfhXJy3XewRKXF0WTV0WZN4Xwh Qjyu66OvBXYPaVBfsjmUw3nRnQQFS2eHb047sJQpwRnuuB7WNkgYelUN5qN5OqmVB9jx h3S7TwBCLyMtsybHhdruZ3CElp2MRE1/96JRVVpbGJ2aJKdJM2VOaI/cq8IYH2YmgGgJ 0fcg== 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=bzCW99wHS6OBxuoTRb30zcwJ8wS2fr1E3AlmaN+4j7g=; b=JTtkCEhuDU/JQqyYDMHrGM0pVuaummMRa8B0bsCEYgzipMOgpK0rY19OAYl5AICWf/ lnteao82sca4QAt4hd1psbaSF8x1YUy4XNAxQ5j1DRFIYxt3K/Vdh4cMC+OoSTAJjdUN ckrQ//W5v1DzS8N1BamAtkI1j0be7yXtHP8gwvz2hWu4b7JAsvaQVkAY5RiEjbpbXCeL TJ6eCviGkBuBnuNzN2wPDPaW5DhbCUNvg5ooqsMT7rSOaB295H8YqufAV3SydTtslm4i NFDrRgIhaqe/ryx8mllLkBedspQ9bKB9DWQHhXSVfIk4qcpY4RWfi+nwqqh8+D1innOx CM2A== X-Gm-Message-State: AOAM530YwyujYlyLqRUDC5qPbwTW7Z8E5/8InKPy4++IUyKKJbWZWKVJ wNMdDgj+qbecDrzP2dikb2La3OqTPQC0dHoRXJ4= X-Google-Smtp-Source: ABdhPJzScBcMBaOeaaPYZc9ddL2q2UqDD6hlzhJTmC8gYK8Kk73wHC08yIpA88R0Bv7Ap0D84q81qQnnUWcXymTD9YI= X-Received: by 2002:a05:6102:5d:: with SMTP id k29mr15603651vsp.17.1602584278754; Tue, 13 Oct 2020 03:17:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yehoshua Gev Date: Tue, 13 Oct 2020 13:17:47 +0300 Message-ID: To: Christer Holmberg Cc: Simon MORLAT , sipcore Content-Type: multipart/alternative; boundary="000000000000a867bf05b18aba4f" Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 10:18:02 -0000 --000000000000a867bf05b18aba4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For triggering discussion (not rejecting Simon's proposal), I've thought of another way for passing several "pn-*"-groups. Let's start with an example of the contact header URI parameters: pn-prid[call]=3D00fc13adff78512; pn-param[call]=3DDEF123GHIJ.org.linphone.phone.voip; pn-provider[call]=3Dapns; pn-methods[call]=3DINVITE; pn-prid[im]=3Dc11292f7b74733d; pn-param[im]=3DDEF123GHIJ.org.linphone.phone.remote; pn-provider[im]=3Dapns; pn-methods[im]=3DMESSAGE This is of course not compatible with RFC 8599, as it uses other (non-constant) parameter names. The idea is grouping the parameters according to user-defined strings, given in brackets. The Proxy will choose the correct group by matching the request method that triggers the push notification to the pn-methods parameter. I also suggest that for push notification that is used for triggering registration refresh, the method REGISTER will be used (although it is not really an incoming REGISTER request). I've not yet seen a usage of non-constant parameter names in SIP URI, so I would like to know if someone has any saying about it :-) This syntax doesn't contradict the SIP URI ABNF of RFC 3261, but seems to work against the notion of IANA registration of URI parameters by name (RFC 3969)... Another way is numbering the parameters with a sequence number (like done for "param" parameter in RFC 4240): pn-prid-1=3D00fc13adff78512; pn-param-1=3DDEF123GHIJ.org.linphone.phone.voip; pn-provider-1=3Dapns; pn-methods-1=3DINVITE; pn-prid-2=3Dc11292f7b74733d; pn-param-2=3DDEF123GHIJ.org.linphone.phone.remote; pn-provider-2=3Dapns; pn-methods-2=3DMESSAGE I think this is less intuitive, but better conforms to the current practices of URI parameters (and maybe also be easier to implement on the Proxy side). Best, Yehoshua On Mon, Oct 12, 2020 at 5:55 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > As you suggest, one solution is to use a different (non-VoIP) push > notification in order to trigger re-registrations. > > > > The only issue with those, AFAIK, is that there is no guarantee when/if > they will actually wake up the application. It depends on a number of > factors, e.g., energy mode, how often the app is used, etc etc. However, = I > don=E2=80=99t have any data regarding that. > > > > Regards, > > > > Christer > > > > *From:* sipcore *On Behalf Of *Simon MORLAT > *Sent:* sunnuntai 11. lokakuuta 2020 23.43 > *To:* Yehoshua Gev > *Cc:* sipcore > *Subject:* Re: [sipcore] Push notifications with iOS 13 (RFC 8599) > > > > Hi Yehoshua, > > > > Thank you for starting this discussion. > > My company is developing the Linphone software (https://linphone.org > ), > an cross platform open-source SIP softphone and SDK. > > The last version we published was for adding compatibility for iOS 13. I > admit it was a nightmare to comply with the new restrictions. > > For push notifications, we based our work on RFC 8599 , but indeed we had > to somewhat extend the RFC in order to transmit 2 different push > notification tokens: > > - the one for calls (PushKit kind of notifications) > > - the one for IMs (using Remote push notification service). > > > > To answer your question: the "remote push notification" token could > apparently also be used for "Background push notifications" ( > https://developer.apple.com/documentation/usernotifications/setting_up_a_= remote_notification_server/pushing_background_updates_to_your_app?language= =3Dobjc > ), which are the push notifications we need to refresh a REGISTER that is > about to expire (or expired). So yes you need two different push services > and tokens. > > > > As of today, the Linphone app doesn't use push notifications for > triggering REGISTER refreshes: we use a very long expire time (one year) > instead. However we would prefer to switch to push-triggered REGISTER > refresh as soon as possible. > > > > The syntax extension we made to RFC8599 is described in our wiki: > > > > > https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/iO= S/#HUpdateContactURIparameters > > > > > We designed this syntax to be compatible with RFC8599 syntax. To > summarize, here is a quick example to understand how we convey push token= s > for an app that needs to advertise calls and IMs: > > > > > pn-prid=3D00fc13adff78512:voip&c11292f7b74733d:remote;pn-param=3DDEF123GH= IJ.org.linphone.phone.voip&remote;pn-provider=3Dapns > > > > Notice the ":voip" and ":remote" token suffixes, and the "&". > > We decided not to go with a multiple contact headers approach, each > contact uri bearing a pn-prid for either voip or remote service: the > forking by a proxy that is unaware of push notifications could result in > INVITEs to be duplicated. > > > > We had to go fast otherwise our app would stop working, but from the > beginning we have in mind that this issue should be raised and hopefully > resolved here at IETF, with or without our proposed syntax extension. > > > > Today due to Apple's recent changes, it looks like RFC8599 cannot be used > "as is" to make a SIP app for iOS. The risk that Google does the same in > near future exists. > Are there people interested here in collaborating to an RFC8599 update to > address this iOS platform evolution ? In other words, we need to solve ho= w > to convey multiple pn-prid and pn-param for a same user-agent instance. > > Best regards, > > Simon > > > > > > > > > > > > > > > > Le dim. 11 oct. 2020 =C3=A0 17:07, Yehoshua Gev a = =C3=A9crit : > > Hi All, > > > > I hope it is ok to post this here and not on sip-implementors... > > > > We are trying to implement RFC 8599 for performing push notifications for > Apple devices. > > > > Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps > receiving VoIP push notifications *must report the call quickly to > CallKit, so it can alert the user* to the presence of the incoming call." > > > > According to RFC 8599, pushes are used for (at least) two different goals= : > > 1) Initiating registration refreshes (section 5.5) > > 2) Notifying of incoming calls (section 5.6.2) > > > > Now, for a reasonable user experience, the registration refresh pushes > must not trigger the UI of incoming call. > > However, when an INVITE is received, the UA must be awoken immediately, > which is the purpose of VoIP push. > > > > Does it make sense to make a different push type for registration refresh > and for incoming calls? > > > > I'm not sure this is possible with the current RFC (and it is also agains= t > the spirit of the RFC), but I can't think of another way around it (besid= es > using regular pushes instead of VoIP pushes, which might introduce delays= , > or having a registration with infinite expiration that will not require > refreshes, which might leave many zomby registrations). > > > > See some discussion here: [2], [3]. > > > > Thanks, > > Yehoshua > > > > [1] > https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-voip > > [2] https://developer.apple.com/forums/thread/117939 > > [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --000000000000a867bf05b18aba4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For triggering discussion (not rejecting Simon's propo= sal), I've thought of another way for passing several "pn-*"-= groups.
Let's start with an example of the contact header URI param= eters:
=C2=A0 =C2=A0 pn-prid[call]=3D00fc13adff78512;
=C2=A0 = =C2=A0 pn-param[call]=3DDEF123GHIJ.org.linphone.phone.voip;
=C2=A0 =C2= =A0 pn-provider[call]=3Dapns;
=C2=A0 =C2=A0 pn-methods[call]=3DINVITE;=C2=A0 =C2=A0 pn-prid[im]=3Dc11292f7b74733d;
=C2=A0 =C2=A0 pn-param[im= ]=3DDEF123GHIJ.org.linphone.phone.remote;
=C2=A0 =C2=A0 pn-provider[im]= =3Dapns;
=C2=A0 =C2=A0 pn-methods[im]=3DMESSAGE

=
This is of course not compatible with RFC 8599, as it uses other (non-= constant) parameter=C2=A0names.
The idea is grouping the paramete= rs according to user-defined strings, given in brackets.
The Prox= y will choose the correct group by matching the request method=C2=A0that tr= iggers the push notification to the pn-methods parameter.
I also = suggest that for push notification that is used for triggering registration= =C2=A0refresh, the method REGISTER will be used (although it is not really = an incoming REGISTER request).

I've not yet=C2= =A0seen a usage of non-constant parameter names in SIP URI, so I would like= to know if someone has any saying about it :-)
This syntax doesn= 't contradict the SIP URI ABNF of RFC 3261, but seems to work against t= he notion of IANA registration of URI parameters by name (RFC 3969)...

Another way is numbering the parameters with a sequenc= e number (like done for "param" parameter in RFC=C2=A04240):
=C2=A0 =C2=A0 pn-prid-1=3D00fc13adff78512;
=C2=A0 =C2=A0 pn-param-= 1=3DDEF123GHIJ.org.linphone.phone.voip;
=C2=A0 =C2=A0 pn-provider-1=3Dap= ns;
=C2=A0 =C2=A0 pn-methods-1=3DINVITE;
=C2=A0 =C2=A0 pn-prid-2=3Dc1= 1292f7b74733d;
=C2=A0 =C2=A0 pn-param-2=3DDEF123GHIJ.org.linphone.phone.= remote;
=C2=A0 =C2=A0 pn-provider-2=3Dapns;
=C2=A0 =C2=A0 pn-methods-= 2=3DMESSAGE

I think this is less intuitive, bu= t better conforms to the current practices of URI parameters (and maybe als= o be easier to implement on=C2=A0the Proxy side).

= Best,
Yehoshua



=


On Mon, Oct 12, 2020 at 5:55 PM Christer Holmberg <christer.holmberg@ericsson.com= > wrote:

Hi,

=C2=A0

As you suggest, one solution is= to use a different (non-VoIP) push notification in order to trigger re-reg= istrations.

=C2=A0

The only issue with those, AFAI= K, is that there is no guarantee when/if they will actually wake up the app= lication. It depends on a number of factors, e.g., energy mode, how often t= he app is used, etc etc. However, I don=E2=80=99t have any data regarding tha= t.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: sipcore <sipcore-bounces@ietf.org> On Behalf Of Simon MORLAT
Sent: sunnuntai 11. lokakuuta 2020 23.43
To: Yehoshua Gev <yoshigev@gmail.com>
Cc: sipcore <sipcore@ietf.org>
Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599)<= /u>

=C2=A0

Hi=C2=A0Yehoshua,

=C2=A0

Thank you for starting this discussion.

My company is developing the Linphone software (https://l= inphone.org), an cross platform open-source SIP softphone and SDK.

The last version we published was for adding compati= bility for iOS 13. I admit it was a nightmare to comply with the new restri= ctions.

For push notifications, we based our work on RFC 859= 9 , but indeed we had to somewhat extend the RFC in order to transmit 2 dif= ferent push notification tokens:

- the one for calls (PushKit kind of notifications)<= u>

- the one for IMs (using Remote push notification se= rvice).=C2=A0

=C2=A0

To answer your question: the "remote push notif= ication" token could apparently also be used for "Background push= notifications" (https://developer.= apple.com/documentation/usernotifications/setting_up_a_remote_notification_= server/pushing_background_updates_to_your_app?language=3Dobjc ), which are the push notifications we need to refresh a REGISTER that is = about to expire (or expired). So yes you need two different push services a= nd tokens.

=C2=A0

As of today, the Linphone app doesn't use push n= otifications for triggering REGISTER refreshes: we use a very long expire t= ime (one year) instead. However we would prefer to switch to push-triggered= REGISTER refresh as soon as possible.

=C2=A0

The syntax extension we made to RFC8599 is described= in our wiki:

=C2=A0

=C2=A0

We designed this syntax to be compatible with RFC859= 9 syntax. To summarize, here is a quick example to understand how we convey= push tokens for an app that needs to advertise calls and IMs:

=C2=A0

pn-prid=3D00fc13adff78512:voip&c11292= f7b74733d:remote;pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;p= n-provider=3Dapns

=C2=A0

Notice the ":voip" and ":r= emote" token suffixes, and the "&".=

We decided not to go with a multiple cont= act headers approach, each contact uri bearing a pn-prid for either voip or= remote service: the forking by a proxy that is unaware of push notifications could result in INVITEs to be duplic= ated.

=C2=A0

We had to go fast otherwise our app would= stop working, but from=C2=A0the beginning we have in mind that this issue = should be raised and hopefully resolved here at IETF, with or without our proposed syntax extension.

=C2=A0

Today due to Apple's recent changes, it looks li= ke RFC8599 cannot be used "as is" to make a SIP app for iOS. The = risk that Google does the same in near future exists.
Are there people interested here in collaborating to an RFC8599 update to a= ddress this iOS platform evolution ? In other words, we need to solve how t= o convey multiple pn-prid and pn-param for a same user-agent instance.

Best regards,

Simon

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Le=C2=A0dim. 11 oct. 2020 =C3=A0=C2=A017:07, Yehoshu= a Gev <yoshigev@= gmail.com> a =C3=A9crit=C2=A0:

Hi All,

=C2=A0

I hope it is ok to=C2=A0post this here and not on si= p-implementors...

=C2=A0

We are trying to implement RFC 8599 for performing p= ush notifications for Apple devices.

=C2=A0

Starting with iOS 13, there is a restriction=C2=A0on= VoIP pushes [1]: "Apps receiving VoIP push notifications must report the call quickly to CallKit, so it can alert the user to= the presence of the incoming call."

=C2=A0

According to RFC 8599, pushes are used for (at least= ) two different=C2=A0goals:

=C2=A0 1) Initiating registration refreshes (section= 5.5)

=C2=A0 2) Notifying of incoming calls (section 5.6.2= )

=C2=A0

Now, for a reasonable=C2=A0user experience, the regi= stration refresh pushes must not trigger the UI of incoming call.=

However, when an INVITE is received, the UA must be = awoken immediately, which is the purpose=C2=A0of VoIP push.

=C2=A0

Does it make sense to make a different push type for= registration refresh and for incoming calls?

=C2=A0

I'm not sure this is possible with the current R= FC (and it is also against the spirit of the RFC), but I can't think of= another way around it (besides using regular pushes instead of VoIP pushes= , which might introduce delays, or having a registration with infinite expiration that=C2=A0will not require refresh= es, which might leave many zomby registrations).

=C2=A0

See some discussion here: [2], [3].

=C2=A0

Thanks,

Yehoshua

=C2=A0

=C2=A0

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

--000000000000a867bf05b18aba4f-- From nobody Sat Oct 17 01:44:10 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841013A08C7 for ; Sat, 17 Oct 2020 01:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 T7dzFhNTriZw for ; Sat, 17 Oct 2020 01:44:03 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::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 3CEA43A08C5 for ; Sat, 17 Oct 2020 01:44:03 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id c13so5379955oiy.6 for ; Sat, 17 Oct 2020 01:44:03 -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 :cc; bh=/YJoqFHSEQVtfuL8XeNEjF/pXsnXBu7l2sPYNrH95Lo=; b=Rmg+9gSniG1W/hWxwHCwbF4kUI6LYmwEpufjijMoaSQAL/w3wKOJclHTIMykWEWEIt VjQe0IGPsDagt3pyRcdt4jIFNgQ6kQbFDMNbpVZy7w59X3jhDsNOQRkYICiuDxx5ICpq 6/gPElctsrmJQ5na/64dCVkSzjZTWjnozOWNMcPIncthv2VH3WjH/lrDRbkMTo+wDzdJ Tb44SRw5w6Yw6CQp4o51pz1KAZJ+iaXdHDE4UIPAhJ0WKJX5nbGTupLUirR8poRljxi9 d+EfA42npGXB8JOmivrOK7By65hxL/Ahu6OvVV426+Ds7ZaOnR0x8W1I0mKtU1siJcr4 pSzA== 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=/YJoqFHSEQVtfuL8XeNEjF/pXsnXBu7l2sPYNrH95Lo=; b=rHnzBQN2cGotmr/TDl18stjkkf+wdXx191tjXaP1zdWiSvMxT8vBI+jeS8z3CJK+cE R3o5S4JTavWIVRuyhpYJtkS9DkQbsIY+7jyB4tcnVIEje6BPoWlSrCo6pWr9RooT2zsV ngqI8Ch1tLDoq4Vz9AwbIPhP0rINWbGCx4x/TJIjRPPQEeplvu3e0aqjnXtD78yJ2TSl vWXTsUOFcFgykDrndX1bfcKi5ymcbFgKaK1tHwmwcYFG7lY5hhyaEPfCyX5P+KwCVoA3 nvCcOxuMXQvOeE/AFUMrOV9Hv8X6VgZLp3PGIvaYIb/9xTZPWUn4DvG6MgcIfWsTiwdf m1Wg== X-Gm-Message-State: AOAM531S/srzJleyWxT5NC6rcEabkW18It63qgbM5Slpb01mmNRFH7rZ vqhd9d2u6//v1g1UjjGBHxdd9wVS+5PNysvFB4o= X-Google-Smtp-Source: ABdhPJwCM7MGKSgzLAP/D9YpqaVaMEyQpwxxAh1LGIQlTglMafA4gWKop1PWi9Dxucr1X69XUAPyjNcJYSwuCmbXkIg= X-Received: by 2002:aca:5652:: with SMTP id k79mr5219690oib.76.1602924242330; Sat, 17 Oct 2020 01:44:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon MORLAT Date: Sat, 17 Oct 2020 10:43:40 +0200 Message-ID: To: Yehoshua Gev Cc: sipcore Content-Type: multipart/alternative; boundary="00000000000010e86605b1d9e2a1" Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 08:44:09 -0000 --00000000000010e86605b1d9e2a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yehoshua, Let me answer your questions. * The pn-param is used by the proxy to know the application ID, which is necessary to know which credentials or TLS client certificate to connect to the Apple push server. The voip&remote advertise that the app understands both voip and remote push notifications, and as such two certificates/credentials should be available to the server for this. 1. Yes. I saw your other suggestion, which is indeed more readable, but breaks compatibility with RFC8599 . 2. The proxy has forcibly some platform specific logic to handle push notifications. It cannot be unaware that for Apple platform, the "voip" type must only be used for calls. Note that it is not a question of SIP method, because SIP INVITE can be used to establish chat sessions with MSRP protocol for example, and in this case a "voip" type notification must not be used. 3. It could indeed, however it discloses information to push notification servers. In linphone, we do not pass it for this reason. Instead, the CallKit view is subsequently updated to display the caller-id once the INVITE has arrived (which usually takes no more than a few seconds). The background updates push notifications ( https://developer.apple.com/documentation/usernotifications/setting_up_a_re= mote_notification_server/pushing_background_updates_to_your_app?language=3D= objc) are reliable. They are indeed rate limited (3 per hour) which makes them unsuitable to advertise calls or incoming messages. But in order to trigger a REGISTER request it's good enough, and they do not require to show something to the user: the work silently. To make the system reliable, I imagine the registrar could send a background push notification at 80 % of expire time, and then once a day during a guard period of XX days in order to give additional chances for apps that temporarily have no longer access to the network to finally refresh their registration. Best regards, Simon Le lun. 12 oct. 2020 =C3=A0 16:40, Yehoshua Gev a =C3= =A9crit : > Hi Simon, > > Thanks for your detailed explanation of the behavior you have implemented= . > > One Q: How is the "pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote" > used? > Does the server really make use of the "&remote" suffix or it can be used > like "DEF123GHIJ.org.linphone.phone.*" with the "*" being always replaced > with the service? > > In any case, I'm willing to help with work on a new RFC, but sadly I don'= t > have much time for it. > > Regarding the scope of the updated RFC, I think there are several issues > that should be addressed: > > 1. How the UA passes several "pn-*"-sets for a single registration. The > solution you've done on Linphone seems like a good approach if backward > compatibility with RFC 8599 is required. > > 2. How would the proxy decide which pn-*-values-set to use for a specific > push notification? For example, a naive approach is to pre-define a mappi= ng > between "pr-*"-set and SIP methods (i.e., INVITE will use a "voip" params= ). > > 3. (maybe unrelated) For good user experience, the caller-id should be > passed along with the voip push notification so the UI of incoming calls > can display it immediately. > > BTW, regarding triggering of registration refreshes, our iOS developers > say that in order for a push notification to work reliably (i.e., assured > to be processed by the application even if it is terminated), it must hav= e > some UI notification. This means that the user will be informed of each > registration refresh. If this is true, then the expiry time must be kept > very long (weeks/months) in any case. Is this also your understanding? > > > Yehoshua > > > On Sun, Oct 11, 2020 at 11:43 PM Simon MORLAT > wrote: > >> Hi Yehoshua, >> >> Thank you for starting this discussion. >> My company is developing the Linphone software (https://linphone.org), >> an cross platform open-source SIP softphone and SDK. >> The last version we published was for adding compatibility for iOS 13. I >> admit it was a nightmare to comply with the new restrictions. >> For push notifications, we based our work on RFC 8599 , but indeed we ha= d >> to somewhat extend the RFC in order to transmit 2 different push >> notification tokens: >> - the one for calls (PushKit kind of notifications) >> - the one for IMs (using Remote push notification service). >> >> To answer your question: the "remote push notification" token could >> apparently also be used for "Background push notifications" ( >> https://developer.apple.com/documentation/usernotifications/setting_up_a= _remote_notification_server/pushing_background_updates_to_your_app?language= =3Dobjc >> ), which are the push notifications we need to refresh a REGISTER that i= s >> about to expire (or expired). So yes you need two different push service= s >> and tokens. >> >> As of today, the Linphone app doesn't use push notifications for >> triggering REGISTER refreshes: we use a very long expire time (one year) >> instead. However we would prefer to switch to push-triggered REGISTER >> refresh as soon as possible. >> >> The syntax extension we made to RFC8599 is described in our wiki: >> >> >> https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/i= OS/#HUpdateContactURIparameters >> >> We designed this syntax to be compatible with RFC8599 syntax. To >> summarize, here is a quick example to understand how we convey push toke= ns >> for an app that needs to advertise calls and IMs: >> >> pn-prid=3D00fc13adff78512:voip&c11292f7b74733d:remote; >> pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;pn-provider=3Dapns >> >> Notice the ":voip" and ":remote" token suffixes, and the "&". >> We decided not to go with a multiple contact headers approach, each >> contact uri bearing a pn-prid for either voip or remote service: the >> forking by a proxy that is unaware of push notifications could result in >> INVITEs to be duplicated. >> >> We had to go fast otherwise our app would stop working, but from the >> beginning we have in mind that this issue should be raised and hopefully >> resolved here at IETF, with or without our proposed syntax extension. >> >> Today due to Apple's recent changes, it looks like RFC8599 cannot be use= d >> "as is" to make a SIP app for iOS. The risk that Google does the same in >> near future exists. >> Are there people interested here in collaborating to an RFC8599 update t= o >> address this iOS platform evolution ? In other words, we need to solve h= ow >> to convey multiple pn-prid and pn-param for a same user-agent instance. >> >> Best regards, >> >> Simon >> >> >> >> >> >> >> >> Le dim. 11 oct. 2020 =C3=A0 17:07, Yehoshua Gev a = =C3=A9crit : >> >>> Hi All, >>> >>> I hope it is ok to post this here and not on sip-implementors... >>> >>> We are trying to implement RFC 8599 for performing push notifications >>> for Apple devices. >>> >>> Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps >>> receiving VoIP push notifications *must report the call quickly to >>> CallKit, so it can alert the user* to the presence of the incoming >>> call." >>> >>> According to RFC 8599, pushes are used for (at least) two >>> different goals: >>> 1) Initiating registration refreshes (section 5.5) >>> 2) Notifying of incoming calls (section 5.6.2) >>> >>> Now, for a reasonable user experience, the registration refresh pushes >>> must not trigger the UI of incoming call. >>> However, when an INVITE is received, the UA must be awoken immediately, >>> which is the purpose of VoIP push. >>> >>> Does it make sense to make a different push type for registration >>> refresh and for incoming calls? >>> >>> I'm not sure this is possible with the current RFC (and it is also >>> against the spirit of the RFC), but I can't think of another way around= it >>> (besides using regular pushes instead of VoIP pushes, which might intro= duce >>> delays, or having a registration with infinite expiration that will not >>> require refreshes, which might leave many zomby registrations). >>> >>> See some discussion here: [2], [3]. >>> >>> Thanks, >>> Yehoshua >>> >>> [1] >>> https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-vo= ip >>> [2] https://developer.apple.com/forums/thread/117939 >>> [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> --00000000000010e86605b1d9e2a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yehoshua,

Let me answer your questions.

* The pn-par= am is used by the proxy to know the application ID, which is necessary to k= now which credentials or TLS client certificate to connect to the Apple pus= h server. The voip&remote=C2=A0advertise that the app understands both = voip and remote push notifications, and as such two certificates/credential= s should be available to the server for this.

1. Y= es. I saw your other suggestion, which is indeed more readable, but breaks= =C2=A0compatibility with=C2=A0RFC8599 .

2. The proxy has forcibly some platform specific logic to handle push noti= fications. It cannot be unaware that for Apple platform, the "voip&quo= t; type must only be used for calls. Note that it is not a question of SIP = method, because SIP INVITE can be used to establish chat sessions with MSRP= protocol for example, and in this case a "voip" type notificatio= n must not be used.

3. It could indeed, however it= discloses information to push notification servers. In linphone, we do not= pass it for this reason. Instead, the CallKit view is subsequently updated= to display the caller-id once the INVITE has arrived (which usually takes = no more than a few seconds).

The background update= s push notifications (https://developer.= apple.com/documentation/usernotifications/setting_up_a_remote_notification_= server/pushing_background_updates_to_your_app?language=3Dobjc) are reli= able. They are indeed rate limited (3 per hour) which makes them unsuitable= to advertise calls or incoming messages. But in order to trigger a REGISTE= R request it's good enough, and they do not require to show something t= o the user: the work silently.=C2=A0
To make the system reliable,= I imagine the registrar could send a background push notification at 80 % = of expire time, and then once a day during a guard period of XX days in ord= er to give additional chances for apps that temporarily have no longer acce= ss to the network to finally refresh their registration.

Best regards,

Simon


Le=C2=A0lun. 12 oct. 2020 =C3=A0=C2=A016:40, Yehoshua Gev <yoshigev@gmail.com> a =C3=A9crit= =C2=A0:
Hi Simon,

=
Thanks for your detailed explanation of the behavior you have implemen= ted.

One Q: How is the "pn-param=3DDEF123GHIJ= .org.linphone.phone.voip&remote" used?
Does the server r= eally make use of the "&remote" suffix or it can be used like= "DEF123GHIJ.org.linphone.phone.*" with=C2=A0the "*" be= ing always replaced with the service?

In any case,= I'm willing to help with work on a new RFC, but sadly I don't have= much time for it.

Regarding the scope of the upda= ted RFC, I think there are several issues that should be addressed:

1. How the UA passes several "pn-*"-sets for a = single registration. The solution you've done on Linphone seems like a = good approach if backward compatibility with RFC 8599 is required.

2. How would the proxy decide which pn-*-values-set to use= for a specific push notification? For example, a naive approach is to pre-= define a mapping between "pr-*"-set and SIP methods (i.e., INVITE= will use a "voip" params).

3. (maybe un= related) For good user experience, the caller-id should be passed along wit= h the voip push notification so the UI of incoming calls can display it imm= ediately.

BTW, regarding triggering=C2=A0of regist= ration refreshes, our iOS developers say that in order for a push notificat= ion to work reliably (i.e., assured to be processed by the application even= if it is terminated), it must have some UI notification. This means that t= he user will be informed of each registration refresh. If this is true, the= n the expiry time must be kept very long (weeks/months) in any case. Is thi= s also your understanding?


Yehoshua=


On Sun, Oct 11, 2020 at 11:43 PM Simon MORLAT <simon.morlat@gmail.= com> wrote:
Hi= =C2=A0Yehoshua,

Thank you for starting= this discussion.
My company is developing the Linphone software = (https://linphone.org), an cross platform open-source SIP softphone and SDK.
For push noti= fications, we based our work on RFC 8599 , but indeed we had to somewhat ex= tend the RFC in order to transmit 2 different push notification tokens:
- the one for calls (PushKit kind of notifications)
- the = one for IMs (using Remote push notification service).=C2=A0

<= /div>
As of today, the Linphone app doesn't use push notificatio= ns for triggering REGISTER refreshes: we use a very long expire time (one y= ear) instead. However we would prefer to switch to push-triggered REGISTER = refresh as soon as possible.

The syntax extension = we made to RFC8599 is described in our wiki:


We designed this syntax to be comp= atible with RFC8599 syntax. To summarize, here is a quick example to unders= tand how we convey push tokens for an app that needs to advertise calls and= IMs:

pn= -prid=3D00fc13adff78512:voip&c11292f7b74733d:remote;pn-param=3DDEF123GHIJ.org.linphone.phone.voi= p&remote;pn-provider= =3Dapns

Notice the ":v= oip" and ":remote" token suffixes, and the "&"= .
We decided not= to go with a multiple contact headers approach, each contact uri bearing a= pn-prid for either voip or remote service: the forking by a proxy that is = unaware of push notifications could result in INVITEs to be duplicated.

We had to go fast otherwise ou= r app would stop working, but from=C2=A0the beginning we have in mind that = this issue should be raised and hopefully resolved here at IETF, with or wi= thout our proposed syntax extension.

Today due to Apple's recent chang= es, it looks like RFC8599 cannot be used "as is" to make a SIP ap= p for iOS. The risk that Google does the same in near future exists.
Are= there people interested here in collaborating to an RFC8599 update to addr= ess this iOS platform evolution ? In other words, we need to solve how to c= onvey multiple pn-prid and pn-param for a same user-agent instance.

= Best regards,

Simon



=



=
Le=C2= =A0dim. 11 oct. 2020 =C3=A0=C2=A017:07, Yehoshua Gev <yoshigev@gmail.com> a =C3=A9cr= it=C2=A0:
Hi All,

=
I hope it is ok to=C2=A0post this here and not on sip-implementors...<= /div>

We are trying to implement RFC 8599 for performing= push notifications for Apple devices.

Starting wi= th iOS 13, there is a restriction=C2=A0on VoIP pushes [1]: "Apps recei= ving VoIP push notifications must report the call quickly to CallKit, so= it can alert the user to the presence of the incoming call."

According to RFC 8599, pushes are used for (at least) = two different=C2=A0goals:
=C2=A0 1) Initiating registration refre= shes (section 5.5)
=C2=A0 2) Notifying of incoming calls (section= 5.6.2)

Now, for a reasonable=C2=A0user experi= ence, the registration refresh pushes must not trigger the UI of incoming c= all.
However, when an INVITE is received, the UA must be awoken i= mmediately, which is the purpose=C2=A0of VoIP push.

Does it make sense to make a different push type for registration refresh= and for incoming calls?

I'm not sure this is = possible with the current RFC (and it is also against the spirit of the RFC= ), but I can't think of another way around it (besides using regular pu= shes instead of VoIP pushes, which might introduce delays, or having a regi= stration with infinite expiration that=C2=A0will not require refreshes, whi= ch might leave many zomby registrations).

See some= discussion here: [2], [3].

Thanks,
= Yehoshua


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--00000000000010e86605b1d9e2a1-- From nobody Sat Oct 17 01:51:38 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3003A0917 for ; Sat, 17 Oct 2020 01:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 rU8k_cZy-pdU for ; Sat, 17 Oct 2020 01:51:34 -0700 (PDT) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 0A42B3A0905 for ; Sat, 17 Oct 2020 01:51:34 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id w7so1215432oow.7 for ; Sat, 17 Oct 2020 01:51:34 -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 :cc; bh=qiwOom30B83pFeAXGZmyg+QIJiv/r1V3n/WXf27L0ng=; b=rF0XoUNPhJgoXWYIbJ/UWG6ConITsbfASV4eeZ6pLVW8NcSixljD5fyjWgjXGWZcy7 Z58ZytdWf9j0qo8X8FUCHWRx6hF+P4JB6G2MOoF5hCfwj6T2o53I2TFORJgzUgmAIuN+ /MjywnxIYPHCZO7dTTLwyrAefS4K6HVRH2Lq+DVazdNRrwlgptNoiEpm1VtkNg9Uk/bD wqPWhP4cP1LLozSu+gk7n3xqoHwHfDOmY/BgBlX+8cKtemQ1enGN4amGB5gbpvHnutQH aAw4GJli0xeX6wXt/QBbJeUh9+GO6tbVQ5VxdUW+5kA71bDI9yzbCLFXURFNv00Gto6v /jgQ== 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=qiwOom30B83pFeAXGZmyg+QIJiv/r1V3n/WXf27L0ng=; b=oaH0IxSy1+as/pXHtgY3Qyus8sTp5pCORJ9UR52HAmuINs+k2nJ+sUsAUGWvH60Zjl eUpGdMCXQyaQxnJ0bnB+Og6mA04kmpMsduW8Wi3H/yzwHoeIEOecLbI5Nts4nLdnWBJ4 VwKHUNsZ7dQ9z381XidPZjgrKAEnuWU0u+dFoyEtytZJbeovUoiSMi7+zF8204oZndVs KnhVl24xX/paLqIISJ5jsjAQkOZwsZThj7lH4UEOa4dcn+x6Y2AAdjW2GeYGI7Uofghr 5UzxuJ3dPd5yRsIzUhzjsrUqKRMm1gzqzhQN83UGFfzghvJtlR7CYjZlagFYi7EDXKTk fCnw== X-Gm-Message-State: AOAM531H5Bi2tGjRGqLF1pBZDIqUTaQ6nzC/e9rIiTreYU4K8ahibgXV ADWe7zy4MLeSpBxynGqdmATz0D00Fp4ReYvOSeY= X-Google-Smtp-Source: ABdhPJx59OVRgmMLvtXTAal84c2aAwQ2DuO1Ivu+tzfUFmNfNzp1yuAjEW3EQ1N7SwI0axYVhtXjzt7tiflsKqrY62o= X-Received: by 2002:a4a:b78f:: with SMTP id a15mr5597515oop.33.1602924693136; Sat, 17 Oct 2020 01:51:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon MORLAT Date: Sat, 17 Oct 2020 10:51:10 +0200 Message-ID: To: Christer Holmberg Cc: Yehoshua Gev , sipcore Content-Type: multipart/alternative; boundary="000000000000efa8fa05b1d9fcd4" Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 08:51:37 -0000 --000000000000efa8fa05b1d9fcd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, >From our experience with Apple push notifications, they are reliable. They can be postponed by a few minutes, but for refreshing a register that has a typical expires of one hour, that's reasonable. It is still possible to use long expires (24 hours for example), and have the server continue to send background push notifications after the expiry for a period of time in order to make sure that the app doesn't get lost if for example it has temporarily no possible access to the network. Best regards, Simon Le lun. 12 oct. 2020 =C3=A0 16:55, Christer Holmberg < christer.holmberg@ericsson.com> a =C3=A9crit : > Hi, > > > > As you suggest, one solution is to use a different (non-VoIP) push > notification in order to trigger re-registrations. > > > > The only issue with those, AFAIK, is that there is no guarantee when/if > they will actually wake up the application. It depends on a number of > factors, e.g., energy mode, how often the app is used, etc etc. However, = I > don=E2=80=99t have any data regarding that. > > > > Regards, > > > > Christer > > > > *From:* sipcore *On Behalf Of *Simon MORLAT > *Sent:* sunnuntai 11. lokakuuta 2020 23.43 > *To:* Yehoshua Gev > *Cc:* sipcore > *Subject:* Re: [sipcore] Push notifications with iOS 13 (RFC 8599) > > > > Hi Yehoshua, > > > > Thank you for starting this discussion. > > My company is developing the Linphone software (https://linphone.org > ), > an cross platform open-source SIP softphone and SDK. > > The last version we published was for adding compatibility for iOS 13. I > admit it was a nightmare to comply with the new restrictions. > > For push notifications, we based our work on RFC 8599 , but indeed we had > to somewhat extend the RFC in order to transmit 2 different push > notification tokens: > > - the one for calls (PushKit kind of notifications) > > - the one for IMs (using Remote push notification service). > > > > To answer your question: the "remote push notification" token could > apparently also be used for "Background push notifications" ( > https://developer.apple.com/documentation/usernotifications/setting_up_a_= remote_notification_server/pushing_background_updates_to_your_app?language= =3Dobjc > ), which are the push notifications we need to refresh a REGISTER that is > about to expire (or expired). So yes you need two different push services > and tokens. > > > > As of today, the Linphone app doesn't use push notifications for > triggering REGISTER refreshes: we use a very long expire time (one year) > instead. However we would prefer to switch to push-triggered REGISTER > refresh as soon as possible. > > > > The syntax extension we made to RFC8599 is described in our wiki: > > > > > https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/iO= S/#HUpdateContactURIparameters > > > > > We designed this syntax to be compatible with RFC8599 syntax. To > summarize, here is a quick example to understand how we convey push token= s > for an app that needs to advertise calls and IMs: > > > > > pn-prid=3D00fc13adff78512:voip&c11292f7b74733d:remote;pn-param=3DDEF123GH= IJ.org.linphone.phone.voip&remote;pn-provider=3Dapns > > > > Notice the ":voip" and ":remote" token suffixes, and the "&". > > We decided not to go with a multiple contact headers approach, each > contact uri bearing a pn-prid for either voip or remote service: the > forking by a proxy that is unaware of push notifications could result in > INVITEs to be duplicated. > > > > We had to go fast otherwise our app would stop working, but from the > beginning we have in mind that this issue should be raised and hopefully > resolved here at IETF, with or without our proposed syntax extension. > > > > Today due to Apple's recent changes, it looks like RFC8599 cannot be used > "as is" to make a SIP app for iOS. The risk that Google does the same in > near future exists. > Are there people interested here in collaborating to an RFC8599 update to > address this iOS platform evolution ? In other words, we need to solve ho= w > to convey multiple pn-prid and pn-param for a same user-agent instance. > > Best regards, > > Simon > > > > > > > > > > > > > > > > Le dim. 11 oct. 2020 =C3=A0 17:07, Yehoshua Gev a = =C3=A9crit : > > Hi All, > > > > I hope it is ok to post this here and not on sip-implementors... > > > > We are trying to implement RFC 8599 for performing push notifications for > Apple devices. > > > > Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps > receiving VoIP push notifications *must report the call quickly to > CallKit, so it can alert the user* to the presence of the incoming call." > > > > According to RFC 8599, pushes are used for (at least) two different goals= : > > 1) Initiating registration refreshes (section 5.5) > > 2) Notifying of incoming calls (section 5.6.2) > > > > Now, for a reasonable user experience, the registration refresh pushes > must not trigger the UI of incoming call. > > However, when an INVITE is received, the UA must be awoken immediately, > which is the purpose of VoIP push. > > > > Does it make sense to make a different push type for registration refresh > and for incoming calls? > > > > I'm not sure this is possible with the current RFC (and it is also agains= t > the spirit of the RFC), but I can't think of another way around it (besid= es > using regular pushes instead of VoIP pushes, which might introduce delays= , > or having a registration with infinite expiration that will not require > refreshes, which might leave many zomby registrations). > > > > See some discussion here: [2], [3]. > > > > Thanks, > > Yehoshua > > > > [1] > https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-voip > > [2] https://developer.apple.com/forums/thread/117939 > > [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --000000000000efa8fa05b1d9fcd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

From our experience with A= pple push notifications, they are reliable. They can be postponed by a few = minutes, but for refreshing a register that has a typical expires of one ho= ur, that's reasonable.
It is still possible to use long expir= es (24 hours for example), and have the server continue to send background = push notifications after the expiry for a period of time in order to make s= ure that the app doesn't get lost if for example it has temporarily no = possible access to the network.

Best regards,

Simon


Le=C2=A0lun. 12 oct. 2020 = =C3=A0=C2=A016:55, Christer Holmberg <christer.holmberg@ericsson.com> a =C3=A9crit=C2=A0:<= br>

Hi,

=C2=A0

As you suggest, one solution is= to use a different (non-VoIP) push notification in order to trigger re-reg= istrations.

=C2=A0

The only issue with those, AFAI= K, is that there is no guarantee when/if they will actually wake up the app= lication. It depends on a number of factors, e.g., energy mode, how often t= he app is used, etc etc. However, I don=E2=80=99t have any data regarding tha= t.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: sipcore <sipcore-bounces@ietf.org> On Behalf Of Simon MORLAT
Sent: sunnuntai 11. lokakuuta 2020 23.43
To: Yehoshua Gev <yoshigev@gmail.com>
Cc: sipcore <sipcore@ietf.org>
Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599)<= /u>

=C2=A0

Hi=C2=A0Yehoshua,

=C2=A0

Thank you for starting this discussion.

My company is developing the Linphone software (https://l= inphone.org), an cross platform open-source SIP softphone and SDK.

The last version we published was for adding compati= bility for iOS 13. I admit it was a nightmare to comply with the new restri= ctions.

For push notifications, we based our work on RFC 859= 9 , but indeed we had to somewhat extend the RFC in order to transmit 2 dif= ferent push notification tokens:

- the one for calls (PushKit kind of notifications)<= u>

- the one for IMs (using Remote push notification se= rvice).=C2=A0

=C2=A0

To answer your question: the "remote push notif= ication" token could apparently also be used for "Background push= notifications" (https://developer.= apple.com/documentation/usernotifications/setting_up_a_remote_notification_= server/pushing_background_updates_to_your_app?language=3Dobjc ), which are the push notifications we need to refresh a REGISTER that is = about to expire (or expired). So yes you need two different push services a= nd tokens.

=C2=A0

As of today, the Linphone app doesn't use push n= otifications for triggering REGISTER refreshes: we use a very long expire t= ime (one year) instead. However we would prefer to switch to push-triggered= REGISTER refresh as soon as possible.

=C2=A0

The syntax extension we made to RFC8599 is described= in our wiki:

=C2=A0

=C2=A0

We designed this syntax to be compatible with RFC859= 9 syntax. To summarize, here is a quick example to understand how we convey= push tokens for an app that needs to advertise calls and IMs:

=C2=A0

pn-prid=3D00fc13adff78512:voip&c11292= f7b74733d:remote;pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;p= n-provider=3Dapns

=C2=A0

Notice the ":voip" and ":r= emote" token suffixes, and the "&".=

We decided not to go with a multiple cont= act headers approach, each contact uri bearing a pn-prid for either voip or= remote service: the forking by a proxy that is unaware of push notifications could result in INVITEs to be duplic= ated.

=C2=A0

We had to go fast otherwise our app would= stop working, but from=C2=A0the beginning we have in mind that this issue = should be raised and hopefully resolved here at IETF, with or without our proposed syntax extension.

=C2=A0

Today due to Apple's recent changes, it looks li= ke RFC8599 cannot be used "as is" to make a SIP app for iOS. The = risk that Google does the same in near future exists.
Are there people interested here in collaborating to an RFC8599 update to a= ddress this iOS platform evolution ? In other words, we need to solve how t= o convey multiple pn-prid and pn-param for a same user-agent instance.

Best regards,

Simon

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Le=C2=A0dim. 11 oct. 2020 =C3=A0=C2=A017:07, Yehoshu= a Gev <yoshigev@= gmail.com> a =C3=A9crit=C2=A0:

Hi All,

=C2=A0

I hope it is ok to=C2=A0post this here and not on si= p-implementors...

=C2=A0

We are trying to implement RFC 8599 for performing p= ush notifications for Apple devices.

=C2=A0

Starting with iOS 13, there is a restriction=C2=A0on= VoIP pushes [1]: "Apps receiving VoIP push notifications must report the call quickly to CallKit, so it can alert the user to= the presence of the incoming call."

=C2=A0

According to RFC 8599, pushes are used for (at least= ) two different=C2=A0goals:

=C2=A0 1) Initiating registration refreshes (section= 5.5)

=C2=A0 2) Notifying of incoming calls (section 5.6.2= )

=C2=A0

Now, for a reasonable=C2=A0user experience, the regi= stration refresh pushes must not trigger the UI of incoming call.=

However, when an INVITE is received, the UA must be = awoken immediately, which is the purpose=C2=A0of VoIP push.

=C2=A0

Does it make sense to make a different push type for= registration refresh and for incoming calls?

=C2=A0

I'm not sure this is possible with the current R= FC (and it is also against the spirit of the RFC), but I can't think of= another way around it (besides using regular pushes instead of VoIP pushes= , which might introduce delays, or having a registration with infinite expiration that=C2=A0will not require refresh= es, which might leave many zomby registrations).

=C2=A0

See some discussion here: [2], [3].

=C2=A0

Thanks,

Yehoshua

=C2=A0

=C2=A0

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

--000000000000efa8fa05b1d9fcd4-- From nobody Sun Oct 18 02:36:59 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA413A0911 for ; Sun, 18 Oct 2020 02:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 6wz_RHiES3A7 for ; Sun, 18 Oct 2020 02:36:55 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 344623A0906 for ; Sun, 18 Oct 2020 02:36:55 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id d19so4000393vso.10 for ; Sun, 18 Oct 2020 02:36:55 -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 :cc; bh=aMf/tNI6zIoBEy9T2LoX0yjAAaTnxBV0dyGIpRK89kk=; b=uIKllk7JE7Niku2LdpncpeAd8F1eL6DQHGmMH4qMekFHcD9JPz+xY5WybFwqquKueT CoAhDoAbDrzt2Nftm+98JckFQ8kZb0Thi0u1kLzWKv2+MDs8WnEq7ueato05l2GPyQpM CcNVNEjvY/zJyEVfAANOQctABMFp4/QfVBbu0771Hb0GmeYUs6dc4ql/6oNRBNWOpm+Z 5qCAlc6iLzzZxwnNB/UY3dD/ZYcjL1RAQyk0nkldtoHR9tX+mFw+sv93pvuN0qVrhgC4 hGIthDH5mPn6KGgUOtVju8UpyJ4esY5UvgpcqrxQ7mCdBGdvGbSYxusDMvj4ERxHlEfU gEIg== 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=aMf/tNI6zIoBEy9T2LoX0yjAAaTnxBV0dyGIpRK89kk=; b=BQz+YX+Bb4F/yfow4oNS7y9d76hQCd80fkuQErR1QhB+J9TwN1dSdmW7mmBjXf44R6 N7e1x3BwENqnCVonrkuRklf2xH7i3LKcglBIJFACtkvcTI+mgDjp1cYM5TW+bnI2PRYo TqYIidUw2CZIif63Hk8NVz8tbhterhoyOqpVhVt0+kBZ3cqz3m/ImxN4RjBVJovVvWwK jd31ADczbI5oHUHBXLqMAaJAPMnHO+nCzKZh0wvT9pgLn9VJMkIMWn8PoQUvstNF8HSe LQfz6yHhSh4FhOJ7rDi5HXbgchiOqWYGY8M9Abq95Tw4UqZRJz4/4I36GL9iUZJaZl8n aDvw== X-Gm-Message-State: AOAM533vahoKAHgfZE2iZHcYNVPOFQaXEBb53c4FNt8eU5HfXbrvOGKF NUGh19DmKq7Kp0GdrCzPOew0dmx2GFh4sqs6JRk= X-Google-Smtp-Source: ABdhPJxm0deBqJGV5RHqf/w4/od/p42fjk02p+/c7syBijfXYV+eF5vwU+KdxSp6lIyisHeIeTiScPBzLhLogIE4/uw= X-Received: by 2002:a67:f981:: with SMTP id b1mr5970907vsq.5.1603013814001; Sun, 18 Oct 2020 02:36:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yehoshua Gev Date: Sun, 18 Oct 2020 12:38:17 +0300 Message-ID: To: Simon MORLAT Cc: sipcore Content-Type: multipart/alternative; boundary="000000000000f4254d05b1eebc66" Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 09:36:58 -0000 --000000000000f4254d05b1eebc66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. So what should be the inputs to the logic that decides which push type to use? Would method + media types (of the SDP m=3D line) suffice? Or maybe just pre-defined types (voice, voice+video?, message and register) with pre-defined proxy logic for choosing between them? Do you think we could come up with a format that will be general and not Apple-specific? Is there interest in the group for this? Yehoshua On Sat, Oct 17, 2020 at 11:44 AM Simon MORLAT wrote: > Hi Yehoshua, > > Let me answer your questions. > > * The pn-param is used by the proxy to know the application ID, which is > necessary to know which credentials or TLS client certificate to connect = to > the Apple push server. The voip&remote advertise that the app understands > both voip and remote push notifications, and as such two > certificates/credentials should be available to the server for this. > > 1. Yes. I saw your other suggestion, which is indeed more readable, but > breaks compatibility with RFC8599 . > > 2. The proxy has forcibly some platform specific logic to handle push > notifications. It cannot be unaware that for Apple platform, the "voip" > type must only be used for calls. Note that it is not a question of SIP > method, because SIP INVITE can be used to establish chat sessions with MS= RP > protocol for example, and in this case a "voip" type notification must no= t > be used. > > 3. It could indeed, however it discloses information to push notification > servers. In linphone, we do not pass it for this reason. Instead, the > CallKit view is subsequently updated to display the caller-id once the > INVITE has arrived (which usually takes no more than a few seconds). > > The background updates push notifications ( > https://developer.apple.com/documentation/usernotifications/setting_up_a_= remote_notification_server/pushing_background_updates_to_your_app?language= =3Dobjc) > are reliable. They are indeed rate limited (3 per hour) which makes them > unsuitable to advertise calls or incoming messages. But in order to trigg= er > a REGISTER request it's good enough, and they do not require to show > something to the user: the work silently. > To make the system reliable, I imagine the registrar could send a > background push notification at 80 % of expire time, and then once a day > during a guard period of XX days in order to give additional chances for > apps that temporarily have no longer access to the network to finally > refresh their registration. > > Best regards, > > Simon > > > Le lun. 12 oct. 2020 =C3=A0 16:40, Yehoshua Gev a = =C3=A9crit : > >> Hi Simon, >> >> Thanks for your detailed explanation of the behavior you have implemente= d. >> >> One Q: How is the "pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote" >> used? >> Does the server really make use of the "&remote" suffix or it can be use= d >> like "DEF123GHIJ.org.linphone.phone.*" with the "*" being always replace= d >> with the service? >> >> In any case, I'm willing to help with work on a new RFC, but sadly I >> don't have much time for it. >> >> Regarding the scope of the updated RFC, I think there are several issues >> that should be addressed: >> >> 1. How the UA passes several "pn-*"-sets for a single registration. The >> solution you've done on Linphone seems like a good approach if backward >> compatibility with RFC 8599 is required. >> >> 2. How would the proxy decide which pn-*-values-set to use for a specifi= c >> push notification? For example, a naive approach is to pre-define a mapp= ing >> between "pr-*"-set and SIP methods (i.e., INVITE will use a "voip" param= s). >> >> 3. (maybe unrelated) For good user experience, the caller-id should be >> passed along with the voip push notification so the UI of incoming calls >> can display it immediately. >> >> BTW, regarding triggering of registration refreshes, our iOS developers >> say that in order for a push notification to work reliably (i.e., assure= d >> to be processed by the application even if it is terminated), it must ha= ve >> some UI notification. This means that the user will be informed of each >> registration refresh. If this is true, then the expiry time must be kept >> very long (weeks/months) in any case. Is this also your understanding? >> >> >> Yehoshua >> >> >> On Sun, Oct 11, 2020 at 11:43 PM Simon MORLAT >> wrote: >> >>> Hi Yehoshua, >>> >>> Thank you for starting this discussion. >>> My company is developing the Linphone software (https://linphone.org), >>> an cross platform open-source SIP softphone and SDK. >>> The last version we published was for adding compatibility for iOS 13. = I >>> admit it was a nightmare to comply with the new restrictions. >>> For push notifications, we based our work on RFC 8599 , but indeed we >>> had to somewhat extend the RFC in order to transmit 2 different push >>> notification tokens: >>> - the one for calls (PushKit kind of notifications) >>> - the one for IMs (using Remote push notification service). >>> >>> To answer your question: the "remote push notification" token could >>> apparently also be used for "Background push notifications" ( >>> https://developer.apple.com/documentation/usernotifications/setting_up_= a_remote_notification_server/pushing_background_updates_to_your_app?languag= e=3Dobjc >>> ), which are the push notifications we need to refresh a REGISTER that = is >>> about to expire (or expired). So yes you need two different push servic= es >>> and tokens. >>> >>> As of today, the Linphone app doesn't use push notifications for >>> triggering REGISTER refreshes: we use a very long expire time (one year= ) >>> instead. However we would prefer to switch to push-triggered REGISTER >>> refresh as soon as possible. >>> >>> The syntax extension we made to RFC8599 is described in our wiki: >>> >>> >>> https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/= iOS/#HUpdateContactURIparameters >>> >>> We designed this syntax to be compatible with RFC8599 syntax. To >>> summarize, here is a quick example to understand how we convey push tok= ens >>> for an app that needs to advertise calls and IMs: >>> >>> pn-prid=3D00fc13adff78512:voip&c11292f7b74733d:remote; >>> pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;pn-provider=3Dapns >>> >>> Notice the ":voip" and ":remote" token suffixes, and the "&". >>> We decided not to go with a multiple contact headers approach, each >>> contact uri bearing a pn-prid for either voip or remote service: the >>> forking by a proxy that is unaware of push notifications could result i= n >>> INVITEs to be duplicated. >>> >>> We had to go fast otherwise our app would stop working, but from the >>> beginning we have in mind that this issue should be raised and hopefull= y >>> resolved here at IETF, with or without our proposed syntax extension. >>> >>> Today due to Apple's recent changes, it looks like RFC8599 cannot be >>> used "as is" to make a SIP app for iOS. The risk that Google does the s= ame >>> in near future exists. >>> Are there people interested here in collaborating to an RFC8599 update >>> to address this iOS platform evolution ? In other words, we need to sol= ve >>> how to convey multiple pn-prid and pn-param for a same user-agent insta= nce. >>> >>> Best regards, >>> >>> Simon >>> >>> >>> >>> >>> >>> >>> >>> Le dim. 11 oct. 2020 =C3=A0 17:07, Yehoshua Gev a >>> =C3=A9crit : >>> >>>> Hi All, >>>> >>>> I hope it is ok to post this here and not on sip-implementors... >>>> >>>> We are trying to implement RFC 8599 for performing push notifications >>>> for Apple devices. >>>> >>>> Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps >>>> receiving VoIP push notifications *must report the call quickly to >>>> CallKit, so it can alert the user* to the presence of the incoming >>>> call." >>>> >>>> According to RFC 8599, pushes are used for (at least) two >>>> different goals: >>>> 1) Initiating registration refreshes (section 5.5) >>>> 2) Notifying of incoming calls (section 5.6.2) >>>> >>>> Now, for a reasonable user experience, the registration refresh pushes >>>> must not trigger the UI of incoming call. >>>> However, when an INVITE is received, the UA must be awoken immediately= , >>>> which is the purpose of VoIP push. >>>> >>>> Does it make sense to make a different push type for registration >>>> refresh and for incoming calls? >>>> >>>> I'm not sure this is possible with the current RFC (and it is also >>>> against the spirit of the RFC), but I can't think of another way aroun= d it >>>> (besides using regular pushes instead of VoIP pushes, which might intr= oduce >>>> delays, or having a registration with infinite expiration that will no= t >>>> require refreshes, which might leave many zomby registrations). >>>> >>>> See some discussion here: [2], [3]. >>>> >>>> Thanks, >>>> Yehoshua >>>> >>>> [1] >>>> https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-v= oip >>>> [2] https://developer.apple.com/forums/thread/117939 >>>> [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> --000000000000f4254d05b1eebc66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks.

So what should be the inputs to= the logic that decides which push type to use?
Would method + me= dia types (of the SDP m=3D line) suffice?
Or maybe just pre-defin= ed types (voice, voice+video?, message and register) with pre-defined proxy= logic for choosing between them?

Do you think we = could come up with a format that will be general and not Apple-specific?
Is there interest in the group for this?

Y= ehoshua

On Sat, Oct 17, 2020 at 11:44 AM Simon MORLAT <simon.morlat@gmail.com> wrote:
Hi Yehoshua,

Let me answer y= our questions.

* The pn-param is used by the proxy= to know the application ID, which is necessary to know which credentials o= r TLS client certificate to connect to the Apple push server. The voip&= remote=C2=A0advertise that the app understands both voip and remote push no= tifications, and as such two certificates/credentials should be available t= o the server for this.

1. Yes. I saw your other su= ggestion, which is indeed more readable, but breaks=C2=A0compatibility = with=C2=A0RFC8599 .

2. The proxy has forcib= ly some platform specific logic to handle push notifications. It cannot be = unaware that for Apple platform, the "voip" type must only be use= d for calls. Note that it is not a question of SIP method, because SIP INVI= TE can be used to establish chat sessions with MSRP protocol for example, a= nd in this case a "voip" type notification must not be used.

3. It could indeed, however it discloses information t= o push notification servers. In linphone, we do not pass it for this reason= . Instead, the CallKit view is subsequently updated to display the caller-i= d once the INVITE has arrived (which usually takes no more than a few secon= ds).

The background updates push notifications (https://developer.apple.com/documentation/= usernotifications/setting_up_a_remote_notification_server/pushing_backgroun= d_updates_to_your_app?language=3Dobjc) are reliable. They are indeed ra= te limited (3 per hour) which makes them unsuitable to advertise calls or i= ncoming messages. But in order to trigger a REGISTER request it's good = enough, and they do not require to show something to the user: the work sil= ently.=C2=A0
To make the system reliable, I imagine the registrar= could send a background push notification at 80 % of expire time, and then= once a day during a guard period of XX days in order to give additional ch= ances for apps that temporarily have no longer access to the network to fin= ally refresh their registration.

Best regards,

Simon


Le=C2=A0lun. 12= oct. 2020 =C3=A0=C2=A016:40, Yehoshua Gev <yoshigev@gmail.com> a =C3=A9crit=C2=A0:<= br>
Hi Simon,

Thanks for your detailed explanation of the b= ehavior you have implemented.

One Q: How is the &q= uot;pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote" used?
Does the server really make use of the "&remote" suff= ix or it can be used like "DEF123GHIJ.org.linphone.phone.*" with= =C2=A0the "*" being always replaced with the service?
<= br>
In any case, I'm willing to help with work on a new RFC, = but sadly I don't have much time for it.

Regar= ding the scope of the updated RFC, I think there are several issues that sh= ould be addressed:

1. How the UA passes several &q= uot;pn-*"-sets for a single registration. The solution you've done= on Linphone seems like a good approach if backward compatibility with RFC = 8599 is required.

2. How would the proxy decide wh= ich pn-*-values-set to use for a specific push notification? For example, a= naive approach is to pre-define a mapping between "pr-*"-set and= SIP methods (i.e., INVITE will use a "voip" params).
<= br>
3. (maybe unrelated) For good user experience, the caller-id = should be passed along with the voip push notification so the UI of incomin= g calls can display it immediately.

BTW, regarding= triggering=C2=A0of registration refreshes, our iOS developers say that in = order for a push notification to work reliably (i.e., assured to be process= ed by the application even if it is terminated), it must have some UI notif= ication. This means that the user will be informed of each registration ref= resh. If this is true, then the expiry time must be kept very long (weeks/m= onths) in any case. Is this also your understanding?


Yehoshua


On Sun, Oct 11, 2020 at 11:4= 3 PM Simon MORLAT <simon.morlat@gmail.com> wrote:
Hi=C2=A0Yehoshua,

Thank you for starting this discussion.=
My company is developing the Linphone software (https://linphone.org), an cross plat= form open-source SIP softphone and SDK.
The last version we publi= shed was for adding compatibility for iOS 13. I admit it was a nightmare to= comply with the new restrictions.
For push notifications, we bas= ed our work on RFC 8599 , but indeed we had to somewhat extend the RFC in o= rder to transmit 2 different push notification tokens:
- the one = for calls (PushKit kind of notifications)
- the one for IMs (usin= g Remote push notification service).=C2=A0

To answ= er your question: the "remote push notification" token could appa= rently also be used for "Background push notifications" (https://developer.apple.com/documentation/usern= otifications/setting_up_a_remote_notification_server/pushing_background_upd= ates_to_your_app?language=3Dobjc ), which are the push notifications we= need to refresh a REGISTER that is about to expire (or expired). So yes yo= u need two different push services and tokens.

As = of today, the Linphone app doesn't use push notifications for triggerin= g REGISTER refreshes: we use a very long expire time (one year) instead. Ho= wever we would prefer to switch to push-triggered REGISTER refresh as soon = as possible.

The syntax extension we made to RFC85= 99 is described in our wiki:

https://wiki.linphone.org/xwiki/wiki/= public/view/Lib/Getting%20started/iOS/#HUpdateContactURIparameters
<= /div>

We designed this syntax to be compatible with RFC8= 599 syntax. To summarize, here is a quick example to understand how we conv= ey push tokens for an app that needs to advertise calls and IMs:
=
pn-prid=3D00fc13ad= ff78512:voip&c11292f7b74733d:remote;pn-param=3DDEF123GHIJ.org.linphone.phone.voip&remote;pn-provider=3Dapns

Notice the ":voip" and "= ;:remote" token suffixes, and the "&".
= We decided not to go with a multi= ple contact headers approach, each contact uri bearing a pn-prid for either= voip or remote service: the forking by a proxy that is unaware of push not= ifications could result in INVITEs to be duplicated.

We had to go fast otherwise our app would stop wo= rking, but from=C2=A0the beginning we have in mind that this issue should b= e raised and hopefully resolved here at IETF, with or without our proposed = syntax extension.
Le=C2=A0dim. 11 oct. 2020= =C3=A0=C2=A017:07, Yehoshua Gev <yoshigev@gmail.com> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hi All,
I hope it is ok to=C2=A0post this here and not on sip-imp= lementors...

We are trying to implement RFC 8599 f= or performing push notifications for Apple devices.

Starting with iOS 13, there is a restriction=C2=A0on VoIP pushes [1]: &qu= ot;Apps receiving VoIP push notifications must report the call quickly t= o CallKit, so it can alert the user to the presence of the incoming cal= l."

According to RFC 8599, pushes are used fo= r (at least) two different=C2=A0goals:
=C2=A0 1) Initiating regis= tration refreshes (section 5.5)
=C2=A0 2) Notifying of incoming c= alls (section 5.6.2)

Now, for a reasonable=C2= =A0user experience, the registration refresh pushes must not trigger the UI= of incoming call.
However, when an INVITE is received, the UA mu= st be awoken immediately, which is the purpose=C2=A0of VoIP push.

Does it make sense to make a different push type for regist= ration refresh and for incoming calls?

I'm not= sure this is possible with the current RFC (and it is also against the spi= rit of the RFC), but I can't think of another way around it (besides us= ing regular pushes instead of VoIP pushes, which might introduce delays, or= having a registration with infinite expiration that=C2=A0will not require = refreshes, which might leave many zomby registrations).
--000000000000f4254d05b1eebc66-- From nobody Mon Oct 19 07:42:58 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8673A0B01 for ; Mon, 19 Oct 2020 07:42:57 -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=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 kDsFw4FYYxWR for ; Mon, 19 Oct 2020 07:42:53 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2075.outbound.protection.outlook.com [40.107.22.75]) (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 5A89E3A0AFA for ; Mon, 19 Oct 2020 07:42:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XXpHsEpYiePnhuSWx3T+EnRbUEr1eH7fSWHJ4NRaaX7HfkTZG2LdpJ5rYEM65uTleGQqP5/Uc8HRdO8yGk0lD+DyhtzCH//kdBQ7d7GQG3qIrrhWGV/TKMXXHz3y+EnBbr9QS9E6BNUv5c1DxHegkusCLpj16+CqBmIZredTApG8HjsrHyrC7IPEaYTSV3Ut0BPh0MpKj/TKcA9gm/n4OnHPH/09+XA4W3iXhdUchJClVVCOIGYiRob63lKsUcmsJ8zBJd1wgc/D43VxxLK/dI3AKKCK/wnWo7Yc7hNflfhNWtmlRXQb6vAtcnCd9d67Q4I5+a5Aggqf8ArgE/smyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WBik3JMx2WtgPWX9+FVSy2pklLSQikiPIGnyTovuw7U=; b=H0lK5O5K2mX0bMeIss1U+iKCgmmjpYONaBlEjX6MgboLK4+NQZSYvQoLFbGC9qJSsYYqsE1QYiGe+Coc58+0viNzbYaQK54N0IVfFA90fxcxjzDRtyk/rNSkMdcl5vXt3jwCKVZ2VDcAN8oERUo25pnSGuRlSjovicQ7T+xo4Gox7fPf8dSlO/uWZIUMX3Qsegz9zjMnJnft4VWUSYZ7pAg0Rwn96g9iMCJ1xzqZ39uDnZcfJ9GgLB7ZSvqs7PHoAR7GajJoyx3U/CDmlGygiT7mn/cNHEayAqUnnmyu6L/gh0lLQddW0aGXs9uKP4U0TX0oL2mcKE7ODBNC8vnjLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WBik3JMx2WtgPWX9+FVSy2pklLSQikiPIGnyTovuw7U=; b=fFML1jtuNidYp8FyMKWCI+k+cqvyoC5q91GBGAe5Ta+7F4J2H9k1ksITqaoDs/Kxd6POEe/lB2KbRFRasvbXbKbZ35YHYC1qjlEA2Ti13rJzmpWgB2WiD4pbl40rygobXgxUM5WqkIGtAQgeji2TgiezAh+1rMMVAnKQ6CDgGHI= Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM0PR07MB5380.eurprd07.prod.outlook.com (2603:10a6:208:fc::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.11; Mon, 19 Oct 2020 14:42:51 +0000 Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::6cc3:4783:280b:d741]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::6cc3:4783:280b:d741%7]) with mapi id 15.20.3499.015; Mon, 19 Oct 2020 14:42:51 +0000 From: Christer Holmberg To: Yehoshua Gev , Simon MORLAT CC: sipcore Thread-Topic: [sipcore] Push notifications with iOS 13 (RFC 8599) Thread-Index: AQHWn+BDUTnEZITSgUW2d71fVS8LKKmS3pmAgAEs5wCAB3f4AIABoZeAgAHk6qA= Date: Mon, 19 Oct 2020 14:42:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 444a351b-fe3a-44f7-7d75-08d8743d4152 x-ms-traffictypediagnostic: AM0PR07MB5380: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +a+knqOudDa6TfCP8uogdIWkAKFJ/QJiX3mVGHM8fM4etbiya8X5jPACVDFmPpvWss/jP46hytl55HgUncIYJT0f8vfget8ts0IVC5eHivdf2VF2WAtY31mDHBJnbEkZKwoCzXCQ+A4u9E+9JiIqPUhji092/q7Ei4KflIZPK1Ok9glqwwAcHXQYBTfmok8Ws3fiNvlLtqy6DyZXoNizwC1Uku349PxOxqdHNMQBzM9cIBVgNGubXRHmXpA96qSrN6PmlbujvKi1TeTt+6FAs+wtlXgtrDhc5vSRAn1+H361CdZBz/x/6d+9QbbNxNtF9UkZ6euaD7CJ8SCpmcbQuz78aUifZnxHbWrgzvqbkiKrUsprr/9q/SNTZ5i9A6XSD4rN2FYkALTUDSIb6gBxSw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(52536014)(76116006)(5660300002)(66946007)(66446008)(66556008)(7696005)(6506007)(53546011)(55016002)(64756008)(66476007)(26005)(8936002)(186003)(4326008)(966005)(9686003)(478600001)(8676002)(316002)(110136005)(83380400001)(66574015)(86362001)(2906002)(71200400001)(15650500001)(33656002)(166002)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: cUfH4gAFuJvjfaNTKxAApyYobv6Gt42BsktC5C2CXGcpjB+01i4c53Yw+5ZT5gH89Nh72JFwk8BgRmr3IIN+3eV+TGdL9WTueNekoAE/qsSSzUs37Lz1zAljtDHQxDic91ysr01JQRCFEeKfkk0+ifxRitPaAlLBQYBtsV8yLQNl7zf1IGcml8KpYNzzVqw4jno36cvyL+vhTjAuXU8baX6KTgzkR7/mqUGnNzLRQOyquBepTxJEXRBrA9iBASSnRQ5bWVfHM3wPA7uz9zYrKQc+F8AGN1GaVxTHQyWTKUdXkaKGfE46vaNGHKI9ktlDh8vYWrOQYQOhVSblAx7qvGPCU1RRAEKxIiIN+Q1qeq2o2OyxTGC30v1L77k/AW+MRBJO1zlVzcnX1vnqrdgpGm3iWPziWaujAoXdtSNc6fPsrDQH7LRJ1slnrrTR0b4y+TDJYFw9H4Wyk0pzEpoTFS3t9l3poeIGRM1An6j4QdqQykTdsGYPMB1m0NhlDzrZ3bTxBeHEgd0Q/sKEr11Rck5UVkllUNXajBupc60CS6H/3nG4vHEyfYqrHGv0YX6sOjh1mabd2ZD7IHQxcpOojT0J2/SMz77h1QTuv5KwK9/Fvb1qdKdiLltvFkuxRkvchJEDDg+nVxtbBypbziJSvQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB3860916523BBCB9EB8614AB1931E0AM0PR07MB3860eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 444a351b-fe3a-44f7-7d75-08d8743d4152 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 14:42:51.0007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZYDikprAAWht/HqwJ9Ne4Rg0EFS52PJv/YzgAzznSQpHrtOR87nzeix+ObRTJ5wvdvNTrFGqJyUlWx76e/wAu0eiB7S/GEaOcqTv0M/nTjA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5380 Archived-At: Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:42:58 -0000 --_000_AM0PR07MB3860916523BBCB9EB8614AB1931E0AM0PR07MB3860eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoYXRldmVyIHRoZSBzb2x1dGlvbiBpcywgaXQgaGFzIHRvIGJlIGJhY2t3YXJkIGNv bXBhdGlibGUsIGluIG9yZGVyIHRvIG1pbmltaXplIHRoZSBpbXBhY3RzIG9uIGV4aXN0aW5nIGRl cGxveW1lbnRzLg0KDQpXaXRob3V0IGhhdmluZyB0aG91Z2h0IHRvbyBtdWNoIGFib3V0IGl0LCBv bmUgc3RyYWlnaHQgZm9yd2FyZCBzb2x1dGlvbiB3b3VsZCBiZSB0byBkZWZpbmUgbmV3IHBuLSBw YXJhbWV0ZXJzIGZvciBub24tVm9JUCBwdXNoIG5vdGlmaWNhdGlvbnMuIEkgYXNzdW1lIHdlIHdv dWxkIG5lZWQgbmV3IHBuLSBwYXJhbWV0ZXJzIGZvciBwbi1wYXJhbSBhbmQgcG4tcHJpZC4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogc2lwY29yZSA8c2lwY29yZS1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgWWVob3NodWEgR2V2DQpTZW50OiBzdW5udW50YWkgMTguIGxv a2FrdXV0YSAyMDIwIDEyLjM4DQpUbzogU2ltb24gTU9STEFUIDxzaW1vbi5tb3JsYXRAZ21haWwu Y29tPg0KQ2M6IHNpcGNvcmUgPHNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNv cmVdIFB1c2ggbm90aWZpY2F0aW9ucyB3aXRoIGlPUyAxMyAoUkZDIDg1OTkpDQoNClRoYW5rcy4N Cg0KU28gd2hhdCBzaG91bGQgYmUgdGhlIGlucHV0cyB0byB0aGUgbG9naWMgdGhhdCBkZWNpZGVz IHdoaWNoIHB1c2ggdHlwZSB0byB1c2U/DQpXb3VsZCBtZXRob2QgKyBtZWRpYSB0eXBlcyAob2Yg dGhlIFNEUCBtPSBsaW5lKSBzdWZmaWNlPw0KT3IgbWF5YmUganVzdCBwcmUtZGVmaW5lZCB0eXBl cyAodm9pY2UsIHZvaWNlK3ZpZGVvPywgbWVzc2FnZSBhbmQgcmVnaXN0ZXIpIHdpdGggcHJlLWRl ZmluZWQgcHJveHkgbG9naWMgZm9yIGNob29zaW5nIGJldHdlZW4gdGhlbT8NCg0KRG8geW91IHRo aW5rIHdlIGNvdWxkIGNvbWUgdXAgd2l0aCBhIGZvcm1hdCB0aGF0IHdpbGwgYmUgZ2VuZXJhbCBh bmQgbm90IEFwcGxlLXNwZWNpZmljPw0KSXMgdGhlcmUgaW50ZXJlc3QgaW4gdGhlIGdyb3VwIGZv ciB0aGlzPw0KDQpZZWhvc2h1YQ0KDQpPbiBTYXQsIE9jdCAxNywgMjAyMCBhdCAxMTo0NCBBTSBT aW1vbiBNT1JMQVQgPHNpbW9uLm1vcmxhdEBnbWFpbC5jb208bWFpbHRvOnNpbW9uLm1vcmxhdEBn bWFpbC5jb20+PiB3cm90ZToNCkhpIFllaG9zaHVhLA0KDQpMZXQgbWUgYW5zd2VyIHlvdXIgcXVl c3Rpb25zLg0KDQoqIFRoZSBwbi1wYXJhbSBpcyB1c2VkIGJ5IHRoZSBwcm94eSB0byBrbm93IHRo ZSBhcHBsaWNhdGlvbiBJRCwgd2hpY2ggaXMgbmVjZXNzYXJ5IHRvIGtub3cgd2hpY2ggY3JlZGVu dGlhbHMgb3IgVExTIGNsaWVudCBjZXJ0aWZpY2F0ZSB0byBjb25uZWN0IHRvIHRoZSBBcHBsZSBw dXNoIHNlcnZlci4gVGhlIHZvaXAmcmVtb3RlIGFkdmVydGlzZSB0aGF0IHRoZSBhcHAgdW5kZXJz dGFuZHMgYm90aCB2b2lwIGFuZCByZW1vdGUgcHVzaCBub3RpZmljYXRpb25zLCBhbmQgYXMgc3Vj aCB0d28gY2VydGlmaWNhdGVzL2NyZWRlbnRpYWxzIHNob3VsZCBiZSBhdmFpbGFibGUgdG8gdGhl IHNlcnZlciBmb3IgdGhpcy4NCg0KMS4gWWVzLiBJIHNhdyB5b3VyIG90aGVyIHN1Z2dlc3Rpb24s IHdoaWNoIGlzIGluZGVlZCBtb3JlIHJlYWRhYmxlLCBidXQgYnJlYWtzIGNvbXBhdGliaWxpdHkg d2l0aCBSRkM4NTk5IC4NCg0KMi4gVGhlIHByb3h5IGhhcyBmb3JjaWJseSBzb21lIHBsYXRmb3Jt IHNwZWNpZmljIGxvZ2ljIHRvIGhhbmRsZSBwdXNoIG5vdGlmaWNhdGlvbnMuIEl0IGNhbm5vdCBi ZSB1bmF3YXJlIHRoYXQgZm9yIEFwcGxlIHBsYXRmb3JtLCB0aGUgInZvaXAiIHR5cGUgbXVzdCBv bmx5IGJlIHVzZWQgZm9yIGNhbGxzLiBOb3RlIHRoYXQgaXQgaXMgbm90IGEgcXVlc3Rpb24gb2Yg U0lQIG1ldGhvZCwgYmVjYXVzZSBTSVAgSU5WSVRFIGNhbiBiZSB1c2VkIHRvIGVzdGFibGlzaCBj aGF0IHNlc3Npb25zIHdpdGggTVNSUCBwcm90b2NvbCBmb3IgZXhhbXBsZSwgYW5kIGluIHRoaXMg Y2FzZSBhICJ2b2lwIiB0eXBlIG5vdGlmaWNhdGlvbiBtdXN0IG5vdCBiZSB1c2VkLg0KDQozLiBJ dCBjb3VsZCBpbmRlZWQsIGhvd2V2ZXIgaXQgZGlzY2xvc2VzIGluZm9ybWF0aW9uIHRvIHB1c2gg bm90aWZpY2F0aW9uIHNlcnZlcnMuIEluIGxpbnBob25lLCB3ZSBkbyBub3QgcGFzcyBpdCBmb3Ig dGhpcyByZWFzb24uIEluc3RlYWQsIHRoZSBDYWxsS2l0IHZpZXcgaXMgc3Vic2VxdWVudGx5IHVw ZGF0ZWQgdG8gZGlzcGxheSB0aGUgY2FsbGVyLWlkIG9uY2UgdGhlIElOVklURSBoYXMgYXJyaXZl ZCAod2hpY2ggdXN1YWxseSB0YWtlcyBubyBtb3JlIHRoYW4gYSBmZXcgc2Vjb25kcykuDQoNClRo ZSBiYWNrZ3JvdW5kIHVwZGF0ZXMgcHVzaCBub3RpZmljYXRpb25zIChodHRwczovL2RldmVsb3Bl ci5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi91c2Vybm90aWZpY2F0aW9ucy9zZXR0aW5nX3VwX2Ff cmVtb3RlX25vdGlmaWNhdGlvbl9zZXJ2ZXIvcHVzaGluZ19iYWNrZ3JvdW5kX3VwZGF0ZXNfdG9f eW91cl9hcHA/bGFuZ3VhZ2U9b2JqYykgYXJlIHJlbGlhYmxlLiBUaGV5IGFyZSBpbmRlZWQgcmF0 ZSBsaW1pdGVkICgzIHBlciBob3VyKSB3aGljaCBtYWtlcyB0aGVtIHVuc3VpdGFibGUgdG8gYWR2 ZXJ0aXNlIGNhbGxzIG9yIGluY29taW5nIG1lc3NhZ2VzLiBCdXQgaW4gb3JkZXIgdG8gdHJpZ2dl ciBhIFJFR0lTVEVSIHJlcXVlc3QgaXQncyBnb29kIGVub3VnaCwgYW5kIHRoZXkgZG8gbm90IHJl cXVpcmUgdG8gc2hvdyBzb21ldGhpbmcgdG8gdGhlIHVzZXI6IHRoZSB3b3JrIHNpbGVudGx5Lg0K VG8gbWFrZSB0aGUgc3lzdGVtIHJlbGlhYmxlLCBJIGltYWdpbmUgdGhlIHJlZ2lzdHJhciBjb3Vs ZCBzZW5kIGEgYmFja2dyb3VuZCBwdXNoIG5vdGlmaWNhdGlvbiBhdCA4MCAlIG9mIGV4cGlyZSB0 aW1lLCBhbmQgdGhlbiBvbmNlIGEgZGF5IGR1cmluZyBhIGd1YXJkIHBlcmlvZCBvZiBYWCBkYXlz IGluIG9yZGVyIHRvIGdpdmUgYWRkaXRpb25hbCBjaGFuY2VzIGZvciBhcHBzIHRoYXQgdGVtcG9y YXJpbHkgaGF2ZSBubyBsb25nZXIgYWNjZXNzIHRvIHRoZSBuZXR3b3JrIHRvIGZpbmFsbHkgcmVm cmVzaCB0aGVpciByZWdpc3RyYXRpb24uDQoNCkJlc3QgcmVnYXJkcywNCg0KU2ltb24NCg0KDQpM ZSBsdW4uIDEyIG9jdC4gMjAyMCDDoCAxNjo0MCwgWWVob3NodWEgR2V2IDx5b3NoaWdldkBnbWFp bC5jb208bWFpbHRvOnlvc2hpZ2V2QGdtYWlsLmNvbT4+IGEgw6ljcml0IDoNCkhpIFNpbW9uLA0K DQpUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgZXhwbGFuYXRpb24gb2YgdGhlIGJlaGF2aW9yIHlv dSBoYXZlIGltcGxlbWVudGVkLg0KDQpPbmUgUTogSG93IGlzIHRoZSAicG4tcGFyYW09REVGMTIz R0hJSi5vcmcubGlucGhvbmUucGhvbmUudm9pcCZyZW1vdGUiIHVzZWQ/DQpEb2VzIHRoZSBzZXJ2 ZXIgcmVhbGx5IG1ha2UgdXNlIG9mIHRoZSAiJnJlbW90ZSIgc3VmZml4IG9yIGl0IGNhbiBiZSB1 c2VkIGxpa2UgIkRFRjEyM0dISUoub3JnLmxpbnBob25lLnBob25lLioiIHdpdGggdGhlICIqIiBi ZWluZyBhbHdheXMgcmVwbGFjZWQgd2l0aCB0aGUgc2VydmljZT8NCg0KSW4gYW55IGNhc2UsIEkn bSB3aWxsaW5nIHRvIGhlbHAgd2l0aCB3b3JrIG9uIGEgbmV3IFJGQywgYnV0IHNhZGx5IEkgZG9u J3QgaGF2ZSBtdWNoIHRpbWUgZm9yIGl0Lg0KDQpSZWdhcmRpbmcgdGhlIHNjb3BlIG9mIHRoZSB1 cGRhdGVkIFJGQywgSSB0aGluayB0aGVyZSBhcmUgc2V2ZXJhbCBpc3N1ZXMgdGhhdCBzaG91bGQg YmUgYWRkcmVzc2VkOg0KDQoxLiBIb3cgdGhlIFVBIHBhc3NlcyBzZXZlcmFsICJwbi0qIi1zZXRz IGZvciBhIHNpbmdsZSByZWdpc3RyYXRpb24uIFRoZSBzb2x1dGlvbiB5b3UndmUgZG9uZSBvbiBM aW5waG9uZSBzZWVtcyBsaWtlIGEgZ29vZCBhcHByb2FjaCBpZiBiYWNrd2FyZCBjb21wYXRpYmls aXR5IHdpdGggUkZDIDg1OTkgaXMgcmVxdWlyZWQuDQoNCjIuIEhvdyB3b3VsZCB0aGUgcHJveHkg ZGVjaWRlIHdoaWNoIHBuLSotdmFsdWVzLXNldCB0byB1c2UgZm9yIGEgc3BlY2lmaWMgcHVzaCBu b3RpZmljYXRpb24/IEZvciBleGFtcGxlLCBhIG5haXZlIGFwcHJvYWNoIGlzIHRvIHByZS1kZWZp bmUgYSBtYXBwaW5nIGJldHdlZW4gInByLSoiLXNldCBhbmQgU0lQIG1ldGhvZHMgKGkuZS4sIElO VklURSB3aWxsIHVzZSBhICJ2b2lwIiBwYXJhbXMpLg0KDQozLiAobWF5YmUgdW5yZWxhdGVkKSBG b3IgZ29vZCB1c2VyIGV4cGVyaWVuY2UsIHRoZSBjYWxsZXItaWQgc2hvdWxkIGJlIHBhc3NlZCBh bG9uZyB3aXRoIHRoZSB2b2lwIHB1c2ggbm90aWZpY2F0aW9uIHNvIHRoZSBVSSBvZiBpbmNvbWlu ZyBjYWxscyBjYW4gZGlzcGxheSBpdCBpbW1lZGlhdGVseS4NCg0KQlRXLCByZWdhcmRpbmcgdHJp Z2dlcmluZyBvZiByZWdpc3RyYXRpb24gcmVmcmVzaGVzLCBvdXIgaU9TIGRldmVsb3BlcnMgc2F5 IHRoYXQgaW4gb3JkZXIgZm9yIGEgcHVzaCBub3RpZmljYXRpb24gdG8gd29yayByZWxpYWJseSAo aS5lLiwgYXNzdXJlZCB0byBiZSBwcm9jZXNzZWQgYnkgdGhlIGFwcGxpY2F0aW9uIGV2ZW4gaWYg aXQgaXMgdGVybWluYXRlZCksIGl0IG11c3QgaGF2ZSBzb21lIFVJIG5vdGlmaWNhdGlvbi4gVGhp cyBtZWFucyB0aGF0IHRoZSB1c2VyIHdpbGwgYmUgaW5mb3JtZWQgb2YgZWFjaCByZWdpc3RyYXRp b24gcmVmcmVzaC4gSWYgdGhpcyBpcyB0cnVlLCB0aGVuIHRoZSBleHBpcnkgdGltZSBtdXN0IGJl IGtlcHQgdmVyeSBsb25nICh3ZWVrcy9tb250aHMpIGluIGFueSBjYXNlLiBJcyB0aGlzIGFsc28g eW91ciB1bmRlcnN0YW5kaW5nPw0KDQoNClllaG9zaHVhDQoNCg0KT24gU3VuLCBPY3QgMTEsIDIw MjAgYXQgMTE6NDMgUE0gU2ltb24gTU9STEFUIDxzaW1vbi5tb3JsYXRAZ21haWwuY29tPG1haWx0 bzpzaW1vbi5tb3JsYXRAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBZZWhvc2h1YSwNCg0KVGhhbmsg eW91IGZvciBzdGFydGluZyB0aGlzIGRpc2N1c3Npb24uDQpNeSBjb21wYW55IGlzIGRldmVsb3Bp bmcgdGhlIExpbnBob25lIHNvZnR3YXJlIChodHRwczovL2xpbnBob25lLm9yZzxodHRwczovL3By b3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTdmOGFkMTAwLTIxMmExMzQ1LTdmOGE5MTliLTg2 OTJkYzgyODRjYi01YThjMWEyODMzZjVkYjUxJnE9MSZlPWVlYTY5ZmEwLWJkZDgtNGU2NC1iZTFl LWZjOTkyY2UzYzNiMiZ1PWh0dHBzJTNBJTJGJTJGbGlucGhvbmUub3JnJTJGPiksIGFuIGNyb3Nz IHBsYXRmb3JtIG9wZW4tc291cmNlIFNJUCBzb2Z0cGhvbmUgYW5kIFNESy4NClRoZSBsYXN0IHZl cnNpb24gd2UgcHVibGlzaGVkIHdhcyBmb3IgYWRkaW5nIGNvbXBhdGliaWxpdHkgZm9yIGlPUyAx My4gSSBhZG1pdCBpdCB3YXMgYSBuaWdodG1hcmUgdG8gY29tcGx5IHdpdGggdGhlIG5ldyByZXN0 cmljdGlvbnMuDQpGb3IgcHVzaCBub3RpZmljYXRpb25zLCB3ZSBiYXNlZCBvdXIgd29yayBvbiBS RkMgODU5OSAsIGJ1dCBpbmRlZWQgd2UgaGFkIHRvIHNvbWV3aGF0IGV4dGVuZCB0aGUgUkZDIGlu IG9yZGVyIHRvIHRyYW5zbWl0IDIgZGlmZmVyZW50IHB1c2ggbm90aWZpY2F0aW9uIHRva2VuczoN Ci0gdGhlIG9uZSBmb3IgY2FsbHMgKFB1c2hLaXQga2luZCBvZiBub3RpZmljYXRpb25zKQ0KLSB0 aGUgb25lIGZvciBJTXMgKHVzaW5nIFJlbW90ZSBwdXNoIG5vdGlmaWNhdGlvbiBzZXJ2aWNlKS4N Cg0KVG8gYW5zd2VyIHlvdXIgcXVlc3Rpb246IHRoZSAicmVtb3RlIHB1c2ggbm90aWZpY2F0aW9u IiB0b2tlbiBjb3VsZCBhcHBhcmVudGx5IGFsc28gYmUgdXNlZCBmb3IgIkJhY2tncm91bmQgcHVz aCBub3RpZmljYXRpb25zIiAoaHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRp b24vdXNlcm5vdGlmaWNhdGlvbnMvc2V0dGluZ191cF9hX3JlbW90ZV9ub3RpZmljYXRpb25fc2Vy dmVyL3B1c2hpbmdfYmFja2dyb3VuZF91cGRhdGVzX3RvX3lvdXJfYXBwP2xhbmd1YWdlPW9iamMg KSwgd2hpY2ggYXJlIHRoZSBwdXNoIG5vdGlmaWNhdGlvbnMgd2UgbmVlZCB0byByZWZyZXNoIGEg UkVHSVNURVIgdGhhdCBpcyBhYm91dCB0byBleHBpcmUgKG9yIGV4cGlyZWQpLiBTbyB5ZXMgeW91 IG5lZWQgdHdvIGRpZmZlcmVudCBwdXNoIHNlcnZpY2VzIGFuZCB0b2tlbnMuDQoNCkFzIG9mIHRv ZGF5LCB0aGUgTGlucGhvbmUgYXBwIGRvZXNuJ3QgdXNlIHB1c2ggbm90aWZpY2F0aW9ucyBmb3Ig dHJpZ2dlcmluZyBSRUdJU1RFUiByZWZyZXNoZXM6IHdlIHVzZSBhIHZlcnkgbG9uZyBleHBpcmUg dGltZSAob25lIHllYXIpIGluc3RlYWQuIEhvd2V2ZXIgd2Ugd291bGQgcHJlZmVyIHRvIHN3aXRj aCB0byBwdXNoLXRyaWdnZXJlZCBSRUdJU1RFUiByZWZyZXNoIGFzIHNvb24gYXMgcG9zc2libGUu DQoNClRoZSBzeW50YXggZXh0ZW5zaW9uIHdlIG1hZGUgdG8gUkZDODU5OSBpcyBkZXNjcmliZWQg aW4gb3VyIHdpa2k6DQoNCmh0dHBzOi8vd2lraS5saW5waG9uZS5vcmcveHdpa2kvd2lraS9wdWJs aWMvdmlldy9MaWIvR2V0dGluZyUyMHN0YXJ0ZWQvaU9TLyNIVXBkYXRlQ29udGFjdFVSSXBhcmFt ZXRlcnM8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az00MzRmOGE3Ni0xZGVm NDgzMy00MzRmY2FlZC04NjkyZGM4Mjg0Y2ItOTk1YzAzMWJlNWFiMzU4NCZxPTEmZT1lZWE2OWZh MC1iZGQ4LTRlNjQtYmUxZS1mYzk5MmNlM2MzYjImdT1odHRwcyUzQSUyRiUyRndpa2kubGlucGhv bmUub3JnJTJGeHdpa2klMkZ3aWtpJTJGcHVibGljJTJGdmlldyUyRkxpYiUyRkdldHRpbmclMjUy MHN0YXJ0ZWQlMkZpT1MlMkYlMjNIVXBkYXRlQ29udGFjdFVSSXBhcmFtZXRlcnM+DQoNCldlIGRl c2lnbmVkIHRoaXMgc3ludGF4IHRvIGJlIGNvbXBhdGlibGUgd2l0aCBSRkM4NTk5IHN5bnRheC4g VG8gc3VtbWFyaXplLCBoZXJlIGlzIGEgcXVpY2sgZXhhbXBsZSB0byB1bmRlcnN0YW5kIGhvdyB3 ZSBjb252ZXkgcHVzaCB0b2tlbnMgZm9yIGFuIGFwcCB0aGF0IG5lZWRzIHRvIGFkdmVydGlzZSBj YWxscyBhbmQgSU1zOg0KDQpwbi1wcmlkPTAwZmMxM2FkZmY3ODUxMjp2b2lwJmMxMTI5MmY3Yjc0 NzMzZDpyZW1vdGU7cG4tcGFyYW09REVGMTIzR0hJSi5vcmcubGlucGhvbmUucGhvbmUudm9pcCZy ZW1vdGU7cG4tcHJvdmlkZXI9YXBucw0KDQpOb3RpY2UgdGhlICI6dm9pcCIgYW5kICI6cmVtb3Rl IiB0b2tlbiBzdWZmaXhlcywgYW5kIHRoZSAiJiIuDQpXZSBkZWNpZGVkIG5vdCB0byBnbyB3aXRo IGEgbXVsdGlwbGUgY29udGFjdCBoZWFkZXJzIGFwcHJvYWNoLCBlYWNoIGNvbnRhY3QgdXJpIGJl YXJpbmcgYSBwbi1wcmlkIGZvciBlaXRoZXIgdm9pcCBvciByZW1vdGUgc2VydmljZTogdGhlIGZv cmtpbmcgYnkgYSBwcm94eSB0aGF0IGlzIHVuYXdhcmUgb2YgcHVzaCBub3RpZmljYXRpb25zIGNv dWxkIHJlc3VsdCBpbiBJTlZJVEVzIHRvIGJlIGR1cGxpY2F0ZWQuDQoNCldlIGhhZCB0byBnbyBm YXN0IG90aGVyd2lzZSBvdXIgYXBwIHdvdWxkIHN0b3Agd29ya2luZywgYnV0IGZyb20gdGhlIGJl Z2lubmluZyB3ZSBoYXZlIGluIG1pbmQgdGhhdCB0aGlzIGlzc3VlIHNob3VsZCBiZSByYWlzZWQg YW5kIGhvcGVmdWxseSByZXNvbHZlZCBoZXJlIGF0IElFVEYsIHdpdGggb3Igd2l0aG91dCBvdXIg cHJvcG9zZWQgc3ludGF4IGV4dGVuc2lvbi4NCg0KVG9kYXkgZHVlIHRvIEFwcGxlJ3MgcmVjZW50 IGNoYW5nZXMsIGl0IGxvb2tzIGxpa2UgUkZDODU5OSBjYW5ub3QgYmUgdXNlZCAiYXMgaXMiIHRv IG1ha2UgYSBTSVAgYXBwIGZvciBpT1MuIFRoZSByaXNrIHRoYXQgR29vZ2xlIGRvZXMgdGhlIHNh bWUgaW4gbmVhciBmdXR1cmUgZXhpc3RzLg0KQXJlIHRoZXJlIHBlb3BsZSBpbnRlcmVzdGVkIGhl cmUgaW4gY29sbGFib3JhdGluZyB0byBhbiBSRkM4NTk5IHVwZGF0ZSB0byBhZGRyZXNzIHRoaXMg aU9TIHBsYXRmb3JtIGV2b2x1dGlvbiA/IEluIG90aGVyIHdvcmRzLCB3ZSBuZWVkIHRvIHNvbHZl IGhvdyB0byBjb252ZXkgbXVsdGlwbGUgcG4tcHJpZCBhbmQgcG4tcGFyYW0gZm9yIGEgc2FtZSB1 c2VyLWFnZW50IGluc3RhbmNlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNpbW9uDQoNCg0KDQoNCg0K DQoNCkxlIGRpbS4gMTEgb2N0LiAyMDIwIMOgIDE3OjA3LCBZZWhvc2h1YSBHZXYgPHlvc2hpZ2V2 QGdtYWlsLmNvbTxtYWlsdG86eW9zaGlnZXZAZ21haWwuY29tPj4gYSDDqWNyaXQgOg0KSGkgQWxs LA0KDQpJIGhvcGUgaXQgaXMgb2sgdG8gcG9zdCB0aGlzIGhlcmUgYW5kIG5vdCBvbiBzaXAtaW1w bGVtZW50b3JzLi4uDQoNCldlIGFyZSB0cnlpbmcgdG8gaW1wbGVtZW50IFJGQyA4NTk5IGZvciBw ZXJmb3JtaW5nIHB1c2ggbm90aWZpY2F0aW9ucyBmb3IgQXBwbGUgZGV2aWNlcy4NCg0KU3RhcnRp bmcgd2l0aCBpT1MgMTMsIHRoZXJlIGlzIGEgcmVzdHJpY3Rpb24gb24gVm9JUCBwdXNoZXMgWzFd OiAiQXBwcyByZWNlaXZpbmcgVm9JUCBwdXNoIG5vdGlmaWNhdGlvbnMgbXVzdCByZXBvcnQgdGhl IGNhbGwgcXVpY2tseSB0byBDYWxsS2l0LCBzbyBpdCBjYW4gYWxlcnQgdGhlIHVzZXIgdG8gdGhl IHByZXNlbmNlIG9mIHRoZSBpbmNvbWluZyBjYWxsLiINCg0KQWNjb3JkaW5nIHRvIFJGQyA4NTk5 LCBwdXNoZXMgYXJlIHVzZWQgZm9yIChhdCBsZWFzdCkgdHdvIGRpZmZlcmVudCBnb2FsczoNCiAg MSkgSW5pdGlhdGluZyByZWdpc3RyYXRpb24gcmVmcmVzaGVzIChzZWN0aW9uIDUuNSkNCiAgMikg Tm90aWZ5aW5nIG9mIGluY29taW5nIGNhbGxzIChzZWN0aW9uIDUuNi4yKQ0KDQpOb3csIGZvciBh IHJlYXNvbmFibGUgdXNlciBleHBlcmllbmNlLCB0aGUgcmVnaXN0cmF0aW9uIHJlZnJlc2ggcHVz aGVzIG11c3Qgbm90IHRyaWdnZXIgdGhlIFVJIG9mIGluY29taW5nIGNhbGwuDQpIb3dldmVyLCB3 aGVuIGFuIElOVklURSBpcyByZWNlaXZlZCwgdGhlIFVBIG11c3QgYmUgYXdva2VuIGltbWVkaWF0 ZWx5LCB3aGljaCBpcyB0aGUgcHVycG9zZSBvZiBWb0lQIHB1c2guDQoNCkRvZXMgaXQgbWFrZSBz ZW5zZSB0byBtYWtlIGEgZGlmZmVyZW50IHB1c2ggdHlwZSBmb3IgcmVnaXN0cmF0aW9uIHJlZnJl c2ggYW5kIGZvciBpbmNvbWluZyBjYWxscz8NCg0KSSdtIG5vdCBzdXJlIHRoaXMgaXMgcG9zc2li bGUgd2l0aCB0aGUgY3VycmVudCBSRkMgKGFuZCBpdCBpcyBhbHNvIGFnYWluc3QgdGhlIHNwaXJp dCBvZiB0aGUgUkZDKSwgYnV0IEkgY2FuJ3QgdGhpbmsgb2YgYW5vdGhlciB3YXkgYXJvdW5kIGl0 IChiZXNpZGVzIHVzaW5nIHJlZ3VsYXIgcHVzaGVzIGluc3RlYWQgb2YgVm9JUCBwdXNoZXMsIHdo aWNoIG1pZ2h0IGludHJvZHVjZSBkZWxheXMsIG9yIGhhdmluZyBhIHJlZ2lzdHJhdGlvbiB3aXRo IGluZmluaXRlIGV4cGlyYXRpb24gdGhhdCB3aWxsIG5vdCByZXF1aXJlIHJlZnJlc2hlcywgd2hp Y2ggbWlnaHQgbGVhdmUgbWFueSB6b21ieSByZWdpc3RyYXRpb25zKS4NCg0KU2VlIHNvbWUgZGlz Y3Vzc2lvbiBoZXJlOiBbMl0sIFszXS4NCg0KVGhhbmtzLA0KWWVob3NodWENCg0KWzFdIGh0dHBz Oi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9kb2N1bWVudGF0aW9uL3B1c2hraXQvcGtwdXNodHlwZS8x NjE0NDgxLXZvaXANClsyXSBodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20vZm9ydW1zL3RocmVh ZC8xMTc5MzkNClszXSBodHRwczovL3d3dy5saW5waG9uZS5vcmcvbmV3cy9pb3MtMTMtaW1wb3J0 YW50LWNoYW5nZXMtdm9pcGltLWFwcHM8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91 cmw/az1jMzUyZjY3NC05ZGYyMzQzMS1jMzUyYjZlZi04NjkyZGM4Mjg0Y2ItODRkMjRjODM5YTMy ODdjZCZxPTEmZT1lZWE2OWZhMC1iZGQ4LTRlNjQtYmUxZS1mYzk5MmNlM2MzYjImdT1odHRwcyUz QSUyRiUyRnd3dy5saW5waG9uZS5vcmclMkZuZXdzJTJGaW9zLTEzLWltcG9ydGFudC1jaGFuZ2Vz LXZvaXBpbS1hcHBzPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUNCg== --_000_AM0PR07MB3860916523BBCB9EB8614AB1931E0AM0PR07MB3860eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTotd2Via2l0LXN0 YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdGV2ZXIgdGhlIHNvbHV0aW9uIGlzLCBpdCBoYXMg dG8gYmUgYmFja3dhcmQgY29tcGF0aWJsZSwgaW4gb3JkZXIgdG8gbWluaW1pemUgdGhlIGltcGFj dHMgb24gZXhpc3RpbmcgZGVwbG95bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+V2l0aG91dCBoYXZpbmcgdGhvdWdodCB0b28gbXVjaCBhYm91dCBpdCwgb25lIHN0cmFpZ2h0 IGZvcndhcmQgc29sdXRpb24gd291bGQgYmUgdG8gZGVmaW5lIG5ldyBwbi0gcGFyYW1ldGVycyBm b3Igbm9uLVZvSVAgcHVzaCBub3RpZmljYXRpb25zLiBJIGFzc3VtZSB3ZSB3b3VsZCBuZWVkIG5l dyBwbi0gcGFyYW1ldGVycw0KIGZvciBwbi1wYXJhbSBhbmQgcG4tcHJpZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHNpcGNvcmUg Jmx0O3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+WWVo b3NodWEgR2V2PGJyPg0KPGI+U2VudDo8L2I+IHN1bm51bnRhaSAxOC4gbG9rYWt1dXRhIDIwMjAg MTIuMzg8YnI+DQo8Yj5Ubzo8L2I+IFNpbW9uIE1PUkxBVCAmbHQ7c2ltb24ubW9ybGF0QGdtYWls LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNpcGNvcmUgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gUHVzaCBub3RpZmljYXRpb25zIHdp dGggaU9TIDEzIChSRkMgODU5OSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T byB3aGF0IHNob3VsZCBiZSB0aGUgaW5wdXRzIHRvIHRoZSBsb2dpYyB0aGF0IGRlY2lkZXMgd2hp Y2ggcHVzaCB0eXBlIHRvIHVzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldvdWxkIG1ldGhvZCArIG1lZGlhIHR5cGVzIChvZiB0aGUgU0RQIG09 IGxpbmUpIHN1ZmZpY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PciBtYXliZSBqdXN0IHByZS1kZWZpbmVkIHR5cGVzICh2b2ljZSwgdm9pY2Ur dmlkZW8/LCBtZXNzYWdlIGFuZCByZWdpc3Rlcikgd2l0aCBwcmUtZGVmaW5lZCBwcm94eSBsb2dp YyBmb3IgY2hvb3NpbmcgYmV0d2VlbiB0aGVtPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgdGhpbmsgd2UgY291bGQgY29tZSB1cCB3 aXRoIGEgZm9ybWF0IHRoYXQgd2lsbCBiZSBnZW5lcmFsIGFuZCBub3QgQXBwbGUtc3BlY2lmaWM/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0 aGVyZSBpbnRlcmVzdCBpbiB0aGUgZ3JvdXAgZm9yIHRoaXM/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllaG9zaHVhPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgT2N0IDE3LCAy MDIwIGF0IDExOjQ0IEFNIFNpbW9uIE1PUkxBVCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpbW9uLm1v cmxhdEBnbWFpbC5jb20iPnNpbW9uLm1vcmxhdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIFllaG9zaHVhLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0IG1lIGFuc3dlciB5b3VyIHF1ZXN0aW9ucy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBUaGUgcG4t cGFyYW0gaXMgdXNlZCBieSB0aGUgcHJveHkgdG8ga25vdyB0aGUgYXBwbGljYXRpb24gSUQsIHdo aWNoIGlzIG5lY2Vzc2FyeSB0byBrbm93IHdoaWNoIGNyZWRlbnRpYWxzIG9yIFRMUyBjbGllbnQg Y2VydGlmaWNhdGUgdG8gY29ubmVjdCB0byB0aGUgQXBwbGUgcHVzaCBzZXJ2ZXIuIFRoZSB2b2lw JmFtcDtyZW1vdGUmbmJzcDthZHZlcnRpc2UgdGhhdCB0aGUgYXBwIHVuZGVyc3RhbmRzIGJvdGgg dm9pcCBhbmQNCiByZW1vdGUgcHVzaCBub3RpZmljYXRpb25zLCBhbmQgYXMgc3VjaCB0d28gY2Vy dGlmaWNhdGVzL2NyZWRlbnRpYWxzIHNob3VsZCBiZSBhdmFpbGFibGUgdG8gdGhlIHNlcnZlciBm b3IgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+MS4gWWVzLiBJIHNhdyB5b3VyIG90aGVyIHN1Z2dlc3Rpb24sIHdoaWNoIGlzIGluZGVl ZCBtb3JlIHJlYWRhYmxlLCBidXQgYnJlYWtzJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZxdW90OyxzZXJpZjtjb2xv cjpibGFjayI+Y29tcGF0aWJpbGl0eSB3aXRoPC9zcGFuPiZuYnNwO1JGQzg1OTkgLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBUaGUgcHJv eHkgaGFzIGZvcmNpYmx5IHNvbWUgcGxhdGZvcm0gc3BlY2lmaWMgbG9naWMgdG8gaGFuZGxlIHB1 c2ggbm90aWZpY2F0aW9ucy4gSXQgY2Fubm90IGJlIHVuYXdhcmUgdGhhdCBmb3IgQXBwbGUgcGxh dGZvcm0sIHRoZSAmcXVvdDt2b2lwJnF1b3Q7IHR5cGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGNh bGxzLiBOb3RlIHRoYXQgaXQgaXMgbm90IGEgcXVlc3Rpb24gb2YgU0lQIG1ldGhvZCwgYmVjYXVz ZSBTSVAgSU5WSVRFDQogY2FuIGJlIHVzZWQgdG8gZXN0YWJsaXNoIGNoYXQgc2Vzc2lvbnMgd2l0 aCBNU1JQIHByb3RvY29sIGZvciBleGFtcGxlLCBhbmQgaW4gdGhpcyBjYXNlIGEgJnF1b3Q7dm9p cCZxdW90OyB0eXBlIG5vdGlmaWNhdGlvbiBtdXN0IG5vdCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBJdCBjb3VsZCBpbmRl ZWQsIGhvd2V2ZXIgaXQgZGlzY2xvc2VzIGluZm9ybWF0aW9uIHRvIHB1c2ggbm90aWZpY2F0aW9u IHNlcnZlcnMuIEluIGxpbnBob25lLCB3ZSBkbyBub3QgcGFzcyBpdCBmb3IgdGhpcyByZWFzb24u IEluc3RlYWQsIHRoZSBDYWxsS2l0IHZpZXcgaXMgc3Vic2VxdWVudGx5IHVwZGF0ZWQgdG8gZGlz cGxheSB0aGUgY2FsbGVyLWlkIG9uY2UgdGhlIElOVklURSBoYXMgYXJyaXZlZCAod2hpY2gNCiB1 c3VhbGx5IHRha2VzIG5vIG1vcmUgdGhhbiBhIGZldyBzZWNvbmRzKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGJhY2tncm91bmQgdXBk YXRlcyBwdXNoIG5vdGlmaWNhdGlvbnMgKDxhIGhyZWY9Imh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxl LmNvbS9kb2N1bWVudGF0aW9uL3VzZXJub3RpZmljYXRpb25zL3NldHRpbmdfdXBfYV9yZW1vdGVf bm90aWZpY2F0aW9uX3NlcnZlci9wdXNoaW5nX2JhY2tncm91bmRfdXBkYXRlc190b195b3VyX2Fw cD9sYW5ndWFnZT1vYmpjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUu Y29tL2RvY3VtZW50YXRpb24vdXNlcm5vdGlmaWNhdGlvbnMvc2V0dGluZ191cF9hX3JlbW90ZV9u b3RpZmljYXRpb25fc2VydmVyL3B1c2hpbmdfYmFja2dyb3VuZF91cGRhdGVzX3RvX3lvdXJfYXBw P2xhbmd1YWdlPW9iamM8L2E+KQ0KIGFyZSByZWxpYWJsZS4gVGhleSBhcmUgaW5kZWVkIHJhdGUg bGltaXRlZCAoMyBwZXIgaG91cikgd2hpY2ggbWFrZXMgdGhlbSB1bnN1aXRhYmxlIHRvIGFkdmVy dGlzZSBjYWxscyBvciBpbmNvbWluZyBtZXNzYWdlcy4gQnV0IGluIG9yZGVyIHRvIHRyaWdnZXIg YSBSRUdJU1RFUiByZXF1ZXN0IGl0J3MgZ29vZCBlbm91Z2gsIGFuZCB0aGV5IGRvIG5vdCByZXF1 aXJlIHRvIHNob3cgc29tZXRoaW5nIHRvIHRoZSB1c2VyOiB0aGUgd29yayBzaWxlbnRseS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRv IG1ha2UgdGhlIHN5c3RlbSByZWxpYWJsZSwgSSBpbWFnaW5lIHRoZSByZWdpc3RyYXIgY291bGQg c2VuZCBhIGJhY2tncm91bmQgcHVzaCBub3RpZmljYXRpb24gYXQgODAgJSBvZiBleHBpcmUgdGlt ZSwgYW5kIHRoZW4gb25jZSBhIGRheSBkdXJpbmcgYSBndWFyZCBwZXJpb2Qgb2YgWFggZGF5cyBp biBvcmRlciB0byBnaXZlIGFkZGl0aW9uYWwgY2hhbmNlcyBmb3IgYXBwcyB0aGF0IHRlbXBvcmFy aWx5IGhhdmUNCiBubyBsb25nZXIgYWNjZXNzIHRvIHRoZSBuZXR3b3JrIHRvIGZpbmFsbHkgcmVm cmVzaCB0aGVpciByZWdpc3RyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltb248bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUm bmJzcDtsdW4uIDEyIG9jdC4gMjAyMCDDoCZuYnNwOzE2OjQwLCBZZWhvc2h1YSBHZXYgJmx0Ozxh IGhyZWY9Im1haWx0bzp5b3NoaWdldkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55b3NoaWdl dkBnbWFpbC5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBTaW1vbiw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91 ciBkZXRhaWxlZCBleHBsYW5hdGlvbiBvZiB0aGUgYmVoYXZpb3IgeW91IGhhdmUgaW1wbGVtZW50 ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uZSBROiBIb3cgaXMgdGhlICZxdW90O3BuLXBhcmFtPURFRjEyM0dISUoub3JnLmxpbnBob25l LnBob25lLnZvaXAmYW1wO3JlbW90ZSZxdW90OyB1c2VkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB0aGUgc2VydmVyIHJlYWxseSBtYWtl IHVzZSBvZiB0aGUgJnF1b3Q7JmFtcDtyZW1vdGUmcXVvdDsgc3VmZml4IG9yIGl0IGNhbiBiZSB1 c2VkIGxpa2UgJnF1b3Q7REVGMTIzR0hJSi5vcmcubGlucGhvbmUucGhvbmUuKiZxdW90OyB3aXRo Jm5ic3A7dGhlICZxdW90OyomcXVvdDsgYmVpbmcgYWx3YXlzIHJlcGxhY2VkIHdpdGggdGhlIHNl cnZpY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIGFueSBjYXNlLCBJJ20gd2lsbGluZyB0byBoZWxwIHdpdGggd29yayBvbiBhIG5ldyBS RkMsIGJ1dCBzYWRseSBJIGRvbid0IGhhdmUgbXVjaCB0aW1lIGZvciBpdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBz Y29wZSBvZiB0aGUgdXBkYXRlZCBSRkMsIEkgdGhpbmsgdGhlcmUgYXJlIHNldmVyYWwgaXNzdWVz IHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gSG93IHRoZSBVQSBwYXNzZXMgc2V2ZXJhbCAmcXVv dDtwbi0qJnF1b3Q7LXNldHMgZm9yIGEgc2luZ2xlIHJlZ2lzdHJhdGlvbi4gVGhlIHNvbHV0aW9u IHlvdSd2ZSBkb25lIG9uIExpbnBob25lIHNlZW1zIGxpa2UgYSBnb29kIGFwcHJvYWNoIGlmIGJh Y2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBSRkMgODU5OSBpcyByZXF1aXJlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gSG93IHdvdWxk IHRoZSBwcm94eSBkZWNpZGUgd2hpY2ggcG4tKi12YWx1ZXMtc2V0IHRvIHVzZSBmb3IgYSBzcGVj aWZpYyBwdXNoIG5vdGlmaWNhdGlvbj8gRm9yIGV4YW1wbGUsIGEgbmFpdmUgYXBwcm9hY2ggaXMg dG8gcHJlLWRlZmluZSBhIG1hcHBpbmcgYmV0d2VlbiAmcXVvdDtwci0qJnF1b3Q7LXNldCBhbmQg U0lQIG1ldGhvZHMgKGkuZS4sIElOVklURSB3aWxsIHVzZSBhICZxdW90O3ZvaXAmcXVvdDsgcGFy YW1zKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+My4gKG1heWJlIHVucmVsYXRlZCkgRm9yIGdvb2QgdXNlciBleHBlcmllbmNlLCB0aGUgY2Fs bGVyLWlkIHNob3VsZCBiZSBwYXNzZWQgYWxvbmcgd2l0aCB0aGUgdm9pcCBwdXNoIG5vdGlmaWNh dGlvbiBzbyB0aGUgVUkgb2YgaW5jb21pbmcgY2FsbHMgY2FuIGRpc3BsYXkgaXQgaW1tZWRpYXRl bHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJUVywgcmVnYXJkaW5nIHRyaWdnZXJpbmcmbmJzcDtvZiByZWdpc3RyYXRpb24gcmVmcmVzaGVz LCBvdXIgaU9TIGRldmVsb3BlcnMgc2F5IHRoYXQgaW4gb3JkZXIgZm9yIGEgcHVzaCBub3RpZmlj YXRpb24gdG8gd29yayByZWxpYWJseSAoaS5lLiwgYXNzdXJlZCB0byBiZSBwcm9jZXNzZWQgYnkg dGhlIGFwcGxpY2F0aW9uIGV2ZW4gaWYgaXQgaXMgdGVybWluYXRlZCksIGl0IG11c3QgaGF2ZSBz b21lIFVJIG5vdGlmaWNhdGlvbi4NCiBUaGlzIG1lYW5zIHRoYXQgdGhlIHVzZXIgd2lsbCBiZSBp bmZvcm1lZCBvZiBlYWNoIHJlZ2lzdHJhdGlvbiByZWZyZXNoLiBJZiB0aGlzIGlzIHRydWUsIHRo ZW4gdGhlIGV4cGlyeSB0aW1lIG11c3QgYmUga2VwdCB2ZXJ5IGxvbmcgKHdlZWtzL21vbnRocykg aW4gYW55IGNhc2UuIElzIHRoaXMgYWxzbyB5b3VyIHVuZGVyc3RhbmRpbmc/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVob3NodWE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBT dW4sIE9jdCAxMSwgMjAyMCBhdCAxMTo0MyBQTSBTaW1vbiBNT1JMQVQgJmx0OzxhIGhyZWY9Im1h aWx0bzpzaW1vbi5tb3JsYXRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2ltb24ubW9ybGF0 QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkmbmJzcDtZZWhvc2h1YSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciBzdGFydGluZyB0aGlzIGRp c2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NeSBjb21wYW55IGlzIGRldmVsb3BpbmcgdGhlIExpbnBob25lIHNvZnR3YXJlICg8YSBo cmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTdmOGFkMTAwLTIxMmEx MzQ1LTdmOGE5MTliLTg2OTJkYzgyODRjYi01YThjMWEyODMzZjVkYjUxJmFtcDtxPTEmYW1wO2U9 ZWVhNjlmYTAtYmRkOC00ZTY0LWJlMWUtZmM5OTJjZTNjM2IyJmFtcDt1PWh0dHBzJTNBJTJGJTJG bGlucGhvbmUub3JnJTJGIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9saW5waG9uZS5vcmc8L2E+ KSwNCiBhbiBjcm9zcyBwbGF0Zm9ybSBvcGVuLXNvdXJjZSBTSVAgc29mdHBob25lIGFuZCBTREsu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg bGFzdCB2ZXJzaW9uIHdlIHB1Ymxpc2hlZCB3YXMgZm9yIGFkZGluZyBjb21wYXRpYmlsaXR5IGZv ciBpT1MgMTMuIEkgYWRtaXQgaXQgd2FzIGEgbmlnaHRtYXJlIHRvIGNvbXBseSB3aXRoIHRoZSBu ZXcgcmVzdHJpY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rm9yIHB1c2ggbm90aWZpY2F0aW9ucywgd2UgYmFzZWQgb3VyIHdvcmsgb24g UkZDIDg1OTkgLCBidXQgaW5kZWVkIHdlIGhhZCB0byBzb21ld2hhdCBleHRlbmQgdGhlIFJGQyBp biBvcmRlciB0byB0cmFuc21pdCAyIGRpZmZlcmVudCBwdXNoIG5vdGlmaWNhdGlvbiB0b2tlbnM6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHRo ZSBvbmUgZm9yIGNhbGxzIChQdXNoS2l0IGtpbmQgb2Ygbm90aWZpY2F0aW9ucyk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gdGhlIG9uZSBmb3Ig SU1zICh1c2luZyBSZW1vdGUgcHVzaCBub3RpZmljYXRpb24gc2VydmljZSkuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGFuc3dl ciB5b3VyIHF1ZXN0aW9uOiB0aGUgJnF1b3Q7cmVtb3RlIHB1c2ggbm90aWZpY2F0aW9uJnF1b3Q7 IHRva2VuIGNvdWxkIGFwcGFyZW50bHkgYWxzbyBiZSB1c2VkIGZvciAmcXVvdDtCYWNrZ3JvdW5k IHB1c2ggbm90aWZpY2F0aW9ucyZxdW90OyAoPGEgaHJlZj0iaHR0cHM6Ly9kZXZlbG9wZXIuYXBw bGUuY29tL2RvY3VtZW50YXRpb24vdXNlcm5vdGlmaWNhdGlvbnMvc2V0dGluZ191cF9hX3JlbW90 ZV9ub3RpZmljYXRpb25fc2VydmVyL3B1c2hpbmdfYmFja2dyb3VuZF91cGRhdGVzX3RvX3lvdXJf YXBwP2xhbmd1YWdlPW9iamMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RldmVsb3Blci5hcHBs ZS5jb20vZG9jdW1lbnRhdGlvbi91c2Vybm90aWZpY2F0aW9ucy9zZXR0aW5nX3VwX2FfcmVtb3Rl X25vdGlmaWNhdGlvbl9zZXJ2ZXIvcHVzaGluZ19iYWNrZ3JvdW5kX3VwZGF0ZXNfdG9feW91cl9h cHA/bGFuZ3VhZ2U9b2JqYzwvYT4NCiApLCB3aGljaCBhcmUgdGhlIHB1c2ggbm90aWZpY2F0aW9u cyB3ZSBuZWVkIHRvIHJlZnJlc2ggYSBSRUdJU1RFUiB0aGF0IGlzIGFib3V0IHRvIGV4cGlyZSAo b3IgZXhwaXJlZCkuIFNvIHllcyB5b3UgbmVlZCB0d28gZGlmZmVyZW50IHB1c2ggc2VydmljZXMg YW5kIHRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXMgb2YgdG9kYXksIHRoZSBMaW5waG9uZSBhcHAgZG9lc24ndCB1c2UgcHVzaCBu b3RpZmljYXRpb25zIGZvciB0cmlnZ2VyaW5nIFJFR0lTVEVSIHJlZnJlc2hlczogd2UgdXNlIGEg dmVyeSBsb25nIGV4cGlyZSB0aW1lIChvbmUgeWVhcikgaW5zdGVhZC4gSG93ZXZlciB3ZSB3b3Vs ZCBwcmVmZXIgdG8gc3dpdGNoIHRvIHB1c2gtdHJpZ2dlcmVkIFJFR0lTVEVSIHJlZnJlc2ggYXMg c29vbiBhcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIHN5bnRheCBleHRlbnNpb24gd2UgbWFkZSB0byBSRkM4NTk5IGlz IGRlc2NyaWJlZCBpbiBvdXIgd2lraTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNv bS92MS91cmw/az00MzRmOGE3Ni0xZGVmNDgzMy00MzRmY2FlZC04NjkyZGM4Mjg0Y2ItOTk1YzAz MWJlNWFiMzU4NCZhbXA7cT0xJmFtcDtlPWVlYTY5ZmEwLWJkZDgtNGU2NC1iZTFlLWZjOTkyY2Uz YzNiMiZhbXA7dT1odHRwcyUzQSUyRiUyRndpa2kubGlucGhvbmUub3JnJTJGeHdpa2klMkZ3aWtp JTJGcHVibGljJTJGdmlldyUyRkxpYiUyRkdldHRpbmclMjUyMHN0YXJ0ZWQlMkZpT1MlMkYlMjNI VXBkYXRlQ29udGFjdFVSSXBhcmFtZXRlcnMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3dpa2ku bGlucGhvbmUub3JnL3h3aWtpL3dpa2kvcHVibGljL3ZpZXcvTGliL0dldHRpbmclMjBzdGFydGVk L2lPUy8jSFVwZGF0ZUNvbnRhY3RVUklwYXJhbWV0ZXJzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBkZXNpZ25lZCB0aGlzIHN5bnRh eCB0byBiZSBjb21wYXRpYmxlIHdpdGggUkZDODU5OSBzeW50YXguIFRvIHN1bW1hcml6ZSwgaGVy ZSBpcyBhIHF1aWNrIGV4YW1wbGUgdG8gdW5kZXJzdGFuZCBob3cgd2UgY29udmV5IHB1c2ggdG9r ZW5zIGZvciBhbiBhcHAgdGhhdCBuZWVkcyB0byBhZHZlcnRpc2UgY2FsbHMgYW5kIElNczo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+cG4tcHJpZD0wMGZjMTNhZGZmNzg1MTI6dm9pcCZh bXA7YzExMjkyZjdiNzQ3MzNkOnJlbW90ZTtwbi1wYXJhbT1ERUYxMjNHSElKLm9yZy5saW5waG9u ZS5waG9uZS52b2lwJmFtcDtyZW1vdGU7cG4tcHJvdmlkZXI9YXBuczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzMzMzMzMyI+Tm90aWNlIHRoZSAmcXVvdDs6dm9pcCZxdW90OyBhbmQgJnF1 b3Q7OnJlbW90ZSZxdW90OyB0b2tlbiBzdWZmaXhlcywgYW5kIHRoZSAmcXVvdDsmYW1wOyZxdW90 Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5XZSBkZWNpZGVkIG5vdCB0byBn byB3aXRoIGEgbXVsdGlwbGUgY29udGFjdCBoZWFkZXJzIGFwcHJvYWNoLCBlYWNoIGNvbnRhY3Qg dXJpIGJlYXJpbmcgYSBwbi1wcmlkIGZvciBlaXRoZXIgdm9pcCBvciByZW1vdGUgc2VydmljZTog dGhlIGZvcmtpbmcgYnkgYSBwcm94eQ0KIHRoYXQgaXMgdW5hd2FyZSBvZiBwdXNoIG5vdGlmaWNh dGlvbnMgY291bGQgcmVzdWx0IGluIElOVklURXMgdG8gYmUgZHVwbGljYXRlZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPldlIGhhZCB0byBnbyBmYXN0IG90aGVyd2lzZSBv dXIgYXBwIHdvdWxkIHN0b3Agd29ya2luZywgYnV0IGZyb20mbmJzcDt0aGUgYmVnaW5uaW5nIHdl IGhhdmUgaW4gbWluZCB0aGF0IHRoaXMgaXNzdWUgc2hvdWxkIGJlIHJhaXNlZCBhbmQgaG9wZWZ1 bGx5IHJlc29sdmVkIGhlcmUNCiBhdCBJRVRGLCB3aXRoIG9yIHdpdGhvdXQgb3VyIHByb3Bvc2Vk IHN5bnRheCBleHRlbnNpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRvZGF5IGR1ZSB0byBBcHBsZSdzIHJlY2VudCBjaGFuZ2VzLCBpdCBs b29rcyBsaWtlIFJGQzg1OTkgY2Fubm90IGJlIHVzZWQgJnF1b3Q7YXMgaXMmcXVvdDsgdG8gbWFr ZSBhIFNJUCBhcHAgZm9yIGlPUy4gVGhlIHJpc2sgdGhhdCBHb29nbGUgZG9lcyB0aGUgc2FtZSBp biBuZWFyIGZ1dHVyZSBleGlzdHMuPGJyPg0KQXJlIHRoZXJlIHBlb3BsZSBpbnRlcmVzdGVkIGhl cmUgaW4gY29sbGFib3JhdGluZyB0byBhbiBSRkM4NTk5IHVwZGF0ZSB0byBhZGRyZXNzIHRoaXMg aU9TIHBsYXRmb3JtIGV2b2x1dGlvbiA/IEluIG90aGVyIHdvcmRzLCB3ZSBuZWVkIHRvIHNvbHZl IGhvdyB0byBjb252ZXkgbXVsdGlwbGUgcG4tcHJpZCBhbmQgcG4tcGFyYW0gZm9yIGEgc2FtZSB1 c2VyLWFnZW50IGluc3RhbmNlLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQo8YnI+DQpT aW1vbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSZuYnNwO2RpbS4gMTEgb2N0 LiAyMDIwIMOgJm5ic3A7MTc6MDcsIFllaG9zaHVhIEdldiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlv c2hpZ2V2QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlvc2hpZ2V2QGdtYWlsLmNvbTwvYT4m Z3Q7IGEgw6ljcml0Jm5ic3A7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaG9wZSBpdCBpcyBvayB0byZuYnNwO3Bvc3QgdGhp cyBoZXJlIGFuZCBub3Qgb24gc2lwLWltcGxlbWVudG9ycy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgdHJ5aW5nIHRvIGltcGxl bWVudCBSRkMgODU5OSBmb3IgcGVyZm9ybWluZyBwdXNoIG5vdGlmaWNhdGlvbnMgZm9yIEFwcGxl IGRldmljZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlN0YXJ0aW5nIHdpdGggaU9TIDEzLCB0aGVyZSBpcyBhIHJlc3RyaWN0aW9uJm5ic3A7 b24gVm9JUCBwdXNoZXMgWzFdOiAmcXVvdDtBcHBzIHJlY2VpdmluZyBWb0lQIHB1c2ggbm90aWZp Y2F0aW9ucw0KPHU+bXVzdCByZXBvcnQgdGhlIGNhbGwgcXVpY2tseSB0byBDYWxsS2l0LCBzbyBp dCBjYW4gYWxlcnQgdGhlIHVzZXI8L3U+IHRvIHRoZSBwcmVzZW5jZSBvZiB0aGUgaW5jb21pbmcg Y2FsbC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWNjb3JkaW5nIHRvIFJGQyA4NTk5LCBwdXNoZXMgYXJlIHVzZWQgZm9yIChhdCBs ZWFzdCkgdHdvIGRpZmZlcmVudCZuYnNwO2dvYWxzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDEpIEluaXRpYXRpbmcgcmVnaXN0cmF0 aW9uIHJlZnJlc2hlcyAoc2VjdGlvbiA1LjUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMikgTm90aWZ5aW5nIG9mIGluY29taW5nIGNh bGxzIChzZWN0aW9uIDUuNi4yKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Ob3csIGZvciBhIHJlYXNvbmFibGUmbmJzcDt1c2VyIGV4cGVyaWVu Y2UsIHRoZSByZWdpc3RyYXRpb24gcmVmcmVzaCBwdXNoZXMgbXVzdCBub3QgdHJpZ2dlciB0aGUg VUkgb2YgaW5jb21pbmcgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHdoZW4gYW4gSU5WSVRFIGlzIHJlY2VpdmVkLCB0aGUg VUEgbXVzdCBiZSBhd29rZW4gaW1tZWRpYXRlbHksIHdoaWNoIGlzIHRoZSBwdXJwb3NlJm5ic3A7 b2YgVm9JUCBwdXNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Eb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gbWFrZSBhIGRpZmZlcmVudCBwdXNoIHR5 cGUgZm9yIHJlZ2lzdHJhdGlvbiByZWZyZXNoIGFuZCBmb3IgaW5jb21pbmcgY2FsbHM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3Qg c3VyZSB0aGlzIGlzIHBvc3NpYmxlIHdpdGggdGhlIGN1cnJlbnQgUkZDIChhbmQgaXQgaXMgYWxz byBhZ2FpbnN0IHRoZSBzcGlyaXQgb2YgdGhlIFJGQyksIGJ1dCBJIGNhbid0IHRoaW5rIG9mIGFu b3RoZXIgd2F5IGFyb3VuZCBpdCAoYmVzaWRlcyB1c2luZyByZWd1bGFyIHB1c2hlcyBpbnN0ZWFk IG9mIFZvSVAgcHVzaGVzLCB3aGljaCBtaWdodCBpbnRyb2R1Y2UgZGVsYXlzLCBvciBoYXZpbmcN CiBhIHJlZ2lzdHJhdGlvbiB3aXRoIGluZmluaXRlIGV4cGlyYXRpb24gdGhhdCZuYnNwO3dpbGwg bm90IHJlcXVpcmUgcmVmcmVzaGVzLCB3aGljaCBtaWdodCBsZWF2ZSBtYW55IHpvbWJ5IHJlZ2lz dHJhdGlvbnMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TZWUgc29tZSBkaXNjdXNzaW9uIGhlcmU6IFsyXSwgWzNdLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWhvc2h1YTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJz cDs8YSBocmVmPSJodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20vZG9jdW1lbnRhdGlvbi9wdXNo a2l0L3BrcHVzaHR5cGUvMTYxNDQ4MS12b2lwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kZXZl bG9wZXIuYXBwbGUuY29tL2RvY3VtZW50YXRpb24vcHVzaGtpdC9wa3B1c2h0eXBlLzE2MTQ0ODEt dm9pcDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlsyXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9mb3J1bXMv dGhyZWFkLzExNzkzOSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNv bS9mb3J1bXMvdGhyZWFkLzExNzkzOTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlszXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIu ZmlyZWV5ZS5jb20vdjEvdXJsP2s9YzM1MmY2NzQtOWRmMjM0MzEtYzM1MmI2ZWYtODY5MmRjODI4 NGNiLTg0ZDI0YzgzOWEzMjg3Y2QmYW1wO3E9MSZhbXA7ZT1lZWE2OWZhMC1iZGQ4LTRlNjQtYmUx ZS1mYzk5MmNlM2MzYjImYW1wO3U9aHR0cHMlM0ElMkYlMkZ3d3cubGlucGhvbmUub3JnJTJGbmV3 cyUyRmlvcy0xMy1pbXBvcnRhbnQtY2hhbmdlcy12b2lwaW0tYXBwcyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmxpbnBob25lLm9yZy9uZXdzL2lvcy0xMy1pbXBvcnRhbnQtY2hhbmdlcy12 b2lwaW0tYXBwczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29y ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM0PR07MB3860916523BBCB9EB8614AB1931E0AM0PR07MB3860eurp_--