IETF Logo Mail Archive

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

Ross Finlayson <finlayson@live555.com> Tue, 18 February 2020 20:02 UTC

Return-Path: <finlayson@live555.com>
X-Original-To: v3@ietfa.amsl.com
Delivered-To: v3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4098C120818 for <v3@ietfa.amsl.com>; Tue, 18 Feb 2020 12:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bgjqoDDAvGh for <v3@ietfa.amsl.com>; Tue, 18 Feb 2020 12:02:51 -0800 (PST)
Received: from us.live555.com (us.live555.com [52.8.240.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC2D120814 for <v3@ietf.org>; Tue, 18 Feb 2020 12:02:50 -0800 (PST)
Received: from [127.0.0.1] (localhost.live555.com [IPv6:0:0:0:0:0:0:0:1]) by us.live555.com (8.15.2/8.15.2) with ESMTP id 01IK2f51023228; Tue, 18 Feb 2020 12:02:41 -0800 (PST) (envelope-from finlayson@live555.com)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Ross Finlayson <finlayson@live555.com>
In-Reply-To: <BYAPR06MB4391E5B3FB4258BEF59F7BFBFB110@BYAPR06MB4391.namprd06.prod.outlook.com>
Date: Wed, 19 Feb 2020 09:02:40 +1300
Cc: "v3@ietf.org" <v3@ietf.org>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Jonathan Rosenberg <jdrosen@jdrosen.net>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3254DED7-C105-4674-82E4-0D6968CB8744@live555.com>
References: <BYAPR06MB43914433BF91CE216E6123A6FB150@BYAPR06MB4391.namprd06.prod.outlook.com> <CAKKJt-eKB4wxqK8Xiho2tYaqpM3_fjQYsjJh5-cf_RWd6iR8sQ@mail.gmail.com> <CA+23+fGNO86ii6q0hd3aiSdib2AT-iu3O+DmgGJXTFbFkGxLnQ@mail.gmail.com> <F72DFB60-1BA3-4CD3-9DB2-DF986F3729DE@live555.com> <BYAPR06MB4391E5B3FB4258BEF59F7BFBFB110@BYAPR06MB4391.namprd06.prod.outlook.com>
To: Jonathan Rosenberg <jdrosen@five9.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/8QiJbZE4zJEHye9QDVn6O_7zHhw>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below
X-BeenThere: v3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <v3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v3>, <mailto:v3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v3/>
List-Post: <mailto:v3@ietf.org>
List-Help: <mailto:v3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v3>, <mailto:v3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2020 20:02:53 -0000

> On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <jdrosen@five9.com> wrote:
> 
> 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.

So just to clarify here:  Is your goal (for this protocol) that media be transferred only over streams (TCP or (reliable) QUIC), not datagrams?  Consequently, how important is end-to-end latency for audio/video calls that would use this protocol?

And are peer-to-peer audio/video calls (that would not involve a web server at all, except perhaps for initial end-user lookup/discovery) out of scope for this protocol?

If that's the case, then you’re not really ‘replacing’ RTP, but rather defining a new media transport protocol to be used in this one (restricted, but important) environment: Transport using reliable protocols via web server(s).  And if that’s the case, then I’m concerned that your SIP replacement (i.e., replacement of the one thing that’s truly broken, and needs replacing) might end up being too restrictive for more general media transport (datagrams and/or peer-to-peer).


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

v2.23.0 | Report a Bug | By Email