3 ms·
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.
by j1elo 4y ago
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 4y agoI 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 4y agoYou'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.