[AVTCORE] Re: Comments on draft-shin-avtcore-rtp-multi-opus-01

[Sun Shin <[e-mail]>]

Hi all,
Thank you again for the feedback and discussion at IETF 124, and for the follow-up comments on the mailing list. I've just submitted the revision(03)<https://datatracker.ietf.org/doc/draft-shin-avtcore-rtp-multi-opus/> <https://datatracker.ietf.org/doc/draft-shin-avtcore-rtp-multi-opus/> of the draft that directly addresses the points raised by Timothy Terriberry and Mo Zanaty.
A brief summary of the updates is below.
Mapping families and semantics (Timothy):

  *   Clarified that mapping families define semantic interpretation of decoded channels, not RTP payload format.
  *   The draft now normatively specifies mapping family 1 only, corresponding to channel-based speaker layouts.
  *   Added explicit text describing how the SDP signaling framework is extensible to additional mapping families, without expanding the scope of this document.
  *   Defined behavior for unsupported mapping families during Offer/Answer negotiation.
  *   Clarified mandatory vs optional SDP fields (e.g., allowing omission of channel_mapping for mono/stereo cases).
  *   Made parameter bounds and mapping-family-specific limits explicit (e.g., numeric ranges, max channels for family 1).
  *   Removed normative references to third-party source code and instead normatively reference RFC 7845 for channel mapping semantics.
  *   Clarified what it means for an answerer to "support" a configuration and the rationale for the SHOULD/SHOULD NOT language in Offer/Answer procedures.

Scope and WG alignment (Mo):

  *   Added an explicit scope statement clarifying that this document defines RTP/SDP signaling only and does not define new Opus codec behavior.
  *   Added a coordination note acknowledging ongoing work in the MLCODEC WG, and clarified that future Opus codec extensions may reuse this SDP signaling framework without changes to the RTP payload format.

I sincerely appreciate the mindful feedback provided. I trust the revision will address these points and would welcome further review.
Thanks again for the helpful feedback.
Best regards,
Sun Shin

________________________________
From: Sun Shin <[e-mail]>
Sent: Friday, November 7, 2025 1:39 AM
To: Mo Zanaty (mzanaty) <mzanaty=[e-mail]>; Timothy B. Terriberry <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Comments on draft-shin-avtcore-rtp-multi-opus-01

Hi Mo,

Thank you for letting me know about the MLCODEC WG and the WG's work on extending Opus.

I'll definitely take a look at the relevant documents in the data tracker to ensure my draft is aligned with any new developments.

Best regards,
Sun Shin
________________________________
From: Mo Zanaty (mzanaty) <mzanaty=[e-mail]>
Sent: Thursday, November 6, 2025 4:56 PM
To: Sun Shin <[e-mail]>; Timothy B. Terriberry <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Comments on draft-shin-avtcore-rtp-multi-opus-01

You don't often get email from mzanaty=[e-mail]. 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 extensions to Opus which may be relevant to your draft. Please review our WG documents in the data tracker for details.

Thanks,
Mo



Cisco Confidential

________________________________
From: Sun Shin <sushin=[e-mail]>
Sent: Thursday, November 6, 2025 6:36:20 PM
To: Timothy B. Terriberry <[e-mail]>; [e-mail] <[e-mail]>
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 feedback. 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 for you as well.

Regarding the feedback you provided, I will carefully review it and promptly 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 <[e-mail]>
Sent: Thursday, November 6, 2025 11:14 AM
To: [e-mail] <[e-mail]>
Cc: Sun Shin <[e-mail]>
Subject: Comments on draft-shin-avtcore-rtp-multi-opus-01

[You don't often get email from [e-mail]. Learn why this is important 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)?