Re: [V3] Gateway new to old

Colin Perkins <csp@csperkins.org> Sun, 29 March 2020 22:05 UTC

Return-Path: <csp@csperkins.org>
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 C63693A0DEB for <v3@ietfa.amsl.com>; Sun, 29 Mar 2020 15:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 fIV5vmoZ99LV for <v3@ietfa.amsl.com>; Sun, 29 Mar 2020 15:05:56 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 F37343A0DEE for <v3@ietf.org>; Sun, 29 Mar 2020 15:05:55 -0700 (PDT)
Received: from [81.187.2.149] (port=44574 helo=[192.168.0.80]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1jIg3w-0002UZ-9z; Sun, 29 Mar 2020 23:05:52 +0100
From: Colin Perkins <csp@csperkins.org>
Message-Id: <A1A23A18-4D5B-4019-9378-F42173FC5EDF@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B3625465-9EE6-4875-A2D6-955C0D79B77B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Sun, 29 Mar 2020 23:05:43 +0100
In-Reply-To: <CAOJ7v-3x=MHUzqwSeXnkAveJ2vEvp6OS1_OTQvOARrnnmFC6fg@mail.gmail.com>
Cc: Cullen Jennings <fluffy@iii.ca>, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "v3@ietf.org" <v3@ietf.org>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
References: <3595789d7a8d24671250e2ca04fcf78eb04179a4.camel@ericsson.com> <EFF58041-128E-42F6-9303-A058A5A02E22@iii.ca> <CAOJ7v-3x=MHUzqwSeXnkAveJ2vEvp6OS1_OTQvOARrnnmFC6fg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/1w5x2bBc-IFRnKl64-2w6kL0Iww>
Subject: Re: [V3] Gateway new to old
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: Sun, 29 Mar 2020 22:05:58 -0000

It may be a reasonable goal to aim to re-use RTP payload formats as the media packetisation within the new transport. That is, different headers and transport, but format the media content the same way.

Since payload format packetisation already all have registered media types this would make the media content easy to identify, and save a lot of work in re-defining packetisation schemes.

Colin



> On 27 Mar 2020, at 20:22, Justin Uberti <juberti=40google.com@dmarc.ietf.org> 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 <fluffy@iii.ca <mailto:fluffy@iii.ca>> wrote:
> 
> 
>> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org <mailto:magnus.westerlund=40ericsson.com@dmarc.ietf.org>> 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@ietf.org <mailto:V3@ietf.org>
> https://www.ietf.org/mailman/listinfo/v3 <https://www.ietf.org/mailman/listinfo/v3>
> -- 
> V3 mailing list
> V3@ietf.org
> https://www.ietf.org/mailman/listinfo/v3