Right now most SFUs start up an ICE Agent [0] and listen to a random port. ICE is used to establish the connection between two peers. Basically both sides exchange a list of peers, and try to find the best path.
With an SFU you end up having thousands of remote peers each with their own port on your server. However you could easily listen on a single port and then handle the inbound packet depending on what the remote 3-tuple is (clients ip/port/protocol). Effectively you would just be running all your ICE Agents on one port, but doing one additional step of processing.
I need to fill out [1] more to fully explain the idea, but I think it could make a huge difference when making it easier to deploy WebRTC SFUs.
Yup that's a great point. I'd love to see this approach explored further. Is there any risk of tuple collisions in some bizarro NAT situation? I'd guess not, since the remote tuple needs to route to a single destination, but there's some weird stuff out there... eg one could imagine a router abusing the IP protocol to somehow route packets to different destinations despite them having the same return IP/port combo. i'm no networking wizard, but in general i assume if its possible, someone is doing it :)
With an SFU you end up having thousands of remote peers each with their own port on your server. However you could easily listen on a single port and then handle the inbound packet depending on what the remote 3-tuple is (clients ip/port/protocol). Effectively you would just be running all your ICE Agents on one port, but doing one additional step of processing.
I need to fill out [1] more to fully explain the idea, but I think it could make a huge difference when making it easier to deploy WebRTC SFUs.
[0] https://github.com/pion/ice
[1] https://github.com/pion/webrtc/wiki/SinglePortMode