CHAIRS: Jonathan Lennox
Bernard Aboba
IETF 121 Agenda
Location: Dublin, Ireland
Session: I
Room: Liffey MR 2
Date: November 4, 2024
Time: 09:30 - 11:30 Dublin time
IETF 121 info: https://www.ietf.org/how/meetings/121
Meeting link: https://meetecho.ietf.org/client/?session=33508
Notes: https://notes.ietf.org/notes-ietf-121-avtcore
Slides:
https://docs.google.com/presentation/d/1bLGLkbxmi4w8Od5vUU-YTRREF8sEBJP0XBJOTdm4-T8/
Notetakers: Magnus Westerlund
Preliminaries (Chairs, 15 min)
Note Well, Note Takers, Agenda Bashing, Draft status
Jonathan went through the meeting tips, note well, code of conduct
and the rest of the introduction.
Three documents in AUTH48: Intended to align some language between
frame-marking and VP9 payload format.
It was noted that RTP payload format for SFRAME has expired, and
contributors are needed.
If there is no implementer interest, it could be left to lapse.
HEVC Profile for WebRTC (B. Aboba, 10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-hevc-webrtc
Issue 27 is for discussion.
RFC 7798 on level-ID as part of the "media format" appears to be
wrong or at least unclearly worded.
On expressing an answer level higher than the offer. This appears to
be a common issue across many video payload formats. Some discussion
around the reason for this. The level-id assymetry limitation is
intentional. Mo argues that SDP sendrecv streams have limitations.
Fixing this needs a larger work addressing many different
parameters. Cullen notes that the simplest fix is to just do
sendonly and recvonly m-lines. It may have issues if one doesn't
have bundle.
Bernard thanked the WG for the input and believes he can draft a
proposal.
RTP over QUIC (M. Engelbart, J. Ott, S. Dawkins, 15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic
RTCP clarifications have been merged in the latest draft version.
This covers issues: #226, #227, #229
Interop testing has made progress and resolved some bugs. New
testing with Lorenzo, which will continue.
Spencer and Victor will continue to work on SDP.
RTP Payload for V-DMC (H. Yang, 15 min)
https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-vdmc
Hyunsik Yang presented the background and need for a new RTP payload
format to carry the basemesh and displacement components of V-DMC.
Jonathan asked if this would work with the current V3C payload
format, or if there would benefit of doing any V3C changes now to
ensure interaction.
H.Y : The atlas component can be utilized, but the base mesh and
displacement require independent RTP structures.
Gurtej: will the decoder have sufficient synchronization using
existing RTP and RTCP mechanisms?
H.Y : The primary goal was an independent bitstream, so
synchronization issues among the four bitstreams were not heavily
considered. This issue will be addressed in future updates.
Harald asked what purpose these parameters have. If they configure
the decoder, or express capabilities.
Please clarify their purpose and try to minimize the amount of
parameters.
H.Y : We will review once again to determine whether these
parameters are truly necessary.
Absolute Capture Time RTP Header Extension (Harald Alvestrand, 10
min)
https://datatracker.ietf.org/doc/html/draft-alvestrand-avtcore-abs-capture-time
Significant discussion about how the proposal works and if this is
useful. What are the benefits of the offset, and its errors
introduced based on the estimate of the one way delay between the
endpoints.
Bernard: What are the primary topologies?
Harald: The audio mixer.
Further clarification needed on behavior of RTP middleboxes that
aren't RTCP terminating would be good.
Also other possible use cases (e.g. musicians playing together from
different locations).
Jonathan: Can each source generate their own RTCP SRs and then have
middlebox adjust them and reissue?
Harald: Middle box needs to adjust both RTP packets and RTCP SRs to
its wall clock. Proposal provides the info to do this.
Spencer asked if it's correct that RTCP is being terminated at each
hop - that's why RTCP computations aren't sufficient across multiple
hops. Harald confirmed that this is the problem. (Timothy Panton
made helpful comments about this in Zulip)
Magnus noted that clock source could be good for the absolute
timestamp to enable a receiver to determine if this is a synched
time stamp or just a local clock on the sending machine. Clock
source has been defined in RFC 7273.
Mo said this isn't as good as NTP, but if you don't control all the
hops/know that all the hops are coordinated, this is better than
nothing. An RTP receiver today has to resurrect the wall clock at
every packet as they come in. The receiver knows RTP's absolute time
in its own domain, but can calculate the offset itself. Harald said
he would like to see a write-up of Mo's proposal.
Gurtej asked if this added 8 bytes per hop - it doesn't. Middlebox
replaces the offset.
Jonathan: there were a lot of comments about why this is needed.
Asked Harald to do a revision.
Bernard: Please file issues in GitHub, instead of just raising them
at the mike at the next meeting!
Action Item: Harald to do an update, the chairs to do an WG adoption
call on the updated draft.
SDP Fingerprints for Raw Public Keys in (D)TLS (J. Lennox, 20 min)
https://datatracker.ietf.org/doc/html/draft-lennox-sdp-raw-key-fingerprints
Jonathan: For post-quantum ciphersuites, self-signed certs will be
painful.
4KB signature for a 1KB cert!
Timothy Panton said they are using the expiration date in the
certificate, and that would be lost with a raw cert.
There also exist an unclarity with the existing solution if there
are multiple fingerprints or fingerprints for multiple certificates.
Cullen notes that as this is something new, it would likely be
better to define a new attribute to avoid confusion.
Jonathan also noted that LAMPS WG is looking into a new mechanism,
which needs to be considered.
(Later note: this is draft-davidben-x509-alg-none.)
Zahed, this may be possible to AD sponsor. However, there appear to
exist a need to have a WG that are chartered to do SDP maintenance.
Bernard there also appear to be need to discuss Post Quantum support
for DTLS in WebRTC.
Conclusion: More community discussion on where to do this work.
Wrapup and Next Steps (Chairs, 15 min)