Alternatively throw up an instance of apprtc[1], which is a few hundred lines of JS using the new WebRTC APIs. NAT traversal, background noise reduction, gain boosting, bandwidth adaptation all come for free.
the idea that it's a skype replacement while simultaneously warning the reader about avoiding NAT is funny, 50% of the skype secret sauce is the NAT traversal.
The real secret sauce is their dead-simple way to sign up and use the client. As you can see in the post, the setup process with the Jitsi client is still a bit awkward, because it is supposed to be a provider-agnostic multi-protocol client. There is still a huge potential in stream-lining this process to get a broad end-user adoption. Flexibility really isn't key in this case, rather than proper UX.
I applaud this effort. Jitsi is nothing new and predates all the Skype hype. My guess is it may even be true "end to end," i.e. it relies on no third party "service" that Joe User would find a little too much hassle to run himself, such as XMPP (or even SIP, for that matter).
But the first problem I have with Jitsi is that the source is still not open. Looking at current website you have to be a "project member".
It's Java-based, right? I want to see that code. If the solution I'm using is less than a few hundred lines of C (quite manageable for any security analysis), why should I blindly (i.e. without seeing the code) switch to Jitsi?
These p2p threads are continually entertaining because they prove time and again how many people still think NAT traversal is some sort of "magic" requiring special expertise (e.g., that only Skype or some other private company has).
That might just be a myth.
Example: Proving a negative. If I can't find a piece of code to do some task does that mean it does not exist? Maybe I just can't find it?
agranig himself mentions a couple of things that are in wide use but "little known". Not every solution is going to be widely known. That does not mean such solutions do not exist.
Doing a simple "
svn co https://svn.java.net/svn/jitsi~svn/trunk jitsi" works perfectly fine for me. Same with the source snapshots at https://download.jitsi.org/jitsi/nightly/src/ . We also had no issues getting our bugfixes into their upstream while we did all the testing. I was wondering about the "observer/member" thing they mention on the website as well, doesn't seem to be relevant though.
Cool. I will have a look then. Thanks again for the tutorials and fixing Jitsi bugs. This is definitely a step in the right direction for moving beyond Skype. Great to see it.
Why make it particularly SIP and not for example Jingle based? And there is no need to build anything. Just use regular XMPP servers infrastructure. Security can be achieved with ZRTP and OTR, though current implementation of secure XMPP/Jingle clients is still lacking.
I have a Skype-in regular phone number. I did not see how to set that up and without some sort of local number availability, for me at least, this is no "Skype Replacement"
In this post, we attempt to build a free, secure, SIP based communication system to provide encrypted voice and video communication, buddy lists, instant messaging, presence and remote desktop sharing/control on a self-hosted system.
I think they mean "in the context of a few private users using skype to communicate with each other", such as a startup or maybe even a tech-happy family.
One of our customers serves north of 1 mio overall provisioned subscribers on two servers with this software, so it's quite scaleable vertically already. It's easier when UDP is used though, because with TLS things add up quite quickly.
To go big, we've horizontal scaling mechanisms using subscriber partitioning by load-balancing SIP and provisioning requests over multiple pairs of such servers (usually placed in blade-center servers).
The key here is to keep as much CPU heavy things like media relaying end-to-end where possible, because the signaling part is pretty light-weight in SIP. To scale out and keep reliability up while keeping complexity low, we have a shared-nothing approach wherever possible. Works well for us.
Maybe he just meant from the user's perspective. If someone just wants to able to call their friends and family, they do not need 32 million users to switch over to anything. What they need are simple instructions and the code to set up the network and make those calls.
The people who brought you your Skype were a bit "bold" don't you think? Shouldn't they have just left VOIP to the telcos? The telcos have 100's of millions of customers. How many did Skype have when it started?
Is this a startup forum or an "I love the status quo" forum?
I didn't mean to be discouraging, sorry about that. It's just that I think "replacing Skype" is more about non-technical things than setting up a SIP server. I used to be involved with this industry back in the day of SER 0.x. It was pretty hard to get people to switch to use anything new, but Skype did that. They were just bringing out the Skype USB handsets and other bundle deals in my country back then.
Nowadays I use many different networks for communication, such as Skype, MS Live, GTalk, Facebook. The reason is that different people are online in different networks and they're not switching from A to B just if I ask. They have their own existing contacts in their networks.
Still I definitely support anything that can replace Skype, since it's totally closed and there's no way to verify the security. And I hate the Mac client.
Sorry if I came across the wrong way. It's just that I find the "replace program x" idea to be counterproductive. It makes it far too easy to dismiss everything.
Maybe the goal is not to "replace" Skype (that would probably imply duplicating all its features, right?) but to offer alternatives for doing some, maybe even all, maybe even more than you can currently do using Skype.
We cannot just assume that everyone wants to replace other programs/solutions whenever they offer an alternative. It may just be additive.
You have given an example: You use many different networks for different things. None of them are exclusive. You can use them all if you like.
It might be easier to get uptake of something "new" (and nurture that infamous "network effect") if it is not framed as "replacement for enormously popular program x that users already know how to use and which works good enough".
Does that make sense?
If I have a cool alternative OS to share with HN, how far do you think I will get if I frame it as a "replacement for iOS/OSX/Linux"? Not very far. The problem is that even if you do not explicitly claim it is a replacement for anything, HN'ers still assume that's what you are implying by even mentioning it.
This is nuts. If someone offers me an OS/program/solution that can do something I can't currently do with the existing OS/programs/solutions I use, I'm not going to disregard it simply because it duplicates some of the functionality of those programs.
I don't automatically think of the choice as "either-or", I think of it as "should I add this to my options". I ask what can this offer me? Can I split out the functionality in this program that I cannot get in existing programs? But I know many users do view things as either-or. It would be foolish to ignore that. "You can never replace program x." OK, we hear you.
This is why I like small programs that only do one thing. If the user is going to view your using your program as an "either-or" decision (it must _replace_ what they currently use) instead of a "can I use this in addition to what I'm already using" decision, then the chances of deciding not to try your program are significantly increased if your program is some sort of do-everything whiz-bang solution. That's because when you offer so many features, some of those the user is already getting from other existing OS/programs/solutions. They are effectively forced to see things as either-or.
What if, e.g., someone offered just the NAT traversal function of Skype, and someone else offered an encryption program, and yet someone else offered a simple open source command line client (e.g. built with pjsip) that developers could write their own GUI's for? None of them would be trying to "replace" Skype, but using those programs in combination, you could indeed construct a Skype alternative. You might actually be able to do more than Skype can do because it would be a more flexible system. As it stands, you are stuck with that Skype UI. And you're stuck with Microsoft. But if you had an open source command line client that anyone could write a GUI for... and solutions to traversing NAT... and solutions for keeping third parties from tampering/intercepting/eavesdropping...
The Jitsi guys are currently working on an Android version, let's see what comes out of that.
In general, the reason for the slow adoption of SIP beyond just pure voice telephony is that the SIP/SIMPLE standard with its companions for buddy lists etc. is really crappy, and as a result so are most clients (or the interoperability between them). It doesn't make it better that the mobile device/equipment vendors forked off their own OMA standards, so the situation is pretty bad in that regards.
I still don't give up all hopes to see a proper Android/IOS SIP client supporting voice, video presence etc. while at the same time adhering to the standards.
The real work-horses are actually Kamailio and Sems, which are quite little known but power a LOT of your ISPs' VoIP systems.
Provisioning is built on top of Apache/Perl/Catalyst with a MySQL backend. The billing system is in C and Perl, and the Media Relay is in C with an own kernel module on top of iptables.
Asterisk is pretty insignificant, but it's surely the best known part in the VoIP world.
[1] http://apprtc.appspot.com/ [2] source: http://code.google.com/p/webrtc-samples/source/browse/trunk/...