Minutes interim-2025-avtcore-02: Tue 16:00
minutes-interim-2025-avtcore-02-202506101600-00

Meeting Minutes Audio/Video Transport Core Maintenance (avtcore) WG
Date and time 2025-06-10 16:00
Title Minutes interim-2025-avtcore-02: Tue 16:00
State Active
Other versions markdown
Last updated 2025-06-27

minutes-interim-2025-avtcore-02-202506101600-00

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)