Re: [AVTCORE] Last question about AVP profiles for RTP over QUIC (was: Re: Registering AVP Profiles for RTP over QUIC)

[Joerg Ott <[e-mail]>]

Hi,

the interaction with ICE is indeed a very important aspect to sort out.

We should have a closer discussion on how one could fix the problem,
because one would need to carefully consider the outcome, not just
the effort to do special treatment within an ICE specs and code.

Since it's been admittedly a long time since I looked closely at
ICE, so forgive me if I am missing the obvious.

The most desirable outcome of an ICE exchange for a given media stream
is to find a workable pair of ICE candidates for the intended transport,
in this case RTP over QUIC over UDP.

I understand that using TCP is a desirable fallback in case this doesn't
work.  This begs the question: wouldn't then RTP over TLS 1.3 over TCP
be the sensible fallback?  Relayed or not?

This would appear to provide the roughly similar properties.

Maybe you can share a bit more on the relay case.  Do you assume an
asymmetric TURN case (UDP to one side, TLS/TCP to the other)?

Best,
Jörg

On 28.07.22 04:06, Spencer Dawkins at IETF wrote:
> Hi, Roman,
> 
> On Wed, Jul 27, 2022, 17:50 Roman Shpount <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi Spencer,
> 
>     My name is misspelled in the presentation (s/Shpout/Shpount) :)
> 
> 
> I'm sorry for the misspelling!
> 
>     The alternative to ICE TCP candidates is relay over TCP or TLS
>     (TURN). Even if we decide not to support ICE-TCP, if ICE is
>     supported, RTP-over-QUIC will be transported over TCP or TLS relay
>     in some cases.
> 
>     My main point is that ICE-TCP is part of ICE infrastructure and
>     typically a part of all major ICE implementations. ICE-TCP solves a
>     major problem with blocked UDP and seamlessly adapts UDP-based
>     protocol to work over TCP. Disallowing ICE-TCP for RTP-over-QUIC
>     would require extra work to disable it in the ICE library. It is
>     possible that a better solution for blocked UDP can be developed for
>     RTP-over-QUIC, but this would require changes to ICE specifications
>     and implementations.
> 
> 
> Thank you for sending your feedback to the mailing list. That helps a lot.
> 
> I appreciate you helping us come up with a plan for blocked UDP that 
> makes sense - that matters, too ...
> 
> Best,
> 
> Spencer
> 
>     To summarize, unless we plan to redesign, modify, or disable ICE for
>     RTP-over-QUIC, ICE-TCP will need to be supported.
>     _____________
>     Roman Shpount
> 
> 
>     On Wed, Jul 27, 2022 at 3:23 PM Spencer Dawkins at IETF
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>         Hi, Roman,
> 
>         On Tue, Jul 26, 2022 at 11:39 PM Roman Shpount
>         <[e-mail] <mailto:[e-mail]>> wrote:
> 
>             Hi Spencer,
> 
>             I am participating remotely, but let me know when the slides
>             are ready.
> 
> 
>         I finished my slides yesterday evening, and I just checked that
>         they're in the datatracker now.
> 
>         URL is
>         https://datatracker.ietf.org/meeting/114/materials/slides-114-avtcore-ietf-114-avtcore-slides-09.pdf
>         <https://datatracker.ietf.org/meeting/114/materials/slides-114-avtcore-ietf-114-avtcore-slides-09.pdf>
>         for combined slideset, and my topic starts on slide 47,
>         immediately following the RTP over QUIC slides.
> 
>         Thank you for being willing to take a look!
> 
>         Best,
> 
>         Spencer
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt