Original text:
4.5.  Both QRT and the Engelbart draft attempt to use existing payloads of RTP, RTCP, and SDP, unlike RUSH and SRT, as well as using existing Datagram frames All drafts take differing approaches to flow/stream identification and management; some address congestion control and others just omit the subject and leave it to QUIC to handle <del> Both QRT and RUSH specify ALPN identification; the Engelbart and SRT drafts do not. Note - need to add WARP and verify these characterizations. </del>  <del> 4.6. </del>  It's worth noting that work on "RTP over QUIC" is being considered in the AVTCORE working group at this time, although no proposals have

Reviewer comments:
(related to )
NAME could you please take a look and let me know if it's an accurate description?
I'm merging this, so we make sure that WARP is included. If we got anything wrong, please let us know - we'll make sure it gets fixed.
Luke Curley has written . It's QUIC based, using CMAF for encapsulation, stream based, has no ALPN amongst other features. That said, it should be included in the "prior art" section of the document.
Agreed!
Some things worth considering, but you guys decide what is worth mentioning. Warp is the only protocol that is not frame based. Instead it attempts to map the GoP structure to QUIC streams. High quality media is basically linear within a GoP in order to maximize compression, which fits very nicely with QUIC's streams. There's no point delivering frames out of order if they cannot be decoded out of order. Warp uses prioritization instead of deadlines to achieve dynamic latency. This removes the need for feedback outside of QUIC ACKs. It avoids a whole class of problems caused by dropped/delayed feedback. Warp uses CMAF segments for full compatibility with HLS/DASH, avoiding transmuxing on edge or at origin. Warp uses the full suite of QUIC functionality. This includes fragmentation, congestion control, flow control, streams (multiplexing + cancellation), etc. Some other protocols use QUIC datagrams and disable everything else, effectively using QUIC as a complex DTLS replacement. Warp supports a bidirectional API using QUIC streams however this was not in scope for the first version of the draft. I wanted to avoid bike shedding to focus instead on the above features. The actual version in production allows the player to manually choose the rendition and pause/play. Warp uses WebTransport at the moment, but we can decide if it's better suited for native QUIC (with ALPN) or even HTTP/3. Warp would even work over HTTP/2 (and Http2Transport) albeit with additional head-of-line blocking.

Revised text:
4.5. <ins> Warp's specification attemps to map Group of Picture encoding of video on top of QUIC streams.  It depends on ISOBMFF containers to encapsulate both media as well as messaging, and defines prioritisation with separate considerations for audio and video.  It doesn't yet define bi-directionality of media flows, and can be run over protocols like WebTransport I-D.draft-ietf-webtrans-overview. 4.6. </ins> Both QRT and the Engelbart draft attempt to use existing payloads of RTP, RTCP, and SDP, unlike RUSH and SRT, as well as using existing Datagram frames All drafts take differing approaches to flow/stream identification and management; some address congestion control and others just omit the subject and leave it to QUIC to handle  <ins> Both QRT and RUSH specify ALPN identification; the Engelbart, Warp, and SRT drafts do not. </ins>  <ins> 4.7. </ins> It's worth noting that work on "RTP over QUIC" is being considered in the AVTCORE working group at this time, although no proposals have