From: Sun Shin <sushin@nvidia.com>
To: "Mo Zanaty (mzanaty)" <mzanaty=40cisco.com@dmarc.ietf.org>, "Timothy B.
 Terriberry" <tterribe@xiph.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: Comments on draft-shin-avtcore-rtp-multi-opus-01
Thread-Index: AQHcT1GaQX7mppgohkm/9m8fx5DRd7TmSjJZgAAZ8YCAAAE2Sg==
Date: Fri, 7 Nov 2025 09:39:09 +0000
Message-ID: 
 <CH2PR12MB9517CD106063C82C0C2D86E3B2C3A@CH2PR12MB9517.namprd12.prod.outlook.com>
References: <98906f50-ba25-1b3a-f73b-2e0f019eb22b@xiph.org>
 <CH2PR12MB951776A5B6ED4390A5541728B2C2A@CH2PR12MB9517.namprd12.prod.outlook.com>
 <DS0PR11MB8181E53DD23B81C99E5A1579B4C3A@DS0PR11MB8181.namprd11.prod.outlook.com>
In-Reply-To: 
 <DS0PR11MB8181E53DD23B81C99E5A1579B4C3A@DS0PR11MB8181.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_c8f49a32-fde3-48a5-9266-b5b0972a22dc_Enabled=True;
 MSIP_Label_c8f49a32-fde3-48a5-9266-b5b0972a22dc_SiteId=5ae1af62-9505-4097-a69a-c1553ef7840e;
 MSIP_Label_c8f49a32-fde3-48a5-9266-b5b0972a22dc_SetDate=2025-11-07T00:53:29.3834342Z;
 MSIP_Label_c8f49a32-fde3-48a5-9266-b5b0972a22dc_Name=Cisco Confidential;
 MSIP_Label_c8f49a32-fde3-48a5-9266-b5b0972a22dc_ContentBits=3;
 MSIP_Label_c8f49a32-fde3-48a5-9266-b5b0972a22dc_Method=Standard;
x-ms-reactions: allow
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH2PR12MB9517:EE_|PH7PR12MB6811:EE_
x-ms-office365-filtering-correlation-id: 129e5e36-91f3-44e8-88ad-08de1de180cf
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: 
 BCL:0;ARA:13230040|366016|376014|1800799024|13003099007|8096899003|7053199007|38070700021;
x-microsoft-antispam-message-info: 
 =?Windows-1252?Q?LrXIr9BZie8AEAx7nWltaypCeXHbn5tmxH3/4qY9+AFAKkPMTv62WRB8?=
 =?Windows-1252?Q?8B+54xhPUlhJGGLlUPIe03i5QkEVuvJluqalVZrJm93+g6IZBVdTGeSq?=
 =?Windows-1252?Q?DRVdyk+fvAsEBp87zQP4sSGA31i883dbTWtpwx3FXtIXnsBmBBr8q9F9?=
 =?Windows-1252?Q?6H0IdSX4TVz+PIOqcweCoPPdDb2aWB2MuR6Em+HKxFXFav7auxiFnCwo?=
 =?Windows-1252?Q?A96hOjyJh/uoYj9OfGyzy1xs3mKD5NZBp7mkuGTI3yu+XBblCtqRTwvh?=
 =?Windows-1252?Q?cRC5iPOa3pZyLMA755ip8nhuCBT04l0DayBKMb1XTyO3UsSAxf3ef4+J?=
 =?Windows-1252?Q?HLxM7aSg0gdzlhkHXdaBD85sx+JBKeWx9qd3vO0nRypWR0eTsFCMk1SK?=
 =?Windows-1252?Q?+XgMEks7WYIv3F1Hb8i6tgG/4MUQMbNcm9G4w2XndXJmBeysjOvzvNOk?=
 =?Windows-1252?Q?S8BsbFP8RyR8GXNQd4HLQCLtfERvvyOUKgClPBYtY7I80a5+vPJ6RO3o?=
 =?Windows-1252?Q?6B7PJfg5lRvUIX3Z86aYItHmJ2qWrG6pj9sGrwTHVET8s7gx1aK45+L8?=
 =?Windows-1252?Q?mARPNDKRb5II1zbP5OW3EfIGxFbYCU5iJ2lG3Q4DFWIj8IlHjYSELgQX?=
 =?Windows-1252?Q?QNfzbTK9ZCZtAdRiUe56initAobGroi9Mua9JhWzWQBSoHJvXREvrD5L?=
 =?Windows-1252?Q?toXgGy5ztwrcchJEuf2EOY0Nsi67Wyhc9/DnLd3Zo7WOOiEN96mPkRsH?=
 =?Windows-1252?Q?JtjukBBuFPuN9dO4srYwRIK7EmtVVSA4AjncwVORxstQxP8d8uNA0K7o?=
 =?Windows-1252?Q?fR1eIL5C4ZXHOrAb4MElZbBriJ7FANwF6/Ne9CwzmQoucHnQ8QvM+WXN?=
 =?Windows-1252?Q?dYvd78eD/q61yafo9d46VeH1sAdwnsMIYGldSp47QTpeBBC+lbErnSY8?=
 =?Windows-1252?Q?0GnrYNcmSOQx2p216a/5P9XcKE2DXwF7QwNexHUMOlN9gHIWewyPinS7?=
 =?Windows-1252?Q?cfDsK4TuLxJ/pGs80yS4dbc0AqP8Itq+cINDITrZEr3hwPRmtKnJPqzm?=
 =?Windows-1252?Q?bU+oJGhPpfrqcMJoqGiVZiUshAVhJXeCAB1uRsR502rkj/XrERJH7Wkb?=
 =?Windows-1252?Q?UdVwJTKcpkS7J254oQnR2TQmNpFPfz++7hx41PAS2prs6zBhJSgN62gm?=
 =?Windows-1252?Q?12uvxpOF4oTKmCGyU2QnK59lFmjorEGuDegzzwCnWCeGHqXgAxu38x3N?=
 =?Windows-1252?Q?m6eR4ErTOd5vdhy88Y3/5BMhF9oxUmpCOj2FlOjD9qbUcLhN86t4dcTV?=
 =?Windows-1252?Q?hjB3ov+hUufX3HXfJIWc+zRsGus/i+xJk0ltzaMML1EaW45pdtTlZf0C?=
 =?Windows-1252?Q?lyQ0Jn7SSlvE2GGqf0BXfNGeko28ew7DQwasB4a6sHSkHMD5a27Hfvy/?=
 =?Windows-1252?Q?vrG7MogFaRHqY90aImhCBaT+3i0JRxOPuxcKsz8CRWAtWC3tRjMYRhbm?=
 =?Windows-1252?Q?F2XzQUn+b23i21FmX7VUXZqXxIfL3s1SICCqleuE9JHosCEpZnyaFNuW?=
 =?Windows-1252?Q?0o5LPbKePhMFv+RpZmYvA7m07J0UxUYAJ08vMdh5j1/RgUqUVTspN8TA?=
 =?Windows-1252?Q?Vsa8D00O1r0OiTXKf2VUe8wx?=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR12MB9517.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(13003099007)(8096899003)(7053199007)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?Windows-1252?Q?bDCMzV0/P3wK1770266figGrdigAOQbTpSjbKsXcc1mize4HgRb3M4cl?=
 =?Windows-1252?Q?L9ICeLGswh0sl3sXZ/XwIUZDmNwWXfSgZa/yEQJ7g4y8Edi4p4w/5nzD?=
 =?Windows-1252?Q?Lj6DnoMw06vPlgb5DwfegKyuEdt0qIOk+QV0IOppPzVg2oPaisu4IyIZ?=
 =?Windows-1252?Q?KoC4ZUQbOQ8lXL//DvEg3ycD5FzGZzh75MAZQmkmbIAC+8mjFGVZYi2v?=
 =?Windows-1252?Q?FYHlYrMYuP+/bbBD+m0oMWP442M1owtS/BNS8ZxXbJe9klIyRNMIos2j?=
 =?Windows-1252?Q?lhXkzY9z3/xRw8TdI/ZvKQ5zUxsLX6GnB+Pr0EB4WJkZPm9p7OV73ug6?=
 =?Windows-1252?Q?zTMY610MQDPm3a193yqxrwI3AJfx03ACXo1A++iwZJ6SBB+pOGKCOcAA?=
 =?Windows-1252?Q?ZIKXH+SzwwHj9JUtHmWcoZKjdbOigI9gkDhykcCZhJc/le9l+1VlwVK/?=
 =?Windows-1252?Q?ClJfvJcH3EK20LbVSAbT6+tPPIStZFEp7dftLfXvl7r/VodJo2bdEfz5?=
 =?Windows-1252?Q?/Twwd4pg4H8nYL3tps9aA0LRsifLej7yYnbTIiaawoED7To1Tzl//mF6?=
 =?Windows-1252?Q?6AYSBKDuGBTx7DOC26ymH5Ar6T3HltXdQdZNobFrn2k4oi9qo5ZFx6q5?=
 =?Windows-1252?Q?oU1+dlnQDJPCXyC9hylB3YJZxF79FN+0LBMXXuffu9d6/U6+QFWQRwMF?=
 =?Windows-1252?Q?UYVntd7o7tcXpEEa8R9bj5nU87aFU/YhNaf6Jume2VS6mnvfxpb0K+1y?=
 =?Windows-1252?Q?IPugOj7H1OizT3SOqAd5Algi6prNnkjRAArQrfykWr2an1V6jxA1ocSp?=
 =?Windows-1252?Q?UL+VPOlq3BjAHZPmnQ8qjTCO/9afMUOuOldfLABx7ZP91wKOjKPg0llj?=
 =?Windows-1252?Q?ugFmPAH8lDWEMX5DYLInALHAAxESS+EI7BPPotZv4fTSZldM+NkAe8BQ?=
 =?Windows-1252?Q?riDDbNBMXrISkWH4xvw5OSLLBTVsw0QW3xRHoHJxLJZenuvBVmuraDu6?=
 =?Windows-1252?Q?j4s3jg+yderHU6UVfB+l0XvnF6PHNrHLeMWfgNtriPZdgdGOInxVqjHH?=
 =?Windows-1252?Q?HCLF26HsdqERlduiShOV5QbiobceBr6LLamPKqfr8Pjft3sO1QWWNY7O?=
 =?Windows-1252?Q?bu4Aldv7F0NFIDyzLh5XOv6Wf4SRR2Aa/inbpwbLyySJ8QwkqM3hpbNy?=
 =?Windows-1252?Q?nGVqV2nZruAEAqY7Fz4GVui23DTOUwhXHiZBO5y7g7jXYdrvXVb0obc+?=
 =?Windows-1252?Q?UhRYVJSWwgAmm+xlbkW9gepLBPY+Ea8xoKe3WD+ZEw8f5WhypYXlueQR?=
 =?Windows-1252?Q?F5mol5kSQkd4DAw4VZktYqVoIrXvoZ72UmtA3V2Uo/Cjl8adu9ZEOq73?=
 =?Windows-1252?Q?xdTXpIELmtqxaR7LYkdaKLBFEgIz7ew5gVQWr/lx5ZyDjnARQZ+3o22d?=
 =?Windows-1252?Q?3jqDKx7H0JFy4HAg/gAL+/3ethYkWRXGljic92F6GNGD/oNq7df4rSEP?=
 =?Windows-1252?Q?c14ZdiTbrtX7p1FG5pRYRegGp69EcYFo4Cxmfouqkm+cViKnR+SRUfAC?=
 =?Windows-1252?Q?Wbfrj55v5xRMo1kijESzRjOMg373DUyci7TGeMtP3rcE/Axmup6woRfH?=
 =?Windows-1252?Q?MQC+46j2ZBMXFCET3dqISBxAfzkesOvi22c7qTFCgIKsxbctKFwe9lC6?=
 =?Windows-1252?Q?Vk8sOPPtykFyWrqsOzLhuO8UMobJzBgYi0DIc7hJThRnZT2Y/o1eYw?=
 =?Windows-1252?Q?=3D=3D?=
Content-Type: multipart/alternative;
	boundary="_000_CH2PR12MB9517CD106063C82C0C2D86E3B2C3ACH2PR12MB9517namp_"
MIME-Version: 1.0
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB9517.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 129e5e36-91f3-44e8-88ad-08de1de180cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2025 09:39:09.9101
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 2pPtpXB3tnEsiFORjHANfqlLPerd+CpjSxLJs9x6MVkpb/i+dn3wB+IzSsMTGfryKpM91VKoCRYEW7ZvZ24RTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6811
X-MailFrom: sushin@nvidia.com
X-Mailman-Rule-Hits: implicit-dest
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-avt.ietf.org-0;
 nonmember-moderation; administrivia; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
Message-ID-Hash: FF47O77FM26SXGLVQRMJL5UZ73F2L3NH
X-Message-ID-Hash: FF47O77FM26SXGLVQRMJL5UZ73F2L3NH
X-Mailman-Approved-At: Fri, 07 Nov 2025 05:32:02 -0800
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BAVTCORE=5D_Re=3A_Comments_on_draft-shin-avtcore-rtp-multi-opus-?=
	=?utf-8?q?01?=
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/avt/bokm4XI8L57ioB0LcLSn8KAAurY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Owner: <mailto:avt-owner@ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Subscribe: <mailto:avt-join@ietf.org>
List-Unsubscribe: <mailto:avt-leave@ietf.org>

--_000_CH2PR12MB9517CD106063C82C0C2D86E3B2C3ACH2PR12MB9517namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Mo,

Thank you for letting me know about the MLCODEC WG and WG=92s work on exten=
ding Opus.

I'll definitely take a look at the relevant documents in the data tracker t=
o ensure my draft is aligned with any new developments.

Best regards,
Sun Shin
________________________________
From: Mo Zanaty (mzanaty) <mzanaty=3D40cisco.com@dmarc.ietf.org>
Sent: Thursday, November 6, 2025 4:56 PM
To: Sun Shin <sushin@nvidia.com>; Timothy B. Terriberry <tterribe@xiph.org>=
; avt@ietf.org <avt@ietf.org>
Subject: Re: Comments on draft-shin-avtcore-rtp-multi-opus-01

You don't often get email from mzanaty=3D40cisco.com@dmarc.ietf.org. Learn =
why this is important<https://aka.ms/LearnAboutSenderIdentification>
External email: Use caution opening links or attachments

Hi Sun,

You should be aware that the MLCODEC WG (which I co-chair) is defining exte=
nsions to Opus which may be relevant to your draft. Please review our WG do=
cuments in the data tracker for details.

Thanks,
Mo



Cisco Confidential

________________________________
From: Sun Shin <sushin=3D40nvidia.com@dmarc.ietf.org>
Sent: Thursday, November 6, 2025 6:36:20 PM
To: Timothy B. Terriberry <tterribe@xiph.org>; avt@ietf.org <avt@ietf.org>
Subject: [AVTCORE] Re: Comments on draft-shin-avtcore-rtp-multi-opus-01

Hi Timothy,

Thank you for taking the time to provide a detailed summary and valuable fe=
edback. I really appreciate your consideration.

Additionally, I'd like to share the WebRTC reference link: <https://webrtc-=
review.googlesource.com/c/src/+/129768>.
After double-checking, I'm confident that this link should be accessible fo=
r you as well.

Regarding the feedback you provided, I will carefully review it and promptl=
y share an updated revision with this mailing list once it's complete.

Thank you again for your thoughtful input!

Best regards,
Sun Shin
________________________________
From: Timothy B. Terriberry <tterribe@xiph.org>
Sent: Thursday, November 6, 2025 11:14 AM
To: avt@ietf.org <avt@ietf.org>
Cc: Sun Shin <sushin@nvidia.com>
Subject: Comments on draft-shin-avtcore-rtp-multi-opus-01

[You don't often get email from tterribe@xiph.org. Learn why this is import=
ant at https://aka.ms/LearnAboutSenderIdentification ]

External email: Use caution opening links or attachments


Hi Shun,

Thanks again for working on this and bringing it to avtcore.

To follow up on the discussion in the room, if you are unsure about the
purpose of mapping families in RFC 7845, I think the easiest way to
think about them is that they are used to assign a _meaning_ to the
audio data transmitted on the wire. They do not affect the format of the
RTP payload itself (beyond establishing the number of streams and number
of channels those get decoded into), but they tell you what those
channels are. This can be simple speaker positions (mapping families 0
and 1), or spherical harmonics as in Ambisonics (mapping families 2 and
3, see RFC 8486), or something that must be agreed upon externally
(mapping family 255). I think that even if this draft limits itself to
mapping family 1, we should have a plan for how additional families
could be supported. That said, I agree with Jean-Marc that adding
support for mapping families 2 and 255 should be relatively painless.

I also had a few more pedantic comments on your draft that I thought
were better suited to the mailing list than our limited meeting time. I
don't think any of these should block working group adoption of the
draft (and I would be in support of adoption).

1) In section 6.1.3, are all of the fields listed there mandatory? Can I
leave out channel_mapping for 1 or 2 output channels with one stream
(i.e., the equivalent of mapping family 0)?

2) RFC 7845 imposes some implicit limitations on the values of the
num_streams, coupled_streams, and channel_mapping fields. E.g., because
they are encoded in octets and treated as unsigned, they cannot be
negative or exceed 255. Encoding them as text in SDP does not enforce
those limitations. Should this draft make them explicit?

There are also some explicit limitations are tied to the mapping family,
e.g., no more than 8 output channels for mapping family 1. This draft
never discusses individual mapping families, so it may not be clear
which of those limitations are intended to apply.

3) It is probably not a great idea to define channel_mapping with a
normative reference to third-party source code (I tried visiting the
libwebrtc link, but it just served me a blank page... probably that is
some issue on my end, but I think it illustrates the point). Is this
just RFC 7845's channel mapping as a comma-separated list? Does it
support silence channels (255)?

4) For the SHOULD NOT in Section 7, what does it mean for the answerer
to support the offered configuration? The ability to parse the format?
The ability to decode or record it? The ability to render to some number
(>2) of speakers?

What reasons would someone have for silently down-converting to stereo
anyway (i.e., why is this SHOULD NOT instead of MUST NOT)?

5) What reasons would someone have for not including a stereo
alternative (again, why is this a SHOULD and not a MUST)?

--_000_CH2PR12MB9517CD106063C82C0C2D86E3B2C3ACH2PR12MB9517namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c=
olor: rgb(0, 0, 0);">
Hi Mo,<br>
<br>
Thank you for letting me know about the MLCODEC WG and WG=92s work on exten=
ding Opus.<br>
<br>
I'll definitely take a look at the relevant documents in the data tracker t=
o ensure my draft is aligned with any new developments.<br>
<br>
Best regards,<br>
Sun Shin</div>
<div id=3D"appendonsend" dir=3D"ltr"></div>
<hr style=3D"display: inline-block; width: 98%;">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><span style=3D"font-family: Calibri, =
sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b>&nbsp;Mo Zan=
aty (mzanaty) &lt;mzanaty=3D40cisco.com@dmarc.ietf.org&gt;<br>
<b>Sent:</b>&nbsp;Thursday, November 6, 2025 4:56 PM<br>
<b>To:</b>&nbsp;Sun Shin &lt;sushin@nvidia.com&gt;; Timothy B. Terriberry &=
lt;tterribe@xiph.org&gt;; avt@ietf.org &lt;avt@ietf.org&gt;<br>
<b>Subject:</b>&nbsp;Re: Comments on draft-shin-avtcore-rtp-multi-opus-01</=
span>
<div>&nbsp;</div>
</div>
<table dir=3D"revert" cellspacing=3D"0" cellpadding=3D"0" style=3D"text-ind=
ent: revert; line-height: revert; white-space: revert; background-color: re=
vert; display: table; margin: revert; width: 100%; height: revert; table-la=
yout: fixed; color: revert; border-collapse: collapse; border-spacing: 0px;=
 box-sizing: border-box;">
<tbody>
<tr style=3D"background-color: revert;">
<td dir=3D"revert" style=3D"text-indent: revert; line-height: revert; white=
-space: revert; border-width: revert; border-style: revert; border-color: r=
evert; background-color: rgb(166, 166, 166); padding: 7px 2px; word-break: =
revert; color: revert; width: 0px; height: revert;">
</td>
<td dir=3D"revert" style=3D"text-align: left; text-indent: revert; line-hei=
ght: revert; white-space: revert; border-width: revert; border-style: rever=
t; border-color: revert; background-color: rgb(234, 234, 234); padding: 7px=
 5px 7px 15px; word-break: revert; color: rgb(33, 33, 33); width: 100%; hei=
ght: revert;">
<div dir=3D"revert" style=3D"text-align: left; text-indent: revert; line-he=
ight: revert; white-space: revert; font-family: wf_segoe-ui_normal, &quot;S=
egoe UI&quot;, &quot;Segoe WP&quot;, Tahoma, Arial, sans-serif; color: reve=
rt;">
<span style=3D"letter-spacing: revert; background-color: revert; line-heigh=
t: revert;">You don't often get email from mzanaty=3D40cisco.com@dmarc.ietf=
.org.
<a href=3D"https://aka.ms/LearnAboutSenderIdentification" style=3D"color: r=
evert; display: revert; background-color: revert;">
Learn why this is important</a></span></div>
</td>
<td dir=3D"revert" style=3D"text-align: left; text-indent: revert; line-hei=
ght: revert; white-space: revert; border-width: revert; border-style: rever=
t; border-color: revert; background-color: rgb(234, 234, 234); padding: 7px=
 5px; word-break: revert; color: rgb(33, 33, 33); width: 75px; height: reve=
rt;">
</td>
</tr>
</tbody>
</table>
<table style=3D"background-color: rgb(255, 235, 156);">
<tbody>
<tr>
<td><span style=3D"font-family: verdana; font-size: 10px; color: black;"><b=
>External email: Use caution opening links or attachments</b></span></td>
</tr>
</tbody>
</table>
<br>
<div dir=3D"ltr">Hi Sun,</div>
<div dir=3D"ltr"><br>
</div>
<div dir=3D"ltr">You should be aware that the MLCODEC WG (which I co-chair)=
 is defining extensions to Opus which may be relevant to your draft. Please=
 review our WG documents in the data tracker for details.&nbsp;</div>
<div dir=3D"ltr"><br>
</div>
<div dir=3D"ltr">Thanks,</div>
<div dir=3D"ltr">Mo</div>
<div dir=3D"ltr"><br>
</div>
<div id=3D"x_ms-outlook-mobile-signature" dir=3D"ltr"></div>
<br>
<p style=3D"margin: 5pt; font-family: Calibri; font-size: 8pt; color: rgb(0=
, 0, 0);">
Cisco Confidential</p>
<hr style=3D"display: inline-block; width: 98%;">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><span style=3D"font-family: Calibri=
, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b>&nbsp;Sun =
Shin &lt;sushin=3D40nvidia.com@dmarc.ietf.org&gt;<br>
<b>Sent:</b>&nbsp;Thursday, November 6, 2025 6:36:20 PM<br>
<b>To:</b>&nbsp;Timothy B. Terriberry &lt;tterribe@xiph.org&gt;; avt@ietf.o=
rg &lt;avt@ietf.org&gt;<br>
<b>Subject:</b>&nbsp;[AVTCORE] Re: Comments on draft-shin-avtcore-rtp-multi=
-opus-01</span>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr" class=3D"x_x_elementToProof" style=3D"font-family: Aptos, =
Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; fo=
nt-size: 11pt; color: rgb(0, 0, 0);">
Hi Timothy,<br>
<br>
Thank you for taking the time to provide a detailed summary and valuable fe=
edback. I really appreciate your consideration.&nbsp;</div>
<div dir=3D"ltr" class=3D"x_x_elementToProof" style=3D"font-family: Aptos, =
Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; fo=
nt-size: 11pt; color: rgb(0, 0, 0);">
<br>
Additionally, I'd like to share the WebRTC reference link: &lt;<a href=3D"h=
ttps://webrtc-review.googlesource.com/c/src/+/129768" originalsrc=3D"https:=
//webrtc-review.googlesource.com/c/src/+/129768">https://webrtc-review.goog=
lesource.com/c/src/+/129768</a>&gt;.<br>
After double-checking, I'm confident that this link should be accessible fo=
r you as well.<br>
<br>
Regarding the feedback you provided, I will carefully review it and promptl=
y share an updated revision with this mailing list once it's complete.<br>
<br>
Thank you again for your thoughtful input!<br>
<br>
Best regards,<br>
Sun Shin</div>
<div id=3D"x_x_appendonsend" dir=3D"ltr"></div>
<hr dir=3D"ltr" style=3D"display: inline-block; width: 98%;">
<div id=3D"x_x_divRplyFwdMsg" dir=3D"ltr"><span style=3D"font-family: Calib=
ri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b>&nbsp;Ti=
mothy B. Terriberry &lt;tterribe@xiph.org&gt;<br>
<b>Sent:</b>&nbsp;Thursday, November 6, 2025 11:14 AM<br>
<b>To:</b>&nbsp;avt@ietf.org &lt;avt@ietf.org&gt;<br>
<b>Cc:</b>&nbsp;Sun Shin &lt;sushin@nvidia.com&gt;<br>
<b>Subject:</b>&nbsp;Comments on draft-shin-avtcore-rtp-multi-opus-01</span=
>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr" class=3D"x_x_PlainText" style=3D"font-size: 11pt;">[You do=
n't often get email from tterribe@xiph.org. Learn why this is important at
<a href=3D"https://aka.ms/LearnAboutSenderIdentification">https://aka.ms/Le=
arnAboutSenderIdentification</a>&nbsp;]<br>
<br>
External email: Use caution opening links or attachments<br>
<br>
<br>
Hi Shun,<br>
<br>
Thanks again for working on this and bringing it to avtcore.<br>
<br>
To follow up on the discussion in the room, if you are unsure about the<br>
purpose of mapping families in RFC 7845, I think the easiest way to<br>
think about them is that they are used to assign a _meaning_ to the<br>
audio data transmitted on the wire. They do not affect the format of the<br=
>
RTP payload itself (beyond establishing the number of streams and number<br=
>
of channels those get decoded into), but they tell you what those<br>
channels are. This can be simple speaker positions (mapping families 0<br>
and 1), or spherical harmonics as in Ambisonics (mapping families 2 and<br>
3, see RFC 8486), or something that must be agreed upon externally<br>
(mapping family 255). I think that even if this draft limits itself to<br>
mapping family 1, we should have a plan for how additional families<br>
could be supported. That said, I agree with Jean-Marc that adding<br>
support for mapping families 2 and 255 should be relatively painless.<br>
<br>
I also had a few more pedantic comments on your draft that I thought<br>
were better suited to the mailing list than our limited meeting time. I<br>
don't think any of these should block working group adoption of the<br>
draft (and I would be in support of adoption).<br>
<br>
1) In section 6.1.3, are all of the fields listed there mandatory? Can I<br=
>
leave out channel_mapping for 1 or 2 output channels with one stream<br>
(i.e., the equivalent of mapping family 0)?<br>
<br>
2) RFC 7845 imposes some implicit limitations on the values of the<br>
num_streams, coupled_streams, and channel_mapping fields. E.g., because<br>
they are encoded in octets and treated as unsigned, they cannot be<br>
negative or exceed 255. Encoding them as text in SDP does not enforce<br>
those limitations. Should this draft make them explicit?<br>
<br>
There are also some explicit limitations are tied to the mapping family,<br=
>
e.g., no more than 8 output channels for mapping family 1. This draft<br>
never discusses individual mapping families, so it may not be clear<br>
which of those limitations are intended to apply.<br>
<br>
3) It is probably not a great idea to define channel_mapping with a<br>
normative reference to third-party source code (I tried visiting the<br>
libwebrtc link, but it just served me a blank page... probably that is<br>
some issue on my end, but I think it illustrates the point). Is this<br>
just RFC 7845's channel mapping as a comma-separated list? Does it<br>
support silence channels (255)?<br>
<br>
4) For the SHOULD NOT in Section 7, what does it mean for the answerer<br>
to support the offered configuration? The ability to parse the format?<br>
The ability to decode or record it? The ability to render to some number<br=
>
(&gt;2) of speakers?<br>
<br>
What reasons would someone have for silently down-converting to stereo<br>
anyway (i.e., why is this SHOULD NOT instead of MUST NOT)?<br>
<br>
5) What reasons would someone have for not including a stereo<br>
alternative (again, why is this a SHOULD and not a MUST)?</div>
</body>
</html>

--_000_CH2PR12MB9517CD106063C82C0C2D86E3B2C3ACH2PR12MB9517namp_--