IPv6 will certainly REDUCE the need for STUN, but there are still (many) cases where you don't want to be "reachable by default", in which case you need a stable reference for negotiating routing and reachability (e.g. STUN).
Edited: It seem that RtcDataChannel can be used with SFU, example LiveSwitch in 2018, but they don't use multiple destination datagrams (3)
More on similar proposal (2).
(1) IPv4 Option for Sender Directed Multi-Destination Delivery. The Selective Directed Broadcast Mode (SDBM) is an integral part of the U.S. Army standard for tactical data communication networks as defined in MIL-STD-188-220().
(2) https://www.researchgate.net/publication/238663190_IPv4_Opti...
(3) https://www.frozenmountain.com/developers/blog/archive/indus...
Edited: I must learn something about multicast in IPv6, the idea seems interesting.
Well, no. This is not about sending all video layers to all receivers and let them choose which one to render. Not al all.
The purpose of video simulcast/SVC is the opposite: make the SFU decide (based on estimated per receiver bandwidth or whatever) which video layers to deliver to each receiver, so a HQ video of 8 mbps does not break your Internet downlink (you just receive the lowest video layer which is 1 mbps, for example).
And more important: no, the server can not send the same UDP datagram (the same RTP packet) to all receivers. The server needs a different RTP sequence number count and a different SRTP encryption keys with each receiver.
I'm afraid this is not so easy as you say, not at all.
BTW: Do you want to say something about mediasoup? or just about your stuff?
Edited: In a recent article (1) it seems that multicast is better than SFU in webrtc. In the PhD. Thesis (2) a hybrid model is used: Hybrid multicast-unicast video streaming over heterogenous cellular networks.
(1)https://ieeexplore.ieee.org/document/8811590 (2) https://summit.sfu.ca/item/16802
In my very humble opinion, I would suggest to reserve some address space in IPv6 for rtc, so that a peer is able to adopt a new special ip reserved for rtc. Nothing new under the sun, in 2014 someone comment along this line of thought (2) and (3).
So what are we waiting for?
(1) https://webrtcglossary.com/ (2) https://www.quora.com/Will-the-IPv6-result-in-the-death-of-S...
(3) 2014, AshleysBrain, https://news.ycombinator.com/item?id=7496986 I think the solution is IPv6. Once every device on the Internet is uniquely addressable again, we can do away with these NAT hacks and two endpoints should be able to reliably connect to each other again, no matter where they are. Of course, that's assuming we don't get more short-sighted engineering that breaks things again...