From nobody Mon Nov 1 06:29:28 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772103A12F4 for ; Mon, 1 Nov 2021 06:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 ek28EShWNsOF for ; Mon, 1 Nov 2021 06:29:22 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10072.outbound.protection.outlook.com [40.107.1.72]) (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 9D60E3A1267 for ; Mon, 1 Nov 2021 06:29:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B2NuUK4vzw9ZMf1xzDD/6YHftzwA44zDL++otEvbOYCzMGTY5pSQI4dgXULzOBCHgtJ5iM8haXNMCUrK43xOgfHIcGLXk4Nrylk/Hr+CJPqvg4pwaFNGb92Hw3c5GyX6isemLVYlUsScwj5a8pB8fgupSrNhGYDKPaWY/w8PJjMf8tWvt79BCjKisC9jQq9d1W9fiKjBR5Rr3aCgVyWnzEjb8eepCq8P3H/fdTY7fnIIL2d15SH7T7buU51xiDMpX/+8VQBF+MjWIjP+gRdoQYWU1GwUCBPelY5oNYv4CLfk4E5dh7AAw4xsemH2e9TJ2FtHDEzC9FwlbK+LSH0IEA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8IWLZkQ0GpCJjWF/QJWqceqEzp/elAH32Hq8l7Txcs4=; b=gqeojH/WDZHUnm664V2zpQvbjwyzHFNH1KinFd9x5dnwxj1JQ5+oP5NLWBRHAA94MCwz7nWAbMWBvE7/wEc/MnCU1uGBlzQxkVSLzn6DXySbxV8DMTTiLyli0t8//RGdP8k8qjf/dhAJpqSp/xDuVpz98VkxJ2oqf2G5pH2rWZy8PyzuJTs7neGx2qejyAVLyk31ddhOYGm+Ex5WiW5s8eFFeKGK3PJHv7o6hTcnVxPRmULRT/Tm+USV1Yv/n+bTY7+WolW0JdtFrbbBwo1DHhoyCGJvuQbfsBMFkjMkPOALuBT0cO/PiO7ZaVa7TLpzyELVHrEGxwjKV8LuZqebxQ== 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=8IWLZkQ0GpCJjWF/QJWqceqEzp/elAH32Hq8l7Txcs4=; b=b485BuNUyWVEh77dNx44ll3MRCmgnjcfLPTC48LYMLvNP7RWh+NrPnZ85lr0SF7UpgNY/94RRi/ZL8G/+i3nZqhLlV6CgkiWR2JtomZoHiTH/NXvyH6ixoJ+UYpfJ7jCMwzd+pRFlc3hzNoHuDehUzMLmtUDfglSONdcvV8xYaY= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR07MB3097.eurprd07.prod.outlook.com (2603:10a6:7:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.4; Mon, 1 Nov 2021 13:29:17 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.009; Mon, 1 Nov 2021 13:29:17 +0000 From: Christer Holmberg To: Justin Uberti CC: Roman Shpount , Justin Uberti , RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B30= Date: Mon, 1 Nov 2021 13:29:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 039f4edd-ff8d-7c7b-c1d3-98743c282fe1 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bae664a6-a124-4f79-eea0-08d99d3b9afd x-ms-traffictypediagnostic: HE1PR07MB3097: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KgtMtFDufiAzCAagpEL1Riq/dA6u8tptUovtTWVspdnakG5g1mEApt6GP7XpQTFHULm2KHd0B6hPjgH4IlutgLE3ylpLQ93NNtVDskhAtJfhsZlTo8lMhAc39+vIjqoQe63MBkIO5D658NXJL1rn9z28/ydn7mUkfwaRRqAc+nBXNGDgzGMc+1wEAMDr9230geodtar9xxapWGUlaDjk1kFCb30ENQKitPlUXgEKhkvs1f6WNu9qVIM2ElJw13oH3qKEmxo9aWBVcwg230DoeeR85trAHu0E/2LGaovZRImzisrqM+Pj2POZiaNY0J+ux7IGuq3EI+TcPhc8DdIdEpHPN0DqBstAQrMPVDv9SfKhsBbv2hx5ACFn/JeBQKvk8KAwrHQaeWjY4wWxBq024jY1NqbQEimOIvI2ps+9WyDLXNdZTgcGbP6anpmYIVUTzj3CcLA4DSGZ2aiFx1J2yXU/RUYmbXEzAFuXLyKrWXx3YIHRZ3JiQDgrKDqCfYu8U60kDNICVP0j31j7TJy+emJdFgHnsllr9bU+Puq3tORJ7BKStimfc4qrBR1P51NnWL4Q9S95bZUMIQwC9wgRJoGk4+fLSLifY9SH+5SfdD8KGpduRteAE7+hQN7wqipCV/eSsKdYLE2ADKTkeS1t5Bih0cAmKUwisXpX7VpHD3gK7E1Uj7H4IzZviEMkWh7g018rfozd9CnK51diXrCnwg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(76116006)(8936002)(5660300002)(82960400001)(6506007)(8676002)(508600001)(55016002)(186003)(38100700002)(54906003)(64756008)(316002)(52536014)(38070700005)(2906002)(66556008)(66476007)(86362001)(7696005)(6916009)(83380400001)(19627405001)(122000001)(66446008)(33656002)(71200400001)(66946007)(4326008)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?uZWMfXyLfu89emQGms2tRtgVQNFwXa2NVUrOV99VaPXSv5nAYPxV6PTV?= =?Windows-1252?Q?zBN4CAYs9K1LEk9Wr99NQoab2aZfPrWEiApKEuwf1PklG+VC3bCosSkz?= =?Windows-1252?Q?N0zLGGC+dWn8dDX3T+oZDdPOuQz3AjvD3Jp4w2oHduP6Nw0SinznTw9Q?= =?Windows-1252?Q?qfnL1UsrFWlU0D8gmLZjr588t8hNHp69dU95GTZPX1XTGMjWgKMmM5EF?= =?Windows-1252?Q?xdzkitmaqJBL8HYgPg6ktMBdLWueWztnxG4xDnCVrM96SuVAR+3SC54P?= =?Windows-1252?Q?vHiPk9OcKJqfkWG7zS3TTW9OoABJXf5FizpG8Ug7fzjfeQte85izDI/+?= =?Windows-1252?Q?OUvSs+UQib9yNzyN4D8pQwPKe4UZKHc+WYGKhYLwlYsQjUlGq+2mm2cF?= =?Windows-1252?Q?mM7bo4gnrYaYllXNFv9csG3El8TYDkdDeWNljSTjZKea7hBs1jIWhYwe?= =?Windows-1252?Q?ofRsKuP7VNNIZLZ6BmZUPrkNv0Yx6cQZJC7odv+M08QOuqkQyNClviXm?= =?Windows-1252?Q?YFdB4GQy/pjA9bCJawawfo1TOeJkFkrmW/xHyjS2fp698DRZKtJsYWAD?= =?Windows-1252?Q?rRCNJVfwaLNfUgtb1SNBFo6qS6voQA1xmHfXueMKXJj2RXFGxcI9iJCe?= =?Windows-1252?Q?boYN+fsf6wdlFbzSyUB62IvjKyYKNvrbSDK2p0OadSWrRDuWEBuxOybP?= =?Windows-1252?Q?wHZS6EZ3eICx/qiA6Bq/Q3uq1mQ1a44CTDUvCDmOACINyIHiKrpVzJoa?= =?Windows-1252?Q?UGUpjcCfKtJOO3NAL7UD851Jxygykxgh6m7mREBZgo4O+3aHpfDjXSeE?= =?Windows-1252?Q?VxXdPs+S+xUC7sv5nF8dkBFE+xbLQdipYpy4FmwSt5eDO5Uq7J8YKED9?= =?Windows-1252?Q?UoimmZsXD1bEcCsmJvTB5jTvhJGT0hjpl/rYmODvwFqljjKk5+nbYP+p?= =?Windows-1252?Q?Rq7J3RAhb2SP2kGLk72rNW0h9M0Fdnu5yOOICsN3YGzG+qRTpbNJNZ1n?= =?Windows-1252?Q?wCnTlSmSfqTEliLQ31pZm/A6FsXrwn1j6oKSFi2YKIcNOLFPfHgIQaG6?= =?Windows-1252?Q?qcl9ZbZP6E/Pp5ANk/UCbTmhXzG7mLyL9ttTVx1isbaJtYUK8Ipv4QCX?= =?Windows-1252?Q?OFdY0ON9f2BnZyxgEByxaSamB38+LxQoUS9foA/A1WVJJHSHB87HIz4g?= =?Windows-1252?Q?lmTGHXll9kFPydGwuV0MYnPqiQvUcKuPgnbdw9mYCb9xMg1PtxSh8nGz?= =?Windows-1252?Q?/8bMNZo6p7oB4nxPDBLu40AHDMOtOFvzVyzepvPNA4342amZucoTXjbn?= =?Windows-1252?Q?2nMb3YZHKhbbqzu+ExpMaDOXXeuuSIZbyIIQ9UA0ElPO/BUMzs9ypWaR?= =?Windows-1252?Q?73RAyYZ9FWm5eGaOdUEkBqeNQNownQc+f9FuAckC2dsM+7lskxQFuvGx?= =?Windows-1252?Q?e8yhN9wMnEHRAHzxDqdLU6P/ixhWMMqd48keeCsWGY9iI9Rsooo2H8Wc?= =?Windows-1252?Q?2JVBYYxZbXNDvuqm5THsc+GxKxW53yIiB9d2B+LeW1MveYWfytmC++5a?= =?Windows-1252?Q?6GJDtQA57SittIfrg+td8Tb4vTetxVOSugL4BKlqshyiD7Qan0WaHgg9?= =?Windows-1252?Q?+KxM76Fve8WBwrjPbPbpnB9vyVbjQEtLo/t0P3LQG9i4u15oIZtl7uhC?= =?Windows-1252?Q?fqZAigujzorp0ODamOpR7389kp5rDA7/O72FGMHdmEjVqVji8OU4B/Ud?= =?Windows-1252?Q?WS5dOC9jF+sN441z8tqsTJvoPc5xx0OazIvgVafNiTo+uzv8QA4bcBxi?= =?Windows-1252?Q?/WByBn7v3NeaXQgLd45gCwYTpQeiqFAE2nD/mCXTC61iM03RnLl+RXCc?= =?Windows-1252?Q?7bm3Kfztwtnbjw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4441B47E50789CBBE1BCB3F5938A9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bae664a6-a124-4f79-eea0-08d99d3b9afd X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2021 13:29:17.6691 (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: psZ8QXNiaIXisN7BKsyMXL+0D/xtchFUcxU2TZOmypf+lo2aonLxu5j+ojTZEFZN++cGjuHHkGwExbuNDl0nlQeNL4efh389v88c83rEByk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3097 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 13:29:27 -0000 --_000_HE1PR07MB4441B47E50789CBBE1BCB3F5938A9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >1. Make subsequent offers valid initial offers. This means adding some lan= guage explaining how the endpoint processing initial offer can detect that = m=3D lines cannot be unbundled. Even if we add this language it will have b= ackwards compatibility issues with anything that has not implemented it. I don=92t agree with that suggestion. Because, in that case we could have d= one it from the beginning, as a general rule, without using port zero. But = there were reason we chose not to allow shared addresses (with non-zero por= t values) in initial offers. >We did come up with a=3Dbundle-only mechanism to ensure backwards compatib= ility, and none of us want to revisit that decision. However, I do think th= at it would be consistent with Postel's Principle for the > answerer to properly handle the case where a 3PCC offer ends up with a sh= ared address, rather than failing simply because the offer does not appear = to be an initial offer. I don't agree with that. Again, that is why we did not define it to begin w= ith. When this was discussed, people indicated that even in cases where an = answerer would accept the offer, it is not possible to predict how the answ= er would look like. Also, keep in mind that the answerer may not know that the offer is for 3PC= C. It may just see an initial offer. >2. Make endpoints generate subsequent offers that are valid initial offers= in 3PCC scenarios. This is what draft 8843 bis does. Correct. However, keep in mind that it is not only about how to encode the port numb= ers and bundle-only attributes. Sending an initial offer also comes with a = set of procedures. Some of those (e.g., ICE) I assume you will have to do = anyway, as the remote endpoint changes. >I would even be fine with webrtc endpoint not doing anything and adding a = note to JSEP telling the 3PCC application to "fix" the offer and add m=3D p= ort zero and bundle-only attributes when it is sending subsequent offers as= initial offers to a new end point. I would be fine adding such text to JSEP. It could be an additional sentenc= e to the existing text. (However, I still would not say =93sending subsequent offers as initial off= ers=94. I would say =93create and send an initial offer based on a received= subsequent offer=94, or something like that.) >This might turn out to be the simplest option, but as noted before, it wil= l require several SDP changes and will be somewhat error-prone as a result = (assuming anyone implements this at all). Accordingly I think #1 above is t= he least bad choice. I don't agree with suddenly allowing (read: specify in the standard that it= is ok) something that we agreed that we are not going to do more or less f= rom day one, and that has never considered later during the process either. --- The PROBLEM is that we have two endpoints, where one sends a subsequent off= er, and the other one expects an initial offer. What do you normally do whe= n you have that kind of problem? You use an SBC/B2BUA. In this case that SB= C/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simp= ly add a note somewhere (in 8843bis and/or 8829bis) which describes the iss= ue and says that the 3GPP controller needs to modify the offer accordingly. Regards, Christer --_000_HE1PR07MB4441B47E50789CBBE1BCB3F5938A9HE1PR07MB4441eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,
 

>1. Make subsequent offers= valid initial offers. This means adding some language explaining how the e= ndpoint processing initial offer can detect that m=3D lines cannot be = unbundled. Even if we add this language it will have backwards compatibility issues with anything that has not implemented= it.

 

I don=92t agree with that sug= gestion. Because, in that case we could have done it from the beginning, as= a general rule, without using port zero. But there were reason we chose no= t to allow shared addresses (with non-zero port values) in initial offers.


>We did come up with a=3Dbundle-only mechanism to ensure backwards = compatibility, and none of us want to revisit that decision. However, I do = think that it would be consistent with Postel's Principle for the
> answerer to properly handle the case where a 3PCC offer ends up w= ith a shared address, rather than failing simply because the offer does not= appear to be an initial offer.

I don't agree with that. Again, that is why we did not define it to be= gin with. When this was discussed, people indicated that even in cases wher= e an answerer would accept the offer, it is not possible to predict how the= answer would look like.

Also, keep in mind that the answerer may not know that the offer is fo= r 3PCC. It may just see an initial offer.

 

>2. Make endpoints generat= e subsequent offers that are valid initial offers in 3PCC scenarios. This i= s what draft 8843 bis does.

 

Correct.

 

However, keep in mind that it= is not only about how to encode the port numbers and bundle-only attribute= s. Sending an initial offer also comes with a set of procedures. Some of th= ose (e.g., ICE)  I assume you will have to do anyway, as the remote endpoint changes.

 

>I would even be fine with= webrtc endpoint not doing anything and adding a note to JSEP telling the 3= PCC application to "fix" the offer and add m=3D port zero and bun= dle-only attributes when it is sending subsequent offers as initial offers to a new end point.

 

I would be fine adding such t= ext to JSEP. It could be an additional sentence to the existing text.

 

(However, I still would not s= ay =93sending subsequent offers as initial offers=94. I would say =93create= and send an initial offer based on a received subsequent offer=94, or some= thing like that.)


>This might turn out to be the simplest option, but as noted before= , it will require several SDP changes and will be somewhat error-prone as a= result (assuming anyone implements this at all). Accordingly I think #1 ab= ove is the least bad choice.

I don't agree with suddenly allowing (read: specify in the standard th= at it is ok) something that we agreed that we are not going to do more or l= ess from day one, and that has never considered later during the process ei= ther.

---

The PROBLEM is that we have two endpoints, where one sends a subsequen= t offer, and the other one expects an initial offer. What do you normally d= o when you have that kind of problem? You use an SBC/B2BUA. In this case th= at SBC/B2BUA would be the 3PCC controller.

So, my suggestion would be to remove the SHOULD text from 8843bis, and= simply add a note somewhere (in 8843bis and/or 8829bis) which describes th= e issue and says that the 3GPP controller needs to modify the offer accordi= ngly.

Regards,

Christer

--_000_HE1PR07MB4441B47E50789CBBE1BCB3F5938A9HE1PR07MB4441eurp_-- From nobody Mon Nov 1 11:53:41 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242C13A275D for ; Mon, 1 Nov 2021 11:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=alphaexplorationco.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 n9Y3F1-Lh4FM for ; Mon, 1 Nov 2021 11:53:29 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7404E3A284B for ; Mon, 1 Nov 2021 11:52:49 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id bd30so6567186oib.13 for ; Mon, 01 Nov 2021 11:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a0hPRD/E9fOfdWYVIPZReUvFEqBX/+XV17bJTGmNjTg=; b=LkGQW+Ml9B2Io+bDduP08VsmUUeXcxig8HA75hG6x8aFPmorTkZfp2DL5ixgDmVMhS 0dNG0jIEyMyedrdmFYQ7fGH1C/QbTivVLU2rREZhlEW0R2lyDP9eO3lkQLXZjG17k6Qy n6BYyqilfI0l2WQZ0CYbJEt4Ht7iQVy/eXdygTUZV0Y6sTgaGQ6HluRu8UW0tHmHQ7CT tVV5NL7MZkAJE87XoctUBZ5eXovT+YvXZBSj/EYz08R3ZOWxoVxtYM0c3rnihh9kAq5Q 4fprskW22rE2efTQf8qmZQ+JRH8pbfSid5JTmCCuV4YUUIsvKMuW+3k//L17FZkDb4m5 I67Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a0hPRD/E9fOfdWYVIPZReUvFEqBX/+XV17bJTGmNjTg=; b=cMSIOCM0AT0lNgukpbJ4Bl1Qwes+tH4SfaB6qtrL0UhWJITrQ6B0azkpmvMTmLpLTr c973i+qm+Pi6q/wWVBOTo2bqG0m3RCPFzWDxayckCXbnFBPNhOT80RjQ1xQg/F+C7BTa gK+VJ3yy3D1OMdoWSFg0ZhOz0WKDpzfQF8GGnL0MDnv0rHHyWcTpBoy/2fBoWdrWG4C4 JOXitCYki+EOEMlY06gLgzzREdBSoYsk090ep1jUVkMTfF3x4hYJCIG6Ps42YDxzfXu5 ZxQP+f9Z4HgqvVuvyfW2sevN0nTtDrm8CmfIJStRAWe/Au3IRFXu1B0M8e+HWKucnmKf P9GA== X-Gm-Message-State: AOAM531X9/ElI6kH48duS1g9wUAsC87g7Ggns9wwDJAH27Z8G9ecxv9/ fBh4FORHmpvEa+xyQyA9ffyZXu/Vm+fyX3YMatkRzg== X-Google-Smtp-Source: ABdhPJwbed+Ca/r9u6s1kz8l8b8bxciLKerL5B8uBcUECXigYaEW5479jIWrCJMHj8snY4rp42kif6s8LWEg82gYXIw= X-Received: by 2002:aca:ac0f:: with SMTP id v15mr690697oie.46.1635792767285; Mon, 01 Nov 2021 11:52:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 1 Nov 2021 11:52:36 -0700 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000d2406105cfbeaebc" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 18:53:40 -0000 --000000000000d2406105cfbeaebc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 1, 2021 at 6:29 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > >1. Make subsequent offers valid initial offers. This means adding some > language explaining how the endpoint processing initial offer can detect > that m=3D lines cannot be unbundled. Even if we add this language it will > have backwards compatibility issues with anything that has not implemente= d > it. > > > > I don=E2=80=99t agree with that suggestion. Because, in that case we coul= d have > done it from the beginning, as a general rule, without using port zero. B= ut > there were reason we chose not to allow shared addresses (with non-zero > port values) in initial offers. > > > >We did come up with a=3Dbundle-only mechanism to ensure backwards > compatibility, and none of us want to revisit that decision. However, I d= o > think that it would be consistent with Postel's Principle for the > > answerer to properly handle the case where a 3PCC offer ends up with a > shared address, rather than failing simply because the offer does not > appear to be an initial offer. > > I don't agree with that. Again, that is why we did not define it to begin > with. When this was discussed, people indicated that even in cases where = an > answerer would accept the offer, it is not possible to predict how the > answer would look like. > > Also, keep in mind that the answerer may not know that the offer is for > 3PCC. It may just see an initial offer. > I think we are talking about a much narrower situation than what was considered years ago. The concern Roman raises is regarding a bundle-aware endpoint that receives an initial offer that is a valid bundle subsequent offer. Can you suggest a specific technical reason why it would be ambiguous for the answerer to handle this offer? > > > > >2. Make endpoints generate subsequent offers that are valid initial > offers in 3PCC scenarios. This is what draft 8843 bis does. > > > > Correct. > > > > However, keep in mind that it is not only about how to encode the port > numbers and bundle-only attributes. Sending an initial offer also comes > with a set of procedures. Some of those (e.g., ICE) I assume you will ha= ve > to do anyway, as the remote endpoint changes. > > > > >I would even be fine with webrtc endpoint not doing anything and adding = a > note to JSEP telling the 3PCC application to "fix" the offer and add m=3D > port zero and bundle-only attributes when it is sending subsequent offers > as initial offers to a new end point. > > > > I would be fine adding such text to JSEP. It could be an additional > sentence to the existing text. > > > > (However, I still would not say =E2=80=9Csending subsequent offers as ini= tial > offers=E2=80=9D. I would say =E2=80=9Ccreate and send an initial offer ba= sed on a received > subsequent offer=E2=80=9D, or something like that.) > > > >This might turn out to be the simplest option, but as noted before, it > will require several SDP changes and will be somewhat error-prone as a > result (assuming anyone implements this at all). Accordingly I think #1 > above is the least bad choice. > > I don't agree with suddenly allowing (read: specify in the standard that > it is ok) something that we agreed that we are not going to do more or le= ss > from day one, and that has never considered later during the process eith= er. > > --- > > The PROBLEM is that we have two endpoints, where one sends a subsequent > offer, and the other one expects an initial offer. What do you normally d= o > when you have that kind of problem? You use an SBC/B2BUA. In this case th= at > SBC/B2BUA would be the 3PCC controller. > > So, my suggestion would be to remove the SHOULD text from 8843bis, and > simply add a note somewhere (in 8843bis and/or 8829bis) which describes t= he > issue and says that the 3GPP controller needs to modify the offer > accordingly. > > Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyway then maybe adding a=3Dbundle-only isn't the end of the world. --000000000000d2406105cfbeaebc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 1, 2021 at 6:29 AM Christ= er Holmberg <christer.= holmberg@ericsson.com> wrote:
Hi,
=C2=A0

>1. Make subsequent offers valid initial offers.= This means adding some language explaining how the endpoint processing=C2= =A0initial offer can detect that m=3D lines cannot be unbundled. Even if we= add this language it will have backwards compatibility issues with anything that has not implemented= it.

=C2=A0

I don=E2=80=99t agree with that suggestion. Because= , in that case we could have done it from the beginning, as a general rule,= without using port zero. But there were reason we chose not to allow share= d addresses (with non-zero port values) in initial offers.


>We did come up with a=3Dbundle-only mechanism to ensure backwards = compatibility, and none of us want to revisit that decision. However, I do = think that it would be consistent with Postel's Principle for the
> answerer to properly handle the case where a 3PCC offer ends up w= ith a shared address, rather than failing simply because the offer does not= appear to be an initial offer.

I don't agree with that. Again, that is why we did not define it t= o begin with. When this was discussed, people indicated that even in cases = where an answerer would accept the offer, it is not possible to predict how= the answer would look like.

Also, keep in mind that the answerer may not know that the offer is fo= r 3PCC. It may just see an initial offer.

I think we are talking about a much narrower s= ituation than what was considered years ago. The concern Roman=C2=A0raises = is regarding a bundle-aware endpoint that receives an initial offer that is= a valid bundle subsequent offer.=C2=A0=C2=A0

Can = you suggest a specific technical reason why it would be ambiguous for the a= nswerer to handle this offer?=C2=A0

=C2=A0

>2. Make endpoints generate subsequent offers th= at are valid initial offers in 3PCC scenarios. This is what draft 8843 bis = does.

=C2=A0

Correct.

=C2=A0

However, keep in mind that it is not only about how= to encode the port numbers and bundle-only attributes. Sending an initial = offer also comes with a set of procedures. Some of those (e.g., ICE) =C2=A0= I assume you will have to do anyway, as the remote endpoint changes.

=C2=A0

>I would even be fine with webrtc endpoint not d= oing anything and adding a note to JSEP telling the 3PCC application to &qu= ot;fix" the offer and add m=3D port zero and bundle-only attributes wh= en it is sending subsequent offers as initial offers to a new end point.

=C2=A0

I would be fine adding such text to JSEP. It could = be an additional sentence to the existing text.

=C2=A0

(However, I still would not say =E2=80=9Csending su= bsequent offers as initial offers=E2=80=9D. I would say =E2=80=9Ccreate and= send an initial offer based on a received subsequent offer=E2=80=9D, or so= mething like that.)


>This might turn out to be the simplest option, but as noted before= , it will require several SDP changes and will be somewhat error-prone as a= result (assuming anyone implements this at all). Accordingly I think #1 ab= ove is the least bad choice.

I don't agree with suddenly allowing (read: specify in the standar= d that it is ok) something that we agreed that we are not going to do more = or less from day one, and that has never considered later during the proces= s either.

---

The PROBLEM is that we have two endpoints, where one sends a subsequen= t offer, and the other one expects an initial offer. What do you normally d= o when you have that kind of problem? You use an SBC/B2BUA. In this case th= at SBC/B2BUA would be the 3PCC controller.

So, my suggestion would be to remove the SHOULD text from 8843bis, and= simply add a note somewhere (in 8843bis and/or 8829bis) which describes th= e issue and says that the 3GPP controller needs to modify the offer accordi= ngly.


Rom= an, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyway = then maybe adding a=3Dbundle-only isn't the end of the world.
=
--000000000000d2406105cfbeaebc-- From nobody Tue Nov 2 01:41:19 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196373A0F46 for ; Tue, 2 Nov 2021 01:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=telurix.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 TXWTyi62HX6p for ; Tue, 2 Nov 2021 01:41:13 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 36ABB3A0F41 for ; Tue, 2 Nov 2021 01:41:13 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id br39so5781678qkb.8 for ; Tue, 02 Nov 2021 01:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cDZyd6dJj5yPJiHF6KG05hdGGqle0Fn++2ilOo0nEy8=; b=vdrR/J5HMh6Guyu/zGhNxt9GJdTOMSj1ghi+zRoKBBADjUp4VcCWjJgzf8lob+9ZoD yHZgZgOfTVGDkED9lxE9xdjtuQyi8lUX545auxKX4kYbnW+WCqG6lNT0zPXiMdZG0h/p Yo2cWsFNV8Ek/zTjM7AeHqFUC2AHZLtv4f3uU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cDZyd6dJj5yPJiHF6KG05hdGGqle0Fn++2ilOo0nEy8=; b=ZpZYevmPdunC+KS1CNBDH49+08BTEGzEFZLGLl8hzOy0V87GUYpGgLVjGNvR3Sp9ig U9hxyraYVJ3/x+D9En53YA8vzJeMdNTCTGKT2fZZ2ju/NOm5I5PUyb7e7v6XyJe38JKT 3h/jHOIxrl5ArgGaqB27wDCxL85fzNZj+3+qxxidMepxlMVu21ZWRZSKYRIny45kvJ2V J6PF/CIOU/jH8YxljaQ4dVe6xFuLshNGAnkcxGnFksavpOGQKDNU0tAwqmb6lK2C7viY dR4quG1I+mTmVK77umCI4FWPMG3Y6lIFX5h9PoYUM3ojGRuIMkdxZh7AQM1m68tktCxC snsg== X-Gm-Message-State: AOAM532Ro3e+4dtROVyokezM9Fo9ToBfj1DsgmTa43CMCSu45y4ubTeT cuEAFPDbFG3rAO1Ado+Ep/fcojPAAaD9Ng== X-Google-Smtp-Source: ABdhPJzqTdW4Z1Oss5k13voTjW9/HFe/DYxEiHItcyNMNpTp5OCLt+Je8YljSH54x1GKkl9JCJlvRw== X-Received: by 2002:a05:620a:889:: with SMTP id b9mr28491914qka.229.1635842471123; Tue, 02 Nov 2021 01:41:11 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id j5sm3486330qki.39.2021.11.02.01.41.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Nov 2021 01:41:10 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id s186so27068173yba.12 for ; Tue, 02 Nov 2021 01:41:09 -0700 (PDT) X-Received: by 2002:a25:ca58:: with SMTP id a85mr40932045ybg.155.1635842469561; Tue, 02 Nov 2021 01:41:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 2 Nov 2021 04:40:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Christer Holmberg , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000004e925c05cfca4161" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 08:41:18 -0000 --0000000000004e925c05cfca4161 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti wrote: > The PROBLEM is that we have two endpoints, where one sends a subsequent >> offer, and the other one expects an initial offer. What do you normally do >> when you have that kind of problem? You use an SBC/B2BUA. In this case that >> SBC/B2BUA would be the 3PCC controller. >> >> So, my suggestion would be to remove the SHOULD text from 8843bis, and >> simply add a note somewhere (in 8843bis and/or 8829bis) which describes the >> issue and says that the 3GPP controller needs to modify the offer >> accordingly. >> >> Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP > anyway then maybe adding a=bundle-only isn't the end of the world. > I am not opposed to this idea. 3PCC typically knows that the subsequent offer is going to be used as initial, and should be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis ( https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. We can then reference this note from 8829bis or restate the same guidance. _____________ Roman Shpount --0000000000004e925c05cfca4161 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 1, 2021 at 2:52 PM Ju= stin Uberti <juberti@a= lphaexplorationco.com> wrote:
The PROBLEM is that we= have two endpoints, where one sends a subsequent offer, and the other one = expects an initial offer. What do you normally do when you have that kind o= f problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the 3= PCC controller.

So, my suggestion would be to remove the SHOULD text from 8843bis, and= simply add a note somewhere (in 8843bis and/or 8829bis) which describes th= e issue and says that the 3GPP controller needs to modify the offer accordi= ngly.

Roman, thoughts on= this? If the 3PCC is going to rewrite the offer SDP anyway then maybe addi= ng a=3Dbundle-only isn't the end of the world.

I am not opposed to=C2=A0this idea. 3PCC typi= cally knows that the subsequent offer is going to be used as initial, and s= hould be able to rewrite the offer to make it valid. We can change=C2=A0SIP= Considerations section in 8843bis (https://ww= w.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-conside= ration), remove the SHOULD, and specify that 3PCC controller should fix= the offer. We can then reference this note from 8829bis or restate the sam= e guidance.
_____________
Roman Shpount
=C2=A0
--0000000000004e925c05cfca4161-- From nobody Tue Nov 2 03:00:45 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838983A1048 for ; Tue, 2 Nov 2021 03:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 rhcQE9xbb9kL for ; Tue, 2 Nov 2021 03:00:37 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70088.outbound.protection.outlook.com [40.107.7.88]) (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 01CB43A1047 for ; Tue, 2 Nov 2021 03:00:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S0i3s6yRCyH0Xjgl1Bgi/pwlfSW+ICrlfQuDSYHo5ugr5uHDXUOk2n/2Uu1fWlsL2UF8ANu1qJKmTV/6gXpeiyN3HJ+DlAf8URQpg5dZDM3NcfZe1EL1f2duCbwtO8b4cnEWSp+CuWpB7hoGYW/drU7+WWZ4xEiDXlaFo4TO13T/2cadLBdOOuvai9RyBXaQ8wmiqxMn1av+ZuWM9fnLMQ+DH0juwaAOzoNO5D/YgopxbEVvgG+e17MhDxwTZ3xG34ezpLlyFPFF8tAoOllS4L2QS5FwhaWvW7KZX/O4DKYi2DP+aqgvlGgp0wNbLzHID/ZxlYlkJD6KpUocbKFMcQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1Sywrj2itffHhZY5DaHYFD6Bers5bz9skR9oNA3XUpk=; b=h8eNfvw7KZtNKXjoPYGeCogFraoQ8BdqOKmjEjc8AhOQnLOkx363UflLTcDFtvdj63Odne5X3PPpW2eRYqDkijGzdvnmmweoEP2bAI0EZDQuNSpp0ajGSAQa/T94Uf4uSuRzGn+ohPObmPi1MTIUV7/dgf3v3YCfLFgOukuJq6j9rX0e+MAXVNwF79kjGe3nOxT+H6m9o360Xnog+mBD0LHo4fvTX+jQs4hlkAzYpT++uc8XkdOvksyCI4G7b+fOPsSDCRh9I5s/Bo4ZEpYvKo2nDzG5x5dKM4u/2UGbeGUIvcnkPeDTCS/FbuRBmgGjTnVqi9YIsavqhmnqLHXsIQ== 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=1Sywrj2itffHhZY5DaHYFD6Bers5bz9skR9oNA3XUpk=; b=OxW3n/8Jn/dy/QT4lebpCSwYumK0J4UdlaoZYYDf0m5mwus/w6LJVKKe7qM3B6ajZnap6ERz2al3TuJ9LXTcjpbBd5oOGpmWiKlJ5ApdlLqIIGX989/A+zkxzbea1oYlqFhmJ6tOVC98ysji0fuN2rXYlIDOSw3HDvAdoJpzztQ= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR0702MB3801.eurprd07.prod.outlook.com (2603:10a6:7:80::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.8; Tue, 2 Nov 2021 10:00:33 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.010; Tue, 2 Nov 2021 10:00:33 +0000 From: Christer Holmberg To: Roman Shpount , Justin Uberti CC: Justin Uberti , RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B32AAGQiAIAA528AgAASO+A= Date: Tue, 2 Nov 2021 10:00:32 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e4b6a716-4ac7-4b31-71cb-08d99de79c1a x-ms-traffictypediagnostic: HE1PR0702MB3801: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t0XktqcRfJu99za3aZEerRLtf2Kn+PeSfkAaxFkJ0l0XbUKdmEhOan6wcgDSgo9Lth5i19vUCzbjSgZ/x6bWHycZjUr00stQolD45AV73si03k/28ce2zyS09lsv+5sOsk7AlfiCH8d5XBDCnv+8sIDHw3xn6UYGnaccbqX2hnl5Hu07cNIeilRfOOjjXM81kUuhVu1sA4WYqZx9ZFN48H2w3px0DFiMzaf/NDfYZiJvPTntEy5/EWneW5n5woXvhgvZ+p633jo+VIPuk8jivf5FhhHSTy01Jj94K9VL4SKzFGlkktxYxeJUY17CMuEMvKU3NRpNY1mbEvzmbdlZyq1liUTgHDtlRHAM4/7AgBc8MoRAsxCKHmHhV4AFmerAlP2NDnKSEFhcP2yeicI2ayvbhmriJcqYvK7dSWcn4utis0K2mue+92lQFisLC69apQVvWAoqDyzYF4cUbGj72MIM8lYA0Lf+I0kw7NArMJSgLXBEny7igu1Evy9mv6zAiFNlggaaKf9XDjqMw+RzmS7qZ4RmPGVFk4zUtOXlgGIoykUuYco6zXG/LnuG1eYOBPUzqGQVoCDWwS0TO1P4l2tkiM55dEM3rHBpokd2gdyidocKbagY39k0sJiQGJvLMnS2W+YNCrEL4FtHCFBHtgr+nkEt86mI+miItO7AezRT4KQ+4zNSxQvqH+t9G4yak/mwYTpH/xLGwfBIeOuV4Z0GGGCO8bjIuZWvNDPuBxHVLUbXC26pciPYP7pXd4sACYDddA9Tj7On/KDlBInHPXjNfnw3bpda337OklTQ8aY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(83380400001)(316002)(2906002)(66946007)(66476007)(66556008)(52536014)(76116006)(8936002)(8676002)(9686003)(5660300002)(6506007)(53546011)(38070700005)(86362001)(38100700002)(508600001)(66446008)(122000001)(64756008)(166002)(7696005)(55016002)(26005)(54906003)(110136005)(71200400001)(44832011)(82960400001)(186003)(33656002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OGhqaUJHSVRQTHB0b2xRVXJwcHdxaDFCSUZ5RGN6RXc1c1ZqbkJJWStrOHor?= =?utf-8?B?enRHWGVSOC9yZi9CakJnVDhVcVB3WTRsOWtTQVlpUU1MRlhYWElmN08yWUJ5?= =?utf-8?B?UUR1V2ZuVjJLdjhuQVkybUNVUlN2Nnl6QmhHQ1Y5bXlsaThWTjhuUjJUdXBI?= =?utf-8?B?Z3ZHT0FMUmNRS3FNR3VnaWQ1WkpMWXlPTHVSS2NVQ1BzRWtaZ0FYK0dwdDlS?= =?utf-8?B?b09xdElMU2hlcW1hWDEvZG1VREc4UjJNQjdHNDMyWFRoaTF3N0FoN0N6VTFx?= =?utf-8?B?MEJhVCtLdEJSSm5QZTdISWpUM3ZLeG9yRFp3d0lDRnVEbzB6bmo0TVBFUWFB?= =?utf-8?B?U2VDTnBrb2NTOC9WNmRIZ3pFUUVyTkdtcnVwTk05TWFwQWovNXBiODlyRXZT?= =?utf-8?B?Y2MwdWdJRkx1KzVDUnlyeWUrQzJBR0o3cHJnajY2M2poU3F2RlJZdFcwSVBL?= =?utf-8?B?K2dzeGViRGRhbHpFTDZrOGRNNVovNmJXZnh1NGVDRWl0dWk4NndIVUdoV2Iw?= =?utf-8?B?SkEwVk1MdUdtOStxYU9pMWgyVmk2RWk5RU5rYmh0b2JIQ3hnd2c3L2xLdUE4?= =?utf-8?B?NG4wWGtKV3Zhb2Fha2krOUpxT2s1T0hLQUdoNDY5aGdvQjJLaTlFUlVVWHUy?= =?utf-8?B?ZVMvcGV4SzdLRW9pb0Z4WG81MjRXNm9aeDlyTVFvYU1DVVJERkh2aVVPMWhI?= =?utf-8?B?ZVJrSlJucHpGaDhIdXdXdS8wSTE0YVMzZi9FbzRGYzlrNXNwY3BLbkxXSVE1?= =?utf-8?B?aVNIWU9zQnRWUVRhOHBzMW5zNHpGd3ZiYjNaMXRxWnhsYzVtWlUrZDdhNW02?= =?utf-8?B?T05xSTl2UytycXkvQWdkV0plRTNzd3hYbFVhYW1FM2JPZlVraTlxcEpJaWtG?= =?utf-8?B?RFU1b0hxZGVubFdsaVViWUxNOGMxRUtCaXBobUt2eDhRcm0zcVpmSGdWK29Q?= =?utf-8?B?a0Q2VzhwbW5hUHBVUUwxcHdLdkE2R2Vyd0J6bXRIWXJBOGpLdzhJdExWeGJ6?= =?utf-8?B?UE5JZDJRQWFJaEorUWFNM2lOcEp0OS9qbE1RSlVRK3B5UE1QaklCZzBUcWtr?= =?utf-8?B?UXpqanVYWDJKci9uZEJVSTRVOEZ4SDVmbjM4Q1JjOURLZmRjMGt4Y29LczFu?= =?utf-8?B?ck5qVXQxNkNCWUJMNkU3RVVvaC9ySi9taFhySlpBU3IyRWs2UlY3TnhCS3ZC?= =?utf-8?B?akwyalRiakFPbVBPMTRqSHRhZ2lmb2hFT0xBT0x3Sno2dXQ4S2tLWmkvMmNB?= =?utf-8?B?TlhlSnhKTHBFS0JGaWlKUmNpR2xFZXQxWmJ1TlZuRWZ2T0x0U3F6K0tHZnl4?= =?utf-8?B?bHE5ZlJabjhqdDFRVjZMdEp1ZERJM0pPS1pnMjNlS1RjT0RFMjhPRGNNdHFW?= =?utf-8?B?WlpIQVpjYXZoWmhlUFNxYk9kcEROU3J3WUp0VE1UY2FOSHYxUk1PZCtoM3M1?= =?utf-8?B?aXBLcmNmZEV6QVAraThpMUVkWTlTaGNsdXhnZWhSYVBYeitIREFtQVRVcVFV?= =?utf-8?B?T0RucTlYWG8vUFFudzZqS3pETFNaK1k1dkttQUVneC9LMXJGWjdicC92dEp0?= =?utf-8?B?ZE9iVXFxbGszVFJIajFNN3V2QjhuNGd5dUs5NnhBUG4vTzIyS3o3SmFLSXhO?= =?utf-8?B?L2xLc2lvUng0MGdrMWZFOTRsU2tHSHB2VmRQQ0hTeU52MzVtSXdWdHZGNGFL?= =?utf-8?B?RTkvYjBzZHovcFZiU0UwVVg3WUpjaEh1WmhJRzNsNVpvRFBxRmpOVytuQzhM?= =?utf-8?B?Z2hsOS9NQngzNG9xSzFheERsVXJUUVJXVkxZZkhWanpMM3d5UHRPNjZ4Ry9M?= =?utf-8?B?N0dSekZ4cXY4UWZtd1JacU1YeXRVWElYNVIvcjhaOUl4d1Z2NzhZNzkwNlFC?= =?utf-8?B?ZXVtSnRvS05YR1lLZ2pXWFgza0Robldra0tzcGZ4VlNibUx3bHVxQ1VxSjRN?= =?utf-8?B?R2hmT2IyZUpXV3pybHk3TWpBOE5KRVJVMkU5a0hWdFAwQ0FqVlVLc0dlbE9O?= =?utf-8?B?MVk4ZFBNSGhQdXRoUVBaS05BZHVzVVIyeU8rMU8wWXZCY0VGdEE5QUJuV3Ey?= =?utf-8?B?K3FTMy85VkZRa01zTVlwRTJJQlR4Zjg4VmR6eUZPMXZ2SWRPdkd4dzF5RGtC?= =?utf-8?B?Tkh4NWdlS0lPVUJBUXVibm9aamFydkk5Zjd0VjREbzRPWWFTakFVSENlWGJS?= =?utf-8?B?Mi9MKzAxSHhEQ0dIOHE4Qnc0QVFWOWNPUllabmc4U2dDSWh1U2l0SlYwMnRE?= =?utf-8?B?c1FpdmZhZ2Z5ZjNFNDY5YnZRc3VBPT0=?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB44412A75040C64BB77431AF3938B9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e4b6a716-4ac7-4b31-71cb-08d99de79c1a X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2021 10:00:32.9561 (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: in4X1oagWJFFDE3ahBOBBcXTTw10+LJfCYbEdUVwJry8mbqTI1I2CtgucHGsGuCE28OCM1hUX7+dXjVBoZmhHXOoJYcYg8DERLRClEKSza0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3801 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 10:00:43 -0000 --_000_HE1PR07MB44412A75040C64BB77431AF3938B9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoYXQgYWJvdXQgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KLS0tDQoNCk9MRDoNCg0K 4oCcVGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBbUkZDMzI2MV0gYWxsb3dz IGEgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgdG8gc2VuZCBhIHJlLUlOVklURSByZXF1ZXN0IHdp dGhvdXQgYW4gU0RQIGJvZHkgKHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyBhbiBlbXB0eSByZS1J TlZJVEUpLg0KSW4gc3VjaCBjYXNlcywgdGhlIFVzZXIgQWdlbnQgU2VydmVyIChVQVMpIHdpbGwg aW5jbHVkZSBhbiBTRFAgT2ZmZXIgaW4gdGhlIGFzc29jaWF0ZWQgMjAwIE9LIHJlc3BvbnNlLiBU aGlzIGlzIHR5cGljYWxseSB1c2VkIGZvciAzcmQgUGFydHkgQ2FsbCBDb250cm9sICgzUENDKSBz Y2VuYXJpb3MuDQpGcm9tIGEgQlVORExFIHBlcnNwZWN0aXZlLCBzdWNoIFNEUCBPZmZlciBTSE9V TEQgYmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBwcm9jZWR1cmVzIGRlZmluZWQgaW4gU2VjdGlvbiA3 LjIu4oCdDQoNCk5FVzoNCg0K4oCcVGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQ KSBbUkZDMzI2MV0gYWxsb3dzIGEgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgdG8gc2VuZCBhIHJl LUlOVklURSByZXF1ZXN0IHdpdGhvdXQgYW4gU0RQIGJvZHkgKHNvbWV0aW1lcyByZWZlcnJlZCB0 byBhcyBhbiBlbXB0eSByZS1JTlZJVEUpLg0KSW4gc3VjaCBjYXNlcywgdGhlIFVzZXIgQWdlbnQg U2VydmVyIChVQVMpIHdpbGwgaW5jbHVkZSBhbiBTRFAgb2ZmZXIgaW4gdGhlIGFzc29jaWF0ZWQg MjAwIE9LIHJlc3BvbnNlLiBUaGlzIGlzIHR5cGljYWxseSB1c2VkIGZvciAzcmQgUGFydHkgQ2Fs bCBDb250cm9sICgzUENDKSBzY2VuYXJpb3MuDQoNCkluIHNvbWUgM1BDQyBzY2VuYXJpb3MgdGhl IFVBUyB3aWxsIGJlIHBhcnQgb2YgYW4gb25nb2luZyBzZXNzaW9uLCBhbmQgd2lsbCB0aGVyZWZv cmUgaW5jbHVkZSBhIHN1YnNlcXVlbnQgb2ZmZXIgaW4gdGhlIDIwMCBPSyByZXNwb25zZXMuIFRo ZSBvZmZlciB3aWxsIGJlDQpyZWNlaXZlZCBieSBhIDNQQ0MgY29udHJvbGxlciAoVUFDKSBhbmQg dGhlbiBmb3J3YXJkZWQgYXMgYW4gaW5pdGlhbCBvZmZlciB0byBhbm90aGVyIFVzZXIgQWdlbnQg KFVBKSB0aGF0IGlzIGN1cnJlbnRseSBub3QgcGFydCBvZiBhIHNlc3Npb24uDQoNCldoZW4gdGhl IEJVTkRMRSBtZWNoYW5pc20gaXMgdXNlZCwgYXMgYW4gaW5pdGlhbCBCVU5ETEUgb2ZmZXIgbG9v ayBkaWZmZXJlbnQgdGhhbiBhIHN1YnNlcXVlbnQgQlVORExFIG9mZmVyLCBpdCBjYW5ub3QgYmUg YXNzdW1lZCB0aGF0IGEgVUEgdGhhdCBleHBlY3RzIGFuIGluaXRpYWwgb2ZmZXINCndpbGwgYmUg YWJsZSB0byBwcm9wZXJseSBwcm9jZXNzIGEgc3Vic2VxdWVudCBvZmZlci4gVGhlcmVmb3JlLCB0 aGUgM1BDQyBjb250cm9sbGVyIG5lZWRzIHRvIGFjdCBhcyBhIEJhY2stVG8tQmFjayBVc2VyIEFn ZW50IChCMkJVQSksIGFuZCB3aGVuIGl0IHJlY2VpdmVzIHRoZSBzdWJzZXF1ZW50DQpvZmZlciBp dCBuZWVkcyB0byByZXdyaXRlIGl0IGludG8gYW4gaW5pdGlhbCBvZmZlciBiZWZvcmUgaXQgaXMg Zm9yd2FyZGVkIHRvIHN1Y2ggVUEu4oCdDQoNCi0tLS0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KDQoNCg0KDQoNCg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4N ClNlbnQ6IHRpaXN0YWkgMi4gbWFycmFza3V1dGEgMjAyMSAxMC40MQ0KVG86IEp1c3RpbiBVYmVy dGkgPGp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbT4NCkNjOiBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgSnVzdGluIFViZXJ0aSA8anVzdGlu QHViZXJ0aS5uYW1lPjsgUlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbcnRjd2ViXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtdWJlcnRpLXJ0Y3dl Yi1yZmM4ODI5YmlzLTAxLnR4dA0KDQpPbiBNb24sIE5vdiAxLCAyMDIxIGF0IDI6NTIgUE0gSnVz dGluIFViZXJ0aSA8anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tPG1haWx0bzpqdWJlcnRp QGFscGhhZXhwbG9yYXRpb25jby5jb20+PiB3cm90ZToNClRoZSBQUk9CTEVNIGlzIHRoYXQgd2Ug aGF2ZSB0d28gZW5kcG9pbnRzLCB3aGVyZSBvbmUgc2VuZHMgYSBzdWJzZXF1ZW50IG9mZmVyLCBh bmQgdGhlIG90aGVyIG9uZSBleHBlY3RzIGFuIGluaXRpYWwgb2ZmZXIuIFdoYXQgZG8geW91IG5v cm1hbGx5IGRvIHdoZW4geW91IGhhdmUgdGhhdCBraW5kIG9mIHByb2JsZW0/IFlvdSB1c2UgYW4g U0JDL0IyQlVBLiBJbiB0aGlzIGNhc2UgdGhhdCBTQkMvQjJCVUEgd291bGQgYmUgdGhlIDNQQ0Mg Y29udHJvbGxlci4NCg0KU28sIG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gcmVtb3ZlIHRoZSBT SE9VTEQgdGV4dCBmcm9tIDg4NDNiaXMsIGFuZCBzaW1wbHkgYWRkIGEgbm90ZSBzb21ld2hlcmUg KGluIDg4NDNiaXMgYW5kL29yIDg4MjliaXMpIHdoaWNoIGRlc2NyaWJlcyB0aGUgaXNzdWUgYW5k IHNheXMgdGhhdCB0aGUgM0dQUCBjb250cm9sbGVyIG5lZWRzIHRvIG1vZGlmeSB0aGUgb2ZmZXIg YWNjb3JkaW5nbHkuDQoNClJvbWFuLCB0aG91Z2h0cyBvbiB0aGlzPyBJZiB0aGUgM1BDQyBpcyBn b2luZyB0byByZXdyaXRlIHRoZSBvZmZlciBTRFAgYW55d2F5IHRoZW4gbWF5YmUgYWRkaW5nIGE9 YnVuZGxlLW9ubHkgaXNuJ3QgdGhlIGVuZCBvZiB0aGUgd29ybGQuDQoNCkkgYW0gbm90IG9wcG9z ZWQgdG8gdGhpcyBpZGVhLiAzUENDIHR5cGljYWxseSBrbm93cyB0aGF0IHRoZSBzdWJzZXF1ZW50 IG9mZmVyIGlzIGdvaW5nIHRvIGJlIHVzZWQgYXMgaW5pdGlhbCwgYW5kIHNob3VsZCBiZSBhYmxl IHRvIHJld3JpdGUgdGhlIG9mZmVyIHRvIG1ha2UgaXQgdmFsaWQuIFdlIGNhbiBjaGFuZ2UgU0lQ IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaW4gODg0M2JpcyAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcv YXJjaGl2ZS9pZC9kcmFmdC1pZXRmLW1tdXNpYy1yZmM4ODQzYmlzLTA1Lmh0bWwjbmFtZS1zaXAt Y29uc2lkZXJhdGlvbiksIHJlbW92ZSB0aGUgU0hPVUxELCBhbmQgc3BlY2lmeSB0aGF0IDNQQ0Mg Y29udHJvbGxlciBzaG91bGQgZml4IHRoZSBvZmZlci4gV2UgY2FuIHRoZW4gcmVmZXJlbmNlIHRo aXMgbm90ZSBmcm9tIDg4MjliaXMgb3IgcmVzdGF0ZSB0aGUgc2FtZSBndWlkYW5jZS4NCl9fX19f X19fX19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_HE1PR07MB44412A75040C64BB77431AF3938B9HE1PR07MB4441eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+V2hhdCBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igJxUaGUgU2Vzc2lvbiBJbml0 aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2VyIEFnZW50IENsaWVu dCAoVUFDKSB0byBzZW5kIGEgcmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBhbiBTRFAgYm9keSAo c29tZXRpbWVzIHJlZmVycmVkIHRvIGFzIGFuIGVtcHR5IHJlLUlOVklURSkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gc3VjaCBjYXNlcywgdGhlIFVzZXIgQWdl bnQgU2VydmVyIChVQVMpIHdpbGwgaW5jbHVkZSBhbiBTRFAgT2ZmZXIgaW4gdGhlIGFzc29jaWF0 ZWQgMjAwIE9LIHJlc3BvbnNlLiBUaGlzIGlzIHR5cGljYWxseSB1c2VkIGZvciAzcmQgUGFydHkg Q2FsbCBDb250cm9sICgzUENDKSBzY2VuYXJpb3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5Gcm9tIGEgQlVORExFIHBlcnNwZWN0aXZlLCBzdWNoIFNEUCBPZmZl ciBTSE9VTEQgYmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBwcm9jZWR1cmVzIGRlZmluZWQgaW4gU2Vj dGlvbiA3LjIu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TkVXOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKAnFRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9j b2wgKFNJUCkgW1JGQzMyNjFdIGFsbG93cyBhIFVzZXIgQWdlbnQgQ2xpZW50IChVQUMpIHRvIHNl bmQgYSByZS1JTlZJVEUgcmVxdWVzdCB3aXRob3V0IGFuIFNEUCBib2R5IChzb21ldGltZXMgcmVm ZXJyZWQgdG8gYXMgYW4gZW1wdHkgcmUtSU5WSVRFKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JbiBzdWNoIGNhc2VzLCB0aGUgVXNlciBBZ2VudCBTZXJ2ZXIgKFVB Uykgd2lsbCBpbmNsdWRlIGFuIFNEUCBvZmZlciBpbiB0aGUgYXNzb2NpYXRlZCAyMDAgT0sgcmVz cG9uc2UuIFRoaXMgaXMgdHlwaWNhbGx5IHVzZWQgZm9yIDNyZCBQYXJ0eSBDYWxsIENvbnRyb2wg KDNQQ0MpIHNjZW5hcmlvcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIHNv bWUgM1BDQyBzY2VuYXJpb3MgdGhlIFVBUyB3aWxsIGJlIHBhcnQgb2YgYW4gb25nb2luZyBzZXNz aW9uLCBhbmQgd2lsbCB0aGVyZWZvcmUgaW5jbHVkZSBhIHN1YnNlcXVlbnQgb2ZmZXIgaW4gdGhl IDIwMCBPSyByZXNwb25zZXMuIFRoZSBvZmZlciB3aWxsIGJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+cmVjZWl2ZWQgYnkgYSAzUENDIGNvbnRyb2xsZXIgKFVBQykg YW5kIHRoZW4gZm9yd2FyZGVkIGFzIGFuIGluaXRpYWwgb2ZmZXIgdG8gYW5vdGhlciBVc2VyIEFn ZW50IChVQSkgdGhhdCBpcyBjdXJyZW50bHkgbm90IHBhcnQgb2YgYSBzZXNzaW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldoZW4gdGhlIEJVTkRMRSBtZWNoYW5pc20gaXMgdXNl ZCwgYXMgYW4gaW5pdGlhbCBCVU5ETEUgb2ZmZXIgbG9vayBkaWZmZXJlbnQgdGhhbiBhIHN1YnNl cXVlbnQgQlVORExFIG9mZmVyLCBpdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IGEgVUEgdGhhdCBl eHBlY3RzIGFuIGluaXRpYWwgb2ZmZXINCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPndpbGwgYmUgYWJsZSB0byBwcm9wZXJseSBwcm9jZXNzIGEgc3Vic2VxdWVudCBv ZmZlci4gVGhlcmVmb3JlLCB0aGUgM1BDQyBjb250cm9sbGVyIG5lZWRzIHRvIGFjdCBhcyBhIEJh Y2stVG8tQmFjayBVc2VyIEFnZW50IChCMkJVQSksIGFuZCB3aGVuIGl0IHJlY2VpdmVzIHRoZSBz dWJzZXF1ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+b2ZmZXIg aXQgbmVlZHMgdG8gcmV3cml0ZSBpdCBpbnRvIGFuIGluaXRpYWwgb2ZmZXIgYmVmb3JlIGl0IGlz IGZvcndhcmRlZCB0byBzdWNoIFVBLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pi0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJvbWFuIFNocG91bnQgJmx0O3JvbWFuQHRl bHVyaXguY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IHRpaXN0YWkgMi4gbWFycmFza3V1dGEg MjAyMSAxMC40MTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFViZXJ0aSAmbHQ7anViZXJ0aUBhbHBo YWV4cGxvcmF0aW9uY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs7IEp1c3RpbiBVYmVydGkgJmx0 O2p1c3RpbkB1YmVydGkubmFtZSZndDs7IFJUQ1dlYiBJRVRGICZsdDtydGN3ZWJAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXb3JraW5nIEdyb3VwIExhc3Qg Q2FsbCBmb3IgZHJhZnQtdWJlcnRpLXJ0Y3dlYi1yZmM4ODI5YmlzLTAxLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gTW9uLCBOb3YgMSwgMjAyMSBhdCAyOjUyIFBNIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9 Im1haWx0bzpqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb20iPmp1YmVydGlAYWxwaGFleHBs b3JhdGlvbmNvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBQUk9CTEVNIGlzIHRoYXQgd2UgaGF2ZSB0d28gZW5kcG9pbnRzLCB3aGVyZSBvbmUgc2Vu ZHMgYSBzdWJzZXF1ZW50IG9mZmVyLCBhbmQgdGhlIG90aGVyIG9uZSBleHBlY3RzIGFuIGluaXRp YWwgb2ZmZXIuIFdoYXQgZG8geW91IG5vcm1hbGx5IGRvIHdoZW4geW91IGhhdmUgdGhhdCBraW5k IG9mIHByb2JsZW0/IFlvdSB1c2UgYW4gU0JDL0IyQlVBLiBJbiB0aGlzIGNhc2UgdGhhdCBTQkMv QjJCVUEgd291bGQNCiBiZSB0aGUgM1BDQyBjb250cm9sbGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgbXkgc3VnZ2VzdGlvbiB3b3Vs ZCBiZSB0byByZW1vdmUgdGhlIFNIT1VMRCB0ZXh0IGZyb20gODg0M2JpcywgYW5kIHNpbXBseSBh ZGQgYSBub3RlIHNvbWV3aGVyZSAoaW4gODg0M2JpcyBhbmQvb3IgODgyOWJpcykgd2hpY2ggZGVz Y3JpYmVzIHRoZSBpc3N1ZSBhbmQgc2F5cyB0aGF0IHRoZSAzR1BQIGNvbnRyb2xsZXIgbmVlZHMg dG8gbW9kaWZ5IHRoZSBvZmZlciBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb21hbiwgdGhvdWdodHMgb24gdGhpcz8gSWYgdGhlIDNQQ0Mg aXMgZ29pbmcgdG8gcmV3cml0ZSB0aGUgb2ZmZXIgU0RQIGFueXdheSB0aGVuIG1heWJlIGFkZGlu ZyBhPWJ1bmRsZS1vbmx5IGlzbid0IHRoZSBlbmQgb2YgdGhlIHdvcmxkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgb3Bwb3NlZCB0byZuYnNwO3RoaXMgaWRlYS4gM1BDQyB0 eXBpY2FsbHkga25vd3MgdGhhdCB0aGUgc3Vic2VxdWVudCBvZmZlciBpcyBnb2luZyB0byBiZSB1 c2VkIGFzIGluaXRpYWwsIGFuZCBzaG91bGQgYmUgYWJsZSB0byByZXdyaXRlIHRoZSBvZmZlciB0 byBtYWtlIGl0IHZhbGlkLiBXZSBjYW4gY2hhbmdlJm5ic3A7U0lQIENvbnNpZGVyYXRpb25zIHNl Y3Rpb24gaW4gODg0M2JpcyAoPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9p ZC9kcmFmdC1pZXRmLW1tdXNpYy1yZmM4ODQzYmlzLTA1Lmh0bWwjbmFtZS1zaXAtY29uc2lkZXJh dGlvbiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLW1tdXNpYy1y ZmM4ODQzYmlzLTA1Lmh0bWwjbmFtZS1zaXAtY29uc2lkZXJhdGlvbjwvYT4pLA0KIHJlbW92ZSB0 aGUgU0hPVUxELCBhbmQgc3BlY2lmeSB0aGF0IDNQQ0MgY29udHJvbGxlciBzaG91bGQgZml4IHRo ZSBvZmZlci4gV2UgY2FuIHRoZW4gcmVmZXJlbmNlIHRoaXMgbm90ZSBmcm9tIDg4MjliaXMgb3Ig cmVzdGF0ZSB0aGUgc2FtZSBndWlkYW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR07MB44412A75040C64BB77431AF3938B9HE1PR07MB4441eurp_-- From nobody Tue Nov 2 09:34:10 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC333A086C for ; Tue, 2 Nov 2021 09:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=telurix.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 1jrlN4Ndx4I9 for ; Tue, 2 Nov 2021 09:34:03 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 2F2143A0867 for ; Tue, 2 Nov 2021 09:34:02 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id t40so19375038qtc.6 for ; Tue, 02 Nov 2021 09:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ho0H0F/gyuDjSPhf0Yvk3zTwEJm4o3gxiYiG90BzCTI=; b=bVgTgC51WOyTQz2m9R5BG3ExzBxJ3tb3efVEOiiAKVgxU/QUruXOScNHIpQo4FD3mj vVnRVUc459kAYFyFkkl4owvIJaRmHE3cK/ig3FXH0ISxcjzGIwP5dJpst3S+vigGKZFL XSrmpLKfO5+YHDPiMZXOZvbcxZS9LqJDJ33gw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ho0H0F/gyuDjSPhf0Yvk3zTwEJm4o3gxiYiG90BzCTI=; b=TgVz0ckqm3kqQwyhkZDEdUn5GRl+qAd4zj5Zb+Zh/fxGGiom17PNxanVMeL7EqHsfh dFsuPrWCXuZCgjbkDeZJwRauUCYgoEHAjy3wy31xJtw1kw9P246voUMVCzNBv2CIrEYj eXW3LP0NR6h3hYi/m5xryj9f3dLWCNaxzXK2OukDNAoqWfSu4GrqXlXnAZfi0ZIBtsMN pa3lpH2l1iRCaqAhxHeQ8XkFXMa6WzqeA7AjkE+1rhIEoo8osK7Al1s+MrSaFCVuvMqH /YLeLeynHHd3c5D/HcljIaWJDLdH/thAkNOGghqtFwWlwzzU+H7qNpNtxUD7GKlNAYBC PMkA== X-Gm-Message-State: AOAM533TqG390c+HQwg+egpFdGHqCRUhXwUQhtHNwkmT6z9UA6jCz/UJ 4NcV7TUAKnfdm3tlr332GkIB74CcXQtPRQ== X-Google-Smtp-Source: ABdhPJyBiWKiOoZZtPwxjD4tP/qe4Ok9NO2+u7UDKq1X1P5QrmqFJSeYm3Uxgz115c3pFF5vvlMFMA== X-Received: by 2002:ac8:5910:: with SMTP id 16mr14847493qty.38.1635870839634; Tue, 02 Nov 2021 09:33:59 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id k19sm6457156qta.82.2021.11.02.09.33.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Nov 2021 09:33:59 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id a129so41389459yba.10 for ; Tue, 02 Nov 2021 09:33:59 -0700 (PDT) X-Received: by 2002:a25:f205:: with SMTP id i5mr40766246ybe.61.1635870838617; Tue, 02 Nov 2021 09:33:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 2 Nov 2021 12:33:47 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Justin Uberti , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003bfae605cfd0dcee" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 16:34:08 -0000 --0000000000003bfae605cfd0dcee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e., a subsequent offer, will be used by a 3PCC controller to establish a new session and forwarded as an initial offer to another endpoint that is currently not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers. It cannot be assumed that a subsequent offer is a valid initial offer and that the endpoint that expects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer before it is used to establish a new session. To make the subsequent offer a valid initial offer, 3PCC will need to modify all the non-tagged m=3D lines to include the bundle-only attribute and set the = m=3D line port to zero. _____________ Roman Shpount On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > What about something like this: > > > > --- > > > > OLD: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > > In such cases, the User Agent Server (UAS) will include an SDP Offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > > From a BUNDLE perspective, such SDP Offer SHOULD be generated using the > procedures defined in Section 7.2.=E2=80=9D > > > > NEW: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > > In such cases, the User Agent Server (UAS) will include an SDP offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > > > > In some 3PCC scenarios the UAS will be part of an ongoing session, and > will therefore include a subsequent offer in the 200 OK responses. The > offer will be > > received by a 3PCC controller (UAC) and then forwarded as an initial offe= r > to another User Agent (UA) that is currently not part of a session. > > > > When the BUNDLE mechanism is used, as an initial BUNDLE offer look > different than a subsequent BUNDLE offer, it cannot be assumed that a UA > that expects an initial offer > > will be able to properly process a subsequent offer. Therefore, the 3PCC > controller needs to act as a Back-To-Back User Agent (B2BUA), and when it > receives the subsequent > > offer it needs to rewrite it into an initial offer before it is forwarded > to such UA.=E2=80=9D > > > > ---- > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > *From:* Roman Shpount > *Sent:* tiistai 2. marraskuuta 2021 10.41 > *To:* Justin Uberti > *Cc:* Christer Holmberg ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > > The PROBLEM is that we have two endpoints, where one sends a subsequent > offer, and the other one expects an initial offer. What do you normally d= o > when you have that kind of problem? You use an SBC/B2BUA. In this case th= at > SBC/B2BUA would be the 3PCC controller. > > > > So, my suggestion would be to remove the SHOULD text from 8843bis, and > simply add a note somewhere (in 8843bis and/or 8829bis) which describes t= he > issue and says that the 3GPP controller needs to modify the offer > accordingly. > > > > Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP > anyway then maybe adding a=3Dbundle-only isn't the end of the world. > > > > I am not opposed to this idea. 3PCC typically knows that the subsequent > offer is going to be used as initial, and should be able to rewrite the > offer to make it valid. We can change SIP Considerations section in 8843b= is > ( > https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name= -sip-consideration), > remove the SHOULD, and specify that 3PCC controller should fix the offer. > We can then reference this note from 8829bis or restate the same guidance= . > > _____________ > Roman Shpount > > > --0000000000003bfae605cfd0dcee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How about we replace the SIP Considerations with:

=
3PCC Considerations

In some 3PCC sc= enarios, an offer generated during an ongoing session, i.e., a subsequent o= ffer, will be used by a 3PCC controller to establish a new session and forw= arded as an initial offer to another endpoint that is currently not part of= a session.

For example, the Session Initiation Protocol (SIP) [RFC3= 261] allows a User Agent Client (UAC) to send a re-INVITE request without a= n SDP body (sometimes referred to as an empty re-INVITE). In such cases, th= e User Agent Server (UAS) will include an SDP offer in the associated 200 O= K response. If UAS is a part of an ongoing session, it will include a subse= quent offer in the 200 OK response. The offer will be received by a 3PCC co= ntroller (UAC) and then forwarded to another User Agent (UA) as an initial = offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is= constructed using different rules than subsequent BUNDLE offers. It cannot= be assumed that a subsequent offer is a valid initial offer and that the e= ndpoint that expects an initial offer will properly process such a subseque= nt offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offe= r into a valid initial offer before it is used to establish a new session. = To make the subsequent offer a valid initial offer, 3PCC will need to modif= y all the non-tagged m=3D lines to include the bundle-only attribute and se= t the m=3D line port to zero.
_____________
Ro= man Shpount


On Tue, Nov 2, 2021 at 6:00 AM Christer Ho= lmberg <christer.holmb= erg@ericsson.com> wrote:

Hi,

=C2=A0

What about something like this:=

=C2=A0

---

=C2=A0

OLD:

=C2=A0

=E2=80=9CThe Session Initiation= Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INV= ITE request without an SDP body (sometimes referred to as an empty re-INVIT= E).

In such cases, the User Agent S= erver (UAS) will include an SDP Offer in the associated 200 OK response. Th= is is typically used for 3rd Party Call Control (3PCC) scenarios.

From a BUNDLE perspective, such= SDP Offer SHOULD be generated using the procedures defined in Section 7.2.= =E2=80=9D

=C2=A0

NEW:

=C2=A0

=E2=80=9CThe Session Initiation= Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INV= ITE request without an SDP body (sometimes referred to as an empty re-INVIT= E).

In such cases, the User Agent S= erver (UAS) will include an SDP offer in the associated 200 OK response. Th= is is typically used for 3rd Party Call Control (3PCC) scenarios.

=C2=A0

In some 3PCC scenarios the UAS = will be part of an ongoing session, and will therefore include a subsequent= offer in the 200 OK responses. The offer will be

received by a 3PCC controller (= UAC) and then forwarded as an initial offer to another User Agent (UA) that= is currently not part of a session.

=C2=A0

When the BUNDLE mechanism is us= ed, as an initial BUNDLE offer look different than a subsequent BUNDLE offe= r, it cannot be assumed that a UA that expects an initial offer

will be able to properly proces= s a subsequent offer. Therefore, the 3PCC controller needs to act as a Back= -To-Back User Agent (B2BUA), and when it receives the subsequent<= /u>

offer it needs to rewrite it in= to an initial offer before it is forwarded to such UA.=E2=80=9D

=C2=A0

----

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Roman Shpount <roman@telurix.com>
Sent: tiistai 2. marraskuuta 2021 10.41
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ub= erti <justin@ube= rti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

=C2=A0

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <juberti@al= phaexplorationco.com> wrote:

The PROBLEM is that we have two endpoints, where one= sends a subsequent offer, and the other one expects an initial offer. What= do you normally do when you have that kind of problem? You use an SBC/B2BU= A. In this case that SBC/B2BUA would be the 3PCC controller.

=C2=A0

So, my suggestion would be to remove the SHOULD text= from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bis) = which describes the issue and says that the 3GPP controller needs to modify= the offer accordingly.

=C2=A0

Roman, thoughts on this? If the 3PCC is going to rew= rite the offer SDP anyway then maybe adding a=3Dbundle-only isn't the e= nd of the world.

=C2=A0

I am not opposed to=C2=A0this idea. 3PCC typically k= nows that the subsequent offer is going to be used as initial, and should b= e able to rewrite the offer to make it valid. We can change=C2=A0SIP Consid= erations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-= sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. = We can then reference this note from 8829bis or restate the same guidance.<= u>

_____________
Roman Shpount

=C2=A0

--0000000000003bfae605cfd0dcee-- From nobody Tue Nov 2 10:24:41 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF4A3A08FA for ; Tue, 2 Nov 2021 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 NLVTvroQNI8n for ; Tue, 2 Nov 2021 10:24:35 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70053.outbound.protection.outlook.com [40.107.7.53]) (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 A44DB3A089C for ; Tue, 2 Nov 2021 10:24:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=awFQBGf2HsdZ4Ra7u9MsBEq6xMPFWPdKuCdFnCfhIo3awZIEcMmvl4AjwJsfe4qC83g/9nIojyoJVA/2hFue1UzJhr3XoCSc2Qgqp36g+NFwquAle8wOfwMHhOcSQxqsmFVP/mmnMKZOVMjUa7O9d5gKHtnEKeZ0AL82ZdKOfLpFvtR5CQvJlcXNTzovVxdYEYVeEhwrSRxwSuC6cJ0kFyi4gnmP7kIqSHEjh6rmLbhu43vgO4QIKBPd/ymadl6HJaeemIiS1BDT+Q9SauvVLXZpt5Jic21GEeXSWDeyfbCJ1qtY3EJ85STdcd/worPVRQ2m3WVtsJKK8QFfnK4zHw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ultv1a11gO2moAhfJQ9Qp2CjzWrQUFhhCA/m/NDQ5/g=; b=nWhHh9KHuFMpHLc28Bt3oduis3CgQWNZidDPbOudkQKHzST0JQAXJm9b0Q96/W/tPdeBYhlQBIR3hU2Pz7q9t6/vbJdPLAroiHxwDmJorrmyiD71MPNYkyQEMMBd8901NoH9NE+AaCIbI9dhz5KIOMADSHFqbsSqo/Y/kMD3KqfcNM2RINL+1OaLxmgphlhZTr/AF7JiM19QVd9F715sfTMRqsL1qoetCIlAzehOSAQTHssUe+Qje0YmPDqY7vcWKiuj1YL9uIybBlMDBqZIsRyIVhQ3kl2loYwuYVKgI298UBtUB50Nmc8zITJjEbbdICU3NG4knKu7mnoJXR+J+Q== 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=ultv1a11gO2moAhfJQ9Qp2CjzWrQUFhhCA/m/NDQ5/g=; b=my2zplqoq2V0FCIW5IkDbgQF3k0KoinCawILjK/tveujzteXKwX+MQsmFTPgNRJABQ/CyPJbAclkyYkdX7OwBFWA810An/4WQPJoq9+cS5mpN6Jg89oiKwJBkg54YnQp2j8qJV3RNMiFblnwAMAz952zRwT403S7NaiuYQrI+qY= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR07MB3340.eurprd07.prod.outlook.com (2603:10a6:7:31::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.6; Tue, 2 Nov 2021 17:24:26 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.010; Tue, 2 Nov 2021 17:24:26 +0000 From: Christer Holmberg To: Roman Shpount CC: Justin Uberti , Justin Uberti , RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B32AAGQiAIAA528AgAASO+CAAHHigIAABbSh Date: Tue, 2 Nov 2021 17:24:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 498dfa59-6879-4833-541a-6ab514c8e127 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 283dc4e1-4aa8-4a2a-cf9c-08d99e259ebf x-ms-traffictypediagnostic: HE1PR07MB3340: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /SdiSfEyVvwTXYXFPdUXa/FnNZMmaNSv607fnd7QWDJCiDWklnLsZQDRUdBWMmngBy/0DYc7UTTvgq4FuHQgzJIc+wAGogOFdVYwv9j9dGfOOemKCInULOeTtU+RA4R5ep8FoiRhdqKsrdrA0buW4+VGZjHxtcfnt6Cm5y/2p1wd4cvvc1m3oxrjPsUI5LayoWcbX+sAD/npHr3VYOm6YGtKbCsSBF3X7zvIag8yKV692Ls+QXSUlIZy5c3yY0P+ejKY77G225lmEB5qp+ITAqnNweOx3iuQn4Ao6VEKmBrDlwC5KvZG/3LMZ3fWXnnDOODqEbnNbjWa9xA1Mf8WWJRKjP44W/XuA5I+ZR17IWf656jMc8F8e7A7L+t1crVFha0lkAxtJG6K1gHHdsSgZ2qz2JkZtK4DqabH9lgmcOb4oRxKXMjQFsUqT5/vSSvEdQtnbrNmZkUqNIielROEArArA7vCYUi5+Du67EZxdHMkTtB6O6QMlmZnifsMP+SPn1Z+O+rUFW6Sz3Oke77rvOOl5bKfNkq3O7nuXnhpuKlCNYVTtT0duGoEa2pWum0/sMnFbJdNngDDQn4xcHNE25B+AStkXyFnQ5LlbmGfbHivuVRqvoeeshxH7Vt226Cic+o6xp/v/DUJ64fDwdNumP1OmPucoUwYlGIKSohyuxc5UOcfOTrxsicfKnXbaq+17twvBXic5MoBJOjYBC7TjUgY6E4KxmYkO//RTpiz3qBFYE3co/k8quBF2HLqNE7c5d7eJpx1yXlESha74F/tNkM2cQFWEHR4lH+SyWQmMk8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(64756008)(66556008)(66476007)(186003)(83380400001)(71200400001)(316002)(55016002)(66446008)(76116006)(7696005)(8936002)(4326008)(82960400001)(38070700005)(54906003)(19627405001)(6506007)(5660300002)(9686003)(44832011)(2906002)(122000001)(86362001)(508600001)(38100700002)(8676002)(33656002)(6916009)(166002)(53546011)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?Jaoap0rA4FPRNl6Ssl4hc8cjMp4IWIocxriXhJxiGePYewQigHQ81XSp?= =?Windows-1252?Q?AZqjN3Z/ldumggc4aAZikOolyx93oBmUxAvhFr6F5+ulmdcvXZD4VIC+?= =?Windows-1252?Q?sMh2657snnRp1rH0NcbOKuYPkmGKjNjrGQJsZ8M9kSDrO5BVNCeTz+HO?= =?Windows-1252?Q?eIzd17N+zLcrIH2cZhnuDngZDJxN0zRp7sgYf57ZCKmSR8f8mG2FQHE5?= =?Windows-1252?Q?zGw7n2oVjDOVlWIIksm8cLbR/LYMWkwzNrLPgp0SY1CBYE0M4149zKSn?= =?Windows-1252?Q?EGAthGq/2Fv2Mxu/CkOQWpjI6YEdjtX9c6Ix//AezomhyEcBNNQ98fAY?= =?Windows-1252?Q?maS+Tn0QcurmhioeJEgclbhah+uNWb/aP+kh5ljivqbqpdyBDzP5JSRs?= =?Windows-1252?Q?eMbF4U/YHvh0z45Oydrzh6gwaq6X5cnyrMr0rwaQCqgrBxP4SOpmk2JQ?= =?Windows-1252?Q?g/Rv2kx2BhCMK1bD0ZdE5wIXno2MbfqkbTLg/GqMJMj085Q9KkWMp5kP?= =?Windows-1252?Q?26iQDxrKDkJesHt9jffr6u722vKQVqZYoqsR5U/Pepm8WnApwVHnSSrr?= =?Windows-1252?Q?k07cTpJSR1yMaP4a46fJ9vrmlAT/whpN5jcqAUyX+MU7uRFmL1V8wwbY?= =?Windows-1252?Q?dD9lHGawJwYK65lEtF9hhorjT//X+4FtR6v+fDhjQLMt7v70EE1Z9McG?= =?Windows-1252?Q?DimrIy83cqJTzFbgx6rqf4Mvxf2iY53yvSMWRB/8tOytUYPLPV114h0t?= =?Windows-1252?Q?hebrSQAs4GQsniGU/ZU/LN4+BIbOerPhD3dFBcHT4aIOgV0r+jiPehGh?= =?Windows-1252?Q?bgH61cCJ+F9zbZaLwiGa/bEXwA0MbZI8WFnXxpuL3yB+m6W9l9fcvdDP?= =?Windows-1252?Q?eprT2Mlg86A1EpM6L1Q4srb82DRSOkU7jIok1I/aTc+rrbXmVR+LY5L+?= =?Windows-1252?Q?owIafevolcKnpme3ELRRT2k43aCcF9DBSnjpdteIRiz4qp6WWqeCn/8W?= =?Windows-1252?Q?NwFZ1L29wUTdqtRMTd5gVE4H7acrUuEk9ynZ2tEb6cAjnNddMkzTkE1g?= =?Windows-1252?Q?zj6vrAj0hpKyXQ5g2AaroLG2RftVBz1wn9ih+aw0uV2mS2ehtHcH6w6Z?= =?Windows-1252?Q?R6tbByWMzEllOJ2nVgthkPxTisOh5IhOPkP395ADJM6KX2OhkggZWx3q?= =?Windows-1252?Q?kMIFhdQSYsR7lT2scGp2zKXVAtAHBpcxFvNVgAyN55f3u8BsThrVEks8?= =?Windows-1252?Q?NekphpWHPsroCd4FsdIwMo+FTyK4jkErMnzWtp7YT64R9Vf0gSB8S0PW?= =?Windows-1252?Q?+UKmkQYRSEfJ3HscGOrwUO7vGh7zM7lvKp8ftDBgG8gixnQwrJqgVEdG?= =?Windows-1252?Q?kGJND+KeH53L1knLdf+hfxo22qA35evBX6rAQDLWTjDtRSTozehbXT5H?= =?Windows-1252?Q?OQRclJwch1Bbr+nLBjO4aFsiUPNEm/tD2vt7ENxE3I+NNx0zIVHAZqoz?= =?Windows-1252?Q?B1Jby2Q2PVI2bu2dx2XI7Slqcq4UdbwTsnjUZgjQjZaQ+0JE7HWCqrpA?= =?Windows-1252?Q?CNHQ9ek1+cuzhpaLIwqO6GQANUpaOxgs40Sqiwib3BUyfBVTi42VDaS4?= =?Windows-1252?Q?b57pEQUEQ6rtUGOliZHgCdfaZeJQSES8pPMtBXQ5W2k68/Cgq3BFSSsP?= =?Windows-1252?Q?bbEWWJIcOiPqWUNRsEduCaKZgksnQS2vCnDuBPJOeW4hWbj+jdeUHEHo?= =?Windows-1252?Q?cnNWXOdtVFuVrUhbWS65AYzTYyboFRAYfEabiCWUIVcGrUXKfsVQQ21E?= =?Windows-1252?Q?lU01yLNBzUKN91E7wgEtVeeS0TP6cZbzpcl5t6sIa3uurMGEsxiE5Ir/?= =?Windows-1252?Q?bAqeOtdPXEA89w=3D=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4441227681F78AB294E1E5FC938B9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 283dc4e1-4aa8-4a2a-cf9c-08d99e259ebf X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2021 17:24:26.2455 (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: s34U/d1wYZv1RpZoYIr2hLoKkvsJCItylQHg4zUdZZkF6eVPgJSLimEnfluTTWG7CQ687PdP7b/SU1rejbuJyx0J0VPCzmw0mQLptN0DsCA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3340 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 17:24:40 -0000 --_000_HE1PR07MB4441227681F78AB294E1E5FC938B9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Eventhough I would not like to make more changes than necessary, I am fine = with "3PCC Considerations". However, your suggested text is very difficult to understand in some places= , so let me give it a try. (The first paragraph is generic, the second SIP specific, and the third BUN= DLE specific.) --- 3PCC Considerations In some 3PCC scenarios a new session will be established between an endpoin= t that is currently part of an ongoing session and an endpoint that is curr= ently not part of an ongoing session. The endpoint that is part of a sessio= n will generate a subsequent offer that will be forwarded to the other endp= oint by a 3PCC controller. The endpoint that is not part of a session will = process the offer as an initial offer. The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client = (UAC) to send a re-INVITE request without an SDP body (sometimes referred t= o as an empty re-INVITE). In such cases, the User Agent Server (UAS) will i= nclude an SDP offer in the associated 200 OK response. If the UAS is a part= of an ongoing session, it will include a subsequent offer in the 200 OK re= sponse. The offer will be received by a 3PCC controller (UAC) and then forw= arded to another User Agent (UA). If the UA is not part of an ongoing sessi= on, it will process the offer as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer in= to a valid initial offer, following the procedures in (Section 7.2), before= it forwards the offer to a UA. In the rewritten offer the 3PCC controller = will set the port value to zero (and include an SDP 'bundle-only' attribute= ) for each "m=3D" section within the BUNDLE group, excluding the offerer-ta= gged "m=3D" section. ________________________________ From: Roman Shpount Sent: Tuesday, November 2, 2021 6:33 PM To: Christer Holmberg Cc: Justin Uberti ; Justin Uberti ; RTCWeb IETF Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e.,= a subsequent offer, will be used by a 3PCC controller to establish a new s= ession and forwarded as an initial offer to another endpoint that is curren= tly not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS = is a part of an ongoing session, it will include a subsequent offer in the = 200 OK response. The offer will be received by a 3PCC controller (UAC) and = then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Ther= efore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid= initial offer before it is used to establish a new session. To make the su= bsequent offer a valid initial offer, 3PCC will need to modify all the non-= tagged m=3D lines to include the bundle-only attribute and set the m=3D lin= e port to zero. _____________ Roman Shpount On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg > wrote: Hi, What about something like this: --- OLD: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the pro= cedures defined in Section 7.2.=94 NEW: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will= therefore include a subsequent offer in the 200 OK responses. The offer wi= ll be received by a 3PCC controller (UAC) and then forwarded as an initial offer = to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look differen= t than a subsequent BUNDLE offer, it cannot be assumed that a UA that expec= ts an initial offer will be able to properly process a subsequent offer. Therefore, the 3PCC co= ntroller needs to act as a Back-To-Back User Agent (B2BUA), and when it rec= eives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded t= o such UA.=94 ---- Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti > wrote: The PROBLEM is that we have two endpoints, where one sends a subsequent off= er, and the other one expects an initial offer. What do you normally do whe= n you have that kind of problem? You use an SBC/B2BUA. In this case that SB= C/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simp= ly add a note somewhere (in 8843bis and/or 8829bis) which describes the iss= ue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyw= ay then maybe adding a=3Dbundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent off= er is going to be used as initial, and should be able to rewrite the offer = to make it valid. We can change SIP Considerations section in 8843bis (http= s://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-c= onsideration), remove the SHOULD, and specify that 3PCC controller should f= ix the offer. We can then reference this note from 8829bis or restate the s= ame guidance. _____________ Roman Shpount --_000_HE1PR07MB4441227681F78AB294E1E5FC938B9HE1PR07MB4441eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

Eventhough I would not like to make more changes than necessary, I am fine = with "3PCC Considerations".

However, your suggested text is very difficult to understand in some places= , so let me give it a try.

(The first paragraph is generic, the second SIP specific, and the third BUN= DLE specific.)

---

3PCC Considerations<= /span>

In some 3PCC scenarios a new session will be established between an endpoin= t that is currently part of an ongoing session and an endpoint that is curr= ently not part of an ongoing session. The endpoint that is part of a sessio= n will generate a subsequent offer that will be forwarded to the other endpoint by a 3PCC controller. The end= point that is not part of a session will process the offer as an initial of= fer. 

The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client = (UAC) to send a re-INVITE request without an SDP body (sometimes referred t= o as an empty re-INVITE). In such cases, the User Agent Server (UAS) will i= nclude an SDP offer in the associated 200 OK response. If the UAS is a part of an ongoing session, it will inclu= de a subsequent offer in the 200 OK response. The offer will be received by= a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If = the UA is not part of an ongoing session, it will process the offer as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following = the procedures in (Section 7.2), before it forwards the offer to a UA. In t= he rewritten offer the 3PCC controller will set the port value to zero (and= include an SDP 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, excluding the o= fferer-tagged "m=3D" section.






From: Roman Shpount <rom= an@telurix.com>
Sent: Tuesday, November 2, 2021 6:33 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Justin Uberti <juberti@alphaexplorationco.com>; Justin Ube= rti <justin@uberti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt
 
How about we replace the SIP Considerations with:

3PCC Considerations

In some 3PCC scenarios, an offer generated during an ongoing session, = i.e., a subsequent offer, will be used by a 3PCC controller to establish a = new session and forwarded as an initial offer to another endpoint that is c= urrently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session,= it will include a subsequent offer in the 200 OK response. The offer will = be received by a 3PCC controller (UAC) and then forwarded to another User A= gent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rew= rite the subsequent offer into a valid initial offer before it is used to e= stablish a new session. To make the subsequent offer a valid initial offer,= 3PCC will need to modify all the non-tagged m=3D lines to include the bundle-only attribute and set the m= =3D line port to zero.
_____________
Roman Shpount


On Tue, Nov 2, 2021 at 6:00 AM Chri= ster Holmberg <christe= r.holmberg@ericsson.com> wrote:

Hi,

 

What about something like thi= s:

 

---

 

OLD:

 

=93The Session Initiation Pro= tocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE = request without an SDP body (sometimes referred to as an empty re-INVITE).<= u>

In such cases, the User Agent= Server (UAS) will include an SDP Offer in the associated 200 OK response. = This is typically used for 3rd Party Call Control (3PCC) scenarios.

From a BUNDLE perspective, su= ch SDP Offer SHOULD be generated using the procedures defined in Section 7.= 2.=94

 

NEW:

 

=93The Session Initiation Pro= tocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE = request without an SDP body (sometimes referred to as an empty re-INVITE).<= u>

In such cases, the User Agent= Server (UAS) will include an SDP offer in the associated 200 OK response. = This is typically used for 3rd Party Call Control (3PCC) scenarios.

 

In some 3PCC scenarios the UA= S will be part of an ongoing session, and will therefore include a subseque= nt offer in the 200 OK responses. The offer will be

received by a 3PCC controller= (UAC) and then forwarded as an initial offer to another User Agent (UA) th= at is currently not part of a session.

 

When the BUNDLE mechanism is = used, as an initial BUNDLE offer look different than a subsequent BUNDLE of= fer, it cannot be assumed that a UA that expects an initial offer

will be able to properly proc= ess a subsequent offer. Therefore, the 3PCC controller needs to act as a Ba= ck-To-Back User Agent (B2BUA), and when it receives the subsequent

offer it needs to rewrite it = into an initial offer before it is forwarded to such UA.=94

 

----

 

Regards,=

 

Christer=

 

 

 

 

 

 

 

 

From: Roman Shpount <roman@telurix.com>
Sent: tiistai 2. marraskuuta 2021 10.41
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ub= erti <justin@ube= rti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

 

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <<= a href=3D"mailto:juberti@alphaexplorationco.com" target=3D"_blank">juberti@= alphaexplorationco.com> wrote:

The PROBLEM is that we have two endpoints, where o= ne sends a subsequent offer, and the other one expects an initial offer. Wh= at do you normally do when you have that kind of problem? You use an SBC/B2= BUA. In this case that SBC/B2BUA would be the 3PCC controller.

 

So, my suggestion would be to remove the SHOULD te= xt from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bis= ) which describes the issue and says that the 3GPP controller needs to modi= fy the offer accordingly.

 

Roman, thoughts on this? If the 3PCC is going to r= ewrite the offer SDP anyway then maybe adding a=3Dbundle-only isn't the end= of the world.

 

I am not opposed to this idea. 3PCC typically= knows that the subsequent offer is going to be used as initial, and should= be able to rewrite the offer to make it valid. We can change SIP Cons= iderations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#nam= e-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. = We can then reference this note from 8829bis or restate the same guidance.<= u>

_____________
Roman Shpount

 

--_000_HE1PR07MB4441227681F78AB294E1E5FC938B9HE1PR07MB4441eurp_-- From nobody Tue Nov 2 10:53:47 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8803A3A0965 for ; Tue, 2 Nov 2021 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=telurix.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 nnw31yEF6Ity for ; Tue, 2 Nov 2021 10:53:41 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 053523A0962 for ; Tue, 2 Nov 2021 10:53:40 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id v22so1967154qtk.9 for ; Tue, 02 Nov 2021 10:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J3lwzxOhA0V8QQa21ckj7Ah9AKIhIc+Mom2Fpa/x/i8=; b=HzCGMnpMOcUyKbII6E+TxS55j3gL7FyFotrTjglj4ZK/JzmlPIT5liv7WXp8eERH2T 4G1ksHXdQqa6Y1cOP0BhrezinRmN03ZoxoUwUPg6F90d89vGxLXZQkYHL3p5FX4e3rRY lEQbaRYQwBHhx7DyX7kqkxB2fl4d0EWwMi6v4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J3lwzxOhA0V8QQa21ckj7Ah9AKIhIc+Mom2Fpa/x/i8=; b=uNwVGpbPw+PjJcBNLAqn33s+brSeVIdQmvM4ir6r5QinVkxZldrkRuhEdYNYChb/on UDla8Y2qcxt5pTm2z/rq8lqs6wvqurnT4uTmeMi51aOgzoRMg/AjNH7sdy4v9+1ljIj/ XYcQ2b9k8lMFmWF/vduPgHoP7QVfAxg9WQNDZtEGYHlmay1ttrhfCJGc/EzoGT4wTxFm al1XNhH6xcgdug+wGWYaEec4slrHLxcAvXKZjJJG6hjZrA+auyK/Me5E4J66d/AKK12l APbMc4uEpLV+V383VrnQu3foULppnis81SRflk5F0b4i3r72H8kVorZKRaKf28b2VdQy Ik3Q== X-Gm-Message-State: AOAM532wkjV8qTNj14wKhzaDz32JjNEp24cDdBizFydZBYEgF3sfnlQA 3kdB/WEEjqopUo1kcd0WC4j7X3/bEMH1hg== X-Google-Smtp-Source: ABdhPJyowG5+c7Q8cuecEHv5PEPOte2AuRcG8VPiAosM+zJ/O3xMQ1qDyrBGzhKZV+eLMmb4ZinnJA== X-Received: by 2002:ac8:615c:: with SMTP id d28mr38070813qtm.103.1635875618586; Tue, 02 Nov 2021 10:53:38 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id v18sm3120598qkp.129.2021.11.02.10.53.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Nov 2021 10:53:37 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id v138so282807ybb.8 for ; Tue, 02 Nov 2021 10:53:37 -0700 (PDT) X-Received: by 2002:a25:ca58:: with SMTP id a85mr44556140ybg.155.1635875617499; Tue, 02 Nov 2021 10:53:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 2 Nov 2021 13:53:26 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Justin Uberti , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000013f05905cfd1f955" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 17:53:47 -0000 --00000000000013f05905cfd1f955 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, This makes it much better. I think it is missing a couple of commas ("In some 3PCC scenarios," and "In the rewritten offer,") but works for me. I have changed the section name so it is clear that it applies to JSEP as well, not just SIP. Best Regards, _____________ Roman Shpount On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Eventhough I would not like to make more changes than necessary, I am fin= e > with "3PCC Considerations". > > However, your suggested text is very difficult to understand in some > places, so let me give it a try. > > (The first paragraph is generic, the second SIP specific, and the third > BUNDLE specific.) > > --- > > 3PCC Considerations > > In some 3PCC scenarios a new session will be established between an > endpoint that is currently part of an ongoing session and an endpoint tha= t > is currently not part of an ongoing session. The endpoint that is part of= a > session will generate a subsequent offer that will be forwarded to the > other endpoint by a 3PCC controller. The endpoint that is not part of a > session will process the offer as an initial offer. > > The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clien= t > (UAC) to send a re-INVITE request without an SDP body (sometimes referred > to as an empty re-INVITE). In such cases, the User Agent Server (UAS) wil= l > include an SDP offer in the associated 200 OK response. If the UAS is a > part of an ongoing session, it will include a subsequent offer in the 200 > OK response. The offer will be received by a 3PCC controller (UAC) and th= en > forwarded to another User Agent (UA). If the UA is not part of an ongoing > session, it will process the offer as an initial offer. > > When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed > using different rules than subsequent BUNDLE offers, and it cannot be > assumed that a UA is able to correctly process a subsequent offer as an > initial offer. Therefore, the 3PCC controller SHOULD rewrite the subseque= nt > offer into a valid initial offer, following the procedures in (Section > 7.2), before it forwards the offer to a UA. In the rewritten offer the 3P= CC > controller will set the port value to zero (and include an SDP > 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, > excluding the offerer-tagged "m=3D" section. > > > > > > > ------------------------------ > *From:* Roman Shpount > *Sent:* Tuesday, November 2, 2021 6:33 PM > *To:* Christer Holmberg > *Cc:* Justin Uberti ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > How about we replace the SIP Considerations with: > > 3PCC Considerations > > In some 3PCC scenarios, an offer generated during an ongoing session, > i.e., a subsequent offer, will be used by a 3PCC controller to establish = a > new session and forwarded as an initial offer to another endpoint that is > currently not part of a session. > > For example, the Session Initiation Protocol (SIP) [RFC3261] allows a Use= r > Agent Client (UAC) to send a re-INVITE request without an SDP body > (sometimes referred to as an empty re-INVITE). In such cases, the User > Agent Server (UAS) will include an SDP offer in the associated 200 OK > response. If UAS is a part of an ongoing session, it will include a > subsequent offer in the 200 OK response. The offer will be received by a > 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an > initial offer. > > When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed > using different rules than subsequent BUNDLE offers. It cannot be assumed > that a subsequent offer is a valid initial offer and that the endpoint th= at > expects an initial offer will properly process such a subsequent offer. > Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a > valid initial offer before it is used to establish a new session. To make > the subsequent offer a valid initial offer, 3PCC will need to modify all > the non-tagged m=3D lines to include the bundle-only attribute and set th= e m=3D > line port to zero. > _____________ > Roman Shpount > > > On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > What about something like this: > > > > --- > > > > OLD: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > > In such cases, the User Agent Server (UAS) will include an SDP Offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > > From a BUNDLE perspective, such SDP Offer SHOULD be generated using the > procedures defined in Section 7.2.=E2=80=9D > > > > NEW: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > > In such cases, the User Agent Server (UAS) will include an SDP offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > > > > In some 3PCC scenarios the UAS will be part of an ongoing session, and > will therefore include a subsequent offer in the 200 OK responses. The > offer will be > > received by a 3PCC controller (UAC) and then forwarded as an initial offe= r > to another User Agent (UA) that is currently not part of a session. > > > > When the BUNDLE mechanism is used, as an initial BUNDLE offer look > different than a subsequent BUNDLE offer, it cannot be assumed that a UA > that expects an initial offer > > will be able to properly process a subsequent offer. Therefore, the 3PCC > controller needs to act as a Back-To-Back User Agent (B2BUA), and when it > receives the subsequent > > offer it needs to rewrite it into an initial offer before it is forwarded > to such UA.=E2=80=9D > > > > ---- > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > *From:* Roman Shpount > *Sent:* tiistai 2. marraskuuta 2021 10.41 > *To:* Justin Uberti > *Cc:* Christer Holmberg ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > > The PROBLEM is that we have two endpoints, where one sends a subsequent > offer, and the other one expects an initial offer. What do you normally d= o > when you have that kind of problem? You use an SBC/B2BUA. In this case th= at > SBC/B2BUA would be the 3PCC controller. > > > > So, my suggestion would be to remove the SHOULD text from 8843bis, and > simply add a note somewhere (in 8843bis and/or 8829bis) which describes t= he > issue and says that the 3GPP controller needs to modify the offer > accordingly. > > > > Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP > anyway then maybe adding a=3Dbundle-only isn't the end of the world. > > > > I am not opposed to this idea. 3PCC typically knows that the subsequent > offer is going to be used as initial, and should be able to rewrite the > offer to make it valid. We can change SIP Considerations section in 8843b= is > ( > https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name= -sip-consideration), > remove the SHOULD, and specify that 3PCC controller should fix the offer. > We can then reference this note from 8829bis or restate the same guidance= . > > _____________ > Roman Shpount > > > > --00000000000013f05905cfd1f955 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

This makes it much better.= I think it is missing a couple of commas ("In some 3PCC scenarios,&qu= ot; and "In the rewritten offer,") but works for me.
I have changed the section name so it is clear that it applies= to JSEP as well, not just SIP.

Best Regards,
_____________
Roman Shpount


On= Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=
Hi,

Eventhough I would not like to make more changes than necessary, I am fine = with "3PCC Considerations".

However, your suggested text is very difficult to understand in some places= , so let me give it a try.

(The first paragraph is generic, the second SIP specific, and the third BUN= DLE specific.)

---

3PCC Considerations

In some 3PCC scenarios a new session will be established between an endpoin= t that is currently part of an ongoing session and an endpoint that is curr= ently not part of an ongoing session. The endpoint that is part of a sessio= n will generate a subsequent offer that will be forwarded to the other endpoint by a 3PCC controller. The end= point that is not part of a session will process the offer as an initial of= fer.=C2=A0

The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client = (UAC) to send a re-INVITE request without an SDP body (sometimes referred t= o as an empty re-INVITE). In such cases, the User Agent Server (UAS) will i= nclude an SDP offer in the associated 200 OK response. If the UAS is a part of an ongoing session, it will inclu= de a subsequent offer in the 200 OK response. The offer will be received by= a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If = the UA is not part of an ongoing session, it will process the offer as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following = the procedures in (Section 7.2), before it forwards the offer to a UA. In t= he rewritten offer the 3PCC controller will set the port value to zero (and= include an SDP 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, excluding the o= fferer-tagged "m=3D" section.






From= : Roman Shpount <roman@telurix.com>
Sent: Tuesday, November 2, 2021 6:33 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti= <justin@uberti.= name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt
=C2=A0
How about we replace the SIP Considerations with:

3PCC Considerations

In some 3PCC scenarios, an offer generated during an ongoing session, = i.e., a subsequent offer, will be used by a 3PCC controller to establish a = new session and forwarded as an initial offer to another endpoint that is c= urrently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session,= it will include a subsequent offer in the 200 OK response. The offer will = be received by a 3PCC controller (UAC) and then forwarded to another User A= gent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rew= rite the subsequent offer into a valid initial offer before it is used to e= stablish a new session. To make the subsequent offer a valid initial offer,= 3PCC will need to modify all the non-tagged m=3D lines to include the bundle-only attribute and set the m= =3D line port to zero.
_____________
Roman Shpount


On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:

Hi,

=C2=A0

What about something like this:

=C2=A0

---

=C2=A0

OLD:

=C2=A0

=E2=80=9CThe Session Initiation Protocol (SIP) [RFC= 3261] allows a User Agent Client (UAC) to send a re-INVITE request without = an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent Server (UAS) will inc= lude an SDP Offer in the associated 200 OK response. This is typically used= for 3rd Party Call Control (3PCC) scenarios.

From a BUNDLE perspective, such SDP Offer SHOULD be= generated using the procedures defined in Section 7.2.=E2=80=9D<= /u>

=C2=A0

NEW:

=C2=A0

=E2=80=9CThe Session Initiation Protocol (SIP) [RFC= 3261] allows a User Agent Client (UAC) to send a re-INVITE request without = an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent Server (UAS) will inc= lude an SDP offer in the associated 200 OK response. This is typically used= for 3rd Party Call Control (3PCC) scenarios.

=C2=A0

In some 3PCC scenarios the UAS will be part of an o= ngoing session, and will therefore include a subsequent offer in the 200 OK= responses. The offer will be

received by a 3PCC controller (UAC) and then forwar= ded as an initial offer to another User Agent (UA) that is currently not pa= rt of a session.

=C2=A0

When the BUNDLE mechanism is used, as an initial BU= NDLE offer look different than a subsequent BUNDLE offer, it cannot be assu= med that a UA that expects an initial offer

will be able to properly process a subsequent offer= . Therefore, the 3PCC controller needs to act as a Back-To-Back User Agent = (B2BUA), and when it receives the subsequent

offer it needs to rewrite it into an initial offer = before it is forwarded to such UA.=E2=80=9D

=C2=A0

----

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Roman Shpo= unt <roman@teluri= x.com>
Sent: tiistai 2. marraskuuta 2021 10.41
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ub= erti <justin@ube= rti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

=C2=A0

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <juberti@alphaexplorationco.com= > wrote:

The PROBLEM is that we have two endpoints, where one sends a subsequent = offer, and the other one expects an initial offer. What do you normally do = when you have that kind of problem? You use an SBC/B2BUA. In this case that= SBC/B2BUA would be the 3PCC controller.

=C2=A0

So, my suggestion would be to remove the SHOULD text from 8843bis, and s= imply add a note somewhere (in 8843bis and/or 8829bis) which describes the = issue and says that the 3GPP controller needs to modify the offer according= ly.

=C2=A0

Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP a= nyway then maybe adding a=3Dbundle-only isn't the end of the world.<= /u>

=C2=A0

I am not opposed to=C2=A0this idea. 3PCC typically knows that the subseq= uent offer is going to be used as initial, and should be able to rewrite th= e offer to make it valid. We can change=C2=A0SIP Considerations section in = 8843bis (https://www.ietf.or= g/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. = We can then reference this note from 8829bis or restate the same guidance.<= u>

_____________
Roman Shpount

=C2=A0

--00000000000013f05905cfd1f955-- From nobody Tue Nov 2 14:13:30 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72693A0AF9 for ; Tue, 2 Nov 2021 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 dyJfpzr7t0cN for ; Tue, 2 Nov 2021 14:13:22 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2040.outbound.protection.outlook.com [40.107.20.40]) (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 9CB713A0AB4 for ; Tue, 2 Nov 2021 14:13:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D30t/k6Dxu23saG6ZwkOFfxvZbHycCrRRKC5oT4yam5AZKavi37trjaAqmNNPo6xotO2Ze0NVihyU07GmyobLJdu9gDgCRbbO1JEcsQGNwI6ilJ+86Hgz9vgVTbrZeWGZDH4w3f0zbP0k9+icYQCnvObPD+cSsK6imFJicKWecpktkLiGF8xaA7pfhn3N+nhEniJYuZwdyg+32ysRC1Me9KTOz7uVJwGP99K0LYCwy0Y3/cnuyhSsEfG2pTQLrUh5qG1g8mwIcidRscv0Kvyq5RkUkm5mH/eGEA8gMg47Dyk3LS8AOAquTvQhuIlpGI3Ik1amNxsxw8tgkr7kHrtLA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Tr/Uk9ZYDRHWmkIiTzmW0z3OfKw37O7JbrPL6kRvqQ4=; b=PwZYBOYBrToEEPUN5wIadHLQjqNBRbF+hYN1t6hJvd9xF396sdaEVbOwJcV1ZDOOPJ/XXR3RwqlIHnddAmzPCP2PMvsT8CUdkdkLB6Hgr6JdAMyrPNLM0RYZTbVFMOLk2nS0owBeGg2bxfqdzP+4dha9hdeRdQahEUZWBUXuvWT1s0SAgaeOFQ5jxMxTJtFaFusTJUBpVesSpvDj74wRuap4niZ+YSd0eiidwJWkFZn0IDTBrbqp76l2tq/ae95IK5WEa+CdCV58mLzG6sFDVIiNcDp/AgNI0CvRWHL/Eo6Wee54exD/WO+qfJVDCHzvnb3tgXkQoxGLdlUbmN5f4w== 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=Tr/Uk9ZYDRHWmkIiTzmW0z3OfKw37O7JbrPL6kRvqQ4=; b=CEVQwKxLVO2HEJusqmDBxqPpTKlIP2atcf9bJghaBqbEXb2W6WPkeah+5DUFEr/NKsezoYn/S4oME/CL10BYhOk1V6tbhH0sVjGAoTmImSTC/o805uzVEvLwA8wuYQ06lX2RNqfA8qSHn22gTP0z+CpHiSSJa1f7po+iTV7Le7w= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR0701MB2186.eurprd07.prod.outlook.com (2603:10a6:3:2b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.5; Tue, 2 Nov 2021 21:13:11 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.010; Tue, 2 Nov 2021 21:13:11 +0000 From: Christer Holmberg To: Roman Shpount CC: Justin Uberti , Justin Uberti , RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B32AAGQiAIAA528AgAASO+CAAHHigIAABbShgAAQjQCAADc8UA== Date: Tue, 2 Nov 2021 21:13:11 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 79197efb-e9a6-4ea0-7e7d-08d99e4593c8 x-ms-traffictypediagnostic: HE1PR0701MB2186: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9QrFk9Pn7lSc9M0Wmz1+j/dr9rxbvcvC+ETpj0/BppQxd73jXHA7evBJ+xZXuYZdUWAoubZWau5qgG+lLUhVXYFo12J84M6z6r4dI3zY9naukom0arIHCJY0AOI7HL+/k7vnVQNPu4qKhQ2bK1IOiGu2JG2ct9R9i62KXJLzJCerBGQTtR8irOGdXxHz7jNiPzbdAaHrwBDp7vuCoqgiQxoTsEXQuN2sAF7NsO5gb9PODa8Hhok/14FLnUJ97Ej2GxH5wXcnfV/KOvb79LZgPAy1XnLCDzReT1TgfWqhWprDcWL538FecNcWx0j5re+zNuvsuUB+JleBD2rNwify7pm9QS0C2IkDkR2xfQTO1AoThMC8e7bR6+aw8Bo7tQ1pva5VSU8NgNkYE1Up7+sDA8kQgqXiQpWXNj9n1tZzIb43E9fnswGoNAzlx7rhipRs3zXYTOj0u+1mqdimV27DIvWAmt531+BpnE4AxvNsvllddN0Zn1a9Eu9zOWV599F0JOU6wozBCuvEqFIPmiaWP1EeWXUX8KItFYoGsQ4z+eWkBSs0p6P0DZfR+fQj14tltIXEJNhfmWukCIpRSUr5m5aB37+Zp01hXjKhVjpvCgX6Wsx1uzPRfK7CC/Ml6Xb1XMdrP0a1li0KYjTLhMMtIvxXU/9U5FYC2mckzBzbf1EA82VBvT6rLqcHNGEwrqMbpTdFsU9J4Kz9qK1kv94CC7ZSNtheQ02oPLYSOLbUQ1Y6Nrt+uesRY23EpUreSNCl19dd4Akap5hzSxtfiZ9bGLKzFe/RQ0VJhJG65q9HDE8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(9686003)(508600001)(316002)(83380400001)(8936002)(186003)(7696005)(26005)(166002)(53546011)(6506007)(6916009)(54906003)(82960400001)(38100700002)(8676002)(5660300002)(33656002)(86362001)(71200400001)(52536014)(122000001)(66946007)(55016002)(76116006)(66446008)(66476007)(64756008)(66556008)(44832011)(38070700005)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NWxXYWd6OExrQ2cxM2ZES0I5UzZKY3RuQ21LbXVNbmYwRHBqQkY0US9XTC91?= =?utf-8?B?Rjl5WERIb1pCWENSWmJFS2YwbS9LZ3dLYVNtOXJzdm8rSHBWYjdCTFVqbzY1?= =?utf-8?B?M0VMaG56L2UyS3lmMmZzNmY1L3lkUVNVdU4vUEJROWtzNHJkcm4rcXB1WjZ3?= =?utf-8?B?NTM2QUtzQW9ueEVSU3VGYVV3WWZaMm5uUEVraFBieEUxQmJpTjZPV3luV3lJ?= =?utf-8?B?a1hHYmdlSDZ1NllkZXovRGJpa2RBWjJWZE43VEJrNlI1WkVaWWRsY01zSWg3?= =?utf-8?B?Q2tVcm8xOWthQXgwbkF6N1dZYTY1UDN1NFE5aEZUTHplQUo2TUsyNDZKWG9W?= =?utf-8?B?K1l4Qlhzbm40RWVHMy9pN0JoTlJTL1hRUEFDR25MbmxFTWJOZmYzRTZrQkhT?= =?utf-8?B?cDlzZ2g1bWZtcWFsWU04TTlNRDVhblRTUTAxcVZpb3NEZ1MvOEdTN3E1bXFK?= =?utf-8?B?TDhwSzBjaktyRWhIb0twTHh5RHdvWGJ6d1dmUmxoek43Y2QvYnc0dE0rTUln?= =?utf-8?B?dmNMMnFvazlUZ2JxYjFSamE5ajk5V25YY1FObnpZYStaV0sraFRaQ3hmSllx?= =?utf-8?B?bUR1Zmd0Rk4wcHZQN3Z4NWdQSlJjNEs0TlNqaE9Iam1ZMVRvWkxFRWVaRXVN?= =?utf-8?B?eEU1dXg4NkFBWWNMcHNRN0JrczRiSmc2c1JGbHNQRUdLVzloNHc5OWRuVE43?= =?utf-8?B?a2k4RTJ4eTZ5RmtjaDJEUHdIWDRwbEhCRlM2UGxFWFJFUVJCS1YzSjgxSzgy?= =?utf-8?B?SDdPSjNuVS9qV1dOaXBOQS9YNGVEL3dwSXNacFBsMXFIZ0VBeXZKU3FkN3F0?= =?utf-8?B?Z0Z2L1hab2FmYk1VVUFRbVk4WGtOMlZNdXZteFNpR3BCVVNESEVUVG9hNTR4?= =?utf-8?B?WmRzTVc3OU8yWnZaSmx4QXVEN05lK2RjTWRXQTZycENHTVhvcDltdTBSdUFB?= =?utf-8?B?N3ZvZFk0TE1RVkNudUVnWGhnUXZScGJXRjNabVZsK2ZSTi8xSmllalpGSk1a?= =?utf-8?B?dzVDS0MyUjJDcGU3QTdHc1Jtd2tiaG55aUxuaWkwNXF3MjdONER1c2ZML0tr?= =?utf-8?B?VTZVaUs1SkVRb3dUVHU1S1UxMC8wZ1A4VmpoQndQSXZ1WkR2a002K0gycUgz?= =?utf-8?B?TVcrZldYYzNnQ3JkMHd0RTBBNXh3L2lvZ1JhQXQ3c2JzMSsrY2J1QXBhaUxD?= =?utf-8?B?VUhTMUpsMWROazRtYW5sN0hwTlJldTUxYkZnRWloWlFVdThGN25tOXZSdzlM?= =?utf-8?B?N1M1ZXl0ZHdyUkcwVk45YjQ0RkpaYkZNVkd2aVpDRXFTSjhLRXpJZmFhYzQ0?= =?utf-8?B?Q2VNejM0RFg4K3FscTZKMUcvWU43akxXYWprWFhETmlVclByYTFDMFBydkQw?= =?utf-8?B?NmRmS2VIaWJ4TVlFMXdpeDFZUk00KzdGZ3Erd0ZpL2ZlTnZjeUwwTHhjTFVO?= =?utf-8?B?ZlpkNk83R0g0TjZWYzFiWTRpanVHVU5IVTBMY3VPSGF2RDd2YnZDZE9TSWxX?= =?utf-8?B?MzVpTElKdzFWSXhOdFpqTE01R0V5aHUxb3JtQ01rQW5CNHNKQUtWcmozTTBQ?= =?utf-8?B?YnVrVTFxbjM1ek9zMVJlcWwrYzhVcDBaZGZ5aXhEUktlVjJXWEt3dGxta0Nu?= =?utf-8?B?QUk3N2tjOTl1azNNUERUd1g4ZFFwZ2RIanZZcU9yeDBPUm5HSVNhdEpUTSsz?= =?utf-8?B?TU5BNXBiMllWQTBFaHFKOW1ydVV4UDhvTmJLZ1FKSE5FVWlJYjl6WTh2YkpV?= =?utf-8?B?UHMrWHdrbTQ0dVRxN1hlZVNFTzJ1WWhaMDhNQ2xlQTMrMi94LytONWdBUTNt?= =?utf-8?B?M3B1c0FlOFNkeERpaGIyYVlKUWlGbitaaXpvMWx0TWlNK1hUbjJuOVEwU3Fa?= =?utf-8?B?bTR6U3J2cGNKK1EvSlFzcWc4M25oSzMycWpseHdoVEQrVVlIb0wzQUVDWHR0?= =?utf-8?B?VUpObVI1T3pNeE5CbG02WDdMWkxBQ2lkM1NCc04zOUx3NXlxVk9RMjdHRHVC?= =?utf-8?B?QkRPZjFaR1d2endYQjMwUUNoTFJ1TFAxNjRsdVRIRitQRmxscENZeVAwcHRJ?= =?utf-8?B?WGwwYnJhbXFaQVJEQ2lCZVZxM0VZTUVRcmdINmZJM0R0ZGNBcVo1d014T2tZ?= =?utf-8?B?N3cvQmRCbjA4K01OTXZ0YUdLenNHOVVjbUlrZHJNTEd4K1ZIcFhhMjFsNkN6?= =?utf-8?B?eUNwTzliTkwzd2l1ZUF1bEFVakQwdHFNdDgwVzJBVHJuNXFmT21IZ0QySzlv?= =?utf-8?B?RjVHd3BTY29XSVR1aExXU1hNWEFRPT0=?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4441586CD786EA555A57C7A0938B9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 79197efb-e9a6-4ea0-7e7d-08d99e4593c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2021 21:13:11.8038 (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: UHdr+o+xYGXNpoTYw5ApBP8q0Tkip+73trOYNXaAYG5fAv0mP+fsUh9S0Shnz1E4TWEfU45yX6O11vRiCaAYOZe4YrGE55rMFwX2jj2Lp+4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2186 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 21:13:28 -0000 --_000_HE1PR07MB4441586CD786EA555A57C7A0938B9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5UaGlzIG1ha2VzIGl0IG11Y2ggYmV0dGVyLiBJIHRoaW5rIGl0IGlzIG1pc3Npbmcg YSBjb3VwbGUgb2YgY29tbWFzICgiSW4gc29tZSAzUENDIHNjZW5hcmlvcywiIGFuZCAiSW4gdGhl IHJld3JpdHRlbiBvZmZlciwiKSBidXQgd29ya3MgZm9yIG1lLg0KDQpJIGNhbiBhZGQgdGhlbSB3 aGVuIEkgYWRkIHRoZSB0ZXh0IHRvIHRoZSBkcmFmdCwgYnV0IEkgdGhpbmsgdGhlIFJGQyBlZGl0 b3Igd2lsbCBtb3N0IGxpa2VseSBub3RpY2Ugc3VjaCB0aGluZy4NCg0KPkkgaGF2ZSBjaGFuZ2Vk IHRoZSBzZWN0aW9uIG5hbWUgc28gaXQgaXMgY2xlYXIgdGhhdCBpdCBhcHBsaWVzIHRvIEpTRVAg YXMgd2VsbCwgbm90IGp1c3QgU0lQLg0KDQpTdXJlLCB0aGF04oCZcyBmaW5lLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCg0KT24gVHVlLCBOb3YgMiwgMjAyMSBhdCAxOjI0IFBNIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkV2ZW50aG91Z2ggSSB3 b3VsZCBub3QgbGlrZSB0byBtYWtlIG1vcmUgY2hhbmdlcyB0aGFuIG5lY2Vzc2FyeSwgSSBhbSBm aW5lIHdpdGggIjNQQ0MgQ29uc2lkZXJhdGlvbnMiLg0KDQpIb3dldmVyLCB5b3VyIHN1Z2dlc3Rl ZCB0ZXh0IGlzIHZlcnkgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQgaW4gc29tZSBwbGFjZXMsIHNv IGxldCBtZSBnaXZlIGl0IGEgdHJ5Lg0KDQooVGhlIGZpcnN0IHBhcmFncmFwaCBpcyBnZW5lcmlj LCB0aGUgc2Vjb25kIFNJUCBzcGVjaWZpYywgYW5kIHRoZSB0aGlyZCBCVU5ETEUgc3BlY2lmaWMu KQ0KDQotLS0NCg0KM1BDQyBDb25zaWRlcmF0aW9ucw0KDQpJbiBzb21lIDNQQ0Mgc2NlbmFyaW9z IGEgbmV3IHNlc3Npb24gd2lsbCBiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIGFuIGVuZHBvaW50IHRo YXQgaXMgY3VycmVudGx5IHBhcnQgb2YgYW4gb25nb2luZyBzZXNzaW9uIGFuZCBhbiBlbmRwb2lu dCB0aGF0IGlzIGN1cnJlbnRseSBub3QgcGFydCBvZiBhbiBvbmdvaW5nIHNlc3Npb24uIFRoZSBl bmRwb2ludCB0aGF0IGlzIHBhcnQgb2YgYSBzZXNzaW9uIHdpbGwgZ2VuZXJhdGUgYSBzdWJzZXF1 ZW50IG9mZmVyIHRoYXQgd2lsbCBiZSBmb3J3YXJkZWQgdG8gdGhlIG90aGVyIGVuZHBvaW50IGJ5 IGEgM1BDQyBjb250cm9sbGVyLiBUaGUgZW5kcG9pbnQgdGhhdCBpcyBub3QgcGFydCBvZiBhIHNl c3Npb24gd2lsbCBwcm9jZXNzIHRoZSBvZmZlciBhcyBhbiBpbml0aWFsIG9mZmVyLg0KDQpUaGUg U2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2Vy IEFnZW50IENsaWVudCAoVUFDKSB0byBzZW5kIGEgcmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBh biBTRFAgYm9keSAoc29tZXRpbWVzIHJlZmVycmVkIHRvIGFzIGFuIGVtcHR5IHJlLUlOVklURSku IEluIHN1Y2ggY2FzZXMsIHRoZSBVc2VyIEFnZW50IFNlcnZlciAoVUFTKSB3aWxsIGluY2x1ZGUg YW4gU0RQIG9mZmVyIGluIHRoZSBhc3NvY2lhdGVkIDIwMCBPSyByZXNwb25zZS4gSWYgdGhlIFVB UyBpcyBhIHBhcnQgb2YgYW4gb25nb2luZyBzZXNzaW9uLCBpdCB3aWxsIGluY2x1ZGUgYSBzdWJz ZXF1ZW50IG9mZmVyIGluIHRoZSAyMDAgT0sgcmVzcG9uc2UuIFRoZSBvZmZlciB3aWxsIGJlIHJl Y2VpdmVkIGJ5IGEgM1BDQyBjb250cm9sbGVyIChVQUMpIGFuZCB0aGVuIGZvcndhcmRlZCB0byBh bm90aGVyIFVzZXIgQWdlbnQgKFVBKS4gSWYgdGhlIFVBIGlzIG5vdCBwYXJ0IG9mIGFuIG9uZ29p bmcgc2Vzc2lvbiwgaXQgd2lsbCBwcm9jZXNzIHRoZSBvZmZlciBhcyBhbiBpbml0aWFsIG9mZmVy Lg0KDQpXaGVuIHRoZSBCVU5ETEUgbWVjaGFuaXNtIGlzIHVzZWQsIGFuIGluaXRpYWwgQlVORExF IG9mZmVyIGlzIGNvbnN0cnVjdGVkIHVzaW5nIGRpZmZlcmVudCBydWxlcyB0aGFuIHN1YnNlcXVl bnQgQlVORExFIG9mZmVycywgYW5kIGl0IGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQgYSBVQSBpcyBh YmxlIHRvIGNvcnJlY3RseSBwcm9jZXNzIGEgc3Vic2VxdWVudCBvZmZlciBhcyBhbiBpbml0aWFs IG9mZmVyLiBUaGVyZWZvcmUsIHRoZSAzUENDIGNvbnRyb2xsZXIgU0hPVUxEIHJld3JpdGUgdGhl IHN1YnNlcXVlbnQgb2ZmZXIgaW50byBhIHZhbGlkIGluaXRpYWwgb2ZmZXIsIGZvbGxvd2luZyB0 aGUgcHJvY2VkdXJlcyBpbiAoU2VjdGlvbiA3LjIpLCBiZWZvcmUgaXQgZm9yd2FyZHMgdGhlIG9m ZmVyIHRvIGEgVUEuIEluIHRoZSByZXdyaXR0ZW4gb2ZmZXIgdGhlIDNQQ0MgY29udHJvbGxlciB3 aWxsIHNldCB0aGUgcG9ydCB2YWx1ZSB0byB6ZXJvIChhbmQgaW5jbHVkZSBhbiBTRFAgJ2J1bmRs ZS1vbmx5JyBhdHRyaWJ1dGUpIGZvciBlYWNoICJtPSIgc2VjdGlvbiB3aXRoaW4gdGhlIEJVTkRM RSBncm91cCwgZXhjbHVkaW5nIHRoZSBvZmZlcmVyLXRhZ2dlZCAibT0iIHNlY3Rpb24uDQoNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUm9tYW4gU2hw b3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NClNlbnQ6 IFR1ZXNkYXksIE5vdmVtYmVyIDIsIDIwMjEgNjozMyBQTQ0KVG86IENocmlzdGVyIEhvbG1iZXJn IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4+DQpDYzogSnVzdGluIFViZXJ0aSA8anViZXJ0aUBhbHBoYWV4cGxvcmF0 aW9uY28uY29tPG1haWx0bzpqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb20+PjsgSnVzdGlu IFViZXJ0aSA8anVzdGluQHViZXJ0aS5uYW1lPG1haWx0bzpqdXN0aW5AdWJlcnRpLm5hbWU+Pjsg UlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtdWJl cnRpLXJ0Y3dlYi1yZmM4ODI5YmlzLTAxLnR4dA0KDQpIb3cgYWJvdXQgd2UgcmVwbGFjZSB0aGUg U0lQIENvbnNpZGVyYXRpb25zIHdpdGg6DQoNCjNQQ0MgQ29uc2lkZXJhdGlvbnMNCg0KSW4gc29t ZSAzUENDIHNjZW5hcmlvcywgYW4gb2ZmZXIgZ2VuZXJhdGVkIGR1cmluZyBhbiBvbmdvaW5nIHNl c3Npb24sIGkuZS4sIGEgc3Vic2VxdWVudCBvZmZlciwgd2lsbCBiZSB1c2VkIGJ5IGEgM1BDQyBj b250cm9sbGVyIHRvIGVzdGFibGlzaCBhIG5ldyBzZXNzaW9uIGFuZCBmb3J3YXJkZWQgYXMgYW4g aW5pdGlhbCBvZmZlciB0byBhbm90aGVyIGVuZHBvaW50IHRoYXQgaXMgY3VycmVudGx5IG5vdCBw YXJ0IG9mIGEgc2Vzc2lvbi4NCg0KRm9yIGV4YW1wbGUsIHRoZSBTZXNzaW9uIEluaXRpYXRpb24g UHJvdG9jb2wgKFNJUCkgW1JGQzMyNjFdIGFsbG93cyBhIFVzZXIgQWdlbnQgQ2xpZW50IChVQUMp IHRvIHNlbmQgYSByZS1JTlZJVEUgcmVxdWVzdCB3aXRob3V0IGFuIFNEUCBib2R5IChzb21ldGlt ZXMgcmVmZXJyZWQgdG8gYXMgYW4gZW1wdHkgcmUtSU5WSVRFKS4gSW4gc3VjaCBjYXNlcywgdGhl IFVzZXIgQWdlbnQgU2VydmVyIChVQVMpIHdpbGwgaW5jbHVkZSBhbiBTRFAgb2ZmZXIgaW4gdGhl IGFzc29jaWF0ZWQgMjAwIE9LIHJlc3BvbnNlLiBJZiBVQVMgaXMgYSBwYXJ0IG9mIGFuIG9uZ29p bmcgc2Vzc2lvbiwgaXQgd2lsbCBpbmNsdWRlIGEgc3Vic2VxdWVudCBvZmZlciBpbiB0aGUgMjAw IE9LIHJlc3BvbnNlLiBUaGUgb2ZmZXIgd2lsbCBiZSByZWNlaXZlZCBieSBhIDNQQ0MgY29udHJv bGxlciAoVUFDKSBhbmQgdGhlbiBmb3J3YXJkZWQgdG8gYW5vdGhlciBVc2VyIEFnZW50IChVQSkg YXMgYW4gaW5pdGlhbCBvZmZlci4NCg0KV2hlbiB0aGUgQlVORExFIG1lY2hhbmlzbSBpcyB1c2Vk LCBhbiBpbml0aWFsIEJVTkRMRSBvZmZlciBpcyBjb25zdHJ1Y3RlZCB1c2luZyBkaWZmZXJlbnQg cnVsZXMgdGhhbiBzdWJzZXF1ZW50IEJVTkRMRSBvZmZlcnMuIEl0IGNhbm5vdCBiZSBhc3N1bWVk IHRoYXQgYSBzdWJzZXF1ZW50IG9mZmVyIGlzIGEgdmFsaWQgaW5pdGlhbCBvZmZlciBhbmQgdGhh dCB0aGUgZW5kcG9pbnQgdGhhdCBleHBlY3RzIGFuIGluaXRpYWwgb2ZmZXIgd2lsbCBwcm9wZXJs eSBwcm9jZXNzIHN1Y2ggYSBzdWJzZXF1ZW50IG9mZmVyLiBUaGVyZWZvcmUsIHRoZSAzUENDIGNv bnRyb2xsZXIgU0hPVUxEIHJld3JpdGUgdGhlIHN1YnNlcXVlbnQgb2ZmZXIgaW50byBhIHZhbGlk IGluaXRpYWwgb2ZmZXIgYmVmb3JlIGl0IGlzIHVzZWQgdG8gZXN0YWJsaXNoIGEgbmV3IHNlc3Np b24uIFRvIG1ha2UgdGhlIHN1YnNlcXVlbnQgb2ZmZXIgYSB2YWxpZCBpbml0aWFsIG9mZmVyLCAz UENDIHdpbGwgbmVlZCB0byBtb2RpZnkgYWxsIHRoZSBub24tdGFnZ2VkIG09IGxpbmVzIHRvIGlu Y2x1ZGUgdGhlIGJ1bmRsZS1vbmx5IGF0dHJpYnV0ZSBhbmQgc2V0IHRoZSBtPSBsaW5lIHBvcnQg dG8gemVyby4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KDQpPbiBUdWUsIE5vdiAy LCAyMDIxIGF0IDY6MDAgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQoNCkhpLA0KDQoNCg0KV2hhdCBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQoNCg0KLS0t DQoNCg0KDQpPTEQ6DQoNCg0KDQrigJxUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChT SVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2VyIEFnZW50IENsaWVudCAoVUFDKSB0byBzZW5kIGEg cmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBhbiBTRFAgYm9keSAoc29tZXRpbWVzIHJlZmVycmVk IHRvIGFzIGFuIGVtcHR5IHJlLUlOVklURSkuDQoNCkluIHN1Y2ggY2FzZXMsIHRoZSBVc2VyIEFn ZW50IFNlcnZlciAoVUFTKSB3aWxsIGluY2x1ZGUgYW4gU0RQIE9mZmVyIGluIHRoZSBhc3NvY2lh dGVkIDIwMCBPSyByZXNwb25zZS4gVGhpcyBpcyB0eXBpY2FsbHkgdXNlZCBmb3IgM3JkIFBhcnR5 IENhbGwgQ29udHJvbCAoM1BDQykgc2NlbmFyaW9zLg0KDQpGcm9tIGEgQlVORExFIHBlcnNwZWN0 aXZlLCBzdWNoIFNEUCBPZmZlciBTSE9VTEQgYmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBwcm9jZWR1 cmVzIGRlZmluZWQgaW4gU2VjdGlvbiA3LjIu4oCdDQoNCg0KDQpORVc6DQoNCg0KDQrigJxUaGUg U2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2Vy IEFnZW50IENsaWVudCAoVUFDKSB0byBzZW5kIGEgcmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBh biBTRFAgYm9keSAoc29tZXRpbWVzIHJlZmVycmVkIHRvIGFzIGFuIGVtcHR5IHJlLUlOVklURSku DQoNCkluIHN1Y2ggY2FzZXMsIHRoZSBVc2VyIEFnZW50IFNlcnZlciAoVUFTKSB3aWxsIGluY2x1 ZGUgYW4gU0RQIG9mZmVyIGluIHRoZSBhc3NvY2lhdGVkIDIwMCBPSyByZXNwb25zZS4gVGhpcyBp cyB0eXBpY2FsbHkgdXNlZCBmb3IgM3JkIFBhcnR5IENhbGwgQ29udHJvbCAoM1BDQykgc2NlbmFy aW9zLg0KDQoNCg0KSW4gc29tZSAzUENDIHNjZW5hcmlvcyB0aGUgVUFTIHdpbGwgYmUgcGFydCBv ZiBhbiBvbmdvaW5nIHNlc3Npb24sIGFuZCB3aWxsIHRoZXJlZm9yZSBpbmNsdWRlIGEgc3Vic2Vx dWVudCBvZmZlciBpbiB0aGUgMjAwIE9LIHJlc3BvbnNlcy4gVGhlIG9mZmVyIHdpbGwgYmUNCg0K cmVjZWl2ZWQgYnkgYSAzUENDIGNvbnRyb2xsZXIgKFVBQykgYW5kIHRoZW4gZm9yd2FyZGVkIGFz IGFuIGluaXRpYWwgb2ZmZXIgdG8gYW5vdGhlciBVc2VyIEFnZW50IChVQSkgdGhhdCBpcyBjdXJy ZW50bHkgbm90IHBhcnQgb2YgYSBzZXNzaW9uLg0KDQoNCg0KV2hlbiB0aGUgQlVORExFIG1lY2hh bmlzbSBpcyB1c2VkLCBhcyBhbiBpbml0aWFsIEJVTkRMRSBvZmZlciBsb29rIGRpZmZlcmVudCB0 aGFuIGEgc3Vic2VxdWVudCBCVU5ETEUgb2ZmZXIsIGl0IGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQg YSBVQSB0aGF0IGV4cGVjdHMgYW4gaW5pdGlhbCBvZmZlcg0KDQp3aWxsIGJlIGFibGUgdG8gcHJv cGVybHkgcHJvY2VzcyBhIHN1YnNlcXVlbnQgb2ZmZXIuIFRoZXJlZm9yZSwgdGhlIDNQQ0MgY29u dHJvbGxlciBuZWVkcyB0byBhY3QgYXMgYSBCYWNrLVRvLUJhY2sgVXNlciBBZ2VudCAoQjJCVUEp LCBhbmQgd2hlbiBpdCByZWNlaXZlcyB0aGUgc3Vic2VxdWVudA0KDQpvZmZlciBpdCBuZWVkcyB0 byByZXdyaXRlIGl0IGludG8gYW4gaW5pdGlhbCBvZmZlciBiZWZvcmUgaXQgaXMgZm9yd2FyZGVk IHRvIHN1Y2ggVUEu4oCdDQoNCg0KDQotLS0tDQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KQ2hyaXN0 ZXINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpGcm9tOiBSb21hbiBTaHBvdW50 IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KU2VudDogdGlp c3RhaSAyLiBtYXJyYXNrdXV0YSAyMDIxIDEwLjQxDQpUbzogSnVzdGluIFViZXJ0aSA8anViZXJ0 aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tPG1haWx0bzpqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25j by5jb20+Pg0KQ2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBKdXN0aW4gVWJl cnRpIDxqdXN0aW5AdWJlcnRpLm5hbWU8bWFpbHRvOmp1c3RpbkB1YmVydGkubmFtZT4+OyBSVENX ZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtydGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC11YmVydGkt cnRjd2ViLXJmYzg4MjliaXMtMDEudHh0DQoNCg0KDQpPbiBNb24sIE5vdiAxLCAyMDIxIGF0IDI6 NTIgUE0gSnVzdGluIFViZXJ0aSA8anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tPG1haWx0 bzpqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb20+PiB3cm90ZToNCg0KVGhlIFBST0JMRU0g aXMgdGhhdCB3ZSBoYXZlIHR3byBlbmRwb2ludHMsIHdoZXJlIG9uZSBzZW5kcyBhIHN1YnNlcXVl bnQgb2ZmZXIsIGFuZCB0aGUgb3RoZXIgb25lIGV4cGVjdHMgYW4gaW5pdGlhbCBvZmZlci4gV2hh dCBkbyB5b3Ugbm9ybWFsbHkgZG8gd2hlbiB5b3UgaGF2ZSB0aGF0IGtpbmQgb2YgcHJvYmxlbT8g WW91IHVzZSBhbiBTQkMvQjJCVUEuIEluIHRoaXMgY2FzZSB0aGF0IFNCQy9CMkJVQSB3b3VsZCBi ZSB0aGUgM1BDQyBjb250cm9sbGVyLg0KDQoNCg0KU28sIG15IHN1Z2dlc3Rpb24gd291bGQgYmUg dG8gcmVtb3ZlIHRoZSBTSE9VTEQgdGV4dCBmcm9tIDg4NDNiaXMsIGFuZCBzaW1wbHkgYWRkIGEg bm90ZSBzb21ld2hlcmUgKGluIDg4NDNiaXMgYW5kL29yIDg4MjliaXMpIHdoaWNoIGRlc2NyaWJl cyB0aGUgaXNzdWUgYW5kIHNheXMgdGhhdCB0aGUgM0dQUCBjb250cm9sbGVyIG5lZWRzIHRvIG1v ZGlmeSB0aGUgb2ZmZXIgYWNjb3JkaW5nbHkuDQoNCg0KDQpSb21hbiwgdGhvdWdodHMgb24gdGhp cz8gSWYgdGhlIDNQQ0MgaXMgZ29pbmcgdG8gcmV3cml0ZSB0aGUgb2ZmZXIgU0RQIGFueXdheSB0 aGVuIG1heWJlIGFkZGluZyBhPWJ1bmRsZS1vbmx5IGlzbid0IHRoZSBlbmQgb2YgdGhlIHdvcmxk Lg0KDQoNCg0KSSBhbSBub3Qgb3Bwb3NlZCB0byB0aGlzIGlkZWEuIDNQQ0MgdHlwaWNhbGx5IGtu b3dzIHRoYXQgdGhlIHN1YnNlcXVlbnQgb2ZmZXIgaXMgZ29pbmcgdG8gYmUgdXNlZCBhcyBpbml0 aWFsLCBhbmQgc2hvdWxkIGJlIGFibGUgdG8gcmV3cml0ZSB0aGUgb2ZmZXIgdG8gbWFrZSBpdCB2 YWxpZC4gV2UgY2FuIGNoYW5nZSBTSVAgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpbiA4ODQzYmlz IChodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYtbW11c2ljLXJmYzg4 NDNiaXMtMDUuaHRtbCNuYW1lLXNpcC1jb25zaWRlcmF0aW9uKSwgcmVtb3ZlIHRoZSBTSE9VTEQs IGFuZCBzcGVjaWZ5IHRoYXQgM1BDQyBjb250cm9sbGVyIHNob3VsZCBmaXggdGhlIG9mZmVyLiBX ZSBjYW4gdGhlbiByZWZlcmVuY2UgdGhpcyBub3RlIGZyb20gODgyOWJpcyBvciByZXN0YXRlIHRo ZSBzYW1lIGd1aWRhbmNlLg0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0K --_000_HE1PR07MB4441586CD786EA555A57C7A0938B9HE1PR07MB4441eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkZJIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7VGhpcyBtYWtlcyBpdCBtdWNoIGJldHRlci4gPC9zcGFuPkkgdGhpbmsg aXQgaXMgbWlzc2luZyBhIGNvdXBsZSBvZiBjb21tYXMgKCZxdW90O0luIHNvbWUgM1BDQyBzY2Vu YXJpb3MsJnF1b3Q7IGFuZCAmcXVvdDtJbiB0aGUgcmV3cml0dGVuIG9mZmVyLCZxdW90OykgYnV0 IHdvcmtzIGZvciBtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkkgY2FuIGFkZCB0aGVtIHdoZW4gSSBhZGQgdGhlIHRleHQgdG8gdGhlIGRyYWZ0LCBidXQgSSB0 aGluayB0aGUgUkZDIGVkaXRvciB3aWxsIG1vc3QgbGlrZWx5IG5vdGljZSBzdWNoIHRoaW5nLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O0kgaGF2 ZSBjaGFuZ2VkIHRoZSBzZWN0aW9uIG5hbWUgc28gaXQgaXMgY2xlYXIgdGhhdCBpdCBhcHBsaWVz IHRvIEpTRVAgYXMgd2VsbCwgbm90IGp1c3QgU0lQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3VyZSwg dGhhdOKAmXMgZmluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMiwgMjAyMSBhdCAx OjI0IFBNIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RXZl bnRob3VnaCBJIHdvdWxkIG5vdCBsaWtlIHRvIG1ha2UgbW9yZSBjaGFuZ2VzIHRoYW4gbmVjZXNz YXJ5LCBJIGFtIGZpbmUgd2l0aCAmcXVvdDszUENDIENvbnNpZGVyYXRpb25zJnF1b3Q7LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SG93ZXZlciwgeW91ciBzdWdnZXN0 ZWQgdGV4dCBpcyB2ZXJ5IGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kIGluIHNvbWUgcGxhY2VzLCBz byBsZXQgbWUgZ2l2ZSBpdCBhIHRyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPihUaGUgZmlyc3QgcGFyYWdyYXBoIGlzIGdlbmVyaWMsIHRoZSBzZWNvbmQgU0lQIHNw ZWNpZmljLCBhbmQgdGhlIHRoaXJkIEJVTkRMRSBzcGVjaWZpYy4pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29s b3I6IzIwMUYxRTtiYWNrZ3JvdW5kOndoaXRlIj4zUENDIENvbnNpZGVyYXRpb25zPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzIwMUYxRSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2NvbG9yOiMyMDFGMUUiPkluIHNvbWUgM1BDQyBzY2VuYXJpb3MgYSBuZXcgc2Vzc2lvbiB3aWxs IGJlIGVzdGFibGlzaGVkIGJldHdlZW4gYW4gZW5kcG9pbnQgdGhhdCBpcyBjdXJyZW50bHkgcGFy dCBvZiBhbiBvbmdvaW5nIHNlc3Npb24gYW5kIGFuIGVuZHBvaW50IHRoYXQgaXMgY3VycmVudGx5 IG5vdCBwYXJ0IG9mDQogYW4gb25nb2luZyBzZXNzaW9uLiBUaGUgZW5kcG9pbnQgdGhhdCBpcyBw YXJ0IG9mIGEgc2Vzc2lvbiB3aWxsIGdlbmVyYXRlIGEgc3Vic2VxdWVudCBvZmZlciB0aGF0IHdp bGwgYmUgZm9yd2FyZGVkIHRvIHRoZSBvdGhlciBlbmRwb2ludCBieSBhIDNQQ0MgY29udHJvbGxl ci4gVGhlIGVuZHBvaW50IHRoYXQgaXMgbm90IHBhcnQgb2YgYSBzZXNzaW9uIHdpbGwgcHJvY2Vz cyB0aGUgb2ZmZXIgYXMgYW4gaW5pdGlhbCBvZmZlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzIwMUYxRSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2NvbG9yOiMyMDFGMUUiPlRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkg W1JGQzMyNjFdIGFsbG93cyBhIFVzZXIgQWdlbnQgQ2xpZW50IChVQUMpIHRvIHNlbmQgYSByZS1J TlZJVEUgcmVxdWVzdCB3aXRob3V0IGFuIFNEUCBib2R5IChzb21ldGltZXMgcmVmZXJyZWQgdG8g YXMgYW4gZW1wdHkgcmUtSU5WSVRFKS4NCiBJbiBzdWNoIGNhc2VzLCB0aGUgVXNlciBBZ2VudCBT ZXJ2ZXIgKFVBUykgd2lsbCBpbmNsdWRlIGFuIFNEUCBvZmZlciBpbiB0aGUgYXNzb2NpYXRlZCAy MDAgT0sgcmVzcG9uc2UuIElmIHRoZSBVQVMgaXMgYSBwYXJ0IG9mIGFuIG9uZ29pbmcgc2Vzc2lv biwgaXQgd2lsbCBpbmNsdWRlIGEgc3Vic2VxdWVudCBvZmZlciBpbiB0aGUgMjAwIE9LIHJlc3Bv bnNlLiBUaGUgb2ZmZXIgd2lsbCBiZSByZWNlaXZlZCBieSBhIDNQQ0MgY29udHJvbGxlciAoVUFD KQ0KIGFuZCB0aGVuIGZvcndhcmRlZCB0byBhbm90aGVyIFVzZXIgQWdlbnQgKFVBKS4gSWYgdGhl IFVBIGlzIG5vdCBwYXJ0IG9mIGFuIG9uZ29pbmcgc2Vzc2lvbiwgaXQgd2lsbCBwcm9jZXNzIHRo ZSBvZmZlciBhcyBhbiBpbml0aWFsIG9mZmVyLjxicj4NCjxicj4NCldoZW4gdGhlIEJVTkRMRSBt ZWNoYW5pc20gaXMgdXNlZCwgYW4gaW5pdGlhbCBCVU5ETEUgb2ZmZXIgaXMgY29uc3RydWN0ZWQg dXNpbmcgZGlmZmVyZW50IHJ1bGVzIHRoYW4gc3Vic2VxdWVudCBCVU5ETEUgb2ZmZXJzLCBhbmQg aXQgY2Fubm90IGJlIGFzc3VtZWQgdGhhdCBhIFVBIGlzIGFibGUgdG8gY29ycmVjdGx5IHByb2Nl c3MgYSBzdWJzZXF1ZW50IG9mZmVyIGFzIGFuIGluaXRpYWwgb2ZmZXIuIFRoZXJlZm9yZSwgdGhl IDNQQ0MgY29udHJvbGxlcg0KIFNIT1VMRCByZXdyaXRlIHRoZSBzdWJzZXF1ZW50IG9mZmVyIGlu dG8gYSB2YWxpZCBpbml0aWFsIG9mZmVyLCBmb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgaW4gKFNl Y3Rpb24gNy4yKSwgYmVmb3JlIGl0IGZvcndhcmRzIHRoZSBvZmZlciB0byBhIFVBLiBJbiB0aGUg cmV3cml0dGVuIG9mZmVyIHRoZSAzUENDIGNvbnRyb2xsZXIgd2lsbCBzZXQgdGhlIHBvcnQgdmFs dWUgdG8gemVybyAoYW5kIGluY2x1ZGUgYW4gU0RQICdidW5kbGUtb25seScgYXR0cmlidXRlKQ0K IGZvciBlYWNoICZxdW90O209JnF1b3Q7IHNlY3Rpb24gd2l0aGluIHRoZSBCVU5ETEUgZ3JvdXAs IGV4Y2x1ZGluZyB0aGUgb2ZmZXJlci10YWdnZWQgJnF1b3Q7bT0mcXVvdDsgc2VjdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0K PGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlk PSJnbWFpbC1tXzY1OTczNDk3MjkyNTQyNTU4MjdkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9h PiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMiwgMjAyMSA2OjMzIFBN PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKdXN0aW4gVWJlcnRp ICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tPC9hPiZndDs7IEp1c3Rp biBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdXN0aW5AdWJlcnRpLm5hbWUiIHRhcmdldD0i X2JsYW5rIj5qdXN0aW5AdWJlcnRpLm5hbWU8L2E+Jmd0OzsgUlRDV2ViIElFVEYgJmx0OzxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV29ya2luZyBHcm91 cCBMYXN0IENhbGwgZm9yIGRyYWZ0LXViZXJ0aS1ydGN3ZWItcmZjODgyOWJpcy0wMS50eHQ8L3Nw YW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhvdyBhYm91dCB3ZSByZXBsYWNlIHRoZSBTSVAgQ29uc2lkZXJhdGlvbnMgd2l0 aDogPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zUENDIENv bnNpZGVyYXRpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIHNvbWUgM1BDQyBzY2VuYXJpb3MsIGFuIG9mZmVyIGdlbmVyYXRlZCBkdXJp bmcgYW4gb25nb2luZyBzZXNzaW9uLCBpLmUuLCBhIHN1YnNlcXVlbnQgb2ZmZXIsIHdpbGwgYmUg dXNlZCBieSBhIDNQQ0MgY29udHJvbGxlciB0byBlc3RhYmxpc2ggYSBuZXcgc2Vzc2lvbiBhbmQg Zm9yd2FyZGVkIGFzIGFuIGluaXRpYWwgb2ZmZXIgdG8gYW5vdGhlciBlbmRwb2ludCB0aGF0IGlz IGN1cnJlbnRseSBub3QgcGFydA0KIG9mIGEgc2Vzc2lvbi48YnI+DQo8YnI+DQpGb3IgZXhhbXBs ZSwgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBbUkZDMzI2MV0gYWxsb3dz IGEgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgdG8gc2VuZCBhIHJlLUlOVklURSByZXF1ZXN0IHdp dGhvdXQgYW4gU0RQIGJvZHkgKHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyBhbiBlbXB0eSByZS1J TlZJVEUpLiBJbiBzdWNoIGNhc2VzLCB0aGUgVXNlciBBZ2VudCBTZXJ2ZXIgKFVBUykgd2lsbCBp bmNsdWRlIGFuIFNEUCBvZmZlcg0KIGluIHRoZSBhc3NvY2lhdGVkIDIwMCBPSyByZXNwb25zZS4g SWYgVUFTIGlzIGEgcGFydCBvZiBhbiBvbmdvaW5nIHNlc3Npb24sIGl0IHdpbGwgaW5jbHVkZSBh IHN1YnNlcXVlbnQgb2ZmZXIgaW4gdGhlIDIwMCBPSyByZXNwb25zZS4gVGhlIG9mZmVyIHdpbGwg YmUgcmVjZWl2ZWQgYnkgYSAzUENDIGNvbnRyb2xsZXIgKFVBQykgYW5kIHRoZW4gZm9yd2FyZGVk IHRvIGFub3RoZXIgVXNlciBBZ2VudCAoVUEpIGFzIGFuIGluaXRpYWwgb2ZmZXIuPGJyPg0KPGJy Pg0KV2hlbiB0aGUgQlVORExFIG1lY2hhbmlzbSBpcyB1c2VkLCBhbiBpbml0aWFsIEJVTkRMRSBv ZmZlciBpcyBjb25zdHJ1Y3RlZCB1c2luZyBkaWZmZXJlbnQgcnVsZXMgdGhhbiBzdWJzZXF1ZW50 IEJVTkRMRSBvZmZlcnMuIEl0IGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQgYSBzdWJzZXF1ZW50IG9m ZmVyIGlzIGEgdmFsaWQgaW5pdGlhbCBvZmZlciBhbmQgdGhhdCB0aGUgZW5kcG9pbnQgdGhhdCBl eHBlY3RzIGFuIGluaXRpYWwgb2ZmZXIgd2lsbCBwcm9wZXJseQ0KIHByb2Nlc3Mgc3VjaCBhIHN1 YnNlcXVlbnQgb2ZmZXIuIFRoZXJlZm9yZSwgdGhlIDNQQ0MgY29udHJvbGxlciBTSE9VTEQgcmV3 cml0ZSB0aGUgc3Vic2VxdWVudCBvZmZlciBpbnRvIGEgdmFsaWQgaW5pdGlhbCBvZmZlciBiZWZv cmUgaXQgaXMgdXNlZCB0byBlc3RhYmxpc2ggYSBuZXcgc2Vzc2lvbi4gVG8gbWFrZSB0aGUgc3Vi c2VxdWVudCBvZmZlciBhIHZhbGlkIGluaXRpYWwgb2ZmZXIsIDNQQ0Mgd2lsbCBuZWVkIHRvIG1v ZGlmeSBhbGwgdGhlDQogbm9uLXRhZ2dlZCBtPSBsaW5lcyB0byBpbmNsdWRlIHRoZSBidW5kbGUt b25seSBhdHRyaWJ1dGUgYW5kIHNldCB0aGUgbT0gbGluZSBwb3J0IHRvIHplcm8uPGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92IDIsIDIwMjEg YXQgNjowMCBBTSBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cD5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPldoYXQgYWJvdXQgc29tZXRoaW5n IGxpa2UgdGhpczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+T0xEOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+4oCcVGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90 b2NvbCAoU0lQKSBbUkZDMzI2MV0gYWxsb3dzIGEgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgdG8g c2VuZCBhIHJlLUlOVklURSByZXF1ZXN0IHdpdGhvdXQgYW4gU0RQIGJvZHkgKHNvbWV0aW1lcyBy ZWZlcnJlZCB0byBhcyBhbiBlbXB0eSByZS1JTlZJVEUpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBzdWNoIGNhc2VzLCB0aGUgVXNlciBBZ2VudCBTZXJ2 ZXIgKFVBUykgd2lsbCBpbmNsdWRlIGFuIFNEUCBPZmZlciBpbiB0aGUgYXNzb2NpYXRlZCAyMDAg T0sgcmVzcG9uc2UuIFRoaXMgaXMgdHlwaWNhbGx5IHVzZWQgZm9yIDNyZCBQYXJ0eSBDYWxsIENv bnRyb2wgKDNQQ0MpIHNjZW5hcmlvcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIj5Gcm9tIGEgQlVORExFIHBlcnNwZWN0aXZlLCBzdWNoIFNEUCBPZmZlciBT SE9VTEQgYmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBwcm9jZWR1cmVzIGRlZmluZWQgaW4gU2VjdGlv biA3LjIu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5ORVc6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxUaGUgU2Vzc2lvbiBJbml0 aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2VyIEFnZW50IENsaWVu dCAoVUFDKSB0byBzZW5kIGEgcmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBhbiBTRFAgYm9keSAo c29tZXRpbWVzIHJlZmVycmVkIHRvIGFzIGFuIGVtcHR5IHJlLUlOVklURSkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHN1Y2ggY2FzZXMsIHRoZSBVc2Vy IEFnZW50IFNlcnZlciAoVUFTKSB3aWxsIGluY2x1ZGUgYW4gU0RQIG9mZmVyIGluIHRoZSBhc3Nv Y2lhdGVkIDIwMCBPSyByZXNwb25zZS4gVGhpcyBpcyB0eXBpY2FsbHkgdXNlZCBmb3IgM3JkIFBh cnR5IENhbGwgQ29udHJvbCAoM1BDQykgc2NlbmFyaW9zLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBzb21lIDNQQ0Mgc2NlbmFyaW9zIHRoZSBVQVMgd2lsbCBi ZSBwYXJ0IG9mIGFuIG9uZ29pbmcgc2Vzc2lvbiwgYW5kIHdpbGwgdGhlcmVmb3JlIGluY2x1ZGUg YSBzdWJzZXF1ZW50IG9mZmVyIGluIHRoZSAyMDAgT0sgcmVzcG9uc2VzLiBUaGUgb2ZmZXIgd2ls bCBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWNlaXZl ZCBieSBhIDNQQ0MgY29udHJvbGxlciAoVUFDKSBhbmQgdGhlbiBmb3J3YXJkZWQgYXMgYW4gaW5p dGlhbCBvZmZlciB0byBhbm90aGVyIFVzZXIgQWdlbnQgKFVBKSB0aGF0IGlzIGN1cnJlbnRseSBu b3QgcGFydCBvZiBhIHNlc3Npb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIj5XaGVuIHRoZSBCVU5ETEUgbWVjaGFuaXNtIGlzIHVzZWQsIGFzIGFuIGluaXRpYWwgQlVO RExFIG9mZmVyIGxvb2sgZGlmZmVyZW50IHRoYW4gYSBzdWJzZXF1ZW50IEJVTkRMRSBvZmZlciwg aXQgY2Fubm90IGJlIGFzc3VtZWQgdGhhdCBhIFVBIHRoYXQgZXhwZWN0cyBhbiBpbml0aWFsIG9m ZmVyDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+d2lsbCBi ZSBhYmxlIHRvIHByb3Blcmx5IHByb2Nlc3MgYSBzdWJzZXF1ZW50IG9mZmVyLiBUaGVyZWZvcmUs IHRoZSAzUENDIGNvbnRyb2xsZXIgbmVlZHMgdG8gYWN0IGFzIGEgQmFjay1Uby1CYWNrIFVzZXIg QWdlbnQgKEIyQlVBKSwgYW5kIHdoZW4gaXQgcmVjZWl2ZXMgdGhlIHN1YnNlcXVlbnQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+b2ZmZXIgaXQgbmVlZHMgdG8g cmV3cml0ZSBpdCBpbnRvIGFuIGluaXRpYWwgb2ZmZXIgYmVmb3JlIGl0IGlzIGZvcndhcmRlZCB0 byBzdWNoIFVBLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+LS0t LTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cD48 Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4g Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJn ZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+ IHRpaXN0YWkgMi4gbWFycmFza3V1dGEgMjAyMSAxMC40MTxicj4NCjxiPlRvOjwvYj4gSnVzdGlu IFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJt YWlsdG86anVzdGluQHViZXJ0aS5uYW1lIiB0YXJnZXQ9Il9ibGFuayI+anVzdGluQHViZXJ0aS5u YW1lPC9hPiZndDs7IFJUQ1dlYiBJRVRGICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC11 YmVydGktcnRjd2ViLXJmYzg4MjliaXMtMDEudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cD5PbiBNb24sIE5vdiAxLCAyMDIxIGF0IDI6NTIgUE0gSnVzdGluIFViZXJ0aSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHA+VGhlIFBST0JMRU0gaXMgdGhhdCB3ZSBoYXZlIHR3byBlbmRw b2ludHMsIHdoZXJlIG9uZSBzZW5kcyBhIHN1YnNlcXVlbnQgb2ZmZXIsIGFuZCB0aGUgb3RoZXIg b25lIGV4cGVjdHMgYW4gaW5pdGlhbCBvZmZlci4gV2hhdCBkbyB5b3Ugbm9ybWFsbHkgZG8gd2hl biB5b3UgaGF2ZSB0aGF0IGtpbmQgb2YgcHJvYmxlbT8gWW91IHVzZSBhbiBTQkMvQjJCVUEuIElu IHRoaXMgY2FzZSB0aGF0IFNCQy9CMkJVQSB3b3VsZCBiZSB0aGUgM1BDQyBjb250cm9sbGVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cD5TbywgbXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byByZW1vdmUgdGhl IFNIT1VMRCB0ZXh0IGZyb20gODg0M2JpcywgYW5kIHNpbXBseSBhZGQgYSBub3RlIHNvbWV3aGVy ZSAoaW4gODg0M2JpcyBhbmQvb3IgODgyOWJpcykgd2hpY2ggZGVzY3JpYmVzIHRoZSBpc3N1ZSBh bmQgc2F5cyB0aGF0IHRoZSAzR1BQIGNvbnRyb2xsZXIgbmVlZHMgdG8gbW9kaWZ5IHRoZSBvZmZl ciBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cD5Sb21hbiwgdGhvdWdodHMgb24gdGhpcz8gSWYgdGhlIDNQ Q0MgaXMgZ29pbmcgdG8gcmV3cml0ZSB0aGUgb2ZmZXIgU0RQIGFueXdheSB0aGVuIG1heWJlIGFk ZGluZyBhPWJ1bmRsZS1vbmx5IGlzbid0IHRoZSBlbmQgb2YgdGhlIHdvcmxkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+SSBhbSBub3Qgb3Bwb3NlZCB0 byZuYnNwO3RoaXMgaWRlYS4gM1BDQyB0eXBpY2FsbHkga25vd3MgdGhhdCB0aGUgc3Vic2VxdWVu dCBvZmZlciBpcyBnb2luZyB0byBiZSB1c2VkIGFzIGluaXRpYWwsIGFuZCBzaG91bGQgYmUgYWJs ZSB0byByZXdyaXRlIHRoZSBvZmZlciB0byBtYWtlIGl0IHZhbGlkLiBXZSBjYW4gY2hhbmdlJm5i c3A7U0lQIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaW4gODg0M2JpcyAoPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLW1tdXNpYy1yZmM4ODQzYmlzLTA1 Lmh0bWwjbmFtZS1zaXAtY29uc2lkZXJhdGlvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1tbXVzaWMtcmZjODg0M2Jpcy0wNS5odG1s I25hbWUtc2lwLWNvbnNpZGVyYXRpb248L2E+KSwNCiByZW1vdmUgdGhlIFNIT1VMRCwgYW5kIHNw ZWNpZnkgdGhhdCAzUENDIGNvbnRyb2xsZXIgc2hvdWxkIGZpeCB0aGUgb2ZmZXIuIFdlIGNhbiB0 aGVuIHJlZmVyZW5jZSB0aGlzIG5vdGUgZnJvbSA4ODI5YmlzIG9yIHJlc3RhdGUgdGhlIHNhbWUg Z3VpZGFuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwPl9fX19fX19fX19fX188YnI+DQpS b21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHA+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR07MB4441586CD786EA555A57C7A0938B9HE1PR07MB4441eurp_-- From nobody Wed Nov 3 04:37:33 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54A93A132E for ; Wed, 3 Nov 2021 04:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbcFV8XObyNZ for ; Wed, 3 Nov 2021 04:37:28 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347E63A132C for ; Wed, 3 Nov 2021 04:37:27 -0700 (PDT) Received: from [192.168.3.157] (unknown [78.156.11.215]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8367D7C7208 for ; Wed, 3 Nov 2021 12:37:24 +0100 (CET) To: rtcweb@ietf.org From: Harald Alvestrand Message-ID: Date: Wed, 3 Nov 2021 12:37:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 11:37:31 -0000 It's come to my attention that there's apparently some 5G spec that says "Use WebRTC datachannel, but don't bother with this ICE stuff". The exact quote is below. Now I don't mind saying "don't use TURN/STUN servers" - that's a configuration option on the WEBRTC API, and anyone can choose to not do that - but I do mind leaving out ICE. An ICE-supporting implementation won't interwork properly with an implementation that doesn't support ICE. Is it possible for the IETF to say "please don't make incompatible changes to our protocols without asking us"? (that's the version where I try not to use expletives). Or is it possible that this is all a misunderstanding, and the 5G folks actually meant to require peer-to-peer ICE, but just wrote it wrongly? Or did I misunderstand what the WG's intent was, and should just suck it up and interoperate with non-ICE-supporting endpoints? Harald --------- Spec reference quote ---------- 1. Spec NG.129 - 5G Data Channel White Paper  (CR1001) 8.2.1Data channel APIs The data channel application consists of the device side logic and the server side logic. Both should use standardized APIs that need to be agreed by the industry. W3C WebRTC1.0 data channel API specification is suggested as the preferred IMS data channel API. RTCPeerConnection , RTCDataChannel object, the  callbacks need to be supported . Only data channel API related definitions  are used and IMS data channel API is not allowed to use WebRTC media. ICE/STUN/TURN are also not required. # Reference 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS GSMA NG.129_5G DATA CHANNEL From nobody Wed Nov 3 06:10:46 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ADF3A12B0 for ; Wed, 3 Nov 2021 06:10:44 -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 LA3oEOswjEGZ for ; Wed, 3 Nov 2021 06:10:39 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 49CA83A13EF for ; Wed, 3 Nov 2021 06:10:39 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id p11-20020a9d4e0b000000b0055a5741bff7so3408447otf.2 for ; Wed, 03 Nov 2021 06:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rw79+cheC9r3ol7LBEbT9YTPSBAAxeVhPhK+7kg7iAk=; b=IAujfvyKlJPWkv1idZjBuHjBkm+9+KYMEQPr7Ro8A20AUxUCBMnRz+N/2EG5+6Bs7l WeNNVDy7CaZoWovtuvL21eanf3Ozbt7NYlsGGD08Jv8fdKYZ9cO8+JfljfitMwkLhWvp RCPmb6hP2tIe2YcT9Ar2Pe+/AOEGHS1kJU3tZmTm09gzxPx2cY7dQD0Xkn+Oi2uGQLrz ECTLPh8xGt9WRC/ItLmURwqx/H9NSKhlFd2mDPQLapvacVqs+JD5LXHAeTYmNyNo+oew cwL11hewVNP7QKYo4nxqERneQHq0tO+38DLWxawh0gFa2qbF1cPnIACsge51FIeUw6FQ kYcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rw79+cheC9r3ol7LBEbT9YTPSBAAxeVhPhK+7kg7iAk=; b=3yCoeuAMjVEiPTQuiWiLCMjnpI6BNaVhrWy09uWf5I2cSpRDxQBtwfhziixcRm6LzK nLL/sRkkgi/0fJcy5r26u63FqBr0CzqE6h6Uc9yin2nqJ/XNXUjZat396i4gvgx3TmaW zAW8Aao4v3Sz1SWGR47yID8/GNrbIrgG3jIGbbPB22JJRH6AjKiJRpTGu2xgRw4aJu+4 afvf1dhmSuWeT+CH4+KIG+VznUAzeOn6AEfV+6c2GXnX3QHjsACAwouBtCTQr5wWkF/v zfYKe2k7T/Q05C1T5yYKwv3qXcbHHbOlJrCGFOt7n3y5vJj91iGMnqXy4qjHRwErKgLz pO8w== X-Gm-Message-State: AOAM533beM5yh7NlVHN6jTbFNsCkswaqXJAg5vEeZpgkneR1lyF7LCbg ZzAWv2I5h2g4APEA3FT6GLQKfKwuZwOIXNGb4MyXI103mi8= X-Google-Smtp-Source: ABdhPJwEW/fitVMT9QnfOVMp49OKn2CjTQEhDm0LIrxF+W3ywEVoCGQVY2Cot9nLWNh9fqxL1u0jMxmaV+vx/3G6umc= X-Received: by 2002:a9d:6c8a:: with SMTP id c10mr33332752otr.338.1635945038482; Wed, 03 Nov 2021 06:10:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Wed, 3 Nov 2021 13:10:12 +0000 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000e41cdf05cfe2221d" Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 13:10:44 -0000 --000000000000e41cdf05cfe2221d Content-Type: text/plain; charset="UTF-8" Hi Harald, It is definitely possible for us to send liaison statements via the appropriate channel, but I am missing some context. Can you provide a citation to the document from which the excerpt comes? (It appears to be labeled a white paper, so the first step may be to confirm that its description and the underlying specs say the same thing.) regards, Ted Hardie On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand wrote: > It's come to my attention that there's apparently some 5G spec that says > "Use WebRTC datachannel, but don't bother with this ICE stuff". > > The exact quote is below. > > Now I don't mind saying "don't use TURN/STUN servers" - that's a > configuration option on the WEBRTC API, and anyone can choose to not do > that - but I do mind leaving out ICE. An ICE-supporting implementation > won't interwork properly with an implementation that doesn't support ICE. > > Is it possible for the IETF to say "please don't make incompatible > changes to our protocols without asking us"? (that's the version where I > try not to use expletives). > > Or is it possible that this is all a misunderstanding, and the 5G folks > actually meant to require peer-to-peer ICE, but just wrote it wrongly? > > Or did I misunderstand what the WG's intent was, and should just suck it > up and interoperate with non-ICE-supporting endpoints? > > Harald > > --------- Spec reference quote ---------- > > 1. Spec > NG.129 - 5G Data Channel White Paper (CR1001) > > 8.2.1Data channel APIs > The data channel application consists of the device side logic and the > server side logic. > Both should use standardized APIs that need to be agreed by the industry. > W3C WebRTC1.0 data channel API specification is suggested as the > preferred IMS data channel API. RTCPeerConnection , > RTCDataChannel object, the callbacks need to be supported . > Only data channel API related definitions are used and IMS data channel > API is not allowed to use WebRTC media. > ICE/STUN/TURN are also not required. > > # Reference > 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction > GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS > GSMA NG.129_5G DATA CHANNEL > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000e41cdf05cfe2221d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Harald,

= It is definitely possible for us to send liaison statements via the appropr= iate channel, but I am missing some context.=C2=A0 Can you provide a citati= on to the document from which the excerpt comes?=C2=A0 (It appears to be la= beled a white paper, so the first step may be to confirm that its descripti= on and the underlying specs say the same thing.)

regards,

Ted Hardie

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvest= rand <harald@alvestrand.no&g= t; wrote:
It'= ;s come to my attention that there's apparently some 5G spec that says =
"Use WebRTC datachannel, but don't bother with this ICE stuff"= ;.

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - t= hat's a
configuration option on the WEBRTC API, and anyone can choose to not do that - but I do mind leaving out ICE. An ICE-supporting implementation
won't interwork properly with an implementation that doesn't suppor= t ICE.

Is it possible for the IETF to say "please don't make incompatible=
changes to our protocols without asking us"? (that's the version w= here I
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck i= t
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper=C2=A0 (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the
server side logic.
Both should use standardized APIs that need to be agreed by the industry. W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the=C2=A0 callbacks need to be supported .
Only data channel API related definitions=C2=A0 are used and IMS data chann= el
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000e41cdf05cfe2221d-- From nobody Wed Nov 3 11:38:34 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885973A0959 for ; Wed, 3 Nov 2021 11:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 qVYLK4cBh3rI for ; Wed, 3 Nov 2021 11:38:28 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20619.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::619]) (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 332BB3A0978 for ; Wed, 3 Nov 2021 11:38:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z2ivDUPQVWhJ2VyHetpDEgG63M7ua60fNDH6d7dCSV4qsyGY+6rypTsOAoqlba/uOR1y0qabYIO4Qtf6+aX5g1JE4f3Qdhgxdlq0JtjEog9MiKo1K9m0qXmeCBwBpNCw6dUS75yb1dr0xcJFLJtctYd+To8ueGwuL8cGtuBtgHZjmx/qYHH64bZDi5fVP0P5/JKGTDYYpKilhHTLOwX37PrdPrPT9hTOucBWn4SnYmgMht6JQKLuuTX6r+Z9Kac3g2INUr8RQqJ2fdrxH3qFoWoWPzDF7q0wz/1dXhfy/QUc69Euxy/xIVgiKT8cI45D5K0Z6jTOevdQfUDx+r9e9w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7+7dNDlR709ySIgOQIAvwKH5SusRpbhEbq68ZTHvA2M=; b=g6DuN8JohTHWXoUchL9kUuEOUn8yC1QnHsJ8i/FIxqeMKQKkrO4EpdKiidJylQW54jrcl5P7KR4b1VxwGkhl3bHpE7v9epRuZ2sWLPzEDY3JSWzFV2+d+bRWmBGPXKtK9oG0Wo1lNG0hEFUsC91Osf4DOYR2YXDY5zVGi3xyTTO4vYFdd7ghMU2uo8hpvjVukIDPWJW6BCoOkA0EyWgT6YGBLX974+Ys3VcZN+FFFeBZW5At8n4gDezLzFQJJ6HaN4kBXHB0chCJ3KCY4IPsuJkSvyM7UHhO7NpJMLwQx4aqfz+KYQBI4RWEWYNbFJFIcJbkME/yYhXbUXRP6HlhMQ== 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=7+7dNDlR709ySIgOQIAvwKH5SusRpbhEbq68ZTHvA2M=; b=eDEj0QIAS8yS7cSxtEDtSfwenHX1IN3jd38uP3AuwnlzFDNX67WkG9IsHluUL+YQmhtpN/chcKAZxh42rF4XK+n6By0EJ0qqzmzwvNEGPgOwEqugctYyoe7Bw16RiePcf0uV5j1eto5QJCuwlzNQHxzAxlc08KUBjh6IXOqR+RM= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR0701MB2155.eurprd07.prod.outlook.com (2603:10a6:3:24::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.8; Wed, 3 Nov 2021 18:38:23 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.011; Wed, 3 Nov 2021 18:38:23 +0000 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: Justin Uberti , RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B32AAGQiAIAA528AgAASO+CAAHHigIAABbShgAAQjQCAADc8UIABZ1Uw Date: Wed, 3 Nov 2021 18:38:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 43c0e563-b631-ccff-8370-d676621200e7 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbffea69-7db3-4932-a426-08d99ef91e1a x-ms-traffictypediagnostic: HE1PR0701MB2155: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rn5WTl6eHCeWaWjbD6ZLNQRnZ6PL8g61ztwO2OrcU3ACl3hJG0L9bC1rjBxcNPesA7cYDLVWlckUD3Aff6euSe9IKYSW/6WWhE1CIlyBivt6jUH57R7146heQSP5canaFQY7KGf188EO1yANRoa08Gwwc8mqfUB9lzo5QndVWL4gX5W10/pC6ABxOGljs7crr3uMMgh0dUfdBYFmMhwF8v0ydbe2QKeTtu7cqIxxUiwyYXtWWd+dK3BqGpgFeGsRVWF5K9Dcp0UWrvks0s0Sm5KlfoAnn34A87Bn+zw0ohvPZSKIG+pcHMuC9LotvLuYhyZMazAlimza/1pcjlawCOVlhoqQHWQgNvH8b3T+91AwnxwYEMLcdjwEZEJEd2o3bwsWsX9N61aT1STWxUoI882yqhJ3aKm51bY1OXrGc/W00X4rKDODqb4OpH0wnl6UbzSEFOYp9iu/+a0X2Q6bSKY3PdXkLUqGpxbqwtqpf/dGjGwaFIEHsQiIXCnj/nHttr4a0fhg7W8eCwHVukrN9rdYmIYmZczAn3lit3vThU6ysJkDz+yirSS1a4AhO/H2mFiu7TXdbYDleUZWcj7FY+dwf52Y/XKnSeWvDjFvh3LvMzGYFUQxYrIwf+jX5zwCcplHaoKevynMS3Ank1Vzc4+lKZ+wN63Df7gRJJpCkBwWUkkLlYgHkoN1y1EutvdlhylZYqM2ywjetesdYDAsJMA+Ox5sv5fwgY0BOk1F2nOa7PTzEAfAE06P5TO4OhTAZmEiaPo8o5W+Ra61l4ejHQRiRqlLLDKFgGi7s3L3uNg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38100700002)(8936002)(186003)(9686003)(122000001)(86362001)(26005)(71200400001)(508600001)(8676002)(5660300002)(44832011)(91956017)(76116006)(55016002)(52536014)(19627405001)(53546011)(66556008)(54906003)(66476007)(66946007)(6506007)(64756008)(7696005)(19627235002)(166002)(83380400001)(110136005)(316002)(33656002)(38070700005)(4326008)(2906002)(82960400001)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?wgE1PjiCD5TSUTvCYSFa817ytx4Sx7f7uobwBCD46MlwI5kIyNROz9cA?= =?Windows-1252?Q?RWa1qfPgsZV+6wf9HyVDOHrqXfXeTnWuCW1ShoVQF6IF+uIgZj4e6oSH?= =?Windows-1252?Q?FqDSrgCh6adDFNEqQYk/MqX5RGs28DNYe43WExT0a8yuaFhoseHiFlyG?= =?Windows-1252?Q?Rf5phpozv2sOPiOQqvT8eO9Rfn9uVbLZzK9FqNJt6SMaHzImpYwMzOws?= =?Windows-1252?Q?30FJtlzNzPz+HeGjNYx1grKs7KORH8qGYHp2fGkxefT/sHIeRRtUC5D0?= =?Windows-1252?Q?nXhnhinrx07c1UFRwQWWGdoVSBh85rlLuffGOGs12oFjKrKGAYsnVZqe?= =?Windows-1252?Q?n33fUSPa51mrNS0JSGLj7ZaSlz39kE/46gCIEB8ZpQviHwUJnkCtxbVq?= =?Windows-1252?Q?x3m4Splo2ruL+TeUkSijPGo6HxWnWJTAiNrw7oSXwjKeFdB5jL+9kahW?= =?Windows-1252?Q?NI1jHy1FrgPVDMeCblOwWdEJl98WXVqVxVUW49Bz+odSP4SxlRxWfn6w?= =?Windows-1252?Q?iBKRhs35Fo8gKa5JuvxZvLA9gxg/BmrhlcUbAP26W/pK1SqfAzIlnJ+D?= =?Windows-1252?Q?Dse3YMZJ1Yha3NABqphnAKvXeEfZfuWAFKGHW4R2wujnks4rzsZ4oy9c?= =?Windows-1252?Q?tkvAE6QLqiUsWqari6GUd8wXZfhDmW3oTOFaQztHl/Nuv1R3K4xEqc15?= =?Windows-1252?Q?kRSmnKgBCwqBaFEdPqWTsfhOofJG/hKseVDh3pL/uAfIi8z2WyVQV/CC?= =?Windows-1252?Q?Pqyoal6sYHoTLa14NauePmG4P2MVuetxp0I0baDYNOpCjer9iCLrcKDk?= =?Windows-1252?Q?F9NZB7EpxMuT5fy2Gwf0fwXwtCrOTCztuhwvzIWLdk57TNggA4k1Yt14?= =?Windows-1252?Q?baXZMIdtuhSw++GHP8GApWaoUADKTcRTmvNdEL5AZvB0QfKVm8BociZz?= =?Windows-1252?Q?zglLQsEWsFauLbepuvoh6H5G8jnnyiMXF3y52XXY55S5y1yM1fvK9c2w?= =?Windows-1252?Q?sFJfgavIvZsxSCSsU2r0ZwA03s+fbk8mlHFcSmoIZLCjefE0xPFqmi5p?= =?Windows-1252?Q?inOcOKxqagVzgyMEYZp5TzQSeb2gBKVN4j/4LpmwsW94O1X3jWVHNVLK?= =?Windows-1252?Q?h6gACpG1sLhsH761Kalpqcf/RdBsFq3ykQj/FP+wV/7ms9JUCXd5OcPy?= =?Windows-1252?Q?INl3bUNYzjyO00ULi2w7eYgv/fKQHUlKtynaqnYly3S9As0rebvS3Ge8?= =?Windows-1252?Q?Y9j68zkdT47Ddz0W7RDjfkDw1tJEI3V8rejzbscIRJrV3D5dWzTwwsBY?= =?Windows-1252?Q?kl1jqgIu35E1B/KFbpEZQXWjArgp3AjTYueC7QndbTHxMTnUF4UsBHfK?= =?Windows-1252?Q?LRw3X5ms3Zz2yekVzvkGMplpdbEu/YaE/CQM8xJWCHpdwhhStEMigy8b?= =?Windows-1252?Q?5041Exlz8Mfg6Lyw1JLfSblqSNbs3HAcv3bfo1StYTg62tmCqZ/fa7W4?= =?Windows-1252?Q?x31ydlmIJk2sS4EN5ccJ21+ryC/3Nz28TpcRix2XOcaJU/fAXGGrgIIq?= =?Windows-1252?Q?o21PpIZOAypuhKfM2RO8lV4JNPLQq0itG/X6SH3y3qbDd0s6u3kTqo+0?= =?Windows-1252?Q?EwVpK2hzgQaUFI95PFUnpz2EXATNKk8FitzfgPwuOX+Rj9nFVQu22RT5?= =?Windows-1252?Q?1uASaAvGqP6a/EApgVLd7V7pi7l8DxnOhOJ1V+cK0Acl91LZoqgGlCfF?= =?Windows-1252?Q?taQXJ9QdBQgM2BCHk2Bjf9LNJLgkODz3BQbda7U7y/Y4GD5Jz86ieT60?= =?Windows-1252?Q?gsjYnw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4441A01ACCD11217261C124A938C9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbffea69-7db3-4932-a426-08d99ef91e1a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2021 18:38:23.7454 (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: seAHHp637NhE6KpBW3ZhVD5xIFN0CZ+7MdRaGTCCAnBlU8jHNmRs08BUKzxBE8HyEGldTzlvZzB67SzLo7gox9sqnXfIRxAPRJP9INnmNJg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2155 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 18:38:34 -0000 --_000_HE1PR07MB4441A01ACCD11217261C124A938C9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Justin, are you ok with the suggested text? I would probably be a good idea= to refer it in 8829bis. Regards, Christer ________________________________ From: rtcweb on behalf of Christer Holmberg Sent: Tuesday, November 2, 2021 11:13 PM To: Roman Shpount Cc: Justin Uberti ; RTCWeb IETF Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt Hi, >This makes it much better. I think it is missing a couple of commas ("In s= ome 3PCC scenarios," and "In the rewritten offer,") but works for me. I can add them when I add the text to the draft, but I think the RFC editor= will most likely notice such thing. >I have changed the section name so it is clear that it applies to JSEP as = well, not just SIP. Sure, that=92s fine. Regards, Christer On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg > wrote: Hi, Eventhough I would not like to make more changes than necessary, I am fine = with "3PCC Considerations". However, your suggested text is very difficult to understand in some places= , so let me give it a try. (The first paragraph is generic, the second SIP specific, and the third BUN= DLE specific.) --- 3PCC Considerations In some 3PCC scenarios a new session will be established between an endpoin= t that is currently part of an ongoing session and an endpoint that is curr= ently not part of an ongoing session. The endpoint that is part of a sessio= n will generate a subsequent offer that will be forwarded to the other endp= oint by a 3PCC controller. The endpoint that is not part of a session will = process the offer as an initial offer. The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client = (UAC) to send a re-INVITE request without an SDP body (sometimes referred t= o as an empty re-INVITE). In such cases, the User Agent Server (UAS) will i= nclude an SDP offer in the associated 200 OK response. If the UAS is a part= of an ongoing session, it will include a subsequent offer in the 200 OK re= sponse. The offer will be received by a 3PCC controller (UAC) and then forw= arded to another User Agent (UA). If the UA is not part of an ongoing sessi= on, it will process the offer as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer in= to a valid initial offer, following the procedures in (Section 7.2), before= it forwards the offer to a UA. In the rewritten offer the 3PCC controller = will set the port value to zero (and include an SDP 'bundle-only' attribute= ) for each "m=3D" section within the BUNDLE group, excluding the offerer-ta= gged "m=3D" section. ________________________________ From: Roman Shpount > Sent: Tuesday, November 2, 2021 6:33 PM To: Christer Holmberg > Cc: Justin Uberti >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e.,= a subsequent offer, will be used by a 3PCC controller to establish a new s= ession and forwarded as an initial offer to another endpoint that is curren= tly not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS = is a part of an ongoing session, it will include a subsequent offer in the = 200 OK response. The offer will be received by a 3PCC controller (UAC) and = then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Ther= efore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid= initial offer before it is used to establish a new session. To make the su= bsequent offer a valid initial offer, 3PCC will need to modify all the non-= tagged m=3D lines to include the bundle-only attribute and set the m=3D lin= e port to zero. _____________ Roman Shpount On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg > wrote: Hi, What about something like this: --- OLD: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the pro= cedures defined in Section 7.2.=94 NEW: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will= therefore include a subsequent offer in the 200 OK responses. The offer wi= ll be received by a 3PCC controller (UAC) and then forwarded as an initial offer = to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look differen= t than a subsequent BUNDLE offer, it cannot be assumed that a UA that expec= ts an initial offer will be able to properly process a subsequent offer. Therefore, the 3PCC co= ntroller needs to act as a Back-To-Back User Agent (B2BUA), and when it rec= eives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded t= o such UA.=94 ---- Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti > wrote: The PROBLEM is that we have two endpoints, where one sends a subsequent off= er, and the other one expects an initial offer. What do you normally do whe= n you have that kind of problem? You use an SBC/B2BUA. In this case that SB= C/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simp= ly add a note somewhere (in 8843bis and/or 8829bis) which describes the iss= ue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyw= ay then maybe adding a=3Dbundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent off= er is going to be used as initial, and should be able to rewrite the offer = to make it valid. We can change SIP Considerations section in 8843bis (http= s://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-c= onsideration), remove the SHOULD, and specify that 3PCC controller should f= ix the offer. We can then reference this note from 8829bis or restate the s= ame guidance. _____________ Roman Shpount --_000_HE1PR07MB4441A01ACCD11217261C124A938C9HE1PR07MB4441eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Justin, are you ok with the suggested text? I would probably be a good idea= to refer it in 8829bis.

Regards,

Christer
From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Christer Holmberg <christer.holmberg=3D40= ericsson.com@dmarc.ietf.org>
Sent: Tuesday, November 2, 2021 11:13 PM
To: Roman Shpount <roman@telurix.com>
Cc: Justin Uberti <justin@uberti.name>; RTCWeb IETF <rtcweb= @ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt
 

Hi,

 

>This makes it much better= . I think it is missing a couple of commas ("In some 3PCC scena= rios," and "In the rewritten offer,") but works for me.

 

I can add them when I add the= text to the draft, but I think the RFC editor will most likely notice such= thing.

 

>I have changed the sectio= n name so it is clear that it applies to JSEP as well, not just SIP.=

 

Sure, that=92s fine.

 

Regards,

 

Christer

 

 

 

On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg &= lt;christer.holmberg@eric= sson.com> wrote:

Hi,<= /span>

&nbs= p;

Even= though I would not like to make more changes than necessary, I am fine with= "3PCC Considerations".

&nbs= p;

Howe= ver, your suggested text is very difficult to understand in some places, so= let me give it a try.

&nbs= p;

(The= first paragraph is generic, the second SIP specific, and the third BUNDLE = specific.)

&nbs= p;

---<= /span>

&nbs= p;

3PCC Considerations

 

In some 3PCC scenarios a new session will be estab= lished between an endpoint that is currently part of an ongoing session and= an endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generat= e a subsequent offer that will be forwarded to the other endpoint by a 3PCC= controller. The endpoint that is not part of a session will process the of= fer as an initial offer. 

 

The Session Initiation Protocol (SIP) [RFC3261] al= lows a User Agent Client (UAC) to send a re-INVITE request without an SDP b= ody (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP= offer in the associated 200 OK response. If the UAS is a part of an ongoin= g session, it will include a subsequent offer in the 200 OK response. The o= ffer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA = is not part of an ongoing session, it will process the offer as an initial = offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following = the procedures in (Section 7.2), before it forwards the offer to a UA. In t= he rewritten offer the 3PCC controller will set the port value to zero (and= include an SDP 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, excluding the o= fferer-tagged "m=3D" section.

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

From: Roman Shpount <roman@telurix.com>
Sent: Tuesday, November 2, 2021 6:33 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti= <justin@uberti.= name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

 

How about we replace the SIP Considerations with: =

 

3PCC Considerations

 

In some 3PCC scenarios, an offer generated during = an ongoing session, i.e., a subsequent offer, will be used by a 3PCC contro= ller to establish a new session and forwarded as an initial offer to anothe= r endpoint that is currently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session,= it will include a subsequent offer in the 200 OK response. The offer will = be received by a 3PCC controller (UAC) and then forwarded to another User A= gent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rew= rite the subsequent offer into a valid initial offer before it is used to e= stablish a new session. To make the subsequent offer a valid initial offer,= 3PCC will need to modify all the non-tagged m=3D lines to include the bundle-only attribute and set the m= =3D line port to zero.

_____________
Roman Shpount

 

 

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

What about something like this:

 

---

 

OLD:

 

=93The Session Initiation Protocol (SIP) [RFC3261] = allows a User Agent Client (UAC) to send a re-INVITE request without an SDP= body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent Server (UAS) will inc= lude an SDP Offer in the associated 200 OK response. This is typically used= for 3rd Party Call Control (3PCC) scenarios.

From a BUNDLE perspective, such SDP Offer SHOULD be= generated using the procedures defined in Section 7.2.=94

 

NEW:

 

=93The Session Initiation Protocol (SIP) [RFC3261] = allows a User Agent Client (UAC) to send a re-INVITE request without an SDP= body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent Server (UAS) will inc= lude an SDP offer in the associated 200 OK response. This is typically used= for 3rd Party Call Control (3PCC) scenarios.

 

In some 3PCC scenarios the UAS will be part of an o= ngoing session, and will therefore include a subsequent offer in the 200 OK= responses. The offer will be

received by a 3PCC controller (UAC) and then forwar= ded as an initial offer to another User Agent (UA) that is currently not pa= rt of a session.

 

When the BUNDLE mechanism is used, as an initial BU= NDLE offer look different than a subsequent BUNDLE offer, it cannot be assu= med that a UA that expects an initial offer

will be able to properly process a subsequent offer= . Therefore, the 3PCC controller needs to act as a Back-To-Back User Agent = (B2BUA), and when it receives the subsequent

offer it needs to rewrite it into an initial offer = before it is forwarded to such UA.=94

 

----

 

Regards,

 

Christer

 

 

 

 

 

 

 

 

From: Roman Shpo= unt <roman@teluri= x.com>
Sent: tiistai 2. marraskuuta 2021 10.41
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ub= erti <justin@ube= rti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

 

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <juberti@alphaexplorationco.com= > wrote:

The PROBLEM is that we have two endpoints, where one sends a subsequent = offer, and the other one expects an initial offer. What do you normally do = when you have that kind of problem? You use an SBC/B2BUA. In this case that= SBC/B2BUA would be the 3PCC controller.

 

So, my suggestion would be to remove the SHOULD text from 8843bis, and s= imply add a note somewhere (in 8843bis and/or 8829bis) which describes the = issue and says that the 3GPP controller needs to modify the offer according= ly.

 

Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP a= nyway then maybe adding a=3Dbundle-only isn't the end of the world.

 

I am not opposed to this idea. 3PCC typically knows that the subseq= uent offer is going to be used as initial, and should be able to rewrite th= e offer to make it valid. We can change SIP Considerations section in = 8843bis (https://www.ietf.or= g/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. = We can then reference this note from 8829bis or restate the same guidance.<= /p>

_____________
Roman Shpount

 

--_000_HE1PR07MB4441A01ACCD11217261C124A938C9HE1PR07MB4441eurp_-- From nobody Thu Nov 4 20:34:04 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F083A0B94 for ; Thu, 4 Nov 2021 20:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBX_mbjD0Fu1 for ; Thu, 4 Nov 2021 20:33:55 -0700 (PDT) Received: from smtp102.iad3b.emailsrvr.com (smtp102.iad3b.emailsrvr.com [146.20.161.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815EA3A0B92 for ; Thu, 4 Nov 2021 20:33:55 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp5.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A3A504007A; Thu, 4 Nov 2021 23:33:53 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_51800772-1F87-4C88-B0B3-151EFCAAF4BF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Cullen Jennings In-Reply-To: Date: Thu, 4 Nov 2021 21:33:52 -0600 Cc: RTCWeb IETF Message-Id: References: To: Christer Holmberg , Roman Shpount , Justin Uberti X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Classification-ID: 36a3c7b9-8840-4831-9703-6e5360ae02a4-1-1 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 03:34:02 -0000 --Apple-Mail=_51800772-1F87-4C88-B0B3-151EFCAAF4BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Could we have a quick call on this next week during one of the breaks. I = have tried to follow this whole thread and some it does not make much = sense to me. I=E2=80=99m a bit lost on what the varios proposed = resolutions are.=20 > On Nov 3, 2021, at 12:38 PM, Christer Holmberg = wrote: >=20 > Justin, are you ok with the suggested text? I would probably be a good = idea to refer it in 8829bis. >=20 > Regards, >=20 > Christer > From: rtcweb > on behalf of Christer Holmberg = > > Sent: Tuesday, November 2, 2021 11:13 PM > To: Roman Shpount > > Cc: Justin Uberti >; = RTCWeb IETF > > Subject: Re: [rtcweb] Working Group Last Call for = draft-uberti-rtcweb-rfc8829bis-01.txt > =20 > Hi, > =20 > >This makes it much better. I think it is missing a couple of commas = ("In some 3PCC scenarios," and "In the rewritten offer,") but works for = me. > =20 > I can add them when I add the text to the draft, but I think the RFC = editor will most likely notice such thing. > =20 > >I have changed the section name so it is clear that it applies to = JSEP as well, not just SIP. > =20 > Sure, that=E2=80=99s fine. > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg = > = wrote: > Hi, > =20 > Eventhough I would not like to make more changes than necessary, I am = fine with "3PCC Considerations". > =20 > However, your suggested text is very difficult to understand in some = places, so let me give it a try. > =20 > (The first paragraph is generic, the second SIP specific, and the = third BUNDLE specific.) > =20 > --- > =20 > 3PCC Considerations > =20 > In some 3PCC scenarios a new session will be established between an = endpoint that is currently part of an ongoing session and an endpoint = that is currently not part of an ongoing session. The endpoint that is = part of a session will generate a subsequent offer that will be = forwarded to the other endpoint by a 3PCC controller. The endpoint that = is not part of a session will process the offer as an initial offer.=20 > =20 > The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent = Client (UAC) to send a re-INVITE request without an SDP body (sometimes = referred to as an empty re-INVITE). In such cases, the User Agent Server = (UAS) will include an SDP offer in the associated 200 OK response. If = the UAS is a part of an ongoing session, it will include a subsequent = offer in the 200 OK response. The offer will be received by a 3PCC = controller (UAC) and then forwarded to another User Agent (UA). If the = UA is not part of an ongoing session, it will process the offer as an = initial offer. >=20 > When the BUNDLE mechanism is used, an initial BUNDLE offer is = constructed using different rules than subsequent BUNDLE offers, and it = cannot be assumed that a UA is able to correctly process a subsequent = offer as an initial offer. Therefore, the 3PCC controller SHOULD rewrite = the subsequent offer into a valid initial offer, following the = procedures in (Section 7.2), before it forwards the offer to a UA. In = the rewritten offer the 3PCC controller will set the port value to zero = (and include an SDP 'bundle-only' attribute) for each "m=3D" section = within the BUNDLE group, excluding the offerer-tagged "m=3D" section. > =20 > =20 > =20 > =20 > =20 > =20 > From: Roman Shpount > > Sent: Tuesday, November 2, 2021 6:33 PM > To: Christer Holmberg > > Cc: Justin Uberti >; Justin Uberti = >; RTCWeb IETF = > > Subject: Re: [rtcweb] Working Group Last Call for = draft-uberti-rtcweb-rfc8829bis-01.txt > =20 > How about we replace the SIP Considerations with:=20 > =20 > 3PCC Considerations > =20 > In some 3PCC scenarios, an offer generated during an ongoing session, = i.e., a subsequent offer, will be used by a 3PCC controller to establish = a new session and forwarded as an initial offer to another endpoint that = is currently not part of a session. >=20 > For example, the Session Initiation Protocol (SIP) [RFC3261] allows a = User Agent Client (UAC) to send a re-INVITE request without an SDP body = (sometimes referred to as an empty re-INVITE). In such cases, the User = Agent Server (UAS) will include an SDP offer in the associated 200 OK = response. If UAS is a part of an ongoing session, it will include a = subsequent offer in the 200 OK response. The offer will be received by a = 3PCC controller (UAC) and then forwarded to another User Agent (UA) as = an initial offer. >=20 > When the BUNDLE mechanism is used, an initial BUNDLE offer is = constructed using different rules than subsequent BUNDLE offers. It = cannot be assumed that a subsequent offer is a valid initial offer and = that the endpoint that expects an initial offer will properly process = such a subsequent offer. Therefore, the 3PCC controller SHOULD rewrite = the subsequent offer into a valid initial offer before it is used to = establish a new session. To make the subsequent offer a valid initial = offer, 3PCC will need to modify all the non-tagged m=3D lines to include = the bundle-only attribute and set the m=3D line port to zero. > _____________ > Roman Shpount > =20 > =20 > On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg = > = wrote: > Hi, > =20 > What about something like this: > =20 > --- > =20 > OLD: > =20 > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body = (sometimes referred to as an empty re-INVITE). > In such cases, the User Agent Server (UAS) will include an SDP Offer = in the associated 200 OK response. This is typically used for 3rd Party = Call Control (3PCC) scenarios. > =46rom a BUNDLE perspective, such SDP Offer SHOULD be generated using = the procedures defined in Section 7.2.=E2=80=9D > =20 > NEW: > =20 > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body = (sometimes referred to as an empty re-INVITE). > In such cases, the User Agent Server (UAS) will include an SDP offer = in the associated 200 OK response. This is typically used for 3rd Party = Call Control (3PCC) scenarios. > =20 > In some 3PCC scenarios the UAS will be part of an ongoing session, and = will therefore include a subsequent offer in the 200 OK responses. The = offer will be > received by a 3PCC controller (UAC) and then forwarded as an initial = offer to another User Agent (UA) that is currently not part of a = session. > =20 > When the BUNDLE mechanism is used, as an initial BUNDLE offer look = different than a subsequent BUNDLE offer, it cannot be assumed that a UA = that expects an initial offer > will be able to properly process a subsequent offer. Therefore, the = 3PCC controller needs to act as a Back-To-Back User Agent (B2BUA), and = when it receives the subsequent > offer it needs to rewrite it into an initial offer before it is = forwarded to such UA.=E2=80=9D > =20 > ---- > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > From: Roman Shpount >=20 > Sent: tiistai 2. marraskuuta 2021 10.41 > To: Justin Uberti > > Cc: Christer Holmberg >; Justin Uberti = >; RTCWeb IETF = > > Subject: Re: [rtcweb] Working Group Last Call for = draft-uberti-rtcweb-rfc8829bis-01.txt > =20 > On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti = > = wrote: > The PROBLEM is that we have two endpoints, where one sends a = subsequent offer, and the other one expects an initial offer. What do = you normally do when you have that kind of problem? You use an = SBC/B2BUA. In this case that SBC/B2BUA would be the 3PCC controller. > =20 > So, my suggestion would be to remove the SHOULD text from 8843bis, and = simply add a note somewhere (in 8843bis and/or 8829bis) which describes = the issue and says that the 3GPP controller needs to modify the offer = accordingly. > =20 > Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP = anyway then maybe adding a=3Dbundle-only isn't the end of the world. > =20 > I am not opposed to this idea. 3PCC typically knows that the = subsequent offer is going to be used as initial, and should be able to = rewrite the offer to make it valid. We can change SIP Considerations = section in 8843bis = (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name= -sip-consideration = ), remove the SHOULD, and specify that 3PCC = controller should fix the offer. We can then reference this note from = 8829bis or restate the same guidance. > _____________ > Roman Shpount > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_51800772-1F87-4C88-B0B3-151EFCAAF4BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Could we have a quick call on this next = week during one of the breaks. I have tried to follow this whole thread = and some it does not make much sense to me. I=E2=80=99m a bit lost on = what the varios proposed resolutions are. 


On Nov 3, 2021, at 12:38 PM, Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org> = wrote:

Justin, are you ok with the = suggested text? I would probably be a good idea to refer it in = 8829bis.

Regards,

Christer
From: rtcweb <rtcweb-bounces@ietf.org> = on behalf of Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org>
Sent: Tuesday, November 2, 2021 = 11:13 PM
To: Roman Shpount <roman@telurix.com>
Cc: Justin Uberti <justin@uberti.name>; = RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group = Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt
 
Hi,

 

>This makes = it much better. I= think it is missing a couple of commas ("In some 3PCC scenarios," and = "In the rewritten offer,") but works for me.

 

I can add them when I add the text to the draft, but I think = the RFC editor will most likely notice such = thing.

 

>I = have changed the section name so it is clear that it applies to JSEP as = well, not just SIP.

 

Sure, that=E2=80=99s fine.

 

Regards,

 

Christer

 

 

 

On Tue, Nov 2, 2021 at 1:24 PM Christer = Holmberg <christer.holmberg@ericsson.com> = wrote:
Hi,

 

Eventhough I would not like to make more changes than = necessary, I am fine with "3PCC Considerations".

 

However, your suggested text is very difficult to understand = in some places, so let me give it a try.

 

(The = first paragraph is generic, the second SIP specific, and the third = BUNDLE specific.)

 

---

 

3PCC = Considerations

 

In some 3PCC scenarios a new session = will be established between an endpoint that is currently part of an = ongoing session and an endpoint that is currently not part of an ongoing = session. The endpoint that is part of a session will generate a = subsequent offer that will be forwarded to the other endpoint by a 3PCC = controller. The endpoint that is not part of a session will process the = offer as an initial offer. 

 

The Session Initiation Protocol = (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE = request without an SDP body (sometimes referred to as an empty = re-INVITE). In such cases, the User Agent Server (UAS) will include an = SDP offer in the associated 200 OK response. If the UAS is a part of an = ongoing session, it will include a subsequent offer in the 200 OK = response. The offer will be received by a 3PCC controller (UAC) and then = forwarded to another User Agent (UA). If the UA is not part of an = ongoing session, it will process the offer as an initial offer.

When the BUNDLE mechanism is used, an initial = BUNDLE offer is constructed using different rules than subsequent BUNDLE = offers, and it cannot be assumed that a UA is able to correctly process = a subsequent offer as an initial offer. Therefore, the 3PCC controller = SHOULD rewrite the subsequent offer into a valid initial offer, = following the procedures in (Section 7.2), before it forwards the offer = to a UA. In the rewritten offer the 3PCC controller will set the port = value to zero (and include an SDP 'bundle-only' attribute) for each "m=3D"= section within the BUNDLE group, excluding the offerer-tagged "m=3D" = section.

 

 

 

 

 

 

From: Roman Shpount <roman@telurix.com>Sent: Tuesday, November 2, 2021 = 6:33 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti <justin@uberti.name>; = RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group = Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

 

How about we replace the = SIP Considerations with: 

 

3PCC Considerations

 

In some 3PCC scenarios, an offer generated = during an ongoing session, i.e., a subsequent offer, will be used by a = 3PCC controller to establish a new session and forwarded as an initial = offer to another endpoint that is currently not part of a session.

For example, the Session Initiation Protocol = (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE = request without an SDP body (sometimes referred to as an empty = re-INVITE). In such cases, the User Agent Server (UAS) will include an = SDP offer in the associated 200 OK response. If UAS is a part of an = ongoing session, it will include a subsequent offer in the 200 OK = response. The offer will be received by a 3PCC controller (UAC) and then = forwarded to another User Agent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial = BUNDLE offer is constructed using different rules than subsequent BUNDLE = offers. It cannot be assumed that a subsequent offer is a valid initial = offer and that the endpoint that expects an initial offer will properly = process such a subsequent offer. Therefore, the 3PCC controller SHOULD = rewrite the subsequent offer into a valid initial offer before it is = used to establish a new session. To make the subsequent offer a valid = initial offer, 3PCC will need to modify all the non-tagged m=3D lines to = include the bundle-only attribute and set the m=3D line port to zero.
_____________
Roman = Shpount

 

 

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg = <christer.holmberg@ericsson.com> = wrote:
Hi,

 

What = about something like this:

 

---

 

OLD:

 

=E2=80=9CT= he Session Initiation Protocol (SIP) [RFC3261] allows a User Agent = Client (UAC) to send a re-INVITE request without an SDP body (sometimes = referred to as an empty re-INVITE).
In = such cases, the User Agent Server (UAS) will include an SDP Offer in the = associated 200 OK response. This is typically used for 3rd Party Call = Control (3PCC) scenarios.
=46rom a = BUNDLE perspective, such SDP Offer SHOULD be generated using the = procedures defined in Section 7.2.=E2=80=9D

 

NEW:

 

=E2=80=9CThe Session Initiation Protocol (SIP) = [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request = without an SDP body (sometimes referred to as an empty = re-INVITE).
In such cases, the User = Agent Server (UAS) will include an SDP offer in the associated 200 OK = response. This is typically used for 3rd Party Call Control (3PCC) = scenarios.

 

In some 3PCC scenarios the UAS will be part of = an ongoing session, and will therefore include a subsequent offer in the = 200 OK responses. The offer will be
received by a 3PCC controller (UAC) and then forwarded as an = initial offer to another User Agent (UA) that is currently not part of a = session.

 

When the BUNDLE mechanism is used, as an = initial BUNDLE offer look different than a subsequent BUNDLE offer, it = cannot be assumed that a UA that expects an initial = offer
will be able to properly = process a subsequent offer. Therefore, the 3PCC controller needs to act = as a Back-To-Back User Agent (B2BUA), and when it receives the = subsequent
offer it needs to = rewrite it into an initial offer before it is forwarded to such = UA.=E2=80=9D

 

----

 

Regards,

 

Christer

 

 

 

 

 

 

 

 

From: Roman Shpount <roman@telurix.com> 
Sent: tiistai 2. marraskuuta 2021 = 10.41
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Justin Uberti <justin@uberti.name>; = RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group = Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

 

On Mon, Nov 1, = 2021 at 2:52 PM Justin Uberti <juberti@alphaexplorationco.com> = wrote:
The PROBLEM is that we have two = endpoints, where one sends a subsequent offer, and the other one expects = an initial offer. What do you normally do when you have that kind of = problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the = 3PCC controller.

 

So, my = suggestion would be to remove the SHOULD text from 8843bis, and simply = add a note somewhere (in 8843bis and/or 8829bis) which describes the = issue and says that the 3GPP controller needs to modify the offer = accordingly.

 

Roman, thoughts on this? If the 3PCC is going to rewrite the = offer SDP anyway then maybe adding a=3Dbundle-only isn't the end of the = world.

 

I am not opposed to this idea. = 3PCC typically knows that the subsequent offer is going to be used as = initial, and should be able to rewrite the offer to make it valid. We = can change SIP Considerations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05= .html#name-sip-consideration), remove the SHOULD, and specify that = 3PCC controller should fix the offer. We can then reference this note = from 8829bis or restate the same guidance.
_____________Roman Shpount

 

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
= --Apple-Mail=_51800772-1F87-4C88-B0B3-151EFCAAF4BF-- From nobody Thu Nov 4 20:53:16 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BBC3A0BF9 for ; Thu, 4 Nov 2021 20:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=telurix.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 D6bEAADtKga0 for ; Thu, 4 Nov 2021 20:53:08 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 9D26A3A0BF5 for ; Thu, 4 Nov 2021 20:53:08 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id az8so7753297qkb.2 for ; Thu, 04 Nov 2021 20:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VLbOTZuT1NPtbxWgmqKFsIjRdVcK4qvWDI0ehjKjC9Q=; b=bwoOElOWeg9ddN9HTAju8ebUWwPpa8BtUEBfVDpvnJpKDSSfcSmNyYTxM5CMk2H72I LW2ITyW3deUH09cn5k1EHv4+3aMKUBOoo3uDLH22MenMVqo51ac2cY9ahQ+LPw6+LnoN cNlPSm7mrplKdKNMBDy4PHE6JQtm95rlqZGLY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VLbOTZuT1NPtbxWgmqKFsIjRdVcK4qvWDI0ehjKjC9Q=; b=CIJagh/a2LFEs/gV17XLkpR9itgb6z4l0a68hV77wINXT5y5oiOBk22Tc9Z/A/lNgs 4Vza2vCQYEY/sFlGnB7gEu3xuKRNzXmSDkoNYR7cixZ+eiAmpY87tR9yCJHvDqyBjO9I 4frbmEQfB2mjOQ21EYuLA1MTFO7MUl/pGVn9qjenJCqppsjzyo38a5MuHoRVsWg9U/ae zFRsYYZEYHcXlTaQapuCV6TxXa6jStSMz5AnHgAsHLlOjMoqLFOwzdAZjrDqosCJR8Fy ZSP0L5EMwuzypaJAL2nELeUnmmdoLBBrBEBZzqtzUWebp6T+AAo3EsiHp7sxY1I19f+y 4H3A== X-Gm-Message-State: AOAM533c5SlejlFyZtSVj/aiH8Rh1wQxGpCbVvADbdDB+IpQP+NXRli5 6CBu5Unbg/VynRYj2RT2ff93Mhas+lWFxQ== X-Google-Smtp-Source: ABdhPJxVuDq8azoNCtSiZorZKLfEY10dqKeRR2jjhYUd1Gi/yysYJE6+x4St/iHO0toApquwAFxOLQ== X-Received: by 2002:a37:b242:: with SMTP id b63mr43217312qkf.346.1636084383587; Thu, 04 Nov 2021 20:53:03 -0700 (PDT) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id m4sm4745140qkk.32.2021.11.04.20.53.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Nov 2021 20:53:02 -0700 (PDT) Received: by mail-yb1-f178.google.com with SMTP id q74so19597635ybq.11 for ; Thu, 04 Nov 2021 20:53:02 -0700 (PDT) X-Received: by 2002:a25:ca58:: with SMTP id a85mr65289733ybg.155.1636084382395; Thu, 04 Nov 2021 20:53:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Thu, 4 Nov 2021 23:52:50 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Christer Holmberg , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000006f6f1505d002941d" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 03:53:14 -0000 --0000000000006f6f1505d002941d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am available during US Eastern hours. I will try to summarize this discussion: With the latest bundle update, subsequent offers with the bundle (offers where bundled m=3D lines which can no longer be unbundled are not marked in any way except that they share the same communication address) are not valid initial offers for the bundle (where bundled m=3D lines which can no longer be unbundled have the port set to zero and bundle-only attribute). It was not the case with RFC8843 (all offers and answers had bundle-only m= =3D line attributes). If, as a result of 3PCC, a subsequent offer becomes an initial offer, it either needs to be fixed by something (originating endpoint or 3PCC controller), or RFC8843 should be modified to make subsequent offers valid initial offers (detect that bundled m=3D lines shar= e the same address and cannot be unbundled). The solution that Christer and I are proposing is that the 3PCC controller should fix the offer if it were the subsequent offer for one session and was used as the initial offer for another. Christer came up with the text for RFC8843bis to specify this. _____________ Roman Shpount On Thu, Nov 4, 2021 at 11:33 PM Cullen Jennings wrote: > > Could we have a quick call on this next week during one of the breaks. I > have tried to follow this whole thread and some it does not make much sen= se > to me. I=E2=80=99m a bit lost on what the varios proposed resolutions are= . > > > On Nov 3, 2021, at 12:38 PM, Christer Holmberg < > christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote: > > Justin, are you ok with the suggested text? I would probably be a good > idea to refer it in 8829bis. > > Regards, > > Christer > ------------------------------ > *From:* rtcweb on behalf of Christer Holmberg < > christer.holmberg=3D40ericsson.com@dmarc.ietf.org> > *Sent:* Tuesday, November 2, 2021 11:13 PM > *To:* Roman Shpount > *Cc:* Justin Uberti ; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > Hi, > > > >This makes it much better. I think it is missing a couple of commas ("In > some 3PCC scenarios," and "In the rewritten offer,") but works for me. > > > I can add them when I add the text to the draft, but I think the RFC > editor will most likely notice such thing. > > > >I have changed the section name so it is clear that it applies to JSEP a= s > well, not just SIP. > > > Sure, that=E2=80=99s fine. > > > Regards, > > > Christer > > > > > > > On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > Eventhough I would not like to make more changes than necessary, I am fin= e > with "3PCC Considerations". > > > However, your suggested text is very difficult to understand in some > places, so let me give it a try. > > > (The first paragraph is generic, the second SIP specific, and the third > BUNDLE specific.) > > > --- > > > 3PCC Considerations > > > In some 3PCC scenarios a new session will be established between an > endpoint that is currently part of an ongoing session and an endpoint tha= t > is currently not part of an ongoing session. The endpoint that is part of= a > session will generate a subsequent offer that will be forwarded to the > other endpoint by a 3PCC controller. The endpoint that is not part of a > session will process the offer as an initial offer. > > > The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clien= t > (UAC) to send a re-INVITE request without an SDP body (sometimes referred > to as an empty re-INVITE). In such cases, the User Agent Server (UAS) wil= l > include an SDP offer in the associated 200 OK response. If the UAS is a > part of an ongoing session, it will include a subsequent offer in the 200 > OK response. The offer will be received by a 3PCC controller (UAC) and th= en > forwarded to another User Agent (UA). If the UA is not part of an ongoing > session, it will process the offer as an initial offer. > > When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed > using different rules than subsequent BUNDLE offers, and it cannot be > assumed that a UA is able to correctly process a subsequent offer as an > initial offer. Therefore, the 3PCC controller SHOULD rewrite the subseque= nt > offer into a valid initial offer, following the procedures in (Section > 7.2), before it forwards the offer to a UA. In the rewritten offer the 3P= CC > controller will set the port value to zero (and include an SDP > 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, > excluding the offerer-tagged "m=3D" section. > > > > > > > > > > > > > ------------------------------ > *From:* Roman Shpount > *Sent:* Tuesday, November 2, 2021 6:33 PM > *To:* Christer Holmberg > *Cc:* Justin Uberti ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > How about we replace the SIP Considerations with: > > > 3PCC Considerations > > > In some 3PCC scenarios, an offer generated during an ongoing session, > i.e., a subsequent offer, will be used by a 3PCC controller to establish = a > new session and forwarded as an initial offer to another endpoint that is > currently not part of a session. > > For example, the Session Initiation Protocol (SIP) [RFC3261] allows a Use= r > Agent Client (UAC) to send a re-INVITE request without an SDP body > (sometimes referred to as an empty re-INVITE). In such cases, the User > Agent Server (UAS) will include an SDP offer in the associated 200 OK > response. If UAS is a part of an ongoing session, it will include a > subsequent offer in the 200 OK response. The offer will be received by a > 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an > initial offer. > > When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed > using different rules than subsequent BUNDLE offers. It cannot be assumed > that a subsequent offer is a valid initial offer and that the endpoint th= at > expects an initial offer will properly process such a subsequent offer. > Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a > valid initial offer before it is used to establish a new session. To make > the subsequent offer a valid initial offer, 3PCC will need to modify all > the non-tagged m=3D lines to include the bundle-only attribute and set th= e m=3D > line port to zero. > _____________ > Roman Shpount > > > > > On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > What about something like this: > > > --- > > > OLD: > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > In such cases, the User Agent Server (UAS) will include an SDP Offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > From a BUNDLE perspective, such SDP Offer SHOULD be generated using the > procedures defined in Section 7.2.=E2=80=9D > > > NEW: > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > In such cases, the User Agent Server (UAS) will include an SDP offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > > > In some 3PCC scenarios the UAS will be part of an ongoing session, and > will therefore include a subsequent offer in the 200 OK responses. The > offer will be > received by a 3PCC controller (UAC) and then forwarded as an initial offe= r > to another User Agent (UA) that is currently not part of a session. > > > When the BUNDLE mechanism is used, as an initial BUNDLE offer look > different than a subsequent BUNDLE offer, it cannot be assumed that a UA > that expects an initial offer > will be able to properly process a subsequent offer. Therefore, the 3PCC > controller needs to act as a Back-To-Back User Agent (B2BUA), and when it > receives the subsequent > offer it needs to rewrite it into an initial offer before it is forwarded > to such UA.=E2=80=9D > > > ---- > > > Regards, > > > Christer > > > > > > > > > > > > > > > > > *From:* Roman Shpount > *Sent:* tiistai 2. marraskuuta 2021 10.41 > *To:* Justin Uberti > *Cc:* Christer Holmberg ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > > The PROBLEM is that we have two endpoints, where one sends a subsequent > offer, and the other one expects an initial offer. What do you normally d= o > when you have that kind of problem? You use an SBC/B2BUA. In this case th= at > SBC/B2BUA would be the 3PCC controller. > > > So, my suggestion would be to remove the SHOULD text from 8843bis, and > simply add a note somewhere (in 8843bis and/or 8829bis) which describes t= he > issue and says that the 3GPP controller needs to modify the offer > accordingly. > > > > Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP > anyway then maybe adding a=3Dbundle-only isn't the end of the world. > > > I am not opposed to this idea. 3PCC typically knows that the subsequent > offer is going to be used as initial, and should be able to rewrite the > offer to make it valid. We can change SIP Considerations section in 8843b= is > ( > https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name= -sip-consideration), > remove the SHOULD, and specify that 3PCC controller should fix the offer. > We can then reference this note from 8829bis or restate the same guidance= . > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --0000000000006f6f1505d002941d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am available during US Eastern hours.

I will try to summarize this discussion:

With the= latest bundle update, subsequent offers with the bundle (offers where bund= led m=3D lines which can no longer be unbundled are not marked in any way e= xcept that they share the same communication address) are not valid initial= offers for the bundle (where bundled=C2=A0m=3D lines which can no longer b= e unbundled have the port set to zero and bundle-only attribute). It was no= t the case with RFC8843 (all offers and answers had bundle-only m=3D line a= ttributes). If, as a result of 3PCC, a subsequent offer becomes an initial = offer, it either needs to be fixed by something (originating endpoint or 3P= CC controller),=C2=A0or RFC8843 should be modified to make subsequent offer= s valid=C2=A0initial offers (detect that bundled m=3D lines share the same = address and cannot be unbundled). The solution that Christer and I are prop= osing is that the 3PCC controller should fix the offer if it were the subse= quent offer for one session and was used=C2=A0as the initial offer for anot= her. Christer came up with the text for RFC8843bis to specify this.
_____________
Roman Shpount


On Th= u, Nov 4, 2021 at 11:33 PM Cullen Jennings <fluffy@iii.ca> wrote:

= Could we have a quick call on this next week during one of the breaks. I ha= ve tried to follow this whole thread and some it does not make much sense t= o me. I=E2=80=99m a bit lost on what the varios proposed resolutions are.= =C2=A0


On Nov 3, 2021, at 1= 2:38 PM, Christer Holmberg <christer.holmberg=3D40ericsson.c= om@dmarc.ietf.org> wrote:

Justin, are you ok with the suggested text? I would proba= bly be a good idea to refer it in 8829bis.

= Regards,

Christer
From:=C2=A0rtcweb <rtcweb-bounces@ietf.org> on behalf of Christer Holmberg <<= a href=3D"mailto:christer.holmberg=3D40ericsson.com@dmarc.ietf.org" style= =3D"color:blue;text-decoration:underline" target=3D"_blank">christer.holmbe= rg=3D40ericsson.com@dmarc.ietf.org>
Sent:=C2=A0Tuesday, November 2, 2021 11:13 PM
To:=C2=A0Roman = Shpount <roman@telurix.com>
Cc:<= /b>=C2=A0Justin Uberti <justin@= uberti.name>; RTCWeb IETF <rtcweb@ietf.o= rg>
Subject:=C2=A0Re: [rtcweb] Working Group = Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt
=C2=A0
=
Hi,
=C2=A0<= /p>
>This makes it much better.=C2=A0<= /span>I think it is missing a couple of commas ("In some 3PCC s= cenarios," and "In the rewritten offer,") but works for me.<= /div>

= =C2=A0

I can add them when I add the text to the draft= , but I think the RFC editor will most likely notice such thing.

=C2=A0

= >I have changed the section name so it is clear that it applies to JSEP = as well, not just SIP.

=C2=A0

Sure, that=E2=80=99s fine.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Tue, Nov 2, 2021 at 1:24 PM Ch= rister Holmberg <christer.holmbe= rg@ericsson.com> wrote:
<= div style=3D"margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Hi,

=C2=A0

Eventhough I w= ould not like to make more changes than necessary, I am fine with "3PC= C Considerations".

= =C2=A0

However, your sugge= sted text is very difficult to understand in some places, so let me give it= a try.

=C2=A0

<= /div>
(The first paragraph is generic, the = second SIP specific, and the third BUNDLE specific.)

=C2=A0

---

=C2=A0<= /p>

3PCC Considerations

=C2=A0

In some 3PCC scenarios a new session will= be established between an endpoint that is currently part of an ongoing se= ssion and an endpoint that is currently not part of an ongoing session. The= endpoint that is part of a session will generate a subsequent offer that w= ill be forwarded to the other endpoint by a 3PCC controller. The endpoint t= hat is not part of a session will process the offer as an initial offer.=C2= =A0

=C2=A0

The Session Initiation Pro= tocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE = request without an SDP body (sometimes referred to as an empty re-INVITE). = In such cases, the User Agent Server (UAS) will include an SDP offer in the= associated 200 OK response. If the UAS is a part of an ongoing session, it= will include a subsequent offer in the 200 OK response. The offer will be = received by a 3PCC controller (UAC) and then forwarded to another User Agen= t (UA). If the UA is not part of an ongoing session, it will process the of= fer as an initial offer.

When the BUNDLE mechanism is used, an initi= al BUNDLE offer is constructed using different rules than subsequent BUNDLE= offers, and it cannot be assumed that a UA is able to correctly process a = subsequent offer as an initial offer. Therefore, the 3PCC controller SHOULD= rewrite the subsequent offer into a valid initial offer, following the pro= cedures in (Section 7.2), before it forwards the offer to a UA. In the rewr= itten offer the 3PCC controller will set the port value to zero (and includ= e an SDP 'bundle-only' attribute) for each "m=3D" section= within the BUNDLE group, excluding the offerer-tagged "m=3D" sec= tion.

=C2=A0

=C2=A0

=C2=A0

=C2=A0=

=C2=A0

=C2=A0

=
From:=C2=A0Roman Shpount <roman@telurix.com>
Sent:=C2=A0Tuesday, Novem= ber 2, 2021 6:33 PM
To:=C2=A0Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" style=3D"color:blue;text-d= ecoration:underline" target=3D"_blank">christer.holmberg@ericsson.com&g= t;
Cc:=C2=A0Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti <= ;justin@uberti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject:=C2= =A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8= 829bis-01.txt

=C2=A0

How about we replace= the SIP Considerations with:=C2=A0

=C2=A0

=
3PC= C Considerations

=C2=A0

In some 3PCC scenarios, an of= fer generated during an ongoing session, i.e., a subsequent offer, will be = used by a 3PCC controller to establish a new session and forwarded as an in= itial offer to another endpoint that is currently not part of a session.
For example, the Session Initiation Protocol (SIP) [RFC3261] allows a = User Agent Client (UAC) to send a re-INVITE request without an SDP body (so= metimes referred to as an empty re-INVITE). In such cases, the User Agent S= erver (UAS) will include an SDP offer in the associated 200 OK response. If= UAS is a part of an ongoing session, it will include a subsequent offer in= the 200 OK response. The offer will be received by a 3PCC controller (UAC)= and then forwarded to another User Agent (UA) as an initial offer.

= When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Ther= efore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid= initial offer before it is used to establish a new session. To make the su= bsequent offer a valid initial offer, 3PCC will need to modify all the non-= tagged m=3D lines to include the bundle-only attribute and set the m=3D lin= e port to zero.
_____________
Roman Shpoun= t

=C2=A0

=C2=A0

On Tue, Nov 2, 2021 at 6:00= AM Christer Holmberg <christer.= holmberg@ericsson.com> wrote:
=
Hi,

=C2=A0

What about something like this:=

= =C2=A0

---

=C2=A0

OLD:

=C2=A0

=E2=80=9CThe Session Init= iation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a = re-INVITE request without an SDP body (sometimes referred to as an empty re= -INVITE).
In such cases, the User Agent Server (UAS) will include an = SDP Offer in the associated 200 OK response. This is typically used for 3rd= Party Call Control (3PCC) scenarios.
From a BUNDLE perspective, such= SDP Offer SHOULD be generated using the procedures defined in Section 7.2.= =E2=80=9D

=C2=A0

NEW:

=C2=A0

=E2=80=9CThe Session Initiatio= n Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-IN= VITE request without an SDP body (sometimes referred to as an empty re-INVI= TE).
In such cases, the User Agent Server (UAS) will include an SDP o= ffer in the associated 200 OK response. This is typically used for 3rd Part= y Call Control (3PCC) scenarios.

=C2=A0

In some 3PCC scenarios the = UAS will be part of an ongoing session, and will therefore include a subseq= uent offer in the 200 OK responses. The offer will be
received by a 3= PCC controller (UAC) and then forwarded as an initial offer to another User= Agent (UA) that is currently not part of a session.

=C2=A0

When = the BUNDLE mechanism is used, as an initial BUNDLE offer look different tha= n a subsequent BUNDLE offer, it cannot be assumed that a UA that expects an= initial offer
= will be able to properly process a subsequent offer. T= herefore, the 3PCC controller needs to act as a Back-To-Back User Agent (B2= BUA), and when it receives the subsequent
offer it needs to rewrite i= t into an initial offer before it is forwarded to such UA.=E2=80=9D<= /div>

=C2= =A0

----

=C2=A0

Regards,

=C2=A0

Christer
=C2=A0

= =C2=A0

=C2=A0

<= span lang=3D"EN-US">=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From:=C2=A0Roman Shpount <roman@telu= rix.com>=C2=A0
Sent:=C2=A0tiista= i 2. marraskuuta 2021 10.41
To:=C2=A0Justin Uberti &= lt;juberti@alphaexplorationco.com>
Cc:=C2=A0Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ub= erti <justin@uberti.name>; RTCWeb IET= F <rtcweb@ietf.org>
Subject:=C2=A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcw= eb-rfc8829bis-01.txt

=C2=A0

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <juberti@alphaexplorationco.com> wrote:
=
The PROBLEM is th= at we have two endpoints, where one sends a subsequent offer, and the other= one expects an initial offer. What do you normally do when you have that k= ind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be = the 3PCC controller.

=C2=A0

So, my suggestion would be to remove the SHOULD text from 8843bis, and si= mply add a note somewhere (in 8843bis and/or 8829bis) which describes the i= ssue and says that the 3GPP controller needs to modify the offer accordingl= y.

=C2=A0

=
Roman, thoughts on this? If the 3PCC is going to rewri= te the offer SDP anyway then maybe adding a=3Dbundle-only isn't the end= of the world.

=C2=A0

I am not opposed to=C2=A0this idea. 3PCC typically kno= ws that the subsequent offer is going to be used as initial, and should be = able to rewrite the offer to make it valid. We can change=C2=A0SIP Consider= ations section in 8843bis (https://www.ietf.org/archive/= id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration), remove= the SHOULD, and specify that 3PCC controller should fix the offer. We can = then reference this note from 8829bis or restate the same guidance.
_____________
Roman = Shpount

=C2=A0

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

--0000000000006f6f1505d002941d-- From nobody Thu Nov 4 21:15:06 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC23A0C26 for ; Thu, 4 Nov 2021 21:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 vAv7jiV_88Mw for ; Thu, 4 Nov 2021 21:14:58 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130043.outbound.protection.outlook.com [40.107.13.43]) (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 9C9A93A077C for ; Thu, 4 Nov 2021 21:14:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eJJcnDt265yaVS3pdL6Ar5e2i/ZzfE2gPAFnOeBbe489Bn8zqchOHsk7sInaccawivEjb0YyqBg7nZhPWKId8sUjLFs8aOqna100NpAqDo997uNW9mLKXkSc+iAc0k4yhYkvnSpfnIaEcxCPaFind5RrBiM2Z9CITetzbk0/GeUVUeg0G/W3oCvuKSUFDaph1tIBYUoFv9qlramHd0hhEBMwe0XbpbUdpHskPlqLYzGZ6EjSpqA6TNmUMURTQyNsP8QVTyaumLtlYfnrOyU4Tx6Y0sZhGSyBTbxFhB91sh8P22RJVhrl4GQ2krhibdu+Rq0Xdv441ccfyeaTN0v2dw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=P0YEjfAC1DK4+9zZ5hUOn8DBDbRB1YEtWvXBvbIXW9E=; b=M9rWmeHCFI6UMa/5g1qyc9iFZOH04vKxoHUtLk9ytyf7IOdjnAzyipRDLP2gVutjLfup3VdDEeIIRL7V63tAc/AxT7UHFpF7BZgBnDDmDtoZ3snIybrkETqeQEQGmE64zISgxg8dlyCsogYhXevz3gpUyu/4UV7JxEDTlvDpdI/zVDfDbN3Nxgei9dBHfLO0PyrLBJZlrQQxt5t8TXhg9uRykTc8xcAnycPuzHGdVzidey4erkHbJAB0eCIAII0np6snIimDI7EQVl/LfoTjlFXK4+rgwUCpT7s3+SZsL5mrR/TIov1Z4/4mua2h081Xf+/eZQx2q8brikSjDKQaMg== 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=P0YEjfAC1DK4+9zZ5hUOn8DBDbRB1YEtWvXBvbIXW9E=; b=PMjsDmoP0FsQmlsGYp5L5b12Qvy1IgRk5ZgBA2Ydc5DClg5RGPOp+dzfBDua50bC7RCEelyY82W6fHK5yLyk+cFP53GlUsufvV/3vjLux/goH3QF2D75ITvF8Gb+8bM4sKL/fPvOfkjdYCqqJn/DqzyTp/4vSm/6IZwy3bDuo4k= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR07MB4330.eurprd07.prod.outlook.com (2603:10a6:7:a0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10; Fri, 5 Nov 2021 04:14:49 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.011; Fri, 5 Nov 2021 04:14:49 +0000 From: Christer Holmberg To: Cullen Jennings , Roman Shpount , Justin Uberti CC: RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B32AAGQiAIAA528AgAASO+CAAHHigIAABbShgAAQjQCAADc8UIABZ1UwgAIoRACAAAqQUA== Date: Fri, 5 Nov 2021 04:14:49 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 39a77ea9-e432-408d-4707-08d9a012cf17 x-ms-traffictypediagnostic: HE1PR07MB4330: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n/QHsdrqVCIXc0cFv74uEemzdx3t+mxoAybTEZ5pSix5nMrw2uRt36C9VYEi7/4vwtprFOJfSU9Ybu4b0HyjpUsl+DxBp+7i6b6b5RX7GsVgeQvr81w4ahIzp2ASmkZ4nidSi0+CtP+Jr+jTY7Cd/xtu6XH2hRkEoWNwLSXOkGGBpUhEP1pmF1hVWlCTT3K9rRPFuAKrOhjUi9iR+QBhpQwxTSEfdYTPvsgmgdwTCb/qU08KeNdTrAO+SP/egZYdJLvuf6YYj/b2bZZsWkPB18Uj2VnQiWXUVCsuxnOfA4SxiFqTCPvFB2IlV113wGmYWOW8Dp0sRm1M4lIk65rtuXTTOOMb5e/eROw15OT8+TY3u1nzz+LiOfmc6tc0pzGKrxpfWpb4yCj17tbrF98ukIDrriQ1/6OsToD0iGrq/pz4fGTErJCwk/RBVdiZr2aRqDzmmv6AY57nmXuGviEm9W0mswmG4fDHUbjSpBeh8xQP5RPYbxCqJ7zumOLc3Hqqgm9KN2VSEgIOX2VEEEhkusAxIe2p94QbAkOkw9gTYMd+06CzvlIWEuJ3mBbZxaOlNqDqowF9xeOVSSdTYDm700uqKFl6Uo1WB8OfNiTGq7bVSHvUHXvklO/mr39bhFTuS+q83fDRtdes7po4DkNdhlLmv4UBCackflItCcg1u5O7i7N8WsMkxJmkUWfYzi879VvQSsxXmDPnbhxD4x7XyypxF5WdS/27s0GnicfbZzt+5BcmjRYl8ffw9F6vkZMejCyJEN5HTRIJnno/u1uOkaujhtRCIBTxaZsgPW/SFw4JFo4oPqZPcH4sTj+8U3maZOjokQk4r+lSj2Me8jEhRg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(5660300002)(86362001)(508600001)(966005)(44832011)(82960400001)(6506007)(53546011)(52536014)(7696005)(26005)(38100700002)(122000001)(8936002)(186003)(33656002)(83380400001)(71200400001)(38070700005)(4326008)(110136005)(9686003)(2906002)(316002)(66946007)(55016002)(66446008)(166002)(66556008)(66476007)(76116006)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bUw1UHE5bkd4V3ZyU3hzdDhuWVVqTVMxR0lzaDh6bURvb2tjTFBhWmNqRVZy?= =?utf-8?B?N1BqeDBWanZpakRtQVFVak5YTFh1WldBbXhtS1dkeDI0VDAxSWRUaEM4UzVH?= =?utf-8?B?S2FkZG5rdXpaRlliK2w2bU5hOEt2SFJDZDA0N0dtbE5jcVUrRlFHcGl0UytM?= =?utf-8?B?TC9iV3A3R2YyNHNzakhtU0VhRDhFak5NYlUwT3RMTCtoQkQ0aG81Tks0cEZC?= =?utf-8?B?Nk1BWkNDcHNjYkZwcmtrWFRhUTFRckRLVmpwejZHV3M2WDB3M3ROTDNKRlkz?= =?utf-8?B?Mkh2NXhMS0U5UGN0MW9GTUhpRkc1YzVobFFRd1pabVBrU3p5dXBXbVZJaDhn?= =?utf-8?B?aldrKzBETlVYRFZoK2U2QmxEVFlZejZPbHQ3b3dIKzZnT0NXMXI2bTBoZjNa?= =?utf-8?B?eGU5VVhzMUNoRGFvcFZlV1FOa2hMRnh4SEpUajhhU1VVaFMxOHZMMXg0VHRy?= =?utf-8?B?dFJ1TTJZV0ZZbTFkTno4ajlxWllPc3ZCQlJML2kxWklEcXAwNkcyKzg5cGZG?= =?utf-8?B?MXR6M0w0UFRjZ1R0T3Y2ZlQwMlVzUW1iMXlQVXBnZEZCcWl2bWVGTUNBcVU2?= =?utf-8?B?YzhPOTlXak54WnZ5UTlTN21Ma3RkR1REenY0bThQNHBvZ2lRUDQ2RHJONzFq?= =?utf-8?B?NEVaWmw0b093a2NuUUo4amRwN3hGR0dBQitzT1B3RW9SMkJjNlM1dG9ycnMw?= =?utf-8?B?MEthZ2NJTDZBK0EvYndvN21uVWZZYnNScllaaEE0WkxDaENPbnZiK1d6VFJX?= =?utf-8?B?SzNyMlJZQ0YyUDQxZmF3cXNka1Noem01ZFJQN294elhnOU42c2YzNVFQMUlM?= =?utf-8?B?MXVKTVBWc2Z0dXk1eUdZNmxKc3dNT1ZHZDAvbjBRVFJqNFplZmlEQzAwdTVO?= =?utf-8?B?U2VKWFVhZFJkTlprbi9ZbGhDQ1dhc1A3cUlpaEdTVUZVL3htUTRJak8ydTdy?= =?utf-8?B?ZDcvbVk1ZmxDaENYY3FuSHFuOWRuVHMraS9EZmNCc1Rlb2JoZHZ0cWxVam52?= =?utf-8?B?R1NXbmhPSDc0TlhpK3RuZE1wWmZnUmRUSjBCNEs4eWVXUlpCazRESmtqanI2?= =?utf-8?B?UXFsY0swV295TEJLTFJqZm9zdDZaTm9DQVZXclMxTHZpZytkTnYzT1JnVzkx?= =?utf-8?B?dWg2MlArWUk3dGtqNk14QUtLWmlRK1A0bmJLS0ZaU0tEYTVwazdQUVh4QUh5?= =?utf-8?B?ZUs3aEVJdHR0TmlKT3drcmtyTHJXM1RYVFl0YXpPWUp0NUtGVndHblEvQ3F2?= =?utf-8?B?ZkJIbGNqbFRxbXRMekxsQWN5SWpzcWRoS0ZuS0ZyTTlSZmt2L0J5Q2Z2Q1gy?= =?utf-8?B?VzdpS1VpV2dCa3ZnVHJCRWU5cFVCNVNrUkhnWHZMaTYrSGorM0lFbFEwYkxq?= =?utf-8?B?c1dFT0ZVMHJYSWVWRkpPWjJDcHAyRU1HaVh0bnZZR2VtL2pBaTNSRE52c1VM?= =?utf-8?B?WC9xTXpwc3JmUGVaU2VJUzBDV3dGc1IvVTIrTU1rekVUL1ZVSDI2OUxVUFlO?= =?utf-8?B?djl0bGRuYkQ4by9GVW16R09OVEl0b3doUDk2Wk1YanVyQnNMSkRJTFE2T2Vj?= =?utf-8?B?SitsSDJwaHBCVDNGeWdBejluaVRRMnQyNUJyemc5SzlMMVl2UVN4Y1lveEhD?= =?utf-8?B?TXFKa3NraUlTQ2VoUkxKNHpuczRRTEVkSEh6UzNpTkZ3T3ZnWlN3eHpodjFX?= =?utf-8?B?MXZBTUFxUDU4ODFTdmxKY2JLTU9OS1JJWUwrelRqTDZvQkdQQlhjQjNSR09t?= =?utf-8?B?Q3MyWGxBcDQwTGJTRkZLWDR5ZEhxRHdEbE5zSjJYLzl1c2RyVitzZi95bnlQ?= =?utf-8?B?QjUrS3pVSW9DZDZoUjMramdlb2FtMVFaUjB5aklZcnYzNnZZMXdEWHVEWSt6?= =?utf-8?B?aUIyUW4vdVQ3b0dYTDM2NkxtdWdrM2JBVUVDMmRNb1p3eDVwWjVxc2ExelZl?= =?utf-8?B?RmxyY2U4K1RHbHNPUW1RWFRLMXh1bWNLK2I1OWlGVUgxY3d2ZTBGdHBiME9M?= =?utf-8?B?YjlGQmJHZGFIQUxWVHRaVElxQUN5R3NxOHB4b0g0OXNveVFNNEp5cTJxNXVn?= =?utf-8?B?SW9wcVM4dEIwU2ovT2txcmJpenVaSHlSQkN5cEhkTUZJeEtXVFV3VWkwK2pp?= =?utf-8?B?eGNjZXRmVjh2YXNGS0ZHRmtTNUtxa0V5TDBjd20xWDdGTEtZTWxZcWpHQTA4?= =?utf-8?B?cGdaenBmWVpNd1FrNW5XV0hRemNnK2pHMDBFQ0tUUVRzQTFjT055UEhIbTNO?= =?utf-8?B?eTV2cHRXbjlIcEluSHhaa2RueVZBPT0=?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB44419BD2DA5EEABD990305D1938E9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39a77ea9-e432-408d-4707-08d9a012cf17 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2021 04:14:49.2481 (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: MnaFT30oVVm8K0/VaeuTm+t82w0a6fK0k1ChTLZ1Nlcb6IAvpkz2iriOJrJ/0S6SG5tX09oFRC/TtSCd5XE509ynLLyNkfvFSyKOHdNFC2c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4330 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 04:15:04 -0000 --_000_HE1PR07MB44419BD2DA5EEABD990305D1938E9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBxdWVzdGlvbiB3YXMgd2hldGhlciBhbiBlbmRwb2ludCB3b3VsZCBiZSBhc3N1 bWVkIHRvIGJlIGFibGUgdG8gYWNjZXB0IGEgc3Vic2VxdWVudCBvZmZlciAoc2FtZSBhZGRyZXNz OnBvcnQgaW4gZWFjaCBtLSBsaW5lKSBhcyBhbiBpbml0aWFsIG9mZmVyLiBJIGRpZCBub3QgYWdy ZWUgdG8gdGhhdC4NCg0KSG93ZXZlciwgdGhlIHN1Z2dlc3Rpb24gYSBjb3VwbGUgb2YgZGF5cyBh Z28sIHdoaWNoIHBlb3BsZSBzZWVtZWQgdG8gYWdyZWUgdG8sIGRvZXMgTk9UIG1ha2UgdGhhdCBh c3N1bXB0aW9uIGFueW1vcmUuIE5vdGhpbmcgb3V0IG9mIHRoZSBub3JtYWwgd291bGQgYmUgYXNz dW1lZCBieSBlbmRwb2ludHMsIGFuZCBpbnN0ZWFkIHRoZSAzR1BQIGNvbnRyb2xsZXIgd2lsbCBh Y3QgYXMgYSBCMkJVQSBhbmQgbW9kaWZ5IHRoZSBTRFAgaWYgbmVlZGVkLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpGcm9tOiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E+DQpTZW50 OiBwZXJqYW50YWkgNS4gbWFycmFza3V1dGEgMjAyMSA1LjM0DQpUbzogQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IFJvbWFuIFNocG91bnQgPHJvbWFu QHRlbHVyaXguY29tPjsgSnVzdGluIFViZXJ0aSA8anVzdGluQHViZXJ0aS5uYW1lPg0KQ2M6IFJU Q1dlYiBJRVRGIDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV29ya2lu ZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LXViZXJ0aS1ydGN3ZWItcmZjODgyOWJpcy0wMS50 eHQNCg0KDQpDb3VsZCB3ZSBoYXZlIGEgcXVpY2sgY2FsbCBvbiB0aGlzIG5leHQgd2VlayBkdXJp bmcgb25lIG9mIHRoZSBicmVha3MuIEkgaGF2ZSB0cmllZCB0byBmb2xsb3cgdGhpcyB3aG9sZSB0 aHJlYWQgYW5kIHNvbWUgaXQgZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlIHRvIG1lLiBJ4oCZbSBh IGJpdCBsb3N0IG9uIHdoYXQgdGhlIHZhcmlvcyBwcm9wb3NlZCByZXNvbHV0aW9ucyBhcmUuDQoN Cg0KDQpPbiBOb3YgMywgMjAyMSwgYXQgMTI6MzggUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZz00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmc9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KSnVz dGluLCBhcmUgeW91IG9rIHdpdGggdGhlIHN1Z2dlc3RlZCB0ZXh0PyBJIHdvdWxkIHByb2JhYmx5 IGJlIGEgZ29vZCBpZGVhIHRvIHJlZmVyIGl0IGluIDg4MjliaXMuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcnRjd2ViIDxy dGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+PiBv biBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnPTQwZXJpY3Nz b24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZz00MGVyaWNzc29u LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyLCAyMDIxIDEx OjEzIFBNDQpUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFu QHRlbHVyaXguY29tPj4NCkNjOiBKdXN0aW4gVWJlcnRpIDxqdXN0aW5AdWJlcnRpLm5hbWU8bWFp bHRvOmp1c3RpbkB1YmVydGkubmFtZT4+OyBSVENXZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPG1h aWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsIGZvciBkcmFmdC11YmVydGktcnRjd2ViLXJmYzg4MjliaXMtMDEudHh0DQoN CkhpLA0KDQoNCj5UaGlzIG1ha2VzIGl0IG11Y2ggYmV0dGVyLiBJIHRoaW5rIGl0IGlzIG1pc3Np bmcgYSBjb3VwbGUgb2YgY29tbWFzICgiSW4gc29tZSAzUENDIHNjZW5hcmlvcywiIGFuZCAiSW4g dGhlIHJld3JpdHRlbiBvZmZlciwiKSBidXQgd29ya3MgZm9yIG1lLg0KDQoNCkkgY2FuIGFkZCB0 aGVtIHdoZW4gSSBhZGQgdGhlIHRleHQgdG8gdGhlIGRyYWZ0LCBidXQgSSB0aGluayB0aGUgUkZD IGVkaXRvciB3aWxsIG1vc3QgbGlrZWx5IG5vdGljZSBzdWNoIHRoaW5nLg0KDQoNCj5JIGhhdmUg Y2hhbmdlZCB0aGUgc2VjdGlvbiBuYW1lIHNvIGl0IGlzIGNsZWFyIHRoYXQgaXQgYXBwbGllcyB0 byBKU0VQIGFzIHdlbGwsIG5vdCBqdXN0IFNJUC4NCg0KDQpTdXJlLCB0aGF04oCZcyBmaW5lLg0K DQoNClJlZ2FyZHMsDQoNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCk9uIFR1ZSwgTm92IDIsIDIw MjEgYXQgMToyNCBQTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhp LA0KDQoNCkV2ZW50aG91Z2ggSSB3b3VsZCBub3QgbGlrZSB0byBtYWtlIG1vcmUgY2hhbmdlcyB0 aGFuIG5lY2Vzc2FyeSwgSSBhbSBmaW5lIHdpdGggIjNQQ0MgQ29uc2lkZXJhdGlvbnMiLg0KDQoN Ckhvd2V2ZXIsIHlvdXIgc3VnZ2VzdGVkIHRleHQgaXMgdmVyeSBkaWZmaWN1bHQgdG8gdW5kZXJz dGFuZCBpbiBzb21lIHBsYWNlcywgc28gbGV0IG1lIGdpdmUgaXQgYSB0cnkuDQoNCg0KKFRoZSBm aXJzdCBwYXJhZ3JhcGggaXMgZ2VuZXJpYywgdGhlIHNlY29uZCBTSVAgc3BlY2lmaWMsIGFuZCB0 aGUgdGhpcmQgQlVORExFIHNwZWNpZmljLikNCg0KDQotLS0NCg0KDQozUENDIENvbnNpZGVyYXRp b25zDQoNCg0KSW4gc29tZSAzUENDIHNjZW5hcmlvcyBhIG5ldyBzZXNzaW9uIHdpbGwgYmUgZXN0 YWJsaXNoZWQgYmV0d2VlbiBhbiBlbmRwb2ludCB0aGF0IGlzIGN1cnJlbnRseSBwYXJ0IG9mIGFu IG9uZ29pbmcgc2Vzc2lvbiBhbmQgYW4gZW5kcG9pbnQgdGhhdCBpcyBjdXJyZW50bHkgbm90IHBh cnQgb2YgYW4gb25nb2luZyBzZXNzaW9uLiBUaGUgZW5kcG9pbnQgdGhhdCBpcyBwYXJ0IG9mIGEg c2Vzc2lvbiB3aWxsIGdlbmVyYXRlIGEgc3Vic2VxdWVudCBvZmZlciB0aGF0IHdpbGwgYmUgZm9y d2FyZGVkIHRvIHRoZSBvdGhlciBlbmRwb2ludCBieSBhIDNQQ0MgY29udHJvbGxlci4gVGhlIGVu ZHBvaW50IHRoYXQgaXMgbm90IHBhcnQgb2YgYSBzZXNzaW9uIHdpbGwgcHJvY2VzcyB0aGUgb2Zm ZXIgYXMgYW4gaW5pdGlhbCBvZmZlci4NCg0KDQpUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3Rv Y29sIChTSVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2VyIEFnZW50IENsaWVudCAoVUFDKSB0byBz ZW5kIGEgcmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBhbiBTRFAgYm9keSAoc29tZXRpbWVzIHJl ZmVycmVkIHRvIGFzIGFuIGVtcHR5IHJlLUlOVklURSkuIEluIHN1Y2ggY2FzZXMsIHRoZSBVc2Vy IEFnZW50IFNlcnZlciAoVUFTKSB3aWxsIGluY2x1ZGUgYW4gU0RQIG9mZmVyIGluIHRoZSBhc3Nv Y2lhdGVkIDIwMCBPSyByZXNwb25zZS4gSWYgdGhlIFVBUyBpcyBhIHBhcnQgb2YgYW4gb25nb2lu ZyBzZXNzaW9uLCBpdCB3aWxsIGluY2x1ZGUgYSBzdWJzZXF1ZW50IG9mZmVyIGluIHRoZSAyMDAg T0sgcmVzcG9uc2UuIFRoZSBvZmZlciB3aWxsIGJlIHJlY2VpdmVkIGJ5IGEgM1BDQyBjb250cm9s bGVyIChVQUMpIGFuZCB0aGVuIGZvcndhcmRlZCB0byBhbm90aGVyIFVzZXIgQWdlbnQgKFVBKS4g SWYgdGhlIFVBIGlzIG5vdCBwYXJ0IG9mIGFuIG9uZ29pbmcgc2Vzc2lvbiwgaXQgd2lsbCBwcm9j ZXNzIHRoZSBvZmZlciBhcyBhbiBpbml0aWFsIG9mZmVyLg0KDQpXaGVuIHRoZSBCVU5ETEUgbWVj aGFuaXNtIGlzIHVzZWQsIGFuIGluaXRpYWwgQlVORExFIG9mZmVyIGlzIGNvbnN0cnVjdGVkIHVz aW5nIGRpZmZlcmVudCBydWxlcyB0aGFuIHN1YnNlcXVlbnQgQlVORExFIG9mZmVycywgYW5kIGl0 IGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQgYSBVQSBpcyBhYmxlIHRvIGNvcnJlY3RseSBwcm9jZXNz IGEgc3Vic2VxdWVudCBvZmZlciBhcyBhbiBpbml0aWFsIG9mZmVyLiBUaGVyZWZvcmUsIHRoZSAz UENDIGNvbnRyb2xsZXIgU0hPVUxEIHJld3JpdGUgdGhlIHN1YnNlcXVlbnQgb2ZmZXIgaW50byBh IHZhbGlkIGluaXRpYWwgb2ZmZXIsIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbiAoU2VjdGlv biA3LjIpLCBiZWZvcmUgaXQgZm9yd2FyZHMgdGhlIG9mZmVyIHRvIGEgVUEuIEluIHRoZSByZXdy aXR0ZW4gb2ZmZXIgdGhlIDNQQ0MgY29udHJvbGxlciB3aWxsIHNldCB0aGUgcG9ydCB2YWx1ZSB0 byB6ZXJvIChhbmQgaW5jbHVkZSBhbiBTRFAgJ2J1bmRsZS1vbmx5JyBhdHRyaWJ1dGUpIGZvciBl YWNoICJtPSIgc2VjdGlvbiB3aXRoaW4gdGhlIEJVTkRMRSBncm91cCwgZXhjbHVkaW5nIHRoZSBv ZmZlcmVyLXRhZ2dlZCAibT0iIHNlY3Rpb24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBSb21hbiBTaHBvdW50IDxyb21h bkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KU2VudDogVHVlc2RheSwg Tm92ZW1iZXIgMiwgMjAyMSA2OjMzIFBNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPj4NCkNjOiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb208 bWFpbHRvOmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbT4+OyBKdXN0aW4gVWJlcnRpIDxq dXN0aW5AdWJlcnRpLm5hbWU8bWFpbHRvOmp1c3RpbkB1YmVydGkubmFtZT4+OyBSVENXZWIgSUVU RiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFtydGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC11YmVydGktcnRjd2Vi LXJmYzg4MjliaXMtMDEudHh0DQoNCg0KSG93IGFib3V0IHdlIHJlcGxhY2UgdGhlIFNJUCBDb25z aWRlcmF0aW9ucyB3aXRoOg0KDQoNCjNQQ0MgQ29uc2lkZXJhdGlvbnMNCg0KDQpJbiBzb21lIDNQ Q0Mgc2NlbmFyaW9zLCBhbiBvZmZlciBnZW5lcmF0ZWQgZHVyaW5nIGFuIG9uZ29pbmcgc2Vzc2lv biwgaS5lLiwgYSBzdWJzZXF1ZW50IG9mZmVyLCB3aWxsIGJlIHVzZWQgYnkgYSAzUENDIGNvbnRy b2xsZXIgdG8gZXN0YWJsaXNoIGEgbmV3IHNlc3Npb24gYW5kIGZvcndhcmRlZCBhcyBhbiBpbml0 aWFsIG9mZmVyIHRvIGFub3RoZXIgZW5kcG9pbnQgdGhhdCBpcyBjdXJyZW50bHkgbm90IHBhcnQg b2YgYSBzZXNzaW9uLg0KDQpGb3IgZXhhbXBsZSwgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90 b2NvbCAoU0lQKSBbUkZDMzI2MV0gYWxsb3dzIGEgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgdG8g c2VuZCBhIHJlLUlOVklURSByZXF1ZXN0IHdpdGhvdXQgYW4gU0RQIGJvZHkgKHNvbWV0aW1lcyBy ZWZlcnJlZCB0byBhcyBhbiBlbXB0eSByZS1JTlZJVEUpLiBJbiBzdWNoIGNhc2VzLCB0aGUgVXNl ciBBZ2VudCBTZXJ2ZXIgKFVBUykgd2lsbCBpbmNsdWRlIGFuIFNEUCBvZmZlciBpbiB0aGUgYXNz b2NpYXRlZCAyMDAgT0sgcmVzcG9uc2UuIElmIFVBUyBpcyBhIHBhcnQgb2YgYW4gb25nb2luZyBz ZXNzaW9uLCBpdCB3aWxsIGluY2x1ZGUgYSBzdWJzZXF1ZW50IG9mZmVyIGluIHRoZSAyMDAgT0sg cmVzcG9uc2UuIFRoZSBvZmZlciB3aWxsIGJlIHJlY2VpdmVkIGJ5IGEgM1BDQyBjb250cm9sbGVy IChVQUMpIGFuZCB0aGVuIGZvcndhcmRlZCB0byBhbm90aGVyIFVzZXIgQWdlbnQgKFVBKSBhcyBh biBpbml0aWFsIG9mZmVyLg0KDQpXaGVuIHRoZSBCVU5ETEUgbWVjaGFuaXNtIGlzIHVzZWQsIGFu IGluaXRpYWwgQlVORExFIG9mZmVyIGlzIGNvbnN0cnVjdGVkIHVzaW5nIGRpZmZlcmVudCBydWxl cyB0aGFuIHN1YnNlcXVlbnQgQlVORExFIG9mZmVycy4gSXQgY2Fubm90IGJlIGFzc3VtZWQgdGhh dCBhIHN1YnNlcXVlbnQgb2ZmZXIgaXMgYSB2YWxpZCBpbml0aWFsIG9mZmVyIGFuZCB0aGF0IHRo ZSBlbmRwb2ludCB0aGF0IGV4cGVjdHMgYW4gaW5pdGlhbCBvZmZlciB3aWxsIHByb3Blcmx5IHBy b2Nlc3Mgc3VjaCBhIHN1YnNlcXVlbnQgb2ZmZXIuIFRoZXJlZm9yZSwgdGhlIDNQQ0MgY29udHJv bGxlciBTSE9VTEQgcmV3cml0ZSB0aGUgc3Vic2VxdWVudCBvZmZlciBpbnRvIGEgdmFsaWQgaW5p dGlhbCBvZmZlciBiZWZvcmUgaXQgaXMgdXNlZCB0byBlc3RhYmxpc2ggYSBuZXcgc2Vzc2lvbi4g VG8gbWFrZSB0aGUgc3Vic2VxdWVudCBvZmZlciBhIHZhbGlkIGluaXRpYWwgb2ZmZXIsIDNQQ0Mg d2lsbCBuZWVkIHRvIG1vZGlmeSBhbGwgdGhlIG5vbi10YWdnZWQgbT0gbGluZXMgdG8gaW5jbHVk ZSB0aGUgYnVuZGxlLW9ubHkgYXR0cmlidXRlIGFuZCBzZXQgdGhlIG09IGxpbmUgcG9ydCB0byB6 ZXJvLg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQoNCg0KDQpPbiBUdWUsIE5vdiAy LCAyMDIxIGF0IDY6MDAgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQpIaSwNCg0KV2hhdCBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQotLS0NCg0KT0xEOg0K DQrigJxUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXSBhbGxv d3MgYSBVc2VyIEFnZW50IENsaWVudCAoVUFDKSB0byBzZW5kIGEgcmUtSU5WSVRFIHJlcXVlc3Qg d2l0aG91dCBhbiBTRFAgYm9keSAoc29tZXRpbWVzIHJlZmVycmVkIHRvIGFzIGFuIGVtcHR5IHJl LUlOVklURSkuDQpJbiBzdWNoIGNhc2VzLCB0aGUgVXNlciBBZ2VudCBTZXJ2ZXIgKFVBUykgd2ls bCBpbmNsdWRlIGFuIFNEUCBPZmZlciBpbiB0aGUgYXNzb2NpYXRlZCAyMDAgT0sgcmVzcG9uc2Uu IFRoaXMgaXMgdHlwaWNhbGx5IHVzZWQgZm9yIDNyZCBQYXJ0eSBDYWxsIENvbnRyb2wgKDNQQ0Mp IHNjZW5hcmlvcy4NCkZyb20gYSBCVU5ETEUgcGVyc3BlY3RpdmUsIHN1Y2ggU0RQIE9mZmVyIFNI T1VMRCBiZSBnZW5lcmF0ZWQgdXNpbmcgdGhlIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBTZWN0aW9u IDcuMi7igJ0NCg0KTkVXOg0KDQrigJxUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChT SVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2VyIEFnZW50IENsaWVudCAoVUFDKSB0byBzZW5kIGEg cmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBhbiBTRFAgYm9keSAoc29tZXRpbWVzIHJlZmVycmVk IHRvIGFzIGFuIGVtcHR5IHJlLUlOVklURSkuDQpJbiBzdWNoIGNhc2VzLCB0aGUgVXNlciBBZ2Vu dCBTZXJ2ZXIgKFVBUykgd2lsbCBpbmNsdWRlIGFuIFNEUCBvZmZlciBpbiB0aGUgYXNzb2NpYXRl ZCAyMDAgT0sgcmVzcG9uc2UuIFRoaXMgaXMgdHlwaWNhbGx5IHVzZWQgZm9yIDNyZCBQYXJ0eSBD YWxsIENvbnRyb2wgKDNQQ0MpIHNjZW5hcmlvcy4NCg0KSW4gc29tZSAzUENDIHNjZW5hcmlvcyB0 aGUgVUFTIHdpbGwgYmUgcGFydCBvZiBhbiBvbmdvaW5nIHNlc3Npb24sIGFuZCB3aWxsIHRoZXJl Zm9yZSBpbmNsdWRlIGEgc3Vic2VxdWVudCBvZmZlciBpbiB0aGUgMjAwIE9LIHJlc3BvbnNlcy4g VGhlIG9mZmVyIHdpbGwgYmUNCnJlY2VpdmVkIGJ5IGEgM1BDQyBjb250cm9sbGVyIChVQUMpIGFu ZCB0aGVuIGZvcndhcmRlZCBhcyBhbiBpbml0aWFsIG9mZmVyIHRvIGFub3RoZXIgVXNlciBBZ2Vu dCAoVUEpIHRoYXQgaXMgY3VycmVudGx5IG5vdCBwYXJ0IG9mIGEgc2Vzc2lvbi4NCg0KV2hlbiB0 aGUgQlVORExFIG1lY2hhbmlzbSBpcyB1c2VkLCBhcyBhbiBpbml0aWFsIEJVTkRMRSBvZmZlciBs b29rIGRpZmZlcmVudCB0aGFuIGEgc3Vic2VxdWVudCBCVU5ETEUgb2ZmZXIsIGl0IGNhbm5vdCBi ZSBhc3N1bWVkIHRoYXQgYSBVQSB0aGF0IGV4cGVjdHMgYW4gaW5pdGlhbCBvZmZlcg0Kd2lsbCBi ZSBhYmxlIHRvIHByb3Blcmx5IHByb2Nlc3MgYSBzdWJzZXF1ZW50IG9mZmVyLiBUaGVyZWZvcmUs IHRoZSAzUENDIGNvbnRyb2xsZXIgbmVlZHMgdG8gYWN0IGFzIGEgQmFjay1Uby1CYWNrIFVzZXIg QWdlbnQgKEIyQlVBKSwgYW5kIHdoZW4gaXQgcmVjZWl2ZXMgdGhlIHN1YnNlcXVlbnQNCm9mZmVy IGl0IG5lZWRzIHRvIHJld3JpdGUgaXQgaW50byBhbiBpbml0aWFsIG9mZmVyIGJlZm9yZSBpdCBp cyBmb3J3YXJkZWQgdG8gc3VjaCBVQS7igJ0NCg0KLS0tLQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KDQoNCg0KDQoNCkZyb206IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29t PG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+DQpTZW50OiB0aWlzdGFpIDIuIG1hcnJhc2t1dXRh IDIwMjEgMTAuNDENClRvOiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25j by5jb208bWFpbHRvOmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbT4+DQpDYzogQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IEp1c3RpbiBVYmVydGkgPGp1c3RpbkB1YmVydGku bmFtZTxtYWlsdG86anVzdGluQHViZXJ0aS5uYW1lPj47IFJUQ1dlYiBJRVRGIDxydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV29y a2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LXViZXJ0aS1ydGN3ZWItcmZjODgyOWJpcy0w MS50eHQNCg0KT24gTW9uLCBOb3YgMSwgMjAyMSBhdCAyOjUyIFBNIEp1c3RpbiBVYmVydGkgPGp1 YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbTxtYWlsdG86anViZXJ0aUBhbHBoYWV4cGxvcmF0 aW9uY28uY29tPj4gd3JvdGU6DQpUaGUgUFJPQkxFTSBpcyB0aGF0IHdlIGhhdmUgdHdvIGVuZHBv aW50cywgd2hlcmUgb25lIHNlbmRzIGEgc3Vic2VxdWVudCBvZmZlciwgYW5kIHRoZSBvdGhlciBv bmUgZXhwZWN0cyBhbiBpbml0aWFsIG9mZmVyLiBXaGF0IGRvIHlvdSBub3JtYWxseSBkbyB3aGVu IHlvdSBoYXZlIHRoYXQga2luZCBvZiBwcm9ibGVtPyBZb3UgdXNlIGFuIFNCQy9CMkJVQS4gSW4g dGhpcyBjYXNlIHRoYXQgU0JDL0IyQlVBIHdvdWxkIGJlIHRoZSAzUENDIGNvbnRyb2xsZXIuDQoN ClNvLCBteSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHJlbW92ZSB0aGUgU0hPVUxEIHRleHQgZnJv bSA4ODQzYmlzLCBhbmQgc2ltcGx5IGFkZCBhIG5vdGUgc29tZXdoZXJlIChpbiA4ODQzYmlzIGFu ZC9vciA4ODI5YmlzKSB3aGljaCBkZXNjcmliZXMgdGhlIGlzc3VlIGFuZCBzYXlzIHRoYXQgdGhl IDNHUFAgY29udHJvbGxlciBuZWVkcyB0byBtb2RpZnkgdGhlIG9mZmVyIGFjY29yZGluZ2x5Lg0K DQpSb21hbiwgdGhvdWdodHMgb24gdGhpcz8gSWYgdGhlIDNQQ0MgaXMgZ29pbmcgdG8gcmV3cml0 ZSB0aGUgb2ZmZXIgU0RQIGFueXdheSB0aGVuIG1heWJlIGFkZGluZyBhPWJ1bmRsZS1vbmx5IGlz bid0IHRoZSBlbmQgb2YgdGhlIHdvcmxkLg0KDQpJIGFtIG5vdCBvcHBvc2VkIHRvIHRoaXMgaWRl YS4gM1BDQyB0eXBpY2FsbHkga25vd3MgdGhhdCB0aGUgc3Vic2VxdWVudCBvZmZlciBpcyBnb2lu ZyB0byBiZSB1c2VkIGFzIGluaXRpYWwsIGFuZCBzaG91bGQgYmUgYWJsZSB0byByZXdyaXRlIHRo ZSBvZmZlciB0byBtYWtlIGl0IHZhbGlkLiBXZSBjYW4gY2hhbmdlIFNJUCBDb25zaWRlcmF0aW9u cyBzZWN0aW9uIGluIDg4NDNiaXMgKGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJh ZnQtaWV0Zi1tbXVzaWMtcmZjODg0M2Jpcy0wNS5odG1sI25hbWUtc2lwLWNvbnNpZGVyYXRpb24p LCByZW1vdmUgdGhlIFNIT1VMRCwgYW5kIHNwZWNpZnkgdGhhdCAzUENDIGNvbnRyb2xsZXIgc2hv dWxkIGZpeCB0aGUgb2ZmZXIuIFdlIGNhbiB0aGVuIHJlZmVyZW5jZSB0aGlzIG5vdGUgZnJvbSA4 ODI5YmlzIG9yIHJlc3RhdGUgdGhlIHNhbWUgZ3VpZGFuY2UuDQpfX19fX19fX19fX19fDQpSb21h biBTaHBvdW50DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoN Cg== --_000_HE1PR07MB44419BD2DA5EEABD990305D1938E9HE1PR07MB4441eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnAueG1zb25vcm1hbCwgbGkueG1zb25vcm1hbCwgZGl2Lnhtc29ub3JtYWwNCgl7bXNvLXN0eWxl LW5hbWU6eF9tc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHF1ZXN0 aW9uIHdhcyB3aGV0aGVyIGFuIGVuZHBvaW50IHdvdWxkIGJlIGFzc3VtZWQgdG8gYmUgYWJsZSB0 byBhY2NlcHQgYSBzdWJzZXF1ZW50IG9mZmVyIChzYW1lIGFkZHJlc3M6cG9ydCBpbiBlYWNoIG0t IGxpbmUpIGFzIGFuIGluaXRpYWwgb2ZmZXIuIEkgZGlkIG5vdCBhZ3JlZSB0byB0aGF0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhvd2V2ZXIsIHRoZSBzdWdnZXN0aW9uIGEgY291 cGxlIG9mIGRheXMgYWdvLCB3aGljaCBwZW9wbGUgc2VlbWVkIHRvIGFncmVlIHRvLCBkb2VzIE5P VCBtYWtlIHRoYXQgYXNzdW1wdGlvbiBhbnltb3JlLiBOb3RoaW5nIG91dCBvZiB0aGUgbm9ybWFs IHdvdWxkIGJlIGFzc3VtZWQgYnkgZW5kcG9pbnRzLCBhbmQgaW5zdGVhZA0KIHRoZSAzR1BQIGNv bnRyb2xsZXIgd2lsbCBhY3QgYXMgYSBCMkJVQSBhbmQgbW9kaWZ5IHRoZSBTRFAgaWYgbmVlZGVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEN1bGxlbiBKZW5uaW5ncyAm bHQ7Zmx1ZmZ5QGlpaS5jYSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBwZXJqYW50YWkgNS4gbWFy cmFza3V1dGEgMjAyMSA1LjM0PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OzsgUm9tYW4gU2hwb3VudCAmbHQ7cm9t YW5AdGVsdXJpeC5jb20mZ3Q7OyBKdXN0aW4gVWJlcnRpICZsdDtqdXN0aW5AdWJlcnRpLm5hbWUm Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBSVENXZWIgSUVURiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV29ya2luZyBHcm91cCBMYXN0IENhbGwg Zm9yIGRyYWZ0LXViZXJ0aS1ydGN3ZWItcmZjODgyOWJpcy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvdWxkIHdlIGhhdmUgYSBxdWljayBj YWxsIG9uIHRoaXMgbmV4dCB3ZWVrIGR1cmluZyBvbmUgb2YgdGhlIGJyZWFrcy4gSSBoYXZlIHRy aWVkIHRvIGZvbGxvdyB0aGlzIHdob2xlIHRocmVhZCBhbmQgc29tZSBpdCBkb2VzIG5vdCBtYWtl IG11Y2ggc2Vuc2UgdG8gbWUuIEnigJltIGEgYml0IGxvc3Qgb24gd2hhdCB0aGUgdmFyaW9zIHBy b3Bvc2VkIHJlc29sdXRpb25zIGFyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE5vdiAzLCAyMDIxLCBhdCAxMjozOCBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZz00MGVyaWNzc29uLmNvbUBk bWFyYy5pZXRmLm9yZyI+Y2hyaXN0ZXIuaG9sbWJlcmc9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5KdXN0aW4sIGFyZSB5b3Ug b2sgd2l0aCB0aGUgc3VnZ2VzdGVkIHRleHQ/IEkgd291bGQgcHJvYmFibHkgYmUgYSBnb29kIGlk ZWEgdG8gcmVmZXIgaXQgaW4gODgyOWJpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIi Pg0KPGhyIHNpemU9IjIiIHdpZHRoPSI4NDQiIHN0eWxlPSJ3aWR0aDo2MzIuOHB0IiBhbGlnbj0i Y2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+cnRjd2ViICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmciPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmc9NDBlcmlj c3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmciPmNocmlzdGVyLmhvbG1iZXJnPTQwZXJpY3Nzb24uY29t QGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgTm92ZW1iZXIgMiwgMjAy MSAxMToxMyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFu QHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5KdXN0aW4gVWJl cnRpICZsdDs8YSBocmVmPSJtYWlsdG86anVzdGluQHViZXJ0aS5uYW1lIj5qdXN0aW5AdWJlcnRp Lm5hbWU8L2E+Jmd0OzsgUlRDV2ViIElFVEYgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbcnRjd2ViXSBX b3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtdWJlcnRpLXJ0Y3dlYi1yZmM4ODI5Ymlz LTAxLnR4dDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7VGhpcyBtYWtlcyBpdCBtdWNoIGJldHRlci48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPkkgdGhpbmsgaXQgaXMgbWlz c2luZyBhIGNvdXBsZSBvZiBjb21tYXMgKCZxdW90O0luIHNvbWUgM1BDQyBzY2VuYXJpb3MsJnF1 b3Q7IGFuZCAmcXVvdDtJbiB0aGUgcmV3cml0dGVuIG9mZmVyLCZxdW90OykgYnV0IHdvcmtzIGZv ciBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiIHN0eWxl PSJtYXJnaW46MGNtIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBjYW4gYWRkIHRoZW0gd2hlbiBJIGFkZCB0aGUg dGV4dCB0byB0aGUgZHJhZnQsIGJ1dCBJIHRoaW5rIHRoZSBSRkMgZWRpdG9yIHdpbGwgbW9zdCBs aWtlbHkgbm90aWNlIHN1Y2ggdGhpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtJ IGhhdmUgY2hhbmdlZCB0aGUgc2VjdGlvbiBuYW1lIHNvIGl0IGlzIGNsZWFyIHRoYXQgaXQgYXBw bGllcyB0byBKU0VQIGFzIHdlbGwsIG5vdCBqdXN0IFNJUC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbSI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3VyZSwgdGhhdOKAmXMgZmluZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIiBzdHlsZT0i bWFyZ2luOjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIiBz dHlsZT0ibWFyZ2luOjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJ4bXNvbm9y bWFsIiBzdHlsZT0ibWFyZ2luOjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIiBzdHls ZT0ibWFyZ2luOjBjbSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Inhtc29ub3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92 IDIsIDIwMjEgYXQgMToyNCBQTSBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkV2ZW50aG91Z2ggSSB3b3VsZCBub3QgbGlrZSB0byBtYWtlIG1vcmUgY2hhbmdlcyB0aGFu IG5lY2Vzc2FyeSwgSSBhbSBmaW5lIHdpdGggJnF1b3Q7M1BDQyBDb25zaWRlcmF0aW9ucyZxdW90 Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJ4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SG93 ZXZlciwgeW91ciBzdWdnZXN0ZWQgdGV4dCBpcyB2ZXJ5IGRpZmZpY3VsdCB0byB1bmRlcnN0YW5k IGluIHNvbWUgcGxhY2VzLCBzbyBsZXQgbWUgZ2l2ZSBpdCBhIHRyeS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIiBzdHls ZT0ibWFyZ2luOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+KFRoZSBmaXJzdCBwYXJhZ3JhcGgg aXMgZ2VuZXJpYywgdGhlIHNlY29uZCBTSVAgc3BlY2lmaWMsIGFuZCB0aGUgdGhpcmQgQlVORExF IHNwZWNpZmljLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJ4bXNvbm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBjbSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+LS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Y29sb3I6IzIwMUYxRTtiYWNrZ3JvdW5kOndoaXRlIj4zUENDIENvbnNpZGVyYXRpb25zPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwi IHN0eWxlPSJtYXJnaW46MGNtO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2NvbG9yOiMyMDFGMUUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzIwMUYxRSI+SW4g c29tZSAzUENDIHNjZW5hcmlvcyBhIG5ldyBzZXNzaW9uIHdpbGwgYmUgZXN0YWJsaXNoZWQgYmV0 d2VlbiBhbiBlbmRwb2ludCB0aGF0IGlzIGN1cnJlbnRseSBwYXJ0IG9mIGFuIG9uZ29pbmcgc2Vz c2lvbiBhbmQgYW4gZW5kcG9pbnQgdGhhdCBpcyBjdXJyZW50bHkgbm90IHBhcnQgb2YNCiBhbiBv bmdvaW5nIHNlc3Npb24uIFRoZSBlbmRwb2ludCB0aGF0IGlzIHBhcnQgb2YgYSBzZXNzaW9uIHdp bGwgZ2VuZXJhdGUgYSBzdWJzZXF1ZW50IG9mZmVyIHRoYXQgd2lsbCBiZSBmb3J3YXJkZWQgdG8g dGhlIG90aGVyIGVuZHBvaW50IGJ5IGEgM1BDQyBjb250cm9sbGVyLiBUaGUgZW5kcG9pbnQgdGhh dCBpcyBub3QgcGFydCBvZiBhIHNlc3Npb24gd2lsbCBwcm9jZXNzIHRoZSBvZmZlciBhcyBhbiBp bml0aWFsIG9mZmVyLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiIHN0eWxlPSJtYXJnaW46MGNtO2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMyMDFGMUUiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Y29sb3I6IzIwMUYxRSI+VGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2Nv bCAoU0lQKSBbUkZDMzI2MV0gYWxsb3dzIGEgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgdG8gc2Vu ZCBhIHJlLUlOVklURSByZXF1ZXN0IHdpdGhvdXQgYW4gU0RQIGJvZHkgKHNvbWV0aW1lcyByZWZl cnJlZCB0byBhcyBhbiBlbXB0eSByZS1JTlZJVEUpLg0KIEluIHN1Y2ggY2FzZXMsIHRoZSBVc2Vy IEFnZW50IFNlcnZlciAoVUFTKSB3aWxsIGluY2x1ZGUgYW4gU0RQIG9mZmVyIGluIHRoZSBhc3Nv Y2lhdGVkIDIwMCBPSyByZXNwb25zZS4gSWYgdGhlIFVBUyBpcyBhIHBhcnQgb2YgYW4gb25nb2lu ZyBzZXNzaW9uLCBpdCB3aWxsIGluY2x1ZGUgYSBzdWJzZXF1ZW50IG9mZmVyIGluIHRoZSAyMDAg T0sgcmVzcG9uc2UuIFRoZSBvZmZlciB3aWxsIGJlIHJlY2VpdmVkIGJ5IGEgM1BDQyBjb250cm9s bGVyIChVQUMpDQogYW5kIHRoZW4gZm9yd2FyZGVkIHRvIGFub3RoZXIgVXNlciBBZ2VudCAoVUEp LiBJZiB0aGUgVUEgaXMgbm90IHBhcnQgb2YgYW4gb25nb2luZyBzZXNzaW9uLCBpdCB3aWxsIHBy b2Nlc3MgdGhlIG9mZmVyIGFzIGFuIGluaXRpYWwgb2ZmZXIuPGJyPg0KPGJyPg0KV2hlbiB0aGUg QlVORExFIG1lY2hhbmlzbSBpcyB1c2VkLCBhbiBpbml0aWFsIEJVTkRMRSBvZmZlciBpcyBjb25z dHJ1Y3RlZCB1c2luZyBkaWZmZXJlbnQgcnVsZXMgdGhhbiBzdWJzZXF1ZW50IEJVTkRMRSBvZmZl cnMsIGFuZCBpdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IGEgVUEgaXMgYWJsZSB0byBjb3JyZWN0 bHkgcHJvY2VzcyBhIHN1YnNlcXVlbnQgb2ZmZXIgYXMgYW4gaW5pdGlhbCBvZmZlci4gVGhlcmVm b3JlLCB0aGUgM1BDQyBjb250cm9sbGVyDQogU0hPVUxEIHJld3JpdGUgdGhlIHN1YnNlcXVlbnQg b2ZmZXIgaW50byBhIHZhbGlkIGluaXRpYWwgb2ZmZXIsIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJl cyBpbiAoU2VjdGlvbiA3LjIpLCBiZWZvcmUgaXQgZm9yd2FyZHMgdGhlIG9mZmVyIHRvIGEgVUEu IEluIHRoZSByZXdyaXR0ZW4gb2ZmZXIgdGhlIDNQQ0MgY29udHJvbGxlciB3aWxsIHNldCB0aGUg cG9ydCB2YWx1ZSB0byB6ZXJvIChhbmQgaW5jbHVkZSBhbiBTRFAgJ2J1bmRsZS1vbmx5JyBhdHRy aWJ1dGUpDQogZm9yIGVhY2ggJnF1b3Q7bT0mcXVvdDsgc2VjdGlvbiB3aXRoaW4gdGhlIEJVTkRM RSBncm91cCwgZXhjbHVkaW5nIHRoZSBvZmZlcmVyLXRhZ2dlZCAmcXVvdDttPSZxdW90OyBzZWN0 aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0ieG1z b25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i eG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0K PGRpdiBpZD0ieF9nbWFpbC1tXzY1OTczNDk3MjkyNTQyNTU4MjdkaXZScGx5RndkTXNnIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5j b208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBOb3ZlbWJlciAyLCAyMDIxIDY6MzMgUE08YnI+ DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPkNocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpq dWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGFs cGhhZXhwbG9yYXRpb25jby5jb208L2E+Jmd0OzsgSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmp1c3RpbkB1YmVydGkubmFtZSIgdGFyZ2V0PSJfYmxhbmsiPmp1c3RpbkB1YmVydGku bmFtZTwvYT4mZ3Q7Ow0KIFJUQ1dlYiBJRVRGICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+UmU6IFtydGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC11YmVydGkt cnRjd2ViLXJmYzg4MjliaXMtMDEudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhvdyBhYm91dCB3ZSByZXBsYWNlIHRoZSBTSVAgQ29uc2lkZXJhdGlvbnMgd2l0aDo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdp bjowY20iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjNQQ0MgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiIHN0eWxlPSJtYXJnaW46MGNt Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBzb21lIDNQQ0Mgc2NlbmFyaW9zLCBhbiBvZmZlciBnZW5lcmF0ZWQgZHVy aW5nIGFuIG9uZ29pbmcgc2Vzc2lvbiwgaS5lLiwgYSBzdWJzZXF1ZW50IG9mZmVyLCB3aWxsIGJl IHVzZWQgYnkgYSAzUENDIGNvbnRyb2xsZXIgdG8gZXN0YWJsaXNoIGEgbmV3IHNlc3Npb24gYW5k IGZvcndhcmRlZCBhcyBhbiBpbml0aWFsIG9mZmVyIHRvIGFub3RoZXIgZW5kcG9pbnQgdGhhdCBp cyBjdXJyZW50bHkgbm90IHBhcnQNCiBvZiBhIHNlc3Npb24uPGJyPg0KPGJyPg0KRm9yIGV4YW1w bGUsIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgW1JGQzMyNjFdIGFsbG93 cyBhIFVzZXIgQWdlbnQgQ2xpZW50IChVQUMpIHRvIHNlbmQgYSByZS1JTlZJVEUgcmVxdWVzdCB3 aXRob3V0IGFuIFNEUCBib2R5IChzb21ldGltZXMgcmVmZXJyZWQgdG8gYXMgYW4gZW1wdHkgcmUt SU5WSVRFKS4gSW4gc3VjaCBjYXNlcywgdGhlIFVzZXIgQWdlbnQgU2VydmVyIChVQVMpIHdpbGwg aW5jbHVkZSBhbiBTRFAgb2ZmZXINCiBpbiB0aGUgYXNzb2NpYXRlZCAyMDAgT0sgcmVzcG9uc2Uu IElmIFVBUyBpcyBhIHBhcnQgb2YgYW4gb25nb2luZyBzZXNzaW9uLCBpdCB3aWxsIGluY2x1ZGUg YSBzdWJzZXF1ZW50IG9mZmVyIGluIHRoZSAyMDAgT0sgcmVzcG9uc2UuIFRoZSBvZmZlciB3aWxs IGJlIHJlY2VpdmVkIGJ5IGEgM1BDQyBjb250cm9sbGVyIChVQUMpIGFuZCB0aGVuIGZvcndhcmRl ZCB0byBhbm90aGVyIFVzZXIgQWdlbnQgKFVBKSBhcyBhbiBpbml0aWFsIG9mZmVyLjxicj4NCjxi cj4NCldoZW4gdGhlIEJVTkRMRSBtZWNoYW5pc20gaXMgdXNlZCwgYW4gaW5pdGlhbCBCVU5ETEUg b2ZmZXIgaXMgY29uc3RydWN0ZWQgdXNpbmcgZGlmZmVyZW50IHJ1bGVzIHRoYW4gc3Vic2VxdWVu dCBCVU5ETEUgb2ZmZXJzLiBJdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IGEgc3Vic2VxdWVudCBv ZmZlciBpcyBhIHZhbGlkIGluaXRpYWwgb2ZmZXIgYW5kIHRoYXQgdGhlIGVuZHBvaW50IHRoYXQg ZXhwZWN0cyBhbiBpbml0aWFsIG9mZmVyIHdpbGwgcHJvcGVybHkNCiBwcm9jZXNzIHN1Y2ggYSBz dWJzZXF1ZW50IG9mZmVyLiBUaGVyZWZvcmUsIHRoZSAzUENDIGNvbnRyb2xsZXIgU0hPVUxEIHJl d3JpdGUgdGhlIHN1YnNlcXVlbnQgb2ZmZXIgaW50byBhIHZhbGlkIGluaXRpYWwgb2ZmZXIgYmVm b3JlIGl0IGlzIHVzZWQgdG8gZXN0YWJsaXNoIGEgbmV3IHNlc3Npb24uIFRvIG1ha2UgdGhlIHN1 YnNlcXVlbnQgb2ZmZXIgYSB2YWxpZCBpbml0aWFsIG9mZmVyLCAzUENDIHdpbGwgbmVlZCB0byBt b2RpZnkgYWxsIHRoZQ0KIG5vbi10YWdnZWQgbT0gbGluZXMgdG8gaW5jbHVkZSB0aGUgYnVuZGxl LW9ubHkgYXR0cmlidXRlIGFuZCBzZXQgdGhlIG09IGxpbmUgcG9ydCB0byB6ZXJvLjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwi IHN0eWxlPSJtYXJnaW46MGNtIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbjowY20iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVl LCBOb3YgMiwgMjAyMSBhdCA2OjAwIEFNIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+V2hhdCBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzOjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0tPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PTEQ6PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj7igJxUaGUgU2Vzc2lv biBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXSBhbGxvd3MgYSBVc2VyIEFnZW50 IENsaWVudCAoVUFDKSB0byBzZW5kIGEgcmUtSU5WSVRFIHJlcXVlc3Qgd2l0aG91dCBhbiBTRFAg Ym9keSAoc29tZXRpbWVzIHJlZmVycmVkIHRvIGFzIGFuDQogZW1wdHkgcmUtSU5WSVRFKS48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ SW4gc3VjaCBjYXNlcywgdGhlIFVzZXIgQWdlbnQgU2VydmVyIChVQVMpIHdpbGwgaW5jbHVkZSBh biBTRFAgT2ZmZXIgaW4gdGhlIGFzc29jaWF0ZWQgMjAwIE9LIHJlc3BvbnNlLiBUaGlzIGlzIHR5 cGljYWxseSB1c2VkIGZvciAzcmQgUGFydHkgQ2FsbCBDb250cm9sICgzUENDKQ0KIHNjZW5hcmlv cy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbSBhIEJVTkRMRSBwZXJzcGVjdGl2ZSwgc3VjaCBTRFAgT2ZmZXIgU0hPVUxEIGJl IGdlbmVyYXRlZCB1c2luZyB0aGUgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFNlY3Rpb24gNy4yLuKA nTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ TkVXOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+4oCcVGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBbUkZDMzI2MV0gYWxs b3dzIGEgVXNlciBBZ2VudCBDbGllbnQgKFVBQykgdG8gc2VuZCBhIHJlLUlOVklURSByZXF1ZXN0 IHdpdGhvdXQgYW4gU0RQIGJvZHkgKHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyBhbg0KIGVtcHR5 IHJlLUlOVklURSkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkluIHN1Y2ggY2FzZXMsIHRoZSBVc2VyIEFnZW50IFNlcnZlciAoVUFT KSB3aWxsIGluY2x1ZGUgYW4gU0RQIG9mZmVyIGluIHRoZSBhc3NvY2lhdGVkIDIwMCBPSyByZXNw b25zZS4gVGhpcyBpcyB0eXBpY2FsbHkgdXNlZCBmb3IgM3JkIFBhcnR5IENhbGwgQ29udHJvbCAo M1BDQykNCiBzY2VuYXJpb3MuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5JbiBzb21lIDNQQ0Mgc2NlbmFyaW9zIHRoZSBVQVMgd2lsbCBiZSBw YXJ0IG9mIGFuIG9uZ29pbmcgc2Vzc2lvbiwgYW5kIHdpbGwgdGhlcmVmb3JlIGluY2x1ZGUgYSBz dWJzZXF1ZW50IG9mZmVyIGluIHRoZSAyMDAgT0sgcmVzcG9uc2VzLiBUaGUgb2ZmZXIgd2lsbCBi ZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5yZWNlaXZlZCBieSBhIDNQQ0MgY29udHJvbGxlciAoVUFDKSBhbmQgdGhlbiBmb3J3YXJk ZWQgYXMgYW4gaW5pdGlhbCBvZmZlciB0byBhbm90aGVyIFVzZXIgQWdlbnQgKFVBKSB0aGF0IGlz IGN1cnJlbnRseSBub3QgcGFydCBvZiBhIHNlc3Npb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5XaGVuIHRoZSBCVU5ETEUgbWVjaGFuaXNt IGlzIHVzZWQsIGFzIGFuIGluaXRpYWwgQlVORExFIG9mZmVyIGxvb2sgZGlmZmVyZW50IHRoYW4g YSBzdWJzZXF1ZW50IEJVTkRMRSBvZmZlciwgaXQgY2Fubm90IGJlIGFzc3VtZWQgdGhhdCBhIFVB IHRoYXQgZXhwZWN0cyBhbiBpbml0aWFsDQogb2ZmZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+d2lsbCBiZSBhYmxlIHRvIHByb3Bl cmx5IHByb2Nlc3MgYSBzdWJzZXF1ZW50IG9mZmVyLiBUaGVyZWZvcmUsIHRoZSAzUENDIGNvbnRy b2xsZXIgbmVlZHMgdG8gYWN0IGFzIGEgQmFjay1Uby1CYWNrIFVzZXIgQWdlbnQgKEIyQlVBKSwg YW5kIHdoZW4gaXQgcmVjZWl2ZXMgdGhlDQogc3Vic2VxdWVudDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5vZmZlciBpdCBuZWVkcyB0 byByZXdyaXRlIGl0IGludG8gYW4gaW5pdGlhbCBvZmZlciBiZWZvcmUgaXQgaXMgZm9yd2FyZGVk IHRvIHN1Y2ggVUEu4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Um9tYW4NCiBT aHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2Js YW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50aWlzdGFpIDIuIG1hcnJhc2t1dXRhIDIw MjEgMTAuNDE8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRp QGFscGhhZXhwbG9yYXRpb25jby5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGFscGhhZXhw bG9yYXRpb25jby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhy ZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OzsgSnVzdGluIFViZXJ0aSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmp1c3RpbkB1YmVydGkubmFtZSIgdGFyZ2V0PSJfYmxhbmsiPmp1 c3RpbkB1YmVydGkubmFtZTwvYT4mZ3Q7Ow0KIFJUQ1dlYiBJRVRGICZsdDs8YSBocmVmPSJtYWls dG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UmU6IFtydGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBk cmFmdC11YmVydGktcnRjd2ViLXJmYzg4MjliaXMtMDEudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPk9uIE1vbiwgTm92IDEsIDIwMjEgYXQgMjo1MiBQTSBKdXN0aW4g VWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBQUk9CTEVNIGlzIHRoYXQg d2UgaGF2ZSB0d28gZW5kcG9pbnRzLCB3aGVyZSBvbmUgc2VuZHMgYSBzdWJzZXF1ZW50IG9mZmVy LCBhbmQgdGhlIG90aGVyIG9uZSBleHBlY3RzIGFuIGluaXRpYWwgb2ZmZXIuIFdoYXQgZG8geW91 IG5vcm1hbGx5IGRvIHdoZW4geW91IGhhdmUgdGhhdCBraW5kDQogb2YgcHJvYmxlbT8gWW91IHVz ZSBhbiBTQkMvQjJCVUEuIEluIHRoaXMgY2FzZSB0aGF0IFNCQy9CMkJVQSB3b3VsZCBiZSB0aGUg M1BDQyBjb250cm9sbGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U28sIG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gcmVt b3ZlIHRoZSBTSE9VTEQgdGV4dCBmcm9tIDg4NDNiaXMsIGFuZCBzaW1wbHkgYWRkIGEgbm90ZSBz b21ld2hlcmUgKGluIDg4NDNiaXMgYW5kL29yIDg4MjliaXMpIHdoaWNoIGRlc2NyaWJlcyB0aGUg aXNzdWUgYW5kIHNheXMgdGhhdCB0aGUNCiAzR1BQIGNvbnRyb2xsZXIgbmVlZHMgdG8gbW9kaWZ5 IHRoZSBvZmZlciBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Um9tYW4sIHRob3VnaHRzIG9uIHRoaXM/IElmIHRoZSAzUEND IGlzIGdvaW5nIHRvIHJld3JpdGUgdGhlIG9mZmVyIFNEUCBhbnl3YXkgdGhlbiBtYXliZSBhZGRp bmcgYT1idW5kbGUtb25seSBpc24ndCB0aGUgZW5kIG9mIHRoZSB3b3JsZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFtIG5vdCBvcHBvc2VkIHRvJm5ic3A7dGhpcyBp ZGVhLiAzUENDIHR5cGljYWxseSBrbm93cyB0aGF0IHRoZSBzdWJzZXF1ZW50IG9mZmVyIGlzIGdv aW5nIHRvIGJlIHVzZWQgYXMgaW5pdGlhbCwgYW5kIHNob3VsZCBiZSBhYmxlIHRvIHJld3JpdGUg dGhlIG9mZmVyIHRvIG1ha2UgaXQgdmFsaWQuIFdlDQogY2FuIGNoYW5nZSZuYnNwO1NJUCBDb25z aWRlcmF0aW9ucyBzZWN0aW9uIGluIDg4NDNiaXMgKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1tbXVzaWMtcmZjODg0M2Jpcy0wNS5odG1sI25hbWUt c2lwLWNvbnNpZGVyYXRpb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LWlldGYtbW11c2ljLXJmYzg4NDNiaXMtMDUuaHRtbCNuYW1lLXNpcC1j b25zaWRlcmF0aW9uPC9hPiksDQogcmVtb3ZlIHRoZSBTSE9VTEQsIGFuZCBzcGVjaWZ5IHRoYXQg M1BDQyBjb250cm9sbGVyIHNob3VsZCBmaXggdGhlIG9mZmVyLiBXZSBjYW4gdGhlbiByZWZlcmVu Y2UgdGhpcyBub3RlIGZyb20gODgyOWJpcyBvciByZXN0YXRlIHRoZSBzYW1lIGd1aWRhbmNlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBv dW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0 PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+ DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR07MB44419BD2DA5EEABD990305D1938E9HE1PR07MB4441eurp_-- From nobody Thu Nov 4 22:12:22 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C051E3A0C90 for ; Thu, 4 Nov 2021 22:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTRnIcBJ7zJe for ; Thu, 4 Nov 2021 22:12:14 -0700 (PDT) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 9C23B3A0C81 for ; Thu, 4 Nov 2021 22:12:14 -0700 (PDT) Received: by mail-pl1-f175.google.com with SMTP id t21so10415421plr.6 for ; Thu, 04 Nov 2021 22:12:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YgPJBsNY1T4wLavxPWQbBsuh4m7q9jYepNjA69Qr3hI=; b=6XSssg18jV1UEGy85K6sQIlSoPjkuywT7jd4mRfsMSnRz8O0TFPTsxbJ/3KN0a8fsw bQQV17HYrzrtVPBk03mcMCIS8LMhCO3/yqDjGxG0nBGzuSUhNI57Xtf6iyXPgiPs2zef SbuT51/sBPSPpLHXKplyvegV1FZJSIB99w6xKosDjHzXD9e5QPOQUPsppC2LpOCWARP2 iTCOvJsKi5YNb+Cqhfi0Np3T4FiRCTUF25ns7ZduLMT+xkTGiKakHv0YlSM9truWg8r6 yp9Ga4X7S6U1yQnz53TrxSp4TnVNmoBIxvz2HGy79RN0lrIl2/P22bPRSE2rtijvGS7B auRQ== X-Gm-Message-State: AOAM530zdzTNfwcKxZX+AlH5+4UVF7B7lvs7Hmd6kA9z1wdKaRMqubFj dHEpUA5wilOrSehcTHdUhEGLItNg1tljydCcuoUpZuNz X-Google-Smtp-Source: ABdhPJw2PJ2zWHQP/GIisGSKOanI5RXHg5ry8c8E9TUbmx4V3KVfBg6NCVNQf7ZA3+T95bwPDrd8IFwxWYshfQsq+Dc= X-Received: by 2002:a17:902:d652:b0:13f:c302:b945 with SMTP id y18-20020a170902d65200b0013fc302b945mr48936133plh.69.1636089133679; Thu, 04 Nov 2021 22:12:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 4 Nov 2021 22:12:02 -0700 Message-ID: To: Christer Holmberg Cc: Cullen Jennings , RTCWeb IETF , Roman Shpount Content-Type: multipart/alternative; boundary="000000000000a2489505d003af99" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 05:12:20 -0000 --000000000000a2489505d003af99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still feel the cleanest solution would be to allow the answerer to accept a subsequent offer as an initial offer (since then things will work in 3PCC with no SDP rewriting), and AFAIK no technical reason has been put forth to explain why this cannot work. However, I can live with the alternate solution put forth by Christer, and the proposed text seems reasonable to me. Justin On Thu, Nov 4, 2021 at 9:14 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > The question was whether an endpoint would be assumed to be able to accep= t > a subsequent offer (same address:port in each m- line) as an initial offe= r. > I did not agree to that. > > > > However, the suggestion a couple of days ago, which people seemed to agre= e > to, does NOT make that assumption anymore. Nothing out of the normal woul= d > be assumed by endpoints, and instead the 3GPP controller will act as a > B2BUA and modify the SDP if needed. > > > > Regards, > > > > Christer > > > > *From:* Cullen Jennings > *Sent:* perjantai 5. marraskuuta 2021 5.34 > *To:* Christer Holmberg ; Roman Shpount < > roman@telurix.com>; Justin Uberti > *Cc:* RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > > > Could we have a quick call on this next week during one of the breaks. I > have tried to follow this whole thread and some it does not make much sen= se > to me. I=E2=80=99m a bit lost on what the varios proposed resolutions are= . > > > > > > On Nov 3, 2021, at 12:38 PM, Christer Holmberg < > christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote: > > > > Justin, are you ok with the suggested text? I would probably be a good > idea to refer it in 8829bis. > > > > Regards, > > > > Christer > ------------------------------ > > *From:* rtcweb on behalf of Christer Holmberg < > christer.holmberg=3D40ericsson.com@dmarc.ietf.org> > *Sent:* Tuesday, November 2, 2021 11:13 PM > *To:* Roman Shpount > *Cc:* Justin Uberti ; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > Hi, > > > > >This makes it much better. I think it is missing a couple of commas ("In > some 3PCC scenarios," and "In the rewritten offer,") but works for me. > > > > I can add them when I add the text to the draft, but I think the RFC > editor will most likely notice such thing. > > > > >I have changed the section name so it is clear that it applies to JSEP a= s > well, not just SIP. > > > > Sure, that=E2=80=99s fine. > > > > Regards, > > > > Christer > > > > > > > > On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > Eventhough I would not like to make more changes than necessary, I am fin= e > with "3PCC Considerations". > > > > However, your suggested text is very difficult to understand in some > places, so let me give it a try. > > > > (The first paragraph is generic, the second SIP specific, and the third > BUNDLE specific.) > > > > --- > > > > 3PCC Considerations > > > > In some 3PCC scenarios a new session will be established between an > endpoint that is currently part of an ongoing session and an endpoint tha= t > is currently not part of an ongoing session. The endpoint that is part of= a > session will generate a subsequent offer that will be forwarded to the > other endpoint by a 3PCC controller. The endpoint that is not part of a > session will process the offer as an initial offer. > > > > The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clien= t > (UAC) to send a re-INVITE request without an SDP body (sometimes referred > to as an empty re-INVITE). In such cases, the User Agent Server (UAS) wil= l > include an SDP offer in the associated 200 OK response. If the UAS is a > part of an ongoing session, it will include a subsequent offer in the 200 > OK response. The offer will be received by a 3PCC controller (UAC) and th= en > forwarded to another User Agent (UA). If the UA is not part of an ongoing > session, it will process the offer as an initial offer. > > When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed > using different rules than subsequent BUNDLE offers, and it cannot be > assumed that a UA is able to correctly process a subsequent offer as an > initial offer. Therefore, the 3PCC controller SHOULD rewrite the subseque= nt > offer into a valid initial offer, following the procedures in (Section > 7.2), before it forwards the offer to a UA. In the rewritten offer the 3P= CC > controller will set the port value to zero (and include an SDP > 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, > excluding the offerer-tagged "m=3D" section. > > > > > > > > > > > > > ------------------------------ > > *From:* Roman Shpount > *Sent:* Tuesday, November 2, 2021 6:33 PM > *To:* Christer Holmberg > *Cc:* Justin Uberti ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > How about we replace the SIP Considerations with: > > > > 3PCC Considerations > > > > In some 3PCC scenarios, an offer generated during an ongoing session, > i.e., a subsequent offer, will be used by a 3PCC controller to establish = a > new session and forwarded as an initial offer to another endpoint that is > currently not part of a session. > > For example, the Session Initiation Protocol (SIP) [RFC3261] allows a Use= r > Agent Client (UAC) to send a re-INVITE request without an SDP body > (sometimes referred to as an empty re-INVITE). In such cases, the User > Agent Server (UAS) will include an SDP offer in the associated 200 OK > response. If UAS is a part of an ongoing session, it will include a > subsequent offer in the 200 OK response. The offer will be received by a > 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an > initial offer. > > When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed > using different rules than subsequent BUNDLE offers. It cannot be assumed > that a subsequent offer is a valid initial offer and that the endpoint th= at > expects an initial offer will properly process such a subsequent offer. > Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a > valid initial offer before it is used to establish a new session. To make > the subsequent offer a valid initial offer, 3PCC will need to modify all > the non-tagged m=3D lines to include the bundle-only attribute and set th= e m=3D > line port to zero. > > _____________ > Roman Shpount > > > > > > On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > What about something like this: > > > > --- > > > > OLD: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > > In such cases, the User Agent Server (UAS) will include an SDP Offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > > From a BUNDLE perspective, such SDP Offer SHOULD be generated using the > procedures defined in Section 7.2.=E2=80=9D > > > > NEW: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > Client (UAC) to send a re-INVITE request without an SDP body (sometimes > referred to as an empty re-INVITE). > > In such cases, the User Agent Server (UAS) will include an SDP offer in > the associated 200 OK response. This is typically used for 3rd Party Call > Control (3PCC) scenarios. > > > > In some 3PCC scenarios the UAS will be part of an ongoing session, and > will therefore include a subsequent offer in the 200 OK responses. The > offer will be > > received by a 3PCC controller (UAC) and then forwarded as an initial offe= r > to another User Agent (UA) that is currently not part of a session. > > > > When the BUNDLE mechanism is used, as an initial BUNDLE offer look > different than a subsequent BUNDLE offer, it cannot be assumed that a UA > that expects an initial offer > > will be able to properly process a subsequent offer. Therefore, the 3PCC > controller needs to act as a Back-To-Back User Agent (B2BUA), and when it > receives the subsequent > > offer it needs to rewrite it into an initial offer before it is forwarded > to such UA.=E2=80=9D > > > > ---- > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > *From:* Roman Shpount > *Sent:* tiistai 2. marraskuuta 2021 10.41 > *To:* Justin Uberti > *Cc:* Christer Holmberg ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > > The PROBLEM is that we have two endpoints, where one sends a subsequent > offer, and the other one expects an initial offer. What do you normally d= o > when you have that kind of problem? You use an SBC/B2BUA. In this case th= at > SBC/B2BUA would be the 3PCC controller. > > > > So, my suggestion would be to remove the SHOULD text from 8843bis, and > simply add a note somewhere (in 8843bis and/or 8829bis) which describes t= he > issue and says that the 3GPP controller needs to modify the offer > accordingly. > > > > Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP > anyway then maybe adding a=3Dbundle-only isn't the end of the world. > > > > I am not opposed to this idea. 3PCC typically knows that the subsequent > offer is going to be used as initial, and should be able to rewrite the > offer to make it valid. We can change SIP Considerations section in 8843b= is > ( > https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name= -sip-consideration), > remove the SHOULD, and specify that 3PCC controller should fix the offer. > We can then reference this note from 8829bis or restate the same guidance= . > > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --000000000000a2489505d003af99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I still feel the cleanest solution would be to allow the = answerer to accept a subsequent offer as an initial offer (since then thing= s will work in 3PCC with no SDP rewriting), and AFAIK no technical reason h= as been put forth to explain why this cannot work.
<= br>
However, I can live with the alternate solution = put forth by Christer, and the proposed text seems reasonable to me.
<= div dir=3D"auto">
Justin

On Thu, Nov 4, 2021= at 9:14 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

The question was whether an end= point would be assumed to be able to accept a subsequent offer (same addres= s:port in each m- line) as an initial offer. I did not agree to that.

=C2=A0

However, the suggestion a coupl= e of days ago, which people seemed to agree to, does NOT make that assumpti= on anymore. Nothing out of the normal would be assumed by endpoints, and in= stead the 3GPP controller will act as a B2BUA and modify the SDP if needed.

=C2=A0

Regards,

=

=C2=A0

Christer

=C2=A0

From: Cullen Jennings <fluffy@iii.ca>
Sent: perjantai 5. marraskuuta 2021 5.34
To: Christer Holmberg <christer.holmberg@ericsson.com>; Roman Shp= ount <roman@telur= ix.com>; Justin Uberti <justin@uberti.name>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

=C2=A0

=C2=A0

Could we have a quick call on this next week during = one of the breaks. I have tried to follow this whole thread and some it doe= s not make much sense to me. I=E2=80=99m a bit lost on what the varios prop= osed resolutions are.=C2=A0

=C2=A0



On Nov 3, 2021, at 12:38 PM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg=3D40ericsson.com@dmarc.ietf.org" target= =3D"_blank">christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote= :

=C2=A0

Justin, are you ok = with the suggested text? I would probably be a good idea to refer it in 882= 9bis.

=C2=A0

Regards,<= /u>

=C2=A0

Christer<= /u>

From:=C2=A0rtcweb <rtcweb-bounces@ietf.org> on behalf of = Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.= ietf.org>
Sent:=C2= =A0Tuesday, November 2, 2021 11:13 PM
To:=C2= =A0Roman Shpount <roman@telurix.com>
Cc:=C2= =A0Justin Uberti <justin@uberti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject:= =C2=A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-r= fc8829bis-01.txt

=C2=A0

Hi,

=C2=A0

>This makes it much better.<= span class=3D"m_-3506113441870466143apple-converted-space">=C2=A0I think it is missing a couple of commas ("In some 3PCC scenarios,= " and "In the rewritten offer,") but works for me.=

=C2=A0

I can add them when I add the t= ext to the draft, but I think the RFC editor will most likely notice such t= hing.

=C2=A0

>I have changed the section = name so it is clear that it applies to JSEP as well, not just SIP.

=C2=A0

Sure, that=E2=80=99s fine.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Eventhough I would = not like to make more changes than necessary, I am fine with "3PCC Con= siderations".

=C2=A0

However, your sugge= sted text is very difficult to understand in some places, so let me give it= a try.

=C2=A0

(The first paragrap= h is generic, the second SIP specific, and the third BUNDLE specific.)

=C2=A0

---

=C2=A0

3PCC Considerations

=C2=A0

In some 3PCC scenarios a new session will be establis= hed between an endpoint that is currently part of an ongoing session and an= endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generate a= subsequent offer that will be forwarded to the other endpoint by a 3PCC co= ntroller. The endpoint that is not part of a session will process the offer= as an initial offer.=C2=A0

=C2=A0

The Session Initiation Protocol (SIP) [RFC3261] allow= s a User Agent Client (UAC) to send a re-INVITE request without an SDP body= (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in th= e associated 200 OK response. If the UAS is a part of an ongoing session, i= t will include a subsequent offer in the 200 OK response. The offer will be= received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA is not part of an= ongoing session, it will process the offer as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following = the procedures in (Section 7.2), before it forwards the offer to a UA. In t= he rewritten offer the 3PCC controller will set the port value to zero (and= include an SDP 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, excluding the o= fferer-tagged "m=3D" section.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From:=C2=A0Roman Shpount <roman@telurix.com>
Sent:=C2= =A0Tuesday, November 2, 2021 6:33 PM
To:=C2= =A0Christer Holmberg <christer.holmberg@ericsson.com>
Cc:=C2= =A0Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti = <justin@uberti.n= ame>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject:= =C2=A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-r= fc8829bis-01.txt

=C2=A0

How about we replace the SIP Considerations with:=C2=A0

=C2=A0

3PCC Considerations

=C2=A0

In some 3PCC scenarios, an offer generated during an= ongoing session, i.e., a subsequent offer, will be used by a 3PCC controll= er to establish a new session and forwarded as an initial offer to another = endpoint that is currently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session,= it will include a subsequent offer in the 200 OK response. The offer will = be received by a 3PCC controller (UAC) and then forwarded to another User A= gent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rew= rite the subsequent offer into a valid initial offer before it is used to e= stablish a new session. To make the subsequent offer a valid initial offer,= 3PCC will need to modify all the non-tagged m=3D lines to include the bundle-only attribute and set the m= =3D line port to zero.

_____________
Roman Shpount

=C2=A0

=C2=A0

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

What about something like this:

=C2=A0

---=

=C2=A0

OLD:

=C2=A0

=E2=80=9CThe Session Initiation Pr= otocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE= request without an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent Serv= er (UAS) will include an SDP Offer in the associated 200 OK response. This = is typically used for 3rd Party Call Control (3PCC) scenarios.

From a BUNDLE perspective, such SD= P Offer SHOULD be generated using the procedures defined in Section 7.2.=E2= =80=9D

=C2=A0

NEW:

=C2=A0

=E2=80=9CThe Session Initiation Pr= otocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE= request without an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent Serv= er (UAS) will include an SDP offer in the associated 200 OK response. This = is typically used for 3rd Party Call Control (3PCC) scenarios.

=C2=A0

In some 3PCC scenarios the UAS wil= l be part of an ongoing session, and will therefore include a subsequent of= fer in the 200 OK responses. The offer will be

received by a 3PCC controller (UAC= ) and then forwarded as an initial offer to another User Agent (UA) that is= currently not part of a session.

=C2=A0

When the BUNDLE mechanism is used,= as an initial BUNDLE offer look different than a subsequent BUNDLE offer, = it cannot be assumed that a UA that expects an initial offer

will be able to properly process a= subsequent offer. Therefore, the 3PCC controller needs to act as a Back-To= -Back User Agent (B2BUA), and when it receives the subsequent

offer it needs to rewrite it into = an initial offer before it is forwarded to such UA.=E2=80=9D

=C2=A0

----

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From:=C2=A0Roman Shpount <roman@t= elurix.com>=C2=A0
Sent:=C2= =A0tiistai 2. marraskuuta 2021 10.41
To:=C2= =A0Justin Uberti <juberti@alphaexplorationco.com>
Cc:=C2= =A0Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ube= rti <justin@uber= ti.name>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject:= =C2=A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-r= fc8829bis-01.txt

=C2=A0

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <= juberti= @alphaexplorationco.com> wrote:

The PROBLEM is that we have two endpoints, where = one sends a subsequent offer, and the other one expects an initial offer. W= hat do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the= 3PCC controller.

=C2=A0

So, my suggestion would be to remove the SHOULD t= ext from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bi= s) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly.

=C2=A0

Roman, thoughts on this? If the 3PCC is going to = rewrite the offer SDP anyway then maybe adding a=3Dbundle-only isn't th= e end of the world.

=C2=A0

I am not opposed to=C2=A0this idea. 3PCC typicall= y knows that the subsequent offer is going to be used as initial, and shoul= d be able to rewrite the offer to make it valid. We can change=C2=A0SIP Considerations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-mmus= ic-rfc8843bis-05.html#name-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. = We can then reference this note from 8829bis or restate the same guidance.<= u>

_____________
Roman Shpount

=C2=A0

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

=C2=A0

--000000000000a2489505d003af99-- From nobody Fri Nov 5 04:40:30 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A243A0D4D for ; Fri, 5 Nov 2021 04:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, 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 SebYeouKQpbZ for ; Fri, 5 Nov 2021 04:40:20 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70040.outbound.protection.outlook.com [40.107.7.40]) (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 069963A0ACD for ; Fri, 5 Nov 2021 04:40:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j3Jz4pWaIqCHDp2BldF6XONiAWUSpGKBZSfpLX6ZxSq5sOdzM0ziMM6UuPuuVYoUH3GX/UorvXAc/dJOnbzeaFxEgfr2vf92aVNINDaHUeOsQeogMZ/7p3ny1RX2t2UgMWOA7jpdlJuiI3Ekb5hzINq2R9z4Y6EehQg+WihI1z0cwYv2eGqEyIo32sDGQ7J7sGoATREMIk1LzzbnMzFLeJtWGd6ApwcANj4ZH5ud9AvqNK42hQaJVNfOGHAYmTbFm1HI6urFjax8K+O6O47ovJQ17wq0/pZVTNHGmg7NnP5uVmbcf8AcmcJyhw7Dm4Bv9rNZhjjeuxrKms5NPB8XPQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dqZ4JHqdfjJZ5CpKyOFptQrz6E5D3MFHnmFHedP3rDI=; b=bQ8WURikfveWf70PTz+jQ1o70grUFIXqzPVK0nOEfd0eFpzYmsd4feUmz5q287X9IJy/YX0wZvFrJ58RkQqwIugMXmeW7gtRaFbmK/S8UUXoxs7zp4gVlvpcpGcoKtpIGRuVeZoKG9mhD7X1uSTIvjpVWBpOta0IxAa1LLTNFlqtvc6g8Volgxo5m4YL/vffIEGu6lxtZMwHc3ZJfZPaXnbczOrqOtcL8vS5ySTENcmjCaqXrTBtEdcY9AXmxpra5seOFAwhT+S7IC+aam45OM1A+8hv1NmWmqfawxCDNeESoP7aszhW7IiC+0nbbTIEIe9Xkf+XtTZzEh5/LYehzA== 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=dqZ4JHqdfjJZ5CpKyOFptQrz6E5D3MFHnmFHedP3rDI=; b=Lp/FtWoQZdLIKtaPYCLWGdQHi3PFqc1AXNgutOMh15BlfCLNfYR7Cao4VPWSK5gkpE7wIMuUjMGVDtbOH3gah5Ks6e5KQRvWftnDY3BKIlqZxaEakZtse/ZIKN3+eT5zbjqC28LkEHUYk1n6kMHiVVkTmUaTFZbPS28osgSrE6U= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR07MB3515.eurprd07.prod.outlook.com (2603:10a6:7:33::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.9; Fri, 5 Nov 2021 11:40:15 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4690.008; Fri, 5 Nov 2021 11:40:15 +0000 From: Christer Holmberg To: Justin Uberti CC: Cullen Jennings , RTCWeb IETF , Roman Shpount Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwIABOTMAgAB5B32AAGQiAIAA528AgAASO+CAAHHigIAABbShgAAQjQCAADc8UIABZ1UwgAIoRACAAAqQUIAAEN4AgABrqcQ= Date: Fri, 5 Nov 2021 11:40:15 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9c159836-8bb3-4ca9-e1d9-08d9a051090d x-ms-traffictypediagnostic: HE1PR07MB3515: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O7Z8kXccXn1YhY7qW9DoFC1rxa9VnJPHjdZLKLPl8Xbo/agEeFvToL5j7L8ifO4fgu8BzLUzuyCl4nDZ9ooCzvvCBRiMsu0r4jdx4q9vkJwEHQ2OMHjRoGQlpXcaM1T3vTWoQ36J3GeRxJc0Ew2oBiW3j+46tIQj6mYQfmwrO1KmclOrvktm0PjuMB+egF3c+8PBh2nIhMWwJhZu0WO8kJS6KNf1Xpp8ug59cpp+baAU8+SYblEYvHSbF+GagC80ARsYbKIgJQAeMxBUo/+DmrF295XQvJor56tWzy6eJ6KQI+zfwMiddWhRhK32PXVCnVE1bEBN0QtNcVrxaTjS7I2WY0o7opRwAd9T/rtrCBPBcnR3hAEYd3QzoenvJvFPvArrn0/4TEjySquKEYfjEmli56zK8j+PlamhUZMougf819npUQPcN84DnIQMiF97ISv8EUoSJLp55s6P7GE1vbNuXG1lr9XBRepHSZPWanJy7gr+KWfKBkX6kUSUX4TzydvftODbz1DUtlggTx2814j7JWLmqjHWCUIavr2klQfQe66F8lDUfqrSwF0sE0vQyrA4OwZQsvQNRkLgzzRiNa/4QYNc2xK+z1II5jWGpnLQZ3W2abls79WcXFhOKadUI0KMei30N0CyurXKqBQUvmdNUdrPKMGLfHjmw0HwRHV96R4/jeY24wXrwt9Lido4E0+eAZ/BFqgpmN+0nt9n6RNnxWo0HP6u0BX2Zh3MW3kNKVawXQ0hbJmb02oOZ+KibzBInytHvnw3gLDV5ZEkr9Lag9Yb8/i3twhKYDoBdZIc7BBR/J+llB1SmFPyqD/9a4kegj2YEFEpUiWvgDqGuw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(316002)(6506007)(82960400001)(26005)(53546011)(52536014)(4326008)(76116006)(45080400002)(71200400001)(33656002)(54906003)(186003)(44832011)(966005)(2906002)(8676002)(8936002)(55016002)(9686003)(66476007)(6916009)(64756008)(66446008)(122000001)(38070700005)(166002)(66556008)(86362001)(38100700002)(7696005)(66946007)(83380400001)(30864003)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?pX6rIqSRlnM/T0gUJoP40jK26g125pyOzFLyErY5AOS8qnjKv2hqI3MM?= =?Windows-1252?Q?AFBb7/MDZdNX9654Sq91B6TnAts9EAmOca8A0f02iVePZiEa/2HDQw8S?= =?Windows-1252?Q?uWnWAHPIFakO5AZ/UE/ayVmBcBYp3byS6E0O9D/TyH9ubp9Tn6AljvwF?= =?Windows-1252?Q?HizLzZk22oLgOuA/3PVexWr6jztNven/LIdXtmGWbr1Pxzol50a6bImo?= =?Windows-1252?Q?Q0mAGyDgYjUkIbbvAnrLY6HSakbzsVGFhScf8Pd8xXdjcI6tvM0laPHP?= =?Windows-1252?Q?N5Tj6/PBofP4DS3jJ6zWjMMQd7BCTsKF+94J18lzDWXJi+ru3ZMuhDQD?= =?Windows-1252?Q?NYYwcJ7rIrPKf0KLrvQwUrNshN3UhodHZUDlAY7Wh4JlSAnyPYffWp3t?= =?Windows-1252?Q?zC9btB4jJgjwl1zwEAn1HyToGOI79UPMBpAr6F4HG7xikl/+zUX/AEYi?= =?Windows-1252?Q?YZnZ1g1BmxNXdtITK2cPOZe+tDH3xDPb90sCfY+y5Iy1XY1O3r0ynZ9j?= =?Windows-1252?Q?iJhORvMyvLdL7iCRyCOFEOypQbidLNYoml16K1jtH95wKQ7Yj5/wKZ4E?= =?Windows-1252?Q?Y2HUTZbBrvLs1ZwiDI+wSAmPCWAWYMM47JT9m65BnbcwsFYX03K0cNBB?= =?Windows-1252?Q?JeVM4tUOn6BaGw0pNrVs9elCjaWmuK/4S2nP0BUQXCj/ZybAfJewjdXs?= =?Windows-1252?Q?Ej0DI0g0mIr86nZIzPmkyRd5r2l16/D/10X8DtWTbuLrtjDp2KZG2HdK?= =?Windows-1252?Q?QCBoEBO0Ckkxq8NRNcSgnG7SUfSBaa2688sVAJh0UQ0jFfpPDVpHexes?= =?Windows-1252?Q?RVzbYEMqEdy22UDLdE9YIPozeL5p3XLjQiVpONUIxh5oNvmH13nYcCmg?= =?Windows-1252?Q?al4WIiW9IIaZbctHfSzJdar71X3u8EnRLXE/q8IDRHEH48QszRIKzKDm?= =?Windows-1252?Q?7MSUiqjEOMCJwfeg7Ak9V73QtEX7bVw3pYQLPnc3i0JtRxknzMdVKsPw?= =?Windows-1252?Q?BlnUa+LdM3r6J6/GW1b46ylM8bTlT/FEqCklXLT+ouO0AgRJsFsDgBuk?= =?Windows-1252?Q?EvlXInmoJFOAki3AcvQCnUjIGnT3oCHmaCyFKqN+UxqRlzkBkHjuBKx1?= =?Windows-1252?Q?y2MNYlN9Ric1pcStI3A0F753J/8xGqu58mtbj8FbYkgJ0NyP59llPTs8?= =?Windows-1252?Q?sGL7y9ZqtvfvbKDw6UVV87F/MRWE7FCP4Ygv2sjZmhTVbV++qzvqSakQ?= =?Windows-1252?Q?lImbsPm25Tsl0grSEzkVm2KHc6bGLUgsaToZmPQCK2pEyp+iX8mK0O2G?= =?Windows-1252?Q?CN/6Jw/9/ZSlgLg8xrxKzn3Q74y6NEfI5z5JGDrzLJgtXmH8BAoTp1rK?= =?Windows-1252?Q?pa70jLKpVSZ9M6fyp8u9TADGSY8jNF+hCF3bqfE58XTlsVSlm58oBGoE?= =?Windows-1252?Q?HqJ5Ms8P2poD2t62YinUgwBKpzwSKyvJNktPEoxadMavsn/hWlJ1SUVE?= =?Windows-1252?Q?48mf4SqQI9jN9nRcxlo7QpulrWj+k11Z/AW/DdCRuFRF3GBGAeWfK0V9?= =?Windows-1252?Q?LMCAmFdeVQrMZGthSdZubC9vfvFY4+iRTOcfP22tQEpUf46Yt5ds4qw5?= =?Windows-1252?Q?Gng6pr9jCc3PM962AacFEG3rzSVphZtZIW144VbYGCtE8pC7jsRzMzGI?= =?Windows-1252?Q?cr/qthde5gbCqUVWu87jvb8IRMcv7frVitDNbWmZK/2JF5Zup8u9W7Uj?= =?Windows-1252?Q?MsxeKH0hbPIVgPhewyaS/qs5tOoniUOTqn/zSh43MW+tXerhrNxhdt91?= =?Windows-1252?Q?IIcqZWYLLNYUbZw3d3gbY7DVCtg=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9c159836-8bb3-4ca9-e1d9-08d9a051090d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2021 11:40:15.2766 (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: V6bQyf42IeWqDISsdR4d9y/rHYB7bO+/HiKklVGpprBOjnlNY+j3/rTEnbPV82BD0Yt0g2OAjg1UTT8va9UbdW6BXpBsWi89UUneFSudSxc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3515 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 11:40:28 -0000 --_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, If the text is something that everyone can agree on, then I suggest we go w= ith that. It does not require any changes or assumptions regarding the endp= oint behaviour. Regards, Christer Get Outlook for iOS ________________________________ From: Justin Uberti Sent: Friday, November 5, 2021 7:12:02 AM To: Christer Holmberg Cc: Cullen Jennings ; RTCWeb IETF ; Roman S= hpount Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt I still feel the cleanest solution would be to allow the answerer to accept= a subsequent offer as an initial offer (since then things will work in 3PC= C with no SDP rewriting), and AFAIK no technical reason has been put forth = to explain why this cannot work. However, I can live with the alternate solution put forth by Christer, and = the proposed text seems reasonable to me. Justin On Thu, Nov 4, 2021 at 9:14 PM Christer Holmberg > wrote: Hi, The question was whether an endpoint would be assumed to be able to accept = a subsequent offer (same address:port in each m- line) as an initial offer.= I did not agree to that. However, the suggestion a couple of days ago, which people seemed to agree = to, does NOT make that assumption anymore. Nothing out of the normal would = be assumed by endpoints, and instead the 3GPP controller will act as a B2BU= A and modify the SDP if needed. Regards, Christer From: Cullen Jennings > Sent: perjantai 5. marraskuuta 2021 5.34 To: Christer Holmberg >; Roman Shpount >; Justin Uberti > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt Could we have a quick call on this next week during one of the breaks. I ha= ve tried to follow this whole thread and some it does not make much sense t= o me. I=92m a bit lost on what the varios proposed resolutions are. On Nov 3, 2021, at 12:38 PM, Christer Holmberg > wrote: Justin, are you ok with the suggested text? I would probably be a good idea= to refer it in 8829bis. Regards, Christer ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Tuesday, November 2, 2021 11:13 PM To: Roman Shpount > Cc: Justin Uberti >; RTCWeb I= ETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt Hi, >This makes it much better. I think it is missing a couple of commas ("In s= ome 3PCC scenarios," and "In the rewritten offer,") but works for me. I can add them when I add the text to the draft, but I think the RFC editor= will most likely notice such thing. >I have changed the section name so it is clear that it applies to JSEP as = well, not just SIP. Sure, that=92s fine. Regards, Christer On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg > wrote: Hi, Eventhough I would not like to make more changes than necessary, I am fine = with "3PCC Considerations". However, your suggested text is very difficult to understand in some places= , so let me give it a try. (The first paragraph is generic, the second SIP specific, and the third BUN= DLE specific.) --- 3PCC Considerations In some 3PCC scenarios a new session will be established between an endpoin= t that is currently part of an ongoing session and an endpoint that is curr= ently not part of an ongoing session. The endpoint that is part of a sessio= n will generate a subsequent offer that will be forwarded to the other endp= oint by a 3PCC controller. The endpoint that is not part of a session will = process the offer as an initial offer. The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client = (UAC) to send a re-INVITE request without an SDP body (sometimes referred t= o as an empty re-INVITE). In such cases, the User Agent Server (UAS) will i= nclude an SDP offer in the associated 200 OK response. If the UAS is a part= of an ongoing session, it will include a subsequent offer in the 200 OK re= sponse. The offer will be received by a 3PCC controller (UAC) and then forw= arded to another User Agent (UA). If the UA is not part of an ongoing sessi= on, it will process the offer as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer in= to a valid initial offer, following the procedures in (Section 7.2), before= it forwards the offer to a UA. In the rewritten offer the 3PCC controller = will set the port value to zero (and include an SDP 'bundle-only' attribute= ) for each "m=3D" section within the BUNDLE group, excluding the offerer-ta= gged "m=3D" section. ________________________________ From: Roman Shpount > Sent: Tuesday, November 2, 2021 6:33 PM To: Christer Holmberg > Cc: Justin Uberti >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e.,= a subsequent offer, will be used by a 3PCC controller to establish a new s= ession and forwarded as an initial offer to another endpoint that is curren= tly not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS = is a part of an ongoing session, it will include a subsequent offer in the = 200 OK response. The offer will be received by a 3PCC controller (UAC) and = then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Ther= efore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid= initial offer before it is used to establish a new session. To make the su= bsequent offer a valid initial offer, 3PCC will need to modify all the non-= tagged m=3D lines to include the bundle-only attribute and set the m=3D lin= e port to zero. _____________ Roman Shpount On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg > wrote: Hi, What about something like this: --- OLD: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the pro= cedures defined in Section 7.2.=94 NEW: =93The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Clie= nt (UAC) to send a re-INVITE request without an SDP body (sometimes referre= d to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the= associated 200 OK response. This is typically used for 3rd Party Call Cont= rol (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will= therefore include a subsequent offer in the 200 OK responses. The offer wi= ll be received by a 3PCC controller (UAC) and then forwarded as an initial offer = to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look differen= t than a subsequent BUNDLE offer, it cannot be assumed that a UA that expec= ts an initial offer will be able to properly process a subsequent offer. Therefore, the 3PCC co= ntroller needs to act as a Back-To-Back User Agent (B2BUA), and when it rec= eives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded t= o such UA.=94 ---- Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc88= 29bis-01.txt On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti > wrote: The PROBLEM is that we have two endpoints, where one sends a subsequent off= er, and the other one expects an initial offer. What do you normally do whe= n you have that kind of problem? You use an SBC/B2BUA. In this case that SB= C/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simp= ly add a note somewhere (in 8843bis and/or 8829bis) which describes the iss= ue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyw= ay then maybe adding a=3Dbundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent off= er is going to be used as initial, and should be able to rewrite the offer = to make it valid. We can change SIP Considerations section in 8843bis (http= s://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-c= onsideration), remove the SHOULD, and specify that 3PCC controller should f= ix the offer. We can then reference this note from 8829bis or restate the s= ame guidance. _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

If the text is something that everyone can agree on, then = I suggest we go with that. It does not require any changes or assumptions r= egarding the endpoint behaviour.

Regards,

Christer
From: Justin Uberti <jus= tin@uberti.name>
Sent: Friday, November 5, 2021 7:12:02 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Cullen Jennings <fluffy@iii.ca>; RTCWeb IETF <rtcweb@ie= tf.org>; Roman Shpount <roman@telurix.com>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt
 
I still feel the cleanest solution would be to allow the = answerer to accept a subsequent offer as an initial offer (since then thing= s will work in 3PCC with no SDP rewriting), and AFAIK no technical reason h= as been put forth to explain why this cannot work.

However, I can live with the alternate solution put forth= by Christer, and the proposed text seems reasonable to me.

Justin

On Thu, Nov 4, 2021 at 9:14 PM Chri= ster Holmberg <christe= r.holmberg@ericsson.com> wrote:

Hi,

 

The question was whether an e= ndpoint would be assumed to be able to accept a subsequent offer (same addr= ess:port in each m- line) as an initial offer. I did not agree to that.<= /u>

 

However, the suggestion a cou= ple of days ago, which people seemed to agree to, does NOT make that assump= tion anymore. Nothing out of the normal would be assumed by endpoints, and = instead the 3GPP controller will act as a B2BUA and modify the SDP if needed.

 

Regards,

 

Christer=

 

From: Cullen Jennings <fluffy@iii.ca>
Sent: perjantai 5. marraskuuta 2021 5.34
To: Christer Holmberg <christer.holmberg@ericsson.com>; Roman Shp= ount <roman@telur= ix.com>; Justin Uberti <justin@uberti.name>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

 

 

Could we have a quick call on this next week durin= g one of the breaks. I have tried to follow this whole thread and some it d= oes not make much sense to me. I=92m a bit lost on what the varios proposed= resolutions are. 

 



On Nov 3, 2021, at 12:38 PM, Christer Holmberg <= ;christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrot= e:

 

Justin, are you o= k with the suggested text? I would probably be a good idea to refer it in 8= 829bis.

 <= /u>

Regards,

 <= /u>

Christer

From: rtcweb <rtcweb-bounces@ietf.org> on behalf= of Christer Holmberg <christer.holmberg=3D40ericsson.com@dm= arc.ietf.org>
Sent:&= nbsp;Tuesday, November 2, 2021 11:13 PM
To:&nb= sp;Roman Shpount <roman@telurix.com>
Cc:&nb= sp;Justin Uberti <justin@uberti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb= -rfc8829bis-01.txt

 

Hi,

 =

>This makes it much better= . I think it is missing a couple of commas ("In some 3PCC scenar= ios," and "In the rewritten offer,") but works for me.

 =

I can add them when I add the= text to the draft, but I think the RFC editor will most likely notice such= thing.

 

>I have changed the sectio= n name so it is clear that it applies to JSEP as well, not just SIP.=

 

Sure, that=92s fine.

 

Regards,=

 

Christer=

 

 =

 =

On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,=

 

Eventhough I woul= d not like to make more changes than necessary, I am fine with "3PCC C= onsiderations".

 

However, your sug= gested text is very difficult to understand in some places, so let me give = it a try.

 

(The first paragr= aph is generic, the second SIP specific, and the third BUNDLE specific.)

 

---=

 

3PCC Considerations

 =

In some 3PCC scenarios a new session will be estab= lished between an endpoint that is currently part of an ongoing session and= an endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generat= e a subsequent offer that will be forwarded to the other endpoint by a 3PCC= controller. The endpoint that is not part of a session will process the of= fer as an initial offer. 

 =

The Session Initiation Protocol (SIP) [RFC3261] al= lows a User Agent Client (UAC) to send a re-INVITE request without an SDP b= ody (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP= offer in the associated 200 OK response. If the UAS is a part of an ongoin= g session, it will include a subsequent offer in the 200 OK response. The o= ffer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA = is not part of an ongoing session, it will process the offer as an initial = offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following = the procedures in (Section 7.2), before it forwards the offer to a UA. In t= he rewritten offer the 3PCC controller will set the port value to zero (and= include an SDP 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, excluding the o= fferer-tagged "m=3D" section.

 

 

 

 

 

 

From: Roman Shpount <roman@telurix.com>
Sent:&= nbsp;Tuesday, November 2, 2021 6:33 PM
To:&nb= sp;Christer Holmberg <christer.holmberg@ericsson.com>
Cc:&nb= sp;Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti = <justin@uberti.n= ame>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb= -rfc8829bis-01.txt

 =

How about we replace the SIP Considerations with:<= span class=3D"x_m_-3506113441870466143apple-converted-space"> <= u>

 =

3PCC Considerations

 =

In some 3PCC scenarios, an offer generated during = an ongoing session, i.e., a subsequent offer, will be used by a 3PCC contro= ller to establish a new session and forwarded as an initial offer to anothe= r endpoint that is currently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User = Agent Client (UAC) to send a re-INVITE request without an SDP body (sometim= es referred to as an empty re-INVITE). In such cases, the User Agent Server= (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session,= it will include a subsequent offer in the 200 OK response. The offer will = be received by a 3PCC controller (UAC) and then forwarded to another User A= gent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed u= sing different rules than subsequent BUNDLE offers. It cannot be assumed th= at a subsequent offer is a valid initial offer and that the endpoint that e= xpects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rew= rite the subsequent offer into a valid initial offer before it is used to e= stablish a new session. To make the subsequent offer a valid initial offer,= 3PCC will need to modify all the non-tagged m=3D lines to include the bundle-only attribute and set the m= =3D line port to zero.

_____________
Roman Shpount

 =

 =

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

What about something like this:=

 =

---

 =

OLD:

 =

=93The Session Initiation Proto= col (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE re= quest without an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent S= erver (UAS) will include an SDP Offer in the associated 200 OK response. Th= is is typically used for 3rd Party Call Control (3PCC) scenarios.

From a BUNDLE perspective, such= SDP Offer SHOULD be generated using the procedures defined in Section 7.2.= =94

 =

NEW:

 =

=93The Session Initiation Proto= col (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE re= quest without an SDP body (sometimes referred to as an empty re-INVITE).

In such cases, the User Agent S= erver (UAS) will include an SDP offer in the associated 200 OK response. Th= is is typically used for 3rd Party Call Control (3PCC) scenarios.

 =

In some 3PCC scenarios the UAS = will be part of an ongoing session, and will therefore include a subsequent= offer in the 200 OK responses. The offer will be<= /span>

received by a 3PCC controller (= UAC) and then forwarded as an initial offer to another User Agent (UA) that= is currently not part of a session.

 =

When the BUNDLE mechanism is us= ed, as an initial BUNDLE offer look different than a subsequent BUNDLE offe= r, it cannot be assumed that a UA that expects an initial offer

will be able to properly proces= s a subsequent offer. Therefore, the 3PCC controller needs to act as a Back= -To-Back User Agent (B2BUA), and when it receives the subsequent

offer it needs to rewrite it in= to an initial offer before it is forwarded to such UA.=94=

 =

----

 =

Regards,

 =

Christer

 =

 =

 =

 =

 =

 =

 =

 =

From: = ;Roman Shpount <roman@t= elurix.com> 
Sent:&= nbsp;tiistai 2. marraskuuta 2021 10.41
To:&nb= sp;Justin Uberti <juberti@alphaexplorationco.com>
Cc:&nb= sp;Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ube= rti <justin@uber= ti.name>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb= -rfc8829bis-01.txt

 

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti &= lt;jube= rti@alphaexplorationco.com> wrote:

The PROBLEM is that we have two endpoints, whe= re one sends a subsequent offer, and the other one expects an initial offer= . What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the= 3PCC controller.

 

So, my suggestion would be to remove the SHOUL= D text from 8843bis, and simply add a note somewhere (in 8843bis and/or 882= 9bis) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly.

 

Roman, thoughts on this? If the 3PCC is going = to rewrite the offer SDP anyway then maybe adding a=3Dbundle-only isn't the= end of the world.

 

I am not opposed to this idea. 3PCC typic= ally knows that the subsequent offer is going to be used as initial, and sh= ould be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-m= music-rfc8843bis-05.html#name-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. = We can then reference this note from 8829bis or restate the same guidance.<= u>

_____________
Roman Shpount

 

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

 

--_000_HE1PR07MB44416A47EAA75FA00C2D8226938E9HE1PR07MB4441eurp_-- From nobody Tue Nov 9 12:38:35 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BB23A10D4 for ; Tue, 9 Nov 2021 12:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY59dzoUwWNi for ; Tue, 9 Nov 2021 12:38:29 -0800 (PST) Received: from smtp111.iad3b.emailsrvr.com (smtp111.iad3b.emailsrvr.com [146.20.161.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1066A3A10CE for ; Tue, 9 Nov 2021 12:38:29 -0800 (PST) X-Auth-ID: fluffy@iii.ca Received: by smtp22.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B14B860120; Tue, 9 Nov 2021 15:38:27 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_66ABFAAF-2CAD-49FB-BCEB-600A01483C70" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Cullen Jennings In-Reply-To: Date: Tue, 9 Nov 2021 13:38:26 -0700 Message-Id: References: To: RTCWeb IETF X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Classification-ID: 8dcb6740-844a-4de6-9e35-954d41bcd51d-1-1 Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 20:38:34 -0000 --Apple-Mail=_66ABFAAF-2CAD-49FB-BCEB-600A01483C70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We might want to say if you don=E2=80=99t want to do any of the ICE = nightmare, ICE Lite is the best way to not do it and still have = interoperability. Do we know someone working on this at 5G that can = help provide more guidance ? > On Nov 3, 2021, at 7:10 AM, Ted Hardie wrote: >=20 > Hi Harald, >=20 > It is definitely possible for us to send liaison statements via the = appropriate channel, but I am missing some context. Can you provide a = citation to the document from which the excerpt comes? (It appears to = be labeled a white paper, so the first step may be to confirm that its = description and the underlying specs say the same thing.) >=20 > regards, >=20 > Ted Hardie >=20 > On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand = > wrote: > It's come to my attention that there's apparently some 5G spec that = says=20 > "Use WebRTC datachannel, but don't bother with this ICE stuff". >=20 > The exact quote is below. >=20 > Now I don't mind saying "don't use TURN/STUN servers" - that's a=20 > configuration option on the WEBRTC API, and anyone can choose to not = do=20 > that - but I do mind leaving out ICE. An ICE-supporting implementation=20= > won't interwork properly with an implementation that doesn't support = ICE. >=20 > Is it possible for the IETF to say "please don't make incompatible=20 > changes to our protocols without asking us"? (that's the version where = I=20 > try not to use expletives). >=20 > Or is it possible that this is all a misunderstanding, and the 5G = folks=20 > actually meant to require peer-to-peer ICE, but just wrote it wrongly? >=20 > Or did I misunderstand what the WG's intent was, and should just suck = it=20 > up and interoperate with non-ICE-supporting endpoints? >=20 > Harald >=20 > --------- Spec reference quote ---------- >=20 > 1. Spec > NG.129 - 5G Data Channel White Paper (CR1001) >=20 > 8.2.1Data channel APIs > The data channel application consists of the device side logic and the=20= > server side logic. > Both should use standardized APIs that need to be agreed by the = industry. > W3C WebRTC1.0 data channel API specification is suggested as the=20 > preferred IMS data channel API. RTCPeerConnection , > RTCDataChannel object, the callbacks need to be supported . > Only data channel API related definitions are used and IMS data = channel=20 > API is not allowed to use WebRTC media. > ICE/STUN/TURN are also not required. >=20 > # Reference > 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction > GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS > GSMA NG.129_5G DATA CHANNEL >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_66ABFAAF-2CAD-49FB-BCEB-600A01483C70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

We might want to say if you don=E2=80=99t = want to do any of the ICE nightmare, ICE Lite is the best way to not do = it and still have interoperability.  Do we know someone working on = this at 5G that can help provide more guidance ?



On Nov 3, 2021, at 7:10 AM, Ted = Hardie <ted.ietf@gmail.com> wrote:

Hi Harald,

It is definitely = possible for us to send liaison statements via the appropriate channel, = but I am missing some context.  Can you provide a citation to the = document from which the excerpt comes?  (It appears to be labeled a = white paper, so the first step may be to confirm that its description = and the underlying specs say the same thing.)

regards,

Ted Hardie

On Wed, Nov 3, 2021 at 11:37 AM Harald = Alvestrand <harald@alvestrand.no> wrote:
It's come to my attention that = there's apparently some 5G spec that says
"Use WebRTC datachannel, but don't bother with this ICE stuff".

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - that's a
configuration option on the WEBRTC API, and anyone can choose to not do =
that - but I do mind leaving out ICE. An ICE-supporting implementation =
won't interwork properly with an implementation that doesn't support = ICE.

Is it possible for the IETF to say "please don't make incompatible
changes to our protocols without asking us"? (that's the version where I =
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks =
actually meant to require peer-to-peer ICE, but just wrote it = wrongly?

Or did I misunderstand what the WG's intent was, and should just suck it =
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper  (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the =
server side logic.
Both should use standardized APIs that need to be agreed by the = industry.
W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the  callbacks need to be supported .
Only data channel API related definitions  are used and IMS data = channel
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and = interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

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

= --Apple-Mail=_66ABFAAF-2CAD-49FB-BCEB-600A01483C70-- From nobody Tue Nov 9 12:49:31 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3E3A1163 for ; Tue, 9 Nov 2021 12:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=telurix.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 VuEARb49QmhX for ; Tue, 9 Nov 2021 12:49:19 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 CAD473A112A for ; Tue, 9 Nov 2021 12:49:18 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id a2so85439qtx.11 for ; Tue, 09 Nov 2021 12:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5B0FKGPjow4v91chr1Kh3fT++gDkca0u9Fme3KhmBCU=; b=OcvSOaSVpaqK5Mt1d9QhwOr89RIlKv7dcoxCey/G+DbFhqoYwPPRSM89LXi6zR4bZV UhLYCdpvuEUMfiG+wpMACidDTtoVlGME8YXhEqDwZcm6qlXA63w5k/ISUNJ3XQqK6CCY 3mOjtZ6I1b0tt29VQ/YFGhbX1ghXOfZbDf+qI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5B0FKGPjow4v91chr1Kh3fT++gDkca0u9Fme3KhmBCU=; b=cZlcw9OfMDoXGrls+wNCwE4DsIDsetEc6hPwcF3gACpBtbYfg2+akb4aoWVSEYNuXM 6Hdov44Kp7YSbxspCUokl2nLQD+5/DsoUABXzZcdAkKJWPqD+oI1Vhv+aHxWU8NIQU1/ rXcU0x1QiX0NMbldTBNOJbxC6pYx0/qJL2d87puJwvArtmDdEQmML27U9VNfTBZtmQog 0ZjoLbaEGEANmaVvVfOQ5C0hU+l4ROvlRts2bCYibftFpYN0816xBTFmnUCX1WtY8w0b St/9vIGN+D3djo7nBwVey5gCcI/NTra4iJCkjzllQ77W1CRzM3AbawQ6zrvU10LigjM9 S/nQ== X-Gm-Message-State: AOAM533Wx1ENMnbtIS3tRHhEX5tQT1I9/4rS3kMC53q+csA8dSngNzVm 9Ogss5H+80/3+nz0Cfyy6zpI0FxUuShctA== X-Google-Smtp-Source: ABdhPJwYyJAmPC6euKeZW7+9iX20pZINXn6EIIl9dNvRc5PelgQitwEnJTz/isXP8Z/2zW63c6SRHQ== X-Received: by 2002:ac8:56f9:: with SMTP id 25mr11877790qtu.374.1636490954054; Tue, 09 Nov 2021 12:49:14 -0800 (PST) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id h12sm12165612qkp.52.2021.11.09.12.49.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Nov 2021 12:49:13 -0800 (PST) Received: by mail-yb1-f178.google.com with SMTP id e136so752168ybc.4 for ; Tue, 09 Nov 2021 12:49:13 -0800 (PST) X-Received: by 2002:a25:2342:: with SMTP id j63mr11066575ybj.22.1636490952812; Tue, 09 Nov 2021 12:49:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 9 Nov 2021 15:49:01 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000ebade705d0613d59" Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 20:49:30 -0000 --000000000000ebade705d0613d59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would advise against ICE-lite. One of the things that ICE provides is consent to send media. ICE-lite does not have this. Getting consent is important to avoid using endpoints for DDOS attacks, so it is a matter of security. If they want to simplify things, they can use host candidates only, which will make the ICE state machine trivial. _____________ Roman Shpount On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings wrote: > > We might want to say if you don=E2=80=99t want to do any of the ICE night= mare, ICE > Lite is the best way to not do it and still have interoperability. Do we > know someone working on this at 5G that can help provide more guidance ? > > > > On Nov 3, 2021, at 7:10 AM, Ted Hardie wrote: > > Hi Harald, > > It is definitely possible for us to send liaison statements via the > appropriate channel, but I am missing some context. Can you provide a > citation to the document from which the excerpt comes? (It appears to be > labeled a white paper, so the first step may be to confirm that its > description and the underlying specs say the same thing.) > > regards, > > Ted Hardie > > On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand > wrote: > >> It's come to my attention that there's apparently some 5G spec that says >> "Use WebRTC datachannel, but don't bother with this ICE stuff". >> >> The exact quote is below. >> >> Now I don't mind saying "don't use TURN/STUN servers" - that's a >> configuration option on the WEBRTC API, and anyone can choose to not do >> that - but I do mind leaving out ICE. An ICE-supporting implementation >> won't interwork properly with an implementation that doesn't support ICE= . >> >> Is it possible for the IETF to say "please don't make incompatible >> changes to our protocols without asking us"? (that's the version where I >> try not to use expletives). >> >> Or is it possible that this is all a misunderstanding, and the 5G folks >> actually meant to require peer-to-peer ICE, but just wrote it wrongly? >> >> Or did I misunderstand what the WG's intent was, and should just suck it >> up and interoperate with non-ICE-supporting endpoints? >> >> Harald >> >> --------- Spec reference quote ---------- >> >> 1. Spec >> NG.129 - 5G Data Channel White Paper (CR1001) >> >> 8.2.1Data channel APIs >> The data channel application consists of the device side logic and the >> server side logic. >> Both should use standardized APIs that need to be agreed by the industry= . >> W3C WebRTC1.0 data channel API specification is suggested as the >> preferred IMS data channel API. RTCPeerConnection , >> RTCDataChannel object, the callbacks need to be supported . >> Only data channel API related definitions are used and IMS data channel >> API is not allowed to use WebRTC media. >> ICE/STUN/TURN are also not required. >> >> # Reference >> 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction >> GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS >> GSMA NG.129_5G DATA CHANNEL >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000ebade705d0613d59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would advise against ICE-lite. One of the things that IC= E provides is consent to send media. ICE-lite does not have this. Getting c= onsent is important to avoid using endpoints for DDOS attacks, so it is a m= atter of security.

If they want to simplify things, they= can use host candidates only, which will make the ICE state machine trivia= l.
_____________
Roman Shpount

<= /div>

On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings <fluffy@iii.ca> wrote:
<= br>
We might want to say if you don=E2=80=99t want to do any of the IC= E nightmare, ICE Lite is the best way to not do it and still have interoper= ability.=C2=A0 Do we know someone working on this at 5G that can help provi= de more guidance ?



On Nov 3, 2021, at 7:10 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

Hi Harald,

It= is definitely possible for us to send liaison statements via the appropria= te channel, but I am missing some context.=C2=A0 Can you provide a citation= to the document from which the excerpt comes?=C2=A0 (It appears to be labe= led a white paper, so the first step may be to confirm that its description= and the underlying specs say the same thing.)

regards,

Ted Hardie

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand= <harald@alves= trand.no> wrote:
It's come to my attention that there's apparently some 5G s= pec that says
"Use WebRTC datachannel, but don't bother with this ICE stuff"= ;.

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - t= hat's a
configuration option on the WEBRTC API, and anyone can choose to not do that - but I do mind leaving out ICE. An ICE-supporting implementation
won't interwork properly with an implementation that doesn't suppor= t ICE.

Is it possible for the IETF to say "please don't make incompatible=
changes to our protocols without asking us"? (that's the version w= here I
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck i= t
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper=C2=A0 (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the
server side logic.
Both should use standardized APIs that need to be agreed by the industry. W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the=C2=A0 callbacks need to be supported .
Only data channel API related definitions=C2=A0 are used and IMS data chann= el
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000ebade705d0613d59-- From nobody Tue Nov 9 14:45:23 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0743A03EE for ; Tue, 9 Nov 2021 14:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 kTEroFTfRA7l for ; Tue, 9 Nov 2021 14:45:16 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70048.outbound.protection.outlook.com [40.107.7.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4FB3A02C1 for ; Tue, 9 Nov 2021 14:45:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ewTsWzbEewCqkOKB/JzMeVLHYOu2BLCme2YhWNInt3ELn21ZfkFZWwYBf+8EDtn85BOSSMjqHuVMZjh0+xb/0ZJ8dQ+gbf8CP/aPQMlhAyWOe1zsH+JeuhGTROc4qQ6bwLhZFR0ca1Rz0xiHYYHsjmztLlklyQUDyNOn+cw8yPYjRc2fsWQ/Rvy8wyF3cveroPbNcC+fWRDHuU+gr77Bd58fcX5296mE6VBtbER4fChLZy4ZSFTxCmalS9UtGaKtQDq17IPMSQb7tsirog6EL9dtRfULoeknTIlREaPdeoxiGtS1PwEr6FRGwBv3OFCjCVWsmR6uAcrMpdc0ABjI2g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h/HCL/eSFxbKphwnTNndTyFO4ag73e63umHWMW7mPSQ=; b=Pg1/QxRiHNLrUoqDgNCHEiObOhJ3yaVKjaqf8zAKwXoSv50oDNDvOg+LIpuGwB79ciDiCWpS2Roi4Xve6A4gvxn9cAqmyYvGQuuQTwyVi4bHZZ0ZBzKDaGRkfTg8b4zJso1bPESWtpdUxRHBk6mkBxiDtBkqylyEP5Xup6D/ont+lj5lPPrABAFiEl4GMwn2DPRzofnwvGEazVtiJJbfeqwNKxFH0EJRzaCI66Q4hbd6GWc2QzbQ4W5ltOMisbdQibgm1ltSXmzILYaPGavPcPX8E4z+xkWc9t9+VvzuloeQLAruq+FlSPHASkOnNTkvn/385NTwhdRM/EdAlrLb5g== 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=h/HCL/eSFxbKphwnTNndTyFO4ag73e63umHWMW7mPSQ=; b=Oicavr1Ao9lM6wFCqaR43VoEqwIDBPL0R0vN5v/Z8ancrd7KrGTka97Fzi6C+z+kW1WcDo29x3hcolP3hqZMc94rw8OGs6SGkngrMZQkBmC7l6ize+qFaxEWQgRsPFzGtG6zchSbMUSPbdK8TPCFvYoaX5CMcrwEFMnKWpTt0ao= Received: from HE1PR07MB3403.eurprd07.prod.outlook.com (2603:10a6:7:32::25) by HE1PR0702MB3690.eurprd07.prod.outlook.com (2603:10a6:7:7e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.9; Tue, 9 Nov 2021 22:45:07 +0000 Received: from HE1PR07MB3403.eurprd07.prod.outlook.com ([fe80::4c9f:2388:31aa:af0e]) by HE1PR07MB3403.eurprd07.prod.outlook.com ([fe80::4c9f:2388:31aa:af0e%7]) with mapi id 15.20.4690.016; Tue, 9 Nov 2021 22:45:07 +0000 From: Bo Burman To: Ted Hardie , Harald Alvestrand CC: RTCWeb IETF Thread-Topic: [rtcweb] 5G standards advocating WebRTC protocol violations? Thread-Index: AQHX0KdAAYfD9gxH+U6UWkCWLMimFavxxvYAgAe6/ZA= Date: Tue, 9 Nov 2021 22:45:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc0c4f07-e59e-479b-5272-08d9a3d29436 x-ms-traffictypediagnostic: HE1PR0702MB3690: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1002; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EJFqTqcTenzG7P2ErRbWEgJchJwE9Cr+lkJgh/Z9Kt0eQUu1Ix089qTKq5vYlEHRhSq86zywHCAmHNKQyBBbXDZQPqH+ZYw0/VgFlPB4igVFNSMV2lELxsBCxPVEVAwtbTBkBHSBlvNgNk59idbrESyq21hbCheqTx99D0spmXH62SBTIhg/ZJZBWJwfWI805cGQlM4qdA65lp/LtQJs1XSyzZ3z7PRMtGOqygBkO659wRDwOym0dibc6jxG30enpGDMqdZ/UuLd6AR9oqTyJdieyCR/iyb+pUFauXER2kZU1Rsu4i1q52Km/lmJPF03YKCh6wd1fUaS+FlhSwtgYIoiFpcM8tV8PU7oX/vEd30NInO0osNrJtDS6D71+IaTdmBo0tCXuWf/jedBtMHg7tM76SwJO5eb/qAVO90apVooR2R9gPP+bBXjXSDZiGmwymBc3fl5ffeIh0ffR09DIFVbQo3H4pt5df9iV52bq2UEMvec+M9GhgNF2LUjauvgAO/a9hKjOokyYqPlwkcPV4isjKsIDvzWxKPwvlyOm1WMQ+2+c/sTniQ84Edp7X1U1nC75ZWE8l0KoIvIsD9UBK070CledpPSnAsVIxVQYNkhuutXA6tRg7qdk+ARKXVzpftXEUDRjD/+eQhxeQPueN8yrQ4C7JghtlRqDEzqVnOL/IepLzd7mUWgERHtqYv1sUC7KPjKCh3TGKKMwJGmW4Ls7KLDmkebz9bgbhcTuXs9NDopfn02R55KPrPZhiJIsQ8lD3aUt5Qyfy+ve141D+snEBcIusRdYljtYIUHsM9lVrfjHj9DVZKpeaA1TWetymPDdoRIOnACmChKRHpeMQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3403.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(166002)(5660300002)(4326008)(83380400001)(64756008)(38100700002)(66946007)(44832011)(33656002)(99936003)(186003)(55016002)(9686003)(66446008)(82960400001)(508600001)(122000001)(110136005)(52536014)(26005)(966005)(6506007)(8676002)(316002)(7696005)(86362001)(53546011)(8936002)(66476007)(66556008)(76116006)(71200400001)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dVQ1cVp4UVJhVnZsSTMvMWlTZ2kra1V3MW5KSkFRV3cvekU3TUJRNWJnV0VP?= =?utf-8?B?c0Rnb3pRd0s3bU1vQXZkc3ZjYmpJQVVBNFlwOUdDR0hJR3RBQlJyTGJzRGZk?= =?utf-8?B?ck1zNjhMMnVjSXNEd3VTNi9WZ29tUHdlM0RqWGtreGlXMmNkdUhuTE9USGg3?= =?utf-8?B?TlFsUVhSVXljUUxNTUxXdGhJM2ZaR0lXVTFlQ2Y2eUxuVWt5TS9xK21LZGpG?= =?utf-8?B?VnlOUmxuSng3T1JrTkphU0ovdUt1QmRJeXpPR3dVbWtwYld3TUczcy9YM0Vn?= =?utf-8?B?UFN3dkZ4azdzYllnZWpoRTBNemljU1pyNEpDL0E1RTNZOCt4QkxEdmpYV0x2?= =?utf-8?B?ZjhlZTJGUXBIZXR3VDlLWFp3Q2xEZ2RERkFRYklmVTNwRkdyeHBlMERTS0tN?= =?utf-8?B?aEZpSm1OMDJqeWVHS2xXd01PZXIwZXBXTi9zWTgxdlFZVSs5UTQ2VXRFVk01?= =?utf-8?B?UFlvaEQ1L1RaeGFRTDJ2NElEN0hydnBHeW5TVjlsQTRFWEg0WHl0Y2R3TG9m?= =?utf-8?B?Q2hBamk4RmtLWjNIUy9HNWFBV3UwWHg2MWNFRFkySXdQYjZRUXlYZnliaDdq?= =?utf-8?B?VmF5RTdvU2xaUHdsdFdhYnV1VG5INVdBN2FsN3Z0NnphR3RhT3haRjg3SVpP?= =?utf-8?B?d0FBc2VNdWtNejNuTzA0b2xqZW5YS3pzYVFNNlZvNFF6MXBmanZvQnIzbWtZ?= =?utf-8?B?Mkp2NlpXMlN2RXM2clpoWE5vVGxBUVRrNWsvTjVrNEpqN1IzRXc5WjdwdGpi?= =?utf-8?B?dXBDZm5kc1M1N3ZmbnpvMldOWDZ4YUJYT2pDMVN1YWlYM1RBeDJ3azZqTFRO?= =?utf-8?B?MHpSOFFRaVdlNWo3UTU5U2tJNkw3Y2RaNHZMSU16Kzk2M0IzRDZxM1h3VUFW?= =?utf-8?B?ZWVlMzFpNlovZC9yb2dEaEVISGVwM0FQOGs2eUd4ZG1obzZHMUcvL21CeXkv?= =?utf-8?B?bDF5aVgzMUtoVFhpalIxOC9lVnN4UGhoRmFqdTNXV1hjYm9pNDNUeVc3dWxC?= =?utf-8?B?RDdXR0J1Z2V5cWxWNVNCMVMzUEQxaDFMK0hVWGFSa2owendRTncrbjJPTkNw?= =?utf-8?B?SEpCZUpyMEUzRE9oOGpLY3BiU2V4Sm5wdWE2VDBLZkUxVnpKZTlkVzlLWGd3?= =?utf-8?B?RFNZYnZ3aDMvSGJrSmQ4VG4rNjhDc2p1TEY4L2I0QnhzOXcrZnEwQ2w4R2xD?= =?utf-8?B?Nm9uTTJBbjRUYS9iTnVzajY5MmV6VXhxeWpTdmkxZTZybWRKSzgyMVgwalBK?= =?utf-8?B?REVTajFpUGJucUxoTnVHMVJDK2YzYXlNTzdTMHNFUStVRVErelJFNjBBckor?= =?utf-8?B?cnV3Mlk3SW96UGdMQTJFMWRqdTQ5czRQanZqOTNGTGwxZmUwSnZDL1hMUlkv?= =?utf-8?B?aG1iazFqYjhhREJPZE5hYnRGaUFxRnRveS85TFIzVEJ1ZTlwdjEvU3NaclZQ?= =?utf-8?B?a0lZSFlzNnlRbGpqMGlwLzN6WEpBbU90bzJ0Mlp6VTFpcmtMZFNjMVRMOUNQ?= =?utf-8?B?a05MOWFIdkdoaStpc05Bb1RoQVBxbThIYmlmVkt5cHZqSVl0UGlWOFpHenhs?= =?utf-8?B?MDd4bzM0ZEIrV1hUT0JpWEJ1QW53UnIrVmorN0F2SnJlU0duTzRHYVdnekhp?= =?utf-8?B?aldZMStjc0Q3SU5MUlJndmJ2V2N0Wkk5MzFPRkFKVStweUcvYVZCWkI2c2U1?= =?utf-8?B?RlBVV3ZPYnB3TG81WW9oSndBNUFKNGp2YlIwcGIrbUV6UWs4RFhjTCttZkcv?= =?utf-8?B?Y21vOG01VGs0Vy9PQkFBcnZhUmdicUpkYnU1QVMzYzhkMzVlYjEwbkhjNDh0?= =?utf-8?B?djZPcTVrVklSeHY1SFE4U0VCYWtLVitjUDZ4N0x3WW53YW1sN3lFb0FxS0dW?= =?utf-8?B?ZTc2NFpuRzBrRW1BWis0eDZJai9BTGpxdGNaRmR4N1lhRmZlKzE4V2NNZVlv?= =?utf-8?B?UGo0YlptcXlQcEdKUGZEMzIwSlN4STdKZENUTFJZWm5hOHZFUE1SZElaMVYx?= =?utf-8?B?OUNyVjdVU211TElDOUpZZUY3RjBmZEZMRkF2cjQ1WGNyYnp6dHR2MlVCRmRk?= =?utf-8?B?MGV4Z2VyaVdyazhLNEMyNWJjNjZNNVpTZHdxSlZJaDNmZ0x4Z0FmcTFYZGdO?= =?utf-8?B?VUNDK2wrdnBqS3JneWloQVNzS0ZrWEZkWmlDR1dhVTExVHRlNXR3THlydjZ6?= =?utf-8?Q?6PvHHnZH+75Apr8uvK72V9k=3D?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01DA_01D7D5C3.D290E850" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3403.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc0c4f07-e59e-479b-5272-08d9a3d29436 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2021 22:45:07.3474 (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: 7JnqJQCDkBzeVk4WuZ3pbQtVTouGUxAnX9wvkGPq8btTuoOKoKCQ+Q1twTRxtYk6DmUbbOGju00Uytc/TnFguA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3690 Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 22:45:22 -0000 ------=_NextPart_000_01DA_01D7D5C3.D290E850 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01DB_01D7D5C3.D290E850" ------=_NextPart_001_01DB_01D7D5C3.D290E850 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Ted, Harald, =20 I have some insight into that GSMA work that might help the discussion. The intent was never to create or even suggest incompatible changes to = WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC = protocols, which I believe is clear from other parts of that White = Paper. The suggested reuse of WebRTC data channel protocol stack is for = 3GPP IMS-native multimedia telephony, not intended to change the core of = WebRTC. It should be OK to use a data channel outside of WebRTC context = =E2=80=93 for example, like CLUE telepresence makes use of it. Also, = 3GPP previously defined WebRTC access to IMS through the use of a = gateway where ICE is used on the WebRTC side, but that is separate from = the GSMA case. =20 The GSMA White Paper is mainly educational for that community, in this = case exploring possibilities with using WebRTC data channel media as = part of 5G phone calls. If GSMA members find this interesting enough, = normative work and specifications will follow but nothing is started = yet. =20 I believe the sentence Harald highlights below should be interpreted = from the perspective that ICE/STUN/TURN functionality is strictly not = needed in a telco operator=E2=80=99s network, since connectivity is = solved by other means in that context. That particular sentence is = likely not considering what requirements, e.g. use of ICE, that may come = from reuse of existing WebRTC protocol stacks. This aspect must however = be kept in mind as the work continues. =20 I hope that helps. =20 Cheers, Bo =20 From: rtcweb On Behalf Of Ted Hardie Sent: den 3 november 2021 14:10 To: Harald Alvestrand Cc: RTCWeb IETF Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol = violations? =20 Hi Harald, =20 It is definitely possible for us to send liaison statements via the = appropriate channel, but I am missing some context. Can you provide a = citation to the document from which the excerpt comes? (It appears to = be labeled a white paper, so the first step may be to confirm that its = description and the underlying specs say the same thing.) =20 regards, =20 Ted Hardie =20 On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand > wrote: It's come to my attention that there's apparently some 5G spec that says = "Use WebRTC datachannel, but don't bother with this ICE stuff". The exact quote is below. Now I don't mind saying "don't use TURN/STUN servers" - that's a=20 configuration option on the WEBRTC API, and anyone can choose to not do=20 that - but I do mind leaving out ICE. An ICE-supporting implementation=20 won't interwork properly with an implementation that doesn't support = ICE. Is it possible for the IETF to say "please don't make incompatible=20 changes to our protocols without asking us"? (that's the version where I = try not to use expletives). Or is it possible that this is all a misunderstanding, and the 5G folks=20 actually meant to require peer-to-peer ICE, but just wrote it wrongly? Or did I misunderstand what the WG's intent was, and should just suck it = up and interoperate with non-ICE-supporting endpoints? Harald --------- Spec reference quote ---------- 1. Spec NG.129 - 5G Data Channel White Paper (CR1001) 8.2.1Data channel APIs The data channel application consists of the device side logic and the=20 server side logic. Both should use standardized APIs that need to be agreed by the = industry. W3C WebRTC1.0 data channel API specification is suggested as the=20 preferred IMS data channel API. RTCPeerConnection , RTCDataChannel object, the callbacks need to be supported . Only data channel API related definitions are used and IMS data channel = API is not allowed to use WebRTC media. ICE/STUN/TURN are also not required. # Reference 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS GSMA NG.129_5G DATA CHANNEL _______________________________________________ rtcweb mailing list rtcweb@ietf.org =20 https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_001_01DB_01D7D5C3.D290E850 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Ted, = Harald,

 

I have some insight into that GSMA work that might = help the discussion.

The intent was = never to create or even suggest incompatible changes to WebRTC = protocols. Quite the opposite, the intent was to reuse WebRTC protocols, = which I believe is clear from other parts of that White Paper. The = suggested reuse of WebRTC data channel protocol stack is for 3GPP = IMS-native multimedia telephony, not intended to change the core of = WebRTC. It should be OK to use a data channel outside of WebRTC context = =E2=80=93 for example, like CLUE telepresence makes use of it. Also, = 3GPP previously defined WebRTC access to IMS through the use of a = gateway where ICE is used on the WebRTC side, but that is separate from = the GSMA case.

 

The GSMA = White Paper is mainly educational for that community, in this case = exploring possibilities with using WebRTC data channel media as part of = 5G phone calls. If GSMA members find this interesting enough, normative = work and specifications will follow but nothing is started = yet.

 

I believe the sentence Harald highlights below should = be interpreted from the perspective that ICE/STUN/TURN functionality is = strictly not needed in a telco operator=E2=80=99s network, since = connectivity is solved by other means in that context. That particular = sentence is likely not considering what requirements, e.g. use of ICE, = that may come from reuse of existing WebRTC protocol stacks. This aspect = must however be kept in mind as the work continues.

 

I hope that = helps.

 

Cheers,

Bo

 

From: = rtcweb <rtcweb-bounces@ietf.org> On Behalf Of Ted = Hardie
Sent: den 3 november 2021 14:10
To: Harald = Alvestrand <harald@alvestrand.no>
Cc: RTCWeb IETF = <rtcweb@ietf.org>
Subject: Re: [rtcweb] 5G standards = advocating WebRTC protocol violations?

 

Hi = Harald,

 

It is definitely = possible for us to send liaison statements via the appropriate channel, = but I am missing some context.  Can you provide a citation to the = document from which the excerpt comes?  (It appears to be labeled a = white paper, so the first step may be to confirm that its description = and the underlying specs say the same = thing.)

 

regards,

 

Ted = Hardie

 

On = Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no> = wrote:

It's come to my attention that there's = apparently some 5G spec that says
"Use WebRTC datachannel, but = don't bother with this ICE stuff".

The exact quote is = below.

Now I don't mind saying "don't use TURN/STUN = servers" - that's a
configuration option on the WEBRTC API, and = anyone can choose to not do
that - but I do mind leaving out ICE. An = ICE-supporting implementation
won't interwork properly with an = implementation that doesn't support ICE.

Is it possible for the = IETF to say "please don't make incompatible
changes to our = protocols without asking us"? (that's the version where I
try = not to use expletives).

Or is it possible that this is all a = misunderstanding, and the 5G folks
actually meant to require = peer-to-peer ICE, but just wrote it wrongly?

Or did I = misunderstand what the WG's intent was, and should just suck it
up = and interoperate with non-ICE-supporting = endpoints?

Harald

--------- Spec reference quote = ----------

1. Spec
NG.129 - 5G Data Channel White Paper  = (CR1001)

8.2.1Data channel APIs
The data channel application = consists of the device side logic and the
server side logic.
Both = should use standardized APIs that need to be agreed by the = industry.
W3C WebRTC1.0 data channel API specification is suggested = as the
preferred IMS data channel API. RTCPeerConnection = ,
RTCDataChannel object, the  callbacks need to be supported = .
Only data channel API related definitions  are used and IMS = data channel
API is not allowed to use WebRTC = media.
ICE/STUN/TURN are also not required.

# = Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and = interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging = over 5GS
GSMA NG.129_5G DATA = CHANNEL

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

------=_NextPart_001_01DB_01D7D5C3.D290E850-- ------=_NextPart_000_01DA_01D7D5C3.D290E850 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR4jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF3DCCA8SgAwIBAgIPAXVWFPODkdW317IdRU4oMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMjMxNTMwMTRaFw0yMzEwMjQxNTMw MTNaME4xETAPBgNVBAoMCEVyaWNzc29uMRIwEAYDVQQDDAlCbyBCdXJtYW4xJTAjBgkqhkiG9w0B CQEWFmJvLmJ1cm1hbkBlcmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDZjgGpWg3zVLAqmJw+ym9/UuzHvsAPGPoug8QqZvNhLURy5iIUkqt17g/2hINesXncbxyZxUOj viKkkQZt46xfTXA0ABuFhVn0yHBda/Cl61uc642ttqoUgouCeF7wtUCjSHzOFSFqIuWYcNgkfbBm 2JwTYiIDQOzZR0QD7Q2FX9718R3/K0NrjILzMUk3xTBlUMHN+y9cdn/B/mXKvJAX1pyndtrBxbZG /Ql0NdMcsowxJay2zmYfb0f/Kj8ArodzvHo5xw8KZAP5X5o0vYF5seYdgbgGAlIFCyWEKScoT9Du P5rJFpXN9t5dDfLo4MAvZ+91oOQ5tLnoBarI+eeRAgMBAAGjggG8MIIBuDAfBgNVHSMEGDAWgBQc exmel5x2rCA92NzjkWrj2y2mUzAdBgNVHQ4EFgQUHra05hxRd68Xe6CMWRxeAEeoCGQwDgYDVR0P AQH/BAQDAgWgMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBz Oi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMCEGA1UdEQQaMBiBFmJvLmJ1 cm1hbkBlcmljc3Nvbi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0 LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9l cmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQDGJup4QMdjP8Oc VobWxGnrRcLZza8XEFqMi+n3dpDIcQskRT1xFd48HsTzWgj1j4OF9QOzwgh8p7sFBM/p27Tbp28P yGPkCf+v6Yo3dKxmxfEA14u3T4Du7BQD8DBx+DB0z18lvFyUozca6kYCNgCPpliGetBLd5ewVCQV EpgnqNYyAsFGlN0ymYwF3x1w0uTdW6i3hIZIxo4+XprGq9Zoe3LXC0Yb/FZaNEgld+9FpboPgwkl BtiHhXMb7Bqd6izv/My24lmHvq51eu3DmyDRUPPnviq94P1HltW1ZlGRwRU0rVIGVqgU6R5WicDS ZJPKYiEkZ3YySP8ZoQcAxOvKd3UgyjV5hjAvmxOiUwjf2EhgSpbAP7O4CY3bEQO4x7I4PtCbjqSS NL2q6I5lEvlAUExY8MrsosTlqS1MuOtpQ0lOgp0wcqESq0K1fZeXHIEzXLin9pLeZKFEwTbiXD7a aDWWpcd6vLb1rLiaUxdF6r3YLvu+19sMsR7FElTFW4jdK/Wnw+72nHSiUJ6oF90D5MTCrCYuVOZG udUdUnToJIr0CVLDxiS+4NrPqr75GYOZ1357J6uZp8W6r9hc02g0igsn7yW12wadmPQwGUyyLPgF 0hE2Yf6H66p4ZszYQfPZ57Ase97pfUgU/kC0vOMmKEIESIIHVzWy0/24NKQGMjCCBsIwggSqoAMC AQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVy aWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkq UXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhV W4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAw qBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/ 8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC +zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8o LUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldv EtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4y hzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pA VwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3Au dHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB /wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRw Oi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7 GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqG SIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5Q taZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj 0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQy sshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx 6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtn gmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi +K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiB maz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP /Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvx OgftYug7OY9EKY+WkDGCA1AwggNMAgEBMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdVYU84OR1bfXsh1F TigwCQYFKw4DAhoFAKCCAcswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjExMTA5MjI0NTA1WjAjBgkqhkiG9w0BCQQxFgQUrLzmK+S65Oksq35CVnD6ZSv0R18waQYJ KwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwF1VhTzg5HVt9eyHUVOKDBrBgsqhkiG9w0B CRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmlj c3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdVYU84OR1bfXsh1FTigwgZMGCSqGSIb3DQEJDzGB hTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCG SAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAZMOlTZfRXWjVJKmKmSW/gjiy 0J3jbzYZhI38TCaOEFH1llai96RBU5xHWKD6Kv8zbrGS7HKWL2S1tsmhark6KQKUj/F7XRizwXkD Fln/Lx8ogMW7T5q7YqMwx3nHP3Irs4gpavviFIZJ8OFSqkHuTcFEvgTuGg8KwiiGvC7ksYH/f+Xq PXxz4fv0IbKvcaIelKYSFsXzy5GJVJbNCaEFDECFgC0N6bRwEwdbxgm90UICgxWZjtr/e6xXd17R 3mkFa8hcUf6T9P4LNbFSEq9AowzFTi8CyHHOxHPsGbws/1tv+zSsTMs6UxRH2iOG3Oy88Q8scy9x eGAB59TSgM96zQAAAAAAAA== ------=_NextPart_000_01DA_01D7D5C3.D290E850-- From nobody Wed Nov 10 00:40:08 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525233A081C for ; Wed, 10 Nov 2021 00:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.226 X-Spam-Level: X-Spam-Status: No, score=-5.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAas1SwXX99p for ; Wed, 10 Nov 2021 00:40:01 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08FE3A0811 for ; Wed, 10 Nov 2021 00:40:00 -0800 (PST) Received: from [192.168.3.157] (unknown [78.156.11.215]) by mork.alvestrand.no (Postfix) with ESMTPSA id 993F47C73DC; Wed, 10 Nov 2021 09:39:58 +0100 (CET) To: Bo Burman , Ted Hardie Cc: RTCWeb IETF References: From: Harald Alvestrand Message-ID: <8c8b1988-1c2a-eb6b-5f0a-c9412c6d8981@alvestrand.no> Date: Wed, 10 Nov 2021 09:39:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8FD5E7C7CC35E1CC76BED2AC" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 08:40:06 -0000 This is a multi-part message in MIME format. --------------8FD5E7C7CC35E1CC76BED2AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Bo! The specific problem I have is that a customer has requested that Chrome be modified to be able to operate without ICE, where the owner of the equipment in question is pointing to this particular sentence as justification for its request. If the sentence had said "Use of STUN and TURN servers are not required, and ICE-Lite can be used", that would have been no problem. Harald On 11/9/21 11:45 PM, Bo Burman wrote: > > Hi Ted, Harald, > > I have some insight into that GSMA work that might help the discussion. > > The intent was never to create or even suggest incompatible changes to > WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC > protocols, which I believe is clear from other parts of that White > Paper. The suggested reuse of WebRTC data channel protocol stack is > for 3GPP IMS-native multimedia telephony, not intended to change the > core of WebRTC. It should be OK to use a data channel outside of > WebRTC context – for example, like CLUE telepresence makes use of it. > Also, 3GPP previously defined WebRTC access to IMS through the use of > a gateway where ICE is used on the WebRTC side, but that is separate > from the GSMA case. > > The GSMA White Paper is mainly educational for that community, in this > case exploring possibilities with using WebRTC data channel media as > part of 5G phone calls. If GSMA members find this interesting enough, > normative work and specifications will follow but nothing is started yet. > > I believe the sentence Harald highlights below should be interpreted > from the perspective that ICE/STUN/TURN functionality is strictly not > needed in a telco operator’s network, since connectivity is solved by > other means in that context. That particular sentence is likely not > considering what requirements, e.g. use of ICE, that may come from > reuse of existing WebRTC protocol stacks. This aspect must however be > kept in mind as the work continues. > > I hope that helps. > > Cheers, > > Bo > > *From:* rtcweb *On Behalf Of *Ted Hardie > *Sent:* den 3 november 2021 14:10 > *To:* Harald Alvestrand > *Cc:* RTCWeb IETF > *Subject:* Re: [rtcweb] 5G standards advocating WebRTC protocol > violations? > > Hi Harald, > > It is definitely possible for us to send liaison statements via the > appropriate channel, but I am missing some context.  Can you provide a > citation to the document from which the excerpt comes?  (It appears to > be labeled a white paper, so the first step may be to confirm that its > description and the underlying specs say the same thing.) > > regards, > > Ted Hardie > > On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand > > wrote: > > It's come to my attention that there's apparently some 5G spec > that says > "Use WebRTC datachannel, but don't bother with this ICE stuff". > > The exact quote is below. > > Now I don't mind saying "don't use TURN/STUN servers" - that's a > configuration option on the WEBRTC API, and anyone can choose to > not do > that - but I do mind leaving out ICE. An ICE-supporting > implementation > won't interwork properly with an implementation that doesn't > support ICE. > > Is it possible for the IETF to say "please don't make incompatible > changes to our protocols without asking us"? (that's the version > where I > try not to use expletives). > > Or is it possible that this is all a misunderstanding, and the 5G > folks > actually meant to require peer-to-peer ICE, but just wrote it wrongly? > > Or did I misunderstand what the WG's intent was, and should just > suck it > up and interoperate with non-ICE-supporting endpoints? > > Harald > > --------- Spec reference quote ---------- > > 1. Spec > NG.129 - 5G Data Channel White Paper  (CR1001) > > 8.2.1Data channel APIs > The data channel application consists of the device side logic and > the > server side logic. > Both should use standardized APIs that need to be agreed by the > industry. > W3C WebRTC1.0 data channel API specification is suggested as the > preferred IMS data channel API. RTCPeerConnection , > RTCDataChannel object, the  callbacks need to be supported . > Only data channel API related definitions  are used and IMS data > channel > API is not allowed to use WebRTC media. > ICE/STUN/TURN are also not required. > > # Reference > 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction > GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS > GSMA NG.129_5G DATA CHANNEL > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------8FD5E7C7CC35E1CC76BED2AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks Bo!

The specific problem I have is that a customer has requested that Chrome be modified to be able to operate without ICE, where the owner of the equipment in question is pointing to this particular sentence as justification for its request.

If the sentence had said "Use of STUN and TURN servers are not required, and ICE-Lite can be used", that would have been no problem.

Harald

On 11/9/21 11:45 PM, Bo Burman wrote:

Hi Ted, Harald,

 

I have some insight into that GSMA work that might help the discussion.

The intent was never to create or even suggest incompatible changes to WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC protocols, which I believe is clear from other parts of that White Paper. The suggested reuse of WebRTC data channel protocol stack is for 3GPP IMS-native multimedia telephony, not intended to change the core of WebRTC. It should be OK to use a data channel outside of WebRTC context – for example, like CLUE telepresence makes use of it. Also, 3GPP previously defined WebRTC access to IMS through the use of a gateway where ICE is used on the WebRTC side, but that is separate from the GSMA case.

 

The GSMA White Paper is mainly educational for that community, in this case exploring possibilities with using WebRTC data channel media as part of 5G phone calls. If GSMA members find this interesting enough, normative work and specifications will follow but nothing is started yet.

 

I believe the sentence Harald highlights below should be interpreted from the perspective that ICE/STUN/TURN functionality is strictly not needed in a telco operator’s network, since connectivity is solved by other means in that context. That particular sentence is likely not considering what requirements, e.g. use of ICE, that may come from reuse of existing WebRTC protocol stacks. This aspect must however be kept in mind as the work continues.

 

I hope that helps.

 

Cheers,

Bo

 

From: rtcweb <rtcweb-bounces@ietf.org> On Behalf Of Ted Hardie
Sent: den 3 november 2021 14:10
To: Harald Alvestrand <harald@alvestrand.no>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

 

Hi Harald,

 

It is definitely possible for us to send liaison statements via the appropriate channel, but I am missing some context.  Can you provide a citation to the document from which the excerpt comes?  (It appears to be labeled a white paper, so the first step may be to confirm that its description and the underlying specs say the same thing.)

 

regards,

 

Ted Hardie

 

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no> wrote:

It's come to my attention that there's apparently some 5G spec that says
"Use WebRTC datachannel, but don't bother with this ICE stuff".

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - that's a
configuration option on the WEBRTC API, and anyone can choose to not do
that - but I do mind leaving out ICE. An ICE-supporting implementation
won't interwork properly with an implementation that doesn't support ICE.

Is it possible for the IETF to say "please don't make incompatible
changes to our protocols without asking us"? (that's the version where I
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks
actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck it
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper  (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the
server side logic.
Both should use standardized APIs that need to be agreed by the industry.
W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the  callbacks need to be supported .
Only data channel API related definitions  are used and IMS data channel
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

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

--------------8FD5E7C7CC35E1CC76BED2AC-- From nobody Wed Nov 10 02:10:20 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61983A0CD2 for ; Wed, 10 Nov 2021 02:10:17 -0800 (PST) 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 ZjTrZpBh7lxf for ; Wed, 10 Nov 2021 02:10:12 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 7F29D3A0CCE for ; Wed, 10 Nov 2021 02:10:12 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id x9so1891170ilu.6 for ; Wed, 10 Nov 2021 02:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gdzIzhJMg5jazIjJNs2AMkgp6dikmpQeIsbozrCmdJc=; b=nbgillspbemMoNv/xCuwU97ZzuG7u+Dn1/06UwbzrXlfCFsmF2wiFrjJs0A3fU1SCe MCFPxx1fXtDMiYUpm7ibXYcsIwDJw/uBSjUJ1uuK3qB/UlSMK4N7Ma8c3J8to6f8dbyE XydE+baTMms4fwX2p4hacrJetjdlme0SJ0y/OKf7M1Wb4JB+VlK2mYnOnnsC+sVxTBpp dXOAPNhl/2FHukAq8W6d5rcaU9PLWgUbNYCWmbXu+lcPrX7c+0bWhgeUMu6tnFJ5j01P cqx6vBxtY9vFdNC2RdStPwirCN709HcWc3TcOnWLmehq1TqCyiEPG9vIxXHY1z0InfDD LQgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gdzIzhJMg5jazIjJNs2AMkgp6dikmpQeIsbozrCmdJc=; b=BktzEofaM1qlm4HtnPu90AvrT5wJl/esTbA5wIuuy0xt5coenXBynmtNOUb+m0oWHy rV0FaO2OV/CiUYNBqGLxajRYc2WldCcJrIQPCxNknz4vZY/A9NaGknXq9OyFztGlZRB7 0aF/3BJm12HI10TWrXBw9QO1OM8PMeqYNYnHudB5+6SKUP1gpVi6f7/RJ95QObKxF1hG RSPtUf9gvxi6eUMlSoQmLBIXGg+uH8urrysWcVplLWpkIsTLEGgt5ts6Tpoy7CTmkRBw 8DyZjjtd3pZZDVy/2W0MYlC+quwpwPa6lIvgJ6qYdIBVqehLdjPOwgz2PXhJZ7U1RYVe p/pA== X-Gm-Message-State: AOAM531aueiKWMgKq9WelimwooYsTK9ZmwI1pZf17jYmC+SVyoY+AuH5 KPfPSOOam+iKOFE6kQCtzsgWwtdLuahe0EJU0SI= X-Google-Smtp-Source: ABdhPJxpr0GeNr6VOr17MQ8WtQ1ghGfL+LmPtNOYxyRbGnNBTc2Af9JLLjbq4mFRU/C8ywnyRUILrE1lGTmtxqJefXU= X-Received: by 2002:a05:6e02:144b:: with SMTP id p11mr10119769ilo.70.1636539010851; Wed, 10 Nov 2021 02:10:10 -0800 (PST) MIME-Version: 1.0 References: <8c8b1988-1c2a-eb6b-5f0a-c9412c6d8981@alvestrand.no> In-Reply-To: <8c8b1988-1c2a-eb6b-5f0a-c9412c6d8981@alvestrand.no> From: Ted Hardie Date: Wed, 10 Nov 2021 10:09:43 +0000 Message-ID: To: Harald Alvestrand Cc: Bo Burman , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000006726b305d06c6e27" Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 10:10:18 -0000 --0000000000006726b305d06c6e27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Harald, Bo, Thanks to you both for the clarifications. It seems to me, in light of this, that the working group probably does not need to draft a liaison statement and that this can be worked out simply using the explanatory email that Bo provided. If that is not the case, I'd appreciate a clearer statement of what would be required. thanks, Ted Hardie On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand wrote: > Thanks Bo! > > The specific problem I have is that a customer has requested that Chrome > be modified to be able to operate without ICE, where the owner of the > equipment in question is pointing to this particular sentence as > justification for its request. > > If the sentence had said "Use of STUN and TURN servers are not required, > and ICE-Lite can be used", that would have been no problem. > > Harald > On 11/9/21 11:45 PM, Bo Burman wrote: > > Hi Ted, Harald, > > > > I have some insight into that GSMA work that might help the discussion. > > The intent was never to create or even suggest incompatible changes to > WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC > protocols, which I believe is clear from other parts of that White Paper. > The suggested reuse of WebRTC data channel protocol stack is for 3GPP > IMS-native multimedia telephony, not intended to change the core of WebRT= C. > It should be OK to use a data channel outside of WebRTC context =E2=80=93= for > example, like CLUE telepresence makes use of it. Also, 3GPP previously > defined WebRTC access to IMS through the use of a gateway where ICE is us= ed > on the WebRTC side, but that is separate from the GSMA case. > > > > The GSMA White Paper is mainly educational for that community, in this > case exploring possibilities with using WebRTC data channel media as part > of 5G phone calls. If GSMA members find this interesting enough, normativ= e > work and specifications will follow but nothing is started yet. > > > > I believe the sentence Harald highlights below should be interpreted from > the perspective that ICE/STUN/TURN functionality is strictly not needed i= n > a telco operator=E2=80=99s network, since connectivity is solved by other= means in > that context. That particular sentence is likely not considering what > requirements, e.g. use of ICE, that may come from reuse of existing WebRT= C > protocol stacks. This aspect must however be kept in mind as the work > continues. > > > > I hope that helps. > > > > Cheers, > > Bo > > > > *From:* rtcweb *On > Behalf Of *Ted Hardie > *Sent:* den 3 november 2021 14:10 > *To:* Harald Alvestrand > *Cc:* RTCWeb IETF > *Subject:* Re: [rtcweb] 5G standards advocating WebRTC protocol > violations? > > > > Hi Harald, > > > > It is definitely possible for us to send liaison statements via the > appropriate channel, but I am missing some context. Can you provide a > citation to the document from which the excerpt comes? (It appears to be > labeled a white paper, so the first step may be to confirm that its > description and the underlying specs say the same thing.) > > > > regards, > > > > Ted Hardie > > > > On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand > wrote: > > It's come to my attention that there's apparently some 5G spec that says > "Use WebRTC datachannel, but don't bother with this ICE stuff". > > The exact quote is below. > > Now I don't mind saying "don't use TURN/STUN servers" - that's a > configuration option on the WEBRTC API, and anyone can choose to not do > that - but I do mind leaving out ICE. An ICE-supporting implementation > won't interwork properly with an implementation that doesn't support ICE. > > Is it possible for the IETF to say "please don't make incompatible > changes to our protocols without asking us"? (that's the version where I > try not to use expletives). > > Or is it possible that this is all a misunderstanding, and the 5G folks > actually meant to require peer-to-peer ICE, but just wrote it wrongly? > > Or did I misunderstand what the WG's intent was, and should just suck it > up and interoperate with non-ICE-supporting endpoints? > > Harald > > --------- Spec reference quote ---------- > > 1. Spec > NG.129 - 5G Data Channel White Paper (CR1001) > > 8.2.1Data channel APIs > The data channel application consists of the device side logic and the > server side logic. > Both should use standardized APIs that need to be agreed by the industry. > W3C WebRTC1.0 data channel API specification is suggested as the > preferred IMS data channel API. RTCPeerConnection , > RTCDataChannel object, the callbacks need to be supported . > Only data channel API related definitions are used and IMS data channel > API is not allowed to use WebRTC media. > ICE/STUN/TURN are also not required. > > # Reference > 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction > GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS > GSMA NG.129_5G DATA CHANNEL > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0000000000006726b305d06c6e27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi = Harald, Bo,
Thanks to you= both for the clarifications.=C2=A0 It seems to me, in light of this, that = the working group probably does not need to draft a liaison statement and t= hat this can be worked out simply using the explanatory email that Bo provi= ded.=C2=A0 If that is not the case, I'd appreciate a clearer statement = of what would be required.

thanks,

<= /div>
Ted Hardie
<= /div>

On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20

Thanks Bo!

The specific problem I have is that a customer has requested that Chrome be modified to be able to operate without ICE, where the owner of the equipment in question is pointing to this particular sentence as justification for its request.

If the sentence had said "Use of STUN and TURN servers are not required, and ICE-Lite can be used", that would have been no problem.

Harald

On 11/9/21 11:45 PM, Bo Burman wrote:
=20 =20 =20

Hi Ted, Harald,

=C2=A0

I have some insight into that GSMA work that might help the discussion.

The intent was never to create or even suggest incompatible changes to WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC protocols, which I believe is clear from other parts of that White Paper. The suggested reuse of WebRTC data channel protocol stack is for 3GPP IMS-native multimedia telephony, not intended to change the core of WebRTC. It should be OK to use a data channel outside of WebRTC context =E2=80=93 for example, like CLUE telepresence makes use of it. Also, 3GPP previously defined WebRTC access to IMS through the use of a gateway where ICE is used on the WebRTC side, but that is separate from the GSMA case.

=C2=A0

The GSMA White Paper is mainly educational for that community, in this case exploring possibilities with using WebRTC data channel media as part of 5G phone calls. If GSMA members find this interesting enough, normative work and specifications will follow but nothing is started yet.<= /u>

=C2=A0

I believe the sentence Harald highlights below should be interpreted from the perspective that ICE/STUN/TURN functionality is strictly not needed in a telco operator=E2=80=99s network, since connectivity is solved by other means in that context. That particular sentence is likely not considering what requirements, e.g. use of ICE, that may come from reuse of existing WebRTC protocol stacks. This aspect must however be kept in mind as the work continues.=

=C2=A0

I hope that helps.

=C2=A0

Cheers,

Bo

=C2=A0

From: rtcweb <rtcweb-bounces@ietf.org> On Behalf Of Ted Hardie
Sent: den 3 november 2021 14:10
To: Harald Alvestrand &= lt;harald@alvestrand.no>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

=C2=A0

Hi Harald,

=C2=A0

It is definitely possible for us to send liaison statements via the appropriate channel, but I am missing some context.=C2=A0 Can you provide a citation = to the document from which the excerpt comes?=C2=A0 (It appears to be labeled a white paper, so the first step may be to confirm that its description and the underlying specs say the same thing.)

=C2=A0

regar= ds,

=C2=A0

Ted Hardie

=C2=A0

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no> wrote:

It's come to my attention that there's apparently some 5G spec that says
"Use WebRTC datachannel, but don't bother with t= his ICE stuff".

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN= servers" - that's a
configuration option on the WEBRTC API, and anyone can choose to not do
that - but I do mind leaving out ICE. An ICE-supporting implementation
won't interwork properly with an implementation that doesn't support ICE.

Is it possible for the IETF to say "please don't= make incompatible
changes to our protocols without asking us"? (that&#= 39;s the version where I
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks
actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck it
up and interoperate with non-ICE-supporting endpoints?
Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper=C2=A0 (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the
server side logic.
Both should use standardized APIs that need to be agreed by the industry.
W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the=C2=A0 callbacks need to be supported .
Only data channel API related definitions=C2=A0 are used and IMS data channel
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

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

--0000000000006726b305d06c6e27-- From nobody Wed Nov 10 02:17:30 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CD83A0CF0 for ; Wed, 10 Nov 2021 02:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAj7tvEFZhxE for ; Wed, 10 Nov 2021 02:17:24 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 6C3DE3A0CEE for ; Wed, 10 Nov 2021 02:17:22 -0800 (PST) Received: (qmail 35937 invoked from network); 10 Nov 2021 10:17:19 -0000 X-APM-Out-ID: 16365394393593 X-APM-Authkey: 255286/0(159927/0) 252 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 10 Nov 2021 10:17:19 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id AF5C2810AE; Wed, 10 Nov 2021 10:17:19 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8r-2RgRNoNKZ; Wed, 10 Nov 2021 10:17:19 +0000 (GMT) Received: from phage-rock.fritz.box (p548c8baa.dip0.t-ipconnect.de [84.140.139.170]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7667A810AA; Wed, 10 Nov 2021 10:17:19 +0000 (GMT) From: westhawk Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0FEAE610-F071-410A-B8FC-934F1563DC8A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 10 Nov 2021 11:17:10 +0100 In-Reply-To: Cc: RTCWeb IETF , Ted Hardie To: Harald Alvestrand References: <8c8b1988-1c2a-eb6b-5f0a-c9412c6d8981@alvestrand.no> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 10:17:28 -0000 --Apple-Mail=_0FEAE610-F071-410A-B8FC-934F1563DC8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is (perhaps) a subclass on an interesting situation, where the 5g = network spins up a new bearer channel with an interface which is = effectively a VPN to the far end. This obviates ICE, also they probably don=E2=80=99t want Chrome to be = able to talk to the far end :-) Tim (who spent too long in Telcoland)=20 > On 10 Nov 2021, at 11:09, Ted Hardie wrote: >=20 > Hi Harald, Bo, >=20 > Thanks to you both for the clarifications. It seems to me, in light = of this, that the working group probably does not need to draft a = liaison statement and that this can be worked out simply using the = explanatory email that Bo provided. If that is not the case, I'd = appreciate a clearer statement of what would be required. >=20 > thanks, >=20 > Ted Hardie >=20 > On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand = > wrote: > Thanks Bo! >=20 > The specific problem I have is that a customer has requested that = Chrome be modified to be able to operate without ICE, where the owner of = the equipment in question is pointing to this particular sentence as = justification for its request. >=20 > If the sentence had said "Use of STUN and TURN servers are not = required, and ICE-Lite can be used", that would have been no problem. >=20 > Harald >=20 > On 11/9/21 11:45 PM, Bo Burman wrote: >> Hi Ted, Harald, >>=20 >> =20 >>=20 >> I have some insight into that GSMA work that might help the = discussion. >>=20 >> The intent was never to create or even suggest incompatible changes = to WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC = protocols, which I believe is clear from other parts of that White = Paper. The suggested reuse of WebRTC data channel protocol stack is for = 3GPP IMS-native multimedia telephony, not intended to change the core of = WebRTC. It should be OK to use a data channel outside of WebRTC context = =E2=80=93 for example, like CLUE telepresence makes use of it. Also, = 3GPP previously defined WebRTC access to IMS through the use of a = gateway where ICE is used on the WebRTC side, but that is separate from = the GSMA case. >>=20 >> =20 >>=20 >> The GSMA White Paper is mainly educational for that community, in = this case exploring possibilities with using WebRTC data channel media = as part of 5G phone calls. If GSMA members find this interesting enough, = normative work and specifications will follow but nothing is started = yet. >>=20 >> =20 >>=20 >> I believe the sentence Harald highlights below should be interpreted = from the perspective that ICE/STUN/TURN functionality is strictly not = needed in a telco operator=E2=80=99s network, since connectivity is = solved by other means in that context. That particular sentence is = likely not considering what requirements, e.g. use of ICE, that may come = from reuse of existing WebRTC protocol stacks. This aspect must however = be kept in mind as the work continues. >>=20 >> =20 >>=20 >> I hope that helps. >>=20 >> =20 >>=20 >> Cheers, >>=20 >> Bo >>=20 >> =20 >>=20 >> From: rtcweb = On Behalf Of Ted Hardie >> Sent: den 3 november 2021 14:10 >> To: Harald Alvestrand = >> Cc: RTCWeb IETF >> Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol = violations? >>=20 >> =20 >>=20 >> Hi Harald, >>=20 >> =20 >>=20 >> It is definitely possible for us to send liaison statements via the = appropriate channel, but I am missing some context. Can you provide a = citation to the document from which the excerpt comes? (It appears to = be labeled a white paper, so the first step may be to confirm that its = description and the underlying specs say the same thing.) >>=20 >> =20 >>=20 >> regards, >>=20 >> =20 >>=20 >> Ted Hardie >>=20 >> =20 >>=20 >> On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand = > wrote: >>=20 >> It's come to my attention that there's apparently some 5G spec that = says=20 >> "Use WebRTC datachannel, but don't bother with this ICE stuff". >>=20 >> The exact quote is below. >>=20 >> Now I don't mind saying "don't use TURN/STUN servers" - that's a=20 >> configuration option on the WEBRTC API, and anyone can choose to not = do=20 >> that - but I do mind leaving out ICE. An ICE-supporting = implementation=20 >> won't interwork properly with an implementation that doesn't support = ICE. >>=20 >> Is it possible for the IETF to say "please don't make incompatible=20 >> changes to our protocols without asking us"? (that's the version = where I=20 >> try not to use expletives). >>=20 >> Or is it possible that this is all a misunderstanding, and the 5G = folks=20 >> actually meant to require peer-to-peer ICE, but just wrote it = wrongly? >>=20 >> Or did I misunderstand what the WG's intent was, and should just suck = it=20 >> up and interoperate with non-ICE-supporting endpoints? >>=20 >> Harald >>=20 >> --------- Spec reference quote ---------- >>=20 >> 1. Spec >> NG.129 - 5G Data Channel White Paper (CR1001) >>=20 >> 8.2.1Data channel APIs >> The data channel application consists of the device side logic and = the=20 >> server side logic. >> Both should use standardized APIs that need to be agreed by the = industry. >> W3C WebRTC1.0 data channel API specification is suggested as the=20 >> preferred IMS data channel API. RTCPeerConnection , >> RTCDataChannel object, the callbacks need to be supported . >> Only data channel API related definitions are used and IMS data = channel=20 >> API is not allowed to use WebRTC media. >> ICE/STUN/TURN are also not required. >>=20 >> # Reference >> 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and = interaction >> GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS >> GSMA NG.129_5G DATA CHANNEL >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = ____________________________= ___________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_0FEAE610-F071-410A-B8FC-934F1563DC8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is (perhaps) a subclass on an interesting situation, where the 5g = network spins up a new bearer channel with an interface which is = effectively a VPN to the far end.
This obviates ICE, also = they probably don=E2=80=99t want Chrome to be able to talk to the far = end :-)

Tim = (who spent too long in Telcoland) 

On 10 = Nov 2021, at 11:09, Ted Hardie <ted.ietf@gmail.com> wrote:

Hi = Harald, Bo,

Thanks to you both for = the clarifications.  It seems to me, in light of this, that the = working group probably does not need to draft a liaison statement and = that this can be worked out simply using the explanatory email that Bo = provided.  If that is not the case, I'd appreciate a clearer = statement of what would be required.

thanks,

Ted Hardie

On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand = <harald@alvestrand.no> wrote:
=20 =20 =20

Thanks Bo!

The specific = problem I have is that a customer has requested that Chrome be modified to be able to operate without ICE, where the owner of the equipment in question is pointing to this particular sentence as justification for its request.

If the sentence had said "Use of STUN and TURN = servers are not required, and ICE-Lite can be used", that would have been no problem.

Harald

On 11/9/21 11:45 PM, Bo Burman wrote:
=20 =20 =20

Hi Ted, Harald,

 

I have = some insight into that GSMA work that might help the discussion.

The intent was never to create = or even suggest incompatible changes to WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC protocols, which I believe is clear from other parts of that White Paper. The suggested reuse of WebRTC data channel protocol stack is for 3GPP IMS-native multimedia telephony, not intended to change the core of WebRTC. It should be OK to use a data channel outside of WebRTC context =E2=80=93 for example, like CLUE telepresence makes use of it. Also, 3GPP previously defined WebRTC access to IMS through the use of a gateway where ICE is used on the WebRTC side, but that is separate from the GSMA case.

 

The GSMA White Paper is mainly educational for that community, in this case exploring possibilities with using WebRTC data channel media as part of 5G phone calls. If GSMA members find this interesting enough, normative work and specifications will follow but nothing is started yet.

 

I = believe the sentence Harald highlights below should be interpreted from the perspective that ICE/STUN/TURN functionality is strictly not needed in a telco operator=E2=80=99s network, since connectivity is solved by = other means in that context. That particular sentence is likely not considering what requirements, e.g. use of ICE, that may come from reuse of existing WebRTC protocol stacks. This aspect must however be kept in mind as the work continues.

 

I hope = that helps.

 

Cheers,

Bo

 

From: rtcweb <rtcweb-bounces@ietf.org> On Behalf Of Ted Hardie
Sent: den 3 november 2021 14:10
To: Harald Alvestrand <harald@alvestrand.no>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] 5G standards = advocating WebRTC protocol violations?

 

Hi Harald,

=

 

It is definitely possible for us to send liaison statements via the appropriate channel, but I am missing some context.  Can you provide a = citation to the document from which the excerpt comes?  (It appears to be labeled a white paper, so the first step may be to confirm that its description and the underlying specs say the same thing.)

 

regards,

 

Ted Hardie

 

On Wed, Nov 3, 2021 = at 11:37 AM Harald Alvestrand <harald@alvestrand.no> wrote:

It's = come to my attention that there's apparently some 5G spec that says
"Use WebRTC datachannel, but don't bother with this ICE stuff".

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - that's a
configuration option on the WEBRTC API, and anyone can choose to not do
that - but I do mind leaving out ICE. An ICE-supporting implementation
won't interwork properly with an implementation that doesn't support ICE.

Is it possible for the IETF to say "please don't make incompatible
changes to our protocols without asking us"? (that's the version where I
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks
actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck it
up and interoperate with non-ICE-supporting = endpoints?

Harald

--------- Spec reference quote ----------
=
1. Spec
NG.129 - 5G Data Channel White Paper  (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the
server side logic.
Both should use standardized APIs that need to be agreed by the industry.
W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the  callbacks need to be supported .
Only data channel API related definitions  are = used and IMS data channel
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

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

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

= --Apple-Mail=_0FEAE610-F071-410A-B8FC-934F1563DC8A-- From nobody Wed Nov 10 06:32:15 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCE23A1073 for ; Wed, 10 Nov 2021 06:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRR4RSvwzL5H for ; Wed, 10 Nov 2021 06:32:09 -0800 (PST) Received: from smtp104.ord1c.emailsrvr.com (smtp104.ord1c.emailsrvr.com [108.166.43.104]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266FD3A104E for ; Wed, 10 Nov 2021 06:32:09 -0800 (PST) X-Auth-ID: fluffy@iii.ca Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A7D72A01AD; Wed, 10 Nov 2021 09:32:07 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D849D571-B740-4F5F-BEEA-F67FF317586C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Cullen Jennings In-Reply-To: Date: Wed, 10 Nov 2021 07:32:06 -0700 Cc: RTCWeb IETF Message-Id: References: To: Roman Shpount X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Classification-ID: 9bf25321-c1d3-45c5-a3ef-8e295dcacda9-1-1 Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 14:32:15 -0000 --Apple-Mail=_D849D571-B740-4F5F-BEEA-F67FF317586C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree we need the consent checks that ICE provided but I think ICE = Lite still provided the checks that provide the consent to receive = packets property.=20 > On Nov 9, 2021, at 1:49 PM, Roman Shpount wrote: >=20 > I would advise against ICE-lite. One of the things that ICE provides = is consent to send media. ICE-lite does not have this. Getting consent = is important to avoid using endpoints for DDOS attacks, so it is a = matter of security. >=20 > If they want to simplify things, they can use host candidates only, = which will make the ICE state machine trivial. > _____________ > Roman Shpount >=20 >=20 > On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings > wrote: >=20 > We might want to say if you don=E2=80=99t want to do any of the ICE = nightmare, ICE Lite is the best way to not do it and still have = interoperability. Do we know someone working on this at 5G that can = help provide more guidance ? >=20 >=20 >=20 >> On Nov 3, 2021, at 7:10 AM, Ted Hardie > wrote: >>=20 >> Hi Harald, >>=20 >> It is definitely possible for us to send liaison statements via the = appropriate channel, but I am missing some context. Can you provide a = citation to the document from which the excerpt comes? (It appears to = be labeled a white paper, so the first step may be to confirm that its = description and the underlying specs say the same thing.) >>=20 >> regards, >>=20 >> Ted Hardie >>=20 >> On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand = > wrote: >> It's come to my attention that there's apparently some 5G spec that = says=20 >> "Use WebRTC datachannel, but don't bother with this ICE stuff". >>=20 >> The exact quote is below. >>=20 >> Now I don't mind saying "don't use TURN/STUN servers" - that's a=20 >> configuration option on the WEBRTC API, and anyone can choose to not = do=20 >> that - but I do mind leaving out ICE. An ICE-supporting = implementation=20 >> won't interwork properly with an implementation that doesn't support = ICE. >>=20 >> Is it possible for the IETF to say "please don't make incompatible=20 >> changes to our protocols without asking us"? (that's the version = where I=20 >> try not to use expletives). >>=20 >> Or is it possible that this is all a misunderstanding, and the 5G = folks=20 >> actually meant to require peer-to-peer ICE, but just wrote it = wrongly? >>=20 >> Or did I misunderstand what the WG's intent was, and should just suck = it=20 >> up and interoperate with non-ICE-supporting endpoints? >>=20 >> Harald >>=20 >> --------- Spec reference quote ---------- >>=20 >> 1. Spec >> NG.129 - 5G Data Channel White Paper (CR1001) >>=20 >> 8.2.1Data channel APIs >> The data channel application consists of the device side logic and = the=20 >> server side logic. >> Both should use standardized APIs that need to be agreed by the = industry. >> W3C WebRTC1.0 data channel API specification is suggested as the=20 >> preferred IMS data channel API. RTCPeerConnection , >> RTCDataChannel object, the callbacks need to be supported . >> Only data channel API related definitions are used and IMS data = channel=20 >> API is not allowed to use WebRTC media. >> ICE/STUN/TURN are also not required. >>=20 >> # Reference >> 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and = interaction >> GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS >> GSMA NG.129_5G DATA CHANNEL >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_D849D571-B740-4F5F-BEEA-F67FF317586C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I =  agree we need the consent checks that ICE provided but I think ICE = Lite still provided the checks that provide the consent to receive = packets property. 

On Nov 9, 2021, at 1:49 PM, = Roman Shpount <roman@telurix.com> wrote:

I would advise against ICE-lite. One of the things that ICE = provides is consent to send media. ICE-lite does not have this. Getting = consent is important to avoid using endpoints for DDOS attacks, so it is = a matter of security.

If they want to simplify things, they can use host candidates = only, which will make the ICE state machine trivial.
_____________
Roman = Shpount


On Tue, Nov = 9, 2021 at 3:38 PM Cullen Jennings <fluffy@iii.ca> wrote:

We might = want to say if you don=E2=80=99t want to do any of the ICE nightmare, = ICE Lite is the best way to not do it and still have = interoperability.  Do we know someone working on this at 5G that = can help provide more guidance ?



On Nov 3, 2021, at 7:10 AM, Ted = Hardie <ted.ietf@gmail.com> wrote:

Hi Harald,

It= is definitely possible for us to send liaison statements via the = appropriate channel, but I am missing some context.  Can you = provide a citation to the document from which the excerpt comes?  = (It appears to be labeled a white paper, so the first step may be to = confirm that its description and the underlying specs say the same = thing.)

regards,

Ted Hardie

On Wed, Nov 3, 2021 at 11:37 AM Harald = Alvestrand <harald@alvestrand.no> wrote:
It's come to my attention that = there's apparently some 5G spec that says
"Use WebRTC datachannel, but don't bother with this ICE stuff".

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - that's a
configuration option on the WEBRTC API, and anyone can choose to not do =
that - but I do mind leaving out ICE. An ICE-supporting implementation =
won't interwork properly with an implementation that doesn't support = ICE.

Is it possible for the IETF to say "please don't make incompatible
changes to our protocols without asking us"? (that's the version where I =
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks =
actually meant to require peer-to-peer ICE, but just wrote it = wrongly?

Or did I misunderstand what the WG's intent was, and should just suck it =
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper  (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the =
server side logic.
Both should use standardized APIs that need to be agreed by the = industry.
W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the  callbacks need to be supported .
Only data channel API related definitions  are used and IMS data = channel
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and = interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

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

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

= --Apple-Mail=_D849D571-B740-4F5F-BEEA-F67FF317586C-- From nobody Wed Nov 10 06:37:09 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD98F3A1073 for ; Wed, 10 Nov 2021 06:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 LK0jf_BtGhF6 for ; Wed, 10 Nov 2021 06:37:01 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on061f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::61f]) (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 4599E3A1045 for ; Wed, 10 Nov 2021 06:37:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OoH7gSCKh6EF+kiRKRf1mwLU8R0ILpIOef0cjUcXosyiJYRfk9lYwVzEAEddoAhWBu5tm/h9EbniGSzMu9ivInC+lxDLsByGt6J9VT2lekzHQC0+vd1dLqzopidSiPJK4syA/UQRStJHMpcBpq2jFZ96EN0D/ywNMcWZElw4G1Q7gAAeKPDeRVlFKGMzpGkK327wJKl27nQ8EDBYPA/t8YA1xz3+GcNYuXw/8t2VGbRtI7rrXgNLE7OHWV6YShSMcBqVXX5oUm8XhtRoKObW/jR19KW6cS33UiqJ7DZY96opxgMlZe3pCDwxQcT7kl0Cpe2q3DjXxPkTDi0Age088A== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qx7qf2wD4ucU2810K/Is6PzOoEM9i9PNrLACjp075WA=; b=CawhIOdYc6hFJcFrceWhOvBgVcKNpNhoScYm5+oAeQe61U2e0MfA/UhO/r4p4LXczeR4+Ai+ZJRQG0i1gSqpHf76uc/hn4vu3dQ2VtGZuFSXVF0QoEkusVFXCsH3gSvJINJT++IEl0z+qj5R51qr2pyuwhAb9Ix/BgjcPWH98gY8L79tPkBYOPGpzq0w+RMyBp5GgSE/Sc+F20yi99J1DQuCi5AwhFxGmb0LeSrsivYtQpKFXmQ5r+7IDYhF4qTXwEEmk4jN705iSQuAdWgDpSKWDazu8AUndOp4Y4ndqow5nJZMOkrsffQ6sAUs2nK8CnnhRQ54vNwDuyf3N3ukmw== 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=qx7qf2wD4ucU2810K/Is6PzOoEM9i9PNrLACjp075WA=; b=aeQaxdzxBko7ZEpPEP2DE3ZZOMroeGzmjxe/qToQMH/iJnheq8dzBYumNUVCe46dqU231WZNx4qh5LLhuoqbMtrM7uvitAlzqDTYZ/DYgVW8DZthOmch/VIn1N5qQMZOnW27c1Low+wgOcXMv2IXY+ufPXfjq8R52iS0AW+tjlU= Received: from HE1PR07MB3403.eurprd07.prod.outlook.com (2603:10a6:7:32::25) by HE1PR07MB3369.eurprd07.prod.outlook.com (2603:10a6:7:30::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.14; Wed, 10 Nov 2021 14:36:56 +0000 Received: from HE1PR07MB3403.eurprd07.prod.outlook.com ([fe80::4c9f:2388:31aa:af0e]) by HE1PR07MB3403.eurprd07.prod.outlook.com ([fe80::4c9f:2388:31aa:af0e%7]) with mapi id 15.20.4690.016; Wed, 10 Nov 2021 14:36:56 +0000 From: Bo Burman To: westhawk , Harald Alvestrand CC: RTCWeb IETF Thread-Topic: [rtcweb] 5G standards advocating WebRTC protocol violations? Thread-Index: AQHX0KdAAYfD9gxH+U6UWkCWLMimFavxxvYAgAe6/ZCAAvnUAIAAGROAgAACFQCAADwLcA== Date: Wed, 10 Nov 2021 14:36:56 +0000 Message-ID: References: <8c8b1988-1c2a-eb6b-5f0a-c9412c6d8981@alvestrand.no> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d4d464c-9299-44e1-63d4-08d9a4578bbc x-ms-traffictypediagnostic: HE1PR07MB3369: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:220; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Eh+o1/2PhivVN6Q12Sfay+CS2zzoqqC1prZLPNjfaz3hslhGhFVXE+ZmdV81BmHCNy4lY/KpHtaGaVm7opPL3pvtjO7Cv2CFAQY1/GJG87EYa59i8TvaebkwHMvXV/WZlFSEjRHaqDBeMkJtWXCT/PcO7/XIP57zlxQ7NCuZSNmmooQ+U4g6jFydb8kUc9B0YRbb3DYGt5/e8RnaCe02iZG9ePvC9SQI/aM2ov4pg9q+rUfJ+9Oo2b89nNbdi3IKXQwD0nd5a4rnBemnYkP1FcqsbxXt2wLbBAEblFxdWZT2+Fw64GavmLYcTYmSedQ5L/Bv/S3Jj6oHxreuH9RmM/uRdQMbZ2/pNO3EfcIjyYR/a6m80wy85vhsHfaWNm8e7rfwgbJccNJkW5tLj2nxKs32kBtn8GHFWnNKtNj4eOVIAbJAcL+9/Fc+EzP1EyA6KKQ37VHQsuFSts2RRahusnA2zcFl0W5N0woG86sh7P2N2H0EM6xBMFoGxrBpcgp7DSImXDCOr+UiOvD00sO9JDLKSecelUKX8igtfB6Zx6zgbaxe4ctN0Ib6UClK2EbRZFrfuXKpoMz8TFiyjuPbJKZ0WrjKyVBGMLfc5KNZjyDcWYqTJkoNlTwMgaCkzp4eorsJbZuecIRea0jL5pUBt5YopYvzoDrKOh/OWKfglx2kAdrZGd2uXbOXJ5LS0zp2RU8oo3aUOvPUyMArK8/J6rbhbWolkQLCg4v6umtjrDVB5LDrOzWR1Z9xWxIy7+bguNDLAmFbrgojo2u98nMSKd5aetifQHRbNZgRmV0yh0tJyGTj2GB1olV7aizrz36x30iCS0JW/SOGk4ZYGdaoXA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3403.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(7696005)(64756008)(66446008)(966005)(66556008)(38100700002)(122000001)(9686003)(8936002)(508600001)(33656002)(166002)(44832011)(66476007)(71200400001)(83380400001)(38070700005)(5660300002)(86362001)(99936003)(82960400001)(316002)(52536014)(66574015)(53546011)(6506007)(2906002)(186003)(4326008)(26005)(110136005)(76116006)(66946007)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZXdXbldIMmxLRk5WT1praUxQbDZGR1laNTFZN01lN2ZxYlFRS1U5cWxNMTg0?= =?utf-8?B?MTlPcGpqc3RLa2wzOFdsRHBMN1pzYngzUit3QXpoQXRXYjZJTWk2V0RaWHIv?= =?utf-8?B?K3RpMXV1VDlNL3ZuV0lEaytyR2VLL0VXZk1ieVVNMkg1Rk5oSTRoR3JadlZJ?= =?utf-8?B?RkNETHRIQktuRjJaT3ZiMkNKaHFEbno0NjYrRk1jQVdUUEVYUEtOOWZTcUMw?= =?utf-8?B?VGNlcTRLVWFORGdWblFraGpRZ1BRNVg3clAweFNqR2E0ZC9tTDhpdFRYWXRk?= =?utf-8?B?dGtVWnFqUGdhNWFnbjZsK0QxQXZCb1RzdVFOcURjZkxpaytiMjhaS29laUJk?= =?utf-8?B?YmIyM3crRWljNkdheENpWlo3MzFhbG9UWlU0UnhVRng2QkljTFRaanZ6K2sr?= =?utf-8?B?bGlhajcyV1d3Tmo5Vkt4TndSNzV0b1hIb3RZeUxtUDBHQklkRUhnTkZsOVRj?= =?utf-8?B?cE1JTTJrWE9KRzZhLzJBS2pJTjdPMzBZbWtGaHdxajJ6YXcxR0M4YUxCS3JT?= =?utf-8?B?WExkWVJIL2cwbEcyRVdtUnF3UE5VSG14Q0FpUXF3MkRHVnZoSkoyMm5xcWtO?= =?utf-8?B?dVFDWW9TVkdNaS9jYmZwMHVRNlVvVHZXN1g0Z1p1T0orM1FuMXcyWnA0TVhw?= =?utf-8?B?VjgvZTJlWXVFRGYvZmhqbkxLbFVsSHN4eDhOL0o1ZUhkNTQ1Ny96ZVI3Qmk0?= =?utf-8?B?TUpzeHJoYUNyYjA1VDRGQ2Y5R0h0OWozMDc1Y2VtbW9jQkxRWTlqMEZlcGFN?= =?utf-8?B?V1R3a1RLdC96Q2FNby9VN0RqL3VnRC8zTUJhb09qdzhWazltcnZ1b1ljbVBs?= =?utf-8?B?WUxsczZENDFUc1R0YmJ5V0NlOUp3NTdEaVRyM2U2TjRtMEJoK1MxNnI2WjJL?= =?utf-8?B?UlhBa0s1RFFXQkFFRW5VSm41cmc4aEtyWG00K01kbkNxS043cHJiMHlQRmw2?= =?utf-8?B?NGJDQThEQnFiY0FIbTVIV2hKWHExYVAwVmxhbmp3YjJUQWExbS94R2MwTXlT?= =?utf-8?B?eGNaWjJTcnJWbmhoTHk0STA4eVdLR1NFVU9nVzBkeUtlWmxzNGExSy9XRWpr?= =?utf-8?B?OXdZSlNlTVkzNVB5azV2NjhoNDJ6S3gzenpFQ0lWR3NMcTZ6NzRIQmtnczBa?= =?utf-8?B?eVdVZjRkNU9jTmVsb1htMW9IM2tDaHh2d3NtdjAwQWthL1NucVNVUEYyeU1C?= =?utf-8?B?VVJ4alBKUEdmdXlBTFAxRUlVQlRYOTFmZW1Pb2plMk56SGhYRmNiOEcydEJs?= =?utf-8?B?QzVoN3NQa0E2SmxFTEJPY2phTWZ0U2kySFl0dXlTaDhnc3AzUUlBL0daM0tS?= =?utf-8?B?WlFHaHlyNTFsNDBsUHBTU3NOT0N6NXhyZkQ3QllPM3Zkei9GalZUTUdJbHZs?= =?utf-8?B?MDAxYzZxV1VLY0V2bmUvTDA1R3dPMjcwMnNOK0tIRzU0N1ZkUzVpUXBZQ0hp?= =?utf-8?B?VlQzQS9waTJRSi95YzBIS0RTa044bURhZ3R4djZSRVR6RGViQTVlMUtuNzJt?= =?utf-8?B?VHowVXUxQUE0NVpVNlpvREVZSTZrSzV5cS9tUWx1QlpiSlFyaS80TEc2a0Vr?= =?utf-8?B?dlp2UzNOYm01RU9zcW4yOFRsbkdEVWQwRnM0QzZBRU84VnNIVXhVUTV1c0Rv?= =?utf-8?B?bnA4UXdLU0hXbEk2OVRaTnNQV2NzSXFDSWNTZ1BJTE01UW51YjdZSUoxa1lx?= =?utf-8?B?dkJMM2hFOVFMakxjK04reFhDdVJoTjJLcXM4MzZyNVNzeUdHQ3VMM2VDWDFt?= =?utf-8?B?eUhYQnd3ekNvd09NS3BocktTK1BWR1VCOUdONmt2ZkdrUStPRGJYYjVpOXJK?= =?utf-8?B?YlptTk4rdEh4WXNpMjNLZ3VmcUJqRHczcC9aRHAvcFdDZCtPM1dsUzJsT1FY?= =?utf-8?B?SmV2anh2QlNDZ3dCbjljNk1RQTlmRG1LeTE1SnZqazdkN1Q3NUQyY3M5Q0lZ?= =?utf-8?B?azJnUTFlUlY1ajBQZ0pFajJIRlY0cUdnd3Q2ZThIZFZVbjc4RjJOTXRubDl0?= =?utf-8?B?em5KcndMeG5BYWU5ZlVKYmxTK25PalFhb0RYMzNyOHNtcXdKV1JieGNYTWtK?= =?utf-8?B?OGs1WGFBTk83dGw0V3ZuR3p5T1pLTmZwWjJjMnNpRTVSaTBuakpvbEdMYkRC?= =?utf-8?B?akRFeHAxNDBnelprNitSd2Zzb09zckhnUDNsSlhRNlQzdUIrSEZ4NDFCZ2FV?= =?utf-8?Q?LDGARxhrxdENsRDb38BNCKM=3D?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02AD_01D7D648.C9FADF90" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3403.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d4d464c-9299-44e1-63d4-08d9a4578bbc X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2021 14:36:56.1805 (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: KWW2mJZvaXL59ZvYVNi9xI3xME9XfX3tRSNZG/+j7sgHdPd97EjshyAeZCWLfrK/W1Xx2WaAp7Py46lmVfnC4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3369 Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 14:37:07 -0000 ------=_NextPart_000_02AD_01D7D648.C9FADF90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02AE_01D7D648.C9FADF90" ------=_NextPart_001_02AE_01D7D648.C9FADF90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems to me that Tim is making a fair description of reality in this = case. =20 While I have no insight into the customer request to Google, I=E2=80=99d = like to emphasize that since it refers to the GSMA text, the context of = that request must reasonably be IMS-native telephony with added data = channel(s). In IMS-native telephony context there=E2=80=99s today no = support for ICE or ICE Lite, which is then likely the reason for the = request. Use of Chrome as a browser application would hardly make sense = to me in the context of IMS-native telephony (without any gateway), so I = agree with Tim on that aspect. =20 Thanks, Bo =20 From: rtcweb On Behalf Of westhawk Sent: den 10 november 2021 11:17 To: Harald Alvestrand Cc: RTCWeb IETF Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol = violations? =20 This is (perhaps) a subclass on an interesting situation, where the 5g = network spins up a new bearer channel with an interface which is = effectively a VPN to the far end. This obviates ICE, also they probably don=E2=80=99t want Chrome to be = able to talk to the far end :-) =20 Tim (who spent too long in Telcoland)=20 On 10 Nov 2021, at 11:09, Ted Hardie > wrote: =20 Hi Harald, Bo, =20 Thanks to you both for the clarifications. It seems to me, in light of = this, that the working group probably does not need to draft a liaison = statement and that this can be worked out simply using the explanatory = email that Bo provided. If that is not the case, I'd appreciate a = clearer statement of what would be required. =20 thanks, =20 Ted Hardie =20 On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand > wrote: Thanks Bo! The specific problem I have is that a customer has requested that Chrome = be modified to be able to operate without ICE, where the owner of the = equipment in question is pointing to this particular sentence as = justification for its request. If the sentence had said "Use of STUN and TURN servers are not required, = and ICE-Lite can be used", that would have been no problem. Harald On 11/9/21 11:45 PM, Bo Burman wrote: Hi Ted, Harald, =20 I have some insight into that GSMA work that might help the discussion. The intent was never to create or even suggest incompatible changes to = WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC = protocols, which I believe is clear from other parts of that White = Paper. The suggested reuse of WebRTC data channel protocol stack is for = 3GPP IMS-native multimedia telephony, not intended to change the core of = WebRTC. It should be OK to use a data channel outside of WebRTC context = =E2=80=93 for example, like CLUE telepresence makes use of it. Also, = 3GPP previously defined WebRTC access to IMS through the use of a = gateway where ICE is used on the WebRTC side, but that is separate from = the GSMA case. =20 The GSMA White Paper is mainly educational for that community, in this = case exploring possibilities with using WebRTC data channel media as = part of 5G phone calls. If GSMA members find this interesting enough, = normative work and specifications will follow but nothing is started = yet. =20 I believe the sentence Harald highlights below should be interpreted = from the perspective that ICE/STUN/TURN functionality is strictly not = needed in a telco operator=E2=80=99s network, since connectivity is = solved by other means in that context. That particular sentence is = likely not considering what requirements, e.g. use of ICE, that may come = from reuse of existing WebRTC protocol stacks. This aspect must however = be kept in mind as the work continues. =20 I hope that helps. =20 Cheers, Bo =20 From: rtcweb = On Behalf Of Ted Hardie Sent: den 3 november 2021 14:10 To: Harald Alvestrand = Cc: RTCWeb IETF Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol = violations? =20 Hi Harald, =20 It is definitely possible for us to send liaison statements via the = appropriate channel, but I am missing some context. Can you provide a = citation to the document from which the excerpt comes? (It appears to = be labeled a white paper, so the first step may be to confirm that its = description and the underlying specs say the same thing.) =20 regards, =20 Ted Hardie =20 On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand > wrote: It's come to my attention that there's apparently some 5G spec that says = "Use WebRTC datachannel, but don't bother with this ICE stuff". The exact quote is below. Now I don't mind saying "don't use TURN/STUN servers" - that's a=20 configuration option on the WEBRTC API, and anyone can choose to not do=20 that - but I do mind leaving out ICE. An ICE-supporting implementation=20 won't interwork properly with an implementation that doesn't support = ICE. Is it possible for the IETF to say "please don't make incompatible=20 changes to our protocols without asking us"? (that's the version where I = try not to use expletives). Or is it possible that this is all a misunderstanding, and the 5G folks=20 actually meant to require peer-to-peer ICE, but just wrote it wrongly? Or did I misunderstand what the WG's intent was, and should just suck it = up and interoperate with non-ICE-supporting endpoints? Harald --------- Spec reference quote ---------- 1. Spec NG.129 - 5G Data Channel White Paper (CR1001) 8.2.1Data channel APIs The data channel application consists of the device side logic and the=20 server side logic. Both should use standardized APIs that need to be agreed by the = industry. W3C WebRTC1.0 data channel API specification is suggested as the=20 preferred IMS data channel API. RTCPeerConnection , RTCDataChannel object, the callbacks need to be supported . Only data channel API related definitions are used and IMS data channel = API is not allowed to use WebRTC media. ICE/STUN/TURN are also not required. # Reference 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS GSMA NG.129_5G DATA CHANNEL _______________________________________________ rtcweb mailing list rtcweb@ietf.org =20 https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org =20 https://www.ietf.org/mailman/listinfo/rtcweb =20 ------=_NextPart_001_02AE_01D7D648.C9FADF90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

It seems to me that Tim is = making a fair description of reality in this case.

 

While I have = no insight into the customer request to Google, I=E2=80=99d like to = emphasize that since it refers to the GSMA text, the context of that = request must reasonably be IMS-native telephony with added data = channel(s). In IMS-native telephony context there=E2=80=99s today no = support for ICE or ICE Lite, which is then likely the reason for the = request. Use of Chrome as a browser application would hardly make sense = to me in the context of IMS-native telephony (without any gateway), so I = agree with Tim on that aspect.

 

Thanks,

Bo

 

From: = rtcweb <rtcweb-bounces@ietf.org> On Behalf Of = westhawk
Sent: den 10 november 2021 11:17
To: = Harald Alvestrand <harald@alvestrand.no>
Cc: RTCWeb IETF = <rtcweb@ietf.org>
Subject: Re: [rtcweb] 5G standards = advocating WebRTC protocol violations?

 

This is = (perhaps) a subclass on an interesting situation, where the 5g network = spins up a new bearer channel with an interface which is effectively a = VPN to the far end.

This = obviates ICE, also they probably don=E2=80=99t want Chrome to be able to = talk to the far end :-)

 

Tim (who spent too long in = Telcoland) 



On 10 Nov 2021, at 11:09, Ted Hardie <ted.ietf@gmail.com> = wrote:

 

Hi Harald, = Bo,

 

Thanks to you both = for the clarifications.  It seems to me, in light of this, that the = working group probably does not need to draft a liaison statement and = that this can be worked out simply using the explanatory email that Bo = provided.  If that is not the case, I'd appreciate a clearer = statement of what would be required.

 

thanks,

 

Ted = Hardie

 

On = Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand <harald@alvestrand.no> = wrote:

Thanks = Bo!

The = specific problem I have is that a customer has requested that Chrome be = modified to be able to operate without ICE, where the owner of the = equipment in question is pointing to this particular sentence as = justification for its request.

If the = sentence had said "Use of STUN and TURN servers are not required, = and ICE-Lite can be used", that would have been no = problem.

Harald<= /o:p>

On 11/9/21 11:45 PM, Bo Burman = wrote:

Hi Ted, = Harald,

 <= /o:p>

I have some = insight into that GSMA work that might help the = discussion.

The intent = was never to create or even suggest incompatible changes to WebRTC = protocols. Quite the opposite, the intent was to reuse WebRTC protocols, = which I believe is clear from other parts of that White Paper. The = suggested reuse of WebRTC data channel protocol stack is for 3GPP = IMS-native multimedia telephony, not intended to change the core of = WebRTC. It should be OK to use a data channel outside of WebRTC context = =E2=80=93 for example, like CLUE telepresence makes use of it. Also, = 3GPP previously defined WebRTC access to IMS through the use of a = gateway where ICE is used on the WebRTC side, but that is separate from = the GSMA case.

 <= /o:p>

The GSMA = White Paper is mainly educational for that community, in this case = exploring possibilities with using WebRTC data channel media as part of = 5G phone calls. If GSMA members find this interesting enough, normative = work and specifications will follow but nothing is started = yet.

 <= /o:p>

I believe = the sentence Harald highlights below should be interpreted from the = perspective that ICE/STUN/TURN functionality is strictly not needed in a = telco operator=E2=80=99s network, since connectivity is solved by other = means in that context. That particular sentence is likely not = considering what requirements, e.g. use of ICE, that may come from reuse = of existing WebRTC protocol stacks. This aspect must however be kept in = mind as the work continues.

 <= /o:p>

I hope that = helps.

 <= /o:p>

Cheers,=

Bo

 <= /o:p>

From:= rtcweb <rtcweb-bounces@ietf.org> On Behalf Of = Ted Hardie
Sent: den 3 november 2021 14:10
To: = Harald Alvestrand <harald@alvestrand.no>
Cc: RTCWeb = IETF <rtcweb@ietf.org>
Subject: Re: = [rtcweb] 5G standards advocating WebRTC protocol = violations?

 <= /o:p>

Hi Harald,

 

It is definitely possible for us to send = liaison statements via the appropriate channel, but I am missing some = context.  Can you provide a citation to the document from which the = excerpt comes?  (It appears to be labeled a white paper, so the = first step may be to confirm that its description and the underlying = specs say the same thing.)

 

regards,

 

Ted = Hardie

 <= /o:p>

On Wed, Nov = 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no> = wrote:

It's come = to my attention that there's apparently some 5G spec that says =
"Use WebRTC datachannel, but don't bother with this ICE = stuff".

The exact quote is below.

Now I don't mind = saying "don't use TURN/STUN servers" - that's a =
configuration option on the WEBRTC API, and anyone can choose to not = do
that - but I do mind leaving out ICE. An ICE-supporting = implementation
won't interwork properly with an implementation that = doesn't support ICE.

Is it possible for the IETF to say = "please don't make incompatible
changes to our protocols = without asking us"? (that's the version where I
try not to use = expletives).

Or is it possible that this is all a = misunderstanding, and the 5G folks
actually meant to require = peer-to-peer ICE, but just wrote it wrongly?

Or did I = misunderstand what the WG's intent was, and should just suck it
up = and interoperate with non-ICE-supporting = endpoints?

Harald

--------- Spec reference quote = ----------

1. Spec
NG.129 - 5G Data Channel White Paper  = (CR1001)

8.2.1Data channel APIs
The data channel application = consists of the device side logic and the
server side logic.
Both = should use standardized APIs that need to be agreed by the = industry.
W3C WebRTC1.0 data channel API specification is suggested = as the
preferred IMS data channel API. RTCPeerConnection = ,
RTCDataChannel object, the  callbacks need to be supported = .
Only data channel API related definitions  are used and IMS = data channel
API is not allowed to use WebRTC = media.
ICE/STUN/TURN are also not required.

# = Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and = interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging = over 5GS
GSMA NG.129_5G DATA = CHANNEL

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

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

 

------=_NextPart_001_02AE_01D7D648.C9FADF90-- ------=_NextPart_000_02AD_01D7D648.C9FADF90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR4jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF3DCCA8SgAwIBAgIPAXVWFPODkdW317IdRU4oMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMjMxNTMwMTRaFw0yMzEwMjQxNTMw MTNaME4xETAPBgNVBAoMCEVyaWNzc29uMRIwEAYDVQQDDAlCbyBCdXJtYW4xJTAjBgkqhkiG9w0B CQEWFmJvLmJ1cm1hbkBlcmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDZjgGpWg3zVLAqmJw+ym9/UuzHvsAPGPoug8QqZvNhLURy5iIUkqt17g/2hINesXncbxyZxUOj viKkkQZt46xfTXA0ABuFhVn0yHBda/Cl61uc642ttqoUgouCeF7wtUCjSHzOFSFqIuWYcNgkfbBm 2JwTYiIDQOzZR0QD7Q2FX9718R3/K0NrjILzMUk3xTBlUMHN+y9cdn/B/mXKvJAX1pyndtrBxbZG /Ql0NdMcsowxJay2zmYfb0f/Kj8ArodzvHo5xw8KZAP5X5o0vYF5seYdgbgGAlIFCyWEKScoT9Du P5rJFpXN9t5dDfLo4MAvZ+91oOQ5tLnoBarI+eeRAgMBAAGjggG8MIIBuDAfBgNVHSMEGDAWgBQc exmel5x2rCA92NzjkWrj2y2mUzAdBgNVHQ4EFgQUHra05hxRd68Xe6CMWRxeAEeoCGQwDgYDVR0P AQH/BAQDAgWgMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBz Oi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMCEGA1UdEQQaMBiBFmJvLmJ1 cm1hbkBlcmljc3Nvbi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0 LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9l cmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQDGJup4QMdjP8Oc VobWxGnrRcLZza8XEFqMi+n3dpDIcQskRT1xFd48HsTzWgj1j4OF9QOzwgh8p7sFBM/p27Tbp28P yGPkCf+v6Yo3dKxmxfEA14u3T4Du7BQD8DBx+DB0z18lvFyUozca6kYCNgCPpliGetBLd5ewVCQV EpgnqNYyAsFGlN0ymYwF3x1w0uTdW6i3hIZIxo4+XprGq9Zoe3LXC0Yb/FZaNEgld+9FpboPgwkl BtiHhXMb7Bqd6izv/My24lmHvq51eu3DmyDRUPPnviq94P1HltW1ZlGRwRU0rVIGVqgU6R5WicDS ZJPKYiEkZ3YySP8ZoQcAxOvKd3UgyjV5hjAvmxOiUwjf2EhgSpbAP7O4CY3bEQO4x7I4PtCbjqSS NL2q6I5lEvlAUExY8MrsosTlqS1MuOtpQ0lOgp0wcqESq0K1fZeXHIEzXLin9pLeZKFEwTbiXD7a aDWWpcd6vLb1rLiaUxdF6r3YLvu+19sMsR7FElTFW4jdK/Wnw+72nHSiUJ6oF90D5MTCrCYuVOZG udUdUnToJIr0CVLDxiS+4NrPqr75GYOZ1357J6uZp8W6r9hc02g0igsn7yW12wadmPQwGUyyLPgF 0hE2Yf6H66p4ZszYQfPZ57Ase97pfUgU/kC0vOMmKEIESIIHVzWy0/24NKQGMjCCBsIwggSqoAMC AQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVy aWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkq UXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhV W4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAw qBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/ 8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC +zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8o LUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldv EtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4y hzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pA VwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3Au dHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB /wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRw Oi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7 GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqG SIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5Q taZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj 0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQy sshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx 6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtn gmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi +K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiB maz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP /Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvx OgftYug7OY9EKY+WkDGCA1AwggNMAgEBMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdVYU84OR1bfXsh1F TigwCQYFKw4DAhoFAKCCAcswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjExMTEwMTQzNjU0WjAjBgkqhkiG9w0BCQQxFgQUHzB9lKMcjBAW1BuOvzhn7gHaZvQwaQYJ KwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwF1VhTzg5HVt9eyHUVOKDBrBgsqhkiG9w0B CRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmlj c3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdVYU84OR1bfXsh1FTigwgZMGCSqGSIb3DQEJDzGB hTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCG SAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEALrG7cXb5ZtEmQdeCAT/0l7Mh CclX1vDb7j+Ehq8m3s6AjToP4HKRdTJwOVdbRY075ATDAi10GPyEncj1o8Q1t7XzvO9Ch0aw6rFi NznmUMbngADTirMOhP3J8f3gldiCtMwZUFl2QcAlQVM9BisbxvcfFDsegXHTevcCIS1jiPFs3Huk /ZGLLlGdbagOX2bMnklJDxq/RVh5RCZZLX26Dl1pfW5SLPpcnHRLF9Q0GPf/gd6OL+JvW6HeAn1B kDDAkWH12xNyEdceLRIh8RkleeBCt+2oIxs4jWwwnLgothLikP5h3WCsjTR4hF58KJrpxR404yJZ DtpPDW6F5YQT+QAAAAAAAA== ------=_NextPart_000_02AD_01D7D648.C9FADF90-- From nobody Wed Nov 10 10:17:09 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340F73A124F for ; Wed, 10 Nov 2021 10:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=telurix.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 0vnQfqJ-lhM5 for ; Wed, 10 Nov 2021 10:17:01 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 5107B3A1240 for ; Wed, 10 Nov 2021 10:17:01 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id q14so2932798qtx.10 for ; Wed, 10 Nov 2021 10:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jir6n9DRoYAK8EspaGDaP30eIAOkR0a4nBGZly1kks4=; b=xEgfB874wQMXog8RihFMj719apFEwLIYmHlvtIgyELYAPnLjEpsVErO1Cmj3CNj3JB 23nXlh7+/OWweWa8rJghbePrY8hUR6ALpgedAZIfbqXjDOTsSEDj9+Yj+BOKTsPBjsGL recUOL9Ah2SDKOD1c6n1bk7m5ziRkBRB09r7o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jir6n9DRoYAK8EspaGDaP30eIAOkR0a4nBGZly1kks4=; b=5y0Ru1V2oPCO/+OvUmRj9pqZeTotccGgmo/PX28p8fb2W3/hZpabr6/DPYtjHUE47D Er7MNk6W1qR7JzmxMVpgIPDJuwwblQDIDFQXy3NhCWU67HjM/bL0LPGQbnA6wZnNJO+W dSZOy4p3geooLqarZEhsNm4uenL+YFDZlgPBv8aQFxGPJRqFPFhr31hRO0UbXSJaOI5s AE57PbFKywP5nN/oJ0+nIXIotewFqC9SrZd9zUXdXelseUbAM5gyLQjoRSU2vQ6J437o nWz0RZggmEaIMlyDweN5Ab6uclq1c9jv4MqJgTUV/C+PX5UD9UeGwgstMUAH9DPPve5p H3dQ== X-Gm-Message-State: AOAM531QSvVck4Rtsxo19Q4IcKV2MLrxDXvb7v10ivBb0/iaW1wsT27D h/8pwB+eq+af/6pywCHENzPvdSsTR+Kd1w== X-Google-Smtp-Source: ABdhPJyZttSUrXdpFyyn+KpMeTJk1aaowb41O2wv1Gz0u3vSYrxx6xcyG/fBES09Vx7JwpgV0Jctjg== X-Received: by 2002:a05:622a:2d1:: with SMTP id a17mr1122802qtx.130.1636568219402; Wed, 10 Nov 2021 10:16:59 -0800 (PST) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id x188sm259677qkd.31.2021.11.10.10.16.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Nov 2021 10:16:58 -0800 (PST) Received: by mail-yb1-f175.google.com with SMTP id s186so8578559yba.12 for ; Wed, 10 Nov 2021 10:16:58 -0800 (PST) X-Received: by 2002:a5b:482:: with SMTP id n2mr1398483ybp.514.1636568218496; Wed, 10 Nov 2021 10:16:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Wed, 10 Nov 2021 13:16:46 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000005071ce05d0733b1e" Archived-At: Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 18:17:07 -0000 --0000000000005071ce05d0733b1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When two ICE-Lite clients are connected, there are no consent checks. With one ICE-Lite client, there are consent checks in one direction only. In either case, an endpoint can be used to generate traffic for DDOS. In the case of WebRTC, there is an additional initial consent present in the form of a DTLS handshake, but only ICE provides continuous consent to send media= . At this point, any system, which sends a large amount of data without consent to receive it, should be considered a DDOS risk. I am not sure how telecom networks would be any different unless they use some other mechanism for the same purpose. _____________ Roman Shpount On Wed, Nov 10, 2021 at 9:32 AM Cullen Jennings wrote: > I agree we need the consent checks that ICE provided but I think ICE Lit= e > still provided the checks that provide the consent to receive packets > property. > > On Nov 9, 2021, at 1:49 PM, Roman Shpount wrote: > > I would advise against ICE-lite. One of the things that ICE provides is > consent to send media. ICE-lite does not have this. Getting consent is > important to avoid using endpoints for DDOS attacks, so it is a matter of > security. > > If they want to simplify things, they can use host candidates only, which > will make the ICE state machine trivial. > _____________ > Roman Shpount > > > On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings wrote: > >> >> We might want to say if you don=E2=80=99t want to do any of the ICE nigh= tmare, >> ICE Lite is the best way to not do it and still have interoperability. = Do >> we know someone working on this at 5G that can help provide more guidanc= e ? >> >> >> >> On Nov 3, 2021, at 7:10 AM, Ted Hardie wrote: >> >> Hi Harald, >> >> It is definitely possible for us to send liaison statements via the >> appropriate channel, but I am missing some context. Can you provide a >> citation to the document from which the excerpt comes? (It appears to b= e >> labeled a white paper, so the first step may be to confirm that its >> description and the underlying specs say the same thing.) >> >> regards, >> >> Ted Hardie >> >> On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand >> wrote: >> >>> It's come to my attention that there's apparently some 5G spec that say= s >>> "Use WebRTC datachannel, but don't bother with this ICE stuff". >>> >>> The exact quote is below. >>> >>> Now I don't mind saying "don't use TURN/STUN servers" - that's a >>> configuration option on the WEBRTC API, and anyone can choose to not do >>> that - but I do mind leaving out ICE. An ICE-supporting implementation >>> won't interwork properly with an implementation that doesn't support IC= E. >>> >>> Is it possible for the IETF to say "please don't make incompatible >>> changes to our protocols without asking us"? (that's the version where = I >>> try not to use expletives). >>> >>> Or is it possible that this is all a misunderstanding, and the 5G folks >>> actually meant to require peer-to-peer ICE, but just wrote it wrongly? >>> >>> Or did I misunderstand what the WG's intent was, and should just suck i= t >>> up and interoperate with non-ICE-supporting endpoints? >>> >>> Harald >>> >>> --------- Spec reference quote ---------- >>> >>> 1. Spec >>> NG.129 - 5G Data Channel White Paper (CR1001) >>> >>> 8.2.1Data channel APIs >>> The data channel application consists of the device side logic and the >>> server side logic. >>> Both should use standardized APIs that need to be agreed by the industr= y. >>> W3C WebRTC1.0 data channel API specification is suggested as the >>> preferred IMS data channel API. RTCPeerConnection , >>> RTCDataChannel object, the callbacks need to be supported . >>> Only data channel API related definitions are used and IMS data channe= l >>> API is not allowed to use WebRTC media. >>> ICE/STUN/TURN are also not required. >>> >>> # Reference >>> 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction >>> GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS >>> GSMA NG.129_5G DATA CHANNEL >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --0000000000005071ce05d0733b1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When two ICE-Lite clients=C2=A0are connec= ted, there are no consent checks. With one ICE-Lite client, there are conse= nt checks in one direction only. In either case, an endpoint can be used to= generate traffic for DDOS. In the case of WebRTC, there is an additional i= nitial=C2=A0consent present in the form of a DTLS handshake, but only ICE p= rovides continuous=C2=A0consent to send media.

At this point, any system, which sends a large amount = of data without consent to receive it, should be considered a DDOS risk. I = am not sure how telecom=C2=A0networks would be any different unless they us= e some other mechanism for the same purpose.
_____= ________
Roman Shpount


On Wed, Nov 10, 2021 at 9:32 AM Cu= llen Jennings <fluffy@iii.ca> wr= ote:
I =C2=A0agree we need the consent checks th= at ICE provided but I think ICE Lite still provided the checks that provide= the consent to receive packets property.=C2=A0

On Nov 9, 2021, at 1:49 PM, Roman Shpount <roman@telurix.com> wrote:<= /div>
I would advise against ICE-lite. One of the = things that ICE provides is consent to send media. ICE-lite does not have t= his. Getting consent is important to avoid using endpoints for DDOS attacks= , so it is a matter of security.

If they want to simplif= y things, they can use host candidates only, which will make the ICE state = machine trivial.
_____________
Ro= man Shpount


On Tue, Nov 9, 2021 at 3:38 PM Cullen Jenn= ings <fluffy@iii.ca> wrote:

We might want to say if you don=E2=80=99t want to do any = of the ICE nightmare, ICE Lite is the best way to not do it and still have = interoperability.=C2=A0 Do we know someone working on this at 5G that can h= elp provide more guidance ?



Hi = Harald,

It is definitely possible for us to send liaison statements via t= he appropriate channel, but I am missing some context.=C2=A0 Can you provid= e a citation to the document from which the excerpt comes?=C2=A0 (It appear= s to be labeled a white paper, so the first step may be to confirm that its= description and the underlying specs say the same thing.)

regards,

Te= d Hardie

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no= > wrote:
= It's come to my attention that there's apparently some 5G spec that= says
"Use WebRTC datachannel, but don't bother with this ICE stuff"= ;.

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - t= hat's a
configuration option on the WEBRTC API, and anyone can choose to not do that - but I do mind leaving out ICE. An ICE-supporting implementation
won't interwork properly with an implementation that doesn't suppor= t ICE.

Is it possible for the IETF to say "please don't make incompatible=
changes to our protocols without asking us"? (that's the version w= here I
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck i= t
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper=C2=A0 (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the
server side logic.
Both should use standardized APIs that need to be agreed by the industry. W3C WebRTC1.0 data channel API specification is suggested as the
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the=C2=A0 callbacks need to be supported .
Only data channel API related definitions=C2=A0 are used and IMS data chann= el
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

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

--0000000000005071ce05d0733b1e--