Re: [V3] Gateway new to old

Cullen Jennings <> Mon, 30 March 2020 13:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E05573A1625 for <>; Mon, 30 Mar 2020 06:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x_1Vc8j2PgyX for <>; Mon, 30 Mar 2020 06:55:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 053263A161C for <>; Mon, 30 Mar 2020 06:55:49 -0700 (PDT)
Received: by (Authenticated sender: with ESMTPSA id D61494353; Mon, 30 Mar 2020 09:55:48 -0400 (EDT)
Received: from [] ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.7.12); Mon, 30 Mar 2020 09:55:49 -0400
From: Cullen Jennings <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC919A2F-E800-4A60-8042-54B1C601C913"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 30 Mar 2020 07:55:47 -0600
In-Reply-To: <>
To: Justin Uberti <>, "" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.14)
X-Classification-ID: c7f8e3f1-1f98-4679-ad29-9f4aed01a9fa-1-1
Archived-At: <>
Subject: Re: [V3] Gateway new to old
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Mar 2020 13:55:52 -0000

On the stateless or not … I’ve tried implementing this a few different ways and I think what we want is a sort of mostly stateless with frequent sate updates for the parts that are not stateless. Let me explain ….

First keep in mind there is nothing stateless about the QUIC connection. Lots of state for crypto. It also seems like it would be a good thing to allow state for compression. So we are already out of a fully stateless design before we even start. 

So when we say RIPT can map to RTP, we really mean RTP + RTCP as that is needed. In the RTCP we need things like the NTP timestamp. I don’t think we want to send the full NTP timestamp in ever RIPT packet which probably rules out a fully stateless design. In WebRTC we took the approach of putting some data in RTP header extensions and sending them not ever packet but relatively frequently like every second or every IFrame.  I think we should do the same thing here - we should have some stuff that is sent frequently enough that if you loose all state until it is resent, it is  not a huge deal. 

This would allow us to do things like send the info to map to NTP time once a second not in every packet. When you look at what is in a basic RTP packet, I think it is easy to have that 1:1 mapping of all that data to something in the RIPT packet but when you start looking at the RTCP data or some of the RTP header extensions, I think that needs to all map to stuff in RIPT but probably not something that has to be every RIPT packet. 

Hope that makes sense. That said, I think this still is an extremely mostly 1:1 and simple 20 lines of code to map between RTP/RTCP and RIPT but I think we will end up with a bit of state that if frequently refreshed and is no worse than loosing an IFrame if you loose that state. 

> On Mar 27, 2020, at 2:22 PM, Justin Uberti <> wrote:
> It's hard to imagine that we can avoid this if we are in fact going to use H3 as a substrate. 
> I do think it would be useful to ensure the RIPT->RTP gateway can be stateless and transparent (i.e., you can transform a RIPT frame into a RTP packet with reasonable fidelity), so that said gateway is all you need in order for existing services to participate in the RIPT ecosystem.
> On Fri, Mar 27, 2020 at 9:32 AM Cullen Jennings < <>> wrote:
>> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund < <>> wrote:
>> The next media transport issue that was barely discussed in the BOF is the
>> legacy (RTP) interoperate question. This is going to come back in the scope
>> discussion and do needs at least a direction. 
> In WebRTC, we decided to be able to gateway SIP to WebRTC without processing media. That turned out to be a major limitation to how WebRTC worked. That is good and we have WebRTC but for this, I am storngly of the view we should not have that design constraint. 
> I think it is fine to require a media gateway to go from RIPT to RTP. Sure that should be pretty easy - one of the major use cases for this work will likely involve building SBCs that talk RIPT on one side and SIP on the other. Pretty sure that a bunch of other people are thinking about the same. 
> That sound right to you are or are you arguing for something else ?
> -- 
> V3 mailing list
> <>
> <>
> -- 
> V3 mailing list