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

Joerg Ott <> Wed, 19 February 2020 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 003BF1201DE for <>; Wed, 19 Feb 2020 08:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fEUijO0vLbcv for <>; Wed, 19 Feb 2020 08:03:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EE0B12013A for <>; Wed, 19 Feb 2020 08:03:41 -0800 (PST)
Received: by (Postfix, from userid 107) id 46F4B1C07EC; Wed, 19 Feb 2020 17:03:39 +0100 (CET)
Received: (Authenticated sender: ott) by (Postfix) with ESMTPSA id C5B381C07E5; Wed, 19 Feb 2020 17:03:36 +0100 (CET) (Extended-Queue-bit
To: "Cullen Jennings (fluffy)" <>, Ross Finlayson <>
Cc: Jonathan Rosenberg <>, Jonathan Rosenberg <>, "" <>, Spencer Dawkins at IETF <>, Colin Perkins <>
References: <> <> <> <> <>
From: Joerg Ott <>
Message-ID: <>
Date: Wed, 19 Feb 2020 17:03:36 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Feb 2020 16:03:44 -0000

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:


On 19.02.20 16:57, Cullen Jennings (fluffy) wrote:
>> On Feb 14, 2020, at 10:00 PM, Ross Finlayson <> 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.