Re: [V3] Thoughts on scope for ript

[Spencer Dawkins at IETF <[e-mail]>]

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

Best,

Spencer