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

[Justin Uberti <[e-mail]>]

On Fri, Feb 14, 2020 at 10:00 PM Ross Finlayson <[e-mail]>
wrote:

> On Feb 15, 2020, at 1:15 PM, Jonathan Rosenberg <[e-mail]>
> wrote:
> >
> > RTP is in scope, in that, RIPT replaces RTP (and SDP and SIP).
> >
> > Basically, the output of the codec is placed into something called a
> 'media chunk' which adds a few parameters which are similar to RTP (i.e.,
> timestamp) and then sent in a PUT request or GET response.
>
> Jonathan is ‘handwaving’ a bit here :-), as he understands (more than just
> about anyone) that replicating the functionality of RTP would involve a lot
> more than just adding a few parameters to PUT and GET.  For each media type
> being transported, you’d need to define how data is best framed within
> (QUIC) datagrams, how (optional) FEC could be used, what RTCP XR
> functionality will be retained (and how), how (the equivalent of) RTP
> header options would be defined/carried, etc. etc. etc.  Essentially, you’d
> be replicating all of the work that took place (over several years) within
> AVT to define a RTP payload format for each media type.  Therefore...
>
>
> > No doubt an issue of contention will be whether we should just
> encapsulate RTP vs. whats in the draft.
>
> 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.)
>

Yes, this is my preferred approach. There still will be a lot of work just
to get this up and running, figure out how congestion control works in this
world, and avoid ending up with a lot of bloat from the encapsulation.
Assuming this works, we get fairly straightforward gatewaying between the
old and new worlds.


> 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.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> --
> V3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v3
>