Re: [V3] Thoughts on scope for ript

[Justin Uberti <[e-mail]>]

On Wed, Mar 25, 2020 at 12:38 PM Stephan Wenger <[e-mail]> wrote:

> Hi Justin, all:
>
>
>
> *From: *V3 <[e-mail]> on behalf of Justin Uberti <juberti=
> [e-mail]>
> *Date: *Wednesday, March 25, 2020 at 12:32
> *To: *Spencer Dawkins at IETF <[e-mail]>
> *Cc: *Victor Vasiliev <[e-mail]>, Jonathan Rosenberg <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [V3] Thoughts on scope for ript
>
>
>
>
>
>
>
> On Wed, Mar 25, 2020 at 12:26 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
> Replying to Justin, after reading Victor's reply - thank you both for
> replying ...
>
>
>
> On Wed, Mar 25, 2020 at 11:55 AM Justin Uberti <[e-mail]> wrote:
>
>
>
>
>
> On Wed, Mar 25, 2020 at 9:28 AM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
> This is interesting ...
>
>
>
> On Wed, Mar 25, 2020 at 10:31 AM Victor Vasiliev <vasilvv=
> [e-mail]> wrote:
>
> I would like to second Justin's point here about the value of a
> client-server RTP streaming by itself (e-f, though in-band c-d are also
> valuable).  There's a lot of value in the world where I can take an HTTP
> URL to some endpoint in the cloud and give it to, say, an IoT camera device
> to use as a realtime media sink, or pass it to an off-the-shelf streaming
> library to show a realtime media source on screen.
>
>
>
> I know most of my own concerns about RIPT media have started out with
> "this won't be as good as RTP for media", but what I've been getting from
> RIPT discussions is, that may not matter as much as I expected.
>
>
>
> For a use case like Victor's, great media quality would be great, but good
> enough media quality may be ... good enough.
>
>
>
> Am I putting words in the mouths of the proponents?
>
>
>
> Some applications may tolerate somewhat lower quality in fallback
> scenarios, but I think we should be aiming for RTP performance with HTTP
> ease of deployment.
>
>
>
> I was actually hoping that wasn't the case, because ISTM that the question
> whether RTP performance over HTTP is possible/likely is going to suck up a
> LOT of the discussion time during the BOF ...
>
>
>
> To Eric's point, "H3 is not widely deployed yet, and so we should think
> about how we want things to look". I think it's entirely possible to
> achieve RTP performance over H3, and hopefully also have a reasonable
> fallback when only H2 is available.
>
>
>
> [Stephan]: many video conferencing technologies (including Vidyo, Zoom),
> have previously, or are currently supporting http-based media transport,
> often for years or even decades.  They are almost never enabled by any
> professional deployer, because the resulting QoS is user-perceived as so
> bad that the marketing guys decided that offering no video/voice (and
> instead make people pick of the phone) is better for product reputation
> than offer the degraded QoS.
>
> Do any of you guys have hard numbers what sort of delay h3-based transport
> can achieve on today’s infrastructure?
>

With H3 we have lots of options; there are lots of details to work through
here but given that the substrate is QUIC there is no theoretical reason
why RTP performance isn't possible.

Regarding HTTP media transport in existing products (i.e., non-H3), you are
correct that there are indeed limitations and as such providers do what
they can to avoid this option, but it is nowhere near as grim as you make
it out to be. Recall that the first web version of Zoom exclusively used
websockets for transport <https://webrtchacks.com/zoom-avoids-using-webrtc/>
.

>