[vr000m]

ICE is needed when both parties are NATes, if one party was not mated, we’d not need ICE in webrtc either.

Agree on 2.

On 3. The videobridge needs state on who is on the session and who to forward to. that requirement doesn’t go away with QUIC. Unless you’re thinking that the video streams are some kind of a named resource or object.

I think the most people gripe about is SDP and it’s prescription of negotiation and encoding. I agree that capability negotiation can be vastly simplified given some of the capabilities can be inferred later in the session.

[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.