[Karrot_Kream]

1. Fair on ICE. But if only one party is NATed, then you don't need STUN (or TURN if there's CGNAT involved.)

3. Yeah I was thinking about named resources/objects. If you could generate them predictably, QUIC+RTP can simplify a lot of things.

[j1elo]

Re: 1.- You'll probably still need it if the NATed party is recvonly, i.e. it expects to just recrive data without it explicitly sending any first.

[Karrot_Kream]

I would presume that the receiver will still make an output request to the QUIC endpoint to at least bring-up the connection/stream, which should be enough to populate the path in NAT tables, no? It shouldn't be any more wasteful than the regular process which receives packets out-of-band but still needs a signaling channel. This just does in-band signaling, so you bring up the connection, perform signaling, then open a new QUIC stream to receive data.

[j1elo]

You're right. I thought your comment was replying that in current implementations (not in the context of QUIC), the NATed peer wouldn't need STUN anyways, as of today. I had lost the context of it referring to an hypothetical implementarion over QUIC.