Audio/Video Transport Core Maintenance (avtcore) Working Group =============================================================== CHAIRS: Jonathan Lennox Bernard Aboba IETF 114 Agenda Date/Time: Thursday, July 28, 2022 at 13:30 -15:30 Eastern Time (Session II) Room: Philadelphia North Meeting link: https://wws.conf.meetecho.com/auth-service/openid/oauth2callback?group=avtcore Notes: https://notes.ietf.org/notes-ietf-114-avtcore Slides: https://docs.google.com/presentation/d/14FG3G4v2Ps333QLC4XMeb3ZaNPvtKMsdUir85x2gsGA/ Notetakers: Magnus Westerlund ------------------------------------------------- 1. Preliminaries (Chairs, 20 min) Note Well, Note Takers, In Memorium, Agenda Bashing, Draft status Chairs opening the meeting and went through the chairs slides, including the Note Well, Note Very Well and Mask policy. Eve Schooler spoke in remembrance of Stephen Casner, former chair of the AVT WG and co-author of RTP, who passed away on July 4, 2022. Eve provided links relating to the pre-history of VOIP and the Mbone, the IEEE 2020 Internet Award, the Oxy Campaign for Good, Stephen's Tesla test drive, and more. Colin Perkins and Magnus Westerlund and spoke of their experiences working with Stephen. Jonathan went over the agenda and draft status. The Cryptex and VVC drafts are in the process of resolving IETF Last Call comments (more on this later). Mo Zanaty acknowledged that he needs to update the Frame marking draft. SCIP over RTP has completed WGLC and two of three solicited "early reviews" (ARTART and GENART). SECDIR review is still outstanding. RFC 7983bis has completed WGLC. "RTP over QUIC" Call for Adoption was successful. Call for Adoption of "Game state over RTP" garnered limited interest so far. Chair proposal is to extend the call and have the proponents sollicit feedback from the target group (game developers) 2. Cryptex (Sergio Garcia Murillo, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex https://github.com/juberti/cryptex/issues Sergio Garcia Murillo presented the current status. New draft addresses non-contentious issues out of the 39 received. WG accepted Sergio's recommendation on issues to be resolved "Won't Fix": do not rename "master key", fingerprinting issue. On IANA registration issue, ART AD Murray K. asked if the WG is fine with not creating a registry. Jonathan suggested that there been so few entries so far that a registry cannot be justified. If we ever get another request then likely a registry should be created. IANA found a typo in the IANA registration. Cryptex can be used at session or media level, so the IANA registration has been corrected. Zaheduzzaman Sarker asked about cryptex IPR declarations, which were not mentioned in the Publication Request because non-author IPR declarations were submitted after the PubReq was sent to the IESG. The received IPR declaration was sent to the mailing list on April 7, 2022, with no objections noted on the list. At the Virtual Interim on May 19, 2022 the issue was raised again and no objections to proceeding to publication were raised. A summary is available here: https://mailarchive.ietf.org/arch/msg/avt/c88xDocWibCpJntwzj0rYG-3lfk/ Stephan Wenger noted that there "IPR incompatible with IETF" is not defined. Cryptex updates RFC 3711. This will be mentioned in the abstract. The pre-RFC5378 warning thrown by the I-D nits can be ignored. Should Cryptex obsolete RFC 6904? Mo, Magnus and others indicate "No". Magnus Westerlund indicated that there are 3GPP proposals that would not work with encrypted header extensions and thus may require mixed encrypted and non encrypted header extensions. Thus, deprecation of RFC 6904 is not advisable. What if an Offer or Answer indicates support for both Cryptex and RFC 6904? The meaning of advertising support for Cryptex is "I support receiving Cryptex". So the question is what should a sender who supports both Cryptex and RFC 6904 send to a receiver who supports both? Jonathan suggests cryptex SHOULD be sent.Magnus indicates he is ok with that. Sergio will formulate a PR. Mandatory Stop #76 Proposal is to go with a MUST. 3. RTP Payload Format for Versatile Video Coding (VVC) (S. Wenger, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc Stephan Wenger summarized the status and changes. He had a meeting with Zahed to clear the discuss, which related to the SDP usage pattern of SPROP parameters. While SPROP parameter SDP usage is somewhat unusual, it was first adopted in RFC 3984 (the original H.264 RTP Payload Format), first published in February 2005. This was carried forward in RFC 6184, 6190 and 7798. So there is 17+ years of history with this approach. It was agreed to add non-normative language describing the existing behavior, but not changing it. IANA found an issue with the IANA registration which was only half-completed. This has been fixed. The changes do not rise to a level where another WGLC is needed. 4. RTP Payload Format for the SCIP Codec (D. Hanson, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip Mike Faller and Daniel Hanson summarized the early review comments. The SDP Directorate review completed, but did not indicate the need for additional SDP procedures, since no new SDP attributes are defined in the document. Both the ARTART and GENART reviews questioned whether the references to SCIP210 and SCIP214 should be normative rather than informative. SCIP214 covers the same ground as this document. Bernard: Do we need to reference SCIP214 at all? Mike Faller: the communities that care about the two different specs are different. This is the only place that links the two communities. Bernard: Are there are future extensions to SCIP like video will that impact the choice to remove the reference to SCIP214? Proposal after discussion is to remove reference to SCIP214. Bernard: SCIP210 is needed to implement SCIP, but this is the SCIP RTP payload specification, not the SCIP specification. Proposal is for reference to SCIP210 to remain as is (non-normative). The media type has already been registered with IANA. So the draft needs to make clear that this is updating these registrations. Among other things, the updated registration should reference the published RFC. Next Steps for this documents: Update the media type registrations and submit a new draft. After that it is ready for publication request writeup. 5. RFC7983bis (B. Aboba, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis Bernard Aboba presented status and updates to RFC7983bis WGLC. The major issue arising in WGLC was how to demultiplex TURN channel traffic from QUIC. This requires the receiver to use TURN server IP address and port. TURN traffic will only originate from those IP address/port combinations; otherwise the traffic is QUIC. There is no need to differentiate QUIC long headers and short headers. Eliminating this QUIC dependency improves QUIC version independence. With these changes the draft appears ready for Publication Request. 6. RTP over QUIC (J. Ott, M. Engelbart, 15 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic Mathis Engelbart presenting. Scope: focus is on RTP over QUIC. SDP signaling is handled in a separate document. The draft covers extensions to QUIC that are potentially valuable, such as timestamps, but baseline assumes nothing more than RFC 9000/9001/9002 QUIC. ALPN: "rtp-mux-quic" is used as the ALPN with a version suffix. Bernard: Does this imply that *only* RTP/RTCP can be sent on the QUIC connection? What about data? In WebRTC the DTLS ALPN allows for use in DTLS-SRTP as well as protection of the WebRTC data channel. Other updates. Current draft restricts a session to either transport over reliable streams (frame/stream) OR datagrams, not both. Mo Zanaty: What is the point to not allow using both streams and datagrams simultanously? There are other usages that will do this. Mo described one use case where he want to send Audio as streams and video as datagrams and video reference frames as streams and datagrams unreliable. Mathis noted they just wanted to avoid unclarities about how to handle incoming traffic. Bernard: It may be useful to spend some time describing the motivation and goals of this effort. Bernard described another use case, involving Scalable Video Coding, where the base layer might be sent over reliable streams and extension layers over datagrams. Jörg Ott states that they are aware of these thoughts but need to figure out the interactions. So interest but more thought needed. Translator forwarding packets over UDP exposes some questions. How would the translator operate if it received a frame over reliable transport and needed to forward it over UDP? The frame could greatly exceed the MTU. Stephan Wenger proposed to not over-engineer. Stupid senders are hard to standardize against. Spencer Dawkins noted that there are many types of RTP middleboxes, so it would be good to check the RTP Topologies draft and see if any of the types of middleboxes described there are what you are thinking of. Bernard: There are several WG work items that affect RTP topologies, so perhaps we need to think about documenting the potential impact. In the case of SFRame/SPacket, a MANE won't have access to the payload so it can't re-packetize even if it wanted to. Also, I presume that this draft is not going to attempt to support QUIC multicast so those topologies are out of scope? (see: https://datatracker.ietf.org/doc/draft-jholland-quic-multicast/) 7. SDP for RTP over QUIC (S. Dawkins, 10 min) https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic Spencer Dawkins presenting the status. TCP-ICE: Jörg Ott wonders how the idea of encapsulating QUIC in TCP come to be. In doing this, you might have an application attempting to implement low-latency congestion control (e.g. SCreAM, gcc) over QUIC (New Reno, BBRv1, BBRv2, Prague) over TCP (QUBIC, BBRv1, DCTCP, Prague). Bernard: This would be a nightmare to analyze, let alone to attempt to deploy. Roman Shpount noted that this is comming from the ICE machinary. So to maximize capabilities and TURN servers, tunneling over TCP becomes an option. Jonathan Lennox: one issue is that ICE stack provides an abstract datagram interface. Bernard: Are we thinking about this at a high enough layer? HTTP/3 and WebTransport fall back to HTTP/2, not to HTTP/3 over QUIC over TCP. The transport characteristics are not the same as with QUIC, but at least this strategy avoids nested congestion controllers. In some cases (e.g. pre-standard QUIC) we have seen multiple approaches tried simultaneously. Spencer: I am think about this at a high level, because I don't know enough about ICE to think about this at a lower level. Jörg: proposes that this be taken to the mailing list as it is hard to keep all of the interactions in one's head. Is this an API problem or a protocol issue? Roman: you have to ask for QUIC/RTP over ICE, as changing protocols, since trying to choose between QUIC/RTP and UDP/RTP in the middle will not work. This discussion should continue on the mailing list ALPN in SDP. Bernard: there are challenges here. What if the ALPN that is used in QUIC does not match that Offered in SDP? Is there an implication that implementations need to support previous versions (e.g. QUIC implementations would typically support 2 previous versions). Or does negotiation fail if the ALPN is not the latest? I am concerned that introducing ALPN negotiation in SDP as well could add to the brittleness. Mo: I understand where ALPN purists are comming from. However, this is different as this is a signalling exchange before the connection. Thus, registrering a lot of different ALPNs doesn't make sense as this is just additional complexities. Spencer: clarifies that different ALPNs mean different QUIC/RTP versions, the way QUIC versions used different ALPNs before QUIC version 1 was finished, and everyone could use "h3". Mo: Notes that there will be a lot of SDP before that can make this clear. Bernard: This was more complicated (implementations supported two versions backwards to avoid failures) How to ask for QUIC feedback #13. Should feedback be enables over all transport layer feedback possibilities, or per feedback type? Bernard: We need to discuss this in relation to the QUIC extensions that can be enabled on the connection, which can affect the types of feedback that QUIC can provide, and which can be combined with the RTCP features that are being used. Mo: noted from this morning's QUIC WG session, there was a proposal for a QUIC Timestamps extension that could be used to provide transport layer feedback. Spencer suggested that people who expect to use QUIC timestamps express interest to the QUIC working group, because the chairs are considering whether to issue a call for adoption between now and IETF 115. Jonathan: Are you asking for WG adoption? Spencer Not at this time, but he plans to update his SDP specification to match the RTP over QUIC draft before the next AVTCORE meeting, and request the chairs to consider a call for adoption at that time. 8. RTP Payload for V3C (Lauri Ilola, 10 min) https://datatracker.ietf.org/doc/html/draft-ilola-avtcore-rtp-v3c Lauri presenting the overview of V3C RTP Payload format. Atlas component is missing RTP paylaod format. Stephan Wenger: This is within the scope of the WG, so no objection against adopting. However, you are going to run into the same issue of providing the ISO specification for free. Stephan offers to provide ISO specification on request. Jonathan: Are there IPR declarations on this draft? Lauri: Yes. Chairs plan to issue call for adoption. 9. RTP Control Protocol (RTCP) Messages for Green Metadata (W. Zia, 10 min) https://datatracker.ietf.org/doc/html/draft-he-avtcore-rtcp-green-metadata W. Zia presenting. Joerg Ott: RTCP msgs are not reliable. Are you sending this in a soft state in which you keep repeating the request, since there is no ack in RTCP? How does the decoder knows the encoder got the request? W. Zia: This is aligned to Temporal spatial tradeoff AVPF request mechanism, decoder sends request with a certain sequence number for a specific SSRC and the encoder responds against that SN. Jonathan: 4 types of feedback in MPEG spec but you are only covering 2? W. Zia: We are only covering what we think is most important. Jonathan: SDP is another mechanism to configure coding configuration (frame rate, dimensions), is the proposed signalling overlapping or complementary? W. Zia: this is supposed to work together with SDP, so it is complementary. Jonathan: do you have IPR on this draft? W. Zia: Qualcomm has made an IPR disclosure. Jonathan: So you are not yet seeking WG adoption, right? W. Zia: not yet, we would like to gather more feedback and address it and then ask for adoption. 10. Wrapup and Next Steps (Chairs, 10 min) Jonathan: The WG has been having interims in addition to the sessions at IETF, so there is the potential for an interim meeting before IETF 115.