From nobody Sun May 7 12:50:58 2023 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5940C15152D for ; Sun, 7 May 2023 12:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkIF9yq5WKyS for ; Sun, 7 May 2023 12:50:52 -0700 (PDT) Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2061e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe12::61e]) (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 57F6EC151525 for ; Sun, 7 May 2023 12:50:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LkJIlyHoDFEAbEJPE8S1KaxhQvvIlDtdco0yEOMEdfWRr6u3wiLwOOwtB7m6MbBB++jKfBJNB8PMyzHC2Yw5H7SQGysgVqRORiBQ2jzf2Hn3Ia2TvkSYfFkIIgqwAlG9uxo7lioD7iBr9C5r4wsgyJf9nyo+skUAuqb6DYOiwDnwE7JgtACCYLJu8nm/vaOgolwV9AfF+5pS/xZCjwGuLLR5RN0b8Hr2PJFP51M54oifKK4srtH2QD+l2U3X34PuuHNALyzownMNyoY2ktEU22lCJJRnix7ZboDVGf8GequUd3/tYX98AdyOtDs6Ct98xcoLLaGnm3Izbk2h204lpQ== 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=wkBNDSJx+tD0Bz8lPpyxIbJYY5+Eul76PDYUeswBwhw=; b=IwusvqR4PxhubtDu+ozsvJSU7heTFjUCPFOCz9J575S6aA+BwM9YMqGWiLIE05GiOJczfCDEGcAzeJWdAJwUFK/QgYzRHELbHAUYD/B2dHYswD54leA8UNziHWBAKpBAf/1yICzYIn/MJuSftqEfmyBfTxH1nZPiz71KkaYOJI1GYbf/6sbjVOlzudEsHpg2JzGSuON3W9fj96Oyp846XSUEAofmxWzv7PiWpsunkxGNEamvYQwUK5jZjAVf0AY69alsxV+/LsQ5nVnt3v7ZsVjy8mAWODvzCX5DdMDeHU28+FPEO+K/v6LE/lggG1JdxGmyuMecQ2qlsgYkKOTujg== 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=wkBNDSJx+tD0Bz8lPpyxIbJYY5+Eul76PDYUeswBwhw=; b=VqNlCiSiTW/zP55mD1ARUpr+I3wqIP74XVP20UPguT/ocOZPhCl68w8AWnJBXvyEcyq/VgXI4jkRaQ+0L1RvZgcr9pG3TuZTSYobqVLsK/DtiAjanNeArxZYM5KJh5MfW1KbmVGjQY8upuCW2PhjYzNYXQf4bdl0jQhQKfdb40M= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by AS5PR07MB10032.eurprd07.prod.outlook.com (2603:10a6:20b:651::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.26; Sun, 7 May 2023 19:50:47 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::8542:2a28:6718:b1b4]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::8542:2a28:6718:b1b4%6]) with mapi id 15.20.6363.032; Sun, 7 May 2023 19:50:46 +0000 From: Christer Holmberg To: Tim Panton CC: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2 Thread-Index: AQHZf7JJZNe2DcDmDEWZ0j8JTBi8Cq9OlyL/gAADcICAAB9nTIAAFd2AgABiLig= Date: Sun, 7 May 2023 19:50:45 +0000 Message-ID: References: <61AC7C19-2806-483F-9526-637DB5D46104@westhawk.co.uk> <8A7B8A70-7E37-4B0F-917D-C2FF62B84768@westhawk.co.uk> In-Reply-To: <8A7B8A70-7E37-4B0F-917D-C2FF62B84768@westhawk.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: HE1PR07MB4441:EE_|AS5PR07MB10032:EE_ x-ms-office365-filtering-correlation-id: c01dfd7c-1f57-47ed-fd12-08db4f3458ea x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w7bNNp9JdCMa61o3ZoXrmgFAPnqElHux6gUQJSOso45r6CdJ4OuwHDuyhTRBhgqqsChcLdIT9W0pqU7+rbtsXwZwsn+xjXNfOVoN1FTKonaLdIAlWlT23wNf088L2Tlq3/MlOzEpn0UTN37cBnoTecdHqL0r4a5hd/65GGxhWSlH/BEnOS46uAjdszzLoEI/hRjZKK8D/b3yK/Bj6o6KrXo9fXGpOd6WqVMfhzYcMYiGrP/K8qgiaA1ONmIgOgnJfeG7yEL47GYTv8TJ5jHW9lsmP6qrRmOrUz+Bxwpyn5sLuZ25W+LR98K/t1H0qzxKF8VKfKxxl3TrwRz5b1c1QMAy8SIyGJGTcMYIKnuK+LAtp1R7rYKywFw7+2WAKAdn9ZwdfaNLeTnD5wn2+dg0qonQROKYfiBv65Rw+HRm9yr+j3doZ4i1h5DvB5nnSt5Cw4qqIm3V69ZJp8t46U/houhL6ZnpyFAQrBcIliiKHfmYAL0Dh3qfngYfG8pfrf4NFJRe9VN7EajcU3rF/3YSg4viSJd2b/Ftb0Am6uQvhLHvyXDZTkcYvdVHdxUSQ2i44gfmUBj14KSuuIZMdHXL5u+hzmEmVAuEzXIOEbYb7RNOPXUqQJHNZKcu8NETDo5UmosYfAbTRZIAxfDlKNcOug== 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:(13230028)(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(451199021)(2906002)(186003)(316002)(19627405001)(33656002)(41300700001)(71200400001)(53546011)(26005)(83380400001)(4326008)(6506007)(9686003)(6916009)(76116006)(64756008)(66446008)(66476007)(91956017)(66946007)(86362001)(66556008)(7696005)(45080400002)(54906003)(66899021)(38070700005)(478600001)(44832011)(166002)(52536014)(5660300002)(8676002)(8936002)(122000001)(82960400001)(966005)(55016003)(38100700002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?ySYQqqgmfpnjR3DIzXtV7AhBVUzieCcp2aVNmpr4yV2cjMM8hWqx8uzp?= =?Windows-1252?Q?XETq57EpxVki46U+O18G68qoxURPZkT4cz86DchQFsQHwyHCFDuQlQhn?= =?Windows-1252?Q?WNO9VW8ysA1qamAaJJr6a/itPSDlNPB6mAO/Kmc8RL9mqO102PB4wN3R?= =?Windows-1252?Q?o6ot5dwlZVMArn69bIuioD6tRxAfyhj0LwsUqSSXx6vOTbpnjrE9UnUd?= =?Windows-1252?Q?UeXOYbkhp93pYCfKl0XpTJXpG9XohV1EkPgbMrPbMS91LTXd6ttew/sq?= =?Windows-1252?Q?bp1G1IDt4tiRcVoHNKEMGqxBJ1C+qQdexdBjoGnhDHx5pghHRDt5Y5sP?= =?Windows-1252?Q?W3NYHqIvz5aFvOgyehgFbr7bIYvcBGSsPVJiAVR0sln+o8E/MjGcl+WL?= =?Windows-1252?Q?L8OIbOmUVyePyBbZ3n4WwXhzPBRGvOBkTILCH7u7dw2gD+CKJRgDXdnv?= =?Windows-1252?Q?DUfIFrjdKfHSwQ/NkZB236ro1x2pZoHrNN4oWq25JWi/f3h8KEwM3afF?= =?Windows-1252?Q?DxV7PjXD6/dS6rLl+Imq9hk16celJ0WGIYE1Xa8ypwxetiEwbRmpzLAM?= =?Windows-1252?Q?MhnzSg0dZ3xdFqg60aZhvhjIzdVT8ukxne1X01dxeZXxA74XcKN9jcll?= =?Windows-1252?Q?bdzAOecS3/HsggZoP9xqOcjwdLwAxfLTKeVO/HanuHcu5rIX17DT1Sk3?= =?Windows-1252?Q?aH6KasWJEg7MFC69mlUfCKBiPwC9IAqyc0D0M07zcAAchSgFGWz5VbF2?= =?Windows-1252?Q?4Bf0nLbIlI3MT7aoeTSYQy6rpC1b8XVqcEKs4f13q1+irqWAhMJnejKM?= =?Windows-1252?Q?PoH5rNqhrIpGWtZagGDp7dofrIU+piUPVEj5OqzZywweNucTeYOShpvV?= =?Windows-1252?Q?uOG8J53WddVOMLpLfEZ6XTRvj8ZKjKkK3EaJYQxQ2Eroq6+4XF9Te26j?= =?Windows-1252?Q?l+GVfMZ5/t3cbTBg18bOA9ppeIXnRmbyaeZ1XbgyLLbDWx1VujsemhXR?= =?Windows-1252?Q?uGpL/IZYeO2z6Ayy3UpDvjg6N5px1ZXQSq4HfaRRVclMSt9VP1SdepM+?= =?Windows-1252?Q?deJoM7g/O9tzSjZV36wgumY74nhJycudtJXeFcksQmLb5I1O/zpRFzhQ?= =?Windows-1252?Q?KcNM39pGI8RxD3eFENdT6BGhABrgWZx0H/7Uo9mgq1ZB3aUj/W6kzDOe?= =?Windows-1252?Q?84ORaiy+aCC6+oLUZXotpXn61yZY1WQ0sln2KrngFHsM6hr8eqYV+xVs?= =?Windows-1252?Q?wXcxbAqrM9QRWpwQ669GFWiiHn8oHLSw9uNzWeoAV4BI/RwRTU7UWldm?= =?Windows-1252?Q?zSTxQ8c3p/Apha6juRigdlipnTsFtra7omeILzhFraYD3BPbtWo133Rx?= =?Windows-1252?Q?9Ndwb2W1WMG9URhuR4kxvg0RyiKQK3Kf/2nQwW02JSVuoFv+TWRqeB7n?= =?Windows-1252?Q?MxrdBYciyyMorD+bI/k1GnSRh8i0JIJdWR9trEWIqMGM+xWlFDDMPZT6?= =?Windows-1252?Q?pweDm6TgRmuTyocTgm5A6h2KImnn7xqAkwFnTQKu825wa/IjC9sKFtwh?= =?Windows-1252?Q?kzSOZceJs/bF0RivF9v8bDak6FAAnmhjmPPX4RS7AOi2kZF0Q5DmsWOa?= =?Windows-1252?Q?ApSvVUDF6zwlFCHFujoaD2ou6yimIi4eZApyU36oppxHkpiETXbXwf70?= =?Windows-1252?Q?grPr+c7i7TJnc6U6yFxC7sfqWGvb290NTbABcs/EZ1B2ZbXhPXFC7g?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4441C0C4B70C1DD980EAE23393709HE1PR07MB4441eurp_" 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: c01dfd7c-1f57-47ed-fd12-08db4f3458ea X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2023 19:50:45.1484 (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: NtAyf87Ha6GAARo6ujl2RdIxMuUcUcXoswrvtVRSvLxpHgr4Zi59chtec/veTLREGjORW1tlOXHO5MowSsrJQKBNEdzMIMRh+uR27j06l8k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS5PR07MB10032 Archived-At: Subject: Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2023 19:50:56 -0000 --_000_HE1PR07MB4441C0C4B70C1DD980EAE23393709HE1PR07MB4441eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >> Are there actually some real implementation issues behind the proposed c= hange, or is it only >> about W3C and IETF using different terminology? > > It=92s an API layer thing. At present there are no ways for a javascript = application to manage which RTP > header extensions are present in an offer*. So the current behaviour is t= o offer _everything_ the > library/stack is capable of. The W3C is creating an API point that allows= the javascript application to > decide which extensions (of all the ones supported by the stack) are usef= ul/relevant/safe for the application. > > If both side=92s webRTC implementations support a lot of RTP header exten= sions, the current wording will have > them _all_ offered and all accepted in an answer, even if none of them ad= d any value to the application - bloating > the packet size needlessly. Specifically: =92supported=92 is taken to me= an supported by the user agent - rather than > supported by the application as a whole. > > (This is my understanding of the issue at least) Wouldn't it be better to have a generic statement, saying that for some fea= tures there are APIs that, for some features, allow the JS application to control what options are offered. That would al= so be future proof, and we would not have to update the JSEP spec every time there is a new API that allows the JS ap= plication to control what options are offered for a certain feature. Regards, Christer Sent from Outlook for iOS ________________________________ From: rtcweb on behalf of Tim Panton Sent: Sunday, May 7, 2023 1:16:27 PM To: Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2 I was also thinking about this too - and I somewhat agree. We could replace =91supported' with 'supported by the current application= =92 since at a high level what this change does is to differentiate between= extensions that the library (libwebrtc etc) can support vs extensions the = current application wants to support. It also makes it clearer that this is an editorial change. T. On 7 May 2023, at 11:10, Christer Holmberg wrote: Hi, I have issues with the proposed change. First, AFAIK, "enabled" is not used in any other O/A specification. Second, my reading of "supported" is that it is something that the endpoint= is actually willing to/capable of using within the session. Third, within the JSEP O/A procedures, "supported" is used for other featur= es (e.g., FEC mechanisms). Using other terminology for one feature will onl= y confuse the reader, in my opinion. Fourth, if it is unclear what "supported" really means we should rather cla= rify that. Regards, Christer Sent from Outlook for iOS ________________________________ From: rtcweb on behalf of Justin Uberti Sent: Saturday, May 6, 2023 3:30:33 AM To: rtcweb@ietf.org ; superuser@gmail.com Subject: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2 The WebRTC W3C WG is working on an extension spec that suggests b= ehavior for RTP header extension O/A that conflicts slightly with the curre= nt version of JSEP. Rather than have this sort of ad-hoc extensions extensi= on to JSEP in the W3C spec, it was suggested that we could apply a tiny pat= ch to JSEP before JSEP-bis is finalized (it's currently in the RFC Editor s= tate). Murray was supportive of this but wanted to make sure the WG was ful= ly behind this change first. For context, Section 5.2 in the W3C extension spec basically says that WebR= TC endpoints can control the extensions that are in use, and as a result O/= A negotiation should a) use only the extensions that are enabled by the end= point, and b) always reoffer all extensions, rather than the previously neg= otiated set. I've made a PR that captures this request at https://github.com/rtcweb-wg/j= sep/pull/1033/files, and it basically makes two surgical changes: 1) replaces the use of "supported RTP header extensions" with "enabled RTP = header extensions" 2) changes the text around "extensions... present in the most recent answer= " to instead say "extensions... enabled on the associated transceiver" (sim= ilar to how codecs are handled in JSEP). Please let me know if this sounds reasonable to you or you have concerns. Thanks, Justin _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_HE1PR07MB4441C0C4B70C1DD980EAE23393709HE1PR07MB4441eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

>> Are there actually some real implementation issues behind the prop= osed change, or is it only
>> about W3C and IETF using different terminology?
>
> It=92s an API layer thing. At present there are no ways for a jav= ascript application to manage which RTP
> header extensions are present in an offer*. So the current behavi= our is to offer _everything_ the
> library/stack is capable of. The W3C is creating an API point tha= t allows the javascript application to
> decide which extensions (of all the ones supported by the stack) = are useful/relevant/safe for the application.
>
> If both side=92s webRTC implementations support a lot of RTP head= er extensions, the current wording will have
> them _all_ offered and all accepted in an answer, even if none of= them add any value to the application - bloating
> the packet size needlessly.  Specifically: =92supported=92 i= s taken to mean supported by the user agent - rather than
> supported by the application as a whole.
>
> (This is my understanding of the issue at least)

Wouldn't it be better to have a generic statement, saying that for som= e features there are APIs that, for some features,
allow the JS application to control what options are offered. That wou= ld also be future proof, and we would not have
to update the JSEP spec every time there is a new API that allows the = JS application to control what options are offered
for a certain feature.

Regards,

Christer  



From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Tim Pant= on <thp@westhawk.co.uk>
Sent: Sunday, May 7, 2023 1:16:27 PM
To: Christer Holmberg <christer.holmberg= =3D40ericsson.com@dmarc.ietf.org>
Cc: rtcweb@ietf.org <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
 
I was also thinking about this = too - and I somewhat agree.

We could replace =91supported' with 'supported by the current applicat= ion=92 since at a high level what this change does is to differentiate betw= een extensions that the library (libwebrtc etc) can support vs extensions t= he current application wants to support.

It also makes it clearer that this is an editorial change.

T.

On 7 May 2023, at 11:10, Christer Holmberg <christer.holmberg=3D40e= ricsson.com@dmarc.ietf.org> wrote:

Hi,

I have issues with the proposed change.

First, AFAIK, "enabled" is not used in any other= O/A specification.

Second, my reading of "supported" is that it is = something that the endpoint is actually willing to/capable of using within = the session. 

Third, within the JSEP O/A procedures, "supported&quo= t; is used for other features (e.g., FEC mechanisms). Using other terminolo= gy for one feature will only confuse the reader, in my opinion.

Fourth, if it is unclear what "supported" really= means we should rather clarify that.

Regards,

Christer
From: rtcweb <rtcweb-bounces@ietf.org&= gt; on behalf of Justin Uberti <justin@fixie.ai>
Sent: Saturday, May 6, 2023 3:30:33 AM
To: rtcweb@ietf.org <rtcweb@ietf.org>; superuser@gmail.com <= ;superuser@gmail.com>
Subject: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2
 
The WebRTC W3C WG is working on an extension spec that suggests behavior for RTP header extension O/A that= conflicts slightly with the current version of JSEP. Rather than have this= sort of ad-hoc extensions extension to JSEP in the W3C spec, it was sugges= ted that we could apply a tiny patch to JSEP before JSEP-bis is finalized (it's currently in the RFC Editor sta= te). Murray was supportive of this but wanted to make sure the WG was fully= behind this change first.

For context, Section 5.2 in the W3C extension spec basically= says that WebRTC endpoints can control the extensions that are in use, and= as a result O/A negotiation should a) use only the extensions that are ena= bled by the endpoint, and b) always reoffer all extensions, rather than the previously negotiated set.

I've made a PR that captures this request at https://github.com/rtcweb-wg= /jsep/pull/1033/files, and it basically makes two surgical changes:
1) replaces the use of "supported RTP header extensions" wit= h "enabled RTP header extensions"
2) changes the text around "extensions... present in the most rec= ent answer" to instead say "extensions... enabled on the associat= ed transceiver" (similar to how codecs are handled in JSEP).

Please let me know if this sounds reasonable to you or you have concer= ns.

Thanks,
Justin

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


--_000_HE1PR07MB4441C0C4B70C1DD980EAE23393709HE1PR07MB4441eurp_--