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

Ross Finlayson <> Wed, 19 February 2020 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50A891200B5 for <>; Wed, 19 Feb 2020 06:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zVsCKANAIfhj for <>; Wed, 19 Feb 2020 06:52:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69654120120 for <>; Wed, 19 Feb 2020 06:52:28 -0800 (PST)
Received: from [] ( [IPv6:0:0:0:0:0:0:0:1]) by (8.15.2/8.15.2) with ESMTP id 01JEqD4V055512; Wed, 19 Feb 2020 06:52:14 -0800 (PST) (envelope-from
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Ross Finlayson <>
In-Reply-To: <>
Date: Thu, 20 Feb 2020 03:52:13 +1300
Cc: Spencer Dawkins at IETF <>, Justin Uberti <>, "Cullen Jennings (fluffy)" <>, Jonathan Rosenberg <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Jonathan Rosenberg <>
X-Mailer: Apple Mail (2.3608.
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 14:52:30 -0000

> On Feb 20, 2020, at 3:01 AM, Jonathan Rosenberg <> 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.