Audio/Video Transport Core Maintenance (avtcore) Working Group =============================================================== CHAIRS: Jonathan Lennox Bernard Aboba Notes: Spencer, with much-appreciated asists from Stephan and James Virtual Interim Agenda Date: Tuesday, May 23, 2023 Time: 09:00 - 11:00 Pacific Time Notes: https://notes.ietf.org/s/notes-ietf-interim-2023-avtcore-02-avtcore Meeting information: https://datatracker.ietf.org/meeting/interim-2023-avtcore-02/session/avtcore Remote instructions: https://meetings.conf.meetecho.com/interim/?short%3Dec888cd7-4423-4a49-aabb-a93c9d9ade05 Slides: https://docs.google.com/presentation/d/1VtKDEvetEF8Q2H2bJreCAiiVo7CHMXcqjCkjtU_MCko/ Agenda ------------------------------------------------- 1. Preliminaries (Chairs, 10 min) Note Well, Note Takers, Agenda Bashing, Draft status Spencer was dragooned as HedgeDoc note-taker, after muttering that meeting participants should be following along with the HedgeDoc note-taker and making corrections while the events are clear in our minds. We shouldn't be relying on one person to capture everything. **Accurately documenting working group discussions is a working group responsibility, in Spencer's humble yet correct opinion** ... :roll_eyes: :face_exhaling: The agenda escaped being bashed TODO: Bernard needs to review the EVC payload draft. 2. RTP Payload Format for SCIP (M. Faller, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip/ballot/ Authors think they have addressed the review comments, and are waiting for IESG reviewers to confirm, but so far, no response to emails. Bernard has read the SCIP documentation and agrees that it is not necessary to read the SCIP document in order to understand how to packetize SCIP in RTP. But that may not be clear to IESG reviewers who haven't read the SCIP document. Roman's DISCUSS on Section 6 looks like he's asking for security properties. Bernard: The document does describe the properties that SCIP provides. Move that discussion to the security considerations section? All key management protocols send in the clear until you are able to turn on encryption. Zahed's DISCUSS asked about profiles. When using SCIP, it is possible to use AVP, AVPF or SAVPF. SCIP does not preclude use of SRTP or feedback. Maybe this needs to be stated explicitly? The use of the term "variable" caused confusion. This was not referring to "variable bitrate". It has been clarified in the -05 draft. Spencer: in the Sarker DISCUSS, there is a question about a "MAY". Is normative language needed here? Or could we substitute "could" or "might"? Bernard: How about focusing on Zahed's DISCUSS for now. It looks like that DISCUSS is easily addressed. Spencer: It's ok to improve the document, but beware of making changes that we just hope will generate a response from radio silent ADs. One way to get a response is to put the draft on an upcoming telechat agenda, to capture the attention of all the ADs again. (Not on the call, but verified after the call - [upcoming IESG agendas](https://datatracker.ietf.org/iesg/agenda/documents/) have "new" items under 2.1.1, so I assume that ADs can still put "returning" items on the agendas as well. Again, that's a fine thing to talk about with our AD) 3. Video Frame Marking RTP Header Extension (M. Zanaty, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtext-framemarking/ballot/ DISCUSS related to privacy of the framemarking header extension. Decision: Add to the existing security considerations section a discussion of privacy issues. The framemarking header extension is intended for middleboxes, so not recommended for 1-1 calls. Applications using video marking RTP header extension can use cryptex (RFC 9335) to ensure against snooping. 4. RTP Payload Format for Visual Volumetric Video-based Coding (V3C) (L. Iliola, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-v3c/ This is just an update for WG information. Jonathan: this draft is close to ready for WGLC. 5. RTP Control Protocol (RTCP) Messages for Green Metadata (Yong He, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtcp-green-metadata Srinivas is presenting in Yong He's absence. Bernard: What happens if a request is received for temporal and spatial resolutions GREATER than what was negotiated in the SDP? Srinivas: that should be an error. Stephan: The draft should just describe what the receiver does - that works better than trying to control what the sender is doing. Srinivas: When the receiver receives a TSRR message with spatial resolution greater than the negotiated spatial resolution negotiated in the SDP, the receiver ignores the request. Jonathan: "ignoring" is tricky - you probably want to send **some** respose, so the sender won't keep retransmitting. Srinivas: When the receiver receives a TSRR message with spatial resolution greater than the negotiated spatial resolution negotiated in the SDP, the receiver ignores the request and will respond with a TSRN message with the existing spatial resolution. The receiver shall not process the TSRR request with a resolution greater than the resolution negotiated in SDP. Srinivas: We will update the draft based on this discussion. 6. RTP over QUIC (M. Engelbart, J. Ott, S. Dawkins, 20 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic Mathis presenting updates since Yokohama, including RTCP and RFC 7667 tables, CC terminology, absence of BCP recs for CC, rearrange of CC section, STOP_SENDING, error codes Bernard: What is the purpose of STOP_SENDING? Is it just a way for a receiver to get the sender to send a RESET_STREAM? Mathis: We'd like to drop it, but feedback was we must define how to handle it. Spencer: There's been confusiion over the meaning, not saying it's the right way to clear the queue. Bernard: Is there a role for it? Spencer: There's a role for an RTP receiver telling an RTP sender to change the leading edge. If we can use STOP_SENDING for that, great, and if not, we need to find a way to do that, but either way we have to define what STOP_SENDING means. Joerg - We have an undetermined amount of data in QUIC due to potential retransmissions, I believe there is a legitimate reason for having this. Jonathan: If you're doing multiple frames per stream, what does this mean? Mathis: STOP_SENDING does not include an indication of what has already been received, so it's possible to cancel more media than necessary. Mathis: I think we need to stick to the behavior defined in QUIC. 7. HEVC Profile for WebRTC (B. Aboba, 10 min) https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-hevc-webrtc Bernard: Browsers are implementing support for HEVC. HEVC decode is now supported in Chromium WebCodecs (hardware only). Encode is a work-in-progress (also hardware only). HEVC support in WebRTC is also a work-in-progress within Chromium. This includes support for RFC 7798 packetization/de-packetization. However, one issue that has arisen is what SDP support is needed. So a draft was needed to cover the requirements for HEVC support in WebRTC, with a similar scope to what RFC 7742 does for H.264. Jonathan: Is this in our charter? Maybe, because the RTCWEB WG is closed. Bernard: I brought it here, because the expertise is here (this WG produced RFC 7798) Jonathan: We also need to think about other things that are unique for HEVC. Bernard: Because support is hardware only, it's necessary to take into account what features chipsets implement. For example, HEVC screen content coding is typically not supported in hardware, so we have not included that in the WebCodecs encoding options. Jonathan: What about bugs in chipsets? Bernard: That is also an issue. For example, there are hardware decoders that do not support spatial references. So even if the encoder supports spatial scalability, a hardware decoder may not be able to decode it. So we had to make it possible to discover if the decoder supported spatial references within the Media Capabilities API. Jonathan: It would be a good idea to send a note to the RTCWEB WG mailing list, pointing to the draft and asking for feedback. 8. RTP Payload Format for SFrame (P. Thatcher, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-sframe-enc https://github.com/pthatcher/avtcore-rtp-sframe At the last meeting, we discussed a way forward for RTP packetization of SFrame. I was asked to write a draft, which I have now posted on github (yesterday). People should look at it... How are sequence numbers handled? This wasn't on the slide because Peter forgot, but he does know about it. ... Bernard: Given the discussion about SCIP, it would be good to have an introductory section going over the architecture and how things work. Jonathan: Having the SFrame document be a public document will make it easier for the IESG. Peter: Should we adopt the draft? Jonathan: A day-old draft is maybe a LITTLE early to adopt ... deal with open questions first? Bernard: You need to submit the draft to the I-D archives, and let people read it first. 9. P2P QUIC (P. Thatcher, 10 min) https://w3c.github.io/p2p-webtransport/ https://w3c.github.io/webrtc-ice/ Peter: Chrome had a P2P QUIC Origin Trial in 2019. The Origin Trial provided support for datagrams as well as QUIC streams. It used gQUIC, so it didn't support RFC 7983bis multiplexing. But it did support peer-to-peer operation of QUIC over ICE. The QUIC connections can be used for any purpose: transport of data, media, etc. Peter: P2P QUIC does not utilize QUIC connection migration, but lets that be handled by ICE (same as in WebRTC data channel). P2P QUIC uses self-signed certificates, similar to DTLS, so the SDP looks similar. Peter: P2P QUIC envisages use of the "q2q" ALPN. Is there a reason to have another ALPN for RoQ? I don't think it's necessary. Bernard: Is it possible for RoQ to run over P2P QUIC? From a protocol perspective, the answer is probably "yes". But it is not clear to me from an API perspective. RoQ envisages tight integration of RTP with the QUIC stack. That integration would not be possible in a browser where the QUIC stack is typically in a separate process. Does the WebTransport API + P2P QUIC API provide the information and control that RoQ needs? Mathis: Current RoQ draft uses the rtp-mux-quic ALPN. James: Don't think the APLN is the right place to distinguish between client-server and P2P? Bernard: P2P QUIC can't reuse the WebTransport ALPN because the protocol is different (raw QUIC versus WebTransport over HTTP/3). Or are you saying to just use the QUIC ALPN? Spencer: Don't worry about conflicting with the SDP for RoQ draft, because that doesn't describe much of the functionality. Peter: In terms of SDP, we start with UDP/QUIC (for P2P QUIC). Then for RoQ we can have UDP/QUIC/RTP. Bernard: A similar issue has come up in WISH. WebRTC DataChannel SDP does not describe what is running on top of the datachannel. So the question has arisen about how you could define what is transported on top. For example, there are streaming applications that transport CMAF over data channel. Peter: For P2P QUIC, it would be useful to have support for realtime congestion control algorithms such as Google Congestion Control (gcc). For that, we would need the QUIC timestamp extension, so we can calculate the one-way delays. I think we should define real-time congestion control once, not just for RoQ Spencer: I agree Jonathan: If it's not RTP-specific, it's not in scope for AVTCORE Spencer: I understand. Perhaps it would be in scope for the proposed Congestion Control Working Group (CCWG), but as of last week, I don't think that charter had been approved. Jonathan: Perhaps it should go to the QUIC WG? Spencer: I think the QUIC WG would have to recharter for that. But the point for this meeting is that Peter has asked a good question, and it's up to us to answer it. Bernard: Maybe bring it to DISPATCH? Jonathan: If that's not in scope for AVTCORE, the RoQ folks should keep an eye on that. 10. Wrapup and Next Steps (Chairs, 10 min) No discussion for this agenda item