Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox, Marius Kleidl

Virtual Interim Agenda
June 10, 2025
16:00 - 18:00 UTC

Preliminaries (Chairs, 10 min)

Note Well, Note Takers, Agenda Bashing, Draft status

SDP Offer/Answer for RTP over QUIC (Spencer Dawkins, 20 min)

https://datatracker.ietf.org/doc/draft-dawkins-avtcore-sdp-roq/

Updates on changes since IETF 122
Requesting input on specific issues
Not clear that quic-datagrams advisory indication is useful
Jonathan Lennox: let's drop it for now and add it later if there's a
use case
Does anybody need to use RoQ without RFC 5761-style multiplexing?
Harald Alvestrand: In WebRTC we don't need support. Supporting both
styles (w and w/o multiplexing) is a hassle.
Spencer Dawkins: Inclination to require multiplexing moving forward.
Do people need to use BUNDLE and Flow IDs?
JL: BUNDLE and multiplexing were sacrifices. QUIC handles all the
multiplexing. Supporting BUNDLE and Flow IDs would allow to bring
back properties from original RTP architecture. Not sure if people
are interested. Would also make code more complex.
HA: Inclined to say that no bundling was a mistake in the RTP
design. Should require to bundle all the time. But also inclined to
say bundling was just a patch and bundling should not be used with
RoQ. But then gateways need to strip them. 51% in favor of requiring
bundling. 100% against letting people choose whether to bundle or
not.
SD: Feel the same way.
Does RoQ need to be first-class transport?
JL: No, RoQ should not be an ICE candidate.
HA: Think the other way. RoQ should not be a second-class transport.
If RoQ is a transport for RTP, then it is a transport. RoQ as a
first class transport makes sense if we support ICE with RoQ.
JL: Need clear picture to see how RoQ + ICE would look like first.
Feel quite complicated. Let's think about this in Madrid.
SD: Spencer agrees.
Marius Kleidl: Can move forward with RoQ draft itself?
Mathis Engelbart: Can move forward in the working group itself. No
hard dependency.
SD: RoQ is currently targeting publication as experimental. If RoQ
is published as experimental, we can publish as proposed standard
later with breaking changes. Spencer's opinion is that we did the
right thing by waiting for the SDP draft up to this point, but we
are less likely to need non-backward-compatible changes in RoQ every
IETF meeting cycle. We don't need to wait further, before moving
forward with the base RoQ draft.
Srinivas Gudumasu: Clarifying question about RoQ flow ID

RTP Payload Format for SFrame (Youenn Fablet, 15 min)

https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-sframe/

Reboot presentation for SFrame in RTP
Goal is to support per-payload and per-frame encryption
Richard Barnes: Work on document for IETF 123
Jonathan Lennox: Makes sense to not declare ciphersuite. Regarding
fragmentation, start flag is needed. We need to make sure it works
with H.264 due to packetization.
Harald Alvestrand: Don't like the negotation in SDP. Implemented
something similar in Chrome, effectively doubling number of packet
types. Instead, treat packetization as a new codec. I think of
SFrame as a codec. In favor of per-frame encryption.
RB: Make it an attribute on the payload? Mark it as a variance of
payload? Payload type is not protected by encryption.
HA: Payload type has to be changed by SFU. Try to separate concepts.
Packetization as an attribute has cost complexity. SFrame as an
attribute will cost the same. Needs to be safe to ignore a=
attributes that you don't understand.
RB: Is that held up in practice? What about a=crypto? Can we copy
their solution?
Youenn Fablet: Goal with m-section wide scope was to ensure for
transreceiver that all or no ... are encoded? With SFrame as codec
this isn't the case anymore.
JL: Over time for now. (Virtual) side meeting for this makes sense
in Madrid.

RTP Payload for V-DMC (Hyunsik Yang, 15 min)

https://datatracker.ietf.org/doc/draft-hsyang-avtcore-rtp-vdmc/

Hyunsik Yan: Proposal for call for adoption?
JL: Any objections?
(no objections raised)

RTP Payload Format for ISO/IEC 21122 (JPEG XS) (Tim Bruylants, 10 min)

https://datatracker.ietf.org/doc/draft-bruylants-avtcore-rtp-jpegxs-3ed/

New draft is compatible with RFC 9134
JL: when no objections, we can start call for adoption
TB: on holiday during IETF 123

RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution (Yong He, 10 min)

https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtcp-green-metadata/

JL: Good review from MPEG side, little review from RTP side. Please
review this
Erik Sprang: I can review. My questions on mailing list have not
been fully answered. What's the purpose?
YE: Example: Battery is low, request lower resolution
ES: Bandwidth reduction can be done on the sender side. Can we have
clear definition of how framerate is defined?
Stephan Wenger: No need to see production deployment for publication
of payload formats. Don't set presedence on this.
JL: Can you provide access to MPEG document?
SW: Yes, can provide access to ISO specs for review
Gorry Fairhurst: Implementations help to publish a document as
Proposed Standard. There are other ways to know that documents are
complete, and ready to publish: please read it with an intention to
consider implementing and offer reviews, or just look into this to
comment if everything is specified in the way it should be. Let's
try to keep the discussion going.

Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media (Srinivas Gudumasu, 10 min)

https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-volumetric-media-roi/

JL: What's the status on this?
Srinivas Gudumasu: Misalignment with MPEG spec. Need to do a change
for this. Review from RTP side would be helpful
JL: Implementations for this?
SG: Not yet
JL: Please review

Wrapup and Next Steps (Chairs, 10 min)

WGLC for RoQ
Side meeting for SFrame payload in Madrid
Call for adoption for draft-hsyang-avtcore-rtp-vdmc
Call for adoption for draft-bruylants-avtcore-rtp-jpegxs-3ed
Seek reviews and discussion for
draft-ietf-avtcore-rtcp-green-metadata