Peer-to-peer has its advantages, but it's no panacea.
After all, practically everyone is behind NAT these days, and it's so rare for an application to ask you to open a port in your firewall, most users probably don't know how to do it.
And early videoconferencing was famous for its unreliability - even simple things like people being able to join calls. Particularly as users might be behind restrictive firewalls on corporate networks or cell phone connections. Video calling that only works 95% of the time isn't good enough for things like job interviews :)
And users don't only expect one-to-one calls - everyone offers multi-party calls. If eight people want to watch Bob while he's talking, you've got to find eight videos' worth of upload bandwidth from somewhere.
And there are far more people trying to video call from battery-powered devices and metered connections than there were 15 years ago. If your competitors' apps uploads one video stream and yours uploads eight at once, users are going to notice the battery and data consumption.
And if you only have to test compatibility between your server and every version of your software, that's a much simpler task than testing compatibility of every possible n-way call between different versions of your software. Especially as you'll have to support Windows, OS X, Android and iPhone at the very least.
The answer is to still have clients and servers, just that the servers deal with the grunt work of routing traffic and the clients just stream the data through a server.
Push vs pull, depending if you can get upnp to open a port to the client.
Skype was originally a peer to peer application, seemed pretty popular and while it still was p2p? It was written by the people who wrote Kazaa, remember that?
*> Skype was originally a peer to peer application&
Sure, but Skype adopted a peer-to-peer design back in 2005 or so when expectations were a lot lower - no smartphones, no group calls, no 1080p, no cross-platform, and if it's unreliable or needs some fiddling around to get it to work properly, such is life - because the competition was paying $$$ for an international phone call that wouldn't have any video.
These days if you want to compete with Skype and Google Hangouts and Discord, I expect my regular four-way video call between people using Windows, OS X, Ubuntu and ChromeOS to establish first-time with clear audio and video to all users.
You could still do opportunistic P2P to lessen server load. And NAT is an issue, but not insurmountable, perhaps both sides have IPv6 or one side has a router with UPnP, PCP or a NAT implementation that makes hole punching easy.
Here's a wish for rapid adoption of IPv6, where no one will be fored to use nat ever again
>If eight people want to watch Bob while he's talking, you've got to find eight videos' worth of upload bandwidth from somewhere.
With p2p you may stream parts of the video from multiple clients
UPnP is pretty much a security disease. Countless security holes have come from that protocol. Worse is tons of users are behind double NATs and carrier NAT.
Really we just need IPv6 where one app binds to one IP.
Doesn't WebRTC need a TURN server to proxy traffic when you're behind a NAT? It's not really peer to peer when all the data goes through a central point.
TURN only proxies if it’s unable to make a connection via STUN, which requires the server to handle only a few packets when the initial connection is formed and provides direct peer to peer access after. Many home NATs only need the latter.
Peer-to-peer has its advantages, but it's no panacea.
After all, practically everyone is behind NAT these days, and it's so rare for an application to ask you to open a port in your firewall, most users probably don't know how to do it.
And early videoconferencing was famous for its unreliability - even simple things like people being able to join calls. Particularly as users might be behind restrictive firewalls on corporate networks or cell phone connections. Video calling that only works 95% of the time isn't good enough for things like job interviews :)
And users don't only expect one-to-one calls - everyone offers multi-party calls. If eight people want to watch Bob while he's talking, you've got to find eight videos' worth of upload bandwidth from somewhere.
And there are far more people trying to video call from battery-powered devices and metered connections than there were 15 years ago. If your competitors' apps uploads one video stream and yours uploads eight at once, users are going to notice the battery and data consumption.
And if you only have to test compatibility between your server and every version of your software, that's a much simpler task than testing compatibility of every possible n-way call between different versions of your software. Especially as you'll have to support Windows, OS X, Android and iPhone at the very least.
Thats a pretty negative picture you paint there.
To me, those are fun things to solve.
The answer is to still have clients and servers, just that the servers deal with the grunt work of routing traffic and the clients just stream the data through a server.
Push vs pull, depending if you can get upnp to open a port to the client.
Skype was originally a peer to peer application, seemed pretty popular and while it still was p2p? It was written by the people who wrote Kazaa, remember that?
*> Skype was originally a peer to peer application&
Sure, but Skype adopted a peer-to-peer design back in 2005 or so when expectations were a lot lower - no smartphones, no group calls, no 1080p, no cross-platform, and if it's unreliable or needs some fiddling around to get it to work properly, such is life - because the competition was paying $$$ for an international phone call that wouldn't have any video.
These days if you want to compete with Skype and Google Hangouts and Discord, I expect my regular four-way video call between people using Windows, OS X, Ubuntu and ChromeOS to establish first-time with clear audio and video to all users.
2 replies →
and one of the primary reasons Skype is no longer p2p is to violate user privacy not because of technical reasons
2 replies →
You could still do opportunistic P2P to lessen server load. And NAT is an issue, but not insurmountable, perhaps both sides have IPv6 or one side has a router with UPnP, PCP or a NAT implementation that makes hole punching easy.
Here's a wish for rapid adoption of IPv6, where no one will be fored to use nat ever again
>If eight people want to watch Bob while he's talking, you've got to find eight videos' worth of upload bandwidth from somewhere. With p2p you may stream parts of the video from multiple clients
IPv6 is ancient at this point and we still don't have it deployed.
It's widely deployed in China - in households, Web and mobile services and applications.
2 replies →
Over 1/3rd of Google's US traffic is IPv6, so it's not exactly rare.
IIRC IPv6 became a ratified internet standard in 2017
> it's so rare for an application to ask you to open a port in your firewall, most users probably don't know how to do it.
in home settings this step has been automated for something like a decade or more. One of UPnP or NAT-PMP are available on basically every router
UPnP is pretty much a security disease. Countless security holes have come from that protocol. Worse is tons of users are behind double NATs and carrier NAT.
Really we just need IPv6 where one app binds to one IP.
But are they enabled and working in the 99.5% house-holds, who do not have a professional Sys-Admin at home?
WebRTC is peer to peer and is supported in most major browsers.
From experience WebRTC starts to fall down in rooms of more than 8 people for video chat.
Meanwhile Zoom and Discord (who use servers) can achieve much greater so YMMV
That said p2p definitely has its advantages
Its just a case of p2p with people running servers (like bitcoint does) and differentiating between the two based on a bandwidth test.
Doesn't WebRTC need a TURN server to proxy traffic when you're behind a NAT? It's not really peer to peer when all the data goes through a central point.
TURN only proxies if it’s unable to make a connection via STUN, which requires the server to handle only a few packets when the initial connection is formed and provides direct peer to peer access after. Many home NATs only need the latter.
But then your data can't be taken and tracked and sold. Never happen.
If only we hadn't killed multicast.