On the site it says "Breakthrough peer to peer WebRTC technology" and the title claims "no latency".
Could you elaborate what makes this different from normal P2P WebRTC without a SFU? Do you feel that the claim of "no latency" is even possible/reasonable regardless of the tech involved?
I do not enjoy being blunt, but the author seem to have borrowed a page from a “that” conferencing company’s marketing playbook by making very questionable claims.
It’s a nice project, but:
> Zipcall is built radically different. We left behind slow bulky servers, opting for decentralized peer to peer calling. We engineered a platform with maximum video quality and low latency.
Translation: it uses WebRTC or we didn’t invent anything — it uses technology built into your browser.
> State of the art VP9 video compression combined with our scaling optimization makes your calls crystal clear.
Same as above (assuming you’re browser supports VP9).
> Breakthrough peer to peer WebRTC technology means your video goes directly to the other person without a server. No middleman. No extra stops.
Same as above.
> End to end state of the art encryption means your calls are exactly that. Your calls.
I am excited for more open-source video-calling tools, but I am also confused by how this "provides video quality and latency simply not available with traditional technology."
A quick glance at the readme suggests that this negotiates peer-to-peer connections using Twilio. But it's not just that it's p2p, right? Since there are a ton of p2p video-calling tools out there, most memorably to me the original Skype before Microsoft bought it.
Many/most WebRTC apps don't do p2p, but rely on a bunch of stuff happening in server side. There are also a lot of ways to set up webrtc in the browser affecting quality.
Where the citation on that? From what I’ve seen, P2P is more common than SFUs, if for no other reason than they are way simpler to implement architecturally for small amount of participants.
So is p2p really bad when dealing with lots of users? Because now instead of you sending your video to a central server, you are now having to send your video to every single person while still receiving the video of everyone. So your upload usage must go through the roof.
You know, strangely, we've never published anything about (nor done any research specifically on) the prospects for private p2p streaming, even though it's something we discuss frequently on our discord.
Once we get this thing launched, we'll right that wrong.
Most calls don't have lots of users, so this is a good tradeoff for many use cases given the security and quality advantages.
Also, networks are getting faster, and so the nr of supportable participants in p2p video calls goes up and conceivably stops being an issue in some years. Many users already have fast enough networks for this today.
Hey how is this better than the Janus webrtc server? It's been developed for a decade, and could flip a page like this in an hour or so. I'm genuinely curious how you could surpass it in stealth, like minus the marketing fluff.
We changed the title from "Show HN: Zipcall.io – Peer to peer browser video calling with no latency". Show HN is for sharing something that you've personally created (please see the rules: https://news.ycombinator.com/showhn.html). And "no latency" sounds more baity than reasonable.
WebRTC uses UDP holepunching via STUN, it's built into almost all browsers and there are free STUN servers online. If you have some types of more tricky networks (usually symmetric NAT or more tricky firewalls) you need TURN which basically proxies the encrypted stream over TCP via the TURN server, but most home and smaller networks can do holepunching.
You still need signaling of the SDP offer, but that can be done via email/sms/whatever if you really don't want to have a server at all.
This service is just run-of-the-mill WebRTC, nothing special about it though.
35 comments
[ 4.9 ms ] story [ 1350 ms ] threadCould you elaborate what makes this different from normal P2P WebRTC without a SFU? Do you feel that the claim of "no latency" is even possible/reasonable regardless of the tech involved?
It’s a nice project, but:
> Zipcall is built radically different. We left behind slow bulky servers, opting for decentralized peer to peer calling. We engineered a platform with maximum video quality and low latency.
Translation: it uses WebRTC or we didn’t invent anything — it uses technology built into your browser.
> State of the art VP9 video compression combined with our scaling optimization makes your calls crystal clear.
Same as above (assuming you’re browser supports VP9).
> Breakthrough peer to peer WebRTC technology means your video goes directly to the other person without a server. No middleman. No extra stops.
Same as above.
> End to end state of the art encryption means your calls are exactly that. Your calls.
How exactly?
A quick glance at the readme suggests that this negotiates peer-to-peer connections using Twilio. But it's not just that it's p2p, right? Since there are a ton of p2p video-calling tools out there, most memorably to me the original Skype before Microsoft bought it.
In comparison, Jitsi sort-of worked on the same devices (but screen share was limited to 5 FPS).
(disclaimer: this is what I work on)
Once we get this thing launched, we'll right that wrong.
Also, networks are getting faster, and so the nr of supportable participants in p2p video calls goes up and conceivably stops being an issue in some years. Many users already have fast enough networks for this today.
https://janus.conf.meetecho.com/videoroomtest.html
It was the same bad WebRTC quality, perhaps even worse as my video preview was really laggy.
You still need signaling of the SDP offer, but that can be done via email/sms/whatever if you really don't want to have a server at all.
This service is just run-of-the-mill WebRTC, nothing special about it though.