Re: [V3] Thoughts on scope for ript

[Anthony Minessale <[e-mail]>]

On Wed, Mar 25, 2020 at 11: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?
>
>
Being "as good as RTP" is relative and so is "quality" There is quality
like how it sounds and quality like (how many packets did I get that I am
supposed to be getting and are they on time, are they dejittered and are
they dropped when they are too old)
If the media signal is in good shape then the second type makes all the
difference in preserving that.

One thing about RTP that is helpful but often not taken advantage of is
that you can pass it through as is even out of order and messed up and the
final thing to receive the stream can put things back together.
If something in the middle just cleanses it and rewrites all the timestamps
you get a permanently messed-up stream that can never be fixed.
Sometimes you want to dejitter and rewrite the packets when you know the
next hop has no way to do it but otherwise usually only when you are the
final terminating leg.

Everything RTP can do to make sure you have these features should be
duplicated or maybe an encapsulation mode to just carry old school RTP as a
payload so 2 aincent devices can still exchange RTP across a RIPT-wormhole.







> Best,
>
> Spencer
> --
> V3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v3
>


-- 


Anthony Minessale  | Founder and CEO

SignalWire: *228 Hamilton Ave 3rd Floor, Palo Alto, CA 94303
<https://maps.google.com/?q=228+Hamilton+Ave+3rd+Floor,+Palo+Alto,+CA+94303&entry=gmail&source=g>*

*https://youtu.be/WKjZkzgK4pc <https://youtu.be/WKjZkzgK4pc>*

https://youtu.be/MwqpSl7luSM

https://youtu.be/l82JtCECkog <https://www.youtube.com/watch?v=l82JtCECkog>

Email: [e-mail]

Phone: [phone]

Website: <https://www.freeswitch.com/>https://www.signalwire.com
<https://www.facebook.com/search/top/?q=signalwire>
<https://twitter.com/SignalWire>