Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

Virtual Interim Agenda

Date: June 4, 2024
Time: 09:00 - 11:00 Pacific Time

Meeting link:
https://datatracker.ietf.org/meeting/interim-2024-avtcore-02/session/avtcore

Notes: https://notes.ietf.org/notes-ietf-interim-2024-avtcore-02-avtcore

Slides:
https://docs.google.com/presentation/d/1_yIUeEPzYl08nWhqNeRqG0V2G6nKL2VpuVrN-mXsoTA/

Notetakers: Spencer Dawkins and Magnus Westerlund

1. Preliminaries (Chairs, 10 min)

Note Well, Note Takers, Agenda Bashing, Draft status

• We are moving to our own AVTCORE organization in Github.
• We'll use this for recently adopted drafts (of which we have
  several).
• Authors of individual drafts can also create repositories in this
  organization.
• The weekly activity report will also report on these repositories
  (when we fix the script to do so).

Action: authors to discuss with the chairs whether/when to move their
drafts into the AVTCORE organization.

2. Closing the RTP Payload Format Media Types IANA Registry (M. Westerlund, 10 min)

https://datatracker.ietf.org/doc/html/draft-westerlund-avtcore-rtp-payload-registry

• We are back-populating the media-types registry and closing the RTP
  Payload Format Media Types registry.
• We THINK we've identified all the registry entries that need to be
  added to media-types.
• We may need to add EVC to the list.
• Ready for adoption yet? No objections to chairs calling for
  adoption.

Action: chairs to call for adoption and WGLC one minute after
adoption.

• Zahed - you've talked to IANA about this, right?
• We define policy, we just want to make sure IANA isn't surprised.

Action: Magnus to ping IANA for early review of the IANA actions.

3. RTP Payload Format for sub-codestream J2K streaming (P. Lemieux, 10 min)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-j2k-scl

• We've gotten some feedback, but want a bit more implementation
  experience before WGLC.

Action: Wait for additional implementation, check status at IETF 120
if ready to progress.

4. RTP Payload Format for Visual Volumetric Video-based Coding (V3C) (L. Ilola, 10 min)

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

• Draft has been updated since Brisbane (details in slides)

Action Jonathan and Christer to review changes, then chairs will issue
WGLC.

• Who's the shepherd? Not either of the chairs ...
• The chairs have volunteers to serve as chairs, but are happy to
  accept more volunteers

5. RTP over QUIC (M. Engelbart, J. Ott, S. Dawkins, 20 min)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

• "A couple of issues have been fixed"
• -11 will issue after some additional PRs are merged.

Buffering Unknown Flow IDs (PR#212)

• #212 is fixing a race condition between signaling and RTP packets
  arriving.
• Bernard: What if RoQ is implemented with an API that does not link
  RTP and signaling? RTP (RFC 3550) doesn't mention SDP. In such a
  situation, info for demuxing (such as PT to codec mapping) could be
  provided without signaling. If the application had the required
  information, why would flowid signaling be required? Application
  could receive an event from RoQ implementation, indicating an
  incoming flowid and could decide whether to accept it or not. If it
  was accepted, application could already have what it needs to
  interpret the incoming stream.
• Joerg: Don't you need to signal flowids for each RTP session?
• Sam: traditionally, if you don't have a port open based on
  signaling, your application never sees the packets, so that is why
  the session needs to be signaled. But in RoQ you can have multiple
  RTP sessions on the same QUIC port.
• Mathias: We can also allow a receiver to completely close a
  connection when its peer is just off the rails.
• Bernard: Can we?? Perhaps I am confused about the flowid security
  model. Does RoQ flowid function like WebTransport pooling (with
  SessionId distinguishing the sessions). That is, do flowids
  potentially represent separate applications multiplexing over a QUIC
  connection? This affects the security model, because in
  WebTransport, ending a session does not close the QUIC connection
  if there are still other sessions using it. The connection only
  closes when all sessions are closed, to avoid having one application
  close the connection used by another application.
• Spencer: If one receives a flow ID one has already done more work
  than compared to just start listening on an UDP port. So the risk of
  damage are less. The suggestion to allow completely closing a
  connection is a good one.
• Magnus: The flow ID represents a RTP session, one needs to receive
  the signal to process it correctly, so ignoring incoming unknown
  data should be fine. But agrees that there needs to be a way to
  allow an endpoint to react to malicous behavior. So what was
  suggested appears right.
• Jonathan: this would not be a problem if we were using the bundle
  model, but we don't seem to be doing that for RoQ. As long as you
  can't add a flow ID in an answer, you shouldn't have this problem,
  but that's a question for the RoQ signaling draft.

• Harald: this is a hard problem to tackle, but if you are throwing
  things away, you may be throwing away some large or key frames. Can
  we define things so that we never have to throw things away?

• Need to look into signal if one usually can avoid having to buffer.

Implementation status

• Implementation section is new
• We have two implementations from Mathis and one from BBC
• We're asking Sam to fill out the section for their implementation

Action: Sam will provide this information, and is also interested in
interop testing.

Next Steps

Spencer: Please contact us if you have an implementation that we don't
know about.

Jonathan: If one does interop one usually find the ambiguties. So it
might be good to wait with WGLC until after interop testing.

Mathis: Will close the last issue before the IETF meeting, but unclear
when interop can be done.

Jonathan: Please figure out when you think can happen so chairs can
consider when last call is suitable.

Action: Authors to merge remaining issues and figure out buffering PR,
then determine timeline for WG last call with chairs.

6. SDP Offer/Answer for RTP Using QUIC as a Transport (S. Dawkins, V. Pascual, 10 min)

https://datatracker.ietf.org/doc/html/draft-dawkins-avtcore-sdp-rtp-quic

Spencer made a status update to the WG. It is time to pick up the pace
on the SDP draft. Aligning it with RoQ and start resolving known
questions from previous presentations and discussions.

Jonathan: The SDP needs to be clear on how flow-ids are mapped to media
blocks (m=).

Magnus: Is the SDP focused only on Offer/Answer or also declarative use,
as QUIC is client/server protocol. Spencer explored some related
aspects. Magnus just conclude on consider if there are a use case for
declarative SDP when the client can receive a SDP, verify its capability
and just connect to the RTP sessions.

Sam: How will the endpoint known that it should use a real-time
congestion controller. One indicator is the ALPN when connecting.
Spencer: noted that from a multiplexing perspective one may consider to
use different ALPNs. There have been some discussion in Masque WG on
handling multipe ALPNs.

Bernard: The congestion control is not negotiated in QUIC, since QUIC
implements sender side congestion control, which allows senders to
implement varying CC algorithns while still maintaining interop with
receivers. So why would you negotiate the CC algorithm in SDP? Spencer
clarify that negotiation is not the right term, more an indication to
the endpoint that that the endpoint should be real-time media friendly.

Zahed:

• (AD hat off) Agreed with Bernard, that one need to be careful what
  one put in SDP as it is not really negotiated in QUIC either.

• AD HAT ON: In regards to QUIC being client server. Hope the RoQ
  draft is clear on the applicability as RTP can a lot of different
  topologies and establishments. Spencer: The capabilities between RoQ
  and SDP may not fully align in capabilities and the document needs
  to be aligned.

• Why do we need SDP? It already needs to be transported to the
  endpoint. Spencer responded that we are doing RTP now and want to go
  to RoQ, but I don't want to make large changes. We focused on the
  applications where SDP are helpful. Didn't consider a lot where it
  wouldn't be useful.

Bernard: There have been implementations of RTP which do not require
SDP, they just require the application to configure senders and
receivers. That configuration could come from signaling or it could be
provided statically. Example: https://draft.ortc.org/ Implementation:
https://github.com/aiortc/aiortc

Jörg: There are no strict binding, we just needs to signal the necessary
information. Maybe the draft can be split into a high level that
explains what information needs to be exchanged, and then one particular
mapping to SDP. Also as an organization that have continued to push SDP
despite knowing better, it would be strange if we didn't provide a usage
of SDP.

Zahed: Noted that it is important to maintain seperation between RoQ and
SDP. There must not be strict dependency on SDP from RoQ. Jörg agreed.
(So did Spencer!)

Jonathan: It can be worth just as consideration would it mean to use SDP
for RoQ in something like RTSP and SAP, the declarative usages, even if
it is unlikely there are any real need. Just to understand the
implications.

Action: mostly for the authors to work through the excellent feedback
we received in this session!
Action: Spencer to talk with the chairs about creating this repository
in the AVTCORE repository.

7. RTP Payload for Haptics (H. Yang, 10 min)

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

• Version -00 as a WG draft is now available.
• Access to MPEG specs for review is available through Stephan Wenger
  (via private email)

Action: chairs to work with authors to move this draft into the
AVTCORE organization.

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

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

• The authors have submitted the required IPR declaration, so now
  re-request that the chairs do the right thing for adoption.

Action: chairs to follow up with existing adoption call.

9. Wrapup and Next Steps (Chairs, 10 min)

Stephan noted a recent draft on normative references, a subject which
has come up in IESG reviews of several WG documents. Stephan to post
details to the mailing list.