Audio/Video Transport Core Maintenance (avtcore) Working Group =============================================================== CHAIRS: Jonathan Lennox Bernard Aboba IETF 112 AGENDA Friday, November 12, 2021 Session I, Room 1 12:00 - 14:00 UTC 04:00 - 06:00 Pacific Time IETF 112 Info: https://www.ietf.org/how/meetings/112/ Meeting URL: https://wws.conf.meetecho.com/conference/?group=avtcore Etherpad: https://notes.ietf.org/s/notes-ietf-112-avtcore Slides: https://docs.google.com/presentation/d/1XB-RTt-ejDTillmkYcT3l6EBzNK7pARw51TqKcCxo8A/ Minute takers: Mo Zanaty ------------------------------------------------- 1. Preliminaries (Chairs, 10 min) Note Well, Note Takers, Agenda Bashing, Draft status 2. Liaisons (Chairs, 10 min) Request from W3C WebTransport WG - How can clients rapidly increase send rate? Will discuss following RTP over QUIC. Liaison from ISO/IEC JTC 1/SC 29/WG 03: https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2021-10-29-iso-iec-jtc1-sc29-wg11-avtcore-liaison-statement-to-ietf-avt-on-mpeg-green-metadata-attachment-1.pdf - Stephan Wenger asked about deployment of Green Metadata. Ask on the list. - Jonathan Lennox (as chair) asked if there is interest to work on a receiver feedback draft. Stephan clarified it can also be a payload format, not just receiver feedback. Take to the list. 3. RTP over QUIC (J. Ott, M. Engelbart, 15 min) https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf - Harald Alvestrand: why is there a need to multiplex multiple RTP sessions in one QUIC connection? Updated draft will expand on this. - Mo Zanaty asked about assumption that one-way delay is represented by RTT/2. One direction might not be congested. QUIC receive timestamp extension may help get a better estimate. - Justin Uberti: is anything is needed beyond QUIC receive timestamps? Has the packetization overhead vs RTP/RTCP have been measured? Can prioritization between realtime and non-realtime flows be left as out of scope for now (can use separate QUIC connections)? - Sergio Murillo: WebTransport browser apps won't have access to the QUIC stack in the same way as a native app. Authors focused on native apps first. - Bernard Aboba: WebTransport could add congestion control selection to the constructor. But today datagrams have strict priority over reliable streams and can starve them. So if you want to mix datagrams and streams without starving the reliable stream a separate QUIC connection is required. - Spencer Dawkins mentioned MOQ list discussions about RTP-related drafts. Should drafts like draft-engelbart-rtp-over-quic use "avtcore" in their name, to make sure the right people are looking at them? Jonathan (as chair) clarified it won't hurt to include avtcore, but no hard guidance. RTP over QUIC discussions should be on the avtcore list, while the MOQ list is for more general Media over QUIC topics. - Colin Perkins: separate QUIC connections cause pain. Is it acceptable, or is more CC/priority work needed to relieve this pain? - Jonathan Lennox (as chair) said to continue discussions on either/both MOQ or AVT lists. 4. Cryptex (Sergio Garcia Murillo, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex Cryptex has completed WGLC and is now in state "AD review". There are two implementations, both not in production yet. There is a proposal for adding support to the WebRTC-PC API. 5. RTP Payloads for VVC/EVC (Stefan Wenger, 15 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc - Stephan Wenger asked whether more complete examples of SDP Offer/Asnwer are needed, and recommends no. Simple cases already have examples. - Bernard Aboba: Is an additional profile document needed to enable interoperability? Without this, we are seeing problems with HEVC interop. - Mo Zanaty: examples for all complex cases are not needed, but some basic ones might help. 6. SCIP (Daniel Hanson, 15 min) https://datatracker.ietf.org/doc/html/draft-hanson-avtcore-rtp-scip - Bernard Aboba (as chair) asked what is needed from the WG? - Authors want to publish an Informational RFC. Murray Kucherawy (as AD) sees no problem with the WG taking this on as Informational. Bernard suggests to discuss on the list how best to publish this, as WG or Independent submission. - Ted Hardie asked if there is a data channel to negotiate separate from audio/scip and video/scip? Authors clarified no, and will update the text to clarify. - Stephan Wenger noted this references unavailable specs, so recommends Independent submission. - Colin Perkins noted other RTP payload formats reference "closed" specs, so there is precedent. - Murray (as AD) asked if reviewers can access the "closed" specs for review. Authors answered yes, and requested reviewers' names. 7. SFrame & SPacket (Sergio Garcia Murillo & Youenn Fablet, 30 min) https://datatracker.ietf.org/doc/html/draft-murillo-avtcore-multi-codec-payload-format - SFRame WG has adopted draft-omara-sframe-03. SFRame WG is developing the encryption format, which can be used for non-RTP transports like WebTransport or RTCDataChannel. SDP negotiation will most likely be handled in MMUSIC WG. Where should RTP-related work be done? - Jonathan Lennox (as chair): RTP integration should be done in avtcore, SDP aspects can be in mmusic. - Colin Perkins: avtcore can also handle RTP payload format SDP aspects. - RTP header extensions can be negotiated, but how are middle boxes made aware of SFrame encryption? Payload types? - Bernard Aboba: Negotiation of RTP header extensions doesn't imply payload encryption, since the middle box might use routing header extensions even for unencrypted payloads. Payload Type is also not a good mechanism since that would cause payload type explosion. - Jonathan Lennox: a new profile, not SAVPF, is another option. - Mo Zanaty and Colin Perkins: discourage another profile, and prefer a wrapper payload format, like RED or FEC, that binds to the underlying media format. - Suhas Nandakumar asked about interoperability of sframe variants. - Colin Perkins: Just negotiating the codec (e.g. VP8) does not make it clear whether existing RTP payload formats will be used or something else. - Jonathan Lennox (as chair) suggested list discussion and a possible sframe interim to close this. 8. Wrapup and Next Steps (Chairs, 10 min) - Jonathan Lennox said (at Spencer Dawkins's request in the chat) that discussion on further RTP-over-QUIC issues should happen on the AVTCore list, whereas more general media-over-QUIC discussion should happen on the MOQ list. -------------------------------------------------