12 ms·
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/obje
by Karrot_Kream 4y ago
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 4y agoRe: 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.