Re: [V3] RIPT BoF approved for IETF 107

I also would think that “encapsulated RTP” approach is more promising as a starting point for all the reasons already mentioned. Having said that, and despite probably being one of the most “legacy oriented” people in the WG, I think it is worth to assess other strategies as well. I would consider cloud/legacy/failover friendliness as important parameters during this process.

Thanks,
Tolga

From: V3 <v3-bounces@ietf.org> On Behalf Of Justin Uberti
Sent: Saturday, February 15, 2020 2:55 AM
To: Ross Finlayson <finlayson@live555.com>
Cc: Cullen Jennings (fluffy) <fluffy@cisco.com>; Jonathan Rosenberg <jdrosen@jdrosen.net>; Jonathan Rosenberg <jdrosen@five9.com>; v3@ietf.org; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

On Fri, Feb 14, 2020 at 10:00 PM Ross Finlayson <finlayson@live555.com<mailto:finlayson@live555.com>> wrote:
On Feb 15, 2020, at 1:15 PM, Jonathan Rosenberg <jdrosen@jdrosen.net<mailto:jdrosen@jdrosen.net>> 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/<http://www.live555.com/>

--
V3 mailing list
V3@ietf.org<mailto:V3@ietf.org>
https://www.ietf.org/mailman/listinfo/v3<https://www.ietf.org/mailman/listinfo/v3>

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------