Re: [V3] Gateway new to old

[Magnus Westerlund <[e-mail]>]

Hi,

(Still as invidual)

Attempting to answer Cullen's question I think there are significant points in
trying to actually enabling the utilization of the advantages this redefinition
can enable. For example to me it appears that one should ensure that the media
transport becomes more ADU focused rather than packet focused. With 1080p or 4K
video in good quality the number of 1400 bytes packets needed to carry a single
frame are more in the range of hundreds than in single digit. I think one should
try to ensure that this work as well as possible. Thus semi-reliable head of
line blocking free transport of whole ADUs becomes of more interest. 

I think there is a point to re-use the RTP payload format. If one has such
support in the end-point one can use the RTP payload fragmentation when needed
for interconnect with RTP systems and not use it if one can rely on QUIC+RIPT
primitives. Reusing RTP payload formats also have the advantage of avoiding to
have to redefine all the codecs of interest.

Cheers

Magnus Westerlund


On Sun, 2020-03-29 at 23:05 +0100, Colin Perkins wrote:
> 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=[e-mail]
> > > 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 <[e-mail]> wrote:
> > > 
> > > > On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <
> > > > magnus.westerlund=[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v3
> > 
> > -- 
> > V3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v3
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------