Re: [V3] Gateway new to old

Hi,

one should add that the payload formats are mostly not overly complex
and their design is defined by the needs of the codecs -- plus mapping
to an unreliable packet transport.  The codecs don't change and the
unreliability still holds with QUIC underneath.  So, there would seem
to be little gain to begin with in attempting to redo all of this.

Cheers,
Jörg

On 30.03.20 15:16, Magnus Westerlund wrote:
> 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=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> wrote:
>>>>
>>>>> On Mar 27, 2020, at 8:23 AM, Magnus Westerlund <
>>>>> 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
>>>> https://www.ietf.org/mailman/listinfo/v3
>>>
>>> -- 
>>> V3 mailing list
>>> V3@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v3
>>
>>
>>