- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Fri, 23 Nov 2018 11:20:43 +0100
- To: westhawk <thp@westhawk.co.uk>
- Cc: public-webrtc@w3.org
- Message-ID: <b37ff38a-844f-cfd4-d2ec-e03fe5eebb37@gmail.com>
On 23/11/2018 11:06, westhawk wrote: >> On 23 Nov 2018, at 11:02, Sergio Garcia Murillo<sergio.garcia.murillo@gmail.com> wrote: >> >> On 23/11/2018 10:52, westhawk wrote: >>> One problem that QUIC_theoretically_ solves is the congestion control problem by bringing everything under >>> the same protocol, but only if you move all media to QUIC and ban RTP. >> Just for the sake of completeness, the other problem that QUIC solves is the sync between media and data, something that is not achievable today between SCTP and RTP (AFAIK). > I’m Nit picking: > It only_potentially_ solves it - since you there are currently_no_ IETF RFCs that address this issue as far > as I’m aware - and again this is only true if you disable use of RTP and depend on some future > “realtime media over QUIC" RFC and > a "synchronisation of data and Media over QUIC” RFC > I agree and disagree, given that media frames will be agnostic to QUIC (or that is the promise), it is up to the app to add sync metadata to both media frames and data over QUIC. There is no need to sync on receiver side (bad wording on my side) but just be able to correlate data with media frames. Anyone, please correct me if my understanding is incorrect. All that, given that an unreliable QUIC stream mode suitable for RTC is specified in IETF, of course. Best regards Sergio
Received on Friday, 23 November 2018 10:17:32 UTC