Re: [V3] Gateway new to old

On Mon, Mar 30, 2020 at 6:55 AM Cullen Jennings <fluffy@iii.ca> wrote:

>
> 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.
>

Sure, there is lots of state for crypto. But this will typically be handled
by a frontend server at the edge of the cloud infra, so we should focus on
the RTP-specific parts.

>
> 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.
>

I can get on board with this. As you say, there already is some state with
RTP/RTCP in terms of the timestamp mapping. The main thing is that this
needs to be loss-tolerant (which makes compression somewhat harder) and
self-healing, e.g., on a gateway failover.

But yeah, it would be nice to not have to send the ~same 12 bytes + 0xBEDE
in every packet. (And this is why I think we can reach parity or better
with RTP efficiency.)

>
>
> On Mar 27, 2020, at 2:22 PM, 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
>
>
>