Wouldn't it be best to present the draft at the next DISPATCH meeting to create a WG/mailing list/etc?
Best regards Sergio El jue, 15 jul 2021 a las 19:29, Maxim Sharabayko (< [email protected]>) escribió: > @Alan, cool draft, thanks for sharing! > > > > @here > > It would be extremely interesting to see a dedicated mailing list and a > working group established to discuss options for live contribution over > QUIC. > > > > We at Haivision have started evaluating QUIC Datagrams as an underlying > transport for the Secure Reliable Transport (SRT) protocol [1]. > > In such a combination QUIC provides a network transport known to CDNs and > ISPs, allowing to route and load balance the traffic, while SRT is used for > latency-aware live streaming at sub-second latencies and loss recovery > based on ARQ and/or FEC. > > An RFC draft preview "Tunneling SRT over QUIC" is available here [2]. > > > > We've also done a PoC using the quicly [3] library to assess the approach > and check for technical difficulties like possible conflicts between SRT's > and QUIC's CC. The results are exciting! > > > > We would be happy to present our work to the IETF community. > > > > [1] - https://tools.ietf.org/html/draft-sharabayko-srt-00 > > [2] - > https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html > > [3] - https://github.com/h2o/quicly > > > > -- Maxim > > > > > ------------------------------ > > *From:* QUIC <[email protected]> on behalf of Mike English < > [email protected]> > *Sent:* 14 July 2021 19:09 > *To:* Victor Vasiliev <[email protected]> > *Cc:* Roberto Peon <[email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; Alan > Frindell <[email protected]>; [email protected] <[email protected]>; > Kirill Pugin <[email protected]>; Luke Curley <[email protected]> > *Subject:* [EXTERNAL] Re: [Wish] [AVTCORE] Video ingest over QUIC > > > > I would personally be very interested in a "video over QUIC" working group > or mailing list. > > The directness of this draft is perhaps what's most interesting to me. > In particular, the absence of out-of-band signaling / session > establishment stands in striking contrast with another UDP-based media > ingest option: WebRTC. > > The signaling needed for session establishment (and the diversity of > implementations for such signaling) has historically been a barrier for > WebRTC adoption as an ingest protocol outside of the browser context. > WISH-WG is working to improve that situation for WebRTC of course, but a > new QUIC-based ingest protocol presents an opportunity to sidestep some of > those known-issues by making an architectural decision up front about > whether that style of session management is necessary in a video > contribution workflow. > > I'm hoping others with more experience on these lists can speak to the > history and tradeoffs associated with those approaches, but I just wanted > to call attention to the aspect of the draft that seemed most notable to me > as an operator of a low latency streaming platform where WebRTC egress and > ingest capabilities are provided, but where RTMP is still the de facto > ingest protocol of choice for many users. > > Thanks for sharing this work! > -Mike > > > > > > > > Maxim Sharabayko > > Senior Software Developer > > [image: Logo] <https://www.haivision.com/> > > > > > -- > Wish mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/wish >
