Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 28 May 2021 08:39 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E113A2083 for <avt@ietfa.amsl.com>; Fri, 28 May 2021 01:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWt8vQCRI36k for <avt@ietfa.amsl.com>; Fri, 28 May 2021 01:39:07 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) (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 6216A3A2082 for <avt@ietf.org>; Fri, 28 May 2021 01:39:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iOgbFuW/f2vbxM5BHCPPzaX7zb4innkTgIVR8LLyXwkWQF0/+zZWBIqALEkhGaFWlNmjqCbLdugqnYvsl3UURUp3mm6dJTLqNvVw2kw4fpfRzofNoEpZIUz5ioLqSYXYZkXLfl8kdPfU3aXbvDpZIWZLwOQ+ppj/4vsIlY5O+XJiUsGfg2t/aoUVOfJsMuJJOS7pawnUeXyvCR/6BdOGopsOqg4iBIDCPeNCdE6uqjUCY5kHtb6pNwxJXNsaSkRrRk9QNNlR4++rjDZV/WhsQS9rRWaUm6rXXZrsqO2TravI4wUiVE2IVANaRzwtA833K5vk3E9SZTyHlpxPdSZ+RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Q7pNYyhW1SoJI05MKPfErKx9bmxhVrNtuLTZ4pNYiw=; b=FdyNi52UQWtMJWyi2M9WdpAbK+WIQYT1VwhTbiSYKcYE/Q58cxOkZVnirDKFwCq8qZGqgQv/mYTeKi5vsh/1PhtJv5IrlPmZY7Q2T6OfXcTOCJWY4EyqhJshNikafnc5hBu33CP2YNqzQbyak25602TWm9bELYGBnMfjps3Q5ujB40FbaO/YzLLkOc5jNgeLMUCYqrqkCzOSLGZV15gOjA7IrFlPQCpNTceko78KrzekVcds4XyBSfxysinDf1v4uMpEIJRqdFTtlZ9pccHRpPb267zb8VD8k9UL8ggn3FzFzGEUtbiFEX/Ala0yWEGX41mhLtr3cFAZSUs53sR0hg==
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=5Q7pNYyhW1SoJI05MKPfErKx9bmxhVrNtuLTZ4pNYiw=; b=obHazHhSKeA8+jvv43RH/09er+mjsbwGLH3qVUnhXtXvvQpW1YRYvmWPfdRSDGMpEFyno3+aTAq/L+m5VaIT4L6GJLqNI7Er5+o4awd6/lJhecwvx2h6DpWrozgFPK9jOXN6013wIGTOCxIuM6Xg8tO9NDE+v4JAWNuc8LGGjNs=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.12; Fri, 28 May 2021 08:39:03 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::b10f:ebc0:80d:db2%7]) with mapi id 15.20.4173.021; Fri, 28 May 2021 08:39:03 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Tim Bruylants <TBR@intopix.com>, Thomas Richter <thomas.richter@iis.fraunhofer.de>, "avt@ietf.org" <avt@ietf.org>
CC: Jean-Baptiste Lorent <jb.lorent@intopix.com>
Thread-Topic: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
Thread-Index: AddLKBOH9HzaEV4jTtmQ8TPYzmKsqwFVwo+gABfRKwAAFpWSgABEymJQAABwR+AAT0NxwAAES3xQ
Date: Fri, 28 May 2021 08:39:03 +0000
Message-ID: <AM0PR07MB38601C40050406725758AB9B93229@AM0PR07MB3860.eurprd07.prod.outlook.com>
References: <AM0PR07MB38605C82DE3B4A8F677C8557932D9@AM0PR07MB3860.eurprd07.prod.outlook.com> <PR3P192MB0748357C78FECBB3CA63BE93AC269@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM> <AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269@AM0PR07MB3860.eurprd07.prod.outlook.com> <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de> <AM0PR07MB386047058704E75B425ED82493249@AM0PR07MB3860.eurprd07.prod.outlook.com> <AM0PR07MB3860D970F710BF2BBBFBEF5993249@AM0PR07MB3860.eurprd07.prod.outlook.com> <PR3P192MB07489B2703BD1C98F8AB7A8DAC229@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM>
In-Reply-To: <PR3P192MB07489B2703BD1C98F8AB7A8DAC229@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: intopix.com; dkim=none (message not signed) header.d=none;intopix.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [80.248.247.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cbb2235a-8298-49b7-737c-08d921b40c8e
x-ms-traffictypediagnostic: AM4PR0701MB2195:
x-microsoft-antispam-prvs: <AM4PR0701MB21955B517F0FC6FBA277D54593229@AM4PR0701MB2195.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 61N9i54ehBd+hIthgY/mc+Jo/maveKX2LYRBXOoxyxw52SiaGjzBTmgm6KIEqivdL5FUXPZKZntc8QnJQhpB6WgqXxD5SM7ujREl6CW0OQ2Fzfu6oxGAniOnXHp8x4fDf46B03nzeWcvvdVrspvblgSz92pYOfg15aM6wNQyhx8JkcYgki3HOCydsFpeItvW31nBwuJU9tNc3G9IeFk2iH/hToK8CODfdZxeeWFRWq8kGUhOpYW7mAbOl1Uu0TnQDQiVrbPW9EcZpoLPGk25xeUXZ/i1sltgYYcpg8A8emlYH2/oAFYIPZf1f0pvnINWxKotlFreJBWsIq20hHXN9+sMTakA4bo+hRzSHG9dgkO2+g1k2tLJpj3v8/5Yxuve3DiKY4PWXp7Kp0v2E6hafkyJMko4J3OTKgvjh4TohT+CL7rPxk3FahJePGPyw41dIvi3dbk6kKShFx6SyfCPasSbjSZBTr3wHKOrf7Dhwdnv4rguisftL7faLyolyrOFs26nW7G/xi6K0gOyxmmWstcSRtMXWZa+8jEEA21YMXVVndqV2TOuqn/+iv/r7PSL7Br9Wt9JE4EoLR8Hltk7AUnREWME1Tl8OplufOyNZKsoH8fn+BykkB5UPra6ku5dBFARLndEcss3fqF+n6G6Wm/Mm0MqtDDVneuRwHG/R+uGem18GI3tsvg2yDA5uVzprB9xQFifTwD1pJmQshles7/EI8EgIrHmnnrAO4Mivk4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(110136005)(316002)(86362001)(26005)(4326008)(53546011)(52536014)(966005)(122000001)(2906002)(38100700002)(83380400001)(6506007)(9686003)(186003)(64756008)(66556008)(66946007)(478600001)(7696005)(66446008)(66476007)(76116006)(55016002)(33656002)(44832011)(8676002)(71200400001)(5660300002)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?rKp/aykETbJlRhSpiW+Mp49tnNFVb+81OFEDNusUqOl1FqfJMRK6CO6UuwBk?= =?us-ascii?Q?uTYlK/fpHcI5RJ/DBjYBm65e7HvJg0IqYXOCMrJynIZVRqiE6j2sCIvbIxR1?= =?us-ascii?Q?5qblr0xvfki5kiT7jWEG+dvQtDfWgPGjN2qnxdrdnW2A+qbFWqTAe3Fo65up?= =?us-ascii?Q?pl/xDecga13x8Boz2E2ACKaQ2b0dlED8RHgw/NLgYPBGmrw2Z5Tq3hXCQMe0?= =?us-ascii?Q?HB74YrYKeMpW7HeubdxE4eQPslDZZmRS4juXbPQSrbnDxieKb4FDkyeoEY7L?= =?us-ascii?Q?3C1tcnPm0kGPh2VCplGvH7CpwqViC1PDW3SU1keuvw/iZhhM2er2zhhood6a?= =?us-ascii?Q?H6oaLtiK9+cGnps7/ukTlUWHJoQ8kpku90P+H3zxM0trSnP2bhQV7iEmvWwG?= =?us-ascii?Q?w26hqOrhsl4bGXt+zTyhH0e3T/J81ImvRCKvZnTOKFdMmgTO3UEgTxIWVTY7?= =?us-ascii?Q?TB3Hv5EdSWBImum6dgflnfs7gp1oUjM0GRsyyn2pTSL0Me7tLLM4W3S60mGW?= =?us-ascii?Q?TxJvIpHDh01RZ7DC+KTHJV0jVgnQHtTiUBRPqY2KMpSbtDFeoQjFewVMueMv?= =?us-ascii?Q?KJcG8up73R1MqPNSRrYf/mXhGFF5SlAJiZwEVuq6Bx9S4M3tw435gJNbBdjL?= =?us-ascii?Q?EcAtTCmaSkXnhn/0ai6pCPhHp1C5Pu+BDruLKV4u35nLIN+uuGes/ggeKdgg?= =?us-ascii?Q?ncxwSnQROP8E2y6hn+7I7DT3ACTuK+yLP9HJzG41cT3773epEcfPJgindaSC?= =?us-ascii?Q?OGRGV47GXHpbaj/d6mukzRsBUdRfGeovxkz8cy9xV7wzbwulac98qE4tt7Su?= =?us-ascii?Q?Qr35Gg6zvqwE8PNQHn1SjsjZN8pBWPPsh4AdysS8nX87KHbRZ905pucQ4CYX?= =?us-ascii?Q?B0Mn8FGmFuOVuzzP+djh/lRZhT0VAuxir4EeZrRimzkxR1Y0hwqj3JhK9y9L?= =?us-ascii?Q?XrATjTopE9qr9TSl6fMJBt8OPyLAFNrLgy7ZynhyJfZF9Z86+zPNOnRvwW6k?= =?us-ascii?Q?O8iwF0o6BSTnO+ayX1WQR3sHG+yUqu1EIk7slLdLER6UYCJtyTWtxAKGIdWQ?= =?us-ascii?Q?xM4vIP3Im2L+FeS/YrnZmOQXJe066eKql3eab9JBMP7QB6SlaOuQtlFnx3Xa?= =?us-ascii?Q?svArMP3A6lKsxlsK9tCq+cqrE3gjCrxItxF1ZQScjsy91AibqKg/tiYdhQV5?= =?us-ascii?Q?Z0gWPxTjLxSpEBeaeFev/3NGAgzkGe9WW84hybtom5rmYwBlkXSbAOcwPGl1?= =?us-ascii?Q?SuqQnC9PvYn9CyXiKDwlqL1xut/iKs5OuSW9eEOGeUeJTxeLxw7a7rbOq4Rw?= =?us-ascii?Q?qvnBVrynOvs4+emNU7B/h0ui?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cbb2235a-8298-49b7-737c-08d921b40c8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2021 08:39:03.6368 (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: 5mzpmL/9cDU2DbrpwuL2aKP8OdIR19BG6H7Acol9lnrLP8vRYv5yKiPHKamD9cuJZEcQ6mLn0/3Gs7/+PwFd/7c/ni0lwb6qarIo/FraqOY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2195
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/xUFjDCpyTn7hkmlEUzkU33c1H8Y>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 08:39:13 -0000

Hi,

First, regarding RFC 8450, that specification was probably never reviewed by the SDP directorate, so I can't really comment on that. But, I see that the RFC e.g., says nothing about whether the SDP indicates sending or receiving capabilities.

Second, nobody mandates you to use SDP, and most part of the spec is protocol independent. But, the "SDP Offer/Answer" section describes the SDP offer/answer procedures, *IF* you choose to use that mechanism for negotiating the session.

Third, I don't think you need very much text. The important thing is to say what is placed in offers and answers, whether there are constraints when generating the answer, and whether there are constraints when it comes to modifying the session. And, you do NOT  need to specify HOW to modify a session, but whether there are payload-specific constraints when doing.

Regards,

Christer

-----Original Message-----
From: Tim Bruylants <TBR@intopix.com> 
Sent: perjantai 28. toukokuuta 2021 9.49
To: Christer Holmberg <christer.holmberg@ericsson.com>om>; Thomas Richter <thomas.richter@iis.fraunhofer.de>de>; avt@ietf.org
Cc: Jean-Baptiste Lorent <jb.lorent@intopix.com>
Subject: RE: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi Christer,

I'm a little bit stuck in how to resolve and address your comments. On one hand I understand that we want the text to be clear, but on the other hand we do not want to repeat SDP specifics too much. SDP is just one way to negotiate a session, and in the case of XS it is not the most commonly used one. XS is not really intended for the classical video-call case, but rather to stream high-quality video content in a professional environment. It can be used for video conferencing, but better suited codecs exist for that use-case.

However, what is important to lay out correctly is the mapping of the media parameters into the a=fmtp field of SDP, because this is actually used by many other protocols (so, just the media description part of SDP is used).

Originally, we based our draft text on RFC 8450 (VC-2 HQ RTP Payload). In that respect, what is written there kind of fits exactly what we want with XS. Given that this is a published RFC, we are puzzeled a bit as to why our draft would need to elaborate so extensively on SDP. For sure, we'd like to allow SDP offer/answer negotiation with XS. But this is very simple: each side tells the other side what it supports, and that's it. In XS the parameters are declarative, meaning (at least that's what we want to express) that each parameter is represents an exact value and is not "inclusive" into a range of lesser values. In other words, the other side cannot expect that a "lesser" value of a parameter can work.

Your proposed structure is just to elaborate and out of scope. As such, I would ask you to consider the example of RFC 8450 (where the use-case and purpose matches that of our draft). For example: Why do we need to state anything specific on "Modifying the Session"? Isn't this layed out by SDP on how to modify a session? There's nothing specific to be put in our draft (we do not want to prevent, not suggest this functionality).

I hope you can understand our difficulty with your remarks and comments. Our proposal as such is to keep the text about SDP very short and simple. The RTP Payload draft can be used with SDP, but it's certainly not the only way.

I will be preparing an updated draft which tries to be very minimal on the SDP specifics. Unless anything is technically wrong, I really hope you can agree to it and move forward with the publication process.

Best regards,
Tim.


-----Original Message-----
From: avt <avt-bounces@ietf.org> On Behalf Of Christer Holmberg
Sent: Wednesday 26 May 2021 18:43
To: Thomas Richter <thomas.richter@iis.fraunhofer.de>de>; avt@ietf.org
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

This is a structure that is typically used for SDP offer/answer procedures:

X.  SDP Offer/Answer Procedures
     X.1.  Generic SDP Considerations
	<Here you can describe things which apply to both offers and answers>
     X.2.  Generating the Initial SDP Offer
	<Here you describe how the initial SDP offer for the session is generated>
     X.3.  Generating the SDP Answer
	<Here you describe how the answerer generates the SDP answer, including whether parameters/parameter values need to be a subset of the parameters/parameter values in the offer etc>
     X.4.  Offerer Processing of the SDP Answer
     7.5.  Modifying the Session
	<Here you describe constraints related to modification of the session, including whether there are certain parameters/parameter values that you cannot modify etc>

Regards,

Christer

-----Original Message-----
From: avt <avt-bounces@ietf.org> On Behalf Of Christer Holmberg
Sent: keskiviikko 26. toukokuuta 2021 19.38
To: Thomas Richter <https://urldefense.proofpoint.com/v2/url?u=http-3A__thomas.richter-40iis.fraunhofer.de&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=-TO1Qf7l1_qc4klRKvbuW8_eD4L8f85OB5Dahb2LQGE&e=>; avt@ietf.org
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Hi,

>> Unfortunately I don't think what you explain above is very clear in 
>> the text.
>> 
>> Consider the following.
>> 
>> The offerer sends an offer. The offerer specifies the characteristics 
>> that the offerer wants to receive. Similarly, the answer specifies 
>> the characteristics that the answerer wants to receive - the answerer 
>> does NOT specify what it is going to send. which I think the text is 
>> currently describing.
>
> Sorry to sound confused, but maybe you could explain a bit better. To my understanding, it is the offerer that describes what it offers to send, and not the other way around? 
> Maybe I misunderstand something very fundamental? Sorry to ask these elementary questions, but this is important for the text.

In SDP Offer/Answer, the default is to indicate what you are willing to RECEIVE :)

Typically your receiving capabilities also implicitly indicate what you are able to send. For example, if I am indicating that I am willing to receive codec X it normally means that I am also able to send codec X.

 But, there are cases where that is not true, especially when it comes to video codes where you typically have more parameters associated with the codec, and one needs to explicitly indicate sending capabilities. 

---

>> "The receiver SHALL ignore any unrecognized parameter or invalid 
>> parameter value."
>> 
>> First, In my opinion invalid parameters values shall trigger an error.
>> 
>> Second, what is an unrecognized parameter?
>
> I wonder why we need to specify this, i.e. what a receive does about 
> parameters it does not recognize? Essentially, this is a problem of 
> "foreward compatibility". Wouldn't it be a matter of implementation whether the receiver accepts an offer (note well, the receiver), and attempts to decode a stream on a "best effort" basis, keeping in mind that the stream itself includes additional means to identify required capabilities necessary for a successful decode.
>
> If that is not an option, we would/could need means to identify the 
> type of parameters in a foreward compatible way. I.e., conventions by which we would identify in the future parameters a receiver can safely ignore and attempt to decode, and parameters a receiver cannot safely ignore.

I think it is fine to say that unrecognized parameters shall be ignored. It is then up to future specifications to worry about backward compatibility, rather than this specification worrying about forward compatibility.

>> Also, the text does not say what restrictions (if any) there are when 
>> it comes to modify the stream during a session. Is it allowed to 
>> modify any/all characteristics?
>
> My understanding is that you cannot modify characteristics during a 
> session. If you need to modify, you need to setup a new session and 
> cancel the current one. For JPEG XS stream decoders, one cannot expect that an instanciated decoder can decode from modified parameters in mid-stream level. That is, if you start decoding in full-HD, and then stream parameters become 8K, the decoder will have to abort.

These kind of things need to be specified. I don't think it needs to be forbidden to try to modify something, because there could be text that strongly recommends against doing it.

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=LtefQiLhdrXwUycah7Zmsayk_dtHF-hMEBwHo6Dpet0&s=1vZTuFjI-QbexP5oX9pga35dZZzthXGgn7S8Zgod9LE&e=