Re: [Rum] Media security

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 01 October 2019 23:53 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508391202A0 for <rum@ietfa.amsl.com>; Tue, 1 Oct 2019 16:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuIMFkK2FZtC for <rum@ietfa.amsl.com>; Tue, 1 Oct 2019 16:53:28 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 BA82E120132 for <rum@ietf.org>; Tue, 1 Oct 2019 16:53:27 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x91NrMNn009526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Oct 2019 19:53:23 -0400
To: "DOLLY, MARTIN C" <md3135@att.com>
Cc: "rum@ietf.org" <rum@ietf.org>
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <C4670F1F-4AEC-45BE-9898-06FF2E28A6A9@standardstrack.com> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <D7293188-DC0C-40A8-9514-308566342170@brianrosen.net> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <3e3c0b3c-0415-1785-3095-2089a281e9df@alum.mit.edu>
Date: Tue, 1 Oct 2019 19:53:22 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <86E626A9-C13D-4106-B423-98223BF26D84@att.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/I450pVOkQyE7bAbEu8ivnWKQ8u8>
Subject: Re: [Rum] Media security
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 23:53:31 -0000

On 10/1/19 4:19 PM, DOLLY, MARTIN C wrote:
> Agree w Paul
> 
> Martin C. Dolly

Thanks Martin. Can you be more explicit about what you are agreeing with?

	Thanks,
	Paul

> Lead Member of Technical Staff
> 
> Government & Services Standards
> 
> AT&T
> 
> Cell: +1.609.903.3360 <tel:+1.609.903.3360>
> 
> Email: md3135@att.com <mailto:md3135@att.com>
> 
> 
> On Oct 1, 2019, at 4:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu 
> <mailto:pkyzivat@alum.mit.edu>> wrote:
> 
>> I would like to revive the point raised in the attached message that 
>> had no followup discussion.
>>
>> The problem with calling for mandatory media security on the RUE is 
>> that current VRS calls use insecure media. The VRS Provider Profile 
>> currently does not specify the RUE interface. It is the responsibility 
>> of the provider to interface (using SDP rewriting or media bridging) 
>> the calling RUE to either the terminating RUE or the other provider 
>> where the terminating RUE is connected. But it would be inappropriate 
>> (deceptive) to interface secure media to insecure media.
>>
>> There are plans to upgrade media security over the VRS Provider 
>> Profile. The following is a likely path forward, though steps 3-5 are 
>> speculation on my part:
>>
>> 1) The current VRS Provider Profile (v1) specifies insecure media. 
>> That is what is currently deployed by VRS providers.
>>
>> 2) There is a revised VRS Provider Profile (v2) in development. It 
>> hopefully will be approved by the end of this year. It calls for 
>> opportunistic media security [RFC8643] between providers. The reason 
>> is to allow gradual migration of providers to the revised profile.
>>
>> 3) Based on past history it may well take a year or more to accomplish 
>> a complete migration of all providers to the new profile. At that time 
>> all calls will be using secure media.
>>
>> 4) Once that migration is complete it will be possible to make a 
>> further revision to the profile (v3) that mandates offering 
>> unprovisional media security while still allowing the acceptance of 
>> offers of provisional media security. Again this is to allow a 
>> phase-in period.
>>
>> 5) Once that is complete, a v4 of the profile could then mandate 
>> unprovisional media security.
>>
>> If the new RUE spec isn't introduced until step (5) then media 
>> security can be achieved without any bridging or SDP rewriting. But 
>> that will likely be multiple years in the future.
>>
>> To incorporate the new RUE spec earlier some compromises will be required.
>>
>> It would be easy to change the RUE spec to use opportunistic media 
>> security. This would still result in secure media if all entities on 
>> the signaling path support it. It that won't be assured until step 
>> (3). Getting this to work with a WebRTC-based RUE (that requires 
>> secure media) will require at least SDP rewriting.
>>
>> Thoughts?
>>
>>    Thanks,
>>    Paul
>>
>> On 9/5/19 4:31 PM, Paul Kyzivat wrote:
>>> On 9/4/19 10:37 AM, Brian Rosen wrote:
>>>> Yes, for sure T.140 (RFC4103).
>>>> The providers have SBCs that anchor media, so they can handle 
>>>> security on one side but not the other.  That’s not a great answer, 
>>>> but it’s an answer.  Transcoding video is not reasonable.
>>> The soon to be released updated version of the Provider Profile 
>>> specifies opportunistic media security [RFC8643].
>>> Also, while providers use SBCs, some of them can set up e2e media for 
>>> point to point calls, where the media won't be anchored and security 
>>> can't be twiddled.
>>> I think this can be a problem if RUM requires the RUE to signal 
>>> mandatory media security, which (I think) WebRTC requires.
>>>     Thanks,
>>>     Paul
>>>> Brian
>>>>
>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström 
>>>>> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> 
>>>>> <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>>>>
>>>>>
>>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen:
>>>>>> I think our consensus is MTI:
>>>>>> Audio: G.711 and Opus
>>>>>> Video: H.264
>>>>>
>>>>>  Real-time text: T.140        (I think you said it is mandatory for 
>>>>> clients, and optional for services.)
>>>>>
>>>>>
>>>>> All these need then transport and security details specified to 
>>>>> assure interop with RUM.
>>>>>
>>>>> How can you hope for backward compatibility with legacy devices 
>>>>> when it is said in RUM that the security requirements must be met?
>>>>>
>>>>> Regards
>>>>>
>>>>> Gunnar
>>>>>
>>>>>>
>>>>>> We need to get into the details of H.264 to maintain compatibility 
>>>>>> with the WebRTC specs and as much backwards compatibility as possible.
>>>>>>
>>>>>> Anyone object?
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <pkyzivat@alum.mit.edu 
>>>>>>> <mailto:pkyzivat@alum.mit.edu> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>>>
>>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote:
>>>>>>>> Just to add: the VRS industry supports a variety of endpoints, 
>>>>>>>> many of which are hardware based and not built by VRS providers 
>>>>>>>> themselves. H.264 and G..711 therefore need to be in the MTI list.
>>>>>>>> I believe the FCC order related to compensation by compliant 
>>>>>>>> providers not that every call had to come from a compliant endpoint.
>>>>>>> Sorry if I got that wrong. I wrote that from memory and perhaps 
>>>>>>> my memory is faulty.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Paul
>>>>>>>
>>>>>>>> Best Regards
>>>>>>>> James
>>>>>>>> ________________________________________
>>>>>>>> From: Rum <rum-bounces@ietf.org <mailto:rum-bounces@ietf.org> 
>>>>>>>> <mailto:rum-bounces@ietf.org>> on behalf of Paul Kyzivat 
>>>>>>>> <pkyzivat@alum..mit.edu <http://mit.edu> 
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mit.edu&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=kUpNW-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=>>
>>>>>>>> Sent: 28 August 2019 16:48
>>>>>>>> To: rum@ietf.org <mailto:rum@ietf.org> <mailto:rum@ietf.org>
>>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
>>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote:
>>>>>>>>> I guess the question is whether we want today’s devices to have 
>>>>>>>>> a chance of being RUM compatible. I don’t think anyone will be 
>>>>>>>>> surprised if a five-year-old device is history. Is it realistic 
>>>>>>>>> for current devices to get VP8 upgrade? [Would be nice for some 
>>>>>>>>> manufacturers or others building such devices to pipe in here.]
>>>>>>>> Lets be clear about what we mean by "RUM compatible".
>>>>>>>> When Henning and I were working on this with the providers in 
>>>>>>>> 2014 and
>>>>>>>> 2015 there was an expectation that the providers would be 
>>>>>>>> required to
>>>>>>>> support the defined RUE devices, but they would also be permitted to
>>>>>>>> support their existing proprietary devices. The RUE devices 
>>>>>>>> could have
>>>>>>>> requirements that their existing devices don't meet. But calls 
>>>>>>>> between
>>>>>>>> the two were expected to work.
>>>>>>>> There was great consternation when subsequently the FCC issued a
>>>>>>>> proposed order that said only VRS calls involving RUE-compatible 
>>>>>>>> devices
>>>>>>>> would be compensated. (But that was in 2015. I presume it has 
>>>>>>>> not happened.)
>>>>>>>> If there is an intent to exclude non-RUM-compliant devices from 
>>>>>>>> use in
>>>>>>>> VRS calls then there needs to be a migration plan to get from 
>>>>>>>> here to there.
>>>>>>>>         Thanks,
>>>>>>>>         Paul
>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <br@brianrosen.net 
>>>>>>>>>> <mailto:br@brianrosen.net> <mailto:br@brianrosen.net>> wrote:
>>>>>>>>>>
>>>>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 
>>>>>>>>>> and VP8 as MTI, then we get backwards compatibility without 
>>>>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t 
>>>>>>>>>> that what we want?
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat 
>>>>>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu> 
>>>>>>>>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Inline...
>>>>>>>>>>>
>>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote:
>>>>>>>>>>>> I certainly have thoughts. The executive summary is that I 
>>>>>>>>>>>> personally believe RUM should specify Opus as the one audio 
>>>>>>>>>>>> codec MTI, and match RFC 7742's "Non-Browser" requirements 
>>>>>>>>>>>> for the video codec MTI. Rationale below.
>>>>>>>>>>>>  From an interop perspective, the important thing is that 
>>>>>>>>>>>> any given profile has (at least) one MTI video codec and (at 
>>>>>>>>>>>> least) one MTI audio codec.. I know there is a strong desire 
>>>>>>>>>>>> -- one that I share -- that these endpoints can talk to/be 
>>>>>>>>>>>> implemented in web browsers without the need for media 
>>>>>>>>>>>> transcoding.
>>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the 
>>>>>>>>>>>> former because it works without transcoding to landline PSTN 
>>>>>>>>>>>> destinations, and the latter because it sounds much, much 
>>>>>>>>>>>> better. RUM could make the same decision; or it could decide 
>>>>>>>>>>>> to move away from a codec that is as old as I am and opt to 
>>>>>>>>>>>> designate Opus as the only MTI. Given that RUM inherently 
>>>>>>>>>>>> needs to deploy into audio/video environments, backwards 
>>>>>>>>>>>> compatibility with the PSTN seems to be unnecessary baggage.
>>>>>>>>>>> Please keep in mind where we are coming from. The RUM will be 
>>>>>>>>>>> a new interface to the *existing* VRS infrastructure. That 
>>>>>>>>>>> infrastructure currently has proprietary devices that serve 
>>>>>>>>>>> the RUE function, deployed to VRS users and to Communications 
>>>>>>>>>>> Assistants (CAs, Interpreters). These have G.711 MTI, and 
>>>>>>>>>>> also *recommend* G.722.2.
>>>>>>>>>>>
>>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic.
>>>>>>>>>>>
>>>>>>>>>>>> For video: While specifying either VP8 or H.264 would be 
>>>>>>>>>>>> sufficient for system interop, and for interop with 
>>>>>>>>>>>> compliant WebRTC endpoints, I'd really prefer not to re-live 
>>>>>>>>>>>> the WebRTC video codec wars. Concretely, what I would 
>>>>>>>>>>>> propose is that RUM indicate that the video codec 
>>>>>>>>>>>> requirements are defined to be identical to those defined 
>>>>>>>>>>>> for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It 
>>>>>>>>>>>> should be made clear that RUM endpoints *are* *not* WebRTC 
>>>>>>>>>>>> Non-Browsers per se; merely that they comply with the same 
>>>>>>>>>>>> video codec requirements as WebRTC Non-Browsers.
>>>>>>>>>>> Continuing my comment above, existing devices have H.264 
>>>>>>>>>>> Constrained Baseline Profile, Level 1.3, packetization mode 1 
>>>>>>>>>>> as the MTI codec. Odds are many of these devices aren't 
>>>>>>>>>>> capable of VP8.
>>>>>>>>>>>
>>>>>>>>>>> We can't realistically require a wholesale swap out of 
>>>>>>>>>>> existing devices before the RUE defined by RUM can work. We 
>>>>>>>>>>> can *discuss* whether forcing the providers to transcode is a 
>>>>>>>>>>> practical way forward. I'm dubious.
>>>>>>>>>>>
>>>>>>>>>>>     Thanks,
>>>>>>>>>>>     Paul
>>>>>>>>>>>
>>>>>>>>>>>> /a
>>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote:
>>>>>>>>>>>>> Well, we certainly want interoperability, and I think we 
>>>>>>>>>>>>> can only get that with MTI codecs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible 
>>>>>>>>>>>>> endpoint, but we want interoperability with a WebRTC 
>>>>>>>>>>>>> browser endpoint.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure how to say this.  Maybe Adam can help.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat 
>>>>>>>>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu> 
>>>>>>>>>>>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. 
>>>>>>>>>>>>>> It now simply references webrtc RFC7742.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC 
>>>>>>>>>>>>>> browser", "WebRTC non-browser", and "WebRTC-compatible 
>>>>>>>>>>>>>> endpoint". AFAIK it assumes that each end is one of these.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is the expectation here that both the RUE and the provider 
>>>>>>>>>>>>>> comply with one of these? In particular, that the provider 
>>>>>>>>>>>>>> may simply be a "WebRTC-compatible endpoint? Notably:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    "WebRTC-compatible endpoints" are free to implement any 
>>>>>>>>>>>>>> video codecs
>>>>>>>>>>>>>>    they see fit.  This follows logically from the 
>>>>>>>>>>>>>> definition of "WebRTC-
>>>>>>>>>>>>>>    compatible endpoint".  It is, of course, advisable to 
>>>>>>>>>>>>>> implement at
>>>>>>>>>>>>>>    least one of the video codecs that is mandated for 
>>>>>>>>>>>>>> WebRTC browsers,
>>>>>>>>>>>>>>    and implementors are encouraged to do so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Similarly, the audio requirements have been changed to 
>>>>>>>>>>>>>> reference webrtc RFC7874. That one doesn't have the 
>>>>>>>>>>>>>> distinction between "WebRTC browser", "WebRTC 
>>>>>>>>>>>>>> non-browser", and "WebRTC-compatible endpoint". It applies 
>>>>>>>>>>>>>> the same requirements to all. In particular, it requires 
>>>>>>>>>>>>>> OPUS support. I don't know why it doesn't make the same 
>>>>>>>>>>>>>> endpoint distinctions as for video.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think simply referencing these documents isn't 
>>>>>>>>>>>>>> sufficient. Seems like we need a more nuanced 
>>>>>>>>>>>>>> specification of what is required, though we may still 
>>>>>>>>>>>>>> reference these docs with qualifications.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>     Paul
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Rum mailing list
>>>>>>>>>> Rum@ietf.org <mailto:Rum@ietf.org> <mailto:Rum@ietf.org>
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=
>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Rum mailing list
>>>>>>>> Rum@ietf.org <mailto:Rum@ietf.org> <mailto:Rum@ietf.org>
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=
>>>>>>> -- 
>>>>>>> Rum mailing list
>>>>>>> Rum@ietf.org <mailto:Rum@ietf.org> <mailto:Rum@ietf.org>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=
>>>>>
>>>>> -- 
>>>>> -----------------------------------------
>>>>> Gunnar Hellström
>>>>> Omnitor
>>>>> gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> 
>>>>> <mailto:gunnar.hellstrom@omnitor.se>
>>>>> +46 708 204 288
>>>>
>>
>> -- 
>> Rum mailing list
>> Rum@ietf.org <mailto:Rum@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=