41–50 of 80 posts
I've been working with WebRTC for a year now building Sqwiggle ( https://www.sqwiggle.com ) - In my experience I can tell you two things, - It's not really possible to go entirely peer-to-peer as many networks do not allow for this communication to happen. You would have constant issues with calls not being able to connect. Some centralised service is required for signaling, STUN and TURN which costs money and uses s…
This should work with WebRTC ( http://www.webrtc.org/ ) using the reference app: https://apprtc.appspot.com/ It should enable you to connect 2 browsers (e.g. Chrome and Firefox), all you need is to transmit the ID of the chat ("r" parameter from the chat URL you will get) to the peer, or the full URL. It keeps amazing me that we do not have simple JS solutions for this, when projects like Chatroulette can be built in…
Same codec set, SDP offer-answer, SRTP(C), ICE and other old cool things nobody cared to implement in real SIP clients for decades.
I've been working with WebRTC for a year now building Sqwiggle ( https://www.sqwiggle.com ) - In my experience I can tell you two things, - It's not really possible to go entirely peer-to-peer as many networks do not allow for this communication to happen. You would have constant issues with calls not being able to connect. Some centralised service is required for signaling, STUN and TURN which costs money and uses s…
TURN does, but not STUN. STUN's just for address discovery and many VoIP providers allow anyone to use theirs. But agreed - STUN on its own can fix only some connection.
Anyway, I think IPv6 can't be here soon enough. That would allow many improvements in the p2p networks!
See this video: http://www.youtube.com/watch?v=9MWYw0fltr0 which explains the causes behind reliability problems.
I have thought about running my own server to manage my NATted voip calls and knowing ice/stun/turn will help has now led me to this: http://www.rtcquickstart.org/introduction
I'm thinking I might try to implement this. Voip on my mobile phone would be great, but I've had my hopes dashed before...
I've been working with WebRTC for a year now building Sqwiggle ( https://www.sqwiggle.com ) - In my experience I can tell you two things, - It's not really possible to go entirely peer-to-peer as many networks do not allow for this communication to happen. You would have constant issues with calls not being able to connect. Some centralised service is required for signaling, STUN and TURN which costs money and uses s…
> Even if you do go peer-to-peer with WebRTC the quality would still be improved by going through a central server (less upstream bandwidth required) Why is that?
2. This doesn't help with the amount of bandwidth used, but sometimes due to peering (that VoIP companies really care about) you can get lower delay going via them rather than directly. This is not very common, but it happens (especially if your broadband provider is your VoIP provider for example).
Maybe the poster above had another reason for it too. There's loads of edge cases in the ITSP world.
I've been working myself on an open source alternative http://vmux.co (code: https://github.com/malditogeek/vmux) but it requires a Twitter account to log in which my pose a problem to your dad. (The upcoming version will allow you to use it without an account tho)
To the people that want to host their own "skype alternatives" have in mind that it's not just serving the HTML+JS. WebRTC needs a way to bootstrap the P2P connection, the so called signaling, vmux provides a signaling mechanism using websockets but you'll still need a STUN server (I'm using the Google's one) and optionally a TURN server to relay users behind crazy NATs.
I've been working with WebRTC for a year now building Sqwiggle ( https://www.sqwiggle.com ) - In my experience I can tell you two things, - It's not really possible to go entirely peer-to-peer as many networks do not allow for this communication to happen. You would have constant issues with calls not being able to connect. Some centralised service is required for signaling, STUN and TURN which costs money and uses s…
> STUN and TURN which costs money and uses significant amounts of bandwidth. TURN does, but not STUN. STUN's just for address discovery and many VoIP providers allow anyone to use theirs. But agreed - STUN on its own can fix only some connection. Anyway, I think IPv6 can't be here soon enough. That would allow many improvements in the p2p networks!
- being generally available soon enough to matter (ever tried accessing your home connection via IPv6 from your mobile? There's no usable workaround that I've found so far and I don't see networks switching to IPv6 anytime soon)
- easy to migrate to (privacy concerns, lots of things to relearn, existing hard- and software WILL break - as my ISP provided cable modem does every three days when my prefix is renewed -> Reboot/reconnect or you're silently offline forever)
The idea is great. I was a fan of the technology in theory. Living with IPv6 at home for ~2 month now I'm considering to cancel my contract _because of issues due to the IPv6 migration_.
That aside, ignoring my anecdotal troubles and my personal disappointment with the way IPv6 is (not..) introduced around me: How would IPv6 help anyway? Just because you're having a globally routable address for all your machines probably doesn't mean that you want them to be directly exposed to the internet? Wouldn't you still need (rather: want) to punch a hole through the firewall?
No account needed and you can instantly start video chatting with anyone who has a modern browser.