And the other 50% is the network effect.
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.
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.
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?
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.
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.
re: p2p stuff
Read the code before you read the marketing copy.
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.
Have you considered of using Freeswitch to replace Asterisk and maybe even your own media relay module?
It makes the setup and maintenance easy, basically.
Personally I use Asterisk with all the standard SIP clients (CSIPSimple on Android for example)
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.
[1] http://apprtc.appspot.com/ [2] source: http://code.google.com/p/webrtc-samples/source/browse/trunk/...
