AVTCORE

Summary

The AVTCORE working group met at IETF 126. The session covered status updates on working group drafts, followed by presentations and technical discussions on frame acknowledgement, RTP payload formats for V-DMC, RTP/SDP signaling for multichannel Opus, and a new SRTP cipher suite utilizing GCM-SST.

Key Discussion Points

1. WG Status Update

Presenter: Jonathan Lennox
Slides: AVTCore 126 Chair Slides
Discussion:
- RFC 9993 (Haptics) has been published.
- The V-3C draft is currently with the RFC Editor.
- JPEG XS (3rd edition) and green metadata are under IESG review.
- draft-ietf-avtcore-hevc-webrtc completed Working Group Last Call (WGLC) with only minor editorial comments.
- The RTP over QUIC draft completed WGLC but received insufficient feedback. Chairs urged the working group (specifically targeting Magnus Westerlund) to review and comment.
- Several adopted drafts have expired. Senders and authors are requested to update them.
- For the V-3C document, Bernard Aboba will remain listed as a co-author during Auth48 to reflect his contributions. This was agreed to by the AD (Alan Ford).

2. Frame Acknowledgement

Presenter: Erik Myhre
Slides: Frame Acknowledgement
Related Draft: draft-ietf-avtcore-frame-acknowledgement
Discussion:
- The draft has been officially adopted and moved to the IETF WG repository.
- To prevent excessive state tracking on the receiver side when feedback is not regularly requested, a negotiable status window (default size 255) has been introduced.
- Senders are explicitly directed to request feedback regularly and adhere to RTCP feedback timing rules to prevent feedback amplification.
- A design question was raised on whether to include a flag signaling that a frame was received completely but could not be decoded (e.g., due to missing dependencies).
  - Jonathan Lennox suggested keeping the mechanism focused purely on decodability (if received and decoded, acknowledge; if not, do not acknowledge) and relying on separate transport-layer mechanisms (like NACKs) for packet receipt. Erik Myhre agreed.
- Clarifying the definition of a "frame" in the context of tile/slice streaming (e.g., H.266, AV1):
  - Moe Zanaty noted that "frame" usually means a full temporal unit, and using it for slices or tiles might introduce confusion.
  - Magnus Westerlund noted that in VR/XR use cases, identifying independent decodable units (like tiles) is highly valuable when some parts of the picture are deliberately discarded.
  - Jonathan Lennox suggested leaving this under encoder control, potentially defining start/end flags so encoders can specify the exact unit of granularity they care about.

3. RTP Payload Format for V-DMC

Presenter: Presenter from IntoZero
Slides: V-DMC slides
Related Draft: draft-ietf-avtcore-rtp-vdmc
Discussion:
- The draft has been updated to version -02.
- Component parameters were updated to match the final MPEG FDIS specification.
- The fragmentation unit part, SDP parameters section, and security concerns section were revised based on feedback.
- The presenter requested WGLC.
- Jonathan Lennox suggested holding the WGLC briefly until the closely related V-3C document finishes RFC Editor processing to ensure any late-stage feedback is incorporated.

4. RTP/SDP for Opus Multistream

Presenter: Shuaiyang Sun
Slides: RTP/SDP for Opus Multistream
Discussion:
- Use case: Cloud gaming clients need multi-channel surround sound. Currently, web browsers reject multi-channel Opus offerings, forcing developers to use a spec-violating workaround called "SDP merging." W3C is moving to deprecate SDP merging.
- During the adoption call, Philipp Hancke objected to introducing a new multiopus MIME type and suggested extending the existing standard opus namespace to support channel counts (e.g., opus/48000/6).
- In the session chat, Philipp Hancke noted: "if mid=0 would offer opus and multiopus it would be accepted."
- Moe Zanaty agreed with Philipp's suggestion, noting that other standards and contexts (like iAMF/YouTube) use the standard opus type with channel mapping parameters without requiring a new MIME type.
- Harald Alvestrand explained the history of the multiopus implementation (introduced in Chromium as an isolated path to prevent breaking standard stereo Opus implementations) and supported transitioning to a clean standard extension.
- Alan Ford and Jonathan Lennox discussed backwards compatibility. If a server offers opus/48000/6 alongside opus/48000/2 as separate payload types, a legacy client should gracefully ignore the multichannel format and negotiate standard stereo.
- Consensus: The group agreed to extend the standard opus payload format to support multi-channel signaling rather than adopting a new multiopus media type.

5. GCM-SST in SRTP

Presenter: Magnus Westerlund & John Preuß Mattsson
Slides: GCM-SST in SRTP
Discussion:
- GCM-SST (Galois Counter Mode with Strong Secure Tags) is an AEAD algorithm designed to address standard GCM's key-compromise vulnerability on tag forgery. By deriving unique authentication keys for each packet/nonce, GCM-SST enables secure tag truncation.
- The authors are working on adopting GCM-SST within CFRG first, then bringing the SRTP cipher suites to AVTCORE.
- A 48-bit tag length was proposed as a balance of security and overhead for RTP.
- Moe Zanaty and Alan Ford suggested adding a 32-bit tag option. Audio developers currently using truncated HMAC-SHA1 32-bit tags are highly sensitive to overhead and would transition more easily to GCM-SST if a 32-bit option was explicitly standardized.
- John Preuß Mattsson clarified that 32-bit GCM-SST is mathematically as strong as 32-bit truncated HMAC-SHA1, but runs twice as fast as Counter Mode + HMAC on hardware supporting AES instructions. It requires two additional ECB operations per packet for key derivation, which has negligible overhead except for extremely small packets.
- John Preuß Mattsson also explained that 128-bit tags only yield about 117 bits of security in GCM-SST due to mathematical bounds, making truncated options (such as 48-bit or 96-bit) highly practical.

Decisions and Action Items

RTP/SDP for Opus Multistream:
- Decision: Do not define a new multiopus payload format. Instead, extend the existing opus payload format to support higher channel counts.
- Action Item: Authors to update the individual draft to reflect this change and add an informative section detailing the historical multiopus workaround.
GCM-SST in SRTP:
- Action Item: Authors to present the work at CFRG, utilizing the expressions of interest from AVTCORE and QUIC, and return to AVTCORE once adopted.
AVTCORE Interims:
- Action Item: Chairs to issue a call on the mailing list to gauge interest for an interim meeting before IETF 127.

Next Steps

draft-ietf-avtcore-rtp-vdmc: Chairs to initiate WGLC after the V-3C draft completes RFC Editor processing.
draft-ietf-avtcore-frame-acknowledgement: Authors to resolve remaining open issues on GitHub and coordinate list discussion on the definition of a "frame" for tile/slice streaming.

Automatic IETF Minutes