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

[Jonathan Rosenberg <[e-mail]>]

So - let me be more precise on my (correctly labeled!) handwaving:

The idea is largely to replace the syntax of the RTP header with something new. The primary motivations for this are to (1) add explicit labels for streams (defined as the combo or source and destination sinks within a callID), (2) utilize variable length encodings to increase the effective number of bits used for timestamps and sequence numbers so that they never roll over, (3) utilize variable length encodings for static payload types, a necessary artifact from the advertisement/directive model which forgoes per-call capabilities exchanges.

Beyond that, the idea was that issues like codec encapsulation do in fact reuse the massive library of payload types that have been defined to date. I agree it would be folly to redo them.

RTCP is more interesting. RIPT adds per-packet acks, along with timestamps, basically gives senders all the information (and more) they'd get from RTCP RR, for example. We also use RTCP a lot for media control (i.e., FIR). With RIPT, since signaling follows media, these can now be sent reliably as events over the event channel. Consequently, the applicability of many of the RTCP extensions is an open question in my mind. I have on my todo-list to do an analysis of the many RTP extensions to get a full picture of this, to aid our decision on whether to fully encapsulate RTP, encapsulate the payloads but change the RTP header (which is what the draft is proposing), or something else entirely.

Also to be clear - whilst I agree that RTP on QUIC is interesting - it is not in scope because httpbis is our target, not quic. We want to allow voice signaling and media to run over web infrastructure services, so http is our 'waist of the hourglass' not quic.

-----Original Message-----
From: Ross Finlayson <[e-mail]>
Sent: Saturday, February 15, 2020 1:00 AM
To: [e-mail]
Cc: Spencer Dawkins at IETF <[e-mail]>; Cullen Jennings (fluffy) <[e-mail]>; Jonathan Rosenberg <[e-mail]>; Jonathan Rosenberg <[e-mail]>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

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.)

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/




________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.