agranig's comments

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.

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.

The only thing Asterisk does in our system is acting as a voicemail server.

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.

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.

There is a "next steps" section at the bottom of the post pointing this out. You can check the handbook at http://www.sipwise.com/doc/2.6/spce/ar01s04.html#_creating_p... to learn how to do it.

The post warns about NAT on the server-side (like Amazon EC2 does). Client-side NAT works just fine.

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.

You are just jealous of our plan :)

If you go lean, revenue is everything. You start with something small, you fight to get every single customer, you grow with every project, staffing up another developer or sysops engineer paid from your own pocket to do a bigger project than the past one, trying to get your "side-product" ready to not be dependent of more projects at some point...

And then, you've the Double Stealth. Why bother with revenues, if VCs are throwing money at you? Why bother with customers at all? Why bother with products? Hell, why not just completely hiding what we do, as long as the money is flowing? Problem? :D

Yes!?

Blue is so facebook, and everybody hates facebook at the moment, so we are grey/yellow for now. Has some potential for pivoting though.

And since customer satisfaction is everything, we published our progress on https://twitter.com/doublestealth/status/220277242935246848 just for you.

Writing great code means making it easily readable and understandable by other developers. If you want to show off your quirky syntax skills, for god's sake play perl golf or attend at obfuscated code contests.

What was your reason to do both a Ltd in UK and a GmbH in Austria?

We've registered an Austrian GmbH couple of years ago and haven't had any issues with that so far. The break-down of voting rights and shares are directly bound to how the common stock (usually 35k€ in AT) is being split. When it comes to investment rounds, the investors either increase the common stocks or buy it from the other shareholders for the nominal price (the percentage of the common stock value). The whole process is strictly bound to a formal process (a notarial act), which can get quite expensive, which is the only down-side in the long run.

On the other hand, Ltds still have some shady smack for some reasons over here (one is that you're seen as being cheap), so when you're an Austrian or German company, I bet you gonna need to explain as a small startup why you have gone the Ltd path when talking to big potential customers, and I think this is something you want to avoid at that stage ("act like how you want to be seen, not like who you are", and each serious company here is a GmbH). I understand that it's a big turn-off for young founders to put in 17.5k€ in cash from the start (which is the minimum amount to be provided when founding), but it pays off when it comes to reputation, at least when acting in the B2B business.

This is pretty cool, thanks! Setting "double_buffer yes" prevents it from flickering in Ubuntu.

As for the command-line VoIP app, you can use "linphonec" included in http://www.linphone.org/.

The tips at http://www.webupd8.org/2011/04/things-to-tweak-fix-after-ins... solved a lot of pain points for me.

Vienna, Austria

Sipwise - http://www.sipwise.com

Sipwise develops and integrates open-source VoIP soft-switches for Europe's biggest Cable operators.

We're hiring full-time, on-site Perl developers and VoIP engineers, check http://www.sipwise.com/news/jobs/sipwise-is-hiring-perl-web-... and http://www.sipwise.com/news/jobs/sipwise-is-hiring-voip-engi... for details. If you need to relocate, we'll of course assist you in finding a nice place.

The VoIP and System engineer positions are full-time and on-site jobs, no exceptions here. If you're an experienced Perl/Catalyst hacker with a good track record, we would also consider telecommute and/or contracting.

@Sipwise in Vienna/Austria

- Web developer: Perl/Catalyst/MySQL and HTML/CSS/JS

- VoIP engineer: OpenSER/Kamailio/OpenSIPS and >3 years of experience in SIP routing

- System engineer: HA/Scalability/Mass-Deployment using Corosync, Pacemaker, Git, Perl

We develop and integrate carrier-grade VoIP systems for 100k-1Mio end users each at major European ISPs. Send an email to agranig at sipwise dot com.