source: http://code.google.com/p/webrtc-samples/source/browse/trunk/...
And the other 50% is the network effect.
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.
It makes the setup and maintenance easy, basically.
Personally I use Asterisk with all the standard SIP clients (CSIPSimple on Android for example)
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.
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...
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.
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?