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

Jonathan Rosenberg <jdrosen@five9.com> Thu, 20 February 2020 01:24 UTC

Return-Path: <jdrosen@five9.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 E62F91200F5 for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 17:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fivn.onmicrosoft.com
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 WJU7gT8Ah0Do for <v3@ietfa.amsl.com>; Wed, 19 Feb 2020 17:24:52 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2072.outbound.protection.outlook.com [40.107.244.72]) (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 AB2581200D6 for <v3@ietf.org>; Wed, 19 Feb 2020 17:24:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M1Ug2DBFwmjQREXivov7+m/qctC9xKISEdcJZCL0GPqSgWYycjdogZfk3AOcTAsYvGlTASHfQRmjPQHvcFJcJzCNFLZiVxycxordvRSbqzznlHMVeMJhDuU8p1Qyg9sYNL2VLflW1SUir6HMtg4p3ZliQZs9xIk5RZAg/ni2GQ/aeQicptKrviEN2IOBHyoo5EMpwntj48m5UpwGBCdTtGnZDx4SowGeQB867vcqGckbmYaFRKCpDcuW02Fsip53dnAoz2eV5MnJUjVe/Fs6PZBcWS8ccIVs+vmQYbfvQ0eWMNJgx8ZD9W8RSTYq0vfHZKWJrWJEN8tbTJrhA6gBww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=URg+Uk5eVgivGKtoCLaGaS3UIq/4VTJwK6MCvDekz5E=; b=CXqsAnU4FmHaPWqyTMQPrZUCqHMAePLDd13cdcPOETI56bM7W0qNmZyfvnXo3hPsIXEcATi1qEpkw3bY2Yq59w3TyfL6k5TBq6ScxptIjcRlQk4J9Ycoe9raT89RBNyfSE/nGjxLUGjw6F3Gp7JwZrxVvBIXahD7HxlTkZjOlzZhsm6nFWSQcsN7AHhOEDxX1c1TzqqJjZUkzvEbVtcZ744TMzkBGFcB3Cj/a5WNxA5HmnLPSgmE7L1+PCEEWKz2qXkChxZ1xbnSzAeESbohRqf22/Me8wuYz1sRIPUgALJSnxJzeSKvhL+waCQw8MJM3Wxxo7/tRPpXWlOfkedjiA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=five9.com; dmarc=pass action=none header.from=five9.com; dkim=pass header.d=five9.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fivn.onmicrosoft.com; s=selector2-fivn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=URg+Uk5eVgivGKtoCLaGaS3UIq/4VTJwK6MCvDekz5E=; b=udxdRTlH5DE+enQ6cHzlgPNFk0bJL4zmxgWwsPKYSNMVVD+IvbfQKO3mytZZGdBQcZvA1psEiRnwsIIRV6U3GSdd1GwGNjZqcAM3avnO2sUQ2eow7zTssGOt2vY6plfWKPXGnl4dWTiRFgJ3ov/gmF/fH6UZDovR94050p5yx+I=
Received: from BYAPR06MB4391.namprd06.prod.outlook.com (52.135.240.26) by BYAPR06MB4517.namprd06.prod.outlook.com (52.135.234.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Thu, 20 Feb 2020 01:24:51 +0000
Received: from BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4]) by BYAPR06MB4391.namprd06.prod.outlook.com ([fe80::21c5:6201:54:13d4%2]) with mapi id 15.20.2729.032; Thu, 20 Feb 2020 01:24:51 +0000
From: Jonathan Rosenberg <jdrosen@five9.com>
To: Ross Finlayson <finlayson@live555.com>
CC: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Justin Uberti <juberti@google.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Jonathan Rosenberg <jdrosen@jdrosen.net>, "v3@ietf.org" <v3@ietf.org>
Thread-Topic: [V3] RIPT BoF approved for IETF 107 - Draft charter below
Thread-Index: AdXjgeGz8imU79X0QTWjBiq5oM7qsgAEGIgAAACwSIAADAjQAACr1DMgAAh5pAAABb8KAAAK9n0AABImCIAAAjApUAACZz6AABX25cA=
Date: Thu, 20 Feb 2020 01:24:51 +0000
Message-ID: <BYAPR06MB43914E2238A2E3EAEC2A0FB9FB130@BYAPR06MB4391.namprd06.prod.outlook.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> <3254DED7-C105-4674-82E4-0D6968CB8744@live555.com> <CAKKJt-e5byVGLTgQAKWn=c9q1eU4mf8e=b8mucPOppPsmFnShw@mail.gmail.com> <CAOJ7v-0YiTZUQ5C7T8zOoe7f4jLWG8hYE08mC_cNuqzVLMZy6w@mail.gmail.com> <CAKKJt-ewJuBY_wu9Uhg2ijOcCRXpFy-tXzFwoKjarA3EV6-EkA@mail.gmail.com> <BYAPR06MB43911753D17BCADE1B0DF40DFB100@BYAPR06MB4391.namprd06.prod.outlook.com> <B0796F47-9F6C-4242-8A96-33A9FCEF73B5@live555.com>
In-Reply-To: <B0796F47-9F6C-4242-8A96-33A9FCEF73B5@live555.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrosen@five9.com;
x-originating-ip: [108.35.46.157]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 17dbcdef-5f26-42aa-97ea-08d7b5a3aeb7
x-ms-traffictypediagnostic: BYAPR06MB4517:
x-microsoft-antispam-prvs: <BYAPR06MB45175F73C59FC96EE8F02612FB130@BYAPR06MB4517.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 031996B7EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(136003)(396003)(39860400002)(199004)(189003)(8676002)(76116006)(53546011)(6506007)(81166006)(66946007)(4326008)(478600001)(64756008)(66446008)(66476007)(66556008)(2906002)(81156014)(8936002)(66574012)(6916009)(7696005)(5660300002)(86362001)(55016002)(52536014)(316002)(71200400001)(54906003)(33656002)(9686003)(966005)(26005)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB4517; H:BYAPR06MB4391.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: five9.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yGc0sfDchUdDwrAxkPYNeEPl8Zd7JbeuNx7UapYeEPn2euvUvBWZbfGtZjVLuTvH8vwJ4uMRNT0dOwyvPIs50Qs2XkbNHsZ89YbWmh0qD2dL++g6jmwaIRFXc3VuK7SWOAxV/oq6krlHAf29EM62EWxs9QFc/LyG1ZkSpwS7PdbCPg8x/cW5hjsCiNk9OmHRmHARvSwH53kfc2S442+0+aYbdb4qLiw7vZtJveeIvT7TI82w49wUxhhv5b/QJyFQ79iXmDEpiVIQJrKOwrNVpE95nbkGVsT4ck1AG87TjLGUhD55iW4NT0vLYoauBTfeDHhlD5paxIGG1IO0yPQizvEMfeg1O98gFsbvktMl1jLa4QmjudgyCoP0g67nAF+tVPRltdP8O6eIekvjq25stS3lHRV5O6znjBoZsp+DotCavmI0/dn1co7VWHTTo40tyQb5oHwR2Gr4dIshdX374qw1sRoubZa7gKB3jNlE+zZ2ND+DBVmpyTdSrkqqh9z3t9cQrg0o4oIddL+QwXtRUw==
x-ms-exchange-antispam-messagedata: 5Y+kC8O3Q2XLF0IPtJOCMTO5Pkp+35Apzr75QvzQvOhXnb3gDyyRo7lad9hunJzVBxvzXt4nxzQDehvsWhVtQDS9Ch9lR3l4burH6wyty0Rd1H8Ixtcv42LvwmgSBdnZKk2F7zNzLvu8zcXob1ZwDw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: five9.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 17dbcdef-5f26-42aa-97ea-08d7b5a3aeb7
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 01:24:51.0299 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f6c5114f-7396-4a09-af1e-98ee46f99bdb
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bv8z1PHyBzAtbjzdTljb7FBUvVtBh1c+epayej2IrEAsXEUUum+lW6DHmKeYXLnrNoN5rKnviYFGYktEn5qpMw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4517
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/zxT2nVT5R2UcvHm5d6RXQGY2djo>
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: Thu, 20 Feb 2020 01:24:55 -0000

Good points - I think the clear feedback from this and Tolga's comments are making the fact that this is really ontop of HTTP much clearer.

In terms of 'grandiose statements' - well, it actually does replace SIP/RTP/SDP depending on what one means by 'replace'. It replaces - in that it provides similar functionality and thus eliminates the need for - SIP/SDP/RTP - in the use case we are trying to address. Those use cases are around peering between cloud-based applications (CCaaS, UCaaS, cloud PBXs, etc) which run in public clouds, and telco providers. Another key use case is between browser and cloud-based application that wants to terminate media (conferencing provider, IP PBX which handles media, etc).

-----Original Message-----
From: Ross Finlayson <finlayson@live555.com>
Sent: Wednesday, February 19, 2020 9:52 AM
To: Jonathan Rosenberg <jdrosen@five9.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>om>; Justin Uberti <juberti@google.com>om>; Cullen Jennings (fluffy) <fluffy@cisco.com>om>; Jonathan Rosenberg <jdrosen@jdrosen.net>et>; v3@ietf.org
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below



> On Feb 20, 2020, at 3:01 AM, Jonathan Rosenberg <jdrosen@five9.com> wrote:
>
> Firstly, we assume that all of the servers sit behind HTTP load balancers, and are not reachable directly. This is standard practice. That means that clients have to send media through HTTP. Secondly, we assume that sticky routing happens in these load balancers the ‘normal’ way – through a combo of hashing of 5-tuples and usage of session cookies. That means that, in order to get the media to the server handling the signaling (which is what we want), the media needs to come in the same connection, and use cookies. This further ties it to HTTP. In order to deal with failures of those servers and enable mid-call recovery without loss of media packets, we also need the transport to contain call identifiers. This way, media can just ‘be sent’ to a new server in the pool behind the load balancer, and it can pick up where things left off in the previous server without losing any media packets (like - not one). In RIPT this happens because all media are PUT/GET from the call URI.

OK, thanks - this explanation makes it very clear that what you’re planning is a protocol for audio/video calls *over HTTP* - and over HTTP only.  A lot of the confusion (largely on my part, I admit) about what you’re proposing would have been avoided if this had been clearer in the name of the protocol (and BOF) - i.e., if there had been an “H” in there (I would have preferred something like MoH: “Media over HTTP” :-)

And grandiose statements about this protocol "replacing SIP, RTP and SDP” don’t help either - unless you really see the “HTTP Internet” (hourglass) becoming the entire Internet.  (Not all of us are ready to concede that, just yet ;-)


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.