Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

[Joerg Ott <[e-mail]>]

Let me just point out here that there is still a dangling question
if one could leverage more state from QUIC than just offering a
datagram service.

Colin and I went through some thought exercise to this end, but we
don't have an integrated implementation within QUIC for some RTP
features yet.  Still, our little analysis may turn out to be useful:
http://www.netlab.tkk.fi/~jo/papers/2018-12-epiq-quic-rtp.pdf

Jörg

On 19.02.20 16:57, Cullen Jennings (fluffy) wrote:
> 
> 
>> On Feb 14, 2020, at 10:00 PM, Ross Finlayson <[e-mail]> wrote:
>>
>> If we want to get something standardized/working quickly, then this is a ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets directly in QUIC datagrams - in such a way that the existing RTP payload format defined for each media type could map directly (i.e., with no more media-specific IETF standardization work required).  Even if this means that there's some duplication of functionality between RTP and QUIC (datagrams).  (Ditto for RTP over QUIC (reliable) streams.)
>>
>> While - at some point in the future - it may be worthwhile defining a new version (v3?) of RTP that works more efficiently with QUIC, this should not be something that we require before we define/standardize a replacement for SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to show its age, but it’s not broken, and has lots of existing deployment that could, ideally, be leveraged quickly within a SIP replacement.
> 
> Almost no modern RTP implementation actually does the full RTP spec so at the very least we need some serious subsetting of what part of RTP would be mapped to QUIC. The RTP extension mechanism is badly broken particularly for low bandwidth satellite links. And if you look at what RTP clients do with the RTCP sent to them, well, I think there is some house cleaning needed here to be able to actually use RTP /RTCP.
>